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 - loustic

1
Général / Re : Maj TW : un souci avec Python (310 et 311 - PyQt6)
Hello

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

https://www.alionet.org/index.php?topic=1608.msg13660#msg13660

Ah, les dépendances python, quel pied... ;-)

Eric

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
2
Général / Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets
salut @chalu

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...
$ rpm -q --recommends git
git-cvs
git-email
git-svn

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)



3
Général / Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets
hello @Chumi

@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 ;-)

eric
4
Général / Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets
hello @chalu

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:
rpm -qa | grep texlive | wc -l
2746


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) :
rpm -q --whatprovides /usr/bin/pdflatex  -->  texlive-latex-bin-bin-2021.20210325.svn54358-150400.31.3.1.x86_64
rpm -q --provides texlive-latex-bin-bin-2021.20210325.svn54358-150400.31.3.1.x86_64  -->  texlive-latex-bin-bin
rpm -q --requires texlive-latex-bin-bin  -->  texlive-latex-bin
rpm -q --recommends  texlive-latex-bin  -->  {texlive-collection-fontsrecommended, texlive-collection-genericrecommended, texlive-collection-latexrecommended}
rpm -q --requires texlive-latex-bin  -->  texlive
rpm -q --recommends  texlive  -->  texlive-scheme-medium
rpm -q --whatrecommends  texlive  -->  no package recommends texlive
rpm -q --whatrecommends  texlive-scheme-medium  -->  texlive-2021.20210325-150400.31.3.1.x86_64

en général, pour faire le ménage, la méthode qui marche assez bien est :
rpm -e xxx  -->  message d'erreur : xxx is neede by aaa, bbb, ccc

il suffit d'itérer en ajoutant les paquets, ... en sachant s'arrêter à temps (dans la cas où le paquet est une dépendance du système)
rpm -e xxx aaa bbb ccc
rpm -e xxx aaa bbb ccc ddd eee fff

bon, ok, avec texlive et ses 2746 paquets en dépendance, il faut générer la liste avec awk, sinon le copier/coller est fastidieux:
deps=` rpm -e xxx |& awk '{ print $NF}' `
rpm -e texlive $deps  --> c'est là qu'il faut faire attention à ne pas effacer "trop"...

et à la fin, la commande passe...

eric
5
Général / Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets
hello

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.
(https://calibre-ebook.com/fr_CA/download_linux)

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

zypper refresh && zypper dup  --allow-vendor-change --allow-name-change --allow-arch-change --allow-downgrade --no-recommends 

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

eric



7
Présentations / Re : Pas vraiment un nouveau ...
PDP-8... c'est une machine vénérable (et il y en ca qui tournent encore)

j'ai fait du VAX-VMS à la fin des années 80, mais avec une console, sans les cartes perforées et un compilateur C (beaucoup plus facile)




8
Présentations / Re : Pas vraiment un nouveau ...
salut les anciens

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

longue vie aux passionnés

9
Matériel / Re : Compilation Kernel
hello burn2

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 ;-)...
10
Matériel / Re : Compilation Kernel
hello

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

eric



11
Programmes et logiciels / Re : openSUSE et PHP 8
hello Pascal

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

et sinon je n'ai pas d'autre idée....

eric
12
Installation et boot / Re : Installation impossible sur ACER Aspire 3
hello William

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

eric
13
Installation et boot / Re : Installation impossible sur ACER Aspire 3
"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)
14
Installation et boot / Re : Installation impossible sur ACER Aspire 3
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

eric

15
Installation et boot / Re : Installation impossible sur ACER Aspire 3
bonjour William

si "les disques durs Windows n'apparaissent pas", c'est probablement le problème du mode SATA configuré par défaut dans le setup "BIOS" (truc habituel), ce qui rejoint ce que dit Antoine

si tu bascules le mode SATA en AHCI dans ton setup, tu devrais voir le disque et ses partitions quand tu bootes ton install linux, mais il y a des chances pour que ton windows ne soit pas très content du changement

je te conseille donc de booter sous windows avec le mode AHCI pour valider que  windows ne fait pas de BSOD pour cause de changement majeur

comme je boote mon laptop avec le secure boot sous linux, je dirais que tu peux tester ces deux settings indépendamment

par contre, il est impératif que tu bootes en mode UEFI (et pas en mode BIOS), pour que l'installeur opensuse te donnes les bonnes options "avec uefi dans /boot/efi et secure boot possible"