PDA

Afficher la version complète : [packaging] S'aider pour faire des RPM de qualité pour notre openSUSE



passionlinux
27/03/2018, 07h57
Un peu comme pour debian, https://debian-facile.org/viewtopic.php?pid=259241#p259241, je propose, n'ayant rien vu auparavant ou si rapprochant, de s'entre-aider pour completer / améliorer l'offre logistique de notre distribution.

J'ai peu de connaissance, diverse notion venant du monde rpm mais plus coté mandriva et localement, openbuild j'ai beaucoup de mal a comprendre...

Bref je me dis que si on forme une sorte de collectif pour faciliter l'envois de paquets créés ou maintenus (mis a jour) ça serait bien.

david
27/03/2018, 09h47
obs à pour page principal https://build.opensuse.org/ tu as obs pour faire sa regarde la doc : http://openbuildservice.org/help/ les packages ainsi créée sont disponible ici : https://software.opensuse.org/search je voie pas pourquoi, ne pas les utiliser. en fin dépôt annexe on à le dépot Packman pour les codes supplémentaire. je trouve qu'il est dommage de se disperser, pour créer des dépot annexe

sogal
27/03/2018, 09h48
Salut,

s/logistique/logicielle non ? :)

Ça peut être une bonne idée en effet de dédier un ou plusieurs fils de discussion à ce sujet.
Voici déjà de la documentation qui m'a bien servie quand j'ai commencé :

openSUSE:Packaging guidelines - openSUSE
(https://en.opensuse.org/openSUSE:Packaging_guidelines)openSUSE:Build Service Tutorial - openSUSE (https://en.opensuse.org/openSUSE:Build_Service_Tutorial)
(https://en.opensuse.org/openSUSE:Packaging_guidelines)openSUSE:Specfile guidelines - openSUSE (https://en.opensuse.org/openSUSE:Specfile_guidelines)
https://fedoraproject.org/wiki/How_to_create_an_RPM_package
https://rpm-guide.readthedocs.io/en/latest/
https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory

@david : je ne pense pas que passionlinux parlait de se disperser mais bel et bien de contribuer en créant des paquets pour des logiciels qui ne sont pas encore présents dans openSUSE (dans aucun dépôt).

passionlinux
27/03/2018, 14h30
Merci David, pour les liens je m'en sers deja meme si je ne suis pas a l'aise avec openbuild, je suis plus a l'aise avec la bonne vieille maniere de faire manuelle avec rpmbuild, mais c'est avec openbuild qu'il faut faire les paquets si on veut aider opensuse alors c'est avec ça que je ferais!

Merci Sogal, j'avais pas autant trouvé de lien, dont un qui me parait bien plus propre et simple pour bien comprendre le openbuild!

je ne pense pas que passionlinux parlait de se disperser mais bel et bien de contribuer en créant des paquets pour des logiciels qui ne sont pas encore présents dans openSUSE (dans aucun dépôt).

Non, non, je ne parle pas de dipersion, je parle de monter une equipe ici pour faciliter la fabrication de paquets et les envoyer soit chez packman ou suse selon le cas, je parle aussi de maintenance, car c'est bien beau de faire des paquets mais le plus chiant c'est l'entretien... On est pas super nombreux mais au vu des outils de opensuse, contrairement a debian qui est vraiment tres fermé (j'ai tenté de faire des uploads de paquets en backport et c'est tout une galere... Et dans le cas de debian je ne parle pas de paquets a creer mais de backport comme par exemple 0ad que j'avais retroporté pour moi et que je voulais envoyer pour faciliter la vie...

De mon coté la maniere que je connaissais pour faire des rpm etait celle-ci: https://www.linuxtricks.fr/wiki/compiler-ses-propres-paquets-rpm-avec-mageia

Et je pensais que l'on pourris faire quelque chose (une section d'entraide pour la fabrication de paquet ou l'entretien) comme sous fedora: https://forums.fedora-fr.org/viewforum.php?id=30

sogal
27/03/2018, 16h37
Merci David, pour les liens je m'en sers deja meme si je ne suis pas a l'aise avec openbuild, je suis plus a l'aise avec la bonne vieille maniere de faire manuelle avec rpmbuild, mais c'est avec openbuild qu'il faut faire les paquets si on veut aider opensuse alors c'est avec ça que je ferais!

En fait c'est surtout que ton rpm peut très bien se construire chez toi avec rpmbuild mais échouer sur l'OBS. Les tests ne sont pas les mêmes et l'environnement utilisé peut l'être aussi. Pour être sûr que ça passera, il faut vraiment utiliser la commande osc qui crée un chroot dans lequel le paquet est construit comme si c'était sur l'OBS.


Merci Sogal, j'avais pas autant trouvé de lien, dont un qui me parait bien plus propre et simple pour bien comprendre le openbuild!


Non, non, je ne parle pas de dipersion, je parle de monter une equipe ici pour faciliter la fabrication de paquets et les envoyer soit chez packman ou suse selon le cas, je parle aussi de maintenance, car c'est bien beau de faire des paquets mais le plus chiant c'est l'entretien... On est pas super nombreux mais au vu des outils de opensuse, contrairement a debian qui est vraiment tres fermé (j'ai tenté de faire des uploads de paquets en backport et c'est tout une galere... Et dans le cas de debian je ne parle pas de paquets a creer mais de backport comme par exemple 0ad que j'avais retroporté pour moi et que je voulais envoyer pour faciliter la vie...

De mon coté la maniere que je connaissais pour faire des rpm etait celle-ci: https://www.linuxtricks.fr/wiki/compiler-ses-propres-paquets-rpm-avec-mageia

Et je pensais que l'on pourris faire quelque chose (une section d'entraide pour la fabrication de paquet ou l'entretien) comme sous fedora: https://forums.fedora-fr.org/viewforum.php?id=30

On peut voir si une section dédiée est pertinente mais rien n'empêche de le faire déjà si tu as un paquet en tête, il y a déjà plusieurs sujets à propos d'aide requise pour construire tel ou tel paquet.
Autant je suis convaincu du bienfait de vouloir contribuer en empaquetant des logiciels absents de la distrib, autant je ne suis pas sûr que ce soit pertinent de « formaliser » ça et de le faire en équipe. Peu de monde est dispo/intéressé/veut apprendre à faire ce genre de choses (mais je peux, et espère, me tromper :) ).
À mon sens, ce qui serait plus efficace ce serait que les personnes intéressées par contribuer de la sorte choisissent un logiciel manquant (et qui les intéresse évidemment) et commence à essayer de l'empaqueter. Et on sera tous là pour l'aider si y'a besoin, sur le forum ou éventuellement lors de sessions de travail dédiées sur IRC.
Mais si plusieurs personnes sont motivées, qu'on a une liste de paquets en projet et une bonne communication (bref, un truc un peu carré et qui avance) ça peut être intéressant.

passionlinux
28/03/2018, 13h22
Coucou Sogal,
Bon je suis de retour sous debian pour le PC fixe mais le portable lui ne bouge plus de leap:p Le fixe sera de retour sous leap certainement avec la 15.
Sinon, j'ai vraiment du mal a comprendre, j'ai regardé la doc que tu donnes, je me contre donc sur osc, au pire OBS mais admettons, as tu un exemple simple et concret que tu pourrais me faire avec un paquet?

Par exemple sous debian, je fais ceci:
Simple retroportage(de SID vers Stable):
- Je créé mon dossier "nom_logiciel" puis je télécharge les sources Debian si ils sont deja dans SID
$ apt-get source nom_logiciel

- changer la version en rajoutant la version et le pourquoi du changement voir changelog*
$ dch -r

- Puis je lance la compilation/empaquetage:
# debuild -uc
ou
# dpkg-buildpackage -b -uc

`fakeroot dpkg-buildpackage -b -uc` afin de ne pas refaire les sources en même temps et de ne pas signer le paquet

Maintenant, souvent le paquet est la sous debian sid donc pas grand chose a faire pour rapporter sous stable, par contre il y a aussi des cas, fréquent, qu'il n'existe pas sous debian mais sous ubuntu, et là aussi très simple, car debian et ubuntu partage la même base, les libs et paquets sont a 99% avec le meme nom, un paquet source debian et ubuntu n'ont que peu de différences, donc la manipe reste bonne, dernièrement(hier) j'ai fait le paquet (simple) ghostwritter (aussi dispo sous openSUSE). La seule chose est de bien regarder si les paquets buildrequire et dépendances sont bien avec les même noms et des versions communes.

Or le soucis avec RPM, c'est que les fichiers SPECs n'ont pratiquement rien a voir entre eux, si je regarde Fedora, Mageia, openSUSE c'est dans l'architecture la même chose mais les commandes de compilation et autre ne sont pas les même....
bref regardons ça ensemble, je reprends le paquet ghostwritter (https://github.com/wereturtle/ghostwriter) que je viens de compiler pour ma debian depuis un source ubuntu:

- fichier .dsc:

Format: 3.0 (quilt)
Source: ghostwriter
Binary: ghostwriter
Architecture: any
Version: 1.5.0-1~bpo9+1
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Uploaders: wereturtle <wereturtledev@gmail.com>
Homepage: http://wereturtle.github.io/ghostwriter/
Standards-Version: 3.9.7
Build-Depends: debhelper (>= 9), qtbase5-dev, libqt5svg5-dev, qtmultimedia5-dev, libqt5webkit5-dev, libhunspell-dev, pkg-config
Package-List:
ghostwriter deb editors optional arch=any
Checksums-Sha1:
3ec5de705df59a0bbe9ebcaf89eb044ebf4c0d68 726757 ghostwriter_1.5.0.orig.tar.gz
3ec95ee770cf8d0a57e395d866bb928c392ea7f0 2200 ghostwriter_1.5.0-1~bpo9+1.debian.tar.xz
Checksums-Sha256:
7c5fc49a54e74f00193af18ba66d07ccfb08f8d56b3218ae2f 075ae913744df2 726757 ghostwriter_1.5.0.orig.tar.gz
27f0c4c8d00562fd11317c7607fe3c922ce5c1d33dc82af1b7 46fdc6806e4263 2200 ghostwriter_1.5.0-1~bpo9+1.debian.tar.xz
Files:
55eee4b2012a6252092e0ed004627a1a 726757 ghostwriter_1.5.0.orig.tar.gz
30a4b6ab5b39c5933b198edc989cdb08 2200 ghostwriter_1.5.0-1~bpo9+1.debian.tar.xz

- le fichier controle:


Source: ghostwriter
Section: editors
Priority: optional
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Uploaders: wereturtle <wereturtledev@gmail.com>
Build-Depends: debhelper (>= 9),
qtbase5-dev,
libqt5svg5-dev,
qtmultimedia5-dev,
libqt5webkit5-dev,
libhunspell-dev,
pkg-config
Standards-Version: 3.9.7
Homepage: http://wereturtle.github.io/ghostwriter/
#Vcs-Git: git://git.debian.org/collab-maint/ghostwriter.git
#Vcs-Browser: http://git.debian.org/?p=collab-maint/ghostwriter.git;a=summary

Package: ghostwriter
Architecture: any
Depends: libqt5concurrent5,
libqt5printsupport5,
libqt5svg5,
${misc:Depends},
${shlibs:Depends},
Suggests: hunspell-dictionary, myspell-dictionary
Description: Distraction-free, themeable Markdown editor
ghostwriter is a Markdown editor that provides a themable,
distraction-free writing environment, along with a live HTML
preview as you type, easy document navigation with an outline HUD,
and export to popular document formats with Sundown, Pandoc,
MultiMarkdown, Discount or cmark processors. It also features a
live word count and auto-save. Eliminate distractions in
fullscreen mode, or concentrate on the current text you are writing
in focus mode. It even remembers your last opened file and position
within the file, so you can pick up where you last left off.

- le fichier rules:

#!/usr/bin/make -f

export QT_SELECT=qt5

%:
dh $@ --parallel
suite...

passionlinux
28/03/2018, 13h38
dans les deux cas ubuntu et debian, ça change pas, j'ai juste maté si les dep étaient bonnes, j'aurais pu toucher aussi au mainteneur et y mettre mon nom, mais c'est pour moi perso alors je m'en fou et puis ce source ne vient pas de moi!

Maintenant, attaquons nous aux RPM:

Le SPEC openSUSE:


#
# spec file for package ghostwriter
#
# Copyright (c) 2017 SUSE LINUX GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.

# Please submit bugfixes or comments via http://bugs.opensuse.org/
#


Name: ghostwriter
Version: 1.5.0
Release: 0
Summary: A distraction-free Markdown editor
License: GPL-3.0+
Group: Productivity/Text/Editors
Url: https://wereturtle.github.io/ghostwriter
Source: https://github.com/wereturtle/ghostwriter/archive/v%{version}.tar.gz#/%{name}-%{version}.tar.gz
BuildRequires: gcc-c++
BuildRequires: hicolor-icon-theme
BuildRequires: libqt5-linguist
BuildRequires: pkgconfig
BuildRequires: update-desktop-files
BuildRequires: pkgconfig(Qt5Concurrent)
BuildRequires: pkgconfig(Qt5Core)
BuildRequires: pkgconfig(Qt5Multimedia)
BuildRequires: pkgconfig(Qt5MultimediaWidgets)
BuildRequires: pkgconfig(Qt5PrintSupport)
BuildRequires: pkgconfig(Qt5Svg)
BuildRequires: pkgconfig(Qt5WebKit)
BuildRequires: pkgconfig(Qt5WebKitWidgets)
BuildRequires: pkgconfig(hunspell)
Requires(post): hicolor-icon-theme
Requires(post): update-desktop-files
Requires(postun): hicolor-icon-theme
Requires(postun): update-desktop-files
Recommends: %{name}-lang
Recommends: multimarkdown
Suggests: MultiMarkdown-5
Suggests: MultiMarkdown-6
Suggests: cmark
Suggests: discount
Suggests: pandoc
Suggests: texlive-context
Suggests: wkhtmltopdf

%description
ghostwriter is a text editor for Markdown, which is a plain text
markup format. For more information about Markdown, please visit John
Gruber’s website at http://www.daringfireball.net. ghostwriter
provides a relaxing, distraction-free writing environment.

%lang_package

%prep
%setup -q

%build
lrelease-qt5 %{name}.pro
%qmake5 PREFIX=%{_prefix}
%make_jobs

%install
%qmake5_install
%suse_update_desktop_file -r %{name} TextEditor
%find_lang %{name} --with-qt

%post
%desktop_database_post
%icon_theme_cache_post

%postun
%desktop_database_postun
%icon_theme_cache_postun

%files
%doc README.md CREDITS.md COPYING
%{_bindir}/ghostwriter
%dir %{_datadir}/appdata
%{_datadir}/appdata/ghostwriter.appdata.xml
%{_datadir}/applications/ghostwriter.desktop
%{_datadir}/icons/hicolor/*
%{_mandir}/man1/ghostwriter.1%{ext_man}
%{_datadir}/pixmaps/ghostwriter.xpm

%files lang -f %{name}.lang
%dir %{_datadir}/ghostwriter
%dir %{_datadir}/ghostwriter/translations

%changelog


et celui de sa cousine Fedora:


%global _hardened_build 1
%define debug_package %{nil}

Summary: ghostwriter: A cross-platform, aesthetic, distraction-free Markdown editor
Name: ghostwriter
Version: 1.5.0
Release: 1%{?dist}
License: GPLv3+
Group: Development/Tools
URL: http://wereturtle.github.io/ghostwriter/
Source0: https://github.com/wereturtle/ghostwriter/archive/v%{version}.tar.gz
BuildRequires: gcc gcc-c++ make
BuildRequires: qt5-devel qt5-qtbase-devel qt5-qtsvg-devel qt5-qtwebkit-devel
BuildRequires: qt5-qtmultimedia-devel hunspell-devel pkgconfig
Requires: qt5-qtbase qt5-qtwebkit qt5-qtsvg qt5-qtmultimedia hunspell

%description
ghostwriter is a Windows and Linux text editor for Markdown, which is a plain
text markup format created by John Gruber. For more information about Markdown,
please visit John Gruber’s website at http://www.daringfireball.net.

ghostwriter provides a relaxing, distraction-free writing environment, whether
your masterpiece be that next blog post, your school paper, or your NaNoWriMo
novel.

%prep
%autosetup

%build
qmake-qt5 PREFIX=%{_prefix}
make %{?_smp_mflags}

%install
export INSTALL_ROOT=%{buildroot}
make install

%files
%{_bindir}/ghostwriter
%{_datarootdir}/ghostwriter/*
%{_datarootdir}/appdata/ghostwriter.appdata.xml
%{_datarootdir}/applications/ghostwriter.desktop
%{_datarootdir}/icons/hicolor/*/apps/ghostwriter.*
%{_mandir}/man1/*
%{_datarootdir}/pixmaps/*
%doc COPYING CREDITS.md

%changelog
* Wed Feb 28 2018 Machiel Molenaar <machiel@machiel.me> - 1.5.0-1
- Update to v1.5.0

* Thu Dec 15 2016 Arun Babu Neelicattu <arun.neelicattu@gmail.com> - 1.4.2-1
- Initial version v1.4.2

Rien que pour partir depuis un Spec Fedora, je ne suis plus capable de savoir exactement ce qui est bon ou pas.

Comment fais tu toi de ton coté avec osc?

sogal
28/03/2018, 19h42
Bonsoir,

Tu parles de beaucoup de choses à la fois, ça peut être utile d'en repréciser certaines.
En préambule, je tiens à dire que je ne suis pas expert en empaquetage RPM hein :) tout ce que je dis n'est que ce que j'ai appris depuis que j'ai voulu faire mon premier paquet pour mon Tilix (https://github.com/gnunn1/tilix) adoré il y a un peu moins d'un an maintenant. C'est donc à lire comme tel.

Les outils :

Tout d'abord, l'OBS. (https://github.com/openSUSE/obs-build) C'est au final un simple « logiciel » ou plutôt une plateforme de développement et de build.
openSUSE en administre et met à disposition une instance ( http://build.opensuse.org/ ) que nous utilisons et qui comporte une interface Web.
Il existe également osc : un client en ligne de commande pour interagir avec l'instance d'OBS d'openSUSE.

Le specfile :

Je n'ai jamais trop fait de paquet complètement pour Debian, mais un specfile pour RPM contient dans un seul fichier :

les metadonnées du paquet
les variables à utiliser dans ce specfile
les dépendances de construction
les dépendances d'exécution
les instructions de compilation
les instructions d'empaquetage
les instructions d'installation
le cas échéant, un changelog


Cas pratique :

On va prendre par exemple le lgociel tty-clock, (https://github.com/xorg62/tty-clock) une chouette horloge pour console.

Création du paquet via osc :

(on considère que le compte sur l'OBS openSUSE est créé et qu'osc est configuré)


osc mkpac tty-clock

Le specfile pour tty-clock :

Méta données :


#
# spec file for package tty-clock
#
# Copyright (c) 2018 SUSE LINUX GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.

# Please submit bugfixes or comments via http://bugs.opensuse.org/
#

Name: tty-clock
Version: 2.3
Release: 0
License: BSD-3-Clause-LBNL
Summary: Clock using lib ncurses
Url: https://github.com/xorg62/tty-clock
Group: Productivity/Utilities
Source: https://github.com/xorg62/tty-clock/archive/v2.3.tar.gz

Dépendances de construction (une seule ici)


BuildRequires: ncurses-devel

Pas de dépendances d'exécution mais on aurait pu avoir par exemple : Requires: libncurses6)


BuildRoot: %{_tmppath}/%{name}-%{version}-build

Description du paquet utilisée par RPM :


%description
tty-clock is a simple clock for terminals using lib ncurses.

Préparation des sources (décompresser l'archiver, préparer l'arborescence de construction) :


%prep
%setup -q

Compilation :


%build
make %{?_smp_mflags}

Installation (dans l'arborescence de construction du paquet) :


%install
make install PREFIX=%_prefix DESTDIR=%{buildroot} %{?_smp_mflags}


Suivi des fichiers installés :


%files
%defattr(-,root,root)
%doc README
%{_bindir}/%{name}
%{_mandir}/man1/%{name}.1.gz

Changelog (chez openSUSE, il est mis à part, dans le fichier tty-clock.changes) :


%changelog

Construction en local :

Imaginons que dans mon dépôt home:sogal (mon compte sur l'OBS) j'ai activé les dépôts openSUSE Leap 42.3 et openSUSE Tumbleweed en x86_64 (64bits) puisque c'est pour ces distributions et cette architecture que je souhaite créer mes paquets, je vais pouvoir construire mon paquet sur ma machine, en local, dans un environnement similaire à celui qu'utilisera l'OBS :


osc build openSUSE_Leap_42.3 x86_64

Là, un chroot est créé puis la compilation se lance. Si ça réussi, on continue, sinon on voit ce qui ne va pas (typo dans le specfile ou dépendance manquante, etc...).

Création du changelog :

Pour éditer le fichier tty-clock.changes, je peux utiliser la commande suivante qui fait appel à mon éditeur préféré (défini par la variable d'environnement du shell « EDITOR »):


osc vc

Pousser son travail sur l'OBS :


osc ci

Là le contenu de mon dossier tty-clock est poussé dans mon home:sogal sur l'OBS qui commence à le construire.
Au bout d'un moment, on peut récupérer les résultats, soit directement via l'interface Web, soit via :


osc results

Voilà déjà une description basique des étapes, du moins de mon flux de travail. Bien entendu c'est un exemple simple et les « recettes » de constructions peuvent être bien plus complexes selon les programmes à empaqueter.

passionlinux
29/03/2018, 14h27
Alors la Sogal c'est royal, tu me confirmes donc que OSC est belle et bien la même chose que OBS mais sur son PC, si on a pas de compte OBS on ne peut utiliser OSC, qui interagit avec OBS pour faire des paquets.

Donc autant passer directement par le site OBS.
En tout cas un gros merci car ça c'est de la démonstration, digne de figurer dans un tuto! Je garde ça sous le coude ;)

sogal
29/03/2018, 14h49
Alors la Sogal c'est royal, tu me confirmes donc que OSC est belle et bien la même chose que OBS mais sur son PC, si on a pas de compte OBS on ne peut utiliser OSC, qui interagit avec OBS pour faire des paquets.

Ou alors tu peux utiliser osc si tu utilises une autre instance de l'OBS que celle fournit par openSUSE (comment ça tu ne veux pas monter ton propre serveur à la maison et y installer OBS ? :p )


Donc autant passer directement par le site OBS.

Hum...non, pas vraiment. Ça peut rassurer au début mais tu verras vite que c'est chiant et contre-productif. Plusieurs raisons à mon sens :



interface Web = plus lent, moins flexible pour ajouter/supprimer tes fichiers ;
au début tu vas beaucoup tester, te planter, recommencer, apprendre : chacun de tes tests va se construire en utilisant les ressources des mêmes serveurs qui construisent la distrib, il vaut donc mieux que tu testes en local d'abord pour ne pas les faire booser « pour rien  » en quelque sorte. Quand ton paquet se construit bien, là tu peux pousser ton travail (la commande osc ci ci-dessus) sur les serveurs de l'OBS ;
tu passerais à côté de l'occasion d'apprendre à utiliser un outil puissant qui te permet non seulement de construire tes paquets, mais aussi gérer les requêtes, créer des branches etc...


En tout cas un gros merci car ça c'est de la démonstration, digne de figurer dans un tuto! Je garde ça sous le coude ;)

Avec plaisir, ce n'est qu'une intro mais ça devrait t'aider à démarrer :)

passionlinux
29/03/2018, 15h16
Ah vu comme ça c'est extreme;)
Va falloir que je me penche plus dessus, je sent que je vais venir continuer a alimenter ce post pour apprendre plus en temps réelle.

passionlinux
11/04/2018, 16h01
Bon ça y est premiere participation, je sais pas si plus simple ou non que les commande debian (debuild) peut etre plus automate, je n'en sais rien, je ne peux pas dire ce que je préfère actuellement.

Par contre c'est clair que c'est tres simple pour "poussé" le paquets et les sources dans l'amont pour le voir apparaitre chez openSUSE, une journée voir moins et ma demande (deux demandes puisque 1.6 et 1.61 de ghostwriter ont été mis a dispo tres vite en amont par son auteur) fut accepté et intégré a openbuild/editor:
https://build.opensuse.org/package/show/editors/ghostwriter

Alors que je suis toujours en attente de le voir chez debian, et encore d'avoir seulement une bonne ame pour "sponsoriser" mon paquets...

Chapeau openSUSE

passionlinux
11/04/2018, 17h40
content de comprendre le fonctionnement simple de osc, je vient de refaire mon paquet ghostwriter que j'avais précédemment fait avec debuild pour debian sur ma debian, et avec osc depuis une leap 42.3 je peux faire ça simplement.... Ce qui veut aussi dire autre chose, je peux inversement faire des paquet depuis debian pour opensuse avec osc et là ça me plait.

Merci sogal !!!

sogal
11/04/2018, 20h09
Salut,
Bien joué ! J'ai vu ton billet dans ton blog également, belle présentation et introduction, j'espère que ça inspirera tes lecteurs :)

passionlinux
12/04/2018, 16h49
Salut,
Bien joué ! J'ai vu ton billet dans ton blog également, belle présentation et introduction, j'espère que ça inspirera tes lecteurs ;D

J'ai deux soucis, mais on va les etudier ou du moins je les dévoile et apres seulement vous venez me dire ce que vous pensez.

Bon je savais que ça allait être trop beau, j'explique un cas concret, sous debian, admettons que le paquet A a besoin pour se faire du paquet B, mais que ce paquet est non présent dans les dépôts dans la version demandé, je dois le choper et le builder en premiers (retro-portage et en esperant que B dans sa nouvelle version n'ait pas des paquets en depandance qui sont eux aussi a retroporter sinon on ne s'en sort plus...) puis l'installer. Une fois installer B et les autres dependance de A present dans stable, nous pouvons contruire notre paquet A avec debuild. Je passe les mannipes et si vous etes interessé je mettrais un lien ici pour ceux qui veulent voir un peu plus. Bon sous debian je n'utilise pas de chroot (pas bien) pour la simple raison que je ne fais que des retroportage ou des paquets non present dans l'archive debian mais ayant toutes ses dépendances de satisfaites dans stable comme pour ghostwriter. De plus maintenant et ce grace a OBS, je peux etre sur que mon deb est bon et se construit dans un chroot tres facilement, je donne le dsc, le origin.tar.gz et le debian.tar.gz et hop ça compile...

Alors maintenant passons a SUSE, je voulais avoir filezilla dans une version plus correcte, tant qu'a faire autant passer par la dernière mais si je n'y arrive pas bah je passerais sur la 3.24 comme pour Debian et qui voit ses dépendances satisfait dans OSS. Filezilla a besoin de libfilezilla 0.12, hop je lance alors le build de libfilezilla0.12, par chance il est dans les depots de update donc ça passe sans soucis. Mais admettons que ce n'est pas le cas, comment je peux dire a osc que je voudrais qu'il ajoute les depots "officieux" comme network, editor, mozilla, games... ?

Par exemple filezilla 3.31 a besoin de:

BuildRequires: pugixml-devel >= 1.7
BuildRequires: wxWidgets-3_0-devel >= 3.0.3
BuildRequires: pkgconfig(gnutls) >= 3.4.15
BuildRequires: pkgconfig(gtk+-2.0)
BuildRequires: pkgconfig(libfilezilla) >= 0.12.1
BuildRequires: pkgconfig(nettle) >= 3.1

Mon premier reflexe est de les builder a leur tour localement via osc, mais en faite ça ne sert a rien,puisque'il faudrait que je puisse dire un moment donné "eh oh, va chercher tes buildeps à tel endroit!".

Alors ma question est comment faites vous?

J'ai vu ceci, mais pas sur que ça soit ce que je veux:


Ensure you have the latest sources Use osc checkout (osc co) or osc up to ensure you have the latest version of the source.
If it is project you don't have checkout at all:
cd <your_obs_working_dir>;
osc co <project> <package>
or
cd <your_obs_working_dir>/<project>;
osc co <package>
or
cd <your_obs_working_dir>/<project>/<package>;
osc up


Je vois aussi et surtout ceci:

osc will connect to the OBS repository server and download all needed RPMs to /var/tmp/osbuild-packagecache/plattform/repository/arch as cache directory. If you want to avoid network traffic, its possible to fill the cache beforehand with rpms from a DVD or iso. For that, copy the rpms from the DVD to the cache dir.

Il suffirait alors si je comprends bien de mettre des paquets buildrequire dans le "cache dir". Est ce bon?

Il y a aussi ceci:

If your package uses a URL download service, you may have to execute the following command first:

zypper ar -r http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_11.3/openSUSE:Tools.repo


je suppose que je peux dans la ligne du depot remplacer 11.3 par 42.3 mais le soucis n'est pas là, je traduis vite fait "Si votre package utilise un service de téléchargement d'URL, vous devrez peut-être exécuter la commande suivante en premier:" Qu'est ce qui va changer en téléchargeant ce dépot de plus? (je vais le faire de toute façon). du reste la ligne est corrigésur mon site mais vu que c'est du statique il n'est pas a jour dans sa version en ligne ;p

sogal
12/04/2018, 20h24
Bonsoir,
Ton paquet est certainement dans un dépôt de devel, il faut que tu rajoutes ce dépôt à ton projet (ton home:user).
Regardes chez moi : https://build.opensuse.org/repositories/home:sogal onglet → Repositories. Pour Leap 42.3 tu constates que j'ai ajouté le dépôt openSUSE:Leap:42.3/standard devel:languages:D/ pour avoir les paquets nécessaires à Tilix par exemple.
Si une dep n'est pas présente nulle part (étonnant mais admettons), rien ne t'empêche d'en construire le paquet dans ton dépôt et de faire appel à ton propre dépôt (je n'ai pas testé ce cas de figure cela dit).

passionlinux
12/04/2018, 20h37
Bonsoir,
Ton paquet est certainement dans un dépôt de devel, il faut que tu rajoutes ce dépôt à ton projet (ton home:user).
Regardes chez moi : https://build.opensuse.org/repositories/home:sogal onglet → Repositories. Pour Leap 42.3 tu constates que j'ai ajouté le dépôt openSUSE:Leap:42.3/standard devel:languages:D/ pour avoir les paquets nécessaires à Tilix par exemple.
Si une dep n'est pas présente nulle part (étonnant mais admettons), rien ne t'empêche d'en construire le paquet dans ton dépôt et de faire appel à ton propre dépôt (je n'ai pas testé ce cas de figure cela dit).

Super, et donc tu rajoutes ça dans ton fichier ocsr? pour rester dans ton exemple c'est juste trusted_prj=openSUSE:Leap:42.3:Update:standard_ devel:languages?

sogal
12/04/2018, 21h02
Oui et non.
La directive trusted_prj dans ton $HOME/.oscrc c'est pour dire que tu leurs accorde ta confiance (ça évite la demande à chaque build).
C'est dans les métadonnées du projet que tu les ajoutes :


osc meta prj -e

Exemple du mien :



<project name="home:sogal">
<title>home:sogal</title>
<description>Personnal builds for packages I need in Leap 42.x</description>
<person userid="sogal" role="maintainer"/>
<debuginfo>
<disable arch="x86_64" repository="openSUSE_Leap_42.3"/>
</debuginfo>
<repository name="openSUSE_Tumbleweed">
<path project="openSUSE:Factory" repository="snapshot"/>
<path project="devel:languages:D" repository="openSUSE_Tumbleweed"/>
<path project="devel:languages:rust" repository="openSUSE_Tumbleweed"/>
<arch>x86_64</arch>
</repository>
<repository name="openSUSE_Leap_42.3">
<path project="openSUSE:Leap:42.3" repository="standard"/>
<path project="devel:languages:D" repository="openSUSE_Leap_42.3"/>
<path project="multimedia:libs" repository="openSUSE_Leap_42.3"/>
<path project="devel:languages:rust" repository="openSUSE_Leap_42.3"/>
<arch>x86_64</arch>
</repository>
<repository name="openSUSE_Leap_15.0">
<path project="openSUSE:Leap:15.0" repository="standard"/>
<arch>x86_64</arch>
</repository>
</project>

passionlinux
12/04/2018, 21h18
Sogal tu me sauve là, j'ai du rater un truc car il me semble pas l'avoir vu si simplement. je vais rajouter ça sur le tuto du blog.

passionlinux
12/04/2018, 23h12
Bon, la je suis perdu et je ne pige pas vraiment, pourtant ça commençait bien;)
j'essaye donc de commiter des paquets mais c'est cela pour la plupart:
~/Paquets/RPM/home:seb95passionlinux/X11:wxWidgets/wxWidgets-3_0> osc ci
- package has baselibs.conf: (unchanged)
- package has wxWidgets-3_0-rpmlintrc: (unchanged)
nothing to do for package wxWidgets-3_0

La c'est qu'un exemple avec un parmis tant d'autre...

Comment j'ai procedé, j'ai fait a chaque fois pour les dep un
osc co Base:System p11-kit

ça m'a fait un jolie dossier dans mon "home" avec les fichiers ect, comme ça pour tous, puis j'ai builder les un apres les autres, maintenant j'aimerais que "mon travail" soit envoyé sur obs pour que je puisse enfin builder admettons filezilla 3.31 dans un 1er temps puis 3.32(oui c'est le but) pour leap 42.3.
je fais donc un :

osc ci

et la ça me fait a chaque fois la meme chose:
~/Paquets/RPM/home:seb95passionlinux/sousdossier/paquet > osc ci
- package has baselibs.conf: (unchanged)
- package has paquet-rpmlintrc: (unchanged)
nothing to do for package paquet

Tu as deja eu ça?

passionlinux
12/04/2018, 23h40
Je pense trouver l’erreur, je te dis ça si ça fonctionne

sogal
13/04/2018, 13h18
Comment j'ai procedé, j'ai fait a chaque fois pour les dep un
osc co Base:System p11-kit

Mais pourquoi ???
Pourquoi faire un checkout des dépôts, il suffit de les ajouter comme source de données dans ton projet perso ?

passionlinux
13/04/2018, 14h05
Mais pourquoi ???
Pourquoi faire un checkout des dépôts, il suffit de les ajouter comme source de données dans ton projet perso ?

Oui je voulais un minimum de paquets externe aux dépôts standard.
Mais j'ai maintenant ajouté les dépots dont j'ai besoin dans mon meta.

Dit moi, sous debian c'est tres mal vu de faire par exemple une mise a jour d'un paquet qui a deja son mainteneur, il faut avant tout le prevenir sur la mailing-list ou par mail, ect... meme pour faire un retroportage de paquet de sid vers stable c'est pareil, voir pire car il faut prevenir le mainteneur et le précédent retroporteur de son intention de le faire. Comment ça se passe sous opensuse? On est plutot comme sous debian ou il faut de l'ancienneté (ce que j'ai pas eu comme impression sur mes deux requetes d'upload) ou bien l'effort fournit est reçu comme un cadeau et on est pas vu comme le voleur de service? Faut il demander avant de proposer sa mise a jour de paquets? Sachant que je ne vais me contenter d'essayer de maintenir a jour des paquets que j'utilise.

sogal
14/04/2018, 19h29
Dit moi, sous debian c'est tres mal vu de faire par exemple une mise a jour d'un paquet qui a deja son mainteneur, il faut avant tout le prevenir sur la mailing-list ou par mail, ect... meme pour faire un retroportage de paquet de sid vers stable c'est pareil, voir pire car il faut prevenir le mainteneur et le précédent retroporteur de son intention de le faire. Comment ça se passe sous opensuse? On est plutot comme sous debian ou il faut de l'ancienneté (ce que j'ai pas eu comme impression sur mes deux requetes d'upload) ou bien l'effort fournit est reçu comme un cadeau et on est pas vu comme le voleur de service? Faut il demander avant de proposer sa mise a jour de paquets? Sachant que je ne vais me contenter d'essayer de maintenir a jour des paquets que j'utilise.

Salut, je n'en sais trop rien mais je pense que c'est moins strict que Debian, plus ouvert.
Cela dit, c'est du bon sens, en règle générale, personne n'aime trop quand quelqu'un vient "mettre le bazar" (même gentiment) dans son travail. Donc le mieux c'est de regarder dans le dépôt de devel du paquet en question. Si tu constates dans les logs, que le paquet est mis à jour régulièrement et suivi, je pense que tu peux t'abstenir. Le mainteneur attitré fait son taf, et si la toute dernière version du logiciel n'est pas dispo c'est sûrement qu'il n'a pas eu encore le temps. Si tu as besoin de cette toute dernière version, alors tu la packages dans ton dépôt perso seulement.
En revanche, si le paquet n'a plus de mainteneur, qu'il n'est plus suivi depuis un looong moment, alors oui, tu peux soumettre ton travail. Si ça se trouve quelqu'un te proposera même d'être mainteneur s'il n'y en a effectivement plus.
Comme je disais : du bon sens ;)

Amuses toi bien.

passionlinux
15/04/2018, 19h18
Salut, je n'en sais trop rien mais je pense que c'est moins strict que Debian, plus ouvert.
Cela dit, c'est du bon sens, en règle générale, personne n'aime trop quand quelqu'un vient "mettre le bazar" (même gentiment) dans son travail. Donc le mieux c'est de regarder dans le dépôt de devel du paquet en question. Si tu constates dans les logs, que le paquet est mis à jour régulièrement et suivi, je pense que tu peux t'abstenir. Le mainteneur attitré fait son taf, et si la toute dernière version du logiciel n'est pas dispo c'est sûrement qu'il n'a pas eu encore le temps. Si tu as besoin de cette toute dernière version, alors tu la packages dans ton dépôt perso seulement.
En revanche, si le paquet n'a plus de mainteneur, qu'il n'est plus suivi depuis un looong moment, alors oui, tu peux soumettre ton travail. Si ça se trouve quelqu'un te proposera même d'être mainteneur s'il n'y en a effectivement plus.
Comme je disais : du bon sens ;)

Amuses toi bien.

Oui je vois que c'est bien plus ouvert, c'est plus du type ceux qui font décident et ça me plait. Sur debian il y a des fois tu te demande pourquoi ils ne font rien pour le backport ou faciliter les ajouts des benevole, par exemple 0ad, c'est rien c'est juste un jeu, mais faut demander l'autorisation au mainteneur puis a celui qui a fait le dernier backport, pour enfin envoyé via mentor.debian le paquet et les sources. Bref, beaucoup de bruit pour pas grand chose, alors que obs wouah ça c'est clair et simple pour participer!