Cette espace vous permet de voir toutes les Sujets réalisées par ce membre. Vous ne pouvez voir que les Sujets réalisées dans les espaces auxquels vous avez accès.
Résumé des épisodes précédents : 1/ ça faisait plusieurs semaines que je n'avais pas mis à jour ma tumbleweed, alors je lance un classique "zypper dup". Un peu moins de 2000 paquets à mettre à jour, ça va je suis patient. Enfin je crois. Après reboot, ma session KDE/X11 ne fonctionne plus : je saisis mon mdp, j'ai le droit au logo KDE plasma avec un curseur de souris par dessus, mais c'est tout. Pas mon bureau. Pas grave je passe sur Wayland, ça fonctionne. Sauf que, j'ai régulièrement besoin d'enregistrer des petites vidéos de mon écran. J'ai testé plusieurs logiciels (voir ce post), aucun ne fonctionne correctement sous Wayland. Bon, c'est pas grave, ça doit être un problème de dépôt. Tranquille, snapper c'est fait pour ça.
2/ snapper rollback, je retrouve mon X11. Je vire tous les dépôts sauf openSuse et packman (pour éviter les 65 problèmes de paquets à changer de fournisseur). Re-zypper dup, re-problème X11
3/ re-snapper rollback. Je vire tous les dépôts sauf openSUSE, re-re-zypper dup, j'accepte les 65 changements de fournisseur. re-re-problème X11.
4/re-re-snapper rollback. Et me voici revenu au départ. Alors maintenant je fais quoi ?
D'abord, je râle . C'est assez rare avec openSuse pour être mentionné : j'ai perdu des données. Toute ma conf Firefox a foutu le camp (favoris, plugins, etc) : après l'étape 1 j'ai ouvert un Firefox récent. Après rollback... un Firefox plus ancien m'a réinitialisé ma conf. Bon, voilà, j'ai râlé.
Et après ? En général dans ce cas j'attends quelques jours et je recommence, mais bon, là je reconnais que je ne suis pas si patient que ça. C'est bien gentil les "zypper dup / snapper rollback", mais ça prend pas 5 minutes à chaque fois.
Plus de son, je soupçonne un problème matériel. Je n'utilise que rarement un casque sur ma machine. Il y a quelques jours j'en ai connecté un (jack) sans souci. Mais depuis que je l'ai retiré, je n'ai plus de son dans mes haut-parleurs. La fenêtre de configuration du système / son m'indique que la sortie active est "casque", le micro actif est aussi celui du casque. Les haut-parleurs apparaissent bien, mais "indisponible". Idem avec pavuControl. Depuis cette fenêtre de configuration, j'arrive néanmoins à sortir quelque chose dans mes haut-parleurs, en les sélectionnant puis en cliquant sur le bouton "Test", les sons de tests sortent bien. Mais rien à faire pour réactiver ces haut-parleurs.
Je suppose que c'est le matériel qui détecte en permanence qu'un casque est connecté. Casque rebranché/débranché plusieurs fois, reboot plusieurs fois, rien n'y fait. Je ne sais pas s'il est possible de faire quelque chose au niveau soft... Une idée ?
j'utilise depuis pas mal de temps "SimpleScreenRecorder", que je trouve très pratique pour faire rapidement un petit enregistrement vidéo d'une zone de mon écran. Depuis assez récemment, et suite à des mises à jour de Tumbleweed, je n'arrive plus à le faire fonctionner. Il m'indique que le codec H.264 n'est pas installé. Pas content, parce que ça a toujours bien marché ce truc, et j'ai bien un paquet libopenH264-7 installé
J'ai eu récemment des soucis également avec VLC, du coup j'ai pas mal jardiné entre les dépôts opensuse/packman/videolan.org, et VLC est rentré dans l'ordre. Mais SimpleScreenRecorder râle toujours après H.264. Après avoir pas mal cherché s'il ne me manquait pas un paquet quelque part, je ne sais plus trop où donner de la tête.
Quelqu'un connaît une solution simple pour faire des petits enregistrements vidéo d'une zone de l'écran ? (que ça soit avec SimpleScreenRecorder ou n'importe quoi d'autre)
Edit : oublié de préciser ce que j'avais déjà testé - deepin-screen-recorder : ça commence très bien, propose des options intéressantes. Quand on arrête l'enregistrement ça crée un dossier dans ~/Vidéos. Tout irait bien... si le dossier ne restait pas vide ! (possible problème de codec ?) - simplescreenrecorder : ne permet que d'enregistrer tout l'écran, pas juste une zone
j'ai une VM FreeBSD 14.0 qui tourne depuis un moment sur QEMU/KVM dans ma tumbleweed. Machine virtuelle créée avec le "gestionnaire de machines virtuelles", et qui d'habitude fonctionne très bien. Ça fait plusieurs semaines que je ne l'avais pas allumée, et là je n'ai plus de réseau dans la VM. Au démarrage de FreeBSD j'ai des échecs répétés du dhcp discover, avec une erreur
Peut-être dû à une mise à jour de tumbleweed? J'ai du mal à voir une autre explication, puisque tout fonctionnait bien jusqu'ici. J'ai essayé de recréer une VM FreeBSD from scratch, mais le problème persiste : l'installer de FreeBSD ne trouve pas le réseau.
Ce qui m'étonne c'est que je n'ai pas le même problème sur une autre VM Kubuntu 24.04.
Configuration du réseau de la VM : config par défaut, c'est-à-dire "réseau virtuel NAT" et "périphérique : virtio"
Je vais me lancer dans la remise à niveau d'une vieille machine, avec en particulier les 2 disques : migration vers des disques + gros. J'ai déjà joué à ce jeu-là il y a un paquet d'années, donc je pense que je pourrai m'en sortir, mais si vous avez quelques conseils à me donner je suis preneur
1. disque dur de données /home en ext4 L'objectif est clair : transférer toutes les données de l'ancien disque au nouveau, à l'identique. Je pense conserver un format ext4, sauf si vous me dites qu'il y a mieux à faire (XFS ?). Pas de btrfs pour ce disque là. Je vois 2 manières de faire : - copie des données : installer le nouveau disque dans la machine, le formatter, le monter en /home2, lancer une bonne vieille copie de toutes les données de /home vers /home2 avec rsync. Puis éditer /etc/fstab pour supprimer l'ancien disque et monter le nouveau sur /home. Inconvénient de la méthode : je ne suis pas sûr du tout des options à passer à rsync pour conserver toute la structure de données (les liens symboliques, les permissions, etc) - copie binaire : cloner brutalement l'ancien disque sur le nouveau avec dd, puis étendre la taille de la partition sur le nouveau disque. Inconvénient : un dd ça clone tout, y compris l'UUID du disque... Déjà joué et déjà eu des conflits de montage de disque, c'est pas si trivial que ça : à faire dans un environnement où /home n'est pas monté. Et après faut réussir à modifier l'UUID de l'ancien disque, puisque je veux le recycler comme disque externe dans 1 boîtier USB.
2. disque système /, SSD en btrfs Là encore je vois 2 options, aucune des 2 n'étant idéale - cloner avec dd puis étendre la partition. Beaucoup plus facile à dire qu'à faire avec btrfs, j'ai le souvenir d'avoir vraiment ramé la dernière fois. Pas sûr de vouloir rejouer - j'oublie le transfert de données et je repars sur une fresh install de ma Tumbleweed. Avantage : ça fait un peu de ménage, inconvénient : pas mal de boulot pour tout réinstaller/reconfigurer.
J'essaie de contribuer à un projet open source, et je tombe sur un problème d'affichage que je ne reproduis que sur tumbleweed . En clair, j'ai certains textes dans des boîtes de dialogue qui sont tronqués.
Auriez-vous déjà vu ça sur d'autres applis en java ?
Voir une copie d'écran sur cette page, le texte du premier bouton radio est tronqué (il manque une lettre). Sur tumbleweed le calcul de la largeur de la chaîne de caractères par eclipse SWT est clairement erroné... Ça ressemble à un problème d'intégration entre eclipse SWT et tumbleweed : avec exactement le même build, je ne reproduis le problème ni sur Ubuntu, ni même sur Leap 15.4
Je sais bien qu'une rolling release est parfois subjecte à quelques comportements approximatifs, et qu'en général ça ne dure pas, mais là je dois admettre que je suis vraiment démuni, je ne sais pas par où attaquer !
Salux Avis aux guitaristes amateurs : Tuxguitar c'est trop bien . J'aurais tout de même apprécié une petite amélioration sur un point précis, mais comme on n'est jamais à l'abri d'une bonne surprise j'ai constaté que j'étais capable de l'implémenter. La question se pose donc naturellement : pourquoi ne pas contribuer ? Après avoir creusé un peu, le tableau n'est pas très rose. Le source de la dernière version (1.5.6) a plus d'un an, le site web a disparu et le développeur ne répond plus (après plus de 15 ans tout de même !). Bon, ça bouge un peu sur Github, espérons qu'un fork va émerger. Mais là n'est pas ma question. Ma tumbleweed me propose une v1.5.4, qui date de 2020 ! C'est bien dommage, la dernière version apporte de vraies améliorations. Donc... le rpm n'est plus maintenu non plus ? Dans le source j'ai bien trouvé des scripts pour packager un .deb, mais rien pour rpm ceci explique peut-être cela.
La question, la voilà : reprendre la maintenance d'un rpm, c'est compliqué ?? - côté charge de travail ça ne devrait pas être trop lourd, au moins tant que le dev est à l'arrêt ! - techniquement : y'a des tutos, ça devrait se faire. Probablement une vraie difficulté à être exhaustif sur les dépendances. Et comment tester ? - juridiquement : comment être sûr que le soft qu'on package est OK vis-à-vis des licences ? Quelle responsabilité pour celui qui package ? - et après : faire un rpm c'est pour qu'il finisse dans un dépôt officiel, correctement signé, sinon ça ne sert à rien. Là je suis dans le brouillard complet ! Pas trivial, mais bon, franchement, Tuxguitar est un trop beau projet pour rester sur le bord de la route, du coup je reconnais être tenté par l'aventure.
dernier petit joujou en date pour bidouilleur du dimanche : un petit oscillo de poche. Premiers tests ce week-end, ça marche plutôt pas mal pour l'usage basique que je compte en faire. Le machin est capable de stocker sur son disque interne (ouaouh, 8Mo !!) les mesures faites. En théorie il devrait même pouvoir les ressortir vers un PC. Pas trouvé grand-chose sur cette capacité d'export de fichier, mais d'après les rares trucs que j'ai pu lire, sans windows10 point de salut
Donc pas beaucoup d'espoir, mais comme je sais qu'il y a des gens compétents ici je tente tout de même ma chance... Une idée de possible bidouille pour réussir à monter ce disque sous TW ? Sais pas exactement ce que c'est comme mémoire, c'est un STM32 qui gère l'interface usb. Ci-dessous les erreurs remontées par dmesg à la connexion usb du machin :
Sujet résolu, mentionné ici juste au cas où je ne serais pas le seul. Depuis un zypper dup assez récent sur Tumbleweed, j'ai systématiquement un délai d'extinction particulièrement long. Avec un message "A stop job is running for system logging service" qui tourne jusqu'à échéance de la temporisation : 1 min 30, c'est long !
Quelques infos ici : bug côté rsyslog. Résolu de mon côté comme mentionné par le lien ci-dessus : désinstallation de rsyslog (ce qui a installé syslog-ng par le jeu des dépendances). Un rapport de bug a été créé, on peut espérer une correction par une prochaine mise à jour
Salut à tous. Quelqu'un saurait-il m'expliquer comment fonctionne la config DNS ? Depuis quelques jours plus de connexion Internet via ma box . En attendant je passe par la 4G de mon téléphone portable. J'ai 2 machines sous Leap 15.3, avec KDE et Network manager. Sur la première ça fonctionne nickel... sur la seconde pas du tout. En regardant de plus près c'est la config DNS qui foire. Sur la seconde machine, quelle que soit la connexion (box/téléphone), toutes les requêtes DNS partent vers l'adresse IP de la box. Et donc quand je suis connecté sur le téléphone, aucune réponse aux requêtes DNS, impossible de se connecter à quoi que ce soit sur le net.
Sur ma première machine, quand je me connecte alternativement sur ma box et sur mon portable, je vois le fichier "/etc/resolv.conf" qui se met à jour, et qui prend comme serveur DNS soit la box, soit le téléphone. Sur la seconde machine, ce même fichier reste toujours inchangé quelle que soit la connexion.
En cherchant encore un peu, je finis par taper (en root) la commande "netconfig update -f", et ça se met à fonctionner normalement : à chaque changement de connexion box/téléphone, l'adresse du serveur DNS se met à jour dans /etc/resolv.conf. Connectivité internet OK Je pensais bien avoir résolu le problème, mais après reboot retour à la case départ Moi je veux bien re-taper cette commande après chaque démarrage, mais je ne suis pas le seul utilisateur de cette machine... Et tout de même, j'aimerais comprendre !
Tentative de mise à jour Leap 15.3, et échec du fait d'une dépendance non résolue : yast2-them-oxygen 4.3.8 requiert yast2-branding 4.3.8 qui ne peut pas être fourni. Problème présent depuis quelques jours.
Bon, je veux bien croire que le thème "oxygen" ne soit plus maintenu (à supposer que cela soit l'explication?), mais est-ce que pour autant je peux supprimer le package "yast2-them-oxygen" ? Ca devrait résoudre le problème de dépendance. Sur le fond ça ne me dérange pas, et au moins ça débloquerait les mises à jour. Je précise qu'il s'agit d'une machine familiale, donc multi-utilisateurs, et que je ne sais pas comment chacun a configuré son thème... Et j'aimerais si possible éviter que certains utilisateurs aient une surprise désagréable à l'ouverture de session ! Que pourrait-il se passer si le thème sélectionné n'est plus installé ? Par ailleurs, suis-je le seul à avoir le problème ?
Upgrade de 15.2 à 15.3 avec zypper dup... plus de connexion réseau. Mais alors plus du tout. Pas de wifi, ça encore je veux bien, c'est un vieux portable il faut probablement retrouver le driver. Mais plus de connexion Ethernet filaire non plus ?! Tout le ''zypper dup' (quelques Go) est pourtant passé par là.
Là, ça m'a laissé perplexe pendant un bon moment. Parce qu'une machine déconnectée de tout, c'est assez délicat à manoeuvrer. J'ai fini par m'en sortir avec :
Une fois reconnecté, pas bien difficile de retrouver ses petits et le bon paquet pour le wifi. Mais je n'arrive toujours pas à comprendre pourquoi ce module ne se monte plus tout seul... En pratique je n'utilise cette machine qu'en wifi, donc pas bien gênant, mais tout de même j'aimerais comprendre ?!
Aujourd'hui, je reviens sur ma machine en Leap 15.2, mise à jour 15.3, et re-re-problème d'install de plugin
Et à chaque fois des erreurs différentes. Ça commence à être fatigant !
Après passage de 15.2 à 15.3 (zypper dup), je ne sais pas pourquoi mais hplip n'était plus installé. Je le réinstalle, l'imprimante revient. Mais pas le scanner, qui me réclame toujours ce fichu plugin. Quand j'essaie de l'installer avec 'hp-plugin', il plante. Cette fois-ci, la dernière erreur affichée est : PermissionError: [Errno 13] Permission non accordée: '/bin/sh'
Pourtant, je ne vois pas de pb de permission. En suivant les liens symboliques:
Il n'y a pas si longtemps que ça (1 ou 2 semaines) mon scanner réseau HP fonctionnait encore sans problème avec Xsane. Comme cela arrive parfois après des mises à jour, lorsque je lance Xsane il me demande d'installer un plugin... mais cette fois-ci l'installation foire avec un message peu éloquent, du genre "ça marche pas".
Je sais que lorsqu'il télécharge ce plugin il le range dans /home/[user]/.hplip. En l'occurrence : hplip-3.20.11-plugin.run En faisant une copie du plugin avant que celui-ci ne soit supprimé, j'arrive à le lancer à la main et à avoir un message d'erreur plus clair, bien que très suprenant : "Error importing HPLIP modules. Is HPLIP installed?"
Ben oui il est installé, hplip... en version 3.20.11-2.5 d'après Yast. Ca semble cohérent.
J'ai essayé de télécharger la dernière version depuis le site de HP, mais il m'informe que tumbleweed n'est pas supporté.
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