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:
#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.
> 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:
#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.
> 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 :)
> 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...
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?
Cheers,
gregor
--
.''`. 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