Aller au contenu principal

Messages

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.

Messages - Chumi

241
Général / Re : Zypper dup (TW), conflit de paquets python
@chalu :

Bon, voilà ce que j'ai fait parce que tout ça est embêtant.

thierry@localhost:~> sudo zypper remove jupyter-jupyterlab-rtc
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):

Réponse oui

Ensuite :

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.

Réponse à la solution 1 :

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):

Réponse oui

Plus de blocage ensuite en faisant zypper dup.

Maintenant je vérifie un truc :

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.
242
Général / Re : Zypper dup (TW), conflit de paquets python
Bonsoir,
Serais-tu tombé sur un moment où les dépôts étaient mal synchronisés ??
Ces paquets semblent bien présents sur TW

Bonsoir,

Je ne sais pas mais voilà chez moi :

hierry@thinkpad-tw:~> 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
---+---------------------------------+--------+-----------+--------------+----------------------
i+ | python310-jupyter-collaboration | paquet | 0.8.0-1.2 | noarch       | (Paquets système)
v  | python310-jupyter-collaboration | paquet | 1.0.0-1.1 | noarch       | Dépôt principal (OSS)
i+ | python310-y-py                  | paquet | 0.5.5-1.2 | x86_64       | (Paquets système)
v  | python310-y-py                  | paquet | 0.6.1-1.1 | x86_64       | Dépôt principal (OSS)
i+ | python310-ypy-websocket         | paquet | 0.8.2-1.3 | noarch       | (Paquets système)
v  | python310-ypy-websocket         | paquet | 0.8.4-1.1 | noarch       | Dépôt principal (OSS)

On dirait donc que ça ne veut pas monter en version.

Mais je note aussi ceci du côté des paquets orphelins (cnijfilter2 c'est du local pour mon imprimante, on s'en fiche) :

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.
243
Général / Re : Zypper dup (TW), conflit de paquets python
La suite :

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?

Pour l'instant je ne protège pas. On verra bien.
244
Général / Zypper dup (TW), conflit de paquets python
Bonjour,

Depuis hier j'ai un conflit de paquets python quand je veux mettre à jour TW (sur deux ordis) :

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 :

https://www.reddit.com/r/openSUSE/comments/149ciiy/hey_guys_i_ran_into_my_first_zypper_package/

Suis-je le seul ici?

Je suis tenté par la solution 2 (conserver le paquet obsolète) mais elle entraîne ceci :

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).

245
Autres distributions GNU/Linux et BSD / Publication de Debian 12 "Bookworm"
Bonjour,

Comme toujours l'évènement de la publication d'une nouvelle Debian stable est saluée un peu partout mais il y a cette fois une nouveauté qui est particulièrement appréciée ou à défaut, soulignée : l'intégration de firmwares non-libres dans la distribution.

En pratique par exemple, pour une nouvelle installation de la distribution, cela signifie que dans certains cas, si l'utilisateur le souhaite, il ne lui sera plus nécessaire d'installer après-coup le firmware non libre de sa carte wifi, celle-ci devrait être immédiatement fonctionnelle.

N'étant pas un technicien, je vous renvoie vers quelques notes ou articles :

https://www.debian.org/News/2023/20230610
https://www.debian.org/vote/2022/vote_003
https://linuxfr.org/news/debian-12-le-debut-d-une-nouvelle-ere

J'ai un Dell E5400 sur lequel était installée Debian-Facile 11. J'ai procédé à la mise à niveau sans trop finasser en m'inspirant de la documentation de Debian-Facile et d'un fil de discussion du forum qui m'a aidé à ne pas rester bloqué avec le paquet libdvd-pkg récalcitrant.

Résultat : Tout roule, j'ai à présent une Debian 12 Xfce fonctionnelle dans le cadre d'une utilisation ordinaire. Mais je ne suis pas en phase avec ce que sera Debian-Facile 12 qui n'a pas encore été publiée (HandyMenu et docs à la traîne donc, et look ancien si celui-ci venait à être modifié). Enfin j'ai des paquets obsolètes que j'aimerais bien nettoyer mais certains me posent question.

J'aurais pu attendre la publication de Debian-Facile 12 et faire une nouvelle installation pour éprouver cette histoire avec les firmwares non libres (mon Dell est concerné pour le wifi) mais un,  j'avais un peu la flemme (plus tard qui sait?) et deux, je voulais me mettre dans la peau d'un utilisateur classique de Debian-Facile tenté par la mise à niveau.

Edit : la question des paquets obsolètes est résolue après une petite conversation sur le forum Debian-Facile.
246
Nouvelles du projet openSUSE / Re : Migration automatisée
... idem avec Displaycal qui offre une version dégradée par rapport à celle de Windows.

Bonsoir,

Nous avons déjà eu cette discussion lors de la sortie de Leap 15.4. Leap pas plus que Tumbleweed ne peuvent pas offrir une version plus dégradée de DisplayCal que l'ultime qui est disponible pour Windows (3.8.9.3) pour la simple raison qu'il n'existe plus de paquet officiel de DisplayCal pour openSUSE. Restent à notre disposition un flatpak de DisplayCal en version 3.8.9.3 (de même génération que celle de Windows donc) et actuellement une version 3.9.10 dans les dépôts communautaires et expérimentaux de Tumbleweed. Cette version 3.9.10 (3.9.11 à venir) est un portage de DisplayCal sur python 3.x  à l'initiative d'un développeur qui n'est pas le développeur original de DisplayCal.

Pour en savoir plus à ce sujet : https://ignace72.eu/displaycal-en-python-3.html

Personnellement je fais avec le flatpak pour le moment.
247
Nouvelles du projet openSUSE / Re : openSUSE LEAP va t'elle continuer au-delà de la 15.5?
 
Hallo,

finalement une version Leap 15.6 est prévue pour début juin 2024, sa fin de vie sera pour fin 2025. Elle sera une évolution mineure de Leap 15.5. Ceci pour laisser plus de temps au développement de la version suivante, elle basée sur l'ALP.

Bonsoir,

Donc je m'illusionnais sur une migration automatisée pour passer à ALP. Pas grave pour un futur proche, ou plus proche qu'ALP s'entend, 15.5 -> 15.6 automatisé, c'est toujours bon à prendre jusque fin 2025.
248
Général / Re : Tumbleweed pb de lecture vidéo avec firefox
çà déconne toujours mais bon y a rien de grave
j'ai bien coché les lecture drm dans firefox  :)

peut être Firefox qui bug ?

Bonjour,

Il n'y a pas de raison que ça fonctionne chez les autres et pas chez toi, et je ne crois pas que Firefox bugue.

Je soupçonne comme chalu que ça se bouscule au portillon du côté des codecs quand tu veux voir une vidéo sur Internet.

Tu as des dépôts en double et d'autres qui sont inutiles. Il serait bon de revenir à une situation initiale saine.

Comme je n'ai pas trop le temps là, dans un premier temps on peut voir si tu as installé quelque chose en provenance de Packman.

Que retourne la commande :

zypper se -sr packman
249
Général / Re : Re : Maj Tumbleweed et gstreamer-plugins-libav (packman)
@geko-suz : Bonjour. Pour une meilleure visibilité du problème que tu cherches à résoudre, crée un nouveau fil avec un titre explicite et précise si tu peux quelles sont les vidéos que tu ne ne peux pas voir (si tu as un exemple et un lien sous le coude pour illustrer). Enfin, dans ce nouveau fil, peux-tu nous donner la liste de tes dépôts avec la commande :

zypper lr
251
Matériel / Re : Lecture de DVD vidéo impossible
Concernant la version 15.5 de OpenSuse Leap, j'avais lu des rumeurs sur d'autre forum comme quoi la distribution Leap serait abandonnée à l'avenir
Avez vous des précisions sur le sujet ou est ce une fausse rumeurs ?

Bonjour,

Non ce n'est ni une fausse rumeur, ni une rumeur. En un mot, officiellement, Leap 15.5 ne connaîtra pas de nouvelles versions et Leap sera remplacée dans ce qui aurait du être sa version 16 par openSUSE ALP (Adaptable Linux Platform).

Une discussion sur Alionet à ce sujet : https://www.alionet.org/index.php?topic=1325.0

Edit : personnellement je ne suis plus vraiment le sujet et j'attends du concret (à mon niveau) avec la version finale de ce qui n'est qu'un prototype pour l'instant.
252
Général / Re : Linux bootable d'une clé USB
Bonsoir,

Un certain nombre de distributions propose de créer un live USB, pas seulement à des fins de tests (je ne crois pas que ce soit ton objectif) mais pour un usage courant avec la persistance des données.

Voici un tuto pour un Live Debian persistant : https://debian-facile.org/doc:install:deblive-usb-persistant

Je l'avais testé avec nakeDeb qui est une Debian (ultra minimaliste c'est tout... mais c'est chouette) et qui propose le même tuto dans son wiki, en y ajoutant toutefois la mention d'un programme permettant la création de volumes virtuels chiffrés, ce qui n'est peut-être pas superflu si la clé usb voyage beaucoup et risque donc d'être égarée (https://nakedeb.arpinux.org/nakedwiki.html#persistence).
253
Général / Re : Maj Tumbleweed et gstreamer-plugins-libav (packman)
@chalu : Moi j'ai la fibre et aucune contrainte professionnelle ou associative, alors la quantité de majs de TW est anecdotique pour moi et je peux prendre mon temps pour assimiler au besoin de supposées améliorations de mes logiciels préférés. Bien sûr qu'un allègement de la maintenance de TW serait profitable à bon nombre, au delà des nouveaux utilisateurs. Il faut juste que ce soit un peu vérifié... ou confronté à quelques cas personnels afin de mesurer l'importance de ceux-ci (XviD  ::) ), surtout s'il s'agit de populariser une nouvelle intégration des codecs.
254
Général / Re : Maj Tumbleweed et gstreamer-plugins-libav (packman)
Après pour les habitués d'openSUSE et du dépôt Packman, ce n'est pas un souci, ils savent comment réagir et où chercher une solution. C'est différent pour un nouvel utilisateur.

Oui, et la question est de savoir ce qui facilite et allège la maintenance de Tumbleweed pour un nouvel utilisateur. S'il existe un moyen, pourquoi pas non? Un moyen éprouvé, c'est aussi ça la question. D'où cette discussion en définitive. Et je note en plus que pas mal de nouveaux utilisateurs se branchent directement sur TW.