Cover Thumnailer est un logiciel permettant d’afficher des couvertures d’albums de musique et de prévisualiser le contenu des dossiers d’images dans divers navigateurs de fichiers tels que Nautilus, Thunar, Caja ou Nemo.
Le projet est né il y a plus de dix ans maintenant, et la dernière version, en dehors de celle qui nous intéresse aujourd’hui, date de 2011. Pourquoi sortir une nouvelle version après autant d’années de silence radio ? C’est justement de ça dont on va parler dans la suite de cette dépêche !
Le commencement
L’histoire de Cover Thumbnailer commence en 2009 sur les forums Ubuntu-fr. J’avais à l’époque développé un petit script Bash permettant d’afficher les couvertures de mes albums de musique dans Nautilus. Il s’est très vite fait remarquer après que j’ai posté une capture d’écran de mon bureau dans l’une de ses interminables discussions dans lesquelles les gens aimaient partager leurs goûts pour les fonds d’écran criards et les thèmes GTK (ou Qt) exotiques (ou douteux, c’est selon).
De fil en aiguille, le petit script Bash est devenu un script Python, puis a évolué pour devenir de plus en plus complet et personnalisable, jusqu’à la sortie de la version v0.8.3 fin 2011, qui fut la dernière publiée avant longtemps.
Pourquoi une nouvelle version aujourd’hui ?
Tout simplement par ce que Cover Thumnailer ne fonctionnait plus ! Depuis toutes ces années, bien que n’évoluant plus, le logiciel avait continué de fonctionner, et donc ses utilisateurs ont continué à l’utiliser. Jusqu’à la sortie en 2018 d’une version de Nautilus qui cassa partiellement son fonctionnement, puis à la sortie d’Ubuntu 20.04 cette année qui finit de l’achever.
Le premier problème est causé par Nautilus : pour des raisons de sécurité, les développeurs ont décidé d’exécuter les thumbnailers (générateurs de miniatures) dans des sandbox (bacs à sable) pour les isoler du système. Cela pose divers problèmes dans le cas de Cover Thumbnailer :
- il a besoin de connaître le chemin réel du dossier pour lequel on lui demande de générer une miniature (pour savoir s’il faut générer une miniature d’album de musique ou une prévisualisation d’un dossier d’images) ;
- il doit pouvoir accéder à son fichier de configuration.
Le second problème est dû quant à lui à la suppression de technologies obsolètes dans Ubuntu 20.04 :
- la prise en charge de Python 2 a été fortement réduite (l’interpréteur est toujours là, mais la plupart des bibliothèques ont été supprimées) ;
- la bibliothèque PyGTK, qui était utilisée pour l’interface graphique de configuration, a elle aussi été supprimée.
Il y avait donc deux choix possibles :
- jeter l’éponge et décréter que Cover Thumbnailer était définitivement abandonné ;
- ou essayer de corriger les problèmes pour ne pas laisser les utilisateurs en plan.
J’ai bien évidemment choisi la seconde solution, sinon vous ne seriez pas en train de lire cette dépêche. :)
Ce qui change dans cette nouvelle version
À vrai dire, les principaux changements sont assez peu visibles pour les utilisateurs :
- le code Python 2 a été converti en Python 3 ;
- l’interface graphique a été portée de PyGTK / GTK 2 à GObject Introspection / GTK 3.
Mais il y a quand même quelques nouveautés :
- les traductions ont été mises à jour, puisque de nouvelles traductions avaient été réalisées sur Launchpad ;
- un bouton a été ajouté pour générer manuellement les miniatures pour un dossier spécifique.
Ce dernier point est là pour pallier le sandboxing de Nautilus qui ne permet plus de générer automatiquement les vignettes pour ce navigateur de fichiers.
En résumé, avec Thunar, Caja et Nemo, Cover Thumnailer fonctionne normalement, et génère les vignettes des dossiers automatiquement. Et avec Nautilus, il faut cliquer sur un bouton situé dans l’interface de configuration de Cover Thumbnailer pour demander la génération des vignettes. Ce n’est pas parfait, mais au moins ça fonctionne.
L’avenir du logiciel
On en arrive au point qui m’a poussé à écrire cette dépêche : l’avenir de Cover Thumbnailer. Je n’ai personnellement plus vraiment de temps à lui consacrer. Je continuerai donc à fournir des correctifs autant que faire se peut, mais il ne faudra pas s’attendre à de nouvelles fonctionnalités de ma part.
C’est pourquoi je cherche un repreneur : si quelqu’un est intéressé par ce logiciel et souhaite poursuivre son développement, qu’il ou elle n’hésite pas à me contacter, je pourrai même lui filer un coup de main pour nettoyer le code si besoin. À bon entendeur ! ;)
Aller plus loin
- Page du projet sur GitHub (236 clics)
- L’histoire du projet sur le blog de FLOZz (39 clics)
- Là où tout a commencé, sur les forums Ubuntu-fr (47 clics)
# (HS) Github
Posté par Franck Routier (Mastodon) . Évalué à 2.
Bonjour, et tout d'abord merci et bravo pour ce travail, et félicitation pour le choix de faire évoluer ce logiciel, là où un abandon en rase campagne aurait été si facile !
Je ne savais même pas qu'il était possible de rajouter des thumbnailers custom à Nautilus…
Ma remarque est un peu hors sujet, mais pourquoi avoir choisi Github et pas un autre hébergement similaire (Gitlab par exemple, ou d'autre dépôts comme Framagit) ?
Pourquoi pas Github ?
Github est aujourd'hui en situation de quasi monopole pour l'hébergement des projets libres. Github collecte énormément de données sur ces projets, leurs technologies, leurs dépendances, etc… Github appartient à Microsoft, qui le rentabilisera d'une façon ou d'une autre.
Tous ces éléments combinés en font une menace pour l'avenir des logiciels libres. Certains projet sont bloqués sur Github, car leur historique et/ou leur encours de tickets n'est pas facile à migrer sur d'autres plateformes. Mais un "nouveau" (si on peut dire :-)) projet peut, devrait oserais-je dire, opter pour une alternative moins centralisée, monopolistique, aux mains du grand méchant crosoft.
[^] # Re: (HS) Github
Posté par gnumdk (site web personnel) . Évalué à 3.
Euh, la migration sous GitLab est relativement transparente avec l'import de tous les tickets en cours.
Après, le problème de GitHub, c'est que c'est pas libre, pas que ça appartient à Microsoft.
Totalement aucun sens pour du libre et pour Git, Microsoft peut faire la même chose en pour n'importe quel logiciel libre hébergé sur ton GitLab.
[^] # Re: (HS) Github
Posté par Franck Routier (Mastodon) . Évalué à 2.
La migration sous Gitlab n'a pas l'air si simple, si on en croit le projet PeerTube, qui conserve son support sur Github, et affiche un lien github sur ses pages, tout en aillant une copie du projet sur Framagit.
Par ailleurs, le fait d'avoir l'intégralité des projets centralisée facilite grandement l'analyse statistique des projets, sans avoir a dupliquer une multitude de dépôts de sources différentes.
Enfin, tu as raison, évidemment, le code de Github n'est pas libre. Ce qui explique en partie son extrème centralisation (on ne peut pas lancer sa propre instance de Github, contrairement à Gitlab).
Enfin, je me permets de penser que si, le fait d'appartenir à Microsoft, dont l'historique anti-LL est particulièrement lourd, est un problème. Malgré la communication intense que cette entreprise déploie pour nous convaincre que "Microsoft loves Linux"…
[^] # Re: (HS) Github
Posté par freem . Évalué à 1. Dernière modification le 15 juillet 2020 à 20:45.
Et qu'en est-il de l'inverse?
De GL ou GH vers d'autres forges moins populaires?
Qu'en est-il aussi des raisons? Techniques? Une BDD c'est toujours chiant a migrer c'est évident, les logiciels sont pas conçus de la même manière…
Hein?
Et tu ne peux pas instancier ton instance gitlab chez toi sans faire tourner de code proprio. A moins que, et ça me surprendrais, l'instance publique ne fasse tourner que du code sous Affero GPL?
Ça s'appelle du bullshit chez moi. Moi, je suis un techie bas de gamme, je n'accepte que les arguments efficaces, mes parents ont oublié de m'installer le plugin pour regarder la marque avant de critiquer.
[^] # Re: (HS) Github
Posté par barmic 🦦 . Évalué à 2.
Si on parle de projets libres, ils n'ont pas vocation à cacher leurs statistiques et les distributions sont les premières à profiter de cette simplification. Ce ne sont pas des données complexes à trouver, ça ne l'a jamais était et ça n'est pas le but, il y a même eu des projets et entreprises qui faisaient ce genre de choses avant github.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: (HS) Github
Posté par gnumdk (site web personnel) . Évalué à 5.
J'ai migré tous mes projets de GitHub vers gitlab.gnome.org et les tickets ont été importés automatiquement.
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . Évalué à 7.
En fait, pour être totalement honnête ma première décision avait été d'abandonner le logiciel (j'en parle rapidement sur l'article que j'ai publié sur mon blog)… Je ne pensais pas qu'il restait plus d'un ou deux utilisateurs, donc je trouvais que ça valait pas le coup de s'embêter à réparer… Mais devant le nombre de messages que j'ai reçu, j'ai finalement changé d'avis (comme quoi, quand vous utilisez un logiciel, faites-le savoir a son créateur, ça motive !).
Réponse courte : par facilité.
Je comprends votre réticence vis-à-vis de l'utilisation de services centralisés, et à une époque j'aurais refusé d'aller sur Github également… Mais du fait de son côté centralisé, beaucoup de devs ont un compte sur Github, ce qui facilite les contributions (en termes de quantité). La friction est moins grande.
Il est plus facile de proposer un correctif ou d'ouvrir un ticket sur un site où on a déjà un compte que de devoir s'inscrire sur un nouveau site, puis de contribuer. Personnellement ça m'est déjà arrivé de renoncer à rapport un bug ou de proposer un correctif, par ce que j'étais en train de faire autre chose en même temps et que j'avais la flemme de créer un compte sur un n-ième site (oui je sais, c'est pas bien).
Ceci dit, le dépôt de Cover Thumbnailer sur Launchpad (qui était le lieu où était développé ce logiciel avant que je migre tous mes dépôts sur Github) est toujours automatiquement synchronisé avec le dépôt Github. Donc on a quand même des backups. :)
En fait j'ai migré le dépôt de Cover Thumbnailer sur Github en Juin 2017, c'est pas tout à fait nouveau donc. :)
[^] # Re: (HS) Github
Posté par freem . Évalué à 3.
Pareil.
D'un autre côté, j'ai le même effet maintenant avec github en vrai, parce que j'ai tendance a caler mon patch dans (ou en pièce jointe à) la réponse, et a chaque fois, même si ça améliore les choses, il faut faire 20 aller-retours pour qu'il soit accepté, pour des questions de code-style (jamais documenté), qui auraient été plus rapidement patchées via un simple de l'auteur.
Pour moi, ce n'est pas que MS soit l'actuel proprio de GH le problème, le problème c'est la bureaucratie inhérence à la façon de gérer les projets par "push-request".
Ça ne date pas du rachat, hein.
Mais ça a toujours été plus proche de la cathédrale que du bazar sur lequel, notamment, linux et ses distributions sont bâties.
Et dans le cas des cathédrales, les BSDs ont prouvé qu'héberger sa forge est efficace, mais ce type de forges se basent sur les échanges de mails.
Je sais que je diverge du sujet initial, mais, la dépendance aux interfaces web je la vit assez mal perso, et toi?
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . Évalué à 2.
Perso j'ai arrêté de faire des retours sur le coding style sur mes projets (à moins que ça soit vraiment dégueulasse) :
Soit j'ai configuré un linter (ce qui donne des règles claires sur ce qui est attendu), et qui tourne dans la CI (donc le dev est prévenu tout de suite des trucs qui ne vont pas quand il fait sa pull request).
Soit j'en ai pas configuré et je n'ai donc pas le droit de me plaindre.
Je comprends ton point de vue, ça casse un peu le côté décentralisé de Git.
Mais personnellement je bosse toute la journée (et une partie de la nuit) sur des tas de projets différents avec énormément de personnes différentes, et clairement, le workflow proposé par Github et Gitlab me simplifie énormément la vie !
J'utilise Github et Gitlab tous les jours, et clairement pour moi il s'agit de formidables outils de collaboration qui me font gagner énormément de temps.
[^] # Re: (HS) Github
Posté par barmic 🦦 . Évalué à 2.
De ce que tu décris, le problème c'est la revue de code qui de ton expérience s'appuie sur des points non pertinents. Tu pourrais avoir la même chose sur la LKML. C'est juste que la LKML fais des remarques plus pertinentes, j'imagine
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: (HS) Github
Posté par freem . Évalué à 4.
Ben, tout le monde a tapé sur Sourceforge (qui héberge cela dis toujours les gros fichiers de bien des projets dont le dev se fait sur GH ou GL hein…) donc on l'exclue.
Y'a quoi d'autre? GitLab? Pas monopole, certes, mais mais 100% libre non plus, leur plateforme n'utilise pas la version libre.
Au final, le but des utilisateurs de GH, c'est de réduire le taux d'emmerdement des nouveaux contributeurs et des développeurs.
Pas besoin d'un Nième compte, pas besoin de s'emmerder a déployer une archi, quitte a se retrouver prisonnier d'une interface qui… disons, «force» une politique de développement.
Sur ce point, je préférais perso sourceforge: il était simple d'avoir des mailings lists publiques, ce qui impliquais donc que les contributeurs n'étaient pas traqués par le site.
Il y avait aussi des forums, bien plus simple d'accès aux béotiens, et bien d'autres fonctionnalités que GH est loin d'égaler a mes yeux.
Lol.
Qui le rentabiliseras?
Ben oui, mais ou est le problème? L'open source, c'est pas juste du "hey, je paye 1) mon temps et 2) mon fric pour que vous puissiez utiliser mon logiciel! Et en plus, je fait la hotline gratos, et me fais insulter for fun!"
Pour info, la boîte derrière GH n'a jamais publié le code hein, ça n'a jamais rien eu à voir avec du libre.
Ils savent comment rentabiliser, et, en gros, le libre leur sers de pub gratos.
Tout comme ce que faisait sourceforge avant de perdre de la vitesse.
Sauf que, limite, sourceforge est plus libre: le soft d'origine est le même que celui utilisé par savannah. On a pas accès à l'histo de dev, certes, mais on a au moins accès a une partie de l'histoire (ça reste non libre selon moi).
Gitlab est sûrement ce que tu préférerais? C'est du libre en partie seulement.
Surtout ce qui est utilisé par leur forge publique et "gratuite".
Bitbucket?
Comme GH, et a une époque meilleure interface, mais ils ont choisi de la bloat, il faut maintenant plusieurs secondes avec un meilleurs hard et une meilleure connection pour charger chaque page.
Perso j'ai jamais aimé GH, mais je le trouve aujourd'hui plus supportable que la bouse qu'est devenue BB.
S'auto-héberger? T'auras moins de contributeurs, et en plus, faut gérer la technique (déployer une forge logicielle, se protéger contre les attaques, etc) et la loi (GPDR par exemple, mais aussi hadopi et bien d'autres).
SourceHut? Faut payer, ou s'auto-héberger.
Donne une seul argument réel de menace sur le libre, pour voir? git est, de base, décentralisé.
De nombreux (mais assez a mon goût) projets utilisent GH comme mirroir.
Au pire, même si tu ne me convaincs pas du mal que représentes GH (ça va être dur, je déteste déjà ce site), que proposes-tu?
Dis nous, comment faire?
Comment faire pour gratuitement exposer notre code a nous dev libristes sans mettre 2 ans a attendre l'approbation d'un quelconque projet?
Je t'écoutes, parce que je suis justement en train de monter mon propre serveur pour héberger mes projets perso. Qui n'auront pour seule interface de l'extérieur qu'un simple mail et un http(s) qui crache l'arbo du git.
[^] # Re: (HS) Github
Posté par Franck Routier (Mastodon) . Évalué à 1.
Si ton argument c'est, auto-héberger c'est trop compliquer, faut gérer le truc, alors, ben, faut des gens qui le fassent à ta place. Dont tu seras dépendant. C'est un choix, mais pas celui d'un internet décentralisé et libre. C'est celui de "gmail" pour les email, github pour les dépôts, facebook / twitter pour le social, etc…
Sinon, https://about.gitlab.com/install/
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . Évalué à 2.
Tout comme la dépendance aux gros acteurs centralisés pose certains problèmes, l'autohébergement a lui aussi son lot d'inconvénients.
Pour moi, le principal souci de l'autohébergement, en dehors de son coût, des compétences nécessaires et de la charge de travail que ça représente, c'est la pérennité : si l'auteur d'un logiciel autohébergé perd toute motivation ou disparaît, tout son travail disparaît avec lui.
Il y a heureusement des solutions comme Internet Archive ou la possibilité de répliquer les dépôts de code sur des plateformes centralisées… Mais c'est pas toujours mis en œuvre, ou de manière incomplète.
Il y a quelque temps, j'ai passé une bonne heure à écumer le web à la recherche d'un petit programme qui avait complètement disparu de la circulation il y a des années (c'était vraiment un truc de niche). J'ai fini par trouver un zip avec le code source du logiciel au fin fond d'un site disparu qui avait heureusement été sauvegardé par quelqu'un sur la way back machine de l'Internet Archive. J'ai donc pu récupérer le code d'une version du logiciel, mais pas son historique (si toutefois il avait été développé en utilisant un VCS).
Je ne dis pas qu'il ne faut pas s'autohéberger hein, juste que chaque solution a ses inconvénients, et que chacun doit prendre ses décisions en fonction de ses priorités et/ou capacités.
[^] # Re: (HS) Github
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Bah, tu as le même problème avec un tiers qui gère le service / les données.
Google par exemple est connu pour détruire les services qui ne l'intéresse plus. Ils ont aussi une politique de ban des utilisateurs sans donner d'explication et en refusant tout retour en arrière.
C'est justement tout l'intérêt de archive.org, mais ça ne fait que décaler le problème à plus tard.
[^] # Re: (HS) Github
Posté par freem . Évalué à 3.
Il est quand même moins probable que, par exemple, google oublie de payer son domaine que toi ou moi. Ou que leur compte bancaire soit fermé suite a bronsonisation du propriétaire.
Pour le fait de leur politique, c'est clairement un fait, surtout pour google. D'ailleurs ils avaient leur propre forge pendant un temps, mais je pense que peu de monde avait vraiment envie d'héberger leur code chez eux, pour entre autres cette raison que tu cites.
D'une manière ou d'une autre, il n'y a vraiment que la réplication qui puisse freiner le problème de la disparition des sources.
[^] # Re: (HS) Github
Posté par barmic 🦦 . Évalué à 3.
J'ai l'impression que Google se tape cette réputation surtout parce qu'ils tentent beaucoup de choses. Mais je ne trouve pas leur politique qui choquante que ça. Framasoft aussi ferme des services. Ça fait partie du cycle de vie de tout service. Soit tu héberge toi pour t'assurer que le cycle de vie correspond à ton besoin soit il faut vivre avec (ce qui n'est pas forcément si compliqué si on a un peu fais attention).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: (HS) Github
Posté par freem . Évalué à 3. Dernière modification le 17 juillet 2020 à 22:59.
C'est un fait, qui ne tente rien n'a rien, et pour une boîte, c'est sain de drop des projets pas rentables.
Mais on a accès au source et on peut host un instance pour refournir le service, pas avec google.
C'est, je pense la grande différence: Framasoft n'utilise en public que des logiciels libres (en privé, je sais pas) dont le code est accessible. Ce n'est pas le cas de google.
En fait, ça serait plus simple (pour moi) d'avoir un argument correct si les logiciels utilisés par Framasoft étaient sous affero, mais vu que je suis déjà pas fan de la GPL, je vais pas le demander.
Je suppose qu'un résumé possible est: «Moi, Freem, ai une certaine confiance dans le fait que Framasoft n'utilise que des logiciels dont je peux avoir le source pour les services dont je dépend, confiance que je n'accorde point a Google.»
Ce qui indique clairement que j'ai jamais été vérifier. Du coup.
Par contre, moi, je suis un utilisateur et un peu contributeur de LL, je n'utilise pas le LL juste parce que c'est souvent gratos. Enfin, ce n'est plus le cas.
Je suis sûr que la majeure partie des râleries contre google sont liées a ça.
Et que s'il y en a peu pour framasoft, c'est parce que c'est peu connu, hors de «notre sphère idéologique».
[^] # Re: (HS) Github
Posté par barmic 🦦 . Évalué à 3.
Pour moi ça n'est pas tenable. AMHA on se trompe en cherchant à caler l'informatique de service sur le logiciel libre. Le paradigme est différent il faut le prendre en compte. Le code de gmail pourrait être libéré que ça ne te permettrait pas de reproduire le service chez toi :
Pour moi, le code quand on parle de service n'a pas d'importance. Tu ne peux que faire confiance comme tu le dis, mais ça n'est pas fiable tu ne peux pas construire ta liberté d'utilisateur sur quelque chose d'aussi fragile.
Ce que tu peux faire par contre c'est regarder tes données :
Ça tu peux le vérifier. Avec des directive comme la RGPD tu peux demander la suppression de tes données, il ne reste plus que pouvoir les manipuler et là ça passe par du logiciel libre. Mais ce dernier point n'est pas le premier et en soit que le logiciel qui fait tourner ton service managé et que celui que tu utilise chez toi ne soient pas les même ne dérange pas. Par exemple, il semble que peu de monde trouve à redire que la plupart des gitlab proposés sous forme de service soit des versions entreprise.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: (HS) Github
Posté par Elfir3 . Évalué à 2.
Ca fait quelques temps que j'ai plus regardé, mais je doute que ça ait fort changé.
Le problème de github n'est pas du point de vue git, mais sur ce qui gravite autour. Github est d'ailleurs plus décentralisé encore dès que tu veux des services annexes. Et c'est là qu'est le piège en tant que développeur de logiciel libre.
Tu profites allègrement de différents services avec free tier et le coût (en temps) d'une migration vers un autre service augmente drastiquement car les outils de migration n'existent pas.
Bref, le soucis c'est surtout que le lock in est insidieux.
Ensuite, on connais les pratiques de Microsoft pour ce qui est d'imposer/garder un monopole en utilisant des techniques anti concurrentielles déloyales. Si ton code est chez eux, tu contribues un peu plus à ce que ça arrive. Et (parce que je sens que ça va venir), non ce n'est pas parce que c'est Microsoft, juste une boite dirigée en regardant des chiffres.
[^] # Re: (HS) Github
Posté par freem . Évalué à 3.
C'est valable pour toutes les forges ça, le fait de pas pouvoir migrer les tickets par exemple (c'est la 2nd plus grosse fonctionnalité d'une forge après tout).
La seule solution au final, c'est d'embarquer les tickets dans le repo. De ce point de vue, fossil est très intéressant. Le problème, c'est juste qu'il faut apprendre a utiliser un nouvel outil, ce qui va freiner les premières contributions de la majorité des contributeurs.
Pour les autres DVCS (et notamment git), il existe divers projets pour ça, mais même si j'aime énormément l'idée (bien plus que de devoir me taper l'UI de github, tu peux me croire), je garde mes doutes sur les implémentations (par exemple, devoir installer la pile ruby pour ça me gêne énormément).
Il faudrait que je reprenne un peu le temps de regarder d'ailleurs.
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . Évalué à 2.
Je tiens tout de même à préciser que Gitlab dispose d'une fonction d'export d'un projet (ça génère un zip avec tout dedans, y compris les issues, merge requests, wiki, board, tags, etc.).
Ce zip peut être réimporté en l'état dans n'importe quelle autre instance Gitlab.
De plus, Gitlab peut importer un dépôt depuis Github, Bitbucket, Gitea et quelques autres forges.
Pour ce qui est de Github en lui-même, il dispose d'APIs, et pas mal de projets existent pour exporter / réimporter les issues et d'autres éléments d'un projet.
[^] # Re: (HS) Github
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 17 juillet 2020 à 06:26.
C'est très spécifique gitlab, je ne suis pas sûr que ce soit documenté, de comment ça se passe si tu as des écarts de version ou si tu passe de Community à Entreprise (ou l'inverse). C'est moins une solution d'intéropérabilité que de backup. Et avec tout ça il ne va pas faire de magie. Tu perds les utilisateurs. Il ne va pas faire de mapping entre les comptes de l'ancien et du nouveau.
J'avais entendu parler d'un projet qui avait fait ce travail de mapping, mais je n'arrive pas à mettre la main dessus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . Évalué à 2.
Dans le zip exporté, les infos du projet, ses issues, MR, etc. sont exportées dans un JSON qui semble bien structuré. Le dépôt Git et le wiki (qui est aussi un dépôt Git), sont exportés sous forme de bundle Git. Donc il me semble assez facile d'exploiter ces données si on devait les traiter nous-même (import dans une forge exotique ou autre).
La compatibilité des exports entre les versions de Gitlab est également bien documentée.
J'ai utilisé cette fonctionnalité cette semaine encore pour transférer un projet entre deux Gitlab, et ça s'est très bien passé : il a bien réattribué les contributions/issues/merge requests aux bons utilisateurs (qui étaient présents des deux côtés).
[^] # Re: (HS) Github
Posté par barmic 🦦 . Évalué à 1.
Non documenté et justement :
Ils ne le supportent que pour 2 versions antérieur ce qui montrent bien qu'il n'y a pas de pérennité à attendre de se format. Si tu veux faire un import de cette archive, tu va potentiellement avoir un bon niveau de casse tête.
Le wiki pour pouvoir réimporter (proprement) le wiki il faut que tu ai la même saveur de markdown, de mermaid, que tu réimplémente le système de lien (pour le liens vers les tickets par exemple),…
Ça ne fonctionne que sur des instances auto hébergées et s'il y a le même email.
Je ne dis pas que la fonctionnalité ne marche pas ou qu'elle est mauvaise, juste qu'elle atteins assez vite ses limites et que l'intéropérabilité qui en découle reste limitée. Comme ses concurrents, gitlab travaille surtout pour que tu puisse continuer à travailler avec lui (en mode hébergé ou chez toi). Ce n'est pas une volonté d'interchangeabilité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: (HS) Github
Posté par Elfir3 . Évalué à 4.
Pourtant ils utilisent des standards pour l'export: du json et des bundle git pour les repos (wiki, snippets, ..)
Sans déconner. C'est tout de même quelques crans plus facile que de te taper tout le scraping à la main, on pourra commencer à parler d’interopérabilité le jour où il y aura une solution standard, mais vu les différences entre les forges je doute ça arrive un jour.
Au moins, à l'heure actuelle pour ce qui est de gitlab, tu as quelques json à parser pour ce que tu veux importer. C'est loin d'être insurmontable dans un environnement de dev.
Maintenant, le sujet initial de ce thread est la liberté de pouvoir continuer à héberger le truc ailleurs que dans une instance chez un hebergeur qui pompe des infos sur ton travail. Je pense qu'une migration gitlab à gitlab remplit parfaitement ce rôle, là où dans le cadre de github, c'est loin d'être gagné.
[^] # Re: (HS) Github
Posté par barmic 🦦 . Évalué à 2.
Et ils utilisent zip et unicode c'est que ça doit être bon, non ? C'est un format qui n'est même pas décrit. Il n'est supporté que pour 3 mois…
Et elle devrait sortir exnihilo ou on pourrait imaginer que les développeurs de forges commencent à travailler sur de l’interopérabilité ?
Ça dépend de ton but. Si tu veux coder l'import de ce format dans redmine par exemple, il faut à chaque nouvelle version de gitlab (soit tous les mois) :
Et vu le changement de politique avec la version 13.x, je me doute qu'il va évoluer ce format.
Questionner les limites de cette migration est hors de propos ?
gitlab se veut être un clone de github et ce genre de solutions pousse à enclaver les gens sur gitlab. Ça pose des problèmes aux autres forges et mène à une monoculture (pour faire simple le github flow).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . Évalué à 2.
Il ne faut pas oublier également que Gitlab (tout comme Github d'ailleurs), propose des API, et je ne pense pas qu'elles cassent tous les 4 matins.
Il est donc également possible d'utiliser ces API pour importer des projets dans une autre forge (tout comme Gitlab le fait pour importer des projets depuis Github, Bitbucket ou Gitea).
Personnellement si je développais une forge, je m’appuierais sur les API pour les imports de projets plutôt que sur l'export ZIP… Ça sera mieux documenté et plus stable dans le temps. :)
[^] # Re: (HS) Github
Posté par barmic 🦦 . Évalué à 3.
C'est vrai (et je m'en sert, mais pas pour faire de l'exportation). C'est déjà bien plus stable et c'est documenté. Mais comme tu le dis, du coup github le fait aussi ainsi bitbucket.
Dans l'état actuel oui, mais en soit j'aurais trouvé plus logique de partir d'une archive :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: (HS) Github
Posté par Elfir3 . Évalué à 3.
Oui et non, je parle surtout des acteurs qui fournissent des services intégrés github et qui au final te rendent dépendant de github car ne proposent pas de forge alternative. Je pensais à Travis (mais mauvais example car maintenant ils semble fournir du service pour Bitbucket en bêta), Circle-CI (idem Bitbucket semble nouveau, mais sur cloud uniquement) et cie.
On dirait que la situation à évolué depuis mes recherches, en tout cas les quelques services que je viens de regarder semblent en fournir. Mais j'avais été étonné il y a 2-3 ans de voir que dans les solutions qu'on avait regardé pour compléter l'offre github, la plupart étaient exclusives à github.
# Diablo Swing Orchestra
Posté par Ant . Évalué à 4.
Oh, Diablo Swing Orchestra en pochette ! Très sympa, je l'ai découvert sur Jamendo il y a bieeeeennnn longtemps. ça fait plaisir.
Quel bon goût !
[^] # Re: Diablo Swing Orchestra
Posté par FLOZz (site web personnel) . Évalué à 4.
Pareil, j'avais découvert ça il y a longtemps sur Jamendo ! J'adore ce groupe ! <3
[^] # Re: Diablo Swing Orchestra
Posté par freem . Évalué à 2.
Han j'avais pas tilté!
Bien vu!
D'ailleurs, si tu as un remplaçant pour jamendo, voire un site ou je pourrais retrouver les artistes que j'y ai découvert, je suis preneur…
[^] # Re: Diablo Swing Orchestra
Posté par FLOZz (site web personnel) . Évalué à 1.
En dehors de Jamendo et Dogmazic, je vois pas trop. Certains des artistes sont sur Youtube ou Spotify, mais du coup autant télécharger les morceaux sur Jamendo… '
Tu lui reproche quoi à Jamendo pour vouloir le remplacer ? :)
[^] # Re: Diablo Swing Orchestra
Posté par freem . Évalué à 4.
Son évolution, ironiquement.
Le fait que ce soit maintenant impossible ou presque de faire des recherches par album.
Leur "nouveau" site est anti-ergonomique pour qui veut écouter un album, mais, j'accepte que c'est un choix.
Pour ce qui est de Dogmazic, en revanche, ça s'est amélioré, même si c'est toujours pas ça (c'est un peu de ma faute, je pourrais p'tet aider, même si je suis une bite ((ouai, c'est fait exprès pour rappeler que non, les références au mâle ne sont pas toujours positives)) en frontal).
Il faut dire que dogmazic est un site commercial, ils ont besoin de revenus, et c'est normal. Je ne leur en veux pas.
D'un autre côté, ni l'un ni l'autre ne suivent vraiment le libre, dans le sens ou il est rare que les sources (partitions, paroles, etc) soient fournies avec.
Il s'agit d'ailleurs d'un problème récurrent pour les gens qui font des jeux vidéo libres (je ne fais que contribuer): rares sont les ressources.
[^] # Re: Diablo Swing Orchestra
Posté par FLOZz (site web personnel) . Évalué à 3.
J'avoue que je ne suis pas fan de leur nouvelle ergonomie #CétaitMieuxAvant… Mais bon c'est pas grave, je télécharge ce qui m'intéresse et ça me donne une excuse pour laisser tomber Spotify de temps en temps et ressortir mon bon vieux MPD. :D
[^] # Re: Diablo Swing Orchestra
Posté par Ant . Évalué à 0.
C'est vrai. Je pense que c'est fait exprès, mais c'est un mauvais choix à mon avis.
Maintenant au niveau financier Jamendo ils sont sur la corde raide depuis un moment.
Mais de temps en temps j'y vais quand même :-)
C'est rafraichissant
[^] # Re: Diablo Swing Orchestra
Posté par freem . Évalué à 3.
De mémoire, le but était de mieux toucher les gens qui se baladent juste sur le web, au détriment de la partie de leurs utilisateurs qui considèrent qu'un album est un tout.
Fait bien longtemps que j'y suis pas allé pour le coup. Ni sur dogmazic d'ailleurs.
# Merci
Posté par Kevin-Dupuis-Morizeau . Évalué à 3.
Je ne connaissais pas Cover Thumbnailer, je viens de l'adopter, merci !
# Documentation sur le fichier utilisé et gestion des tags id3 et assimilés
Posté par tao popus . Évalué à 2.
Bravo pour le travail.
J'ai quelques suggestions pour l'amélioration :
Le README ne dit pas grand chose sur son fonctionnement. Les utilisateurs ne savent pas forcément qu'un fichier nommé COVER.(jpg|png) et toutes ses variantes (avec ., min/maj etc…, est considéré comme une pochette de disque/cassette/album.
Les fichiers au format mp3 et d'autres formats audio ou d'encapsulation peuvent contenir des tags id3 (ou autre, avec le plus rara APE_tag, ou encore plus rare MPEG-7), permettant d'embarquer une vignette (ou plus) dans le fichier. J'ai regardé le code python en diagonal, et n'ai pas l'impression que ce soit géré. Cela pourrait être utilisé pour représenter le dossier ou le fichier lui même si cela diffère par morceau par exemple. Dans ce cas, je ne suis pas sûr que ce soit nécessaire de le conserver en cache ?
eye3D peut servir d'exemple, voir de module python. Je l'utilise pour étiqueter mes fichiers, via des deulignes (encore un site perso Free pertinent tiens) en bash, mais il sert aussi à la lecture/debug des étiquettes/tags. C'est un des plus respectueux des standards.
[^] # Re: Documentation sur le fichier utilisé et gestion des tags id3 et assimilés
Posté par FLOZz (site web personnel) . Évalué à 4.
… heu… oui, tu as raison ! 😅️
Ça a probablement dû être expliqué quelque part dans le thread sur les forums d'Ubuntu-fr, mais clairement ça devrait être dans le README ! C'est une information tellement évidente pour moi que je ne me suis même pas rendu compte qu'elle manquait. Merci !
Tu as raison, ce n'est pas géré. Ça a déjà été suggéré plusieurs fois, mais je n'ai jamais implémenté cette fonctionnalité (et je n'aurais malheureusement pas le temps de m'en occuper pour le moment).
Ceci dit, il doit être possible de trouver (ou de faire) un script qui extrait les images depuis les fichiers audio et qui les écrit dans un fichier
.cover.jpgpour que Cover Thumbnailer l'utilise.Pour ce qui est du dossier, ça rentre dans le scope de Cover Thumbnailer, mais pour les fichiers eux-mêmes ce n'est plus le cas. Il existe de plus déjà des thumbnailers pour les fichiers audio. Sur mon Ubuntu 20.04 ils sont en tout cas présents et activés par défaut (Nautilus). 😃️
[^] # Re: Documentation sur le fichier utilisé et gestion des tags id3 et assimilés
Posté par FLOZz (site web personnel) . Évalué à 4.
J'ai mi à jour le README avec plus d'informations sur le fonctionnement du logiciel. Merci encore de m'avoir fait remarquer à quel point ça manquait.
# parles en sur reddit
Posté par manatlan (site web personnel) . Évalué à 3.
Tu devrai lancer ton appel sur reddit.com/r/Python …
Je suis certain que tu trouveras des pythonistas près à mettre la main à la patte
[^] # Re: parles en sur reddit
Posté par FLOZz (site web personnel) . Évalué à 2. Dernière modification le 16 juillet 2020 à 13:09.
Tu as probablement raison, mais dans un premiers temps je préfère essayer de trouver un repreneur qui utilise ou a utilisé le logiciel… Je suis pas sur que ça intéresse quelqu'un de complètement extérieur au projet (surtout vu la qualité actuelle du code, ya du boulot pour nettoyer tout ça
^^')Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.