Packaging [Réglé] Fork de usb-imagewriter : IsoDumper Déjà dans les dépôts
Reprise du message précédent
carabao :
isodumper ne se lance toujours pas à partir du menu de kde. Pas de mot de passe demandé.
A partir de la console pas de problème.
idem pour la version de ce matin (0.13-1.mga4)
Maintenant il me demande les droits root directement au lancement de la commande:
je pensais que le mot de passe était simplement nécessaire pour écrire sur une clé ?
A partir de la console pas de problème.
idem pour la version de ce matin (0.13-1.mga4)
Maintenant il me demande les droits root directement au lancement de la commande:
je pensais que le mot de passe était simplement nécessaire pour écrire sur une clé ?
Bonjour,
L'identification en tant qu'administrateur ne serait requise qu'au moment de l'écriture. Mais comme je ne sais pas gérer çà, l'identification est demandée au début, pour l'ensemble du programme.
Si tu lances le programme sans droit root, il va s'exécuter, mais au moment de l'écriture, il va s'arrêter faute de droits suffisants.
Est-ce plus clair ?
Concernant le lancement depuis KDE, j'ai l'impression qu'il y a des problèmes autres. J'ai des problèmes par exemple avec le lancement du CCM.
D'autres pour confirmer ?
Yves
I/
1 Actuelement (le 22-12-2013, en matinée, Cauldron x-64 b2, neuve de dvd déballé sur miroir local, puis mise à jour), isodumper lancé en session-utilisateur-kde par un clic sur son icône (menu kde) n'affiche rien.... Attente perpétuelle. Comme Carabao.
2 Lancé en konsole simple utilisateur, isodumper demande le m.d.p. root validé, et le programme continue normalement à son terme si les réponses clavier qu'il attend lui conviennent et que le matériel usb est présent et détecté.
3 Dans une session graphique ouverte par startx --> kde (donc en super-u graphique tout le temps, pas recommandé, mais c'est le test), la boîte s'ouvre, on renseigne uniquement la source et la cible, et le programme aboutit (sans demande de mdp).
4 Donc le problème c'est: comment faire apparaître sur l'écran la boîte de dialogue du lanceur graphique (isodumper.desktop), actuellement muet en utilisateur-non-privilégié ?
4.1 Je proposais de la rendre visible, ici dans kde, par l'ajout (dans un éditeur ascii super-u) à la fin du script isodumper.desktop de la clé:
X-KDE-SubstituteUID=true
servant à faire apparaître (ou non, avec false) un programme à l'écran du bureau-utilisateur référencé.
Ce script est ici par construction:
/usr/share/applications/isodumper.desktop
II/
J'ai tenté, et ça fonctionne, urpmi task-gnome (sans avoir modifié isodumper.desktop comme ci-dessus). Le fait d'avoir téléchargé un autre bureau, pour une raison que je n'ai pas tenté de connaître, rend isodumper utilisable brut de téléchargement en utilisateur par simple cliquage du menu aussi bien avec gnome que kde. La suppression totale de gnome laisse isodumper utilisable en utilisateur kde.... !!! Je n'ai pas le temps de chercher pourquoi !
Voici un extrait des normes freedesktop, dans quoi est indiqué que [X-PRODUCT GROUPNAME] or something similar est utilisable .
==========================================================
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html
==========================================================
Extending the format
If the standard is to be amended with a new {key,value} pair which should be applicable to all supporting parties, a group discussion will take place. This is the preferred method for introducing changes. If one particular party wishes to add a field for personal use, they should prefix the key with the string X-PRODUCT, e.g. X-NewDesktop-Foo, following the precedent set by other IETF and RFC standards.
Alternatively, fields can be placed in their own group, where they may then have arbitrary key names. If this is the case, the group should follow the scheme outlined above, i.e. [X-PRODUCT GROUPNAME] or something similar. These steps will avoid namespace clashes between different yet similar environments.
A. Example Desktop Entry File
[Desktop Entry]
Version=1.0
Type=Application
Name=Foo Viewer
Comment=The best viewer for Foo objects available!
TryExec=fooview
Exec=fooview %F
Icon=fooview.png
MimeType=image/x-foo;
X-KDE-Library=libfooview
X-KDE-FactoryName=fooviewfactory
X-KDE-ServiceType=FooService
===========================================================
Il est fort possible que l'obstacle soit dans mon installation et que l'affichage soit régulier chez d'autres... auquel cas il vaudrait mieux ne pas tenir compte de cette pseudo-trouvaille ! Edité par alp1 Le 22/12/2013 à 11h01
1 Actuelement (le 22-12-2013, en matinée, Cauldron x-64 b2, neuve de dvd déballé sur miroir local, puis mise à jour), isodumper lancé en session-utilisateur-kde par un clic sur son icône (menu kde) n'affiche rien.... Attente perpétuelle. Comme Carabao.
2 Lancé en konsole simple utilisateur, isodumper demande le m.d.p. root validé, et le programme continue normalement à son terme si les réponses clavier qu'il attend lui conviennent et que le matériel usb est présent et détecté.
3 Dans une session graphique ouverte par startx --> kde (donc en super-u graphique tout le temps, pas recommandé, mais c'est le test), la boîte s'ouvre, on renseigne uniquement la source et la cible, et le programme aboutit (sans demande de mdp).
4 Donc le problème c'est: comment faire apparaître sur l'écran la boîte de dialogue du lanceur graphique (isodumper.desktop), actuellement muet en utilisateur-non-privilégié ?
4.1 Je proposais de la rendre visible, ici dans kde, par l'ajout (dans un éditeur ascii super-u) à la fin du script isodumper.desktop de la clé:
X-KDE-SubstituteUID=true
servant à faire apparaître (ou non, avec false) un programme à l'écran du bureau-utilisateur référencé.
Ce script est ici par construction:
/usr/share/applications/isodumper.desktop
II/
J'ai tenté, et ça fonctionne, urpmi task-gnome (sans avoir modifié isodumper.desktop comme ci-dessus). Le fait d'avoir téléchargé un autre bureau, pour une raison que je n'ai pas tenté de connaître, rend isodumper utilisable brut de téléchargement en utilisateur par simple cliquage du menu aussi bien avec gnome que kde. La suppression totale de gnome laisse isodumper utilisable en utilisateur kde.... !!! Je n'ai pas le temps de chercher pourquoi !
Voici un extrait des normes freedesktop, dans quoi est indiqué que [X-PRODUCT GROUPNAME] or something similar est utilisable .
==========================================================
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html
==========================================================
Extending the format
If the standard is to be amended with a new {key,value} pair which should be applicable to all supporting parties, a group discussion will take place. This is the preferred method for introducing changes. If one particular party wishes to add a field for personal use, they should prefix the key with the string X-PRODUCT, e.g. X-NewDesktop-Foo, following the precedent set by other IETF and RFC standards.
Alternatively, fields can be placed in their own group, where they may then have arbitrary key names. If this is the case, the group should follow the scheme outlined above, i.e. [X-PRODUCT GROUPNAME] or something similar. These steps will avoid namespace clashes between different yet similar environments.
A. Example Desktop Entry File
[Desktop Entry]
Version=1.0
Type=Application
Name=Foo Viewer
Comment=The best viewer for Foo objects available!
TryExec=fooview
Exec=fooview %F
Icon=fooview.png
MimeType=image/x-foo;
X-KDE-Library=libfooview
X-KDE-FactoryName=fooviewfactory
X-KDE-ServiceType=FooService
===========================================================
Il est fort possible que l'obstacle soit dans mon installation et que l'affichage soit régulier chez d'autres... auquel cas il vaudrait mieux ne pas tenir compte de cette pseudo-trouvaille ! Edité par alp1 Le 22/12/2013 à 11h01
carabao
Membre non connecté

salut alp1,
j'ai effectué ta modification
X-KDE-SubstituteUID=true dans /usr/share/applications/isodumper.desktop
et effectivement le programme se lance en mode graphique.
Si je mets, X-KDE-SubstituteUID=FALSE , il ne se lance pas du tout.
Donc droit root obligatoire en mode graphique dès e lancement
En mode console, je peux démarrer le progrmme en mode utilisateur, le mot de passe root n'est demandé que lorsque je veux écrire sur la clé.
Pourquoi cette différence ?
Et je ne comprends toujours pas pourquoi le mot de passe root est nécessaire par défaut pour écrire sur une clé usb . Ces permissions ne doivent-elles pas être réglées au niveau du système et non du programme ? En interdisant par exemple l'utilisation du port USB à un utilisateur non ROOT .
j'ai effectué ta modification
X-KDE-SubstituteUID=true dans /usr/share/applications/isodumper.desktop
et effectivement le programme se lance en mode graphique.
Si je mets, X-KDE-SubstituteUID=FALSE , il ne se lance pas du tout.
Donc droit root obligatoire en mode graphique dès e lancement
En mode console, je peux démarrer le progrmme en mode utilisateur, le mot de passe root n'est demandé que lorsque je veux écrire sur la clé.
Pourquoi cette différence ?
Et je ne comprends toujours pas pourquoi le mot de passe root est nécessaire par défaut pour écrire sur une clé usb . Ces permissions ne doivent-elles pas être réglées au niveau du système et non du programme ? En interdisant par exemple l'utilisation du port USB à un utilisateur non ROOT .
carabao
Membre non connecté

il se lance sans problème sans demander le mot de passe.
Maintenant, j'ai laissé ta modification (X-KDE-SubstituteUID=true ) pour le lien dans le menu de kde, il se lance aussi sans problème mais avec la demande du mot de passe ROOT dès le lancement. Edité par carabao Le 22/12/2013 à 14h20
Maintenant, j'ai laissé ta modification (X-KDE-SubstituteUID=true ) pour le lien dans le menu de kde, il se lance aussi sans problème mais avec la demande du mot de passe ROOT dès le lancement. Edité par carabao Le 22/12/2013 à 14h20
Pour vous mettre l'eau à la bouche, j'ai fait évoluer isodumper vers une version 0.30.
Il dispose maintenant de trois fonctions qui peuvent être mise en œuvre de manière indépendante :
1- écriture d'une image sur la clé (rien de nouveau)
2- sauvegarde du contenu de la clé dans un fichier image. La restauration se fait avec la fonction 1.
3- formatage en une partition au choix FAT32 NTFS et ext4.
Pour l'instant c'est dans github uniquement, mais je ne doute pas que David_david va vous packager çà
Il dispose maintenant de trois fonctions qui peuvent être mise en œuvre de manière indépendante :
1- écriture d'une image sur la clé (rien de nouveau)
2- sauvegarde du contenu de la clé dans un fichier image. La restauration se fait avec la fonction 1.
3- formatage en une partition au choix FAT32 NTFS et ext4.
Pour l'instant c'est dans github uniquement, mais je ne doute pas que David_david va vous packager çà

Yves
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie