SliTaz Forum
You are not logged in.
Hi,
I finish to rebuild all packages on current chroot, now wait that mirror update before build isos.
First update it manually to have new slitaz-toolchain (gcc 8.3.0, glibc 2.28).
After it's do, rebuild all packages, and finally new packages i put in my space (mc, xine-ui, gummi, ...)
This packages broken, need check it, because modules change between 3.x and 4.x.
For linux-firmware, we have [c]firmware[/c] but think not same
linux-firmware
linux-input-tablet
linux-irda
linux-mmc
linux64-irda
linux64-mmc
Offline
Hi,
Switch my minipc (use a server at brother) to current mirror and update it
52 packages updated (all due of rebuild + new kernel)
installed also linux-pae-ipv6 for ip6tables (to drop ipv6 by default)
sysadmin@amberle:~$ uname -a
Linux amberle 4.19.305-slitaz-pae #6 SMP Wed Jan 17 17:49:30 Europe 2024 i686 GNU/Linux
sysadmin@amberle:~$ free -m
total used free shared buff/cache available
Mem: 14075 48 13993 0 32 13540
Swap: 0 0 0
sysadmin@amberle:~$ cat /proc/cpuinfo |grep "model name"
model name : AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx
model name : AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx
model name : AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx
model name : AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx
sysadmin@amberle:~$
Also think clean or at least reduce stuff/iso in my space (14Go used just by me).
Check for build current iso and put them on mirror
Offline
Bonjour Shann,
Bravo !
Chargé la dernière current core64 bits :
[c]tux@slitaz:~$ cat /etc/slitaz-version
SliTaz GNU/Linux - current 20240119[/c]
Premier tour d'horizon plus que prometteur :
les qq jeux testés s'ouvrent,
mhwaveedit sait lire le mp3, j'arrive à lire et entendre du multimédia en mp4 (un fichier qui ne veut pas se lancer sur 5 ou 6 testés),
webradios ok
alsaplayer lit du wav du mp3 (pas essayé d'autres formats pour l'instant),
nano et vi s'affichent fièrement,
le gestionnaire de paquets fonctionne aussi très bien.
Bref, ça donne envie.
Beau boulot.
Salutations admiratives.
Offline
I shann,
I wouldn't be a killjoy but having a look at the Current cooker, i can see [c]Cook failed[/c] for the gcc package with message [c]checking for inttypes.h... objcopy: /tmp/ls18731: cannot fill debug link section'x': No such file or directory[/c]; no troubles using the package?
Thanks.
Offline
Hi Ceel,
Infact i see it, but no issue to use it, and search talk about add-gnu-debuglink.
I check and see on gcc83 this :
[c]
sed -i 's|\(add-gnu-debuglink.*\);|\1 2> /dev/null;|' \
$src/libbacktrace/configure*
[/c]
Go to rebuild gcc with this to check if debug link section issue go out.
No directly related to current, but think we need to found how to request build package without hack receipt.
I see build of ethtool on current cook and only diff i see is "space add" for trigger cooker 
Offline
build gcc on my local cook it's ok no issue about debug link.
If understand remove debuglink feature.
This feature seem for create debug file on side final binary if understanding
Diff i see between build :
without sed
[c]
checking whether objcopy supports debuglink... yes
checking for inttypes.h... objcopy: /tmp/ls18731: cannot fill debug link section
x': No such file or directory
no
checking whether tests can run... yes
[/c]
with sed remove add-gnu-debuglink
[c]
checking whether objcopy supports debuglink... no
checking whether tests can run... yes
[/c]
Offline
Hi,
After read cooker.cgi, i found we can call cooker to recook pkg, seem not publicly in doc.
Test on my local cooker env, work well, also on current chroot.
Minus fix crontab line set by [c]cooker setup-cron[/c].
Offline
Hi shann,
linux-pae-aufs receipt:
[c]PROVIDE="aufs:linux-pae"[/c]
Shouldn't it be
[c]PROVIDE="linux-aufs:linux-pae"[/c] ?
Have a good day.
Offline
Offline
Hi shann,
Trying to build Eolie. I'm going to need webkit2gtk; I had a look at its receipt and found
[c]DEPENDS="gtk+ enchant libxslt expat gtk+ jpeg ...[/c]
Should be [c]gtk+3[/c] isn't it?
(btw, [c]gtk+[/c] is also twice in the [c]webkitgtk[/c] receipt as in the [c]libwebkit[/c] receipt in Current and Rolling)
Offline
Hi ceel,
Oh infact good catch, because in few time i set sakura gtk3 version, gtk+3 already installed.
In case miss review 
I update receipt for libwebkit and webkit2gtk on current.
Offline
Bonsoir shann,
Tout d'abord, un grand MERCI ! J'ai vu que tu avais construit webkit2gtk et ses dépendances, ça va m'avancer dans ma dernière étape pour Eolie.
Mais actuellement, je rencontre un petit problème en construisant un autre paquet et j'aurais besoin de tes lumières :
[c]find: unrecognized: -false[/c]
[c]Command line: find -L[/c]/path/to/file[c]-type f ( -name text-x-script.png -o -name text-x-script.jpg -o -name text-x-script.jpeg -o -name text-x-script.tif -o -name text-x-script.tiff -o -name text-x-script.xpm -o -name text-x-script.bmp -o -name text-x-script.gif -o -name text-x-script.pnm -o -name text-x-script.tga -o -false[/c]
[c]BusyBox v1.31.1 (2024-01-14 17:59:30 Europe) multi-call binary.
[...][/c]
Je suppose que je devrais utiliser bash mais même en l'ajoutant dans les [c]BUILD_DEPENDS[/c] j'ai toujours la même erreur pour 3 fichiers (apparemment sans trop d'importance, puisque le paquet fonctionne).
J'ai désinstallé/réinstallé bash du chroot et, curieusement, lors de l'installation, [c]tazpkg[/c] ne demande pas [c]Do you want to set Bash to default (y/N) ? :[/c]
Comment faire pour indiquer à cook d'utiliser bash ?
Ce qui me rapelle un problème précédent dans le chroot : [c]tazpkg up[/c], dans le chroot, quitte immédiatement sans timeout :
`You have 2 available upgrades (0 blocked)
167 installed packages scanned in 3s
Do you whish to install them now? (y/N) Leaving without any upgrades installed.`
J'ai fait la manip suivante sur plusieurs ISOs (20231030, 20231107, 20231202, 20231217, 20231223) :
[*]boot en mode frugal d'une ISO Current
[*]installation de [c]tazdev[/c]et création d'un chroot : [c]tazdev -gc current[/c]
[*]entrée dans le chroot : [c]tazdev -c current[/c]
[*]changement du mirroir du chroot : [c]tazpkg -sm http://people.slitaz.org/~shann/slitaz-current-stuff/packages-incoming/[/c]
[*]et lancé [c]tazpkg up[/c]
et...
[c]You have 12 available upgrades (0 blocked)
12 installed packages scanned in 4s
Do you whish to install them now? (y/N) Leaving without any upgrades installed.[/c]
avec chacune d'elles .
J'avais déjà remarqué que [c]tazpkg[/c] ne se comporte pas de la même façon dans un chroot et dans le host avec l'option [c]remove[/c]:
[*]host :
[c]tazpkg -r <pkg_name>
Remove package "package" (2.70.3)? (y/N)</li>
[...][/c]
[*]chroot :
[c]tazpkg -r <pkg_name>
Removing <pkg_name>
[...][/c]
Dans Rolling comme dans Current.
Dans chacun de ces cas [c]tazpkg[/c] ne demande pas de confirmation ; coïncidence ? Tu ne rencontres pas ces problèmes ?
Offline
Bonsoir Ceel,
hmm je viens de check en effet si je prend les isos et que je créer un chroot failed
Dans mon cas le chroot se mettant à jour au fur et à mesure, je n'ai pas rencontré ce problème, de plus bash est installé donc pas vu de message qui aurait pû m'alerter
Il semble que tu avais déjà remonté ce point pour le chroot, et c'était lié à /dev/shm /dev/pts qui était manquant.
En l'état je viens de voir qu'on a bien /dev/pts /dev/shm.
Il semble qu'en utilisant /dev/pts /dev/shm du host avec --bind, le soucis ne soit pas présent.
A creuser ce qui change car je ne me l'explique pas
tazdev -c current
=> Failed
umount /home/slitaz/current/chroot/dev/pts
umount /home/slitaz/current/chroot/dev/shm
mount --bind /dev/pts /home/slitaz/current/chroot/dev/pts
mount --bind /dev/shm /home/slitaz/current/chroot/dev/shm
tazdev -c current
tazpkg up -r (ok pour le prompt)
Offline
Bonjour shann,
Merci pour ta réponse ; pas encore eu le temps de tester ta solution. Oui, j'avais signalé ce problème il y a quelques temps mais j'avais trouvé un moyen de le contourner : pour les update "massif", après [c]tazpkg up[/c] je lançais [c]tazpkg get-install-list /var/lib/tazpkg/packages.up[/c].
Deux problèmes avec Current sur mon PC le plus ancien (Pentium 4, 1.5 GHz, 256MB RAM)
[*]Avec le kernel PAE, le ventilateur du CPU tourne en permanence à Vmax. Avec la version non PAE, la vitesse du ventilateur est régulée en fonction de la température du processeur.
À l'exception des paramètres pour le PAE, y a-t-il d'autres différences dans la configuration utilisée pour compiler les 2 kernels ?
[*]Avec le build d'openbox actuellement sur le miroir, le déplacement des fenêtres est extrêmement lent (pixel après pixel ) ; ré-empaqueté d'une ISO 20231030, openbox tourne à merveille.
À part 4 patches ajoutés et celui des "rounded corners" que tu as supprimé (merci, j'ai horreur des fenêtres qui ne sont pas carrées 
), la différence notable que j'ai remarquée est l'ajout de [c]python-xdg[/c] aux [c]BUILD_DEPENDS[/c] ; ça pourrait avoir une relation ?
J'essaierai de recompiler le paquet sans elle pour voir si ça change quelque chose. Sur le Lenovo, je ne constate pas le phénomène mais difficile de faire une comparaison entre les deux machines
Dernière question : [c]python3[/c] est-il vraiment indispensable dans les [c]DEPENDS[/c] de [c]glib[/c] ? Je l'ai supprimé et bloqué dans le rootfs que j'utilise sur le vieux PC (sinon il se figeait avec le message [c]Out of memory[/c] au boot) et jusqu'à présent, je n'ai rencontré aucun problème.
Offline
Bonjour Ceel,
Pour le kernel non normalement pas de diff hormis le PAE, je vais faire attention et refaire des tests sur mon x300 (pentium M 1.5Ghz, 1Go ram, éventuellement réduire 512Mo).
Le diff entre le kernel normal et PAE
root@tank:/home/slitaz/wok# diff linux/stuff/linux-slitaz.config linux/stuff/linux-slitaz-pae.config | grep '\+'
+++ linux/stuff/linux-slitaz-pae.config
@@ -19,7 +19,7 @@
+CONFIG_LOCALVERSION="-slitaz-pae"
@@ -234,7 +234,7 @@
+CONFIG_PGTABLE_LEVELS=3
@@ -263,6 +263,7 @@
+# CONFIG_XEN is not set
@@ -346,15 +347,17 @@
+# CONFIG_HIGHMEM4G is not set
+CONFIG_HIGHMEM64G=y
+CONFIG_X86_PAE=y
+# CONFIG_X86_PMEM_LEGACY is not set
@@ -387,7 +390,7 @@
+CONFIG_PHYSICAL_ALIGN=0x200000
@@ -395,6 +398,7 @@
+CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
@@ -583,7 +587,6 @@
@@ -726,6 +729,7 @@
+CONFIG_HAVE_ARCH_HUGE_VMAP=y
@@ -862,6 +866,7 @@
+CONFIG_PHYS_ADDR_T_64BIT=y
@@ -5353,7 +5358,6 @@
@@ -6261,6 +6265,7 @@
+# CONFIG_LIBNVDIMM is not set
@@ -6573,6 +6578,7 @@
+CONFIG_PAGE_TABLE_ISOLATION=y
@@ -6745,8 +6751,6 @@
@@ -6842,8 +6846,10 @@
+CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+CONFIG_SWIOTLB=y
Pour Openbox, je vais refaire des tests x300 / eeepc.
En effet sur l'Eeepc, le déplacement semble ok, (driver intel)
Pour glib, il semble que python3 soit requis pour gdbus-codegen, glib-genmarshal, glib-mkenums, gtester-report.
root@tank:/home/slitaz/wok# grep -nrl python glib/install/usr/*
glib/install/usr/bin/gdbus-codegen
glib/install/usr/bin/glib-mkenums
glib/install/usr/bin/glib-genmarshal
glib/install/usr/bin/gtester-report
glib/install/usr/lib/libgio-2.0.so
glib/install/usr/lib/libgio-2.0.so.0
glib/install/usr/lib/libgio-2.0.a
glib/install/usr/lib/libgio-2.0.so.0.7000.3
ce que je vois Arch par exemple défini python comme optional.
A tester mais je pense qu'on peut le mettre en SUGGESTS.
Offline
Bonjour shann,
[*]Confirmé. En remplaçant [c]linux-pae[/c] par [c]linux[/c] sur les rootfs que j'utilise sur le vieux PC, la vitesse du ventilateur est régulée correctement. Ça ne fait pas entièrement mon affaire car ça m'oblige à gérer 2 versions de modules. Mais bon, c'est tout de même un grand soulagement pour les oreilles...
[*]Hmm, non, avec ou sans python-xdg dans les [c]BUILD_DEPENDS[/c] même punition (je ne vois aucune différence dans les log) ; j'ai recompilé également en supprimant tous les patches que tu as ajouté
Finalement j'ai pensé que si le problème ne venait pas d'un ajout, il venait peut-être d'une suppression ?
Bingo ! En rétablissant le patch des rounded-corners, openbox revient à un fonctionnement normal. Bien que je n'aime pas les fenêtres aux angles arrondis, je vais m'en satisfaire, autrement, la performance en mode graphique est vraiment trop dégradée
Offline
Bonjour Ceel,
En fait je peut pas tester sur mon dell x300, supporte pas le PAE .
A regarder su mon Eeepc qui supporte le PAE.
Hmm bizarre pour openbox en effet, je vais creuser car je vois dans le patch qu'il a des modifs lié au framerender certe lié aux coins arrondies mais peut-être des modifs à reprendre.
Suite aux commits de HGT, je vais creuser pourquoi fsarchiver ne se construit pas.
Assez frusté de voir qu'on utilise pas les hooks à dispo pour rebuild les paquets et qu'en lieu et place on fait des modifs dans les receipts
En l'état je suis arrivé à ceci :
[c]package/version binutils glibc gcc e2fsprogs util-linux fsarchiver
cooking/rolling 2.37 2.14.1 4.6.3 1.45.5 2.38 OK
current 29/10 2.37 2.23 6.3.0 1.45.5 2.38 KO
current 2.37 2.28 8.3.0 1.45.5 2.38 KO
current (binutils223/gcc49) 2.23 2.28 4.9.2 1.45.5 2.38 KO
stable 4.x 2.23 2.22 4.9.2 1.44.2 2.19.1 OK
stable 4.x 2.23 2.22 4.9.2 1.45.5 2.19.1 KO[/c]
La stable 4.x correspond à la version 4.0 mis à jour avec la nouvelle toolchain.
En l'état j'ai du mal à comprendre ce qui serait cassé sur current
L'erreur en question
CCLD fsarchiver
/usr/bin/ld: cannot find -lext2fs
/usr/bin/ld: cannot find -le2p
collect2: error: ld returned 1 exist status
make[2]: *** [fsarchiver] Error 1
J'ai suspecté après recherche gcc car il semble que les librairies à lié doivent être passé à la fin, d'où l'usage de binutils223/gcc49 mais cela n'a pas eu de changement.
Offline
come back,
Alors la va comprendre
[c]package/version binutils glibc gcc e2fsprogs util-linux fsarchiver
cooking/rolling 2.37 2.14.1 4.6.3 1.45.5 2.38 OK
current 29/10 2.37 2.23 6.3.0 1.45.5 2.38 KO
current 2.37 2.28 8.3.0 1.45.5 2.38 KO
current (binutils223/gcc49) 2.23 2.28 4.9.2 1.45.5 2.38 KO
stable 4.x 2.23 2.22 4.9.2 1.44.2 2.19.1 OK
stable 4.x 2.23 2.22 4.9.2 1.45.5 2.19.1 KO
###
current 2.37 2.28 8.3.0 1.44.2 2.38 OK[/c]
Donc la version 1.44.2 e2fsprogs est ok pour construire fsarchiver mais pas 1.45.5, je vais continuer à creuser ce point.
Offline
Bonjour shann,
J'essaie de mettre mon wok à jour mais je me heurte à un petit problème :
# tazpkg -gi glib-dev --forced
Checksum error for "glib-dev-2.70.3.tazpkg"****************| 340k 0:00:00 ETA
Recharging repository "Main"
================================================================================
Checking... [ Done ]
Database timestamp: 02/19/24 20:59
================================================================================
Repository "Main" is up to date.
Checksum error for "glib-dev-2.70.3.tazpkg"****************| 340k 0:00:00 ETA
Please wait until the mirror synchronization is complete and try again.
Pourtant, l'heure de cuisson du paquet dans le Summary du cooker et l'heure de création du paquet sur le miroir coïncident. Une idée ?
Offline
Bonsoir Ceel,
J'ai vu que mirror pour current ne faisait pas de clean, j'ai ajusté ma commande rsync avec [c]--delete[/c].
Je viens de refaire un cook pkgdb et rsync, c'est rentré dans l'ordre.
Offline
Yes ! C'est tout bon.
Merci beaucoup.
Offline
Bonsoir shann,
Pour reprendre ton expression, alors là, va comprendre
Je n'avais pas percuté mais
[*]Rolling et Current 20231030 utilisent la même version d'[c]openbox[/c] et la même recette, et bien que le patch [c]openbox-rounded.patch[/c] soit appliqué, les fenêtres ont des coins... carrés
[*]Après mise à jour Current 20231030 avec [c]openbox[/c] bloqué (la version actuelle sur le miroir de Current dégrade les performances du mode graphique sur mon viel acer, les angles des fenêtres sont arrondis
Le coupable est ... [c]slitaz-configs[/c] @@
Comme il n'est pas possible de ré-empaqueter [c]slitaz-configs[/c] (du moins sur l'ISO justx) avant la mise à jour, je ne peux pas confirmer en revenant à la version initiale. Mais j'ai répété la manip, et idem.
Pourquoi la mise à jour de ce paquet modifie-t-elle l'apparence des fenêtres, il n'installe que des scripts, des fichiers de config, .desktop et quelques images ?
De plus, ni sa recette, ni sa version (donc ses sources), n'ont changé ???
Offline
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.62 MiB (Peak: 1.77 MiB) ]
