Reprise du message précédent :
C'est fait pour.

En faisant un "pacman -Syu" aujourd'hui je constate que pacman a installé un nouveau paquet et a activé un service systemd :

Vous avez eu la même chose ?

Je ne connaissais pas ce paquet pipewire-media-session, j'espère que l'activation automatique de ce service systemd ne va pas créer de problèmes.

Non (ça remonte à plus d’une semaine, la dernière MAJ de PipeWire…), mais je crois savoir pourquoi : d’après sa fiche, « pipewire-media-session » est un paquet optionnel pour PipeWire, mais il est requis par Kwin ; ce qui fait que ce qui t’est arrivé vient du fait que tu utilises Plasma (qui a donc besoin de ce paquet « pipewire-media-session », apparemment).

Ça faisait 2 semaines que je n'avais pas fait de "pacman -Syu".

J'utilise en effet plasma, j'ai redémarré le PC après la mise à jour, pas de problèmes, tout semble Ok.

Pour avoir 385 MAJ à te farcir en une fois, je veux bien te croire !
 

Non, mais depuis le temps que tu le dis à chaque fois, on le sait et on risque pas de l’oublier, que tu es sur Plasma ! La preuve avec mon message…

Il est probable que ce nouveau service tient lieu de mise à jour pour un autre supprimé dans la foulée et qui devait être activé.
Car normalement Arch n'active pas automatiquement les services systemd à ma conaissance (et c'est très bien comme ça   ).

Suite à l'installation du noyau linux 5.15.2 j'ai maintenant cette erreur au boot, erreur qui est non bloquante, c'est une ligne qui apparait furtivement et qu'on peut voir au tout début de dmesg:

avez-vous la même chose ?

edit : apparement le problème est connu et sera corrigé par une future version du noyau linux :
https://forums.opensuse.org/showthr [...] 5-15-2-1-1

Oui, cf le topic du noyau Linux : là.
Je compile le .4 qui a le correctif.
 
edit : l'erreur reste présente.

Je viens de compiler et passer sur le 5.15.4, et toujours le souci (que j'avais en 5.15.3) :

Exact, je viens de le voir aussi.

Bon, après, l'erreur est anodine.
À suivre donc!

Un article de Nextinpact sur Arch : https://www.nextinpact.com/article/ [...] t-possible

En accès payant pour le moment (si vous avez 5 € pour un mois d’accès complet, sachez que ça les vaut). Il passera donc en gratuit à Noël ou le lendemain.

Avez-vous remarqué des problèmes de crash vidéo en utilisant l'accélération vidéo vdpau dans VLC ?
 
J'ai une vieille carte tuner DVB-T, une carte graphique radeon HD4650, au bout de quelques heures il arrive que lors d'un zapping l'affichage devienne completement noir, le clavier bloqué, plus aucun son, obligé de faire un reset, l'utilisation des touches magiques n'a pas réussi à faire redémarrer le PC :
 
https://wiki.archlinux.fr/Sysrq
 
J'ai l'impression que c'est un pilote qui a planté, en rapport avec la carte graphique ou la carte tuner.

Aucun problème avec VLC, mais j’utilise la sortie vidéo OpenGL, pas VDPAU. Est-ce que ça ne résoudrait pas ton problème, déjà ?
 
Après, les touches magiques sont désactivées par défaut sur Arch Linux, non ? C’est peut-être pour ça qu’elles n’ont pas fonctionné.

J'ai vérifié chez moi, les touches magiques semblent activées :

là j'ai changé la sortie vidéo dans VLC, en mettant sur "automatique" (avant elle était sur "vdpau" ), j'essaierai aussi openGL,

comme le plantage est aléatoire c'est pas évident de le reproduire, parfois pas de bugs pendant plusieurs jours, puis hop ça arrive sans prévenir en tentant de changer de chaine.

Possible que le problème vienne de la carte tuner qui serait défectueuse, un problème de puce, ou la carte graphique si elle est mal ventilée, durant l'utilisation de VLC la température du GPU monte vers 66~68 degrés, puis au repos ça retombe à 55 degrés.

Hi
 
Synology a sorti un paquet linux pour Active Backup For Business son logiciel de sauvegarde de PC mais malheureusement il n'y a des paquets que en DEB (ubuntu, debian) et RPM (Fedora)...
 
Rien sur les dépots AUR.

C’est récent ?

Synology n’étant pas une obscure marque noname que personne ne connaît, il est probable que quelqu’un produise bientôt un PKGBUILD qui consistera en gros à récupérer et décompresser la version DEB ou RPM (si la source n’est pas disponible), et tu l’auras sur Arch, Manjaro, Endeavour, etc. C’est comme ça que ça marche pour la plupart des paquets présents sur AUR, alors que l’éditeur ne fait que des versions DEB et RPM (voir, par exemple, le PKGBUILD de Vivaldi, qui est exactement dans ce cas ; et c’est sans doute le cas aussi pour Teams, Skype, et autres quand ils ne fournissent pas plutôt un AppImages à la place).

Tu peux les installer avec debtap : https://github.com/helixarch/debtap

IL y a aussi le logiciel Hyper Backup Explorer - j'ai trouvé sur les dépots AUR mais ce n'est pas la dernière version
On dirait qu'il n'y a plus de "maintainer"
https://aur.archlinux.org/packages/ [...] p-explorer

La version 3 est sortie mais pas de paquet AUR
https://www.synology.com/fr-fr/rele [...] upExplorer

Comment on peut faire pour devenir contributeur c'est compliqué ?

je regarderai ca merci

Pour devenir contributeur sur un paquet AUR qui existe déjà il suffit d'en faire la demande et d’être accepté par le proprio. Si le proprio refuse mais que tu as une bonne raison, tu peux faire appel a un modo pour faire pression.
Si le paquet est abandonné il te suffit de l'adopter.
Pour soumettre un 1er PKGBUILD c'est super facile et sans regles particulière (j'ai maintenu pas mal de paquets depuis que je suis passé sur Arch).

GRUB 2.06 vient d’arriver sur le canal stable d’Arch : pensez à porter les modifications éventuellement faites à /etc/default/grub sur le fichier grub.pacnew ajouté, surtout en décommentant au besoin la dernière ligne (si vous êtes en dual boot), pour réactiver OS Prober( désactivé par défaut « pour des raisons de sécurité ») :

Et faire ensuite un « (sudo) grub-mkconfig -o /boot/grub/grub.cfg » pour prendre en compte cette nouvelle configuration.

Merci pour le warning, mais en faisant un diff sur mon fichier grub et le pacnew, aucune différence mis à part que j'ai justement dé-commenté l'os prober ...

Dans la plupart des cas, il n’y aurait que ça à faire, mais il me fallait :

• pour le portable : forcer le réglage de la clocksource sur hpet (sinon, ça démarre plus depuis je sais plus quelle version du noyau sortie en 2018 ; peut-être la 4.8 ?).
• pour le fixe : décommenter cette ligne.
• pour les deux : forcer la mémorisation de la dernière option sélectionnée au démarrage (quand on installe par exemple le noyau LTS après le noyau normal, c’est le LTS qui est le choix par défaut et je dois aller dans les options avancées pour choisir le noyau normal ; en mettant « GRUB_DEFAULT=saved » et en décommentant « GRUB_SAVEDEFAULT=true », j’ai plus qu’à appuyer deux fois sur Entrée, si « Options avancées pour Arch Linux » était le choix au démarrage précédent).

Il m’a fait un truc bizarre, Pacman, ce matin…

Bon, rien de bloquant et le redémarrage s’est produit sans encombres, mais je vois pas d’où ça vient (et il y a rien à ce sujet sur le site, le bugtracker ou le forum d’Arch).

Inutile de dire que je n’ai évidemment jamais touché les permissions… Je sais qu’il y a une MAJ corrective de systemd (qui restaure un fichier legacy.conf, apparemment abandonné depuis la version 250 qui vient de sortir, laquelle version a justement été proposée ce matin), mais je pense pas que ce soit lié, puisque je n’ai redémarré qu’après.

(J’ai balisé : au début, j’avais cru que c’était la régénération des initramfs qui avait foiré, surtout depuis la MAJ de GRUB d’hier ; mais non, elle a eu lieu juste après, sans problème)

T'as un FS qui supporte pas les attributs étendus ? Ou un kernel qui les a pas ?

Ce serait nouveau : à part /boot en ext2 et la partition swap, les deux partitions / et /home sont en ext4.
 
Enfin, vu que je ne constate aucun problème au redémarrage, ni même après, je vais autant ignorer la chose que Pacman lui-même l’a fait. Parce que la seule chose qui m’importe est que les machines restent aussi utilisables qu’elles l’ont toujours été, et c’est toujours le cas.

Tout semble indiquer un bug d'une version récente du paquet systemd, chez manjaro ils en parlaient il y a 4 jours :
https://forum.manjaro.org/t/systemd [...] mote/96057

