Noyau Testing

Support Debian
#1

Bonsoir,

Je viens d’installer Debian Testing via son Netinsall et lors de l’installation de Xfce4 + Xfce4-goodies, j’ai eu une mise à jour du kernel vers la version 2.6.32-trunk… Cette même version étant utilisée sur Sid.

Or, comme le montre ce sources.list, je ne suis qu’en Testing :

[code]#

deb cdrom:[Debian GNU/Linux testing Squeeze - Official Snapshot amd64 NETINST Binary-1 20100103-21:31]/ squeeze main

#deb cdrom:[Debian GNU/Linux testing Squeeze - Official Snapshot amd64 NETINST Binary-1 20100103-21:31]/ squeeze main

##Stable
deb http://ftp2.fr.debian.org/debian/ stable main contrib non-free
#deb-src http://ftp2.fr.debian.org/debian/ stable main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free
#deb-src http://security.debian.org/ stable/updates main contrib non-free

deb http://mirror.home-dn.net/debian-multimedia stable main
#deb-src http://mirror.home-dn.net/debian-multimedia stable main

##Testing
deb http://ftp2.fr.debian.org/debian/ testing main contrib non-free
#deb-src http://ftp2.fr.debian.org/debian/ testing main contrib non-free

deb http://security.debian.org/ testing/updates main contrib non-free
#deb-src http://security.debian.org/ testing/updates main contrib non-free

deb http://mirror.home-dn.net/debian-multimedia testing main
#deb-src http://mirror.home-dn.net/debian-multimedia testing main

##Unstable
#deb http://ftp2.fr.debian.org/debian/ unstable main contrib non-free
#deb-src http://ftp2.fr.debian.org/debian/ unstable main contrib non-free

#deb http://mirror.home-dn.net/debian-multimedia unstable main
#deb-src http://mirror.home-dn.net/debian-multimedia unstable main[/code]

Mise à jour normal ou (couille) dans le potage? :mrgreen:

Merci

#2

Salut,
Je m’inquietais aussi mais il semble que ce soit " normal". Aptitude me le propose aussi.
[size=85]Sauf que j’ en veut pas de cet espèce de tunk qui me fait tout planter[/size] :smt013

#3

Je l’ai moi aussi installé, mais des firmwares ne sont plus dans ce paquet. Il faut bien installer linux-firmware si vous en avez besoin (dans mon cas la carte ethernet)

#4

Salut
tien il gère quoi ce paquet ? parce que je vien de remarquer que la temp de ma carte mère n’esst plus detecter pas sensors, malgré un sensors-detect suivi d’un reboot (la fleme d’utilise modprobe lol)

#5

