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.
ou alors la maison mère pense effectivement que le "open" de openSUSE est pénalisant pour l'association avec la marque SUSE (qui implicitement se retrouve avec une étiquette négative "close" quand on compare SUSE avec openSUSE)
sans parler des français qui ont un petit sourire en coin à cause de SUZE, ... (alors que la référence à la vénérable Suse Mésopotamienne échappe à tout le monde ou presque)
l'erreur a probablement été de choisir ce nom openSUSE quand la version communautaire a été créée. Yoman a fait remaquer que fedora n'avait pas grand chose à voir avec RedHat, et pour SUSE ils avaient sans doute voulu montrer par opposition que les liens étaient très forts avec la version communautaire, ... mais sans voir le piège du "open"
il me semble que comme tout le monde parle de "leap" ou de "tumbleweed" (ou de "slowroll"), la transition me semble déjà faite à moitié
le vrai problème selon moi est qu'ils décideront ensuite de couper l'accès aux repositories enterprise (des rpms gratos avec une signature "enterprise", c'est vraiment une très bonne affaire), et qu'il va se passer plus ou moins la même mayonnaise que dans le feuilleton Centos, ... ... sauf que là il n'y aura peut-être pas de chevalier blanc qui investira pour builder/héberger les binaires alignés sur les sources des versions enterprise avec une signature "pro" (comme pour Alma ou ... SUSE avec LibertyLinux)
si ils acceptent de payer l'hébergement pour avoir des repositories avec le build des sources enterprises mais avec une signature "leap", on s'en sortira pas mal au final
du moment qu'ils n'interdisent pas l'usage du gecko comme logo...
Ce topic me rappelle ... la même chose, mais "avant" (lien ci-dessous)
Perso, j'ai décidé qu'il fallait réserver le python du système aux outils fournis avec le système, et jouer avec avec la ou les versions de python ('pyenv' est parfait) nécessaires aux différents outils utilisateur, sans chercher à casser le python du système pour essayer de résoudre les turpitudes de la biodiversité des outils python (quelle créativité ces développeurs...)
Si vous ne l'avez pas encore essayé, le one-liner d'installation pour Calibre sur le site du développeur est parfait, quelle que soit la distrib (et sans utiliser flatpack)
Et si vous êtes tentés par une longue réponse avec plein de blabla dedans, ...
Ps: j'ai pas encore essayé la slowroll, et ça me semble une très bonne idée de freiner le côté systématique de la chaîne de build/valid (en théorie réserve aux développeurs) en y ajoutant un flag humain pour la promotion vers le côté public du repo
en effet c'est une colle, et je suis quand-même allé chercher au plus simple, à savoir regarder ce que recommande git lui-même en ce moment, et la réponse est surprenante...
et donc ma réponse la plus probable est : - tu as sans doute installé git "il y a un certain temps", - à cette époque, git-gui était "la référence" pour faire de la UI avec git (mais depuis, comment dire ? ...*), - et git-gui aurait donc été installé avec un '--recommends' "avant" ? - et depuis, il est mis à jour en silence puisqu'il est présent dans la liste des paquets installés ? - (j'ai vérifié sur mes machines et il est présent partout : pareil --> du coup je l'ai viré) - (et j'essayerai de voir qui le fait revenir, si il revient)
pas mieux
eric *à ce propos, je cherche des avis pour une UI de git sur linux qui serait "aussi" parfaite que tortoisehg pour mercurial (selon moi)
pour l'instant je reste toujours sur la faim car les UI disponibles sous linux proposent uniquement des fonctions basiques pour le B-A-BA de la vie de développeur, mais quand on veut faire de l'archéologie dans le "bazar" d'un repo git il faut des super pouvoirs que la plupart des UI ne traitent pas, ... ou alors partiellement (ex: GitAhead), ... ou alors on enrage car bien sûr ça existe sous windows mais ça ne se lance pas avec wine (caramba, encore raté)
bref, si vous avec une idée de perle rare, je prends
et sinon je peux vous partager mon README pour configurer la dernière version de gitExtensions (windows) développée avec la dernière version de .NET supportée par mono, ce qui est pour l'instant "le moins pire" selon moi (avec meld comme compagnon c'est presque parfait)
@loustic : oui, je connais la préconisation du développeur de Calibre. J'ai toujours associé celle-ci au manque de fraîcheur des versions proposées par telle ou telle distribution (c'est un logiciel très fréquemment mis à jour). Avant sur Debian (stable) je passais par les backports pour Calibre. Ceci dit Calibre a toujours bien fonctionné en passant par les dépôts, donc je ne m'inquiétais pas.
en fait, j'ai basculé sur la méthode du développeur le jour où j'ai tenté d'installer "en insistant" une version de Calibre "récente", en réalité "plus récente que celle du système" (c'était pour faire de la maintenance en local sur le host où se trouve ma collection Callibre, - donc : trop long par le réseau -, et pas de bol ce host méritait quelques 'zypper dup -releasever=X' pour rattraper son retard)
la version récente de Calibre tirait plein de dépendances introuvables et comme j'arrivais pas à tout trouver sur OBS j'ai essayé de faire le build moi-même des morceaux manquants, mais à la fin j'ai arrêté car je suis tombé su run paquet '-devel' qui m'obligeait à toucher au système, et il fallait faire une VM dédiée pour m'en sortir. galère.
et je suis tombé sur ce fameux one-liner qui a marché parfaitement...
si je savais comment fonctionne OBS, je me ferais un compte et mon premier commit serait pour wrapper le one-liner de Calibre ;-)
J’ai opté pour une installation de Lyx avec distrobox car sur Tumbleweed les mises à jour sont très fréquentes et ça fait souvent beaucoup de paquets.
j'ai aussi texlive sur mon host (pour faire du markdown->pandoc->pdflatex->pdf avec un résultat final propre, sinon le pdf fait peur), et c'est le high-score pour la décomposition extrème en petits paquets:
J’ai opté pour une installation de Lyx avec distrobox car sur Tumbleweed les mises à jour sont très fréquentes et ça fait souvent beaucoup de paquets. Ainsi je maintiens plus facilement le système principal. Mon problème est qu’avant d’adopté cette méthode, j’avais installé Lyx sur le système. Je pense l’avoir supprimé avec toutes ses dépendances et recommandés, il y a sans doute un autre paquet qui recommande texlive. Mais comme celui-ci était installé, ça ne m’a pas sauté aux yeux quand j’ai installé cet autre paquet.
je suis d'accord : le bundle c'est très pratique. ça vaut peut-être aussi le coup de tenter d'ajouter le repository d'un mainteneur sérieux de lyx avec une priorité plus grande, puis de fixer l'affinité de lyx et ses dépendances sur ce repo (vendor-change). avec un peu de chance, ce mainteneur n'est pas abonné sur la CI qui lance un build dès qu'un développeur fait un 'git push', le truc qui déclenche une rafale de nouveaux binaires disponibles (ce que malheureusement OBS doit être programmé à faire...)
les distributions homéostatiques comme tumbleweed ou arch, c'est "toujours à jour", mais comme il y a pas mal de développeurs opensource, ça bouge pas mal dans les mises à jour (c'est pour ça que je fonctionne avec leap + patch en dentelle pour les trucs en plus ou plus récents)
Je suis plutôt à la recherche d’une commande qui permettrait de savoir quels sont les paquets installés sur le système qui recommande un paquet nommé x.
et sinon, pour faire le ménage, ...
la database des paquets installés possède toutes les réponses (c'est un débat sans fin mais il me semble que 'rpm' gagne au niveau des options par rapport à 'dpkg'). il y a l'approche "UI avec yast" en jouant avec les checkbox sur la gauche, ou l'approche copier/coler dans le terminal (qui a l'avantage d'être scriptable)
pour voir les infos disponibles sur un paquet donné (infos présentes dans le rpmspec pour la création du paquet avec rpmbuild) :
rpm -q --provides <nom_de_paquet> --> donne les aliases utilisés dans la base pour les résolutions provides/requires rpm -q --requires <nom_de_paquet> --> les alias demandés (le truc qui fait que zypper choisit automatiquement X ou Y) rpm -q --recommends <nom_de_paquet> --> les alias suggérés, ... et sélectionnés
pour faire des recherches sur la base et chercher les coupables (exemple en partant de pdflatex) :
oui, je partage complètement l'avis général : les mainteneurs qui poussent via des "recommend" des trucs qui leur paraissent "évidents" par rapport à leurs conf perso, c'est une plaie (et les fans de Jupyter ou de haskell ou de latex ou des modules pythons ou etc... ne voient pas pourquoi ils font halluciner les non-développeurs). sans parler des mainteneurs qui gèrent sans finesse les dépendances dans leurs paquets en propageant dans leur rpmspec les versions de ce qu'ils ont en local sur leur machine de bidouille sans même tester sur un host propre avec les versions par défaut : je pense qu'ils ont la palme...
bref, comme chacun y va de ses astuces, je vais ajouter les miennes ;-)
1- (ignorez si vous n'utilisez pas Calibre) petite parenthèse pour Calibre : , la recommandation officielle pour installer ... est de ne pas utiliser les versions disponibles dans les distros :
Citer
Merci de ne pas utiliser le paquet calibre fourni par votre distribution, ceux-ci sont souvent problématiques/obsolètes. Utilisez plutôt l'installation des binaires décrite ci-dessous.
c'est un peu comme utiliser un snap, mais sans snap, en utilisant directement avec la méthode du développeur/mainteneur (qui maîtrise), et en lançant sa méthode one-liner marche du premier coup
2- (ignorez si vous ne faîtes pas de bricolages python) le sujet "la version de python du système est trop vieille" est sans fin : - j'ai quelques exemples de collègues qui ont fini par casser le système lui-même en voulant modifier le python du système pour essayer de le plier à leurs besoins "user", - le "pip --user" en utilisant le python système ne résoud rien aux besoins "user" en général, - oser demander aux mainteneurs de la distro (stable) de mettre à jour le python système afin de pour pouvoir installer le dernier truc instable à la mode qui tire des dépendances délirantes, c'est plutôt le monde à l'envers, - etc...
bref, j'ai définitivement arrêté d'ajouter les modules python "demandés par les gentils outils de dev que l'on doit installer en permance" en allant à la pêche avec zypper et en complétant avec pip, car au final il y a une pollution inutile du python système
"moins il y a de paquets pythons installés avec zypper et mieux c'est"
ma solution préférée est d'utiliser 'pyenv' pour gérer ma collection de versions de python, sur lesquelles je viens ajouter des modules exotiques avec pip une fois la version choisie grâce à pyenv. c'est un peu dans le même style que 'rustup' pour gérer plein de versions de rust en parallèle, et surtout : en mode light par rapport à anaconda ou jupyter
il suffit de mettre ces lignes à la fin du .profile/bashrc/etc, et de switcher dans un des contextes python en stock avec "pyenv VERSION" (éventuellement en mettant la commande au début du script qui lance tel ou tel outil qui a besoin de sa version de python)
mais pour faire des tests pour valider qu'un dev python fonctionnera (ou pas) avec les N versions de python potentiellment installées chez tous les utilisateurs, c'est très cool
# let PYENV be the default method to manage multiple version of python in a NON-SYSTEM context PYENV_ROOT="$HOME/.pyenv" export PYENV_ROOT command -v pyenv >/dev/null || PATH="$PYENV_ROOT/bin:$PATH" && export PATH eval "` pyenv init - `"
3- comme je suis développeur dans la journée et bricoleur à mes heures perdues, j'ai en local sur mes machines une collection "confortable" de 65 repositories qui s'empilent avec des priorités, au dessus (ou au dessous) des repositories de référence, car j'ai souvent besoin d'installer des paquets non-standards sélectionnés par-ci/par-là (je vais à la pêche sur OBS et en général je trouve tout sans avoir besoin de passer par snap ou équivalent), ou tout simplement des version plus sympatiques .que les repositories de référence (ex: KVM/libvirt)
comme ces paquets proviennent de N développeurs/mainteneurs qui bossent chacun dans leur coin, - chacun avec sa conf locale qui lui semble évidente -, c'est un bazar sans fin avec les mises à jour délirantes et/ou les conflits insolubles si on n'a pas les super-pouvoirs de la libzypp à portée de main
l'idée de sélectionner "la pépite dans chacun de ces repos, et d'essayer de tirer uniquement les grappes des dépendances dont ils ont vraiment besoin, en mode "dentelle", grâce aux priorités des repositories, et surtout grâce aux affinités gérées par la libzypp
et surtout avec le solveur de la libzypp qui détecte les problèmes avant la cata, qui propose des solution de repli avec changement d'affinité de tel ou tel paquet sur un autre repo ("vendor-change"), itérativement jusqu'à ce que ça marche, et surtout sans rien casser tant qu'on n'a pas fait YES à la fin. pour info j'ai définitivement arrêté debian après avoir réussi à faire planter dpkg (ie: perdre la base des paquets installés) en tentant une mise à jour avec stable/testing/unstable simultanés, en pensant que la gestion des versions ferait le job même si les mainteneurs étaient "légers"...
bref, zypper, zypper, et re-zypper
j'ai donc fini par converger vers une méthode un peu non-conventionnelle pour faire mes mises-à jour "de base" (quand le p'tit windget des updates faciles dans le tray est perdu)
"control-R zypper" me fait ressortir tout de suite de l'historique la ligne à rallonge toute prête qui fait tout du sol au plafond et qui permet de faire sortir immédiatement le solveur au moindre doute dans la jungle des repositories (et des mainteneurs) :
le temps de calcul du solver n'est pas long (par rapport au temps du refresh de 65 repositories...), et c'est toujours bon du premier coup, car au lieu de faire un update simple qui va faire sortir le solver pour essayer de résoudre itérativement sans trop savoir dans quelle direction on part, le résumé affiché par le dup propose directement le résumé de ce qu'il faudrait faire pour arriver à une nouvelle situation stable
une revue rapide pour détecter un gros loup éventuel (du genre 2000 fichiers et là je creuse), mais sinon c'est OK direct car en général c'est parfait
j'ai des zones de priorité pour les repositories en fonction des types de softs, en laissant les trucs plus stables fournir un socle de référence et en permettant aux trucs les plus volatiles de vivre plus vite (valeur de prio inférieure) plus prioritaire (~90) - média (pacman, vlc, codecs, etc) - langages de dev - outils de productivité (git, mercurial, edit, debug) - réseau (mozilla, davmail, samba) - kde/Qt (au cas par cas, en faisant super gaffe, et avec "disable + le dup magique" pour réparer au cas où) - système (filesystems, vitualisation, monitoring) - [les repos opensuse leap et SLE de référence] - kernel latest (pour aller à la pêche aux modules propriétaires récents sans tirer un kernel par jour) - les trucs expérimentaux en mode ça passe ou ça casse (si le solveur s'affole je n'installe pas et je retourne à la pêche chez OBS) moins prioritaire (~110)
en général je partage ces trucs avec mes collègues locaux, mais là c'est un post public pour de vrai, et donc j'ai hâte de lire vos retours
quand je pense que je me fais gentillement traiter de dinosaure par mes (jeunes) collègues de boulot car je fais plein de trucs bizarres et que je suis né en ... 1965, ça aide à relativiser ;-)
oui, en ajoutant tumbleweed, on a effectivement le risque de tirer la glibc de TW si on clique sans vérifier ce qui va être installé dans l'onglet "install summary" (ça se rattrape mais ça peut être chaud si on n'aime pas la ligne de commande...)
mais ce n'est pas senser arriver si le repo TW est en prio inférieure et si on n'ajoute pas des paquets de repos "contrib" qui possèdent des dépendances cachées sur TW (ajoutées par erreur en faisant le .spec car ça marchait sur le host du mainteneur et il n'a pas fait gaffe)
si tu as une astuce pour ne pas prendre les mises a jour kernel du repo kernel_stable, je prends ;-)...
c'est un pb classique avec le hardware récent : la leap 15.2 est "stable", et donc elle ne prend pas en compte ce qui a été validé "après", ... mais on peut quand-même tenter l'astuce suivante (comme le dit manchette ci-dessus)
1- ajouter le repo kernel latest ci-dessus avec une priorité inférieure (ex: 110) 2- dans yast2, sélectionner *dans ce repo* kernel-firmware (et éventuellement les micro-codes intel et amd) --> il suffit d'aller dans l'onglet "versions" et de cliquer sur la bonne ligne NOTE: compare la date avec le paquet de la leap-15.2 officiel, il y a en général un an d'écart NOTE: désormais yast2 mémorise l'afinité pour ce(s) paquet(s) et il en fera les mises à jour depuis ce repo 3- rebooter 4- si le kernel officiel de la leap-15.2 n'arrive pas à charger les firmwares, aller chercher un kernel plus récent sur le même principe (en évitant celui de kernel stable car il change tout le temps) 5- ajouter le repo tumbleweed avec une priorité inférieure (ex: 110) 6- dans yast2, sélectionner *dans ce repo* kernel-default --> il suffit d'aller dans l'onglet "versions" et de cliquer sur la bonne ligne NOTE: désormais yast2 mémorise l'afinité pour ce(s) paquet(s) et il en fera les mises à jour depuis ce repo NOTE: en profiter pour faire du ménage car kernel-default est un paquet multi-versions et il y a souvent plein de vieilleries IMPORTANT: toujours conserver le dernier kernel-default de la leap-15.2 , pour pouvoir booter dessus avec grub (on ne sait jamais ) 7- rebooter 8- et depuis que je fais ça je n'ai plus jamais joué à recompiler des kernels....
question simple, pour confirmer que ton message d'erreur initial "classique" porte bien sur "Require local" et que ce n'est pas un effet de bord, car "Require" est un truc bateau de chez bateau : https://httpd.apache.org/docs/2.4/howto/access.html
d'après la doc, ce type de directives est portée par deux modules : "Access control can be done by several different modules. The most important of these are mod_authz_core and mod_authz_host. "
et si ces modules ne sont pas chargés par httpd.conf avant d'en utiliser les directives, alors la partie générique de apache-core va juste dire qu'il n'a jamais entendu parler de ces mots clés bizarres et donc il va s'arrêter direct
peux-tu vérifier que tu as bien des lignes 'LoadModule' correspondantes (et non commentées) si tu suis le jeu des includes dans /etc/apache2/httpd.conf ? (chez moi ils sont bien présents et non commentés dans /etc/apache2/loadmodule.conf, qui est chargé au début du fichier httpd.conf)
il y a peut-être un effet indirect avec ton paquet php-8, car "le script d'install de php-8 bricole les fichiers de conf apache2", et chez le mainteneur ça marche, mais comme il n'a pas le même conf que toi, alors pas de bol sur ton host ça se passe mal ?
si les modules sont chargés (et donc que les keywords sont connus par apache-core), alors ton erreur est un effet de bord, et la vraie erreur est ailleurs...
je te conseille en premier de lancer 'ldd' sur tous les modules mod_*.so, pour voir si il n'y en aurait pas un à qui il manquerait des dépendances au link, et donc ça serait une erreur indirecte remontée par apache-core en mode panique (en utilisant la directive X du module Y, ca a merdé et donc j'affiche une erreur Z). toujours la même idée : le host de build a tiré une dépendance sur une version de lib plus récente que sur ta machine, mais comme le mainteneur a oublié d'en tenir compte dans les dépendances du paquet, ... alors la mise à jour de la dépendance sur ton host n'a pas été vue quand tu as installé ce paquet php-8 (en clair ton install ne peut pas marcher car les binaires sont "dans le futur" par rapport à ta config)
si la chasse aux binaires ne suffit pas, je te conseille de mettre le httpd.conf original de côté et d'en construire un à toi, linéaire par copier/coller à partir des includes, qui commence par charger tous les modules en bloc, puis qui contient les directives --> quand l'erreur apparaîtra, le numéro de ligne devrait être plus indicatif et te donner la vraie raison du pb
comme tu es passé en mode "wait", je pense malheureusement que tu vas attendre longtemps car le "support" est en général plus commercial que technique (sauf si tu réussis à trouver l'adresse directe des vrais techos de la bande)
je pense que la proposition de luckyboy fait sens si tu ne veux pas attendre la vie d'Héra.... "essaie aussi de prendre en photo ton bios et de l'envoyer ici, car je ne comprends pas vraiment ton problème."
"Si je comprends bien, il faudrait que je re-installe Windows, mais dans une version non OEM pour pouvoir modifier le BIOS. Mais je ne vais pas acheter une version de Windows pour installer Linux. Ce serait un étrange paradoxe ! "
euh, c'est effectivement ce que j'ai fait avec mon laptop pro, et selon moi ce n'est pas lié à OEM versus non-OEM, mais ce sont les conditions implicites de windows qui détecte qu'il y a violation de licence si on tente de déplacer "le disque avec un windwos valide" sur un hardware "différent de la machine d'origine"
on trouve des licences windows OEM à ~1,50€, et si tu es joueur, on peut toujours faire le tour de passe-passe "windows-7 qui obtient une licence légale par magie, puis qui migre en windows 10 gratos"... (mais je ne vais pas expliquer comment ici)
autre problème possible, qui rejoint ce que dit Chalu
si ton laptop a un firmware trop récent par rapport au kernel+kernel-firmware de l'installeur de la 15.2, alors tu es logiquement "dans le flou" car il te manque du hardware
si ça se passe mieux en bootant sur l'intaller tumbleweed, ca confirmera cette piste
si c'est ça, il sera tjs possible d'installer une 15.2 mais c'est tricky car il faudra d'abord booter sur un linux "qui voit le hardware" avant d'installer une 15.2 patchée avec le repo kernel:latest pour tirer les kernel-firware récents (et peut-être aussi le kernel)
avec mon laptop, j'ai eu un pb intermédiaire : le kernel+kernel-firmware de la 15.2 voyait le disque en AHCI mais "pas grand chose" à côté, et je m'en suis sorti en ajoutant un repo 'http://download.opensuse.org/repositories/Kernel:/HEAD/standard/' en priorié basse pendant l'install pour aller accrocher l'affinité du paquet kernel-firmware sur ce repo
