Libelektra: testshell_markdown_tutorial_crypto: échec

@ markus2330 cela réussit sur le serveur de compilation. Est-ce un spectacle pour vous? Cela serait reflété dans les journaux de la version ( kdb run_all -v > ~elektra/$VERSION/run_all 2>&1 ).

EDIT: Je peux essayer de faire cette partie sur a7 / v2 car cela échoue peut-être uniquement dans mon scénario avec fedora comme hôte (et debian uniquement dans docker).

Non, ce n'est certainement pas un spectacle. Très probablement, c'est simplement parce qu'un fichier temporaire est toujours là d'une exécution précédente ou # 2957 n'est pas complètement corrigé après tout.

Espérons que @ petermax2 a le temps de le réparer avant la version 0.9.2: wink:

@mpranj avez-vous besoin d'aide avec les notes de version ou autre chose?

Je ne peux pas reproduire le problème lors de la construction de 2bc994ae8b3f3a04396303ece106ea563764e490 à partir de zéro en utilisant votre commande cmake d'en haut.

    Start 188: testshell_markdown_tutorial_crypto 
222/235 Test #188: testshell_markdown_tutorial_crypto ...........   Passed    3.16 sec

Peut-être que votre répertoire de construction est cassé. Pourriez-vous s'il vous plaît essayer de compiler et de tester avec un nouveau répertoire de construction (vide)?

@ petermax2 merci de l'avoir vérifié si rapidement. J'ai essayé plusieurs fois sur mon système hôte (fedora) et aussi sur un conteneur docker debian buster. J'ai également nettoyé le répertoire de construction plusieurs fois.

Il est toujours possible que ce soit juste un problème de mon côté. Je vérifierai à nouveau plus tard!

Hm étrange! Je pense que j'ai utilisé hier un conteneur Debian: stable pour la construction et les tests. Je peux réessayer avec Fedora dans la soirée. Pour le moment, je n'ai pas beaucoup de temps pour le dépannage mais je vais jeter un coup d'œil rapide.

Le problème est reproductible sous Fedora.

The following tests FAILED:
 41 - testshell_markdown_base64 (Failed)
 56 - testshell_markdown_csvstorage (Failed)
 76 - testshell_markdown_iconv (Failed)
 78 - testshell_markdown_ini (Failed)
 93 - testshell_markdown_mini (Failed)
116 - testmod_resolver (Failed)
181 - testshell_markdown_tutorial_crypto (Failed)

Ce n'est peut-être pas un problème spécifique au didacticiel cryptographique. Je dois enquêter.

kdb gen-gpg-testkey est introuvable. Ce problème est lié à # 3246 (KDB_EXEC_PATH).

EDIT: L'analyse n'est valable que pour testshell_markdown_tutorial_crypto . Je n'ai pas encore vérifié les autres tests.

Merci d'avoir jeté un œil à ce numéro!

Je n'ai pas vu les autres tests échouer tbh. Etes-vous sûr que c'est le même problème? Je n'ai même pas travaillé avec le kdb installé, j'ai juste lancé ctest avec make run_all.

À long terme, nous ajouterons également des images de docker fedora (# 3227), pour attraper quelque chose comme ça plus tôt.

Etes-vous sûr que c'est le même problème?

Non, probablement plusieurs problèmes différents.

À long terme, nous ajouterons également des images de docker fedora

Très bonne idée!

J'ai édité mon article d'avant pour clarifier ce que je voulais dire avec mon analyse.

Le problème n'est pas isolé de ma machine. Le test échoue car l'appel de rename () suivant échoue:
https://github.com/ElektraInitiative/libelektra/blob/263cbe69686a9f087204a7f3660b007d1de22da2/src/plugins/fcrypt/fcrypt.c#L231

La raison en est que / tmp est un point de montage séparé sur Fedora par défaut, ce qui n'était pas le cas pour Debian. Ainsi, le fichier ne peut pas être renommé sur différents points de montage.

J'ai vérifié que c'était bien le problème en appliquant un patch (très sale). Je proposerais de le garder cohérent avec l'implémentation du résolveur et de placer le fichier temporaire dans le même répertoire que le fichier d'origine.

@ petermax2 qu'en pensez-vous et auriez-vous le temps de le réparer avec un correctif approprié?

Le répertoire tmp utilisé par fcrypt peut être défini via la configuration du plugin.

fcrypt utilise l'option de configuration fcrypt / tmpdir pour générer des chemins pour les fichiers temporaires pendant le chiffrement et le déchiffrement. Si aucune option de configuration de ce type n'est fournie, fcrypt essaiera d'utiliser la variable d'environnement TMPDIR. Si TMPDIR n'est pas défini dans l'environnement, / tmp est utilisé comme répertoire par défaut.

(_Source_: Documentation du plugin )

Le moyen le plus simple d'atténuer les tâches de construction de type Fedora serait d'utiliser un autre répertoire. Sur le serveur de build, le répertoire de build local peut être utilisé. Qu'est-ce que tu penses?

@ petermax2 qu'en pensez-vous et auriez-vous le temps de le réparer avec un correctif approprié?

Je peux allouer du temps libre le week-end, mais qu'avez-vous à l'esprit comme solution appropriée?

Je peux allouer du temps libre le week-end, mais qu'avez-vous à l'esprit comme solution appropriée?

Pas besoin de sur-concevoir quoi que ce soit. Comme je l'ai suggéré, je mettrais le fichier temporaire dans le même répertoire que le fichier cible. C'est ainsi que resolver fait lors de la validation des modifications, donc ce serait un peu cohérent.

Je suis également très bien avec la configuration d'un TMPDIR différent pour les versions. Je peux mettre en œuvre ce changement moi-même.

Nous suivrons tout ce que vous suggérez ici.

De renommer docu :

[EXDEV]
[CX] [Option Start] The links named by new and old are on different file systems and the implementation does not support links between file systems. [Option End]

Edit: échoue avec sudo avec la même erreur:

213: CMD: kdb set user/tests/password 1234
213: RET: 5
213: === FAILED return value does not match expected pattern 0
213: STDERR: Sorry, module fcrypt issued the error C01100:
213: Resource: Renaming file /tmp/test.ini.571145:1586371945.946855.tmpHdGEMt to /root/.config/test.ini.571145:1586371945.946855.tmp failed. Reason: Invalid cross-device link
213: ERROR: C01100

Une solution simpliste serait de remplacer l'opération rename par une copie + supprimer.

Je vais simplement configurer un TMPDIR différent explicitement pour les versions. Si le problème se reproduit sur les systèmes cibles, nous pouvons rouvrir et trouver une meilleure solution.

Ce problème pourrait survenir plus souvent, je pense. Nous recommandons même dans la documentation de fcrypt de remonter /tmp sur un disque RAM. Nous vous recommandons donc de déclencher cette erreur immédiatement.

Je vais essayer de fournir une solution appropriée.

Je vais simplement configurer un TMPDIR différent explicitement pour les versions. Si le problème se reproduit sur les systèmes cibles, nous pouvons rouvrir et trouver une meilleure solution.

C'est également une solution de contournement pour les serveurs de build.

Merci beaucoup pour votre recherche!

Une solution simpliste serait de remplacer l'opération de renommage par une copie + suppression.

Pas pour remplacer le code mais pour le faire si le changement de nom échoue. (Et pour déchiqueter également le fichier source dans ce cas.) Ensuite, les personnes sans disque RAM sur / tmp ont de la vitesse et les personnes avec un disque RAM sur / tmp ont plus de sécurité.