OK, c’est un bug de la version 250-1 du paquet. Et comme ce matin, la 250-3 était déjà en ligne en amont, j’ai juste été victime d’un miroir pas à jour.
 
Ça m’étonne quand même que j’en aie trouvé nulle trace sur le forum d’Arch lui-même (j’ai fait toutes les sections), ni le bugtracker pour systemd (j’ai même cherché dans les bugs fermés et classés par date décroissante de modification). Et la dernière actu ne concernait que des modules Python qui n’avaient rien à voir (et que j’avais pas à écraser, puisque pas concerné par cet autre problème).
 
Sont bien gentils de pousser à se renseigner par soi-même, chez Arch. Mais y a quand même des fois où eux-mêmes n’y mettent vraiment pas du leur ! Je veux dire : un truc pareil a forcément dû être repéré (d’où la version 250-2 qui corrige ça), donc ils auraient pu se fendre d’un petit mot disant que c’était pas grave pour ceux qui allaient éventuellement tomber dessus, au moins ça.

Faut utiliser reflector pour les miroirs

Voilà comme ça il aurait eu le paquets qui merde plus tôt

vous avez pas eu un souci avec Xorg server 21.1.3-1 ? Tout mon laptop était lent, rien dans les logs. En downgradant à la précédente aucun soucis  

Tu as redémarré après la mise à jour ?
Parfois il est préférable de redémarrer en cas de mise à jour d'un composant critique type bureau kde plasma/gnome, xorg, noyau linux.

Un bureau lent : peut-être un pilote vidéo propriétaire qui a un bogue, l'accélération graphique désactivée, en consultant les fichiers log (dmesg, journalctl, le log de Xorg) on peut en savoir plus (d'ailleurs je cherche une interface graphique permettant de consulter plus facilement les erreurs).

Je n'ai pas encore fait la mise à jour.

RAS chez moi.

Idem

Oui bien redémarré, plusieurs fois même, en downgradant uniquement ce paquet plus aucune lenteur, étrange. Je n'ai pas trouvé de bug ouvert mais je n'ai pas cherché en détail.
On verra à la prochaine MaJ ce que ça donne !

J'ai remarqué un problème depuis une mise à jour de qemu :

- je n'arrive plus à avoir du son dans mes machines virtuelles windows (host linux),

l'option "-device AC97" empêche la machine virtuelle de se lancer, si je la retire alors la machine se lance mais je n'ai plus de son.

Avez-vous remarqué la même chose ?

Quelle option en ligne de commande pour qemu vous utilisez pour avoir du son ?
La documentation n'est pas claire, voire obsolète.

J'ai 2 cartes son dans l'host : le classique intel HDA (realtek ALC888) et une vieille carte son PCI yamaha YMF-744B.

Il y a quelques semaines ça marchait encore très bien qemu pour le son, mais plus maintenant depuis une mise à jour.

edit : j'ai trouvé une solution en utilisant ces options pour une machine virtuelle windows 7 :

Comme l’année dernière, le gag s’est reproduit : en ce 12 janvier 2022, le noyau LTS proposé sur Arch est dans une version plus avancée (5.15.14) que celle du noyau normal (toujours en 5.15.13) !

Le mainteneur du noyau normal doit être en congé et pas l'autre.

C'est pas trop un problème en soi.
Par contre la politique d'avoir un linux-lts sur la même branche que le package linux (les deux en 5.15.XX quoi) ça c'est un peu stupide, ça rend le lts un peu inutile je trouve.

C’est ce qui est arrivé en février dernier, donc sûrement aussi cette fois-ci.
 

C’est ce que tu avais dit l’année dernière, en gros. Parce que c’est vrai que, plus d’une fois, le noyau LTS m’a servi de roue de secours quand le normal me posait des problèmes (heureusement résolus ensuite). Mais si jamais j’avais des soucis toujours en cours avec le 5.15 et que je restais sur le 5.10 en attendant que ce soit résolu, ben, je serais marron si je faisais pas gaffe (d’ailleurs, ça s’est joué de peu que je ne le voie pas avant de confirmer le lancement du téléchargement, cette fois)…
 
C’est d’ailleurs pour ça qu’il faut se retenir de nettoyer trop vite le cache des paquets téléchargés (j’en connais qui font ça dès que l’opération de mise à jour est finie). Perso, je ne purge ce cache qu’une fois la partition / déclarée trop remplie.