Subject: Problème de version et de cymbales

From: Christian LE BARS <[email-masked]>
Date: Mon, 4 May 2020 23:38:24 +0200

Bonsoir a tous.

Je viens d'installer la version lilyjazz de Vincent Gay.

Cela fonctionne chez moi, cependant Lily râle( mais fait le travail
quand même) elle voudrais que soit installée la version:2.20.0

cette version n'est pas dans le dépot Fedora actuellement.

Que puis-je faire?

autrement les cymbales ne sont pas prit en compte dans la version de
Vincent.

Comment et ou implante t'on les cymbales?

Par avance merci.

Portez vous bien.

Christian

---

From: Valentin Villenave <[email-masked]>
Date: Tue, 5 May 2020 00:10:34 +0200

> cette version n'est pas dans le dépot Fedora actuellement.

Depuis quelques semaines, il est redevenu possible (et même
préférable) d’utiliser les versions publiées sur lilypond.org, voire
la version dite «de développement» (branche numérotée impaire, en ce
moment 2.21) qui paraît toutes les deux semaines.

http://lilypond.org/development

C’est un fichier .sh, à télécharger puis à exécuter dans un terminal
(en mode root ou non, personnellement c’est ce que je ferais) :

cd Téléchargements
./lilypond-2.21.1-1.linux-64.sh

Cordialement,
V.

---

From: Christian LE BARS <[email-masked]>
Date: Tue, 5 May 2020 08:48:05 +0200

Merci Valentin pour ta réponse concernant la version de lilypond.

Mais comme il y avait 2 questions dans mon message je vais reposer la
dernière questions.

Cordialement

Christian

---

From: Vincent Gay <[email-masked]>
Date: Tue, 5 May 2020 09:49:23 +0200

> moment 2.21) qui paraît toutes les deux semaines.

D'un point de vue lilypondesque Valentin a certainement raison (je ne me
hasarderais pas à le contredire). D'un point de vue système il est bien
plus agréable de laisser la maîtrise des mises à jour et son lot de
dépendances à son gestionnaire de paquets. Je sais aussi que l'on peut
avoir plusieurs versions de Lily en même temps mais je n'en vois pas
l'intérêt. Mes exigences étant moindres que celles de Valentin cela m'a
toujours convenu.

Christian, concernant les fichiers qui te posent problèmes : ils sont
passés récemment de 2.19.82 à 2.20.0 avec convert-ly et je ne me
souviens pas qu'il y ait eu de changement. Le fait que ça compile le
confirme. Si le message d'avertissement t'ennuie tu peux tout simplement
changer la première ligne de chacun d'entre eux en revenant de

> \version "2.20.0"
à
> \version "2.19.82"

-- 
Vincent Gay
Envoyé depuis mon saxo-phone :)
http://blog.vintherine.org/ - http://photos.vintherine.org/

---

From: Valentin Villenave <[email-masked]>
Date: Tue, 5 May 2020 09:56:21 +0200

On 5/5/20, Christian LE BARS <[email-masked]> wrote:
> je vais reposer la dernière question.

Ah oui, c’est quoi au juste ce problème de cymbale ? Elles ne sont pas
rendues dans le MIDI ?

V.

---

From: Yoann LE BARS <[email-masked]>
Date: Tue, 5 May 2020 11:29:10 +0200

Salut à tous !

Le 05/05/2020 à 09:49, Vincent Gay a écrit :
> D'un point de vue système il est bien

	Je suis bien d’accord : les développeurs de toutes les applications,
moi y compris, expliquerons tous qu’il est très simple d’installer la
version de développement de leur application. Donc, si on écoute ces
conseils, on se retrouve très rapidement à devoir maintenir soi-même les
versions des divers applications que l’on utilise ce qui devient
rapidement très problématique au niveau de la gestion des dépendances –
si vous ne me croyez pas, essayez d’utiliser Linux From Scratch pendant
plusieurs mois en prenant soin de mettre à jour chaque composante dès
qu’une nouvelle version sort.

	Cependant, il y a une solution intermédiaire : l’usage d’un
gestionnaire de paquets indépendant de la distribution tels que Snappy
(https://snapcraft.io/) ou de Flatpak (https://flatpak.org/). Snappy
semble plus répandu à l’heure actuelle, mais une partie du code est
propriétaire, on peut donc lui préférer Flatpak. En tout cas, j’ai testé
pour quelques applications, ça marche très bien et ça permet aux
développeurs de déployer plus facilement des versions récentes de leurs
applications sans se soucier de tester pour chaque distribution.

	Cela dit, j’ai un peu cherché, je n’ai trouvé ni de snap, ni de pak,
pour Lilypond. Donc, il faudrait que quelqu’un s’y colle…

	À bientôt.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : [email-masked]

---

From: Valentin Villenave <[email-masked]>
Date: Tue, 5 May 2020 11:41:31 +0200

On 5/5/20, Yoann LE BARS <[email-masked]> wrote:
> si on écoute ces
> rapidement très problématique au niveau de la gestion des dépendances

Oui et non. Dans le cas présent, LilyPond-gub (l’installeur distribué
par le site) embarque ses propres dépendances et il n’y a quasiment
rien (pas même Frescobaldi, au sens strict) qui dépende de LilyPond.

> je n’ai trouvé ni de snap, ni de pak,

C’est amusant parce que je lisais justement ce matin un témoignage qui
tire à boulets rouges sur ces systèmes (et je suis en grande partie
d’accord) :
https://www.osnews.com/story/131746/ubuntu-20-04-lts-snap-obsession-has-snapped-me-off-of-it
Dans le cas de LilyPond encore une fois, ça ne présenterait pas
vraiment d’intérêt, à part de réinventer la roue en ajoutant une
couche supplémentaire de lourdeur et de gaspillage de ressources. On
proposait autrefois un "autopackage", qui était un équivalent de ce
genre de trucs (en plus léger), il y a une raison pour laquelle plus
personne n’en a éprouvé le besoin.

Encore une fois, l’installeur GUB contient _déjà_ toutes les
dépendances nécessaires (à part glibc, d’accord), et installe une
distribution LilyPond de façon remarquablement propre et cloisonnée,
sans requérir davantage de surcourches, chroot, container,
virtualisation ou que sais-je. La question serait entièrement
différente pour une application graphique ou nécessitant une prise en
charge matérielle spécifique (serveur son, primitive graphiques,
parallélisation, haute priorité ou autre) ; mais en l’état LilyPond
reste tranquillement dans son coin.

Au surplus, pour certaines distributions il devient même _plus_ facile
d’installer LilyPond-gub que par les dépôts, puisque jusqu’à ce jour
nous avons été contraints de dépendre d’une version antédiluvienne de
Guile, qui commence à disparaître de pas mal de distributions.

V.

---

From: Vincent Gay <[email-masked]>
Date: Tue, 5 May 2020 11:51:10 +0200

Le 05/05/2020 à 11:41, Valentin Villenave a écrit :
> d’installer LilyPond-gub que par les dépôts,

Il y a une autre raison pour laquelle je reste sur la version de ma
distribution : elle change bien moins souvent que les versions de
développement de Lily. Et n'ayant pas de très gros besoins je préfère
une version obsolète que je connais à une version up to date que je dois
ré-apprendre. Bon, c'est un peu caricaturale ce que je dis là mais il me
reviens souvent ces vieux préceptes pas si idiots que me rabâchait mon
grand-père et notamment : le mieux est l'ennemi du bien !

---

From: Christian LE BARS <[email-masked]>
Date: Tue, 5 May 2020 11:59:03 +0200

Bonjour a tous.

Je vois beaucoup d'échange sur ma question.

CE matin j'étais au supermarché, en ce moment je fais la bouffe.

Donc je m'y mettrais que cet A.M.

A+

---

From: Yoann LE BARS <[email-masked]>
Date: Tue, 5 May 2020 15:46:12 +0200

Salut à tous !

	Bon, j’ai hésité à répondre, parce que je ne veux pas que ça tourne à
la /flaming war/, mais je me dis que ça vaut tout de même le coup. En
fait, je pense qu’il y a une vraie difficulté pour les développeurs, qui
sont pourtant également des utilisateurs, à se mettre dans la
perspective d’un utilisateur.

Le 05/05/2020 à 11:41, Valentin Villenave a écrit :
> On

	Tout à fait. D’ailleurs, GNU/Linux peine à se faire une place comme
système pour ordinateurs de bureau, alors que c’est ce pour quoi Linus
TORVALDS l’avait conçu à la base. À l’inverse, le grand-public
plébiscite des systèmes où les applications s’installent au moyen de
paquets indépendants tel qu’Android.

	Est-ce que vraiment nous devons rejeter l’hypothèse qu’Autopackage ne
répondait qu’imparfaitement à la demande ?

> d’installer LilyPond-gub que par les dépôts

	C’est bien ce que je disais : un développeur dira toujours que son
application est facile à installer.

	Cependant, avec Lilypond-gub, l’application ne se mettra plus à jour
avec le reste du système. L’utilisateur devra se tenir au courant de
l’état d’avancement de l’application. Aucun problème, c’est facile.

	Bon, un utilisateur de Lilypond a toutes les chances de se mettre à
LaTeX à un moment ou a un autre. Là, même discours : autant utiliser
TeXLive, c’est facile à faire – sur les listes de diffusions dédiées à
LaTeX, on voit passer exactement le même discours. Une autre application
pour laquelle l’utilisateur ne pourra plus utiliser le système
centralisé de son système et devra se tenir au courant des avancé.

	Puis, quelqu’un qui réalise des partitions sur ordinateur a
probablement besoin au moins un peu de logiciels de musique assisté par
ordinateur, tel qu’Ardour. Encore une fois, autant utiliser la dernière
version, ce n’est pas compliqué à installer.

	Ainsi de suite…

	Bon, derrière, il y a déjà la question de savoir s’il est vraiment
utile de suivre les dernières versions des applications – à titre
personnel, déformation de débianeu, je pense que généralement non, mais
passons. Toujours est-il que si nous conseillons aux utilisateurs
d’utiliser une version très récente, il faut leur fournir un moyen
simple de conserver leur système à jour.

> La question serait entièrement
> parallélisation, haute priorité ou autre)

	Certes. Cependant, les systèmes ne faisant tourner uniquement Lilypond
sont très rare. D’où l’importance de proposer un système qui puisse
prendre en compte une classe d’applications plus large et notamment les
applications les plus répandues.

	Le problème que soulève cet article, c’est d’une part le fait de ne pas
laisser le choix à l’utilisateur, ce à quoi je souscris, ainsi que la
question de la pertinence qu’il y a à baser fortement un système sur ce
genre de paquets et sur ce point je pense moi aussi que c’est une
mauvaise idée.

	En revanche, je pense qu’ici la problématique est différente : dans le
cas présent, ce type de paquet permet à l’utilisateur de simplement
suivre les versions récentes d’une application donnée.

> jusqu’à ce jour

	Problématique à laquelle répond parfaitement Flatpak, ainsi que Snappy.

	Bon, cela dit, il y a un autre problème : Flatpak et Snappy répondent à
des questions d’utilisateurs, mais la création de ces paquets est à la
discrétion des développeurs, qui eut n’arrive pas à en voir l’intérêt…

	À bientôt.

---

From: Valentin Villenave <[email-masked]>
Date: Tue, 5 May 2020 16:41:31 +0200

On 5/5/20, Yoann LE BARS <[email-masked]> wrote:
> je pense qu’il y a une vraie difficulté pour les développeurs, qui

Je ne suis vraiment pas sûr que flatpak/snap/docker/electron/etc.
soient vraiment à un stade d’utilisation accessible au premier venu.
(En tout cas, pas plus que la distribution LilyPond-gub.)

(Et : oui, c’est un brin de mauvaise foi de juxtaposer flatpak, docker
et electron, flatpak étant quand même _un peu_ moins lourd que les
autres. Mais je fais cet amalgame pour appuyer mon argument : les
surcouches devraient être évitées lorsqu’elles ne sont pas absolument
nécessaires.)

> À l’inverse, le grand-public

Euh, tout dépend ce qu’on entend par "indépendant" : en un sens, le
succès du modèle "App Store" centralisé est venu confirmer (en moins
bien) ce que les distributions GNU/Linux faisaient depuis vingt ans.
Et de ce point de vue, je comprends tout à fait que beaucoup préfèrent
utiliser la version de LilyPond disponible pour leur distribution ; le
modèle flat/snap/truc s’approche en revanche plutôt (en mieux) de ce
que sont habitués à devoir faire les Windowsiens, obligés d’aller
télécharger des installeurs .exe/.msi/.dmg etc.

> répondait qu’imparfaitement à la demande ?

Je pense que dans le cas de LilyPond, cela faisait simplement
double-emploi avec les installeurs gub. Et ce serait également le cas
d’un truc en flatpack/snappy (avec probablement un peu de lourdeur en
plus).

> l’état d’avancement de l’application.

C’est tout à fait vrai. Ces installeurs sont destinés aux
utilisateurs/trices les plus chevronné.e.s, qui veulent avoir une
version récente pour pouvoir bénéficier de nouveautés ou de
corrections de bugs. (Et en cela, cela rejoint une large partie du
public de cette liste.)

> sur les listes de diffusions dédiées à
> LaTeX, on voit passer exactement le même discours.

Ouch. C’est quand même méchamment moins le bordel avec LilyPond ; on
distribue *un* seul programme, qui se met dans *un* seul dossier. Ce
qui me dérange infiniment moins que d’avoir à installer le machin TeX,
et puis 4000 packages perl avec ctan, et puis 25000 applications avec
pip, sans parler de npm, php compose, le machin de ruby etc. C’est
également la raison pour laquelle la proposition d’un gestionnaire de
package lilypond (lyp) a été accueillie avec un froid polaire il y a
quelques années.

Dans un monde idéal, les distributions resteraient au taquet et on
n’aurait pas besoin d’attendre trois ans que Ubuntu réalise qu’une
nouvelle version stable de LilyPond est sortie (et que _rien_ mais
alors rien n’empêche de la backporter sur tous les systèmes encore en
circulation). Ça a été le cas par le passé : ainsi, il fallait environ
3 jours pour que Fedora intégre la toute dernière version _devel_ de
LilyPond, toutes les deux semaines ; ça s’est grippé lorsque
(précisément à cause d’une déficience de gub) on a passé plusieurs
années sans publier aucune version, ni stable ni devel. Avec un peu de
chance ça peut reprendre -- mais il est certain que les petites
distributions avec peu de moyens, à moins de compter parmi leurs
contributeurs un ou deux mordus de LilyPond, ne pourront jamais rester
à la page.

> personnel, déformation de débianeu, je pense que généralement non

Curieusement, quasiment personne parmi les développeurs de Lily n’est
sous Debian :-)

Pour une utilisation assez simple, il est certain qu’avoir quelques
années de retard ne pose pas de problème majeur ; la syntaxe n’a que
très peu changé depuis 2.14 (2.16 pour les fonctions en Scheme).
Encore une fois le système de publication par le site web est destiné
aux utilisateurs à qui la liste des nouveautés d’une version à l’autre
donne l’eau à la bouche, et aussi -- plus fréquemment sans doute -- à
celles et ceux qui tombent sur un bug ennuyeux et pas simple à
backporter dans la branche stable (et encore moins dans les anciennes
branches stables).

> si nous conseillons aux utilisateurs

D’une façon générale, nous recommandons l’utilisation de la version
_stable_. Ça s’est détraqué pendant le dernier cycle car 2.18 est
devenue vraiment, vraiment ancienne au point que 2.19.83 l’a presque
remplacée, de facto, comme l’équivalent d’une version majeure.

En temps "normal", c’est-à-dire jusqu’à 2017 et depuis janvier
dernier, la seule raison pour laquelle il nous arrive effectivement de
recommander une version de développement, est lorsqu’il y a des bugs
ennuyeux et que nous préférons dire "c’est corrigé, ça va sortir dans
dix jours" plutôt que "ça va sortir dans deux ans".

> la pertinence qu’il y a à baser fortement un système sur ce

On est d’accord. Même pour LilyPond, encore une fois, si les
distributions font correctement leur boulot le paquet natif devrait
être largement suffisant pour beaucoup d’utilisateurs/trices.
Autrefois Fedora (et la plupart des distributions RPM), mais aussi
Arch et même Slackware, ont toujours été irréprochables ; il reste à
voir si ça va reprendre à l’heure actuelle.

> discrétion des développeurs, qui eux n’arrive pas à en voir l’intérêt…

Si, précisément ! GUB était justement conçu pour répondre à ce besoin,
longtemps avant FlatPak, Snappy et même AutoPackage. Certes, sans
gestion des mises à jour, mais en revanche avec un atout de poids, qui
est la compilation multi-plateforme. (D’ailleurs il y a même eu une
époque où des installeurs Win/Mac/Nux/BSD pour OpenOffice et Inkscape
étaient générés par GUB.)

Aujourd’hui, GUB accuse son âge (et c’est même toute l’infrastructure
de compilation de LilyPond qu’il faudrait revoir entièrement, mais on
parle là d’un boulot titanesque), mais au moins on est arrivés à le
refaire marcher après trois ans de panne ; il n’y a absolument pas les
ressources pour arriver à lui faire cracher des paquets flat/snap/dock
(et je ne sais même pas si ce serait possible sans nuire au support
multi-plateforme) donc, if it ain’t broken,…

V.

---

From: Yoann LE BARS <[email-masked]>
Date: Tue, 5 May 2020 17:39:49 +0200

Salut à tous !

Le 05/05/2020 à 16:41, Valentin Villenave a écrit :
> double-emploi avec les installeurs gub.

	Sauf qu’en l’espèce GUB est spécifique à un petit nombre d’applications.

> Ouch. C’est quand même méchamment moins le bordel avec LilyPond

	Il n’empêche : on voit régulièrement passer sur les listes consacrées à
LaTeX cet argument : TeXLive, ça roule tout seul.

> circulation).

	C’est-à-dire que la version de Lilypond d’Ubuntu est la version de
Debian et Lilypond n’est pas dans les /backports/ Debian parce qu’il n’y
a pas suffisamment de monde pour lui faire passer les tests de qualités
nécessaires pour intégrer les /backports/. Pour ma part, je n’ai pas été
capable de faire passer ma correction d’un bogue bloquant d’Ardour dans
les /backports/, donc clairement seul je ne ferais pas passer Lilypond
dans les /backports/.

	Ubuntu se focalise sur un certain nombre de paquets et Lilypond n’en
fait pas partie. Sous Debian, cela fonctionne sur la base du volontariat
et il n’y a pas assez de volontaires pour Lilypond. Après, je ne sais
pas comment évaluer le rapport de causalité avec le fait que peu de
développeurs de Lilypond utilisent Debian.

> dix jours" plutôt que "ça va sortir dans deux ans".

	Évidemment, les développeurs considèrent que leur application est très
importante. Cependant, une distribution ce sont des milliers
d’applications et il n’est pas si évident d’assurer une bonne
consistance de la distribution en mettant à jour les logiciels aussi
régulièrement que tous les dix jours, sauf avec des choix comme ceux
d’Archlinux qui demandent aux utilisateurs un niveau de connaissances
techniques assez important.

	Du coup, pour les cas où les développeurs considèrent qu’il est
important que les utilisateurs puissent accéder à une nouvelle version,
mais où ce sera compliqué pour les mainteneurs de distributions de la
mettre à disposition, Flatpack offre une solution.

> multi-plateforme) donc, if it ain’t broken,…

	En tout cas, il n’est pas pertinent d’utiliser plusieurs formats de ce
type de paquets, puisque le propos est justement de ne faire qu’un seul
paquet pour toutes les distributions. Ce qui répond à la question du
multi-plateforme : ces formats sont multi-plateforme. Par exemple, même
si Canonical développe Snappy, il est parfaitement possible de faire
tourner un paquet Flatpack sur Ubuntu.

	Par ailleurs, pour avoir testé ces systèmes, du point de vue de
l’utilisateur c’est vraiment très simple.

	À bientôt.

---

From: Valentin Villenave <[email-masked]>
Date: Tue, 5 May 2020 21:03:40 +0200

> 	Sauf qu’en l’espèce GUB est spécifique à un petit nombre d’applications.

Ce n’était pas le but à l’origine : GUB était censé pouvoir servir à
n’importe quelle app, comme en témoigne l’exemple de LO et Inkscape.

> nécessaires pour intégrer les /backports/.

Bin je ne sais pas ce qu’il leur faut, on a une suite de tests de
régression qui est probablement la plus complète du monde des
logiciels Libres…

> Sous Debian, cela fonctionne sur la base du volontariat

Je pense que c’est dans l’autre sens ; le profil des gens qui
s’intéressent de très près à LilyPond n’est pas celui de gens qui ont
envie d’un système hyper-stable où les mises à jour ne sortent qu’avec
5 ans de décalage :-)

Du coup c’est vrai qu’on trouve plus volontiers des fous furieux de
Lily chez Arch, Fedora, et même FreeBSD.

> mettre à disposition, Flatpack offre une solution.

GUB aussi :-)

> Ce qui répond à la question du
> multi-plateforme : ces formats sont multi-plateforme.

Euh, j’entendais par-là multi-OS _et_ multi-architecture, à un niveau
natif et non dans une couche de virtualisation. Mine de rien, GUB
c’est quand même un sacré truc. (Dommage que ça n’ait pas pris plus
largement.)

V.

---

From: Denis Bitouzé <[email-masked]>
Date: Tue, 05 May 2020 21:33:00 +0200

Le 05/05/20 à 17h39, Yoann LE BARS a écrit :

>>> sur les listes de diffusions dédiées à LaTeX, on voit passer
>>> exactement le même discours.
>> 
> 	Il n’empêche : on voit régulièrement passer sur les listes
> consacrées à LaTeX cet argument : TeXLive, ça roule tout seul.

Concernant LaTeX, je suis un de ceux qui préconisent une TeX Live « à la
vanille » (donc pas via les packages Linux) parce que ceux qui la
packagent pour les distributions Linux la découpent en général (je ne
connais en fait pas d'exception) en plusieurs packages différents et il
n'est du coup pas rare qu'il manque un package (LaTeX), même en ayant
installé le package (Linux) appelé « texlive-full »...
-- 
Denis

---

From: Yoann LE BARS <[email-masked]>
Date: Tue, 5 May 2020 22:00:15 +0200

Salut à tous !

> n’importe quelle app, comme en témoigne l’exemple de LO et Inkscape.

	Il reste le problème que l’utilisateur doit se tenir au courant de
l’actualité de toutes les applications qu’il a installé avec GUB. Ne
serait-ce que simplement pour les problèmes de sécurité ou de bogues. Ce
problème ne se pose pas avec Flatpak.

> régression qui est probablement la plus complète du monde des

	Sans doute. Cependant, un logiciel n’existe pas tout seul. Entre autre,
il a des dépendances, qui peuvent entrer en conflit avec d’autres
applications, par exemple.

	Peu importe la qualité de la gestion du projet, pour assurer une
distribution de qualité, il n’est pas possible d’intégrer un logiciel,
quel qu’il soit, sans procéder à des tests. Puis, ne me dit pas qu’il
n’y a jamais eu de problème dans une version stable de Lilypond. Déjà
que tu te plains que ça prend 5 ans à intégrer une nouvelle version,
imagine qu’on reste 5 ans avec une version bancale…

> envie d’un système hyper-stable où les mises à jour ne sortent qu’avec

	Arf !

	Cela dit, en passant, j’ai constaté il y a quelques jours que la
version de Thunderbird dans Ubuntu est plus ancienne que dans celle de
Debian stable + /backports/. Comme quoi…

	Bon, ce n’était qu’une blague en passant, mais sur les applications
classées comme les plus populaires, avec les /backports/ les paquets
sont très à jours, dans ces cas Debian est même une des distributions
les plus à jour.

> c’est quand même un sacré truc. (Dommage que ça n’ait pas pris plus

	Ah, mais je ne conteste pas les qualités de GUB. Simplement, force est
de constater que depuis 1999, pour une raison ou une autre, il n’a pas pris.

	À bientôt.

---

From: Yoann LE BARS <[email-masked]>
Date: Tue, 5 May 2020 22:04:22 +0200

Salut à tous !

> installé le package (Linux) appelé « texlive-full »...

	Je confirme, tu me l’as régulièrement conseillé sur la liste GUT. C’est
bien le seul conseil obtenu sur cette liste que j’ai toujours
consciencieusement ignoré – je ne sais pas si je fais bien de le révéler…

	À bientôt.

---

From: Denis Bitouzé <[email-masked]>
Date: Tue, 05 May 2020 22:48:43 +0200

> consciencieusement ignoré – je ne sais pas si je fais bien de le révéler…

Ah, la vache ! :)
-- 
Denis