Cette espace vous permet de voir toutes les Voir les messages réalisées par ce membre. Vous ne pouvez voir que les Voir les messages réalisées dans les espaces auxquels vous avez accès.
je note pour la prochaine fois. Je viens de réussir à régler mon problème avec SimpleScreenRecorder... un peu lâchement je l'admets : un bon vieux retour en arrière de 3 mois avec un instantané btrfs, et une bonne remise à niveau avec zypper dup. Cette fois j'ai dû sélectionner les bonnes options pour régler quelques conflits entre dépôts, tout est rentré dans l'ordre.
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
Bon ben voilà, c'est souvent comme ça. On cherche, on cherche, on trouve pas, on finit par poster sur un forum. Mais bon, comme on est embêté, on continue à chercher un peu quand même. Et là, on trouve
Avis à ceux qui auraient le même souci : dans FreeBSD, ajouter la ligne suivante dans le fichier /boot/loader.conf
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"
Merci burn2 pour les suggestions. bon, je viens de trouver le temps de m'attaquer à la chose, et ben j'ai quand même un peu ramé mais c'est tout bon. Petit retour si ça peut intéresser quelqu'un qui voudrait se lancer dans la même aventure :
1. disque dur de données /home en ext4 première tentative : depuis un Linux live, copie binaire du disque avec dd (2 heures), puis tentative d'extension de la taille de la partition. Échec. Le format de la table de partition ne permettait pas de gérer des partitions > 2To deuxième tentative : depuis un Linux live, redéfinition à la mimine d'une table de partition GPT. Copie binaire de la partition (pas du disque). Re-2heures. A la fin de la manœuvre, je vois bien dans le partition manager une partition de 4To avec un taux d'occupation normal. Débranchement de l'ancien disque, reboot sur mon openSuse... qui ne voit que 1To (la taille du disque d'origine) troisième tentative : depuis un Linux live, repartitionnement, reformattage en ext4 et copie des données avec "rsync -a". Là, ça copie tous les fichiers un par un... pas loin de 6 heures. Puis j'ai remis le même UUID qu'avant (tune2fs -U), comme ça même pas besoin de retoucher au /etc/fstab. Faudra juste que je fasse attention à changer l'UUID de l'ancien disque avant de le mettre dans un boîtier USB. Sinon quand on branche, 2 disques avec le même UUID c'est mal ! (dans ce cas Linux remonte /home sur le disque externe, à la volée, ça fait tout drôle) Mais voila, c'est tout bon
2. disque système /, SSD en btrfs L'installer de TW m'a créé tout plein de subvolumes partout, je n'y comprends pas grand-chose. Et quand je ne comprends pas je n'aime pas jouer ! Alors là j'ai finalement opté pour une réinstall du système. Ça va très vite, ça marche très bien, mais je vais passer un peu de temps (au fur et à mesure) pour tout reconfigurer comme avant (essentiellement des install de paquets)
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'ai reboot et utilisé snapshot, dans Grub (3°ligne ); hou que c'est bien de retrouver Suse. (...) je fais un zypper dup en espérant que ça va tout arranger
Pas sûr de comprendre... Après un reboot comme ça c'est tout à fait normal que tu ne puisses plus faire un "zypper dup". Au grub quand on revient sur une ancienne snapshot, c'est juste pour une fois : ça reboot sur ton vieux système, mais en read-only. Il n'est donc pas possible de le mettre à jour. Une snapshot c'est une sauvegarde, ça ne doit pas pouvoir se modifier comme ça. Si tu veux restaurer cette ancienne snapshot et repartir de là une bonne fois pour toutes, après avoir booté dessus depuis grub il faut lancer un "snapper rollback" en root, puis rebooter (sur l'option par défaut du grub !). Là tu te retrouves sur ton bon vieux système, accessible read-write, et tu peux donc retenter un "zypper dup". Attention il est possible que ça te supprime tes snapshots postérieures à celle que tu as restaurée (pas sûr, me souviens plus, mais ça serait logique)
Bon, ben ça avance. Reprise complète de tous les patches, du fichier .spec, revue des dépendances de build, puis publication sur OBS. Pour l'instant le paquet a été accepté dans Java:Packages, c'est le projet de développement qui doit normalement déboucher sur Factory, et donc dans les dépôts officiels de tumbleweed. La v1.6.0 de TuxGuitar est maintenant visible dans les "paquets expérimentaux". Je ne sais pas pourquoi le "1-click install" ne fonctionne pas, mais le paquet, lui, fonctionne correctement
C'est que les sources ont pas mal changé, depuis la 1.5.4... Alors en pratique c'est pas si simple : il faut remettre à jour tous les patches (voir le lien ci-dessus), également le fichier .spec, et c'est pas trivial ! J'essaierai probablement un jour, mais pour l'instant le dev de l'appli ne me laisse pas beaucoup de temps pour ça. A suivre donc, mais pas tout de suite !
Salut, il est où et sous quel format le carnet d'adresses que tu veux importer ? Dans Thunderbird, avec le menu "Outils/CardBook" puis un clic-droit dans la colonne de gauche tu as un menu "Nouveau carnet d'adresses" qui te propose plusieurs options, notamment pour importer des trucs De mon côté j'ai réglé le problème en déployant un serveur OwnCloud sur un raspberry pi. Thunderbird se synchronise dessus (carnets d'adresses / agendas), tout comme mon smartphone. Un peu de boulot à mettre en place, mais du coup plus de problème en cas de réinstall, changement de téléphone, etc.
J'avais dit que je vous raconterais... Pour les anglophones, ce post devrait vous donner quelques infos plus détaillées. En bref, packager un rpm c'est techniquement pas très compliqué et y'a des tutos un peu partout. En mode bourrin il suffit te tout déployer dans /opt/monAppliAmoi et on arrive assez rapidement à un truc qui marche. Après, faire un rpm qui soit acceptable par une distro c'est toute une autre affaire. Il faut bien respecter les chemins où déployer les paquets, et surtout faire gaffe aux licences. Le packaging rpm de TuxGuitar actuellement présent dans OpenSuse télécharge TuxGuitar depuis SourceForge, et le patche tout partout avant de le compiler puis de construire le rpm. Deux exemples : - la banque de sons livrée dans le source de TuxGuitar n'a pas une super traçabilité, ni de licence claire. Pas acceptable par une distro officielle - le fait de dispatcher les libs un peu partout dans le filesystem impose de patcher le script de lancement pour ajouter des arguments à la ligne de commande java
J'avais commencé à regarder comment migrer le rpm actuel d'OpenSuse de TuxGuitar 1.5.4 à 1.5.6, c'est pas si évident. Et puis en pratique, j'ai tout mis de côté pour l'instant. Quitte à tenter un upgrade, est-ce vraiment utile sur une version 1.5.6 qui a déjà + d'1 an ?
Du coup, plutôt que de relancer la maintenance du paquet j'ai préféré investir du temps à relancer le développement de l'appli ! Et ça a pas mal avancé ces derniers mois. On vient de sortir une beta d'une future version 1.6.0, qui j'espère devrait devenir un jour la version "officielle" Pour les amateurs de guitare n'hésitez pas à y jeter un oeil, et à en parler autour de vous ! (lien de téléchargement) Pour la petite histoire, pour l'instant le .rpm livré est généré à partir d'un .deb par alien, et il fonctionne dans le mode bourrin décrit ci-dessus (tout dans /opt). J'ai bien réussi à produire un rpm similaire "à la main" avec rpmbuild, mais le mainteneur du repo github est sous Debian et pour l'instant c'est + simple de rester comme ça. On va avancer petit à petit !
Euh... c'est vrai que mon msg n'était pas super clair, désolé. Pas une super idée de répondre en 3min sur le trajet du bureau Et merci bcp pour ces infos. Du coup ça ne sert à rien de chercher + longtemps côté TuxGuitar. Je vais créer un rapport de bug chez opensuse. Merci !
salut, pas essayé sur Gnome (que je n'ai pas installé), mais essayé sur une session IceWM : problème identique. J'ai voulu essayer sur KDE/Wayland mais ça n'est pas testable l'appli se plante pour une autre raison
C'est vraiment bizarre... J'ai le problème depuis une mise à jour d'eclipse SWT. Anciennement l'appli utilisait la 4.6.1, la version actuelle étant la 4.27. Le problème apparaît en passant de 4.9 à 4.10. Mais uniquement sur TW J'ai du mal à croire à un bug eclipse, c'est un peu gros, comment un truc pareil (trivial à reproduire) pourrait rester présent aussi longtemps (de 4.10 à 4.27) ?
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 !
, merci OBS !
