Re: RFS: nanostat
Hi Andreas,
On 04.09.20 13:08, Andreas Tille wrote:
> On Fri, Sep 04, 2020 at 12:00:49PM +0200, Steffen Möller wrote:
>>> Can you please make it team maintained?
>> Done.
> Thanks.
>
>>> To my experience the way
>>> I described how to do a package at
>>>
>>> https://salsa.debian.org/med-team/community/MoM/-/wikis/home#quickstart-with-debian-med-package-template%22
>>>
>>> is the most time efficient way and ensures that your package follows the
>>> team policy. It would be great if you would prefer this over dh-make
>>> which in the end creates more work (or please tell my what is missing in
>>> our template in case you consider this wrong).
>> In my experience, packaging using dh_make is mostly reduced to using
>> "rm" and "mv" with selected edits for which I exactly know where to
>> look. There is nothing wrong with the template, and I fix it where it is
>> (the last edit is mine on
>> https://salsa.debian.org/med-team/community/package_template/-/tree/master/debian
>> :o) ) . Just, when there is a new empty project, my fingers say
>> "dh_make". Can I have a dh_make_team?
> Feel free to write it around package_template. I consider the following
> as major advantages of package_template over dh-make:
>
> 1. You have less to remove since we do not provide so many templates
> that are most probably never used in our projects.
> 2. Team maintenance is set
> 3. Vcs fields are set
> 4. You can set even more in case you have a Github based project when
> you get a working watch file and correct Homepage field
>
> It is simply less work and fits our needs better.
I had sent a friendly wishlist-level bug report to dh-make
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969527
Let's see where this goes.
>> But hey, I have adopted your routine-update, inject-into-salsa-git and
>> itp_from_debian_dir scripts and am a huge fan!!!
> I admit don't need "fans" - I just want that people save their time on
> routine jobs. ;-)
>
>>> BTW, dh-make also adds the perfectly redundant "debian uupdate" to the
>>> watch file. Routine-update does not work properly with this. The
>>> easiest solution is to simply not use this redundant strings (or not use
>>> dh-make at all as I'd suggest for years). The possibly better solution
>>> would be to fix routine-update but I will not spent my time into it
>>> since for me that problem is not visible in the packages I'm touching.
>> I think we should improve dh_make to prepare for team maintenance. And
>> routine-update to gain extra compatibility.
> I admit I'm not motivated to work on this since there is a working
> solution for me. But for sure its free software. ;-P
Hm. Hm. Hm.
> Unfortunately there is another issue in nanostat. Please try to build it
> in a chroot:
>
> ...
> mkdir -p debian/nanostat/usr
> mv debian/python3-nanostat/usr/bin debian/nanostat/usr/
> PYTHONPATH=debian/python3-nanostat/usr/lib/python3.8/dist-packages/:debian/python3-nanostat/usr/lib/python3/dist-packages/ help2man ./debian/nanostat/usr/bin/NanoStat > NanoStat.1
> help2man: can't get `--help' info from ./debian/nanostat/usr/bin/NanoStat
> Try `--no-discard-stderr' if option outputs to stderr
>
>
> I admit I personally stopped creating manpages inside the build process.
> On one hand I've never seen a fully acceptable result from help2man. On
> the other hand you spent sometimes a lot of time to get help2man working
> (as we see here). Well, it can be considered some kind of build time
> test but I guess this was not intended. If you consider creating manpages
> in advance I recommend the script createmanpages[1].
>
> [1] https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages
This happens when after being happy with the packaging you see the
lintian error about the missing man page and go through
dpkg-buildpackage afterwards, not through cowbuilder again. Aaargh.
Thank you for spotting that. Fixed now. It is an unintended build time
test, indeed. But what I value the most is an automated consistency
between what upstream provides and the man page that we show. If I'd
have to manually update something redistributed in the debian folder ...
unless if routine-update does it I prefer the one-off initial investment.
Done. It needed all the runtime dependencies for --help . The upcoming
NanoComp is the same. I'll ask upstream if he sees a way to delay the
import of the default modules - which would ruin this build test but a
bit of lazy loading seems appropriate.
Steffen
Reply to: