BAud a écrit 12765 commentaires

Quel peuples ? Celtes ? Romains ? Basque ? Huns? Pictes? Et j'en oublie

moui, pour les Huns, j'ai un petit doute ;-) mais on peut rajouter les Maures jusque Poitiers (au moins, comme les magnétoscopes), les Vikings, les Germains et encore yen a d'autres si on remonte plus loin dans l'histoire du peuplement de la France

ok. Je repars généralement de la dernière version disponible, en adaptant les versions / ajoutant des dépendances.
Dans ce cas, autant enlever celles que tu identifies, oui : les autres ont été suffisantes pour générer un paquet.

Ce n'est pas vraiment au paquet Vosk de s'occuper du stockage des modèles de langage.

euh si, un peu, tout de même.

sur https://github.com/papoteur-mga/elograf/blob/master/README_fr
papoteur< indique d'ailleurs

• que c'est censé être stocké dans /usr/share/vosk-models au niveau système => mais dans le code d'elograf c'est /opt/vosk-models => à revoir avec papoteur< ;-)
• Pour le stockage dans l'espace système, les informations d'identification root sont demandées par le mécanisme polkit

bon, ce serait une évolution dans une version ultérieure, le temps de se coordonner ;-)

j'ai complété le .spec de Mageia pour lister :

BuildRequires:  bison
BuildRequires:  libtool
BuildRequires:  libespeak-devel
BuildRequires:  libvosk-devel
BuildRequires:  xdotool-devel
BuildRequires:  pkgconfig(Qt6Gui)
BuildRequires:  pkgconfig(Qt6Core)
BuildRequires:  pkgconfig(Qt6Widgets)
BuildRequires:  pkgconfig(Qt6Multimedia)
BuildRequires:  pkgconfig(alsa)
BuildRequires:  pkgconfig(libpulse)

j'ai ajouté Qt6Multimedia qui me manquait visiblement et pris en compte libvosk-devel que tu as ajouté.

en revanche, aucun Requires: : ils sont sans doute identifiés automatiquement désormais… ? À vérifier ;-)

J'ai préféré n'avoir qu'une installation système pour tous les utilisateurs.

moui, je pense aussi que c'est plus mieux, à voir comment c'est géré du côté des jeux pour les cartes de FPS par utilisateur… (bon c'est dans /usr/games ya des fichiers en drwxr-sr-xr-x appartenant à root groupe games)
Ce serait donc au paquet vosk d'avoir un répertoire /usr/share/vosk/vosk-models qui appartiendrait ou aurait un sticky-bit au groupe vosk (avoir un répertoire en 777 sous /usr/share/ c'est pas top… après faut penser à rajouter tous les utilisateurs légitimes au groupe vosk et modifier les paquets elograf et nocomprendo pour le faire automatiquement). Bah ça attendra sans doute une version ultérieure le temps de se mettre d'accord :D

lorsque j'essaie de reconstruire le paquet en Cauldron à jour, par un rpmbuild -ba nocomprendo.spec j'ai eu quelques soucis

TLDR :

• rajouter un BuildRequires: pkgconfig(Qt6Multimedia) pour éviter Project ERROR: Unknown module(s) in QT: multimedia
• trouver pourquoi à la compil' il ne prend pas /usr/lib64/libvosk.so plutôt que /usr/lib/python3.10/site-packages/vosk/libvosk.so ou alors faire en sorte que le paquet python3-vosk-0.3.46-4.mga10 fasse un lien vers /usr/lib64/libvosk.so.0

Donc bon, ça fonctionne bien sous Gnome :

• je réussis à lancer VLC
• la dictée est correctement prise en compte (ce que je dis s'affiche) mais dans gedit il n'a l'air de prendre que 4 caractères (alors qu'il prend tout pour la formule de politesse o_O) => je vais creuser
• même avec le modèle small-fr cela fonctionne correctement, le modèle fr faisant plutôt 1,7 Go une fois décompressé…

Je n'ai pas eu la même erreur que sous Debian 12 Bookworm ;-)

Reste à le proposer pour inclusion : en se basant sur Qt6 pour Cauldon, Qt5 peut-être pour Mageia 9.

Détail des erreurs :

+ /usr/lib64/qt6/bin/qmake libsuff=64 'QMAKE_CFLAGS=-O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3  -fstack-protector-strong -m64 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full' 'QMAKE_CXXFLAGS=-O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3  -fstack-protector-strong -m64 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full' 'QMAKE_LFLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--build-id=sha1 -Wl,--enable-new-dtags' QMAKE_STRIP=
Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.
Info: creating stash file /home/baud/rpmbuild/BUILD/nocomprendo-2.0-build/nocomprendo-2.0/.qmake.stash
Project ERROR: Unknown module(s) in QT: multimedia
erreur : Mauvais statut de sortie pour /home/baud/rpmbuild/tmp/rpm-tmp.23yNA3 (%build)

et je ne vois pas pourquoi il y a dans le .spec :

BuildRequires: lib64qt5widgets-devel
BuildRequires: lib64pulseaudio-devel
BuildRequires: qtbase5-common-devel

et non :

BuildRequires: lib64qt6widgets-devel
BuildRequires: lib64pulseaudio-devel
BuildRequires: qtbase6-common-devel

j'ai essayé avec

BuildRequires:  pkgconfig(Qt6Gui)
BuildRequires:  pkgconfig(Qt6Core)
BuildRequires:  pkgconfig(Qt6Widgets)

bon avec compil' à partir du tar.gz :

qmake && make
Info: creating stash file /home/baud/rpmbuild/SOURCES/nocomprendo-2.0/.qmake.stash
Project ERROR: Unknown module(s) in QT: multimedia

ok j'installe lib64qt6multimedia-devel => là, la compil' se lance (oui, je suis sous Gnome par défaut mais j'ai task-plasma-minimal-6.2.5-1.mga10 et task-plasma-6.2.5-1.mga10 d'installés, mais pas l'env' de dév de KDE…)

=> donc rajouter un BuildRequires: pkgconfig(Qt6Multimedia)

g++ -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--build-id=sha1 -Wl,--enable-new-dtags -Wl,-O1 -Wl,-rpath-link,/usr/lib64 -o nocomprendo about.o blink.o command.o commandset.o comprendo.o config.o dotoolpipe.o editcommand.o editutterance.o filedownloader.o main.o mainwindow.o misc.o modelchooser.o modelloader.o osd.o osdeditor.o reminder.o runguard.o settab.o settings.o speech.o trayicon.o zoombutton.o qrc_nocomprendo.o qrc_qmake_qmake_qm_files.o moc_about.o moc_blink.o moc_commandset.o moc_comprendo.o moc_dotoolpipe.o moc_editcommand.o moc_editutterance.o moc_filedownloader.o moc_mainwindow.o moc_modelchooser.o moc_modelloader.o moc_osd.o moc_osdeditor.o moc_reminder.o moc_settab.o moc_settings.o moc_speech.o moc_trayicon.o moc_zoombutton.o /usr/lib/python3.10/site-packages/vosk/libvosk.so /usr/lib64/libQt6Widgets.so /usr/lib64/libQt6Multimedia.so /usr/lib64/libQt6Gui.so /usr/lib64/libGLX.so /usr/lib64/libOpenGL.so /usr/lib64/libQt6Network.so /usr/lib64/libQt6Core.so -lpthread -lGLX -lOpenGL

/usr/bin/ld: cannot find /usr/lib/python3.10/site-packages/vosk/libvosk.so: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:328: nocomprendo] Error 1
erreur : Mauvais statut de sortie pour /home/baud/rpmbuild/tmp/rpm-tmp.RkPamP (%build)

pourtant, j'ai :

rpm -qa|grep -i vosk|sort
lib64kaldi-vosk5-git20231220-3.mga10
lib64kaldi-vosk-devel-git20231220-3.mga10
lib64vosk0-0.3.46-4.mga10
lib64vosk-devel-0.3.46-4.mga10 # fournit /usr/lib64/libvosk.so
python3-vosk-0.3.46-4.mga10 # ne fournit pas /usr/lib/python3.10/site-packages/vosk/libvosk.so

donc bon, j'ai été au plus court :

cd /usr/lib/python3.10/site-packages/
[root@localhost site-packages]# mkdir vosk
[root@localhost site-packages]# cd vosk
[root@localhost vosk]# ln -s /usr/lib64/libvosk.so

donc => voir pourquoi ne pas se baser sur fichier dans /usr/lib64/ ?

voilà, vous pouvez reprendre une activité normale ;-)

Je pense qu'on peut déplacer la création de ce répertoire du script du paquet vers le make install. Ce serait plus malin.

oui, ce serait la bonne pratique : ou en tout cas, apporté par le bon paquet => pourquoi n'est ce pas apporté par vosk ?
En outre, /opt/vosk-models c'est pour un programme externe au système. Pour vosk, ce serait plutôt /usr/share/vosk/models/ et si c'est spécifique à nocomprendo : /usr/share/nocomprendo/vosk-models/ via un paquet nocomprendo-vosk-models (ou 2 pour choisir entre le fr ou le small-fr)

Je sais bien faire les paquets pour Mageia. Il y en a un disponible sur le site et le fichier .spec est présent dans l'archive.

oui, j'ai récupéré ton .spec

il ne passe qu'en x86_64 je pense

j'ai le spec de la 1.2 disponible en cauldron

Il y a un peu d'adaptation à faire pour mettre le tien aux normes (c'est le boulot de l'empaqueteur).

Le problème des multiples distributions est de trouver les noms de chaque bibliothèque pour chaque distribution.

déjà lister l'intégralité de tes dépendances dans le README ou un fichier INSTALL aiderait… quitte à ce que tu n'indiques que celles que tu connais : ça évite d'avoir à fouiller dans un install.sh ou un Makefile ou…

Pour Fedora, ils avaient fait le choix d'avoir le même nom en i586 et x86_64(libnom_de_la_lib), pas chez Mandriva ni chez Mageia (préfixe lib ou lib64, et il n'y a pas forcément non plus le même découpage entre Qt5 et Qt6…)

Pour la première version, j'avais autant de machines virtuelles que de distributions Linux. Chacune à mettre à jour à chaque version, vérifier que ça compile toujours. Ça prend beaucoup de temps et c'est vraiment pénible.

ah mais ce n'est pas moi qui te demanderait cela ;-) et, pour moi, ce n'est pas à toi de le faire.

Un empaqueteur bénéficie d'un système de construction des paquets (build-system) avec déclinaison selon les versions (et je te confirme que ça peut vite devenir lourdingue à maintenir).

L'avantage d'un fablab c'est que j'ai déjà plusieurs machines avec plusieurs distributions, donc bon ça permet déjà de fournir une première version adaptée du .spec ou du .DSC, après à l'empaqueteur de le remettre en forme aux normes de chaque distro (et selon le découpage des dépendances).

Avec OBS, je ne sais jamais où récupérer ce qui a permis de construire un paquet… sur https://software.opensuse.org/download.html?project=home:be-root:nocomprendo&package=nocomprendo il n'y a pas le .spec ni le .DSC…

La mise à jour des paquets demande un suivi annuel fastidieux, à chaque sortie de nouvelle version d'une distribution.
Je n'ai plus le temps ni l'envie de m'en occuper.

L'Open Build Services c'est pas mal, mais pas idéal en terme d'intégration :/

Côté Mageia, tu peux soumettre une demande de mise à jour via https://bugs.mageia.org

Par exemple, https://bugs.mageia.org/show_bug.cgi?id=30710 si tu fournis le .spec actualisé, c'est généralement plus rapide :-) pour libaacs ça a bien fonctionné

Bon, ça ne garantit pas que tu trouveras un nouvel empaqueteur ;-)
https://bugs.mageia.org/show_bug.cgi?id=32652 pour printrun : nouveau paquet… ça n'a pas (encore) motivé grand' monde :/ (bon ya 2 paquets avec les dépendances)

La procédure est similaire côté Debian (ça finira par se retrouver dans les dérivés) et Fedora (le compte est chez Redhat mais bon…).

sinon, voir aussi côté https://github.com/fwupd/fwupd s'ils ont eu des contacts côté Dell pour ce produit, ça évitera de se marcher sur les pieds ;-)

évidemment il faut Windows pour mettre à jour celui de la station,

dans les minimal requirements : il y a ubuntu 14.04 or greater

mais il n'y a pas de pilote proposé sur https://www.dell.com/support/home/en-us/product-support/product/dell-universal-dock-d6000/drivers (autre que pour windows)

=> demander la procédure à Dell pour mettre à jour le firmware du dock à partir d'un Linux (ou plus généralement, sans windows : clé USB avec un freedos par exemple… comme ça, ça fonctionnera pour BSD/Haiku…). Si personne ne demande, forcément ils n'auront pas tendance à le faire :/ Accessoirement, demander si ça peut être sous licence libre (firmware + programme + doc'), préférentiellement MIT ou "BSD-2 clause" pour faciliter la distribution…

c'est écrit un peu petit, il faut mettre $$ de chaque côté et la formule sur sa propre ligne :-)

puisque

puis clarifier aide-edition et mettre à jour aide-edition-latex avec des exemples de formules sympas (et classiques)

Comme mentionné par d'autre, c'est bizare de considérer qu'une offre gratuite te serait due.

eh ! il peut toujours demander à se faire rembourser _o/

nan, avec un javelot pour exécuter la cible

hmmm l'exécuteur, avec un flingue ? :D

lanceur ça le ferait tout aussi bien

et tous les sujets traités sur LinuxFr.org taggués dicom

Impossible d'accéder au message authentifié avec la clé

oui, il y a une durée de rétention limitée du jeton — ce pour quoi Floxy< demande de l'inclure dans la liste des personnes à qui répondre :-)

c'est classique sur les listes de discussion

une fiche pratique qui recommande Zorin OS

ZorinOS (basé sur Ubuntu) ou PrimTux (basé sur Debian).

J'ai découvert ZorinOS lors d'une install'partie l'été 2024 dernier : c'est plutôt bien adapté aux utilisateurs souhaitant utiliser des ordinateurs peu récents (mais 64 bits tout de même). On avait du LinuxMint qui ne passait pas pour certains ordis et ZorinOS fonctionnait, je n'ai même pas eu à sortir ma clé Mageia ou Debian o_O

c'est basé sur Ubuntu (donc privateur)…

une approche différente de ZorinOS est de laisser le choix des sources de paquet entre

• deb
• flatpak
• snap pouvant être installé

et ils ont eu ce genre de discussions autour de snap depuis ~2019

Donc, bon, ça fait une distro de plus que je veux bien prendre du temps à recommander pour qui ne voudrait pas de Debian.

De plus, je compare un GNOME finement tuné pour être léger et un XFCE conf Debian vanilla, donc peut-être qu'il y a moyen de diminuer l'empreinte mémoire

pas tant que ça : XFCE a emprunté pas mal de bibliothèques de GNOME :/ Avec LXDE tu gagnes un petit peu, un peu plus avec LXQt. Pour vraiment gagner, regarder enlightenment ou se contenter de WM ;-) GNOME n'est pas un si mauvais choix :D

En revanche, pour avoir essayé sur des EeePC (901, 1000H et 1015), moins de 2 Go de RAM c'est plus d'une heure rien que pour l'installation initiale (et reste les mises à jour… et c'est peu réactif à l'utilisation, nombreux freezes :/). En les boostant à 2 Go de RAM, c'est un peu plus d'1/2 h ce qui fait 1 h avec mises à jour + modifications config' de base et cela reste un peu réactif.

une alimentation stabilisée de 750W qui consommait quelque chose comme 45W alors qu'elle était éteinte ! (via un gros bouton marche-arrêt qui nous fait croire que tout est coupé…).

eh ! Faut bien alimenter la LED de la carte-mère ATX /o\

c'est de la grammaire…

la technique pour l'évier du coup ?

tu enlèves la bonde ;-)

il est possible de voter plusieurs fois :p

cf. la faq

les cheat code de l’époque marchent !

pfff j'ai trop joué à Doom pour savoir que c'est I D D A D et I D K F Q /o\ respectivement pour être invincible et recharger toutes les armes (en nightmare c'est un peu nécessaire). Et oui, hormis le dernier niveau, j'ai refait tout le jeu au shotgun

la meilleure solution aurait été le taxi

bin c'est ce qu'il a fait, si j'ai bien compris son commentaire

le taxi étant un transport en commun.