Cela fait – en ce 19 avril 2026 – deux semaines que j’ai lancé une expérience avec CalamaroOS en machine virtuelle, vous savez cette Gentoo précompilée avec systemd comme init principal.
Je dois dire que l’expérience est foncièrement ennuyeux. Cela fait facilement une dizaine de jours qu’aucune mise à jour n’a été rendu disponible. Un dépôt binaire complètement obsolète ?
J’ai donc utilisé le miroir de l’Ircam dans le fichier /etc/portage/binrepos.conf/, mais ça n’a rien changé. Toujours aucune mise à jour disponible.
Je dois dire que je commence à me poser des questions. Je vais quand même laisser une dernière chance à la CalamaroOS, mais son absence de mise à jour depuis près de deux semaines, ça m’interroge quelque part. En tout cas, c’est mal barré, et mon envie de continuer l’expérience est un brin émoussée.
Ajout le 21 avril vers 8 h 20 : Après quelques recherches, je me suis aperçu que sudo emerge --sync est cassé. Utiliser sudo emerge --webrsync suivi de la ligne de commande pour effectuer la mise à jour a été fonctionnelle.
J’ai trop l’habitude de gestionnaire de paquets qui synchronisent les miroirs et mettent à jour le système en une commande groupée 🙂
Même pas une update en ebuild? Pourtant ça envoi en ce moment, il n’y a pas une journée où il n’a rien (même si je fais qu’une fois par semaine). Tu as quoi dans le make.conf?
Tu devrais avoir:
EMERGE_DEFAULT_OPTS= »${EMERGE_DEFAULT_OPTS} –getbinpkg »
FEATURES= »getbinpkg »
Si tu veux la signature des paquets (conseillé): FEATURES= »binpkg-request-signature »
Puis faire un getuto.
tu fais quoi pour mettre à jour? Comment as tu rajouté les dépôts? Chez moi j’ai ceci dans mon binhost:
« `
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consider using a local mirror.
#[gentoo]
#priority = 1
#sync-uri = https://distfiles.gentoo.org/releases/amd64/binpackages/23.0/x86-64-v3
#location = /var/cache/binhost/gentoo
#verify-signature = true
[gentoo]
priority = 9999
sync-uri = https://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/releases/amd64/binpackages/23.0/x86-64-v3/
verify-signature = true
« `
Petite question, ça donne quoi comme modification? Je veux dire par là, ils ont chargé beaucoup de fichiers pour passer par dessus gentoo comme redcore ou bien c’est plutôt calculate?
Je t’ai répondu par courrier électronique, c’est plus pratique.
Ça m’a titiller alors j’ai été voir de mon coté, en ce moment j’ai un total de 18 packages (11 upgrades, 1 in new slot, 6 reinstalls, 5 binaries), oui seulement 5 binaires car j’ai toutes cette liste de paquets qui ne peut s’installer à cause de flag different entre mon système et les bianires eux mêmes:
« `
!!! The following binary packages have been ignored due to non matching USE:
=sys-libs/libseccomp-2.6.0-r3 -python_targets_python3_14
=sys-libs/libseccomp-2.6.0-r3 -python_targets_python3_13 -python_targets_python3_14
=sys-libs/libseccomp-2.6.0-r3 python_targets_python3_12 -python_targets_python3_13 -python_targets_python3_14
=sys-libs/libseccomp-2.6.0-r3 python_targets_python3_12 -python_targets_python3_14
=sys-libs/libseccomp-2.6.0-r3 -python_targets_python3_13 -python_targets_python3_14 -verify-sig
=sys-libs/libseccomp-2.6.0-r3 python_targets_python3_12 -python_targets_python3_13 -python_targets_python3_14 -verify-sig
=sys-libs/libseccomp-2.6.0-r3 python_targets_python3_12 -python_targets_python3_14 -verify-sig
=sys-libs/libseccomp-2.6.0-r3 -python_targets_python3_14 -verify-sig
=sys-libs/libblockdev-3.4.0 introspection -python_single_target_python3_13 -python_single_target_python3_14
=sys-libs/libblockdev-3.4.0 introspection python_single_target_python3_12 -python_single_target_python3_13 -python_single_target_python3_14
=sys-libs/libblockdev-3.4.0 introspection -python_single_target_python3_14
=sys-libs/libblockdev-3.4.0 -python_single_target_python3_13 -python_single_target_python3_14
=sys-libs/libblockdev-3.4.0 python_single_target_python3_12 -python_single_target_python3_13 -python_single_target_python3_14
=sys-libs/libblockdev-3.4.0 -python_single_target_python3_14
=net-libs/libtorrent-rasterbar-2.0.10 -python_single_target_python3_14
=net-libs/libtorrent-rasterbar-2.0.10 python -python_single_target_python3_10 python_single_target_python3_12 -python_single_target_python3_13 -python_single_target_python3_14
=net-libs/libtorrent-rasterbar-2.0.10 -python_single_target_python3_10 python_single_target_python3_12 -python_single_target_python3_13 -python_single_target_python3_14
« `
Remarques qu’on me dit quoi faire si je veux à tout prix des paquets compilés au lieu de compiler:
« `
NOTE: The –binpkg-respect-use=n option will prevent emerge
from ignoring these binary packages if possible.
Using –binpkg-respect-use=y will silence this warning.
« `
Ce qui m’étonne c’est que tu n’as pas de mises à jour tout court, mais il faut penser à une chose, les paquets pré-compiler ne sont disponibles qu’avec quelques flags populaires/communs, donc si tu as un système où tu as déjà rempli tes USE(s) avec des trucs peu communs. Pareil méfies toi du -U (changed-use) (https://wiki.gentoo.org/wiki/Binary_package_guide#Updating_packages_on_the_binary_package_host):
» Important
Do not use –changed-use(-U) when updating packages on the binary package host, doing so will cause packages with added or removed USE flags to be skipped, which will cause their installation from binary package on the client to fail due to non-matching USE between the source ebuild and binary package (if the client’s –binpkg-respect-use=y, the default). Use –newuse(-N), which will always rebuild packages even for added or removed USE flags, ensuring the binary package stays in sync with the source ebuild. »
Alors, si je comprends bien dans ton cas tu n’es pas concerné, mais ça reste un soucis car tu vas te retrouver avec des USE(s) qui ne seront plus en accord avec ton installation. Mais je me trompe certainement.
Salut
Question bete, mais comme je ne voit pas sur ta capture écran, as-tu fait un emerge –sync ?
Attention quand même, car si je ne m’abuse, Calamaro utilise flatpack ( dans les dernières version dispo). Du coup, peut être voir le nombres de programmes sous ce format qui ne sont pas mis à jour par la commande classique.
Bonne expérience à toi.
Le rsync lancé par la commande emerge –sync explose en vol :
rsync error: receive SIGINT, SIGTERM or SIGHUP (code 20) at rsync.c(716) [receiver=3.4.1]Et bien entendu, la connexion est fonctionnelle…
Je t’ai répondu tardivement par mail, j’ai juste deux interrogations donc tu ne pouvais pas syncro avec le miroir ça sera bon avec un « emaint -a sync », et as tu fais un getuto? Ça c’est pour les binaires (juste une fois), ça sert à importer les signatures. Sinon dans le mail, je t’ai apporté quelques (très peu en fait) améliorations de confort.
La solution emerge websync m’a débloqué la situation. Comme je l’ai précisé en addenda à l’article.