Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Discussions Générales [long] compilation de mount : erreur

[long] compilation de mount : erreur

9 réponses
Avatar
Thomas Nemeth
Bonjour.

Voilà : j'ai un vieux portable avec une vieille debian dessus. Pour
diverses raisons, je ne peux pas changer de version de debian dessus
(en particulier pour du matos incorrectement supporté par les noyaux
récents).
M'étant acheté un appareil photo usb il y a peu, j'ai donc décidé de
recompiler le noyau 2.2.25. Impec. Tout s'est très bien passé (sauf
pour mon appareil photo qui est trop récent pour l'usb du 2.2.25,
mais c'est pas grave, j'ai des scripts pour knoppix qui font ça tout
seuls, même si ça nécessite de booter une knoppix puis de revenir
sous debian).

Le seul truc qui pêche, c'est mount. En effet, il me gueule dessus
comme quoi le noyau serait plus récent que mount (ce qui est
effectivement le cas :), et, comble du comble, ne veut pas monter
/proc/bus/usb. Bon. Normal, puisqu'il a été compilé avec un 2.2.17
qui ne supportait pas l'usb.

Donc, pour faire ça « the Debian way » :
apt-get source -b mount
Reading Package Lists... Done
Building Dependency Tree... Done
Need to get 1129kB of source archives.
Get:1 http://archive.debian.org potato/main util-linux 2.10f-5.1 (dsc) [610B]
Get:2 http://archive.debian.org potato/main util-linux 2.10f-5.1 (tar) [1048kB]
Get:3 http://archive.debian.org potato/main util-linux 2.10f-5.1 (diff)[79.7kB]
Fetched 1129kB in 18s (60.8kB/s)
[...]
rm -f nfs_mountversion.h
if [ -f /usr/include/linux/nfs_mount.h ]; then \
grep NFS_MOUNT_VERSION /usr/include/linux/nfs_mount.h \
| sed -e 's/NFS/KERNEL_NFS/'; \
else \
echo '#define KERNEL_NFS_MOUNT_VERSION 0'; \
fi > nfs_mountversion.h
cc -c -Wall -Wstrict-prototypes -Wmissing-prototypes -I../lib -pipe -O2
-m486 -fomit-frame-pointer -DHAVE_NFS nfsmount.c
In file included from /usr/include/linux/nfs_mount.h:11,
from nfs_mount3.h:15,
from nfsmount.c:53:
/usr/include/linux/in.h:129: warning: `IN_CLASSA' redefined
/usr/include/netinet/in.h:117: warning: this is the location of the
previous definition
[...] (il y en a plusieurs comme ça)
In file included from /usr/include/linux/nfs_mount.h:11,
from nfs_mount3.h:15,
from nfsmount.c:53:
/usr/include/linux/in.h:25: conflicting types for `IPPROTO_IP'
/usr/include/netinet/in.h:35: previous declaration of `IPPROTO_IP'
[...] (là aussi il y en a plusieurs)
/usr/include/linux/in.h:51: redefinition of `struct in_addr'
/usr/include/linux/in.h:91: redefinition of `struct ip_mreq'
/usr/include/linux/in.h:97: redefinition of `struct ip_mreqn'
/usr/include/linux/in.h:104: redefinition of `struct in_pktinfo'
/usr/include/linux/in.h:112: redefinition of `struct sockaddr_in'
In file included from /usr/include/linux/byteorder/little_endian.h:11,
from /usr/include/asm/byteorder.h:45,
from /usr/include/linux/in.h:177,
from /usr/include/linux/nfs_mount.h:11,
from nfs_mount3.h:15,
from nfsmount.c:53:
/usr/include/linux/byteorder/swab.h:100: warning: no previous prototype
for `__fswab16'
[...] (encore plusieurs)
nfsmount.c: In function `nfsmount':
nfsmount.c:245: `NFS_VERSION' undeclared (first use in this function)
nfsmount.c:245: (Each undeclared identifier is reported only once
nfsmount.c:245: for each function it appears in.)
nfsmount.c:558: `NFS_PORT' undeclared (first use in this function)
nfsmount.c:145: warning: `nfsvers' might be used uninitialized in this
function
make[2]: *** [nfsmount.o] Erreur 1
make[2]: Quitte le répertoire `/root/util-linux-2.10f/mount'
make[1]: *** [all] Erreur 1
make[1]: Quitte le répertoire `/root/util-linux-2.10f'
make: *** [build] Erreur 2
Build command 'cd util-linux-2.10f && dpkg-buildpackage -b -uc' failed.
E: Child process failed


Voilà.
J'ai un peu de mal à comprendre : comment ceux qui font les paquets
binaires réussissent-ils à compiler quoi que ce soit dans ces
conditions ?

J'ai bien entendu un /usr/include/linux adapté au nouveau noyau.

Y a-t-il un moyen simple d'avoir un mount adapté ?
C'est pas que c'est vital : mount fonctionne quand même, mais bon,
ce serait mieux si ça pouvait marcher correctement...


Thomas
--
BOFH excuse #43:
Boss forgot system password.

--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Florent Rougon
Thomas Nemeth wrote:

Bonjour.



Bonjour,

J'ai bien entendu un /usr/include/linux adapté au nouveau noyau.



Je crains que ceci ne signifie pour vous :

/usr/include/linux -> /usr/src/linux/include

Ceci n'est plus à la mode. Depuis un certain temps, il est de bon ton
d'avoir dans /usr/include/linux les headers d'un(e version du) noyau que
la glibc installée connait bien, et qui sont bien stables. D'ailleurs
(sur une woody, certes -- désolé, je n'ai pas de place pour un
musée [complet ;-]...) :

% dpkg -S /usr/include/linux/stat.h
libc6-dev: /usr/include/linux/stat.h

/usr/share/doc/kernel-package/README.headers parle de toute cette
histoire (j'espère que c'est à jour ; ça fait longtemps que je ne l'ai
pas regardé).

--
Florent

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Thomas Nemeth
Le mar 25 nov 2003 à 10:01, Florent Rougon a tapoté :
| Thomas Nemeth wrote:
|
| > J'ai bien entendu un /usr/include/linux adapté au nouveau noyau.
|
| Je crains que ceci ne signifie pour vous :
|
| /usr/include/linux -> /usr/src/linux/include

Effectivement.


| Ceci n'est plus à la mode.

Ah ! C'était une mode ? :)


| Depuis un certain temps, il est de bon ton
| d'avoir dans /usr/include/linux les headers d'un(e version du) noyau que
| la glibc installée connait bien, et qui sont bien stables.

Hum. Dans ce cas comment dire à mount qu'on a compiler le noyau pour
supporter de nouveaux FS ? Si on utilise des headers obsolètes, ne
reconnaissant pas les fonctionnalités du nouveau noyau, ça ne sert
à rien, non ?
(j'ai tout de même aussi testé avec ce que j'avais déjà, et ça ne
fonctionne pas plus)


| D'ailleurs
| (sur une woody, certes -- désolé, je n'ai pas de place pour un
| musée [complet ;-]...) :
|
| % dpkg -S /usr/include/linux/stat.h
| libc6-dev: /usr/include/linux/stat.h

c'est aussi le cas avec une potato.


Thomas
--
Il faut pomper pour vivre et donc vivre pour pomper.
-- Proverbe Shadok

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Yann Marigo
hello,

Bonjour.

Voilà : j'ai un vieux portable avec une vieille debian dessus.
Pour diverses raisons, je ne peux pas changer de version de debian
dessus(en particulier pour du matos incorrectement supporté par
les noyaux récents).
M'étant acheté un appareil photo usb il y a peu, j'ai donc décidé
de recompiler le noyau 2.2.25.



Une question: tu dis que tu ne peux upgrader car le noyaux trop récents
ne supportent plus ton matériel, mais une woody installe un 2.2.22 (ou
24 dans la dernière version). Où est le piège ?

A mon avis, tu devrais faire un distupgrade histoire de remettre tes
packages à jour. Si après tu dois recompiler ton noyau pour tout
supporter, ce sera au moins avec des headers récents. un 2.2.17, ce
n'est même pas un potato ça, c'est quoi comme release ?


--
@+ Yann Marigo
Dernier mini_howto: "Ajouter le support ext3 à son noyau 2.2.2x" :
http://www.geekounet.org/docs/ext3_2.2_kernel_mini_howto.html
Article en Free Documentation Licence biensûr ! ;-)

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Thomas Nemeth
Le mer 26 nov 2003 à 10:12, Yann Marigo a tapoté :
| hello,

'lu Yann.


| > Voilà : j'ai un vieux portable avec une vieille debian dessus.
| > Pour diverses raisons, je ne peux pas changer de version de debian
| > dessus(en particulier pour du matos incorrectement supporté par
| > les noyaux récents).
| > M'étant acheté un appareil photo usb il y a peu, j'ai donc décidé
| > de recompiler le noyau 2.2.25.
|
| Une question: tu dis que tu ne peux upgrader car le noyaux trop récents
| ne supportent plus ton matériel, mais une woody installe un 2.2.22 (ou
| 24 dans la dernière version). Où est le piège ?

Ah ? Il m'avait semblé que c'était un 2.4...


| A mon avis, tu devrais faire un distupgrade histoire de remettre tes
| packages à jour. Si après tu dois recompiler ton noyau pour tout

Oui. Ceci dit ça ne m'explique pas pourquoi ça ne compile pas plus
avec les fichiers et tout ce qui est fourni par la distro :(


| supporter, ce sera au moins avec des headers récents. un 2.2.17, ce
| n'est même pas un potato ça, c'est quoi comme release ?

Si si, potato. C'était la dans la r0. Elle est ensuite passée au
2.2.19...


Thomas
--
le seul moyen de se mettre vraiment a Linux, c'est de passer par une distrib
radicale : ca te force à en chier pour en comprendre le fonctionnement !


La Mdk n'est pas mal pour ça. Surtout quand tu désire travailler avec.
-+- GN in GFA : "La mdk c'est plus fort que toi" -+-

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Florent Rougon
Thomas Nemeth wrote:

| /usr/include/linux -> /usr/src/linux/include



[...]

| Ceci n'est plus à la mode.

Ah ! C'était une mode ? :)



Bon, OK, c'était la méthode recommandée[1] il y a quelques années. :)

| Depuis un certain temps, il est de bon ton
| d'avoir dans /usr/include/linux les headers d'un(e version du) noyau que
| la glibc installée connait bien, et qui sont bien stables.

Hum. Dans ce cas comment dire à mount qu'on a compiler le noyau pour
supporter de nouveaux FS ? Si on utilise des headers obsolètes, ne
reconnaissant pas les fonctionnalités du nouveau noyau, ça ne sert
à rien, non ?



Je ne suis pas un expert en noyau/libc (si quelqu'un de plus compétent a
d'autres idées sur la question, son intervention est la bienvenue), mais
si j'étais à votre place, j'essaierais de mettre à jour la libc (en
prenant les précautions nécessaires, bien-sûr). Je commencerais par
essayer de voir si je peux le faire simplement via le package libc6 de
woody. Les premiers problèmes vont venir de son champ :

Conflicts: strace (<< 4.0-0), libnss-db (<< 2.2-3), timezone, timezones,
gconv-modules, libtricks, libc6-doc, libc5 (<< 5.4.33-7),
libpthread0 (<< 0.7-10), libc6-bin, libwcsmbs,
apt (<< 0.3.0), libglib1.2 (<< 1.2.1-2), libc6-i586,
libc6-i686, libc6-v9, netkit-rpc

Il y a aussi libc6-dev qui pourrait être coton, selon les versions dans
potato des packages cités dans les Conflicts :

Conflicts: libstdc++2.10-dev (<< 1:2.95.2-15), gcc-2.95 (<< 1:2.95.3-9),
libpthread0-dev, libdl1-dev, libdb1-dev, libgdbm1-dev,
libc6-dev (<< 2.0.110-1), locales (<< 2.1.3-5),
libstdc++2.9-dev, netkit-rpc, libc-dev

[ au fait, potato n'est plus supportée par la Debian Security Team,
c'est clair, n'est-ce pas ? ]

Hmmm. En tout cas, je ne conçois pas de mettre à jour la libc sans
passer par le package Debian (à moins que le but soit d'obtenir une LFS
obsolète).

Si la solution précédente s'avère compliquée à mettre en oeuvre, il y en
a une autre, assez simple, consistant à faire tourner avec votre noyau
2.2.25 un (ch)root de woody ou de sid (ou de testing). Dans celui-ci, la
libc et le mount seraient assez récents et toutes les mises à jour se
feraient le plus simplement du monde avec dselect. Il faudrait bien
entendu monter proc au bon endroit (<(ch)root>/proc) en plus du point de
montage habituel, /proc dans la « vraie » racine.

Vous ne pourriez monter votre FS récent qu'à l'intérieur du chroot
(allez, abusons), mais les applications hors de ce chroot pourraient y
accéder sans problème, donc ce n'est peut-être pas gênant.

Pour info, j'ai un chroot sid sur ma presque-woody et je peux y faire
tourner toutes sortes d'applications sans problème, même graphiques
(même OpenOffice.org...), avec un script qui fait des petites
invocations de xauth avant de rentrer dans le chroot, et un
environnement à l'intérieur du chroot tel que DISPLAY contienne un truc
comme localhost:0.0 (et un X à l'extérieur du chroot qui écoute sur les
sockets TCP et un netfilter qui empêche les machines extérieures d'en
profiter pour m'em***der).

On peut aussi lancer le X du chroot directement sur une console mais je
trouve cela peu pratique car ça oblige à avoir deux sessions X
distinctes. Par contre, ça permet de tester un X récent sans flinguer sa
Debian si besoin est.

| % dpkg -S /usr/include/linux/stat.h
| libc6-dev: /usr/include/linux/stat.h

c'est aussi le cas avec une potato.



Donc vous avez modifié un fichier sous /usr[pas-local] quand vous avez
fait le lien /usr/include/linux -> /usr/src/linux/include.

C'est Mal(TM). /usr[pas-local] est le domaine réservé de dpkg !

Si vous avez compilé des applis avec cette config, elles utilisent des
headers différents de ceux des applis compilées par les développeurs
Debian (que vous avez sur votre machine) et ça pourrait je pense causer
des problèmes subtils (avec des programmes liés à des bibliothèques, par
exemple).

[1] En tout cas, si je me souviens bien, dans _Programmation Linux 2.0_,
dont les auteurs connaissaient a priori un bon rayon sur le noyau.
De plus, le fichier /usr/share/doc/kernel-package/README.headers
m'incite à croire que ce n'était pas une lubie de ces seuls auteurs.

--
Florent

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Thomas Nemeth
Le mer 26 nov 2003 à 16:30, Florent Rougon a tapoté :
| Thomas Nemeth wrote:
|
| > | Ceci n'est plus à la mode.
| >
| > Ah ! C'était une mode ? :)
|
| Bon, OK, c'était la méthode recommandée[1] il y a quelques années. :)

:))


| > | Depuis un certain temps, il est de bon ton
| > | d'avoir dans /usr/include/linux les headers d'un(e version du) noyau que
| > | la glibc installée connait bien, et qui sont bien stables.
| >
| > Hum. Dans ce cas comment dire à mount qu'on a compiler le noyau pour
| > supporter de nouveaux FS ? Si on utilise des headers obsolètes, ne
| > reconnaissant pas les fonctionnalités du nouveau noyau, ça ne sert
| > à rien, non ?
|
| Je ne suis pas un expert en noyau/libc (si quelqu'un de plus compétent a
| d'autres idées sur la question, son intervention est la bienvenue), mais
| si j'étais à votre place, j'essaierais de mettre à jour la libc (en
| prenant les précautions nécessaires, bien-sûr).

Ouch.
Ça veut donc bien dire que mount est dépendant de la version de la
libc en ce qui concerne ce qu'il peut monter :(


| Je commencerais par
| essayer de voir si je peux le faire simplement via le package libc6 de
| woody.

Autant mettre à jour avec la woody :-/


| [ au fait, potato n'est plus supportée par la Debian Security Team,
| c'est clair, n'est-ce pas ? ]

Tout à fait. Potato est même sur archive.debian.org et donc plus
dans les pool habituels.


| Hmmm. En tout cas, je ne conçois pas de mettre à jour la libc sans
| passer par le package Debian (à moins que le but soit d'obtenir une LFS
| obsolète).

Effectivement, ça reviens à ça.


| Si la solution précédente s'avère compliquée à mettre en oeuvre, il y en
| a une autre, assez simple, consistant à faire tourner avec votre noyau
| 2.2.25 un (ch)root de woody ou de sid (ou de testing).

Pas la place :)
Je n'ai qu'un disque de 2Go et la machine est trop vieille pour les
disques de + de 8Go (et on n'en trouve plus).


| > | % dpkg -S /usr/include/linux/stat.h
| > | libc6-dev: /usr/include/linux/stat.h
| >
| > c'est aussi le cas avec une potato.
|
| Donc vous avez modifié un fichier sous /usr[pas-local] quand vous avez
| fait le lien /usr/include/linux -> /usr/src/linux/include.

Disons que j'ai fait un
mv /usr/include/linux /usr/include/linux-orig
ln -s /usr/src/linux/include/linux /usr/include


| C'est Mal(TM). /usr[pas-local] est le domaine réservé de dpkg !

Mouais. Mais bon, d'un autre côté, il lui arrive de me les briser,
dpkg ;)
(Ça fait des années que je souhaite des .deb avec relocation).


| Si vous avez compilé des applis avec cette config, elles utilisent des

Non, non, c'était juste pour tester après la 1ère tentative
infructueuse avec les trucs de dpkg.


| headers différents de ceux des applis compilées par les développeurs
| Debian (que vous avez sur votre machine) et ça pourrait je pense causer
| des problèmes subtils (avec des programmes liés à des bibliothèques, par
| exemple).

Je suis seul sur mes machines à compiler quoique ce soit.


| [1] En tout cas, si je me souviens bien, dans _Programmation Linux 2.0_,
| dont les auteurs connaissaient a priori un bon rayon sur le noyau.

Oui, je l'ai ici :)


Thomas
--
BOFH excuse #40:
Not enough memory, go get system upgrade.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Florent Rougon
Thomas Nemeth wrote:

| Une question: tu dis que tu ne peux upgrader car le noyaux trop récents
| ne supportent plus ton matériel, mais une woody installe un 2.2.22 (ou
| 24 dans la dernière version). Où est le piège ?

Ah ? Il m'avait semblé que c'était un 2.4...



C'est un 2.2 par défaut et un 2.4 si on le demande au menu de boot (lire
l'aide).

| A mon avis, tu devrais faire un distupgrade histoire de remettre tes
| packages à jour. Si après tu dois recompiler ton noyau pour tout

Oui. Ceci dit ça ne m'explique pas pourquoi ça ne compile pas plus
avec les fichiers et tout ce qui est fourni par la distro :(



Ben y'a des chances pour que ce soit causé par les headers. Il est
clairement bien plus intéressant sur le long terme de passer en woody si
cela vous est possible plutôt que de mettre en oeuvre les solutions
décrites dans mon message précédent ! (et c'est probablement plus simple
que la solution de mise à jour de la libc).

--
Florent

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Florent Rougon
Thomas Nemeth wrote:

Ouch.
Ça veut donc bien dire que mount est dépendant de la version de la
libc en ce qui concerne ce qu'il peut monter :(



Non. J'ai bien dit que je ne suis pas expert dans ce domaine, mais les
messages d'erreur que vous avez postés me font penser à une
incompatibilité de la version de mount que vous avez essayé de compiler
avec les headers utilisés pour cette compilation. Une mise à jour de la
libc pourrait certes amener des headers compatibles avec ce mount, mais
la raison *immédiate* de cette mise à jour ne serait pas « pour que
mount puisse supporter de nouveaux FS ».

| Je commencerais par
| essayer de voir si je peux le faire simplement via le package libc6 de
| woody.

Autant mettre à jour avec la woody :-/



Oui !

| Si la solution précédente s'avère compliquée à mettre en oeuvre, il y en
| a une autre, assez simple, consistant à faire tourner avec votre noyau
| 2.2.25 un (ch)root de woody ou de sid (ou de testing).

Pas la place :)
Je n'ai qu'un disque de 2Go et la machine est trop vieille pour les
disques de + de 8Go (et on n'en trouve plus).



Arf, ces saletés de BIOS... :-|

À titre indicatif, un chroot « minimal » (ce qui serait le cas si vous
ne l'installiez que pour avoir un mount récent) ne doit pas dépasser les
100 à 300 Mo. Faudrait faire le test (avec debootstrap par exemple) pour
avoir des chiffres fiables.

Sinon, j'ai oublié de le dire dans mon post précédent, mais il est
important d'adapter les scripts d'initialisation dans le chroot pour ne
pas lancer des services non désirés lors des mises à jour des
packages... Par exemple, inetd est désactivé dans mon chroot sid puisque
j'ai déjà celui de woody qui tourne (et bénéficie des mises à jour de
sécurité, lui).

Disons que j'ai fait un
mv /usr/include/linux /usr/include/linux-orig
ln -s /usr/src/linux/include/linux /usr/include



OK, vous n'irez qu'au purgatoire, alors. ;-)

(Ça fait des années que je souhaite des .deb avec relocation).



Je ne sais pas si ça répond complètement à vos attentes, mais il y a
dpkg-divert(8) et l'option --root de dpkg(8) pour ce genre de choses.

Non, non, c'était juste pour tester après la 1ère tentative
infructueuse avec les trucs de dpkg.



OK.

--
Florent

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Thomas Nemeth
Le mer 26 nov 2003 à 22:41, Florent Rougon a tapoté :
| Thomas Nemeth wrote:
|
| > | A mon avis, tu devrais faire un distupgrade histoire de remettre tes
| > | packages à jour. Si après tu dois recompiler ton noyau pour tout
| >
| > Oui. Ceci dit ça ne m'explique pas pourquoi ça ne compile pas plus
| > avec les fichiers et tout ce qui est fourni par la distro :(
|
| Ben y'a des chances pour que ce soit causé par les headers. Il est
| clairement bien plus intéressant sur le long terme de passer en woody si
| cela vous est possible plutôt que de mettre en oeuvre les solutions
| décrites dans mon message précédent ! (et c'est probablement plus simple
| que la solution de mise à jour de la libc).

Bon.
Ça fait longtemps que cette enfilade est finie, mais j'ai le plaisir
d'anoncer que même sans recompilation, mon vieux mount peut monter
usbdevfs.
Et grâce à ça j'ai pu modifier le driver usb du 2.2.25 pour qu'il
reconnaisse mon APN !

OUF !

Merci à tous pour les infos...


Thomas
--
Ta mère elle adore jouer à RISC.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.