OVH Cloud OVH Cloud

[gentoo-user-fr] media-tv/linuxtv-dvb

10 réponses
Avatar
Pascal Ronecker
Salut,

c'est "amusant", si je veux faire un update de maplyer, voilà ce que me
propose emerge :

[ebuild N ] media-tv/linuxtv-dvb-1.1.1-r2 553 kB
[ebuild N ] media-tv/linuxtv-dvb-headers-3.1 0 kB
[ebuild N ] virtual/libintl-0 0 kB
[ebuild U ] media-video/mplayer-1.0.20060217 [1.0_pre7-r1]


Quand je regarde linuxtv je vois ca :
* media-tv/linuxtv-dvb
Latest version available: 1.1.1-r2
Latest version installed: [ Not Installed ]
Size of downloaded files: 553 kB
Homepage: http://www.linuxtv.org
Description: Standalone DVB driver for Linux kernel 2.4.x
License: GPL-2

Visiblement ca sert aux kernels 2.4.x
Or je suis en 2.6.14 (fait à la main ... vieille manie ...)
D'où ma question :
- comment faire pour ne pas subir cette install inutile
- accessoirement : c'est sorti d'où, jusqu'à présent il ne me le
proposait pas. (flaggé "N" par emerge -p)

--
gentoo-user-fr@gentoo.org mailing list

10 réponses

Avatar
Bruno Félix
Pascal Ronecker wrote:
Salut,

c'est "amusant", si je veux faire un update de maplyer, voilà ce que me
propose emerge :

[ebuild N ] media-tv/linuxtv-dvb-1.1.1-r2 553 kB
[ebuild N ] media-tv/linuxtv-dvb-headers-3.1 0 kB
[ebuild N ] virtual/libintl-0 0 kB
[ebuild U ] media-video/mplayer-1.0.20060217 [1.0_pre7-r1]


Quand je regarde linuxtv je vois ca :
* media-tv/linuxtv-dvb
Latest version available: 1.1.1-r2
Latest version installed: [ Not Installed ]
Size of downloaded files: 553 kB
Homepage: http://www.linuxtv.org
Description: Standalone DVB driver for Linux kernel 2.4.x
License: GPL-2

Visiblement ca sert aux kernels 2.4.x
Or je suis en 2.6.14 (fait à la main ... vieille manie ...)
D'où ma question :
- comment faire pour ne pas subir cette install inutile
- accessoirement : c'est sorti d'où, jusqu'à présent il ne me le
proposait pas. (flaggé "N" par emerge -p)




hello,

USE="-dvb" dans ton make.conf devrait le faire.
d'après gentoo-portage.com, ce use flag n'existait pas dans l'ebuild de
la 1.0_pre7-r1

Ciao.

--bur
--
mailing list
Avatar
Pascal Ronecker
Bruno Félix wrote:
Pascal Ronecker wrote:

Salut,

c'est "amusant", si je veux faire un update de maplyer, voilà ce que me
propose emerge :

[ebuild N ] media-tv/linuxtv-dvb-1.1.1-r2 553 kB
[ebuild N ] media-tv/linuxtv-dvb-headers-3.1 0 kB
[ebuild N ] virtual/libintl-0 0 kB
[ebuild U ] media-video/mplayer-1.0.20060217 [1.0_pre7-r1]


Quand je regarde linuxtv je vois ca :
* media-tv/linuxtv-dvb
Latest version available: 1.1.1-r2
Latest version installed: [ Not Installed ]
Size of downloaded files: 553 kB
Homepage: http://www.linuxtv.org
Description: Standalone DVB driver for Linux kernel 2.4.x
License: GPL-2

Visiblement ca sert aux kernels 2.4.x
Or je suis en 2.6.14 (fait à la main ... vieille manie ...)
D'où ma question :
- comment faire pour ne pas subir cette install inutile
- accessoirement : c'est sorti d'où, jusqu'à présent il ne me le
proposait pas. (flaggé "N" par emerge -p)




hello,

USE="-dvb" dans ton make.conf devrait le faire.
d'après gentoo-portage.com, ce use flag n'existait pas dans l'ebuild de
la 1.0_pre7-r1

Ciao.

--bur
--
mailing list





Tout s'explique donc !

merci bcp,

a+
--
mailing list
Avatar
Pascal Ronecker
Tiens ben els surprises continuent :

erreur a la compilation de mplayer:

tvi_v4l2.c:44:29: linux/videodev2.h: No such file or directory


