Reprise du message précédent :
bah dans le cas de la création du paquet on ne touche qu'au patch quand on veut tester différentes valeurs,

on peut désactiver la vérification de la signature sha256 du patch dans le PKGBUILD ( mot clé "SKIP" ) pour ne pas avoir à modifier à chaque fois ce fichier quand on modifie le patch, ça permet de gagner du temps,

j'avais procédé de cette manière pour résoudre un bug lié à une carte controleur sata/ide Jmicron, pour tester des patchs proposés par un développeur linux,

grosso modo ça revient au même que la compilation manuelle, sauf que tout est automatisé via makepkg, avec l'assurance qu'on bousillera pas son système,

après c'est vrai que c'est un peu moins pratique pour les git-bisect, quand je déboguais mesa j'avais opté pour l'installation dans le /home avec le truc du "prefix=", puis une variable d'environnement LD_LIBRARY_PATH qui pointe dans mon /home au moment de tester les librairies

drap

SI on suit ton raisonnement, tu devrais aussi faire un package même en cas de bisect et utiliser makepkg -e

Bonjour !  
 
Petit souci à l'extinction sur un laptop avec une arch installée hier.
 
Lors d'un accès à un lecteur réseau, l'extinction ou le reboot prend pas mal de temps. Ca bloque sur un écran noir, et ensuite, un défilement de [OK] et compagnie que je n'ai pas le temps de lire, puis l'extinction.
 
Je suis un noob total avec systemd, connaissez vous une astuce pour que je puisse retrouver ces lignes (genre dans un log) pour voir ce qui plante?

journalctl, dmesg… Tu trouveras peut-être ton bonheur parmi les exemples de commandes proposés ici : https://blog.seboss666.info/2015/03 [...] e-systemd/

J'ai ceci dans mes logs

J'ai réduit le DefaultTimeoutStopSec=90s à 8s et décommenté la ligne dans /etc/systemd/system.conf . En espérant que ça contourne le bug  

J'ai le bug a chaque shutdown maintenant.
Faudra que je pense a reduire le timeout a l'occasion aussi

Doucement avant de parler de bug.
Le réseau se couperait pas avant le démontage des lecteurs réseau ?

C'est quand même un phénomène qui se manifest chez pleins d'archistes depuis quelques temps, donc oui,  je pense que c'est un bug (ou alors uen sacrée coïncidence).

Moi j'ai pas ce problème. Ça peut être un truc mal configuré qui avant fonctionnait par chance et maintenant il se voit aussi

oui j'ai le bug aussi, sur mon PC principal : quasiment un reboot/shutdown sur deux j'ai ce "a stop job for Session C2 for user",

et j'arrive à le reproduire dans une machine virtuelle ( qemu ), avec une fréquence d'apparition de 100% cette fois,

même chose sur un vieux PC portable de 2003, 100% d'apparition,

donc 3 configurations différentes où à chaque fois le bug est là,

j'ai creusé la chose et le bug apparait lorsqu'on lance une session graphique type plasma 5 ou lxqt, peut-être quelque chose lié à polkit comme indiqué dans le rapport de bug,

car lorsqu'on se contente de démarrer archlinux en mode "console pure" ( pas d'interface graphique ) et qu'on fait tout de suite un reboot/shutdown alors le bug n'apparait pas

attention pour ceux qui utilisent virtualbox, un changement subtil est apparu avec le paquet virtualbox-host-modules qui est maintenant remplacé par virtualbox-host-dkms :
 
https://lists.archlinux.org/piperma [...] 27801.html
 
ça ne plait pas à des utilisateurs :
 
https://bbs.archlinux.org/viewtopic.php?id=209780
 

J'avais suivi de loin la conversation sur la ml à propos de ça, normalement ils étaient censés avertir de mettre pacman à jour seul manuellement avant de faire un Syu. Apparemment ça a pas été fait

le souci que je vois à ce changement c'est que maintenant les modules kernel de virtualbox sont compilés depuis le poste de l'utilisateur, alors qu'avant ils étaient fournis sous forme binaire depuis un paquet,
 
ces modules virtualbox qui seront écrits dans "/" sans qu'ils appartiennent à aucun paquet, alors qu'idéalement chaque fichier binaire installé devrait être fait sous forme de paquets pour qu'il y ait un suivi via pacman,
 

