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.
Vous pouvez essayez en sélectionnant dans le menu "configuration ->son" et vérifier les sorties. Si vous utilisiez le casque, il est possible que la sortie par les hp soit désactivée.
C'est bien mon problème : la sortie hp apparaît indisponible dans "configuration->son", parce que ma machine croit en permanence qu'un casque est branché, même quand ça n'est pas le cas.
J'ai renoncé à jouer du tournevis, le connecteur jack est du mauvais côté de la carte mère, je ne suis pas super motivé par le démontage intégral (portable compact, pas trivial). Mais je confirme le problème matériel : petit nettoyage en douceur du jack, par l'extérieur, et j'ai retrouvé mes hp actifs... pendant au moins 10-20 secondes. Faux contact dans le connecteur sans aucun doute.
Ceci dit j'ai trouvé un contournement logiciel : en console, taper "alsamixer", F6 pour sélectionner la carte son, sélection de l'option "auto-mute" puis "disable". La sortie haut-parleurs apparaît toujours "indisponible" dans "configuration->son"... mais cette fois ils fonctionnent quand même.
Euh... Dans Yast je n'ai plus rien qui s'appelle "son". Le paquet "yast2-sound" n'existe plus, ceci explique peut-être cela. Je crains que la prochaine étape ne soit le tournevis.
Bon, je trouve quand meme cette fragmentation dommageable. Mais dans la vie comme chez Suze, il semblerait que la division devienne la règle :-(
Effectivement, en tant qu'utilisateur je trouve aussi cette fragmentation très pénible. J'ai cependant pris du recul depuis que je me suis retrouvé de l'autre côté du miroir : côté développeur. Depuis que j'ai repris le développement d'une appli open source, j'ai reçu des rapports de bugs : - sur une version particulière de Fedora, avec wayland (non reproductible avec x11) - sur une version particulière de Kubuntu (non reproductible sur la même version d'Ubuntu) - sur une version particulière de Mint - sur une version particulière d'Ubuntu - sur une autre distrib dont je ne connaissais même pas le nom (une distrib brésilienne de mémoire) - j'ai aussi eu un bug suite à une mise à jour de Tumbleweed J'en oublie sûrement. Et je vous passe les bugs spécifiques Android/Win/Mac/FreeBSD.
Qu'on le veuille ou non Linux est très fragmenté. Comment voulez-vous vous en sortir ? Est-ce réaliste de trouver un mainteneur dans chaque distro pour lui générer son paquet adapté ? Moi j'ai pas trouvé. En pratique c'est très compliqué de garantir une compatibilité avec tout ça. J'ai déjà installé 5 ou 6 VMs juste pour tester, c'est super lourd.
Moi j'aime bien les rpm dans les repo Tumbleweed, mais dans cette position-là on comprend un peu mieux le concept flatpak. Et même là j'ai eu des soucis, du coup je ne vous cache pas que je commence à songer sérieusement à livrer un appImage.
Bon, rassurez-vous quand même, mon app est bien dispo dans le repo Tumbleweed. C'est l'avantage de maîtriser le dev, au moins je peux maintenir le paquet moi-même pour ma distro!
Merci de la suggestion. Je n'ai pas de process pulseaudio qui tourne sur ma machine. En fait, je ne pense pas qu'arrêter/redémarrer un process puisse régler le problème, qui a survécu à plusieurs redémarrages complets de la machine. Il faudrait trouver un moyen de signifier au système son qu'il ne doit plus utiliser le casque.
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 ?
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 !
, merci OBS !