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

Re: RFS: nanostat



Hi Steffen,

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

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

Kind regards
      Andreas.

[1] https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages

-- 
http://fam-tille.de


Reply to: