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.
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.
thierry@thinkpad-tw:~> sudo zypper packages --orphaned [sudo] Mot de passe de thierry : Chargement des données du dépôt... Lecture des paquets installés... S | Repos-> | Name | Version | Arch ---+---------+------------------------+-----------+------------- i+ | @System | cnijfilter2 | 5.20-1 | x86_64 i | @System | jupyter-jupyterlab-rtc | 0.8.0-1.2 | noarch
jupyter-jupyterlab-rtc 0.8.O-1.2 et d'un autre côté python310-jupyter-collaboration 0.8.O-1.2 verrouillé. On dirait bien que le premier bloque. Mais essayer de le virer?
thierry@thinkpad-tw:~> sudo zypper remove jupyter-jupyterlab-rtc [sudo] Mot de passe de thierry : Lecture des paquets installés... Résolution des dépendances des paquets...
Les 2 paquets suivants vont être SUPPRIMÉS : jupyter-jupyterlab-rtc python310-jupyter-collaboration
2 paquets à supprimer. Après l'opération, 67,1 KiB d'espace disque sera libéré. Continuer ? [o/n/v/...? affiche toutes les options] (o):
J'ai essayé de répondre logiquement afin de provoquer une montée en version du reste mais d'autres questions surgissant après coup sur un zypper dup, je me suis réfugié frileusement dans un snapshot. Là je ne bouge plus pour ce soir.
Sur les conseils du forum officiel en espagnol, j'ai donc choisi la solution 2 (conserver le paquet obsolète) et j'ai ensuite eu deux autres questions similaires auxquelles j'ai répondu de la même façon.
Les majs passent à présent et j'ai donc à présent trois paquets dit verrouillés : python310-jupyter-collaboration, python310-y-py, python310-ypy-websocket.
À priori pour ne pas buter ultérieurement sur les mêmes questions lors des majs et si le problème n'est pas réglé rapidement, il faudrait protéger ces paquets (je vois comment faire dans Yast). Par contre je ne comprends pas la logique. S'ils sont protégés qu'adviendra t-il d'eux en cas d'une mise à jour qui réglerait le problème?
2 problèmes : Problème : rien ne fournit '(python310-jupyter_ydoc >= 1.0.1 with python310-jupyter_ydoc < 2.0.0)' qui est nécessaire pour l'élément python310-jupyter-collaboration-1.0.0-1.1.noarch à installer 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
Problème : rien ne fournit '(python310-jupyter_ydoc >= 1.0.1 with python310-jupyter_ydoc < 2.0.0)' qui est nécessaire pour l'élément python310-jupyter-collaboration-1.0.0-1.1.noarch à installer Solution 1 : désinstallation de python310-jupyter-collaboration-0.8.0-1.2.noarch Solution 2 : conserver l'élément python310-jupyter-collaboration-0.8.0-1.2.noarch obsolète Solution 3 : casser python310-jupyter-collaboration-1.0.0-1.1.noarch en ignorant certaines de ses dépendances
Choisir une des solutions ci-dessus par son numéro ou bien sauter, recommencer ou annuler [1/2/3/s/r/a/d/?] (a):
Je ne vois rien à ce sujet sur le forum officiel mais un cas similaire a été signalé sur Reddit :
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
Solution 2 à nouveau?
Ou attendre encore?
Pour une fois Packman n'est pas en cause (désactivé au profit du nouveau dépôt de codecs sur mes deux ordis soit dit en passant).
Edit : Question également posée sur le forum officiel (section espagnol)... une première pour moi (on verra).