Erreur en utilisant auroscope pour chercher des packages #99

New issue

Closed

opened 2026-10-21 00:51:47 +00:00 by mathieu · 1 comment

mathieu commented

2026-10-21 00:51:47 +00:00

Owner

MODE: EXECUTION

❯ auroscope proton

...


 10 extra/python-proton-vpn-local-agent 1.6.3-1 [1.40 MiB 4.50 MiB]
    Proton VPN local agent written in Rust
  9 extra/python-proton-vpn-api-core 5.8.7-1 [4.85 MiB 25.59 MiB]
    The proton-vpn-core-api acts as a facade to the other Proton VPN components, exposing a uniform API to the available Proton VPN services.
  8 extra/python-proton-keyring-linux 0.2.3-1 [25.84 KiB 89.83 KiB]
    The proton-keyring-linux component.
  7 extra/python-proton-core 0.7.4-1 [119.62 KiB 654.62 KiB]
    The proton-core component contains core logic used by the other Proton components.
  6 extra/protontricks 1.14.1-1 [135.69 KiB 643.07 KiB]
    Run Winetricks commands for Steam Play/Proton games among other common Wine features
  5 extra/protonmail-bridge-core 3.27.1-1 [8.99 MiB 29.52 MiB]
    Integrate ProtonMail paid account with any program that supports IMAP and SMTP (core executable and daemon)
  4 extra/protonmail-bridge 3.27.1-1 [1.52 MiB 3.19 MiB]
    Integrate ProtonMail paid account with any program that supports IMAP and SMTP (Qt desktop application)
  3 extra/proton-vpn-gtk-app 4.18.7-1 [703.17 KiB 5.16 MiB]
    ProtonVPN GTK app, Maintained by Community
  2 extra/proton-vpn-daemon 0.13.8-1 [45.33 KiB 227.37 KiB]
    Daemons for Proton VPN Linux client (split tunneling service)
  1 extra/proton-vpn-cli 1.0.5-1 [82.78 KiB 432.68 KiB]
    Official ProtonVPN CLI Linux app
:: Paquets à sélectionner (ex : 1 2 3, 1-3) :
:: 4 3 2
auroscope: incompatible Paru issue-21 contract: requested target "proton-vpn-daemon" was not classified
zsh: exit 1     auroscope proton

MODE: EXECUTION ``` ❯ auroscope proton ... 10 extra/python-proton-vpn-local-agent 1.6.3-1 [1.40 MiB 4.50 MiB] Proton VPN local agent written in Rust 9 extra/python-proton-vpn-api-core 5.8.7-1 [4.85 MiB 25.59 MiB] The proton-vpn-core-api acts as a facade to the other Proton VPN components, exposing a uniform API to the available Proton VPN services. 8 extra/python-proton-keyring-linux 0.2.3-1 [25.84 KiB 89.83 KiB] The proton-keyring-linux component. 7 extra/python-proton-core 0.7.4-1 [119.62 KiB 654.62 KiB] The proton-core component contains core logic used by the other Proton components. 6 extra/protontricks 1.14.1-1 [135.69 KiB 643.07 KiB] Run Winetricks commands for Steam Play/Proton games among other common Wine features 5 extra/protonmail-bridge-core 3.27.1-1 [8.99 MiB 29.52 MiB] Integrate ProtonMail paid account with any program that supports IMAP and SMTP (core executable and daemon) 4 extra/protonmail-bridge 3.27.1-1 [1.52 MiB 3.19 MiB] Integrate ProtonMail paid account with any program that supports IMAP and SMTP (Qt desktop application) 3 extra/proton-vpn-gtk-app 4.18.7-1 [703.17 KiB 5.16 MiB] ProtonVPN GTK app, Maintained by Community 2 extra/proton-vpn-daemon 0.13.8-1 [45.33 KiB 227.37 KiB] Daemons for Proton VPN Linux client (split tunneling service) 1 extra/proton-vpn-cli 1.0.5-1 [82.78 KiB 432.68 KiB] Official ProtonVPN CLI Linux app :: Paquets à sélectionner (ex : 1 2 3, 1-3) : :: 4 3 2 auroscope: incompatible Paru issue-21 contract: requested target "proton-vpn-daemon" was not classified zsh: exit 1 auroscope proton ```

