book ( livre) worm ( ver ): ver de livre, ver qui dévore les livres, termite, au figuré : gros lecteur de bouquins !
Je me demande si la traduction la plus proche ne serait pas « rat de bibliothèque » ]]>
ok, mais y'a aucune raison ...
la raison est que la page n'est pas entièrement traduite,
https://manpages-l10n-team.pages.debian … le-fr.html
mais qui a fait dériver vers mountpoint dont la manpage est absente de sid,
I don't understand why no man pages for section 1 are shown in the
bullseye list, sorry. For other languages it works. But at least
mountpoint(1) is complete in both bullseye and unstable (as of today).
et la page de manuel de mount pour unstable devrait bientôt être dispo ..]]>
Après peut-être que tu connais personnellement le mainteneur de pelican, et que tu as de bonnes raisons de penser qu’il ne fait pas d’effort pour maintenir ce paquet. Mais dans ce cas on ne cause pas de la même chose. J’ai profité de ce ticket que tu as évoqué, parce que pris hors de tout contexte il représente bien le genre de souci auquel on peut faire face en temps que mainteneur d’un logiciel ou d’un paquet.
Oui j'ai de bonnes raisons de supposer qu'il ne fasse pas d'effort, une version qui a déjà deux ans de retard, alors que la prochaine version stable de debian va pas tarder à geler et donc bloquer toutes updates de paquets, je pense que c'est une tare, cette méthode de mainteneur / dieu de paquets est une tare, la preuve c'est qu'on a plein de programmes qui ne bougent pas ou peu car personnes ne s'en occupent. Si la personne n'a pas le temps, bah il lache la chose, du coup d'autres personnes plus motivées pourront reprendre le flambeau.
Mais mon expérience plus globale du libre ce n’est pas ça. J’ai bien plus l’habitude des bénévoles débordés ou à la motivation fluctuante, à qui je dois renvoyer des rappels réguliers. Et ayant moi aussi été dans leur situation (mon emploi avait commencé à me bouffer toute mon énergie, mes projets libres en pâtissaient, ça n’a pu se régler qu’en quittant ma boîte), je n’ai aucun souci à imaginer qu’ils puissent avoir tout un tas de raisons pour ne pas avoir le temps/l’énergie/la volonté de répondre rapidement.
Peut être mais dans ce cas la personne lâche et laisse la place, comme je t'ai dis chez opensuse c'est pas comme ça, on fait et on parle, déjà sans relancer, la personne a t'elle répondu à la première personne qui demandé une montée de version? La réponse est non, j'ai demandé à mon tour toujours rien, et deux relance plus tard car entre temps il y a eu quand même 3 ou 4 versions importantes de ce logiciels corrigeant tout un tas de merdouilles, toujours rien et ça en en deux ans, la demande n'a pas deux ans, mais au minimum le logiciel n'a pas été entretenu depuis deux ans... alors qu'en amont il n'a jamais été aussi vivace.
Dans ce genre de situation, une série de demandes comme tes trois rappels de nouvelles versions en moins de deux mois, c’est le genre de truc qui m’aurait juste poussé à me déconnecter encore plus. Peut-être que si les rôles étaient inversés tu n’aurais vu aucun souci à ce qu’on t’envoie ces rappels, mais tu ne peux pas juste en déduire que c’est la même chose pour la personne en face de toi.
Perso, il y en aurait pas eu besoin, c'est comme ça, c'est en tout cas comme ça que j'opère, a moins de pas savoir et d'être enquiquiner par un gros changement, ou un truc qui me dépasse, mais encore une fois le jour où je ne serais plus apte (moins de temps, moins d'envie, ...) je lacherais la chose et je ferais une demande pour qu'on reprenne mes paquets.
Encore une fois, et il n'y a pas de soucis sur tes remarques, c'est juste un comportement que je n'approuve pas quand on est mainteneur, dit moi, est-ce bien poli de ne pas répondre? Car la on parle de mainteneur mais c'est une team et non un mainteneur!!! Au delà du fait que la personne est en charge du bien être de ses paquets, si il n'a pas le temps de le faire (ça prend pas vraiment longtemps de faire le taf), une réponse c'est encore moins long, juste non je ne mettrai pas a jour le paquet bande de petits cons, m'aurait suffit. :-)
Là actuellement je pense clairement que la méthode du mainteneur / dieu de paquets montre ses limites, là où celle d'opensuse montre sa puissance. Mais Debian n'est pas la seule dans ce cas, j'ai vu pareil voir pire chez fedora, bon ce n'est qu'un jeu, mais flare chez fedora fait un segfault, du coup j'ai fait un gentil rapport pour signaler et toujours rien, c'est bien plus pénible car de un bugzilla demande d'avoir un compte donc enregistrement là ou chez Debian c'est BTS et qu'il n'y pas d'enregistrement, de deux que pour lire le bug il faut un compte (oui juste lire chez fedora faut un compte, bonjour l'ouverture et l'opensource vu par redhat!!!)
Mais tu as raison, je vais faire le paquet (je l'ai déjà mais on va le refaire sans mes ajouts perso) et l'envoyer en complément du rapport pour le fermer et on verra si c'est prit, je pense que je connais déjà la réponse, un droit de non recevoir sans même une seule réponse!
Après ça on te parle que debian souffre de manque de main d’œuvre.
Faut vraiment pas le prendre personnellement, j’aurais tenu le même discours si l’auteur des mails s’appelait vv222 plutôt que seb93 tongue
(et je suis sûr qu’en fouillant bien on peut trouver des situations où j’ai eu ce comportement que je désapprouve aujourd’hui)
Non non, t'en fais pas, j'espère que mes réponses ne sont pas désagréable, c'est pas contre toi ou qui que ce soit mais plutôt un raz le bol d'entendre toujours on manque de si on manque de ça mais en contre partie on ne veut pas bouger!
Perso, je connais un projet, qui a les mêmes soucis mais c'est moins flagrant car il n'y a pas ce truc de c'est moi le mainteneur de ce paquet alors pas touche!]]>
Bonjour Mélodie, il n'y a pas que gscreenshot de l'univers pip install qui est intéressant, je m'y étais intéressé à cet univers il y a quelques années avec Wheezy, il y en a énormément, je ne les plus en tête sauf l'excellent et rapide mps-youtube.
Le premier problème pour l'introduction dans debian de gscreenshot, c'est celui des logiciels python installés par pip dans une distribution Debian, c'est à dire que python est installé deux fois avec des PATH différents, le python de la distribution et celui qui vient avec pip. Ce qui peut dans certains cas créer des problèmes. Le deuxième problème, c'est que des paquets nettement plus importants ne trouvent même pas d'aide supplémentaire, voir :
https://www.debian.org/devel/wnpp/help_requested_byage
L'idéal auquel je pense, serait que les développeurs de gscreenshot se forment aux méthodes debian et à la création de paquets debian et qu'à partir de leur code original, ils créent quelque chose comme une passerelle de transformation de leur code original qui crache à la sortie du code suivant les règles des paquets debian. À mon avis, c'est plutôt aux dev de gscreenshot de s'en occuper qu'à ceux de debian, ne reste plus qu'à les convaincre.
Salut Gilles,
je comprends mais là je ne vois que le résultat final : une interface graphique petite et très légère pour interfacer scrot, très peu de dépendances, contrairement à certains programmes de captures d'écrans très lourds présents dans les dépôts, et Debian qui est la mère de beaucoup de distributions. Comme l'a indiqué phlinux, il existe un paquet deb chez Sparky Linux : https://repo.sparkylinux.org/pool/main/g/gscreenshot/
L'autre problème que tu évoques, le manque de contributeurs, nécessite un effort de recrutement qui va bien au delà d'une simple demande de paquet. Il serait nécessaire de lancer une grande campagne de recrutement ! Auprès de, disons, le CNLL et ses 13 clusters régionaux, l'Aful, l'Interlug, les universités informatiques… et de même dans les grands réseaux du monde.
Qu'en penses-tu ?]]>