dkms est plus ou moins une sorte de package manager, avec des hooks pour les gérer à chaque update/install/remove, mais oui ça rajoute une couche potentiellement désynchronisable.

je ne connais pas le cas précis ici mais un des intérêts de dkms c'est de ne pas avoir à mettre à jour le paquet de module quand on change de noyau, dkms recompilant automatiquement le module pour le nouveau noyau, généralement au démarrage de celui-ci.

il y a un démon dkms dans ce cas activé par défaut pour assurer cet automatisme ?

parce qu'en général sous archlinux par défaut aucun automatisme n'est installé à l'insu de l'utilisateur,

c'est l'utilisateur qui doit lui même activer le démon ou un service systemd, en lisant le wiki archlinux pour savoir comment procéder,

peut-être que la recompilation se fait manuellement en ligne de commande ( programme dkms ), ou bien lorsque le paquet virtualbox-host-dkms est mis à jour lors d'un "pacman -Syu", ça appelle alors en ligne le programme dkms avec pour ordre de recompiler les modules virtualbox ?

bon c'est bien ce que je pensais, sous archlinux il faut manuellement activer un service systemd pour dkms, sinon aucune recompilation automatique des modules virtualbox ne se fera quand le noyau linux est mis à jour :
 

 
https://wiki.archlinux.org/index.ph [...] stallation
 
si on ne veut pas du service systemd alors il faut compiler à la main en utilisant en ligne de commande l'utilitaire dkms ( "dkms autoinstall" ) :
 
https://wiki.archlinux.org/index.ph [...] port#Usage

 
J'ai rien eu besoin à faire pour que dkms se lance automatiquement lors de la dernière mise à jour du noyau  
D'ailleurs, si j'en crois la liste des fichiers fournis par dkms il y a tout ce qu'il faut pour s’exécuter automatiquement avec pacman :  

(Bon je ne suis pas chez moi pour vérifier ce que font exactement ces hooks par contre)
 
Merci pacman 5.0 et les hooks

Non, avant c'était un service au démarrage qui compilait les modules dkms, maintenant c'est un hook pacman.
Mais ça gueule sur la ML

Après trois jours d'essais, j'ai installé mon premier Arch fonctionnel. Sur une VM... Et même là toujours pas réussi à lancer i3. J'ai xfce au moins... Je deviens fou.

comme d'habitude il faut respecter à la lettre le wiki, si on saute des étapes, qu'on fait de l'approximatif ça risque de ne pas marcher :

https://wiki.archlinux.org/index.php/i3

sinon c'est peut-être un bug mais faut nous donner des détails sur ce qui ne va pas

est-ce que vous connaissez des interfaces graphiques permettant d'utiliser les outils de systemd ?

un frontend graphique serait utile pour afficher les évenements du journal ( journalctl ) de manière plus conviviale que dans une console ( personnellement dans Konsole les messages de journalctl sont tronqués car ils dépassent la limite de 80 colonnes, il n'y a pas de retour à la ligne, donc on voit pas la fin des lignes )

idem aussi pour créer des fichiers "unit" et "timer" de manière plus simple sans retenir les mots clés/options

Il me semble qu'il y a un module KCM (KDE) pour Systemd, mais c'est peut-être juste pour KDE 4 et pas Plasma 5...

c'est ce paquet :

https://www.archlinux.org/packages/ [...] stemd-kcm/

http://kde-apps.org/content/show.p [...] ent=161871

j'ai testé, ça marche avec plasma 5, il lui manque juste l'affichage du journal de systemd

il y a aussi ce paquet :

https://www.archlinux.org/packages/ [...] ystemd-ui/

le bug est résolu depuis le noyau linux 4.4.5-1, ce disque dur connecté sur une carte pci express contrôleur sata n'est plus considéré comme périphérique amovible

   
Une idée de comment contourner ça ?  
Autre qu'éditer le PKGBUILD à la main, ou de tout compiler puis d'installer qu'un seul package, évidemment

c'est pas clair du tout, que veulent-ils dire par "single package" ?
un paquet "solitaire" ?
 
j'ai pas eu de problème pour créer des paquets avec la version 5.0.1

C'est pour les split packages.
Ca sert servait à compiler que certains packages du PKGBUILD.

C'est ici aussi pour Manjaro ou il y a un topic spécial pour lui ?

Pour ceux qui se demandait le pourquoi du comment virtualbox-host-dkms, j'ai remarqué la disponibilité du noyau linux-zen dans [extra] et du noyau linux-grsec dans [community] enfin ce n'est pas nouveau nouveau à première vue (surtout linux-grsec).

Lisez les ML les gars ! C'est assez croustillant d'ailleurs
On voit qu'Arch c'est quand même plus que géré à l'arrache. Moi tant que je sais me dépatouiller je m'en fous

Links?

https://lists.archlinux.org/piperma [...] 27801.html

attention, le mainteneur du paquet virtualbox-host-dkms  a cru bon de forcer le chargement des modules virtualbox au boot, ce qui crée un bug et le mécontentement des utilisateurs :

https://bugs.archlinux.org/task/485 [...] &sort=desc

ça ne respecte pas la philosophie d'archlinux qui est de ne pas forcer l'activation d'un service/démon à l'insu de l'utilisateur, c'est à l'utilisateur de choisir si oui ou non il veut qu'un service se lance automatiquement au boot ( ici le chargement des modules noyaux de virtualbox, comme j'utilise très peu virtualbox je ne veux pas que les modules virtualbox soient chargés tout le temps au boot, je ne charge ces modules que manuellement lorsque j'ai besoin de lancer virtualbox )

concernant le bug ( échec du service systemd-modules-load ) ça viendrait d'un problème de saut de ligne dans le fichier /usr/lib/systemd/systemd-modules-load/virtualbox-host-dkms.conf, le mainteneur a peut-être utilisé un éditeur de texte qui a foutu la merde au niveau des sauts de ligne ( problème d'encodage des caractères ? )  :

https://bbs.archlinux.org/viewtopic [...] 3#p1612033

la solution pour supprimer le chargement automatique des modules : supprimer le fichier  /usr/lib/systemd/systemd-modules-load/virtualbox-host-dkms.conf

A ma connaissance ça n'a jamais été formalisé ça, c'est plus une espèce d'habitude consensuelle, mais en pratique y a forcément des exceptions, surtout sur des modules/plugins.

dans le cas de virtualbox c'est pas vraiment justifié de charger par défaut tout le temps les ( nombreux ) modules virtualbox au boot du PC, le mainteneur les a en plus tous activés alors que certains modules sont optionnels,

un utilisateur lambda ( PC à la maison, utilisation domestique/loisir ) ne va pas forcément utiliser tous les jours virtualbox, moi je lance virtualbox que si j'ai besoin de faire tourner quelque chose sous windows ( programme qui ne tourne pas ou mal sous wine par exemple ), du coup c'est rare que je le lance, de plus je privilégie qemu qui utilise kvm,

il me semble que les modules noyaux virtualbox n'ont pas une excellente réputation, ils ont été pendant longtemps suspectés de provoquer des instabilités systèmes ( kernel panic ), donc c'est chaud d'avoir ça chargé en permanence en mémoire dès le boot, j'ai pris pour habitude de charger manuellement quelque chose, puis ensuite idéalement de le stopper quand j'en ai plus besoin ( comme le service pour apache/mariadb ), le tout via un script

Je ne dis pas le contraire

Heeeeu, y a un GROS problème sur un paquet en Testing là, non ? Je suis passé en Testing ce matin pour bénéficier du nouveau kernel 4.5, et ma session est devenue inutilisable, ça ramait comme pas permis, avec parfois 1 minute (oui...) entre un clic et son action, l'horreur... En repassant en Stable, plus de problème. Du coup, le paquet incriminé est un de ceux-là :

Je suspecte un paquet lié à X, car en passant la session problématique sur un TTY, je n'ai pas de problème... Personne n'a rien constaté de similaire ?

Jte dirai sûrement ce soir. Mais pour juste le kernel t'aurais du cherrypick et installer avec -U plutôt que tout passer en testing.

En fait ça fait plusieurs semaines que je compile le linux-mainline 4.5RCxx depuis AUR, mais je voulais tester la version finale. Après c'est pas méga recommandé, de prendre un paquet tout seul du dépôt Testing, je pense ?