Cette espace vous permet de voir toutes les Messages réalisées par ce membre. Vous ne pouvez voir que les Messages réalisées dans les espaces auxquels vous avez accès.
Depuis quelques jours ma tumbleweed ne s'éteint plus correctement. La procédure se bloque sur : A stop job is running for Network Manager ( / )
Avec un chrono qui s'incrémente et une échéance affichée à 1min31s. Au bout d'1min31 l'échéance passe à 3min01, puis 4min32, puis 6min02. Là il passe enfin à l'étape suivante, puis se bloque à nouveau : A stop job is running for WPA Supplicant daemon ( / )
Ça tourne... l'échéance grimpe tranquillement jusqu'à 12min03... C'est long ! Il enchaîne et finit par rester bloqué sur un laconique "Reached target power-off", où il ne me reste plus qu'à faire un appui long sur le bouton power
Pour une machine qui redémarrait en 45 secondes il y a quelques jours c'est un peu frustrant ! Comportement pas systématique, mais pas loin, c'est à dire bien trop fréquent à mon goût. Reproduit en utilisant la commande d'extinction de KDE, également avec une commande poweroff en root
Petite mise à jour : j'ai posté sur le forum de FreeCAD (ici) La solution que l'on m'a proposée = passer sur la dernière version, depuis Github Ca fonctionne effectivement, avec cette version le problème est résolu (voir le lien ci-dessus). Mais du coup il faut utiliser la version de FreeCAD au format AppImage...
En pratique ça ressemble à un problème d'intégration avec Qt La dernière version AppImage intègre un FreeCAD plus récent que la version actuellement disponible dans Tumbleweed... mais avec un Qt plus ancien. A voir comment ça va évoluer !
Merci pour l'info, la description du problème a l'air très cohérente avec ce que je vois chez moi. Pas réussi à faire un downgrade (revenir en 0.18.x) depuis opensuse software, conflit de dépendances non résolu. Bon, je sens que je vais être obligé d'attendre un peu une prochaine mise à jour... Les aléas de la rolling release !
Concernant l'ouverture depuis dolphin : le problème est a priori purement interne à FreeCAD. Ca n'est qu'un exemple des très nombreux cas d'erreur. Indépendamment de ça, j'ai droit à des erreurs très souvent, dès que je manipule un peu des objets dans FreeCAD. Le simple fait de déplacer une pièce dans la vue 3D amène parfois ce type d'erreur, également lorsque je dessine des nouveaux éléments avec le sketcher. Mais de manière assez aléatoire. J'ai cité le problème d'ouverture de fichier dans mon post précédent, car au moins il est systématique, et donc trivial à reproduire.
Effectivement sur software opensuse il y a dans les paquets communautaires une version 0.18, je vais tester ça.
Depuis la dernière mise à jour de FreeCAD (0.19.1-1.1) celui-ci s'avère assez instable, et me renvoie à la pelle des erreurs "call stack is not deep enough" Un exemple assez trivial (parmi beaucoup d'autres) : depuis FreeCAD, ouvrir un fichier fonctionne sans problème. Mais en cliquant directement sur le même fichier depuis Dolphin, FreeCAD s'ouvre, me renvoie une palanquée erreurs "call stack is not deep enough", et ne m'affiche rien de rien (re- ) 2 petites questions : - je suis le seul dans ce-cas là ? - quelqu'un saurait me dire comment faire un downgrade du package ? Sous Leap je saurais faire sans problème, mais sous Tumbleweed je n'ai jamais fait. Dans le software management de Yast, seule la dernière version du package apparaît (ce qui paraît logique dans une rolling release...)
Depuis quelques semaines, je n'ai plus d'icône pour mon client owncloud dans ma "boîte à miniatures" KDE sous Tumbleweed. Ou plutôt l'icône n'est plus visible. Il y a bien un espace vide à la place, quand je passe la souris dessus il m'affiche le message correspondant, je peux faire un clic-droit dessus et j'ai mon menu contextuel owncloud, mais l'icône n'est plus visible. Pas dramatique, mais bon. Comme l'icône affiche l'état de la synchronisation c'est tout de même pratique quand ça marche. Quelqu'un a une idée ? (note : pas de problème sur une autre machine sous Leap)
Maintenant je m'interroge en aparté : /usr/local/bin/ est normalement un chemin d'accès déclaré des exécutables de telle sorte qu'une commande présente dans /usr/local/bin/ ne doivent pas être nécessairement précédée de son chemin pour l'invoquer (j'exprime en français ma compréhension du PATH... c'est plus long, désolé). Donc pas normal que cela ne réagisse pas correctement à la première invoquation.
Oui... mais non ! En fait cela me semble tout à fait normal...et même plutôt bien pensé. Avec sudo on donne des droits à un programme précis, pas juste à un nom de commande. Il faut tout de même éviter qu'un petit malin créé un binaire, le nomme "protonvpn", le range quelque part dans le path, et puisse ensuite l'exécuter en root sans mot de passe ! Yast/sudo est d'ailleurs bien fait, puisqu'il demande de sélectionner le programme (avec son emplacement précis), pas juste de donner un nom de commande.
D'ailleurs ça m'intrigue un peu ce protonvpn. S'il ne doit être exécuté que par root, je me demande bien pourquoi il est rangé dans /usr/local/bin et pas /usr/local/sbin qui est fait pour ça (les binaires réservés à root). Pour éviter des risques inutiles, il serait bon de vérifier que seul root à le droit de modifier /usr/local/bin/protonvpn, sinon on retrouve le problème de sécurité mentionné plus haut (n'importe qui peut faire n'importe quoi avec les droits root, bof bof).
En résumé, sudo c'est avec précautions. En règle générale quand on crée des exceptions de sécurité avec sudo, il faut faire attention à maîtriser le programme auquel on donne des droits privilégiés
scrogneugneu, même en sudo, il me demande quand même mon password!
Euuuh... Je ne comprends pas : si j'en crois ta capture d'écran, tu n'as pas eu besoin de saisir le mdp quand tu as tapé la commande "sudo /usr/local/bin/protonvpn c -f" ? En clair ça a l'air de marcher, non ?
Le plus simple à mon avis pour automatiser : - tu crées un fichier texte "monscriptamoi.sh" quelque part - tu le rends exécutable : "chmod +x monscriptamoi.sh", ou simplement via dolphin/clic-droit/propriétés/Droits d'accès et tu coches "est exécutable" - tu tapes dedans ta commande: sudo /usr/local/bin/protonvpn c -f - via "Configuration du système / Démarrage et arrêt / Démarrage automatique" tu pointes sur ton script.
Ça devrait se lancer tout seul à chaque ouverture de session, et sans demander de mdp
Je ne connais pas protonvpn, mais s'il a besoin d'être connecté au réseau avant de s'exécuter et que tu te connectes en wifi, il y a moyen pour que le script se lance trop tôt et que ça foire... Dans ce cas, tu peux aussi (toujours via "configuration du système") attacher un raccourci clavier perso à ton script. Comme ça, quand tu en as besoin, un petit raccourci clavier et c'est bon.
Je serais un peu moins optimiste, en pratique je ne vois aucune raison pour laquelle un prochain upgrade pourrait régler le problème... C'est d'autant plus surprenant que chez moi le diaporama est toujours là, alors que je suis bien sur libliveMedia81. Ça vient peut-être d'ailleurs... Côté kernel je suis passé en 5.8.14 mais je serais étonné que le problème vienne de là.
Afficher l'historique , je choisi la date du 20/10 de mon dernier zypper dup ce qui => une liste de paquets et leur version; je cherche dans les paquets k; peut-être kcoreaddons 5.75.0 ?? cliquer dessus ne fait rien...
Effectivement c'est juste une liste qui s'affiche, pas moyen de cliquer dessus. Normalement il affiche le nom des paquets modifiés, installés, et des paquets supprimés (avec une petite croix rouge sur l'icône du paquet). J'espérais juste que par là tu puisses retrouver le nom des paquets que tu as perdus (pour pouvoir les réinstaller à la main)...
Bizarre d'ailleurs: sur ma tumbleweed (à jour) je vois toujours le diaporama dans "clic-droit, Configurer le bureau et les fonds d'écran", dans l'onglet "fond d'écran", dans la liste déroulante "type de fond d'écran". Jamais utilisé, ceci dit.
Je confirme 1/ dans yast/sudo : tu donnes le droit à ton utilisateur d'exécuter la commande "machin" avec les droits root, sans mot de passe 2/ depuis une console, avec ton utilisateur, la commande "sudo machin" s'exécutera en root sans te demander de mot de passe
Attention, à utiliser avec prudence, donner des droits via "sudo" reste une dérogation à une règle de sécurité.
Dans ton cas, si effectivement tu as besoin de taper cette commande à chaque ouverture de session, j'irai probablement jusqu'à l'automatiser... Via les paramètres de ta session ("Configuration du système / Démarrage et arrêt / Démarrage automatique) tu peux ajouter l'exécution automatique d'une commande ou d'un script à l'ouverture de ta session.
Ben non, ça ne marche toujours pas... à la prochaine install de Suse, je choisirais que le user soit aussi le super-user... na !
Alors ça, c'est une TRES mauvaise idée ! A titre personnel, je suis tout à fait rassuré de ne jamais (ou quasiment jamais) être root. C'est une protection très efficace contre les erreurs !
Pas sûr d'avoir compris la question, mais s'il s'agit juste d'éviter de taper le mdp root, alors il est possible de configurer sudo (par ex. via Yast), pour y ajouter la commande (et ses paramètres) avec l'option "pas de mot de passe".
Via "Yast / Installer et supprimer des logiciels", puis le menu "Extras/Afficher l'historique", on doit pouvoir voir les paquets qui ont changé, classés par date. Après, je dis peut-être des bêtises : je ne sais pas s'il affiche dans ce menu les modifs faites par zypper dup (?)
Bon, pas mieux avec le rpm 3.20.9 trouvé via software.opensuse.org : même problème qu'avec la version récupérée via HP.
En revanche, j'ai fini par m'en sortir. A force d'essayer et de re-re-télécharger le plugin, j'ai fini par trouver où l'installeur (par ex hp-setup) l'enregistrait : un fichier hpxxx.run qu'il enregistre dans /home/[user]/.hplip Pendant une tentative d'install j'en ai fait une copie, avant qu'il ne vide tout le dossier à la fin de la procédure. En exécutant directement ce .run (après un chmod +x), j'ai enfin eu un message d'erreur cohérent : "missing : PyQt5". Sur ma machine, le package python3-qt5 était bien installé, mais pas la version pour python2.
Après install du package python2-qt5, exécution du script hpxxx.run,... "success".