et pourtant :

locate videodev2.h
/usr/src/linux-2.6.14/include/linux/videodev2.h

ll /usr/src/
lrwxrwxrwx 1 root root 12 Nov 5 11:52 linux -> linux-2.6.14
drwxr-xr-x 19 root root 4.0K Nov 5 20:09 linux-2.6.14


J'y perd mes basiques de makefiles :-)
--
mailing list
Avatar
Thomas de Grenier de Latour
On Mon, 27 Mar 2006 23:08:14 +0200,
Pascal Ronecker wrote:

locate videodev2.h
/usr/src/linux-2.6.14/include/linux/videodev2.h



Et c'est tout ? Tu devrais avoir un /usr/include/linux/videodev2.h.
Parceque celui dans /usr/src, c'est clair qu'il va pas être trouvé
(pas de "-I/usr/src/linux-machin" dans l'appel à gcc), et c'est normal.
On ne lie pas une application directement sur les sources du noyau.

Qu'est-ce que raconte "equery list sys-kernel/linux-headers" (ou autre
commande listant les linux-headers installés) ?

--
TGL.
--
mailing list
Avatar
Pascal Ronecker
Thomas de Grenier de Latour wrote:
On Mon, 27 Mar 2006 23:08:14 +0200,
Pascal Ronecker wrote:


locate videodev2.h
/usr/src/linux-2.6.14/include/linux/videodev2.h




Et c'est tout ? Tu devrais avoir un /usr/include/linux/videodev2.h.
Parceque celui dans /usr/src, c'est clair qu'il va pas être trouvé
(pas de "-I/usr/src/linux-machin" dans l'appel à gcc), et c'est normal.
On ne lie pas une application directement sur les sources du noyau.

Qu'est-ce que raconte "equery list sys-kernel/linux-headers" (ou autre
commande listant les linux-headers installés) ?

--
TGL.
--
mailing list





Zarma !!??!?

ben dans /usr/include/linx j'ai des fichiers qui datent de al premiere
install de mon systeme !! (sept 2003 quand même)


equery list sys-kernel/linux-headers
Searching for package 'linux-headers' in 'sys-kernel' among:
* installed packages
!!! aux_get(): ebuild path for 'sys-kernel/linux-headers-2.4.19-r1' not
specified:
!!! None
!!! Internal portage error, terminating
!!! "'sys-kernel/linux-headers-2.4.19-r1' at None"


Moi mes noyaux j'avais l'habitude de les faire à la main, donc sous
Gentoo j'ai continué ... mais alors j'ai grave merdé un truc sans jamais
que ca me pose de problèmes jusque là ? délire.


Bon alors du coup, je fais comment ?
Directement à partir des vanillia sources doit y avoir moyen non ?

--
mailing list
Avatar
Pascal Ronecker
Pascal Ronecker wrote:
Thomas de Grenier de Latour wrote:

On Mon, 27 Mar 2006 23:08:14 +0200,
Pascal Ronecker wrote:


locate videodev2.h
/usr/src/linux-2.6.14/include/linux/videodev2.h





Et c'est tout ? Tu devrais avoir un /usr/include/linux/videodev2.h.
Parceque celui dans /usr/src, c'est clair qu'il va pas être trouvé
(pas de "-I/usr/src/linux-machin" dans l'appel à gcc), et c'est normal.
On ne lie pas une application directement sur les sources du noyau.

Qu'est-ce que raconte "equery list sys-kernel/linux-headers" (ou autre
commande listant les linux-headers installés) ?

--
TGL.
--
mailing list





Zarma !!??!?

ben dans /usr/include/linx j'ai des fichiers qui datent de al premiere
install de mon systeme !! (sept 2003 quand même)


equery list sys-kernel/linux-headers
Searching for package 'linux-headers' in 'sys-kernel' among:
* installed packages
!!! aux_get(): ebuild path for 'sys-kernel/linux-headers-2.4.19-r1' not
specified:
!!! None
!!! Internal portage error, terminating
!!! "'sys-kernel/linux-headers-2.4.19-r1' at None"


Moi mes noyaux j'avais l'habitude de les faire à la main, donc sous
Gentoo j'ai continué ... mais alors j'ai grave merdé un truc sans jamais
que ca me pose de problèmes jusque là ? délire.


Bon alors du coup, je fais comment ?
Directement à partir des vanillia sources doit y avoir moyen non ?

--
mailing list