[quote=“http://packages.debian.org/lenny-backports/firmware-linux”]This package contains the binary firmware for various drivers in the Linux kernel. This is a collection of firmware blobs which are not individually large enough to warrant a standalone package.

Contents:

  • 3Com Typhoon firmware, version 03.001.008
  • DAB-USB FPGA bitfile, version unknown
  • DAB-USB firmware, version unknown
  • Intel 82559 D101M microcode, version unknown
  • Intel 82559 D101S microcode, version unknown
  • Intel 82551-F and 82551-10 microcode, version unknown
  • kaweth/new_code.bin, version unknown
  • kaweth/new_code_fix.bin, version unknown
  • kaweth/trigger_code.bin, version unknown
  • kaweth/trigger_code_fix.bin, version unknown
  • Matrox G200 WARP engine microcode, version unknown
  • Matrox G400/G550 WARP engine microcode, version unknown
  • Rage 128 CCE microcode, version unknown
  • Radeon R100-family CP microcode, version unknown
  • Radeon R200-family CP microcode, version unknown
  • Radeon R300-family CP microcode, version unknown
  • Radeon R400-family CP microcode, version unknown
  • Radeon R500-family CP microcode, version unknown
  • Radeon R600 CP/PFP microcode, version unknown
  • Radeon RS600 CP microcode, version unknown
  • Radeon RS690 CP microcode, version unknown
  • Radeon RS780 CP/PFP microcode, version unknown
  • Radeon RV610 CP/PFP microcode, version unknown
  • Radeon RV620 CP/PFP microcode, version unknown
  • Radeon RV630 CP/PFP microcode, version unknown
  • Radeon RV635 CP/PFP microcode, version unknown
  • Radeon RV670 CP/PFP microcode, version unknown
  • Radeon RV710 CP/PFP microcode, version unknown
  • Radeon RV730 CP/PFP microcode, version unknown
  • Radeon RV770 CP/PFP microcode, version unknown
  • Tehuti network card firmware, version unknown
    [/quote]
#6

Euh …
Question idiote : ce ne serait pas firmware-linux plutôt ?
Je n’ai pas trouvé linux-firmware dans les dépôts :smt102

Mais avec ma sid, je n’ai pas pu avoir le module r8169 pour l’éthernet (pourtant présent en lenny …).
J’e suis donc resté avec le 2.6.31 qui marche très bien …

#7

Ha oui, firmware-linux, et j’ai même une version free et une non free.
en faisant une recherche sur “firmware”, on trouve pas mal de paquets.

#8

Chez moi ça à l’air de marcher.
J’ai quelques questions:
Pourquoi “trunk”? Il n’y a plus de binaires ocultes?
Ces drivers ATI présents dans le linux-firmware, c’est quoi? Les pilotes proprios? Alors pourquoi s’embeter avec # m-a a-i fglrx?

#9

[quote=“synaptic”]This package contains firmware which was previously included in the Linux
kernel and which is compliant with the Debian Free Software Guidelines.

Most firmware previously included in the Linux kernel is non-free and has
been moved to the firmware-linux-nonfree package.[/quote]

[quote=“silver.sax”]Pourquoi “trunk”? Il n’y a plus de binaires ocultes?
Ces drivers ATI présents dans le linux-firmware, c’est quoi? Les pilotes proprios? Alors pourquoi s’embeter avec # m-a a-i fglrx?[/quote]

A premiere vu ça l’air d’être ça, il semble qu’ils était prévus pour être inclus dans le noyau, mais pas assez libre; En ce qui me concerne pas de problèmes ethernet mais je n’ai pas réussi ( en toute une aprèm et en essayant toute les variantes possibles ) a ré-installé les drivers Ati ( ennuyeux: sans lui je ne peut pas rester devant l’écran plus de 5 minutes sans avoir les yeux explosés par les saccades de l’affichage). D’autre firmware était demandés mais je ne les ait pas trouvés ;
Alors ma solution “bof” : continuer a bouter sur le 2.6.30.2 en attendant d’y voir plus clair (au propre comme au figuré) :arrow_right: :arrow_right:
C’est quoi ces trucs: des composants du Kernels qui ne respectait pas la charte Debian ???
Si quelqu’un des infos, je suis preneur …

#10

Salut,

Bon j’ai pas pris le temps de creuser, j’ai juste essayé à l’instant vite fait mal fait, mais pour moi qui suis aussi en Testing ça m’indique notamment ça au redémarrage :

[code]r8169: rtl8168d-2.fw, rtl8168d-1.fw

Required firmware file may be missing[/code]

Ça concerne ma carte Ethernet realtek.

Sachant que j’ai bien firmware-linux et firmware-linux-nonfree, et que je suis néanmoins connecté (J’arrive à faire un apt-get update).

Comment je peux donner au système ce qu’il me demande ?

Bon comme en plus y a une histoire de pilote propriétaire Ati à devoir encore réinstallé après ça (Comprendre : Kwin part en vrille :astonished: ), j’ai pas longtemps insisté comme dit, et suis donc revenu au noyau 2.6.30

Sinon quand je prendrais le temps de m’y mettre sérieusement, j’en ferais peut être au besoin un sujet séparé :slightly_smiling:

a+

P.S. : Ah bah voila, je viens de relire le sujet une deuxième fois et tombe donc sur ça :

[quote=“ginkgo biloba”]Mais avec ma sid, je n’ai pas pu avoir le module r8169 pour l’éthernet (pourtant présent en lenny …).
J’e suis donc resté avec le 2.6.31 qui marche très bien …[/quote]

Donc nous sommes déjà 2 ginkgo biloba :slightly_smiling:

Moi comme dit plus haut ça se passe sur une Debian Squeeze/Sid et je suis donc revenu au noyau 2.6.30-2

#11

Et de 3: j’attend le noyau “pas trunk”. C’est celui de la futur stable alors ça devrait pas être trop long.
j’espere …

#12

pareil pour moi. Ce chip ethernet est très répandu …

#13

Bilan des courses pour moi:
-fglrx s’est recompilé parfaitement (comprendre: pas mieux/pire que la dernière fois). J’ai les mêmes fps à glxgears qu’avec le 30.
-ethernet marche mais rame. pourtant je croyais que mon firmware n’était pas concerné:

-wifi marche impec’… pourquoi? comment? je croyais que les pilotes etaient non-libres pour lui…

Je trouve ça sympa de séparer le non-free pour de bon. Si les constructeurs libèrent les specifications, plus de soucis. Par contre, si c’est l’inverse, la liste des pilotes à installer soi même va devenir longue.

#14

plop
C est pour que si on doit supprimer le: pas libre de debian
Que debian puisse encore tourner. pas très utile parce que.
Sa risque d’être difficile de faire tourner une debian sur du matériel 100% libre d’un utilisateur debutan…
par contre pour foutre le boxon oui c est génial…

#15

[quote=“panthere”]Sa risque d’être difficile de faire tourner une debian sur du matériel 100% libre d’un utilisateur debutan…
par contre pour foutre le boxon oui c est génial…[/quote]

Pourtant, il me semble que c’est la logique Debian. Sous Ubuntu, il y a ce truc qui te propose d’activer les pilotes proprio selon ton matériel. Ca pourrait très bien exister sous Debian par défaut mais on s’en passe plutôt bien.

Faut voir la tournure que ça prend. Si effectivement il faut se souvenir du pilote proprio à installer pour chaque composant, perso ça va me gonfler. Si les pilotes libres prennent la relève alors c’est cool.

#16

+1

Sous Ubuntu ils sont activés d’office ( exemple : ma wifi qui marche automatiquement )

J’ai peur que : On va se retrouver avec de OS libres “pour la façade” qui feront aussi ( un peu) dans le commercial ( mais c’est que ça coute de l’argent tout ça) et des libres “jusqu’au-boutiste”. Pis au milieu des distrib’ qui ne savent plus sur quel pied danser.
Donc:[quote=“panthere”]par contre pour foutre le boxon oui c est génial…Image[/quote]

#17

Arrêtez-moi si je me trompe, mais ça existe déjà le kernel Debian complètement libre, non ? Donc je pense pas que ça soit la démarche ici…

#18

Je pense que c’est très positif de séparer le libre du non libre. Par contre, tout les firmware non libre devraient étre regroupé dans des paquets au nom explicite car actuellement c’est un peu le bazar.
A moins de gérer ça à coup de dépendances …;

#19

[quote=“piratebab”]Je pense que c’est très positif de séparer le libre du non libre. Par contre, tout les firmware non libre devraient étre regroupé dans des paquets au nom explicite car actuellement c’est un peu le bazar.
A moins de gérer ça à coup de dépendances …;[/quote]

+1

mai c est le boxon quand même pour le moment. séparer le libre du proprio oui c’est le but de debian. mai effectivement regrouper les frimwares dans des dépendances ou un autre moyen commence a ce faire sentir.
Je pense que boutoumou proposant le choix est propriétaire est une bonne idée. reste a voir ce que les dev proposeront dans le futur…

#20

Je ne comprends pas où est le problème, vraiment: un paquet est divisé en deux pour des raisons claires: les firmware sont opaques et donc non libres. Debian a le bon gout de regrouper tous les blobs dans un seul paquet. La question est: Où est le problème, on installe ce paquet et tout va bien. Le seul souci que je vois est à l’installation: certains blobs sont largement utilisés et il me parait quasiment indispensable de proposer ce paquet dans le CD d’installation de la netinstall. Un non-free dans le net-install c’est ennuyeux.