hephaistos added the

Status

In Progress

Kind/Bug

labels

2026-10-21 00:52:17 +00:00

hephaistos commented

2026-10-21 00:58:51 +00:00

Owner

Diagnostic confirmé — bug de classification, pas de recherche

La sélection de Paru fonctionne. Le refus vient ensuite d’AURoscope : il suppose
qu’un paquet explicitement demandé porte forcément le rôle TARGET dans
paru -P --order. Cette hypothèse est fausse sur le Paru déjà supporté.

Reproduction avec le vrai Paru

J’ai compilé le commit compatible 9ac3578807a87858651e81a02586ceb947686e7c
dans l’image Arch épinglée par le projet. La résolution suivante réussit,
avec un code de sortie 0 :

paru -P --order -- protonmail-bridge proton-vpn-gtk-app proton-vpn-daemon

Extraits réels, les autres dépendances étant omises ici :

REPO TARGET extra protonmail-bridge
REPO DEP extra proton-vpn-daemon
REPO TARGET extra proton-vpn-gtk-app

proton-vpn-daemon est déjà rencontré comme dépendance de l’application VPN.
Le résolveur le conserve en DEP lorsqu’il arrive ensuite à cette cible explicite.
En plaçant le daemon en premier, les trois paquets ressortent en TARGET.
Le daemon seul ressort également en TARGET ; l’application seule le fait
ressortir en DEP. Le défaut dépend donc de la combinaison, de l’ordre des
cibles et de l’état des paquets installés, pas du mot recherché « proton ».

Cause dans le code

internal/app/paru.go:300-315 : ensureTargetsClassified ne compte que
les entrées TARGET et produit exactement l’erreur signalée.
internal/app/paru.go:268-273 : plan ne conserve également que les
cibles officielles marquées TARGET pour la transaction finale.
internal/app/review.go:45-57 : ce contrôle bloque avant l’installation
native des paquets officiels.

Le comportement amont est établi dans src/order.rs::get_pkg_type du Paru
épinglé et aur-depends 5.0.0, src/resolve.rs::resolve_repo_pkg : un paquet
visité n’est pas promu en cible lors d’un second passage.

Supprimer seulement l’erreur serait incomplet : la préparation du plan
perdrait encore une cible sélectionnée. Le correctif doit reconnaître une cible
présente sous un rôle de dépendance et préserver les cibles explicitement
sélectionnées lors du transfert final, sans promouvoir toutes les dépendances
en cibles ni supprimer le refus des cibles réellement absentes.

Vérifications et limites

Un test diagnostique temporaire appliqué par overlay Go au code 88ebe63
reproduit exactement l’erreur avec DEP et MAKE. Le contrôle avec trois
entrées TARGET passe. Il confirme aussi la perte de la cible dans RepoTargets.
Les tests existants de sélection, résolution et chemin officiel passent : ils
ne couvraient pas cette combinaison de cibles officielles interdépendantes.

Aucun paquet Proton n’a été installé, aucune recette AUR n’a été exécutée et
aucune modification n’a été faite sur le poste de Mathieu. Le checkout reste
inchangé. Ce diagnostic n’est ni un correctif ni une qualification de paquet.
Les preuves locales sont dans le répertoire temporaire
/home/mathieu/.hermes/profiles/hephaistos/cache/scratch/auroscope-99/
(probe-arch.log, results.json, diagnostic-test.log).

Suite

Classification : MODE: EXECUTION, bug dans le périmètre existant ; aucun
arbitrage d’architecture n’est requis. Responsable technique : Héphaïstos.
Reste à corriger les deux points, ajouter une non-régression avec le vrai Paru
pour ces cibles et leur ordre inverse, puis livrer et qualifier le paquet Arch
dans une PR. Le ticket reste ouvert ; aucun correctif n’est publié à ce stade.

## Diagnostic confirmé — bug de classification, pas de recherche La sélection de Paru fonctionne. Le refus vient ensuite d’AURoscope : il suppose qu’un paquet explicitement demandé porte forcément le rôle `TARGET` dans `paru -P --order`. Cette hypothèse est fausse sur le Paru déjà supporté. ### Reproduction avec le vrai Paru J’ai compilé le commit compatible `9ac3578807a87858651e81a02586ceb947686e7c` dans l’image Arch épinglée par le projet. La résolution suivante réussit, avec un code de sortie 0 : ```sh paru -P --order -- protonmail-bridge proton-vpn-gtk-app proton-vpn-daemon ``` Extraits réels, les autres dépendances étant omises ici : ```text REPO TARGET extra protonmail-bridge REPO DEP extra proton-vpn-daemon REPO TARGET extra proton-vpn-gtk-app ``` `proton-vpn-daemon` est déjà rencontré comme dépendance de l’application VPN. Le résolveur le conserve en `DEP` lorsqu’il arrive ensuite à cette cible explicite. En plaçant le daemon en premier, les trois paquets ressortent en `TARGET`. Le daemon seul ressort également en `TARGET` ; l’application seule le fait ressortir en `DEP`. Le défaut dépend donc de la combinaison, de l’ordre des cibles et de l’état des paquets installés, pas du mot recherché « proton ». ### Cause dans le code - `internal/app/paru.go:300-315` : `ensureTargetsClassified` ne compte que les entrées `TARGET` et produit exactement l’erreur signalée. - `internal/app/paru.go:268-273` : `plan` ne conserve également que les cibles officielles marquées `TARGET` pour la transaction finale. - `internal/app/review.go:45-57` : ce contrôle bloque avant l’installation native des paquets officiels. Le comportement amont est établi dans `src/order.rs::get_pkg_type` du Paru épinglé et `aur-depends 5.0.0`, `src/resolve.rs::resolve_repo_pkg` : un paquet visité n’est pas promu en cible lors d’un second passage. **Supprimer seulement l’erreur serait incomplet** : la préparation du plan perdrait encore une cible sélectionnée. Le correctif doit reconnaître une cible présente sous un rôle de dépendance et préserver les cibles explicitement sélectionnées lors du transfert final, sans promouvoir toutes les dépendances en cibles ni supprimer le refus des cibles réellement absentes. ### Vérifications et limites Un test diagnostique temporaire appliqué par overlay Go au code `88ebe63` reproduit exactement l’erreur avec `DEP` et `MAKE`. Le contrôle avec trois entrées `TARGET` passe. Il confirme aussi la perte de la cible dans `RepoTargets`. Les tests existants de sélection, résolution et chemin officiel passent : ils ne couvraient pas cette combinaison de cibles officielles interdépendantes. Aucun paquet Proton n’a été installé, aucune recette AUR n’a été exécutée et aucune modification n’a été faite sur le poste de Mathieu. Le checkout reste inchangé. Ce diagnostic n’est ni un correctif ni une qualification de paquet. Les preuves locales sont dans le répertoire temporaire `/home/mathieu/.hermes/profiles/hephaistos/cache/scratch/auroscope-99/` (`probe-arch.log`, `results.json`, `diagnostic-test.log`). ### Suite Classification : `MODE: EXECUTION`, bug dans le périmètre existant ; aucun arbitrage d’architecture n’est requis. Responsable technique : Héphaïstos. Reste à corriger les deux points, ajouter une non-régression avec le vrai Paru pour ces cibles et leur ordre inverse, puis livrer et qualifier le paquet Arch dans une PR. Le ticket reste ouvert ; aucun correctif n’est publié à ce stade.

hephaistos referenced this issue from a pull request that will close it,

2026-10-21 01:16:52 +00:00

Corriger les sélections de paquets déjà résolus comme dépendances #100

hephaistos

2026-10-21 01:16:53 +00:00