Euh ...


j'ai trouvé un truc dans la doc linux from scratch, une ciration de Linus :

----------------------------------------------------

Je suggère que les personnes qui compilent des noyaux devraient :

- ne pas créer un seul lien symbolique (sauf celui créé lors de la
construction du noyau, "linux/include/asm" qui est utilisé pour la
compilation
du noyau lui-même).

Et oui, c'est ce que je fais. Mon répertoire /usr/src/linux a toujours les
anciens entêtes du noyau 2.2.13, même si je n'ai pas lancé cette version du
noyau depuis un _loong_ moment. Mais Glibc a été compilé avec, donc ces
entêtes correspondent aux objets de la bibliothèque.

Et cela correspond à l'environnement suggéré depuis au moins les cinq
dernières
années. Je ne sais pas pourquoi l'idée du lien symbolique est toujours
vivante,
comme un mauvais zombie. Pratiquement toutes les distributions conservent
l'idée du lien et tout le monde se souvient que les sources du noyau doivent
aller sous "/usr/src/linux" même si ce n'est plus vrai depuis _trèès_
longtemps.

--------------------------------------------------------

La partie essentielle se trouve là où Linus indique que les fichiers
d'entête doivent être ceux avec lesquels gblic a été compilé. Ces
entêtes doivent être utilisés plus tard lorsque vous compilerez d'autres
packages, car ce sont eux qui représentent les fichiers de bibliothèques.

==> Je dois recompiler ma glibc après l'opération ?
et après, je recompile tout ?

Mais non d'une pipe j'ai jamais eu besoin de faire ca ?!? un monde
s'écroule.




--
mailing list
Avatar
Thomas de Grenier de Latour
On Tue, 28 Mar 2006 21:03:42 +0200,
Pascal Ronecker wrote:

ben dans /usr/include/linx j'ai des fichiers qui datent de al
premiere install de mon systeme !! (sept 2003 quand même)



Bah voilà. Avec d'aussi vieux headers, ton système (de la glibc
jusqu'aux applications) n'a aucune connaissance des fonctionnalités
récentes des noyaux Linux.

Moi mes noyaux j'avais l'habitude de les faire à la main, donc sous
Gentoo j'ai continué ...



Mais ça n'a rien à voir. Ce qui se passe dans les /usr/src/linux*, ça
ne regarde que tes noyaux (+ les éventuelles modules externes). Le reste
de ton système lui, il repose sur un ensemble distinct d'entêtes (le
fameux "sys-kernel/linux-headers"), qui est bien sûr issu des sources
d'un noyau Linux (le but du jeu étant quand même, pour la libc ou
les applis, de savoir parler au kernel), mais avec qlqs différences
quand même : la plus grosse, c'est qu'on en change pas tous les matins,
et puis sinon y'a divers petits nettoyages qui facilitent la compilation
de certains paquets, etc.

Bon alors du coup, je fais comment ?



- Tu mets à jour sys-kernel/linux-headers. La version actuelle doit
être une 2.6.11-rX. Je suis étonné d'ailleurs que tu sois passé à
travers cette mise à jour là. Tu ne fais jamais de "emerge -auD world",
ou au moins "emerge -auD system" ? Et quel est ton profile ("ls
-l /etc/make.profile") ?

- Tu réinstalles la glibc ("emerge --oneshot -av sys-libs/glibc").
Une note sur les USE flags : avec des headers 2.6, on peut utiliser le
système de threads "nptl", qui remplace avantageusement les anciennes
pthreads. Tu peux activer ce flag. Par contre, conserve quand même aussi
les pthreads, parceque pour l'instant c'est ce que tes applis
s'attendent à trouver. Donc n'active pas "nptlonly", sinon là tu
t'exposeras à des soucis (à moins de faire un "emerge -e world"
derrière, mais bon, quand on peut éviter hein..).

- Tu recompiles les quelques autres paquets qui utilisent directement
des appels au noyau, c'est à dire qui utilisent ces headers. Ne
t'inquiètes pas, elle ne sont pas très nombreuses (les autres elles se
contentent de la glibc comme interface). Ceci devrait te donner une
liste acceptable :
% find /var/db/pkg/ -name "*DEPEND"
-exec egrep -q '/(linux|os)-headers' {} ;
-printf '%hn'
| sed 's:/var/db/pkg/:=:'
| egrep -v "sys-kernel/linux-headers|sys-libs/glibc"
| uniq

