[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 :)
> 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:

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


> 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.
> 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 :)
> 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:

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?>

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.
> 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.

> 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 :)
> 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.
> 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...


> 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
>     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?


 .''`.  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

Attachment: fusioninventory-agent_2.4-3_amd64.build.gz
Description: application/gzip

Attachment: signature.asc
Description: Digital Signature

Reply to: