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.
La question est finalement de savoir quels services fournit au mieux le dépôt openH264 dans le domaine du multimédia, s'il suffit à certains utilisateurs et sinon comment ils peuvent éventuellement compléter avec Packman.
Je ne vois pas d'opposition entre ces deux dépôts, sauf qu'en utilisant les deux, la recette actuelle du changement de fournisseur en faveur de Packman, telle qu'elle est préconisée dans le guide non-officiel au chapitre Codecs Multimedia, et qui impacte des dépôts entiers, ne tient plus.
Reste encore l'utilisation des flatpaks pour ne pas dans certains cas devoir gérer finement l'utilisation complémentaire de Packman.
Avec la dernière mise à niveau TW (20230701), il y a une petite bizarrerie avec les consoles virtuelles.
Normalement les combinaisons de touches Ctrl+Alt+F1... à F6 permettent d'accéder aux consoles virtuelles tty1,..., tty6. Et pour retourner sur X (en mode graphique donc), il faut exécuter Ctrl+Alt+F7.
Cela ne fonctionne plus et pour revenir à X je dois faire Ctrl+Alt+F2
Merci pour l'info. J'ai fais l'upgrade sur ma première machine (une machine secondaire), je vais voir si ça me pose problème pour lire des vidéos ou pas.
Avec l'arrivée de Cisco OpenH264, le dépôt Pacman a t-il encore un intérêt?
Bonjour,
Personnellement j'ai fini par sauter le pas (suppression de Packman au profit du dépôt OpenH264) et je n'ai jusqu'à présent rencontré des soucis de lecture qu'avec des vidéos encodées en Xvid . Toutefois je pouvais les lire en installant VLC en flatpak. Comme ces vidéos, des films rippés que je ne regardais plus, m'encombraient plus qu'autre chose, je les ai supprimées et du coup le VLC des dépôts me suffit. Aucun problème par ailleurs pour lire des vidéos sur internet avec Firefox.
Ce n'est que mon expérience que je trouve très allégée à présent.
Non, c'est vraiment un choix qui affecte le processeur, la luminosité, etc. Sur Manjaro, je dois installer power-profiles-deamon, mais je ne trouve pas comment le faire sur openSUSE.
Bonsoir torxxl,
Il est vraiment utile de préciser quelle branche d'openSUSE tu utilises (Leap ou Tumbleweed?) et ça vaut aussi pour ton environnement de bureau (KDE, Gnome, autres ou rien). Soit tu le mentionnes une fois pour toute dans ta signature, soit tu l'indiques systématiquement dans l'ouverture d'un nouveau sujet réclamant une solution.
Cela évite de vaines recherches pour ceux qui veulent te venir en aide et des échanges interminables plein d'équivoques (power-profiles-daemon est d'ailleurs un bon exemple à ce sujet).
Je déduis de tes précédents sujets de discussion que tu utilises Tumbleweed et KDE-Plasma (encore que pour KDE-Plasma... c'était imaginable directement avec tes citations de Kubuntu et Manjaro).
Ou avec Yast-Software si tu veux faire avec une interface graphique. Peu importe, le paquet existe bien et fait ce que tu veux qu'il fasse en cliquant sur l'icône de la batterie. J'ai vérifié sur mon portable.
À noter : sur openSUSE Tumbleweed, power-profiles-daemon entre en conflit avec TLP (un autre gestionnaire d'alimentation). C'est l'un ou l'autre. Si tu installes power-profiles-daemon, tu devras accepter de désinstaller TLP si celui-ci était installé. Pas de dommage collatéral, c'est juste l'un ou l'autre. Moi j'ai TLP mais j'avoue ne pas avoir fouillé le sujet à fond (ça me gave un peu et TLP est censé être bien pour mon ThinkPad).
À noter aussi : je ne vois pas de paquet officiel pour power-profiles-daemon et pas davantage pour TLP destinés à Leap 15.5 quand je cherche ici : https://software.opensuse.org/explore
Je m'étonne d'ailleurs à ce sujet (mais Leap 15.5 est encore jeune).
D'où l'importance de préciser la branche sur laquelle on est.
power-profiles-daemon me rappelle une discussion d'il y a un an :
Je n'ai pas vu pour le bouton "rapporte un bogue" ou alors ça n'a rien à voir avec discover ?
Bonjour,
C'est une option quand Discover plante il me semble. S'il ne plante pas on ne voit rien.
Personnellement j'oublie Discover pour mettre à jour mon système (sur TW mais aussi sur Leap auparavant). Ceci dit Discover fonctionne bien chez moi pour le moment.
Je ne la connaissais pas et après m'être renseigné, elle peut être très utile... à condition de bien observer ce qui se passe lors d'un zypper dup (je dois être plus attentif).
Je te remercie déjà d'avoir vérifié la non-présence chez toi de tous ces paquets dépendants de jupyter-notebook (je fais court).
Non, je ne crois pas avoir été tenté à un seul moment de compiler un ou des paquets. Compiler? ma première expérience, concluante, remonte à OpenOffice 0.9.x dont il était question dans une revue papier alors que j'expérimentais Linux Mandrake je crois (sympa l'archive web); la dernière aurait pu être nécessaire quand j'essayais Salix récemment (même pas!). Entre-temps et depuis, rien de cet ordre il me semble (pourquoi?).
J'ai pris un peu de temps à te répondre car j'ai d'abord vérifié sur mon portable que la suppression et le nettoyage de Jupyter-notebook ne m'infligeait pas une punition et parce que j'ai découvert d'autres applications nouvelles pour moi dans les menus de mon installation : accerciser, ipython310, ipyhon311, ipython-qtconsole (celle-ci de mémoire mais c'était quelque chose comme ça). Présentes sur mes deux ordis avec TW.
Le nettoyage de Jupyter-notebook n'était déjà pas parfait (je me traînais encore d'autres trucs jupyter ).
Par contre, après avoir découvert les applications ipython qui ne me servent à rien à priori, je me suis à nouveau posé la question de faire le ménage (suppression et nettoyage).
ipython311 concentre tout ou presque : lui même et une foule d'outils, accerciser, jupyter-notebook (et ses "variantes" lab et nbclassic, ect). ipython310, lui même, d'autres outils et des restes de jupyter (tout ça en moins grand nombre sans être insignifiant).
Les dépendances réunies vont au moins chercher dans les 300 paquets à la louche.
Pas question que tu vérifies à nouveau. À tâtons, testant d'abord sur mon portable, j'ai décidé de tout virer sur mes deux installations de TW. Il me reste deux paquets au moins que je crois pouvoir virer : python310-y-py et python310-ypy-websocket. Pour l'instant tout semble bien fonctionner.
Je ne suis pas un fanatique du nettoyage mais je suis surpris, déjà par le conflit décrit à l'origine et par ces applications que je n'ai pas voulu installer.
Quand nous parlons de majs de TW, c'est un abus de langage. À chaque fois nous faisons des mises à niveau. Elles sont fréquentes (normal) mais se pourrait-il qu'en les faisant fréquemment, quotidiennement, on tire un jour une "mauvaise" carte? une mise à niveau pas catastrophique mais bizarre?
Il y a des interrogations récentes (pas sur TW en général) :
Non. Ma version de Firefox des dépôts : 114.0.1. TW 20230617 (je suis à jour). Désolé de ne pas pouvoir t'en dire plus dans l'immédiat car je suis sur une autre question avec TW.
C’est peut-être venu en dépendance d’un paquet que tu as supprimé ensuite. Tu peux les supprimer en console, tu auras la liste des paquets qui seront eux aussi supprimés et tu pourras dire non. C’est bizarre car il me semble que plus de personnes seraient touchés…
Tout est possible mais des applications entières, conséquentes, installées comme des dépendances d'un truc anodin que j'aurais pu installer? (rien de très compliqué chez moi même quand je m'aventure).
Quant à désinstaller, oui je peux à priori, facilement si je n'ajoute pas de nettoyer les dépendances (--clean-deps)... et là je réponds non c'est sûr.
Je viens de m'apercevoir que j'ai trois applications Jupyter Notebook dans la section Développement du menu KDE : Jupyter Lab, Jupyter NBClassic et Jupyter Notebook (et elles proviennent des dépôts officiels).
Je ne suis pas le seul à avoir fait récemment cette découverte surprenante :
L'intervenant sur ce forum n'est concerné que pour une seule installation de TW (sur deux) et moi sur mes deux ordis.
La désinstallation des applications Jupyter a eu un effet assez destructeur pour KDE chez lui. Moi je peux garder ces applications, elles ne me servent pas mais bon... bizarre quand même tout ça.
Tu as voulu tester les notebook jupyter peut-être ? Ce qui est dommage, c'est d'être allé chercher dans un dépôt externe, ça met le bazar. Tant mieux si tout semble fonctionner. Pour le coup, ça vaut le coup d'utiliser un conteneur, avec distrobox par exemple, pour faire l'installation dedans sans risque pour le système (enfin c'est mon avis)
Bonsoir,
Mais non! rien de tout ça! je ne sais même pas ce qu'est un notebook jupyter Je n'ai utilisé qu'un seul dépôt externe à une époque, c'était sur Leap et pour avoir la dernière version de darktable, ce qui est tout à fait inutile avec Tumbleweed qui bénéficie régulièrement des dernières versions dans les dépôts officiels.
Or j'ai eu le même problème sur deux ordis. Ma tour est une réinstallation relativement toute fraîche et pure de Tumbleweed après changement de son SSD. Sur mon ThinkPad, après avoir décidé d'abandonner Leap, j'avais procédé à une installation de Tumbleweed depuis rien.
Je me garde bien de tout bricolage avec des dépôts externes sur Tumbleweed si je peux l'éviter, et je l'ai toujours évité jusqu'à présent. Pour preuve j'ai même fini par virer Packman.
thierry@localhost:~> sudo zypper dup Chargement des données du dépôt... Lecture des paquets installés... Avertissement : Vous êtes sur le point d'exécuter une mise à niveau de distribution avec tous les dépôts activés. Assurez-vous que ces dépôts sont compatibles avant de continuer. Reportez-vous à 'man zypper' pour obtenir plus d'informations sur cette commande. Calcul de la mise à niveau de la distribution...
Problème : l'élément python310-jupyter-ydoc-0.2.4-1.2.noarch installé nécessite '(python310-y-py >= 0.5.3 with python310-y-py < 0.6.0)', mais cette exigence ne peut pas être remplie fournisseurs supprimés : python310-y-py-0.5.5-1.2.x86_64 Solution 1 : désinstallation de python310-jupyter-ydoc-0.2.4-1.2.noarch Solution 2 : conserver l'élément python310-y-py-0.5.5-1.2.x86_64 obsolète Solution 3 : casser python310-jupyter-ydoc-0.2.4-1.2.noarch en ignorant certaines de ses dépendances
Choisir une des solutions ci-dessus en tapant son numéro ou bien annuler en tapant 'a' [1/2/3/a/d/?] (a):
Solution 1 car il y a un candidat à la mise à jour de python310-y-py de version supérieure à la version 0.6.0 (candidat : 0.6.1-1.1). python 310-jupyter-ydoc bloque visiblement la maj. Je le vire.
Les 2 paquets suivants vont être mis à jour : python310-y-py python310-ypy-websocket
Le paquet suivant va être SUPPRIMÉ : python310-jupyter-ydoc
2 paquets à mettre à jour, 1 à supprimer. Taille de téléchargement totale : 553,0 KiB. Déjà en cache : 0 B. Après l'opération, 7,6 KiB d'espace disque sera libéré. Continuer ? [o/n/v/...? affiche toutes les options] (o):
thierry@localhost:~> zypper search -s python310-jupyter-collaboration python310-y-py python310-ypy-websocket Chargement des données du dépôt... Lecture des paquets installés...
S | Name | Type | Version | Arch | Repository ---+---------------------------------+--------+-----------+--------------+---------------------- | python310-jupyter-collaboration | paquet | 1.0.0-1.1 | noarch | Dépôt principal (OSS) i+ | python310-y-py | paquet | 0.6.1-1.1 | x86_64 | Dépôt principal (OSS) i+ | python310-ypy-websocket | paquet | 0.8.4-1.1 | noarch | Dépôt principal (OSS)
Du coup python310-jupyter-collaboration n'est plus installé chez moi. Je ne sais pas à quoi il peut être utile. Les deux autres le sont mais je ne sais pas davantage à quoi ils servent.
c'est là que tu dois répondre :