Re: About fusioninventory-agent packaging
Hello Gregor,
> Envoyé: Lundi 25 Juin 2018 18:22:41
> Objet: Re: About fusioninventory-agent packaging
>
> On Mon, 25 Jun 2018 17:26:44 +0200, Guillaume Bougard wrote:
>
> > Hi Gregor,
> > well, I'll really need help regarding your changelog TODOs ^^
>
> Sure, that's what we are here for :)
thank you for help ;-)
> > I'm taking them back here and make my comments around.
>
> Good idea to keep the list in the loop, so others can help as well,
> explain in different words, etc.
>
> > 1. d/changelog: there should be only one changelog entry for a new upload,
> > so
> > everything after 1:2.3.16-1 should be squashed into this stanza
> > d/changelog: as this is the first upload of 2.4, the version should be
> > 1:2.4-1 (not -3)
> >
> > I uploaded 2.3.18, 2.3.21 & 2.4, do you mean there should be only
> > one changelog entry for each ?
>
> From a Debian point of view, nothing was uploaded after 1:2.3.16-1,
> so every change to the package afterwards should be in one changelog
> entry for the current upload, 1:2.4-1:
>
> #v+
> fusioninventory-agent (1:2.4-1) UNRELEASED; urgency=low
>
> * all the
> * changes since
> * the last upload
> * which is 1:2.3.16-1
>
> -- Guillaume Bougard <gbougard@teclib.com> Fri, 22 Jun 2018 14:18:33 +0000
>
> fusioninventory-agent (1:2.3.16-1) unstable; urgency=low
>
> * New upstream release
> * Bump Standard-version to 3.9.6
> * Refresh the debian/changelog file
>
> -- Gonéri Le Bouder <goneri@debian.org> Sat, 20 Jun 2015 01:10:40 +0200
>
> fusioninventory-agent (1:2.3.15-1) experimental; urgency=medium
>
> ...
> #v-
>
> > In fact, there's one for 2.3.18, that should be okay so for this one.
> > There are 2 entries for 2.3.21, but in fact I still released
> > privately them to some customers. They were published there:
> > http://debian.fusioninventory.org/downloads/
> > This is the same for 2.4. In fact, I merged my own debian changelog
> > that was itself merged in our github repository.
> > It could be a problem if debian publishes 2.4-1 and one customer
> > still installed our 2.4-2. It won't be updated until next release.
> > Btw as 2.4.1 should be release in few days, this won't be a big
> > deal if you don't want I merge my own changelog.
>
> Ouch, this is of course a bit of a pain if you have releases in
> privates repositories.
> But with 1:2.4.1-1 that should be fixed, I guess.
Okay, I'll merge the changelog into one entry and we won't worry about version collision as 2.4.1 will follow soon.
> > But then do you want only a 2.4 release after the 2.3.16 (with
> > 2.3.18 & 2.3.21 changelog merged in 2.4) ? If yes, I'll have to
> > reset again the repository.
>
> I'm not sure what you mean be "restting the repository" but I'm
> pretty sure you don't need to do it :)
> I'm just talking about calling `dch' to edit debian/changelog in
> order to rearrange the entries and delete a few lines :)
Understood.
> > 2. bug closing: closing bugs fixed in older versions ("Still fixed in
> > 2.3.15-1")
> > should be done via versioned closes in the BTS, not in the changelog of
> > a
> > newer upload.
> >
> > Here I really don't know how to close the bug in BTS. Gonéri is
> > still the defined maintainer on BTS and he missed to close the bug.
>
> Luckily everyone can close bugs in the Debian BTS :)
> Please take a look at the documentation at https://bugs.debian.org
>
> For this case it is quite easy:
>
> - Send a mail to 756622-done@bugs.debian.org (and 792205-done@bugs.debian.org
> for the other bug)
> - with some nice subject
> - and a body like:
>
> #v+
> Version: 1:2.3.15-1
>
> This bug was fixed in 1:2.3.15-1, <some more explanation etc.>
>
> <Maybe something more to say?>
> #v-
>
> The mails to nnnnnn-done will close the bug, and the "Version: "
> pseudo-header (pseudo-header as it looks like a header but is the
> first line of the body) will tell the BTS in which version of the
> package the bug is fixed.
Thank you, this help.
I finally found my way in documentation: https://www.debian.org/Bugs/Developer
Of course the documentation says only the bug owner or the package maintainer could close the bug. But this is an exception, so I guess this will work.
> > 3. d/changelog: "Fix litian warnings":
> > + typo litian -> lintian
> > + mention what changes you made (that's more interesting than which
> > tool
> > helped)
> >
> > Okay I missed the typo sorry. But in fact, and if I remember well,
> > I just fixes the lintian warning found while testing the package
> > build and I noticed everything just after the line... I just
> > removed the entry then as the following lines are telling what was
> > fixed.
>
> Great.
>
> > 4. debian/patches: patches should be unapplied in git, and have proper
> > headers (not the autogenerated ones). for quilt:
> > https://perl-team.pages.debian.net/howto/quilt.html
> >
> > Okay, I wasn't aware to not apply the patch in git. I can revert
> > the patch for last 2.4 release, but I can't for 2.3.18 & 2.3.21,
> > unless resetting the repository.
>
> Again, I'm pretty sure you don't have to reset anything :)
> I just meant to unapply the patches. So something like:
>
> % patch -p1 -R < debian/patches/Makefile.PL.patch
> % patch -p1 -R < debian/patches/systemd-obsolete-after-fix.patch
> % patch -p1 -R < debian/patches/00bb19f26-upstream-github-commit.path
>
> and git add / commit.
>
> > For the patch having propre header, I missed to fix it for 2.3.18
> > patches (was deleted with 2.3.21 as the problem was fixed
> > upstream). For 2.3.21 & 2.4, I think headers are okay, but of
> > course I could be wrong.
>
> 00bb19f26-upstream-github-commit.path has nice headers,
> Makefile.PL.patch and systemd-obsolete-after-fix.patch have
> autogenerated boilerplate headers.
>
> > Again, to fix that this means I should reset the repository.
>
> Again, you just have to edit 2 text files :)
Sorry, I missed Makefile.PL.patch and systemd-obsolete-after-fix.patch headers O:)
And I understand now why I shouldn't have applied the patchs in master branch.
This will be fixed.
> > 5. the package doesn't build, a test fails:
> > # Failed test 'rpm: parsing'
> > # at t/tasks/inventory/linux/softwares.t line 306.
> > # Compared $data->[6]{"INSTALLDATE"}
> > # got : '24/03/2012'
> > # expect : '25/03/2012'
> >
> > I don't have that issue on my own.
>
> I guessed so.
>
> > We had such kind of TZ related issue back in 2016 and it should has
> > been fixed in 2.3.18. Can you give me more detail about which
> > version is tested and in which context ? Eventually send me back
> > the full output log so I can understand what happened ? Thank you.
>
> I built whatever was in git at that time, in my usual cowbuilder sid
> amd64 chroot.
>
> I'm attaching my build log.
Thank you, this should help to fix the issue... and add a patch :)
> > 8. debian/control: Standards-Version: 4.1.4 is the current one
> > (in d/changelog you say 4.1.4 :))
> >
> > Do you mean I forgot to set 4.1.4 in d/control...
>
> Ack.
>
> > Weirdly it seems
> > to be the old value 3.9.8 in d/control and I though I set it to
> > 4.1.4...
>
> Yup, looks like an oversight.
>
> > 9. debian/copyright:
> > + incomplete, `grep -ir copyright .' shows more
> > * for inc/* you can use
> > https://perl-team.pages.debian.net/copyright.html#Module%3A%3AInstall
> > + years are different from the ones in README.md
> >
> > Okay I added Module::Install license section in d/copyright.
>
> Ok, cool. Not sure any of the other hits of "copyright" are relevant,
> let's hope not :)
>
> > 10. why is the init script removed? is this really necessary?
> > if yes, this needs a big fat warning in debian/NEWS
> >
> > init support has been deprecated upstream and systemd support is now
> > mandatory.
> > I create a debian/NEWS so to explain the purpose. I need also to tell about
> > other big changes there after all. Thank you for the suggestion.
>
> It's sad to see sysv init support go but if is like this then "oh
> well".
>
> > I'm pretty sure the package doesn't build reproducibly because
> > debian/fix-install.sh
> > embeds the output of `uname -r' and `uname -n' which is a Bad Idea™
> >
> > Yes, I agree. My goal was to make it works, but surely not make it
> > works cleanly. I'll pass some time on that to make it better. I
> > even think I may have to enhance the Makefile.PL directly so every
> > can benefit from the changes I need to do for debian.
>
> > To avoid mis-understandings in issue reporting with people from
> > different platforms, we really need to set on which platform was
> > packaged the software.
>
> Ok, I see the point.
>
> > Do you know what should I do to replace theses uname commands ? Is
> > there any environment variables set by build environment I can
> > simply use ?
>
> Hm, not sure, maybe someone else has ideas what to use in this case?
> I guess the question is which information do you really need, and is
> this information consistent across different debian builds.
>
> dpkg-dev has some makefile snippets that can be included in
> debian/rules which provide variables that can be used:
> Maybe $(DEB_VENDOR) from /usr/share/dpkg/vendor.mk is enough?
Thank you, I'll check that, but I also think to see what I should better do in Makefile.PL to also limit the sources changes.
> Cheers,
> gregor
>
Cheers,
Guillaume
> --
> .''`. https://info.comodo.priv.at -- Debian Developer
> https://www.debian.org
> : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649
> AA06
> `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation
> Europe
> `- NP: Elton John: Don't Let The Sun Go Down On Me
>
Reply to: