Reprise du message précédent :
 
disons qu'ils auraient pu faire passer les infos sur la maj un peu en avance ...

Ils l'ont fait… Dans les mailling list de dev

Oh ça c’est petit

 
mais tellement +1 !!!!

 
 
Je ne suis pas dev, donc je suis inscrit uniquement à la ML users et annonces, j'estime tout de même que ce genre de modification ne dois pas descendre vers les utilisateur au dernier moment...
L'annonce pour la maj de la glibc est passée le 14/07 à 16h01 chez moi, le même jour que la maj du paquet (http://www.archlinux.org/packages/core/x86_64/glibc/) avant ou après, je ne sais pas.
 

Ce n'est pas très KISS tout ça ...

ou un petit script qui donnerait à l'utilisateur un rapport ( compréhensible sans être expert ) avec des consignes pour régler le problème, genre :

- attention vous avez tel paquet installé qui a des fichiers dans /lib, désinstallez ce paquet avant de mettre à jour glibc, puis réinstaller ce paquet

- attention des fichiers orphelins sont présents dans /lib/modules, faites un "mv /lib/modules /home/user/backup"

là par défaut on a un message peu compréhensible de pacman quand la mise à jour de glibc échoue, avec le risque que l'utilisateur fasse le terminator en utilisant le commutateur "--force"

bon j'hésite à me lance, est-ce que je delete tout ce qui n'est pas glibc dans mon /lib

edit : bon ca a marché en purgeant mon répertoire à l'avance (des vieux modules dont j'avais plus besoin de toutes façons)

la règle est simple:

dans /lib il ne doit y avoir que des fichiers appartenant à glibc et rien d'autre, en gros ça donne ça si on fait un ls /lib :

/lib
/lib/* ( * étant un fichier appartenant à glibc )

il ne doit pas y avoir de repertoire /lib/modules

dans le cas contraire cela suppose de désinstaller les paquets qui squattent /lib/modules ( ceux qui proviennent du dépot AUR ou les modules compilés à la main ), puis de supprimer les fichiers orphelins de lib, une fois la mise à jour de glibc effectuée on réinstalle alors les paquets qui iront automatiquement dans /usr/lib grâce au lien symbolique /lib

si on fait une connerie en supprimant une dépendance j imagine qu un pacman-syu la re installe de toutes facons

ça a l'air de défiler niveau kernel sous archlinux, une nouvelle version vient de sortir en moins d'une semaine : linux-3.4.5-1
 
peut-être un bug découvert sur l'ancienne version

 
Bah, je pense que les dev archlinux ont leur propre patchset, et le 3.4.5, c'est une nouvelle version upstream (cf. kernel.org)...

Firefox 14

à propos de Firefox, vous n'avez pas remarqué une grosse lenteur depuis la V13?
 
parfois il faut plusieurs secondes pour passer d'un onglet à l'autre
 
c'est bien la peine d'avoir un quad-core
 
du coup je vais voir si la 14 améliore cela

ça dépend peut-être des extensions et plugins utilisées sous firefox, il faudrait faire le test avec un nouveau profil ( firefox -p ) et sans utiliser d'extension/plugin

gros gros mieux avec la 14! (pour l'instant?)
 
et ce sans avoir rien changé (extensions ou autre)

Je ne pense pas non.
Si tu supprimes un fichier pacman ne le saura pas.
Ca ne sera repare qu'en faisant une mise a jour du paquet en question.

cte post de violent sur le dernier upgrade

https://planet.archlinux.org/

mais c'est le genre d'incident qui risque de freiner l'adoption d'archlinux par le reste du public,
 
le problème à la base n'est pas forcément l'utilisateur mais peut-être l'utilitaire "pacman" qui ne dispose pas de garde-fous suffisants pour empêcher la casse,
 
par exemple dans l'idéal quand un update requiert une intervention manuelle ce serait bien que pacman puisse automatiquement télécharger les consignes du wiki et l'afficher au format texte dans la console, comme ça l'utilisateur ne sera pas pris en traitre s'il a oublié de consulter le wiki ( ou si le wiki a été mis à jour trop tardivement, un problème d'anticipation, les gens qui n'ont pas eu le temps de s'informer ),
 
il suffirait qu'il y ai une option "warning_procedure" dans le PKGBUILD du paquet, option qui serait un lien vers des consignes texte que pacman téléchargerait automatiquement afin que l'utilisateur soit informé que l'installation du paquet requiert une intervention manuelle
 

 
Je crois sincèrement que les devs d'arch s'en moquent de ca (et c'est pas qu'ils ont raison mais quand meme je le pense un peu aussi, arch annonce la couleur et demande des efforts de la part de l'utilisateur.
 
Reste que cet update etait bien sale

Bah le problème, c'est qu'hier, j'ai tenté une installation en "milieu hostile" (comprenez "pas chez moi" ) de l'Arch pour me faire un petit serveur de test sous VirtuaBox. Alors j'ai à la base le CD d'installation 2011.08.19-core-686.iso, mais le hic, c'est que derrière un proxy, je n'ai pas trouvé dans la configuration que l'on pourrait mettre (si jamais c'est possible!) avec le setup d'installation pour lui en faire prendre en compte, donc obligé d'installer le "core" d'Aout 2011...
 
Bon l'installation se passe bien, pas de problème, mais les merdes commencent directement avec pacman -Syu (en mode wget avec configuration du proxy dans /etc/wgetrc), parce qu'on a en vrac:
_ un pacman a mettre à jour
_ le changement de filesystem
_ le changement systemd / udev
_ le changement houleux de glic (qui m'avait bien emmerdé sur une testing y'a 3 semaines)
 
Le hic c'est que ne sachant pas comment forcer l'installateur a utiliser pacman en mode wget + configurer le proxy, je n'ai pas d'autre choix.. Car j'ai bien regardé les nigthly build du CD d'installation, les derniers n'auront pas tous les problèmes d'upgrade, mais ils ne sont qu'en netinstall, ce qui n'est pas pratique derrière un proxy.
 
Alors peut être que certains d'entre vous auraient des tips pour une installation en net derrière un proxy, j'ai regardé rapidement mais je n'ai rien trouvé de bien intéressant, mais il serait de bon ton que chez Arch on sorte un CD d'installation "core" un peu plus a jour, parce la, certes je ne représente pas un cas courant mais ça coince sec !

j y connais rien en proxy mais j ai vu des sujets la dessus sur le forum

 
Ah ptain ouais, mais en fait j'ai vu où j'ai en partie merdé !!    
 
J'ai utilisé le mode "DHCP" pour la carte réseau et c'est en mode "Full manuel" que l'on a une configuration du proxy (ce qui est quand même un peu con, l'attribution d'une IP n'a pas grand chose à voir avec un proxy mais bon), par contre, ça risque de coincer quand même car pacman en mode standard a du mal avec le proxy qui ne répond pas assez vite ici, donc obligé de le mettre en mode wget qui est moins chiant pour ça, mais bon, je vais tester déjà ça !

 
dans le meilleur des mondes, l'option 252 d'un DHCP de permet de définir un serveur Proxy :-)

GRUB n'est plus dans core :
archlinux.fr/news/grub-legacy-nest-plus-supporte

Il est conseillé de migrer vers GRUB2 ou un autre bootloader.

Ca y va en ce moment les MAJ manuelle, la vache...

EDIT : migration vers GRUB2 réalisée, fbsplash compris. C'est assez simple, le WiKi est bien foutu.

 
il faut configurer une variable d'environnement: http_proxy ( et eventuellement ftp_proxy ) :
 
export http_proxy="http://username:password@127.0.0.1:3128"
 
après le "@" tu mets l'adresse ip du serveur proxy suivi du numéro de port

en fait tu n'étais pas obligé de faire la migration vers grub2, typiquement le bootloader c'est le truc qui a le moins besoin d'être mis à jour, surtout si tu n'as pas l'intention de faire des bricolages de ouf niveau boot, tu t'es fait chier pour rien

et grub2 c'est le composant anti-kiss par excellence, je l'ai testé sous une machine virtuelle et ça fait mal à la tête, des fichiers de configuration un peu partout avec des imbrications et un contenu pas très lisible,

syslinux semble beaucoup plus compatible avec archlinux au niveau philosophie

et encore plus simple, le bon vieux LILO
 
OK par défaut c'est moche, mais il suffit de rajouter un joli bitmap et ça roule
 
grub2 je trouve ça horrible aussi

idem j aime bcp sysli ux

vous allez etre content : nouvel iso 2012.7 dans les cartons de dev

lilo est meme plus propose dans l install de base

Oui, mais il est toujours dans les repos officiels
 
Je parlais de LILO car je me suis fait aujourd'hui une install "à la mano" depuis une iso "releng" (en gros sans l'installeur arch-setup)
 
http://releng.archlinux.org/isos/

Vu que grub2 est moche j'utilise Burg

Connaissais pas Burg, j'ai vu quelques screens sur le site officiel, c'est en effet assez joli pour certaines captures, mais heu, ça reste un Bootloader, le truc qu'on regarde 4/5 secondes au grand max ;o
 
PS: tu t'es échappé du topic Ibra ? ;>

 
Et visiblement Arch va perdre la conf en rc.conf pour être plus proche de l'upstream

 
j'ai pas compris ta phrase,
 
tu veux dire qu'il ne sera plus possible d'utiliser le fichier /etc/rc.conf ?    
 
et il y a ça qui m'inquiète :
 

 
ça va être encore moins user-friendly l'installation d'archlinux, j'ai rapidement vu sur le forum anglais que cela n'avait pas plu aux forumeurs

 
si mais ca finira par etre modifié pour suivre les procédures classiques system v

C'est donc pour ça que l'iso "releng" que j'ai téléchargé il y a 3 jours ne fournissait plus l'installeur Arch!
 
J'aime bien le rc.conf

mais qui décide de faire ce genre de réformes dans le système archlinux ?

c'est démocratique ( avis des utilisateurs, vote ) ou bien c'est un petit comité de développeurs anonymes nommés on ne sait plus trop comment  ? ( genre junte militaire )

pas sûr que ça aille dans l’intérêt des utilisateurs,

je vais faire un test d'installation de ce nouvel iso sous virtualbox pour voir les conséquences de ces changements

 
ba c'est le groupe de dev, une distrib n'a pas a etre démocratique, le kernel ne l'est pas non plus

pourtant Debian c'est démocratique

ça évite qu'un groupe de dev se la joue solo et parte en sucette