Reprise du message précédent :

 
Honnêtement je sais pas si c'est très sexy.
C'est Sway, donc du tiling avec  

• sur le premier workspace des terminaux (alacritty)
• sur le deuxième workspace un Emacs fullscreen
• sur le troisième workspace un Firefox fullscreen

après suivant les machine ça varie mais sur le PC principal perso un Calibre et un Steam (fourni par Conty)
 
Je suis pas fan de Sway mais pour le moment ça fait l'affaire. Je regrette Awesome mais j'ai été forcé de passer sous Wayland a un moment et j'ai pas trop envie de revenir « en arrière »… Qtile a l'air pas mal mais comme plein de trucs Wayland ça a pas l'air vraiment « sec » (et c'est du Python )
 
https://luoi.eu/20221212_22h31m44s_grim.png

Merci pour ton partage !
 
Ça fait plaisir de voir ce topic agrémenté de quelques captures d'écran.

Je tourne avec Mesa 22.3(.1) et libdrm 2.4.114 depuis une dizaine de jours sur 15.0, compilé avec les sources de current après avoir désactivé rusticl (ne passe pas) et des drivers dont je ne me sers pas et ajouté intel_hasvk qui manque pour GPUs Intel Gen7/Gen8.
 

 
EDIT: En me relisant, je suis étonné de ne pas avoir fait un export de BUILD_AMBER, à voir...
EDIT2: En effet, BUILD_AMBER=NO n'était pas pris en compte sans export. J'ai édité. Cela dit, il faut garder la branche amber pour certains matos "anciens".

Un petit ChangeLog Noëlien avec que du bon, du Ruby et du kernel 6.1 chelou en 32bits ?

   
Un ./build-all-kernels.sh sur 15.0 64bits plus tard, ce que je peux dire, c'est que ça boot.

Ça y est, kernel 6.1.4 hors de testing/  

 
Bon 2023

Installation full de l'ISO du 3 janvier de www.slackware.no.
Passage en français comme dans le vidéo Youtube.
OK.
 
slackpkg update
slackpkg upgrade slackpkg
slackpkg install-new
slackpkg upgrade-all ---> C'est mort.
 
/lib64/libc.so.6: version `GLIBC_2.34' not found.
 
Je me perds en conjectures...
 

 
Idem !

Aillé, problème résolvaide..    
 
Suite à une MAJ du fichier, /etc/slackpkg/mirrors pointait sur slackware64-15.0 au lieu de slackware64-current.
 
Et même problème avec "lftp -c 'open http://slackware.com/~alien/multilib/ ; mirror -c -e 15.0'" au lieu de current.
 

Nickel ! Enfin il fallait trouver...

  Tout s'explique !

Appel à testeurs samba+AD
 

Hola,

J'ai une curiosité sur mon install.

Avec les différents changements de config, le matériel varie un peu et notamment la cg. Actuellement sur du intel, j'ai eu par le passé du nvidia avec pilote proprio. Ce pilote nécessite des liens symboliques sur certaines librairies pour fonctionner, liens qu'on peut gérer avec nvidia-switch.

Donc là avec la carte intel, les liens sont désactivés. Sauf qu'ils se remettent en place de temps en temps. Je comprenais pas comment c'était possible, j'avais déjà fouillé un peu partout sans rien trouver. Sauf qu'hier, je m'aperçois que les liens sont de nouveaux actifs et je repends un peu de temps pour trouver une piste.

Et je tombe, avec les timestamps de ces liens, sur une indication que ca se ferait avec l'installation de nouveaux paquets. Je me dit impossible, donc je désinstalle le paquet en question (ca va ca demande pas à tout casser), je désactive les liens, je réinstalle le paquet, et paf je trouve une parties des liens en place.

Le script post install du driver nvidia, contient bien la création de ces liens, mais il en contient bien plus que ceux qui sont crées. Donc ca viendrait pas de là.

J'en perds la tête un peu, alors si quelqu'un a une idée, je suis preneur.

Edit:
au strace, je vois bien que la création du lien se fait au moment de l'install d'un paquet
et au strace aussi, il m'indique qu'il ne se base pas sur le script du paquet nvidia-driver

d'où il tient son info, bo**** ???

K.

 
A partir de 15.0, il n'y a plus de problème de cohabitation semble-t-il.
 
https://docs.slackware.com/howtos:h [...] cs_drivers
https://docs.slackware.com/howtos:h [...] ia_optimus
Le 1er lien (qui date un peu) ne parle pas de nvidia-switch et le 2e (plus récent) dit qu'il n'est plus nécessaire.
 
Au niveau installation, oui, les scripts de post-installation des paquets mettent en place des liens, tout est maintenant dans /var/lib/pkgtools/scripts/ (ex. /var/log/scripts).
Si ce n'est pas la question, je ne comprends pas l'info qu'il te manque.

Ce que tu cite pour libglvnd, c'est dans le cas d'une installation du driver et depuis le .run, de ce que je comprends. Faudra que je pousse la recherche plus loin pour être sûr.
 
Dans mon cas, le driver est déjà installé, pas utilisé, les liens désactivés avec nvidia-switch (ca facilite la tâche).  
 
Ce que j'essai de comprendre c'est pourquoi une partie des liens désactivés, se remet en place lors d'une installation d'un paquet qui n'a rien à voir avec le paquet nvidia driver.  
 
Je suis toujours en 14.2, mais ca change rien au schmilibilimilibick
 

Ah, un peu vu que libglvnd a été ajouté après. Tu prépares la migration du coup ?
 
Ça ne me choquerait pas plus que ça que certains liens soient génériques et soient utiles au paquet en question, surtout si ça concerne le GPU.
Possible aussi que ce soit une erreur de packaging.
C'est quoi le paquet en question ? Il vient d'où ?

J'ai peut être mal compris l'explication de libglvnd, j'en comprends que c'est au moment de l'installation du driver depuis le .run que sont génèrer les liens, et libglvnd intervient à ce moment.  
Moi le driver est installé depuis belle lurette (et n'est plus utilisé depuis belle lurette aussi) et depuis un package alors il ne devrait pas y avoir d'interaction puisque le script du paquet nvidia driver n'est pas déclenché.  
 
Le paquet que j'installe c'est zstd installé via sbopkg, donc rien à voir avec nvidia ni gpu, mais en revenant sur les fois précédentes où les liens se sont recréés, c'est bien possible que ca vienne au moment de l'installation de n'importe quel paquet.  
 
En revenant sur le strace, à un moment se fait un appel à ldconfig et c'est dans cet appel que les liens se recréé.
 
Edit:
Ca semble un peu plus couillu que ça.
J'ai fait le test avec un autre paquet. Si je l'installe via spi, les liens nvidia ne sont pas générés, si je l'installe depuis installpkg, les liens sont crées
 
Aussi, la migration est prévu oui, pour quand je ne pourrais plus faire autrement
 

Attention, attention.
 
À peine remis de la 15.0, voici une beta pointant le bout de ses doigts avec dedans du php-8.2.3, du openssl-3.0.8 et des tas de choses recompilées en conséquence…
 

 
Je ne pensais pas à ldconfig, donc c'est bien des liens légitimes, d'ailleurs ldconfig est appelé au démarrage en multi-user (runlevel 3 et 4).
 
Mystaïre résolu donc ?
 
libglvnd, je ne sais pas comment ça marche mais c'est intéressant que ça permette une cohabitation. En 14.2, autant désinstaller nvidia en cas de souci.

 
Intrigant...  

 
Dans une certaine mesure oui, puisqu'ils sont liés à un paquet/driver.  
 
 

 
Bah non pas vraiment. Les liens sont légitimes certes, ils sont malgré tout désactivables, et devraient rester désactivés tant qu'ils ne sont pas réactivés à la main (par exemple nvidia-switch --install par une personne physique).  
 
Le mystère c'est de savoir pourquoi ils sont réactivés (en partie) automatiquement.  
 
 

 
C'est une possibilité bien sur, mais c'est la facilité aussi   . Par curiosité et pour ma culture perso, j'aimerai bien comprendre le mécanisme.  
 
Je me rends compte que les liens sont installés, assez rapidement, généralement par quelques artifacts dans le navigateur, et je peux corriger rapidement, donc la gêne est pas immense. Et en plus maintenant je sais que je dois faire attention quand j'installe un paquet, voir en plus récent, quand je fait les mises à jour.

Bon je vais poser une question qui va vous paraitre un peu conne...
 
Je travaille avec un serveur linux Samba. Je n'ai besoin que de samba, rsync et les commandes basiques.  
 
Slackware serait au top pour une utilisation 100% ligne de commande ?
 

Oui sans problèmes.

Sinon pour cette curiosité qui me chagrinne, je pense tenir l'explication.  
 
Dans l'histoire il y a bien l'intervention de ldconfig. Là où je ne comprenais pas pourquoi il y avait création de liens, c'est que pour moi, il ne faisait que de référencer l'existant (et donc le liens symbolique déjà là). Après lecture et relecture de man ldconfig, ca a fait tilt (oui je suis un peu lent à la détente ) et un test rapide confirme.  
 

 
Par "the most recent", ce n'est pas le timestamp qui est utilisé mais la version du .so (ex malib.so.version).
 
Donc, si un lien d'un .so vers un .so.version existe et qu'il y'a un .so.version+1, ldconfig va recréé le lien symbolique vers .so.version+1 à son éxecution.
 
Je peux maintenant désinstaller les paquets nvidia parce que j'ai compris  
 
 
Edit:
Après lecture du fonctionnement de libglvnd, un doute persiste sur le faite que ça aurait pu aider dans ce cas là.

Bonne Saint-Patrick !

J'ai installé des nouveaux disques dans le PC la semaine dernière.
Avec des partitions système sur différents disques, j'ai fait un petit comparatif.
Le proc est un i5-4570 @ 3.6GHz.
 
test 1: restauration d'un backup d'OS Slackware, tar/zstd, ~17 Go décompressé, 648832 fichiers/dossiers
test 2: upgrade Slackware (15.0 09/04/23 -> current 09/04/23), IO write 19-20 Go (juste l'upgrade des packages sans les tâches manuelles annexes).
test 3: backup de l'OS upgradé, tar/zstd, ~17 Go
 
WD Green 2 To (2013) : 150 sec / 57 min 29 sec / 18 min 11 sec (ondemand)
 
WD Elements 12 To (2021) : 114 sec / 56 min 12 sec / 15 min 32 sec (ondemand)
 
MX500 2 To (2022 ?) : 43 sec / 53 min 43 sec / 2 min 47 sec (ondemand) - / 49 min 24 sec / - (performance)
 
Pour les backups, le changement avec le SSD est radical.
Par contre, pour l'upgrade, l'amélioration est assez limitée. Cela trahit la gestion des installations de package par scripts shells quasiment sans parallélisme.
 
Lors du 3e upgrade, en voyant la charge CPU varier constamment, je me suis dit que ce serait bien de comparer avec le meilleur CPU governor. Résultat, ça améliore un peu les perfs, mais ce n'est pas le jour et la nuit non plus.

Ça va le peuple ?
 
Du silence dans les parages vu que je vois pas grand chose à dire. Current suis son bonhomme de chemin vers la 15.1 tranquillement.
 
Pour sans doute de bonnes raisons le noyau est toujours en 6.1.x (longterm) alors que stable est en 6.3.x. Rien de fondamentalement gênant je pense ? J'ai pas ressenti le besoin de compiler un 6.3 ou 6.4-rc
 
Pareil pour gcc qui n'inclus toujours pas libgccjit mais là je compile mon propre gcc comme décrit dans un post page 110. Je devrait faire un SlackBuild bien propre qui ne packagerait que libgccjit mais flemme.
 
Récemment j'ai changé deux fois de machine mon serveur@home (tiga → titzima → tibonom) juste à coup de install + rsync. Les deux fois ça c'est passé dans une sérénité et une simplicité confondante.
 
 

En vrai on aimerait bien que nous partage un peu plus de chose.  
 
Moi j'ai essayé Slackware, mais j'ai pas réussi à tout.
 
Je suis avec Debian, j'aime bien mais j'avour que le coté sécurité de Slack m'incite a tester.

Aujourd'hui on va mettre à jour nos firmwares avec fwupd (tout en root) :
 
1. Déjà commençons par utiliser sbopkg et mettre à jour les SlackBuilds et les queues :

 
2. Ensuite on installe fwupd :

 
3. Et enfin le but de « tout ça », la mise à jour proprement dite :

 
Y voilà  

Attention petit -currentiste, ne mets surtout pas à jour le paquet kernel-firmware-20230625_ee91452-noarch-1 sinon tu risque de te faire pincer très fort !

EDIT : et si tu t'es fait eu l'ancien est là : https://slackware.uk/cumulative/sla [...] arch-1.txz

EDIT2 : oublie pas de refaire ton initrd aussi

Oui , mais ce bug a été corrigé dans un nouveau paquet:
Thu Jun 29 19:32:12 UTC 2023
a/kernel-firmware-20230625_ee91452-noarch-2.txz:  Rebuilt.
  When building the package, install from the download directory rather than
  moving the download directory to the destination directory first. Evidently
  "cp -d foo foo" and "cat foo > foo" don't exactly behave the same. ;-)
  Support a COMPRESSION= variable which may be set to xz or zstd to compress
  the kernel modules. For now, we'll stick with uncompressed modules.
isolinux/initrd.img:  Rebuilt.
  Replaced corrupted firmware.
usb-and-pxe-installers/usbboot.img:  Rebuilt.
  Replaced corrupted firmware.

Même punition pour le dernier paquet bluez,  
 
reprendre l'ancien:
 
https://slackware.uk/cumulative/sla [...] 6_64-1.txz

MAJ ce matin. Tout roule n’ayant pas de foufoune bleue...

bluez du nouveau paquet bluez-5.68 OKI

Je vois aussi le remplacement de /etc/mtab par un lien vers /proc/mounts.
 
Si on fait des 'grep' ou 'awk' sur mtab, ça peut avoir un impact.
 
La commande 'findmnt' semble être le remplacement le plus pérenne, par ex.

.

Ça avait temporairement pété conty aussi.
 
Comme dis Pa.t c'est un bon rappel que -current c'est un dev en cours

 
Ici, j'ai mis des findmnt dans tous mes scripts qui lisaient /etc/mtab ou /proc/mounts, histoire d'être prêt pour 15.1 et plus.

Et en attendant, on peut trinquer un coup   car Slackware vient de fêter ses 30 ans hier !  

Les gens se lèvent tôt  
 
Effectivement, sur le Pa.treon et dans le Changelog :

 
« Salut les gens ! C'est le moment de saluer une autre de ces jalons… 30 ans depuis que j'ai écrit le message ci-dessous annonçant la première version stable de Slackware après des mois de bêta test. Merci à tous les contributeurs dévoués, utilisateurs loyaux, et tout ceux qui on aidé à garder la lumière allumée ici. Cela a authentiquement été  une remarquable aventure que je n'aurais pas pu imaginer en débutant en 1993. Salut ! »
https://www.slackware.com/announce/1.0.php