Fedora-Fr - Communauté francophone Fedora - Linux

Communauté francophone des utilisateurs de la distribution Linux Fedora.

  

Dernière news : Assemblée Générale Ordinaire de Borsalinux-fr de 2021

#1 14/01/2021 22:15:49

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Un peu perdu (voir beaucoup) pour contribuer.

Bonjour à tous,

Sur Fedora depuis une bonne semaine, je m'y plais bien, j'en suis même le premier étonné, tellement que je voudrais y rester et contribuer en maintenant des paquets, j'ai pas dit créer mais maintenir à jour des paquets tache ingrat.

Le truc c'est que là où openSUSE est très facile d’accès pour contribuer (en gros avec opensuse il y a OBS, on fork un paquet dans les dépôts, on met dans la dernière version, on le build et on soumet le paquet ainsi créé pour rejoindre les dépôts officiels. j'ai fais un résumé de la version en ligne de commande OSC par là: https://passiongnulinux.tuxfamily.org/p … avec-obs/), là où Debian est un peu plus complexe mais assez simple car suffit de ce faire un compte, d'utiliser les outils devscript et / ou pbuilder (pour un chroot) (j'ai fais des semblant de tutos: https://passiongnulinux.tuxfamily.org/p … re-partie/, https://passiongnulinux.tuxfamily.org/p … me-partie/ et https://passiongnulinux.tuxfamily.org/p … pbuilder/), le plus dur est d'attendre que son paquet (un paquet non dispo dans les dépots) soit accepté, après ça va bien plus vite et ça ressemble un peu de ce que j'ai pu voir à la façon de faire de Fedora, c'est-à-dire, demande de bugs pour ajouter un paquet, création du paquet, attente qu'un packager regarde et confirme la bonne forme, acceptation et rebelote pour un autre paquet...

Et bien sous Fedora j'ai l'impression à en lire les documentations que c'est énormément compliqué, j'ai commencé par lire Fedora Packaging Guidelines (https://docs.fedoraproject.org/en-US/pa … uidelines/) encore là ça va, c'est un peu près partout pareil, puis https://doc.fedora-fr.org/wiki/RPM_:_en … nstruction et https://doc.fedora-fr.org/wiki/La_cr%C3 … r_les_nuls, ainsi que https://doc.fedora-fr.org/wiki/La_cr%C3 … _Paquetage jusque là c'est simple.

Ça se complique quand j'ai commencé à lire https://fedoraproject.org/wiki/Join_the … aintainers,  on me parle de git, de Bodhi et de kodji, et là je suis étonné de voir la complexité de la chose surtout que je m'attendais à un truc plus simple car j'ai toujours entendu dire que participer dans Fedora était simple comme bonjour.

Alors, au jour d'aujourd'hui, j'ai un compte fedora pour Copr, pour bugzilla, pour les sources de fedora qui tourne sur pargure (je dis peut etre des anneries), j'ai les outils de fedora d'installé, je retrouve mes marques que j'avais avec la création de rpm... Concrètement qu'est ce qui reste à faire? De votre coté pour ceux qui packagent, qu'est ce que vous avez fait exactement?

Bien amicalement seb

Hors ligne

#2 15/01/2021 01:03:30

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Alors, oui, l'écosystème Fedora est....... riche tongue ! Laisse-moi te faire un tour d'horizon !

Comment un paquet voyage-t-il donc pour arriver dans les repository ? C'est pas si complexe en faite !

Première Étape : La Validation

Avant qu'un paquet arrive dans Fedora, il faut que ce dernier soit validé, jusque-là, rien d'excentrique !

Il faut en premier lieu créer un fichier SPEC et un SRPM. Il est aussi préférable de créer un projet COPR pour le nouveau paquet.

Il faut s'assurer que le paquet n'existe pas et n'a jamais existé auparavant dans Fedora. Sinon, les procédures sont différentes (ouvrez un nouveau sujet pour cela tongue !). Pour vérifier ça, cherchez si un paquet existe dans le SCM.

Le Bugzilla

Tout nouveau paquet doit passer par le Bugzilla de Fedora/Red Hat. Il faut créer un ticket spécial où on y fait référence aux URL de notre SPEC et SPRM, une description du paquet (généralement celle qui se trouve dans le fichier SPEC), le nom d'utilisateur dans le FAS, Fedora Account System, celui qui vous permet d'avoir accès à COPR et Bugzilla, ainsi que, si possible, un build dans COPR et/ou un build "brouillon" (scratch) dans Koji (qui sera expliqué plus tard). Voici un exemple de demande de création de paquet. N'importe qui, qui est packager, peut l'accepter (vous pouvez même vous échanger des tickets sur la mailing liste à toujours condition d'être déjà packager). Normalement, cela ne prend que quelques jours pour une réponse, j'ai même eu des paquets approuvé le jour même. Néanmoins, dans certaines périodes, ça peut durer beaucoup plus longtemps. Mais, ça ne devrait pas durer plus d'un mois. D'ailleurs, la demande que je viens de vous donner était celle pour laquelle j'aurais dû attendre le plus longtemps.

Par contre, si vous n'êtes pas Packager, vous devez le préciser et vous devez ajouter "FE-NEEDSPONSOR" dans la cellule "Blocks" (pour ce dernier, ça se fait après avoir créé le ticket seulement). Seul un sponsor peut vous faire entrer à ce point, il vous fera d'ailleurs sûrement passer un petit test tongue (Surtout si c'est celui que je pense, Robert André Mauchin (eclipseo) wink...) ! Il est aussi recommandé de se présenter sur la mailing liste "devel" et de s'y inscrire (faites-vous d'ailleurs peut-être une autre addresse si vous en avez l'occasion vu la quantité de mail par jour) tout en y incluant votre première demande de paquet. Le sujet du mail devrait être "Self Introduction: [Nom et Prénom]". Voici les liens pour s'inscrire à la mailing liste ainsi que les archives ! Il est plutôt important de suivre au moins sommairement la mailing liste, vu qu'elle contient des informations sur absolument tout ce qui se passe dans Fedora, mais ça n'est pas obligatoire (mais vraiment conseillé).

Ensuite......................... Il faut attendre. C'est plus long que si on est déjà packager puisque la personne devant vous accepter devra être un sponsor. Voici mon premier ticket par exemple !

L'examen

Ensuite, le paquet devra être méticuleusement examiné par la personne qui aura choisi de le faire, pour s'assurer que votre paquet suis les guidelines. S'il vous fait des remarques, vous devrez y répondre. Généralement, c'est fait à partir d'une check liste généré quasi-automatiquement par un outil génial, que vous pouvez installer, fedora-review. Il génère un rapport quasi-complet sur votre paquet, et demande quelques vérifications manuelles de la part de celui qui vous examinera !

C'est une bonne idée de ce faire un auto-examen (mais ne pensez pas vous auto-approuver pour autant hammer) !

Dès qu'il n'y aura plus aucun problème avec votre paquet, ce dernier sera approuvé !

La création du dépôt git dans le SCM

Il faut ensuite créer le dépôt git. Pour l'instant, c'est encore géré de façon manuelle... Mais, pour vous, il faut juste installer l'outil "fedpkg", dont vous aurez besoin ensuite de toute façon, et de faire :

fedpkg request-repo [NOM DU PAQUET] [NUMÉRO DU TICKET BUGZILLA]
fedpkg request-branch --repo [NOM DU PAQUET] [NOM D'UNE SEULE BRANCHE]

Répétez request-branch avec toutes les branches que vous voulez maintenir (sauf rawhide), en ce moment, ça serait sûrement f33 et f32 (ne pas oublier le "f"). Si vous voulez en plus une branche EPEL, pour créer des paquets pour RHEL, CentOS, Rocky Linux (bientôt), Oracle et autres... C'est des branches epel8, epel7 etc... Les branches EPEL sont optionnelles, les branches Fedora obligatoires.

Ça prend quelques heures pour que le dépôt soit créé. Et à ce point, il est rare, voir quasi-impossible, que ça soit refusé.

Pour faire cela, il faut s'assurer d'avoir une clé API de Pagure pour pouvoir créer le ticket ici. Cela est expliqué lorsque vous lancerez la commande si ça n'est pas le cas !

Deuxième Étape : Le Premier Paquet

Bien, vous avez maintenant votre beau petit dépôt git, qu'à vous, où vous gèrerait tout sur votre paquet !

Cloner le dépôt

Il faut bien sûr cloner le dépôt tongue !

fedpkg clone [NOM DU DÉPÔT]

Importer le paquet

Il faut importer le paquet une première fois ! Pour cela, rien de plus simple ! Il faut néanmoins que vous ayez ajouté votre clé SSH dans votre compte FAS.

fedpkg import [SRPM]

Ensuite, il faut l'envoyer dans le dépôt, autrement dire, le commit et le push, si vous vous y connaissez en git !

fedpkg commit -m "Initial import"
fedpkg push

Koji et la construction du paquet

Koji est le logiciel de Fedora qui construit tous les paquets grâce à mock, les signes, et les prépare à l'envoi à Bodhi ! Comment construire votre paquet me diriez-vous ? Rien de plus simple grâce à fedpkg !

fedpkg build

La commande "koji" disponible dans les dépôts de Fedora est aussi très pratique, permettant aussi de créer des scratch builds, qui ne sont que des builds de test, et de télécharger des builds d'autres personnes ! N'importe qui peut créer des scratch build de n'importe quel SRPM (néanmoins, les builds normaux doivent être fait par le packager).

Bodhi et la mise à jour

Ceci est une partie TRÈS intéressante... Ne vous êtes-vous jamais demandé comment Fedora parvient à avoir tant de stabilité avec des logiciels toujours à jour ? Et bah, tout cela tient en la magie de Bodhi !

Bodhi est le logiciel s'occupant de mettre à jour les dépôts et de proposer une interface à tout le monde pour tester les mises à jour ! En effet, quand vous mettez à jour un logiciel, ce dernier reste dans les dépôts "testing" pendant au moins 7 jours (sauf si c'est une branche de développement) (ou 14 jours si c'est une mise à jour très importante) ou jusqu'à ce qu’au moins 2 personnes ont testé la mise à jour (vous pouvez abaisser ça à 1 personne). Pendant cette période, tout le monde peut tester la mise à jour. Après cette période, la mise à jour devient stable et entre dans les dépôts "update" où tout le monde peut l'essayer.

Prenons un exemple, cette mise à jour aléatoire. Une commande y est proposé pour tester la mise à jour, certains y réagissent, jusqu'à ce que la mise à jour soit devenu stable !

En plus, Bodhi permet aussi de coordonner les mises à jour, quand par exemple une librairie est mise à jour, et qu'il y a besoin que toutes les dépendances le soient aussi. Cette mise à jour par exemple ! Quand une nouvelle mise à jour de KDE a été présenté et 46 paquets ont été mis à jour simultanément !

Néanmoins, Bodhi n'est pas utilisé pour Rawhide, mais, il l'est pour les bêta, avec juste 4 jours à la place.

Donc, sauf si vous êtes sur la branche de Rawhide, pour envoyer le paquet à bodhi, il faut faire :

fedpkg update --type newpackage --bugs [NUMÉRO DU TICKET BUGZILLA] --notes "Initial release"

Refaire tout ça pour toutes les branches

Bien, vous avez envoyé votre paquet ! Mais qu'à Rawhide pour l'instant ! Chaque version de Fedora est considéré comme une branche git différente. Tout ce que vous avez fait été sur la branche "rawhide" (l'équivalent de la branche "master" pour Fedora), mais il vous faut refaire ça pour "f33" et "f32" (et faire Bodhi pour la première fois, vu que cela ne s'appliquait pas à Rawhide).

Pour changer de branche :

fedpkg switch-branch [NOM DE LA BRANCHE]

Pour reprendre les changements de la branche Rawhide sans tout réimporter :

git merge rawhide

Ensuite, faites un push, un build et un update (pas besoin de faire un commit).

Et n'oubliez pas à la fin de revenir à la branche principale après avoir fini tout, pour pas que vous ne faites des changements à la mauvaise branche :

fedpkg switch-branch rawhide

Conclusion

C'était dur n'est-ce pas ? Ne vous inquiétez pas, tout la suite en comparaison est bien plus simple ! Et après que le paquet soit enfin envoyé une première fois dans les dépôt, tout devient plus simple !

Techniquement, vous pourriez tout arrêter là, sans connaître la suite, et à chaque mise à jour, vous pourriez recréer un SRPM et le réimporter dans les dépôts et tout refaire, mais sachez qu'il est bien plus simple de le faire autrement après la première mise à jour !

Dernière modification par Lyes Saadi (17/01/2021 01:11:02)


Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#3 15/01/2021 02:26:12

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

(J'ai mis à jour mon post)


Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#4 15/01/2021 09:22:10

nouvo09
Accro à Fedo !
Lieu : Paris
Inscription : 22/09/2005
Messages : 22 915

Re : Un peu perdu (voir beaucoup) pour contribuer.

Excellent.

Je pense qu'un tel article a largement sa place dans la doc.


C'est pas parce que c'est difficile qu'on n'ose pas,
c'est parce qu'on ose pas que c'est difficile !

Hors ligne

#5 15/01/2021 12:00:51

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Ouhaaaa, un grand merci, vraiment, bon j'admets que j'ai du mal à encaisser tout ça, ça me parait compliqué même par rapport à Debian et surtout par rapport à ce qui se fait chez openSUSE pint  Mais clairement c'est un post qu'il faut mettre en avant et mériterai bien une place dans la documentation!

J'ai hate de voir la suite, par contre j'ai du coup et au vu de tout ce qu'il faut faire pour un seul paquet, peur de me lancer. C'est surtout au vu des logiciels à lancer, des étapes, des scripts, j'ai un peu peur de ne pas être à la hauteur. On verra bien, je vais regarder un paquet orphelin pour voir en espérant que c'est les mêmes étapes.

Encore une fois, j'espère que tu mettra ton post dans la doc c'est bien plus compréhensible que la doc officielle (en anglais) enfin je trouve.

Dernière modification par seb95 (15/01/2021 12:03:55)

Hors ligne

#6 15/01/2021 12:10:42

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Et pour l'attente de ton paquets ce n'est rien, chez Debian ça va vraiment plus doucement pour un premier paquet:

https://passiongnulinux.tuxfamily.org/p … ns-debian/

Les étapes de “debianisation” de ce programme ont mit 9 mois entre le moment du premier rapport de bug #894260 et l’arrivée du paquet dans Sid, mais seulement 2 mois si on compte le moment où FTP Master le met en attente et l’acceptation dans Sid.

Bien amicalement.

Hors ligne

#7 15/01/2021 15:40:09

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Je fais un copié collé de ton post en markdown, ça te dérange que je le post en ton nom sur mon blog?

Hors ligne

#8 15/01/2021 16:04:35

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Ça ne me dérange pas, mais attend juste que je finisse de l'écrire hammer !

Dernière modification par Lyes Saadi (15/01/2021 16:05:21)


Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#9 15/01/2021 16:45:01

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Oki, pour le moment le draft est là:

https://passiongnulinux.tuxfamily.org/d … ction.html

Dernière modification par seb95 (15/01/2021 23:06:19)

Hors ligne

#10 17/01/2021 03:34:29

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

[Je continue le reste ici]

Troisième Étape : La Mise À Jour

Bien, maintenant qu'on a importé le paquet une première fois, comment faire pour le maintenir à jour ?

Mettre à jour le fichier SPEC

Pour mettre à jour le paquet, il faut se rappeler trois étapes importantes :

  1. Mettre à jour la version du paquet

  2. Réinitialiser le release du paquet à 1

  3. Ajouter une note de version dans la partie changelog

Pour rapidement faire ça, une commande est à disposition :

rpmdev-bumpspec -n [VERSION] -c "Updating to [VERSION]"

Télécharger les nouvelles sources et le lookaside cache

Après avoir mis à jour la version, et à condition que les Sources soient des URLs et qu'elles soient dynamiquement mis à jour grâce aux macros de version, il est trivial de rapatrier les sources grâce à une simple commande :

spectool -g [SPEC]

Ensuite, il faut téléverser ces sources au "lookaside cache" grâce à cette commande :

fedpkg new-sources [SOURCES...]

Le lookaside cache est l'emplacement où sont stockés l'ensemble des sources des logiciels. Il est aussi possible de stocker certain patch et fichiers dans le dépôt git, dans ce cas-là mettre le nom du patch/fichier suffit. Mais pour ces derniers, cela doit se limiter aux fichiers spécifiques à Fedora, comme des README personnalisés, des patchs pour résoudre des problèmes spécifiques et tout autre fichiers qui ne proviennent pas du projet officiel.

Tester la nouvelle version

S'assurer que sa mise à jour compile bien et que le logiciel marche toujours est une tâche importante du packager, surtout quand il y a des changements significatifs. Une commande heureusement permet de facilement faire tout cela grâce à mock :

fedpkg mockbuild

Le résultat de la construction se trouvera à "results_[NOM]/[VERSION]/[RELEASE]/"

Envoyer ses mises à jour

git add .
fedpkg ci -c
fedpkg push

La première commande n'est rien d'inconnu si vous vous y connaissez en git et on a déjà vu la dernière ! Mais qu'en est il de "fedpkg ci -c" ? "fedpkg ci" n'est qu'un simple raccourcis pour "fedpkg commit", et l'option "-c" permet d'utiliser la dernière note de version du RPM comme un message pour git !

Construire et mettre à jour votre paquet

Nous avons déjà vu ces commandes, il n'est pas nécessaire de les réexpliquer. Mais, regarder la page d'aide de "fedpkg update", cette dernière contient d'intéressantes options !

fedpkg build
fedpkg update --type enhancement --notes "Updating to [VERSION]"

Conclusion

Et voilà, c'est tout ! Il faut bien sûr mettre aussi à jour toutes les autres branches que nous souhaitons de la même façon que l'on a fait auparavant. Mais, il est simple d'enchaîner les commandes :

fedpkg switch-branch [BRANCHE] && git merge master && fedpkg push && fedpkg build && fedpkg update --type enhancement --notes "Updating to [VERSION]"
Quatrième Étape : Et Si On Automatisait Tout ? Présentation de fbrnch !

Qu'est-ce donc fbrnch ? C'est un logiciel permettant d'automatiser une pléthore de tâches communes d'un packager ! Crée par Jens Petersen, elle permet de facilement mettre à jour des logiciels à travers plusieurs branches en parallel ! Et de créer facilement de nouvelles demande de création de paquet !

Installation

Rien de plus simple, un dépôt COPR est à disposition !

sudo dnf copr enable petersen/fbrnch && sudo dnf install fbrnch

Créer une demande de création de paquet

Faire une demande n'a jamais été aussi simple :

fedpkg create-review [SPEC]

C'est tout hammer ! Oui ! Vraiment !

Et pour mettre à jour le ticket avec un nouveau fichier SPEC :

fedpkg update-review [SPEC]

Néanmoins, cela ne marchera pas si vous n'êtes pas déjà packager ou contributeur officiel à Fedora ! Vu qu'il va devoir utiliser fedorapeople.org qui n'est disponible qu'à ceux qui sont contributeur et membre d'au moins un des groupes de contributeurs de Fedora (Packager, Design, Traduction, etc...).

Mettre à jour un logiciel

Il est toujours nécessaire de manuellement mettre à jour le fichier SPEC, de télécharger les nouvelles sources, de les envoyer au cache, de tester le nouveau paquet et de commit tout cela, en tout cas, au moment où j'écris ces lignes, vu que ce logiciel est

Mais, à la place de devoir construire et mettre à jour le paquet pour toutes les branches, ceci suffit :

fbrnch build --all-branches --update-type enhancement -m

Et c'est tout ! Veuillez néanmoins noter que fbrnch demande de temps en temps des interactions par l'utilisateur avant de faire quelque chose de dangereux !

fbrnch contient néanmoins plein d'autres commandes plus avancées pour se faciliter la vie qui ne sont pas de l'ordre du jour. Mais n'hésitez pas à y jeter un coup d'œuil !


Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#11 17/01/2021 04:14:36

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Au passage, pour t'aider dans ton Blog, voici mes messages en "BBCode":

Alors, oui, l'écosystème Fedora est....... riche :-P ! Laisse-moi te faire un tour d'horizon !

Comment un paquet voyage-t-il donc pour arriver dans les repository ? C'est pas si complexe en faite !

[h]Première Étape : La Validation[/h]

Avant qu'un paquet arrive dans Fedora, il faut que ce dernier soit validé, jusque-là, rien d'excentrique !

Il faut en premier lieu créer un fichier SPEC et un SRPM. Il est aussi préférable de créer un projet COPR pour le nouveau paquet.

Il faut s'assurer que le paquet n'existe pas et n'a jamais existé auparavant dans Fedora. Sinon, les procédures sont différentes (ouvrez un nouveau sujet pour cela :-P !). Pour vérifier ça, cherchez si un paquet existe dans [url=https://src.fedoraproject.org/]le SCM[/url].

[b]Le Bugzilla[/b]

Tout nouveau paquet doit passer par le Bugzilla de Fedora/Red Hat. Il faut créer un [url=https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-review]ticket spécial[/url] où on y fait référence aux URL de notre SPEC et SPRM, une description du paquet (généralement celle qui se trouve dans le fichier SPEC), le nom d'utilisateur dans le FAS, Fedora Account System, celui qui vous permet d'avoir accès à COPR et Bugzilla, ainsi que, si possible, un build dans COPR et/ou un build "brouillon" (scratch) dans Koji (qui sera expliqué plus tard). Voici un exemple de [url=https://bugzilla.redhat.com/show_bug.cgi?id=1825560]demande de création de paquet[/url]. N'importe qui, qui est packager, peut l'accepter (vous pouvez même vous échanger des tickets sur la mailing liste à toujours condition d'être déjà packager). Normalement, cela ne prend que quelques jours pour une réponse, j'ai même eu des paquets approuvé le jour même. Néanmoins, dans certaines périodes, ça peut durer beaucoup plus longtemps. Mais, ça ne devrait pas durer plus d'un mois. D'ailleurs, la demande que je viens de vous donner était celle pour laquelle j'aurais dû attendre le plus longtemps.

Par contre, si vous n'êtes pas Packager, vous [b]devez[/b] le préciser et vous [b]devez[/b] ajouter "FE-NEEDSPONSOR" dans la cellule "Blocks" (pour ce dernier, ça se fait après avoir créé le ticket seulement). Seul un sponsor peut vous faire entrer à ce point, il vous fera d'ailleurs sûrement passer un petit test :-P (Surtout si c'est celui que je pense, Robert André Mauchin (eclipseo) ;-)...) ! Il est aussi recommandé de se présenter sur la mailing liste "devel" et de s'y inscrire (faites-vous d'ailleurs peut-être une autre addresse si vous en avez l'occasion vu la quantité de mail par jour) tout en y incluant votre première demande de paquet. Le sujet du mail devrait être "Self Introduction: [Nom et Prénom]". Voici les liens pour [url=https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/]s'inscrire à la mailing liste[/url] ainsi que [url=https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/]les archives[/url] ! Il est plutôt important de suivre au moins sommairement la mailing liste, vu qu'elle contient des informations sur absolument tout ce qui se passe dans Fedora, mais ça n'est pas obligatoire (mais vraiment conseillé).

Ensuite......................... Il faut attendre. C'est plus long que si on est déjà packager puisque la personne devant vous accepter devra être un sponsor. Voici [url=https://bugzilla.redhat.com/show_bug.cgi?id=1767998]mon premier ticket par exemple[/url] !

[b]L'examen[/b]

Ensuite, le paquet devra être méticuleusement examiné par la personne qui aura choisi de le faire, pour s'assurer que votre paquet suis les guidelines. S'il vous fait des remarques, vous devrez y répondre. Généralement, c'est fait à partir d'une check liste généré quasi-automatiquement par un outil génial, que vous pouvez installer, fedora-review. Il génère un rapport quasi-complet sur votre paquet, et demande quelques vérifications manuelles de la part de celui qui vous examinera !

C'est une bonne idée de ce faire un auto-examen (mais ne pensez pas vous auto-approuver pour autant :hammer:) !

Dès qu'il n'y aura plus aucun problème avec votre paquet, ce dernier sera approuvé !

[b]La création du dépôt git dans le SCM[/b]

Il faut ensuite créer le dépôt git. Pour l'instant, c'est encore géré de façon manuelle... Mais, pour vous, il faut juste installer l'outil "fedpkg", dont vous aurez besoin ensuite de toute façon, et de faire :

[code]
fedpkg request-repo [NOM DU PAQUET] [NUMÉRO DU TICKET BUGZILLA]
fedpkg request-branch --repo [NOM DU PAQUET] [NOM D'UNE SEULE BRANCHE]
[/code]

Répétez request-branch avec toutes les branches que vous voulez maintenir (sauf rawhide), en ce moment, ça serait sûrement f33 et f32 (ne pas oublier le "f"). Si vous voulez en plus une branche EPEL, pour créer des paquets pour RHEL, CentOS, Rocky Linux (bientôt), Oracle et autres... C'est des branches epel8, epel7 etc... Les branches EPEL sont optionnelles, les branches Fedora obligatoires.

Ça prend quelques heures pour que le dépôt soit créé. Et à ce point, il est rare, voir quasi-impossible, que ça soit refusé.

Pour faire cela, il faut s'assurer d'avoir une clé API de [url=https://pagure.io/]Pagure[/url] pour pouvoir créer le ticket [url=https://pagure.io/releng/fedora-scm-requests/issues]ici[/url]. Cela est expliqué lorsque vous lancerez la commande si ça n'est pas le cas !

[h]Deuxième Étape : Le Premier Paquet[/h]

Bien, vous avez maintenant votre beau petit dépôt git, qu'à vous, où vous gèrerait tout sur votre paquet !

[b]Cloner le dépôt[/b]

Il faut bien sûr cloner le dépôt :-P !
[code]fedpkg clone [NOM DU DÉPÔT][/code]

[b]Importer le paquet[/b]

Il faut importer le paquet une première fois ! Pour cela, rien de plus simple ! Il faut néanmoins que vous ayez ajouté votre clé SSH dans votre compte FAS.
[code]fedpkg import [SRPM][/code]

Ensuite, il faut l'envoyer dans le dépôt, autrement dire, le commit et le push, si vous vous y connaissez en git !
[code]
fedpkg commit -m "Initial import"
fedpkg push
[/code]

[b]Koji et la construction du paquet[/b]

[url=https://koji.fedoraproject.org/]Koji[/url] est le logiciel de Fedora qui construit tous les paquets grâce à mock, les signes, et les prépare à l'envoi à Bodhi ! Comment construire votre paquet me diriez-vous ? Rien de plus simple grâce à fedpkg !
[code]fedpkg build[/code]

La commande "koji" disponible dans les dépôts de Fedora est aussi très pratique, permettant aussi de créer des scratch builds, qui ne sont que des builds de test, et de télécharger des builds d'autres personnes ! N'importe qui peut créer des scratch build de n'importe quel SRPM (néanmoins, les builds normaux doivent être fait par le packager).

[b]Bodhi et la mise à jour[/b]

Ceci est une partie TRÈS intéressante... Ne vous êtes-vous jamais demandé comment Fedora parvient à avoir tant de stabilité avec des logiciels toujours à jour ? Et bah, tout cela tient en la magie de Bodhi !

[url=https://bodhi.fedoraproject.org/]Bodhi[/url] est le logiciel s'occupant de mettre à jour les dépôts et de proposer une interface à tout le monde pour tester les mises à jour ! En effet, quand vous mettez à jour un logiciel, ce dernier reste dans les dépôts "testing" pendant au moins 7 jours (sauf si c'est une branche de développement) (ou 14 jours si c'est une mise à jour très importante) ou jusqu'à ce qu’au moins 2 personnes ont testé la mise à jour (vous pouvez abaisser ça à 1 personne). Pendant cette période, tout le monde peut tester la mise à jour. Après cette période, la mise à jour devient stable et entre dans les dépôts "update" où tout le monde peut l'essayer.

Prenons un exemple, [url=https://bodhi.fedoraproject.org/updates/FEDORA-2021-9b7b3599be]cette mise à jour aléatoire[/url]. Une commande y est proposé pour tester la mise à jour, certains y réagissent, jusqu'à ce que la mise à jour soit devenu stable !

En plus, Bodhi permet aussi de coordonner les mises à jour, quand par exemple une librairie est mise à jour, et qu'il y a besoin que toutes les dépendances le soient aussi. [url=https://bodhi.fedoraproject.org/updates/FEDORA-2021-5da509fd8e]Cette mise à jour[/url] par exemple ! Quand une nouvelle mise à jour de KDE a été présenté et 46 paquets ont été mis à jour simultanément !

Néanmoins, Bodhi n'est pas utilisé pour Rawhide, mais, il l'est pour les bêta, avec juste 4 jours à la place.

Donc, sauf si vous êtes sur la branche de Rawhide, pour envoyer le paquet à bodhi, il faut faire :
[code]
fedpkg update --type newpackage --bugs [NUMÉRO DU TICKET BUGZILLA] --notes "Initial release"
[/code]

[b]Refaire tout ça pour toutes les branches[/b]

Bien, vous avez envoyé votre paquet ! Mais qu'à Rawhide pour l'instant ! Chaque version de Fedora est considéré comme une branche git différente. Tout ce que vous avez fait été sur la branche "rawhide" (l'équivalent de la branche "master" pour Fedora), mais il vous faut refaire ça pour "f33" et "f32" (et faire Bodhi pour la première fois, vu que cela ne s'appliquait pas à Rawhide).

Pour changer de branche :
[code]fedpkg switch-branch [NOM DE LA BRANCHE][/code]

Pour reprendre les changements de la branche Rawhide sans tout réimporter :
[code]git merge rawhide[/code]

Ensuite, faites un push, un build et un update (pas besoin de faire un commit).

Et n'oubliez pas à la fin de revenir à la branche principale après avoir fini tout, pour pas que vous ne faites des changements à la mauvaise branche :
[code]fedpkg switch-branch rawhide[/code]

[b]Conclusion[/b]

C'était dur n'est-ce pas ? Ne vous inquiétez pas, tout la suite en comparaison est bien plus simple ! Et après que le paquet soit enfin envoyé une première fois dans les dépôt, tout devient plus simple !

Techniquement, vous pourriez tout arrêter là, sans connaître la suite, et à chaque mise à jour, vous pourriez recréer un SRPM et le réimporter dans les dépôts et tout refaire, mais sachez qu'il est bien plus simple de le faire autrement après la première mise à jour !

[h]Troisième Étape : La Mise À Jour[/h]

Bien, maintenant qu'on a importé le paquet une première fois, comment faire pour le maintenir à jour ?

[b]Mettre à jour le fichier SPEC[/b]

Pour mettre à jour le paquet, il faut se rappeler trois étapes importantes :
[list=1]
[*]Mettre à jour la version du paquet[/*]
[*]Réinitialiser le release du paquet à 1[/*]
[*]Ajouter une note de version dans la partie changelog[/*]
[/list]

Pour rapidement faire ça, une commande est à disposition :
[code]rpmdev-bumpspec -n [VERSION] -c "Updating to [VERSION]"[/code]

[b]Télécharger les nouvelles sources et le lookaside cache[/b]

Après avoir mis à jour la version, et à condition que les Sources soient des URLs et qu'elles soient dynamiquement mis à jour grâce aux macros de version, il est trivial de rapatrier les sources grâce à une simple commande :
[code]spectool -g [SPEC][/code]

Ensuite, il faut téléverser ces sources au "lookaside cache" grâce à cette commande :
[code]fedpkg new-sources [SOURCES...][/code]

[url=https://src.fedoraproject.org/lookaside/pkgs/]Le lookaside cache[/url] est l'emplacement où sont stockés l'ensemble des sources des logiciels. Il est aussi possible de stocker certain patch et fichiers dans le dépôt git, dans ce cas-là mettre le nom du patch/fichier suffit. Mais pour ces derniers, cela doit se limiter aux fichiers spécifiques à Fedora, comme des README personnalisés, des patchs pour résoudre des problèmes spécifiques et tout autre fichiers qui ne proviennent pas du projet officiel.

[b]Tester la nouvelle version[/b]

S'assurer que sa mise à jour compile bien et que le logiciel marche toujours est une tâche importante du packager, surtout quand il y a des changements significatifs. Une commande heureusement permet de facilement faire tout cela grâce à mock :
[code]fedpkg mockbuild[/code]

Le résultat de la construction se trouvera à "results_[NOM]/[VERSION]/[RELEASE]/"

[b]Envoyer ses mises à jour[/b]

[code]
git add .
fedpkg ci -c
fedpkg push
[/code]

La première commande n'est rien d'inconnu si vous vous y connaissez en git et on a déjà vu la dernière ! Mais qu'en est il de "fedpkg ci -c" ? "fedpkg ci" n'est qu'un simple raccourcis pour "fedpkg commit", et l'option "-c" permet d'utiliser la dernière note de version du RPM comme un message pour git !

[b]Construire et mettre à jour votre paquet[/b]

Nous avons déjà vu ces commandes, il n'est pas nécessaire de les réexpliquer. Mais, regarder la page d'aide de "fedpkg update", cette dernière contient d'intéressantes options !
[code]
fedpkg build
fedpkg update --type enhancement --notes "Updating to [VERSION]"
[/code]

[b]Conclusion[/b]

Et voilà, c'est tout ! Il faut bien sûr mettre aussi à jour toutes les autres branches que nous souhaitons de la même façon que l'on a fait auparavant. Mais, il est simple d'enchaîner les commandes :
[code]fedpkg switch-branch [BRANCHE] && git merge master && fedpkg push && fedpkg build && fedpkg update --type enhancement --notes "Updating to [VERSION]"[/code]

[h]Quatrième Étape : Et Si On Automatisait Tout ? Présentation de fbrnch ![/h]

Qu'est-ce donc [url=https://github.com/juhp/fbrnch#readme]fbrnch[/url] ? C'est un logiciel permettant d'automatiser une pléthore de tâches communes d'un packager ! Crée par Jens Petersen, elle permet de facilement mettre à jour des logiciels à travers plusieurs branches en parallel ! Et de créer facilement de nouvelles demande de création de paquet !

[b]Installation[/b]

Rien de plus simple, [url=https://copr.fedorainfracloud.org/coprs/petersen/fbrnch/]un dépôt COPR[/url] est à disposition !
[code]
sudo dnf copr enable petersen/fbrnch && sudo dnf install fbrnch
[/code]

[b]Créer une demande de création de paquet[/b]

Faire une demande n'a jamais été aussi simple :
[code]fedpkg create-review [SPEC][/code]

C'est tout :hammer: ! Oui ! Vraiment !

Et pour mettre à jour le ticket avec un nouveau fichier SPEC :
[code]fedpkg update-review [SPEC][/code]

Néanmoins, cela ne marchera pas si vous n'êtes pas déjà packager ou contributeur officiel à Fedora ! Vu qu'il va devoir utiliser fedorapeople.org qui n'est disponible qu'à ceux qui sont contributeur et membre d'au moins un des groupes de contributeurs de Fedora (Packager, Design, Traduction, etc...).

[b]Mettre à jour un logiciel[/b]

Il est toujours nécessaire de manuellement mettre à jour le fichier SPEC, de télécharger les nouvelles sources, de les envoyer au cache, de tester le nouveau paquet et de commit tout cela, en tout cas, au moment où j'écris ces lignes, vu que ce logiciel est 

Mais, à la place de devoir construire et mettre à jour le paquet pour toutes les branches, ceci suffit :
[code]fbrnch build --all-branches --update-type enhancement -m[/code]

Et c'est tout ! Veuillez néanmoins noter que fbrnch demande de temps en temps des interactions par l'utilisateur avant de faire quelque chose de dangereux !

fbrnch contient néanmoins plein d'autres commandes plus avancées pour se faciliter la vie qui ne sont pas de l'ordre du jour. Mais n'hésitez pas à y jeter un coup d'œuil !

Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#12 17/01/2021 15:25:40

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Coucou Lyes Saadi :)

Merci pour tout ça, j'ai lu avec passion ce que tu as écris, c'est énorme!
C'est compréhensible et sans paraitre simple c'est quand même faisable.

Sans juger, je trouve quand même que Fedora se complique la vie pour pas grand chose en regardant ce qui se fait chez le cousin openSUSE :). Je vais juste faire un exemple avec un paquet que je maintiens.

Donc pour Ghotwriter, on doit déjà faire une demande de compte pour le OBS, on installe OSC sur notre machine (mais on peut se contenter de le faire graphiquement avec l'interface de OBS), je vais me contenter de OBS et de faire comme si on reprenait un paquet déjà dans les dépôts mais pas à jour.

Premièrement, on clone le dépôt devel de ghostwriter, ensuite on change les sources (rapatrie les nouvelles sources) et on change le spec et le changelog. Encore une fois on peut tout faire depuis sa machine en local (avec les outils spectool et rpmdev comme je l'ai découvert si tard grâce à toi :) ).

Puis on clique sur proposer le paquet. Et c'est tout!! Après il faut qu'une personne habilité fasse la vérification et accepte mais ça va très vite (dans les heures qui suivent voir ma première demande faite le 09/04/18 à 11:40 accepté à 11:55 du même jour)

OBS facilite la vie vraiment coté packager, tout en évitant pas le coté manuelle si on veut le faire avec les outils de rpmdev.

Après je peux parler aussi de Debian,  pour le peu que je connais, c'est assez ressemblant à Fedora dans le principe construction sur notre machine, avec debuild des outils devscripts et debhelper.

Je ne parle que en temps que contributeur et non développeur Debian, car bien que je maintienne un paquet ou deux chez Debian, je ne suis qu'un simple contributeur et je dois toujours passer par un sponsor pour mon travail et ce malgré que j'en suis le mainteneur officiel.

En gros, je survole pour montrer que ça ressemble en partie à ce que fait Fedora, on installe les devscripts:

# apt install devscripts

On fait notre source de paquets avec les outils qui vont bien (debhelper). une fois qu'on a fait le paquet et après l'avoir testé, on doit l'envoyer quelque part qui permet de le faire tester et approuver par un dev Debian, dans notre cas, le plus facile est de le faire chez Debian-mentors.

Il faut bien sur avoir un clé gpg, puis se faire un compte avec dessus (et avoir signé son paquet avec), de la on ouvre un ticket, pardon un bug avec le BTS et pour se faire on peut  se faciliter la vie avec reportbug. Et là comme c'est un première demande de paquet non encore inclus dans les sources c'est long... La mienne à duré 9 mois depuis le rapport de bug (la demande initiale) et l'inclusion dans SID (voir https://passiongnulinux.tuxfamily.org/p … s-debian/).

Après ça va très vite pour les prochaines versions, de l'ordre de la journée, faut se rappeler que je n'ai pas le status de développeur  juste de contributeur et de mainteneur de mes paquets donc j'ai besoin d'avoir un sponsor.

Je vais quand même me lancer et tester, pourquoi pas, ça serait dommage de ne pas tenter avec tout le taff de documentation que tu as fait.

Il n'y a pas dans l'absolu, une tentative de simplifier les choses?

Hors ligne

#13 17/01/2021 15:48:17

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

seb95 a écrit :

Il n'y a pas dans l'absolu, une tentative de simplifier les choses?

En faite, tout le travail des dernières années dans Fedora est de simplifier la charge de travail des packagers.

fbrnch en est le parfait exemple ! Il y a aussi des tentatives pour supprimer la changelog et le remplacer par les messages de commit git, d'autres pour simplifier la création de nouveaux spec, ou encore les macros %forge qui simplifient la vie.

La raison pour laquelle la barre de contribution est si haute est pour s'assurer de la qualité des paquets et logiciels dans Fedora. C'est grâce à ça que Fedora est réputé pour sa stabilité tout en étant "bleeding-edge".

OpenSUSE n'a pas vraiment ces contraintes, ni Debian, ces distributions sont soit rolling-release ou ne suivent pas une cadence de mise à jour biannuelle, et n'ont pas comme promesse d'être toujours une vitrine de ce qui se fait de nouveau. Voilà pourquoi Bodhi existe par exemple.

De plus, Fedora maintient simultanément plusieurs Branches en même temps (actuellement: f32, f33, rawhide et très bientôt f34), quand pour OpenSUSE par exemple, il n'y a pas ce problème. Pareil pour Debian qui dès qu'une nouvelle version est sortie, les anciennes ne sont que mis à jour pour des corrections de bugs importants et pour les problèmes de sécurité.

Fedora donne aussi énormément de liberté aux packagers après l'approbation de leur paquet. Ils peuvent facilement packager pour de nouvelles branches, ouvrir leurs paquets à EPEL ou même facilement créer des Flatpak à partir des modules RPMs. Et tout cela, sans devoir demander à quelqu'un qu'il n'approuve quoi que ce soit en amont.


Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#14 17/01/2021 16:46:57

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Oui en effet j'ai vu qu'il y avait des choses faites pour simplifier la chose, j'avais cru comprendre que Copr en était un parmi tant d'autre.

Surtout ne pas prendre mon post comme une critique, c'était pas le but, c’était plutôt un étonnement vis-à-vis du travail pour faire juste un paquet.

La raison pour laquelle la barre de contribution est si haute est pour s'assurer de la qualité des paquets et logiciels dans Fedora. C'est grâce à ça que Fedora est réputé pour sa stabilité tout en étant "bleeding-edge".

Je me doutais un peu de ça, ça démotive un peu (beaucoup) de suite de nombreux possibles contributeurs dont moi, je l'avoue, ne me sentant pas capable d'utiliser le nombre de programmes/scripts/autres que tu cites, mais je vais tenter de m'y atteler car j'apprécie ce que j'ai en ce moment et pour la première fois, j’apprécie Fedora! De plus vu ce que tu as  fait pour me faire comprendre tout ça je dois au moins tenter une fois. Même si je suis plus dans la maintenance de paquets, j'irais voir les paquets orphelin (j'ai toujours du mal à les trouver chez fedora car une recherche m’envoie dans DNF et la suppression des paquets orphelins et non les paquets orphelins sans mainteneurs.).

fbrnch en est le parfait exemple ! Il y a aussi des tentatives pour supprimer la changelog et le remplacer par les messages de commit git, d'autres pour simplifier la création de nouveaux spec, ou encore les macros %forge qui simplifient la vie.

J'ai vu un projet github s'appelant autospec, qui permettrait en combinant diverses choses de trouver comment faire les sections %prep %build %install automatiquement.
Mais le sujet n'est pas là.

De plus, Fedora maintient simultanément plusieurs Branches en même temps (actuellement: f32, f33, rawhide et très bientôt f34), quand pour OpenSUSE par exemple, il n'y a pas ce problème. Pareil pour Debian qui dès qu'une nouvelle version est sortie, les anciennes ne sont que mis à jour pour des corrections de bugs importants et pour les problèmes de sécurité.

Pour Debian oui mais openSUSE maintient ses versions 18 mois chacune ce qui fait actuellement 15.1 - 15.2 - tumbleweed - factory et bientôt 15.3 en plus des version SUSE Entreprise puisqu'il y a eu un rapprochement pour fusionner le code de leap (openSUSE) et de SLE (SUSE), mais le problème ne se pose pas, car OBS compile et fabrique le paquet pour chaque version, suffit juste de balancer les sources et le spec et lui fait le reste, j'explique mal, mais OBS est un truc vraiment pas mal et je reste étonné de voir que personne que ce soit Mageia qui préfère Copr me semble t'il et/ou surtout Fedora n'aient pensé à l'utiliser. Je ne dis pas que ça change drastiquement les choses (quoique pour moi oui), mais ça simplifie la tache des mainteneurs et surtout ça simplifie l’accès aux nouveaux contributeurs.

Par exemple j'ai vu que Debian, du moins un dev de chez eux avait envisagé de passer par OBS et démontrait le temps gagné et les ressources. https://passiongnulinux.tuxfamily.org/p … conomiser/

De mon coté, pour debian je build chez moi avec pbuilder puis je balance chez debian pour que ça soit prit en compte de manière officiel, mais je balance aussi sur mon OBS pour
mes paquets non officiels (et officiels aussi) pour les rendre plus facilement accessible.

Du reste, un truc qui n'a rien à voir, mais a quoi sert le compte fedora dans la configuration des comptes en lignes de Gnome? j'ai beau entrer mon FAS ça ne le prend pas...

Hors ligne

#15 17/01/2021 16:54:23

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

seb95 a écrit :

J'ai vu un projet github s'appelant autospec, qui permettrait en combinant diverses choses de trouver comment faire les sections %prep %build %install automatiquement.
Mais le sujet n'est pas là.

Je pensais à rpm-spec-wizard wink (EDIT: Il y a des discussions pour l'intégrer dans COPR) !

seb95 a écrit :

Pour Debian oui mais openSUSE maintient ses versions 18 mois chacune ce qui fait actuellement 15.1 - 15.2 - tumbleweed - factory et bientôt 15.3 en plus des version SUSE Entreprise puisqu'il y a eu un rapprochement pour fusionner le code de leap (openSUSE) et de SLE (SUSE), mais le problème ne se pose pas, car OBS compile et fabrique le paquet pour chaque version, suffit juste de balancer les sources et le spec et lui fait le reste, j'explique mal, mais OBS est un truc vraiment pas mal et je reste étonné de voir que personne que ce soit Mageia qui préfère Copr me semble t'il et/ou surtout Fedora n'aient pensé à l'utiliser. Je ne dis pas que ça change drastiquement les choses (quoique pour moi oui), mais ça simplifie la tache des mainteneurs et surtout ça simplifie l’accès aux nouveaux contributeurs.

Je m'excuse, j'étais mal informé tongue ! Je croyais que Tumbleweed était où toute l'action se passait, puis que Leap prenait des "snapshot" de temps en temps à chaque fois, un peu comme la relation entre Fedora et RHEL.

seb95 a écrit :

Du reste, un truc qui n'a rien à voir, mais a quoi sert le compte fedora dans la configuration des comptes en lignes de Gnome? j'ai beau entrer mon FAS ça ne le prend pas...

C'est pour Kerberos, ça simplifie l'authentification avec Koji/Bodhi, pour ne pas avoir à mettre son mot de passe à chaque fois qu'on fait un build/màj. Sinon, ça sert à rien.

Il faut peut-être déjà être packager pour pouvoir l'utiliser ? J'en ai aucune idée, pour moi ça marche.

Dernière modification par Lyes Saadi (17/01/2021 16:56:20)


Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#16 17/01/2021 17:41:58

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Je m'excuse, j'étais mal informé tongue ! Je croyais que Tumbleweed était où toute l'action se passait, puis que Leap prenait des "snapshot" de temps en temps à chaque fois, un peu comme la relation entre Fedora et RHEL.

Il n'y a pas de mal ;)
En faite c'est bien plus compliqué mais la compléxité est caché par OBS.

Il y a pricipalement trois distributions, factory qui est l'équivalant de Debian ou de rawhide, c'est la que se passe les test, c'est la rolling de développement. Ensuite il y a tumbleweed qui est la rolling comme arch, mais pas une rolling de developpement. Puis il y a leap, qui est la fixed stable comme f33 ou encore Debian stable, c'est plus dans le sens debian car elle bouge peu et est assez vieillotte dans le sens qu'elle est de plus en plus dans un état d'esprit de SLES communautaire. Du reste les sources se construisent maintenant depuis les mêmes builds...

Et en faite c'est même pas dans factory que tout se passe, mais dans les différent dépôts comme par exemple editor: https://build.opensuse.org/package/show … hostwriter.
On peut voir dans cette page de ghostwriter, qu'il est construit dans "editor" avant d'aller dans factory, mais editor est disponible pour toutes les versions d'opensuse. Donc on peut tres bien faire notre paquet, l'envoyer dans editor (ou autre si c'est autre chose) et le rendre disponible pour chaque version d'openSUSE, comme par exemple leap 15.2.
Puis aprés au bout d'un certain temps, le paquet va dans factory automatiquement à moins que l'on le pousse... Puis ensuite quand la future leap se prépare, le paquet est poussé dedans, comme actuellement la future leap 15.3.

Aussi et je sais pas si je m'explique clairement, leap est bloqué, c'est rigide, puisque c'est la stable et qu'elle est censé n'avoir que des mise-à-jour de sécurité, mais on peut ajouter des dépôts dit "experimentales" qui sont en fait les dépôts cités plus haut dont editor fait partie, et donc avoir les dernières versions des paquets, que ce soit plasma-kde ou tout autre chose.

J'ai dans mes installations d'opensuse, les dernières versions de kde, kde-extra, pelican (pour mon blog) et différents paquets dont ceux qui sont dans mon home perso(l'équivalent de copr/utilisateur)...

C'est pour Kerberos, ça simplifie l'authentification avec Koji/Bodhi, pour ne pas avoir à mettre son mot de passe à chaque fois qu'on fait un build/màj. Sinon, ça sert à rien.

Il faut peut-être déjà être packager pour pouvoir l'utiliser ? J'en ai aucune idée, pour moi ça marche.

Bon, c'est peut être la raison du pourquoi ça marche pas chez moi ;).

Maintenant, je voudrais savoir une petite chose, pour les paquets abandonné, sans mainteneurs, comment ça se passe? C'est le même principe?

Hors ligne

#17 17/01/2021 18:04:50

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

seb95 a écrit :

Maintenant, je voudrais savoir une petite chose, pour les paquets abandonné, sans mainteneurs, comment ça se passe? C'est le même principe?

Alors, Fedora distingue entre 2 types de paquets abandonnés :

Les paquets orphelins

C'est un paquet qui a été récemment abandonné par un packager. N'importe quel packager peut l'adopter. Il faut juste qu'il aille sur le dépôt git du paquet en question, et qu'il le réclame en appuyant simplement sur un bouton, c'est tout !

Chaque semaine, sont annoncé les paquets qui ont le statut orphelin dans la mailing liste. Voici la dernière annonce. Il y est aussi annoncé tout les paquets impactés et leurs maintainers.

Il y a aussi un site web pour voir les paquets orphelins et ceux qui en dépendent.

Si un paquet reste orphelin pour six semaines, alors, ça devient un paquet retiré.

Les paquets retirés

Ces paquets sont supprimés des dépôts Rawhides et de toutes les versions de Fedora qui suivront. Ils sont soit des paquets orphelins depuis trop longtemps, ou des paquets qui ont été enlevé manuellement par leur maintainer.

Pour les réclamer, il faut créer un ticket dans le dépôt pagure releng indiquant le nom du paquet et les branches. De plus, si le paquet a été retiré depuis plus de 8 semaines, il faut aussi refaire une demande d'approbation du paquet comme si s'en était un nouveau. En effet, il est considéré que le paquet est sûrement à ce stade obsolète et il est donc nécessaire de le remettre en état vu que les Guidelines changent fréquemment.

Il est aussi conseillé d'annoncer sur la mailing liste quand on fait ré-approuver un paquet qui a été retiré !

Dernière modification par Lyes Saadi (17/01/2021 18:06:20)


Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#18 17/01/2021 18:16:16

Lyes Saadi
Un p'tit nouveau qui s'améliore :-P
Rédacteur Wiki
Lieu : 127.0.0.1
Inscription : 03/02/2018
Messages : 480
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Bien sûr, il faut déjà être packager pour faire tout ça (sauf dans les cas où il y a un ticket de ré-approbation à soumettre, vu que c'est identique à la création d'un paquet de zéro, à part pour le request-repo vu que le dépôt existe déjà et qu'il faut donc passer par releng).

Mais, dans ces cas, il est possible de contourner quelque peu les règles habituelles et à demander à devenir packager sans passer par un premier paquet ! Mais cela est plutôt rare... C'est plutôt réservé à ceux qui sont développeur du logiciel en question et qui souhaitent prendre en charge le maintien de leur propre logiciel. Il est très possible que quelqu'un qui ne soit pas nécessairement connu soit refusé et qu'il soit demandé de prouver qu'il comprenne les Guidelines.


Ceci n'est pas une signature.
Les développeurs C++ sont des terroristes.
Et Linux est meilleur que Windows. Ce sont des faits.

Hors ligne

#19 01/02/2021 16:56:57

seb95
Un Debianeu se fedorarisant :-)
Inscription : 08/01/2021
Messages : 26
Site Web

Re : Un peu perdu (voir beaucoup) pour contribuer.

Merci Lyes Saadi,

Désolé pour te répondre que maintenant, je n'avais pas vu la réponse et j'etais occupé à me battre sur autre chose ;).

Hors ligne

Pied de page des forums