Quant à recompiler le système complet, bof, nan, faut pas pousser non
plus à mon avis. Il se peut bien sûr que les changements au niveau de
la glibc exposent quelques nouveautés dont qlqs applis auraient pu tirer
parti, mais bon, ça n'a vraiment rien de vital. (Enfin, modulo le cas du
"nptlonly" déjà mentionné.)

--
TGL.
--
mailing list
Avatar
Thomas de Grenier de Latour
On Tue, 28 Mar 2006 21:21:23 +0200,
Pascal Ronecker wrote:

Mais non d'une pipe j'ai jamais eu besoin de faire ca ?!? un monde
s'écroule.



Bah, "avoir besoin", c'est très relatif hein...

Faire tourner un vieil userspace (une glibc compilée avec des headers
de 2.4, voir de 2.2, etc.) ne pose effectivement pas de problème en
général : y'a quand même une bonne compatibilité ascendante pour les
noyaux Linux (au niveaux des appels systèmes hein, je parle pas des
couches plus basses comme celles utilisées par les modules), donc
effectivement, "ça marche", et pour longtemps en général. C'est juste
pas vraiment optimal, mais on peut parfaitement s'en taper.

Maintenant, il y a aussi de temps en temps des changement au niveau de
Linux qui ne sont pas des simples améliorations de l'ancien, mais des
vraies nouveautés, comme cette histoire de videomachin sur laquelle tu
es tombé. Et là, point de salut pour ton vieil userspace: la
bibliothèque, ou je ne sais quoi, que tu veux utiliser, elle est
spécifiquement prévue pour tourner sur du 2.6, donc là il lui faut
vraiment un système adapté.

--
TGL.
--
mailing list
Avatar
Pascal Ronecker
Thomas de Grenier de Latour wrote:
On Tue, 28 Mar 2006 21:21:23 +0200,
Pascal Ronecker wrote:


Mais non d'une pipe j'ai jamais eu besoin de faire ca ?!? un monde
s'écroule.




Bah, "avoir besoin", c'est très relatif hein...

Faire tourner un vieil userspace (une glibc compilée avec des headers
de 2.4, voir de 2.2, etc.) ne pose effectivement pas de problème en
général : y'a quand même une bonne compatibilité ascendante pour les
noyaux Linux (au niveaux des appels systèmes hein, je parle pas des
couches plus basses comme celles utilisées par les modules), donc
effectivement, "ça marche", et pour longtemps en général. C'est juste
pas vraiment optimal, mais on peut parfaitement s'en taper.

Maintenant, il y a aussi de temps en temps des changement au niveau de
Linux qui ne sont pas des simples améliorations de l'ancien, mais des
vraies nouveautés, comme cette histoire de videomachin sur laquelle tu
es tombé. Et là, point de salut pour ton vieil userspace: la
bibliothèque, ou je ne sais quoi, que tu veux utiliser, elle est
spécifiquement prévue pour tourner sur du 2.6, donc là il lui faut
vraiment un système adapté.

--
TGL.
--
mailing list





Merci pour cette mine d'informations !!


en effet j'ai jamais fait d'emerge -auD system ou truc du genre.. Je
sais, c'est pas très malin.
(et je tends mes doigts, ... aïeuh )
Au début je me disais, hum, on verra, pour le moment je découvre. Pis,
pas super confiance avant d'avoir vu tourner, j'avoue aussi.
Ensuite : ben voilà quoi...., le temps passe, tout ca ...

Enfin bref, je m'emploie a présent à remettre un peu d'ordre là dedans :-)

--
mailing list
Avatar
Pascal Ronecker
>>



Merci pour cette mine d'informations !!




Bon en fait je suis les recommandations ...
et là après recompile de la glibc, j'ai des seg fault à la pelle des que
je alnce des trucs.
(genre mplayer, toujours lui, même après recompilation).

euh ..

pas envie de tester le reboot là tout de suite du coup ...


vlà les use flags que j'ai (je sais pas d'ou sort le nls, il ne sert a
rien pour glibc. Surement dans le make.conf, une erreur).

Calculating dependencies ...done!
[ebuild R ] sys-libs/glibc-2.3.5-r2 -build -erandom -glibc-compat20
-glibc-omitfp -hardened -linuxthreads-tls (-multilib) +nls +nptl
-nptlonly -pic -profile (-selinux) -userlocales 0 k

Des conseils avant de me mettre _vraiment_ dans une mouise noire ?
--
mailing list