[Pkg-shadow-devel] out of my depth

[Serge E. Hallyn]

Quoting Bálint Réczey (balint at balintreczey.hu):
> Hi Serge,
> 
> 2016-11-30 17:14 GMT+01:00 Serge E. Hallyn <serge at hallyn.com>:
> > On Wed, Nov 30, 2016 at 12:47:19AM +0100, Bálint Réczey wrote:
> >> 2016-11-30 0:45 GMT+01:00 Bálint Réczey <balint at balintreczey.hu>:
> >> > Hi,
> >> >
> >> > 2016-11-27 9:02 GMT+01:00 Mike Frysinger <vapier at gentoo.org>:
> >> >> On 25 Nov 2016 13:42, Serge E. Hallyn wrote:
> >> >>> On Tue, Nov 22, 2016 at 02:23:56AM +0100, Bálint Réczey wrote:
> >> >>> > 2016-11-22 2:19 GMT+01:00 Serge E. Hallyn <serge at hallyn.com>:
> >> >>> > > Quoting Bálint Réczey (balint at balintreczey.hu):
> >> >>> > >> Hi Serge,
> >> >>> > >>
> >> >>> > >> I started reviewing the new package. The changes in Debian look good
> >> >>> > >> but the generated
> >> >>> > >> files in the original tarball do worry me.
> >> >>> > >> Those are not present in tag 4.4 in upstream repository.
> >> >>> > >
> >> >>> > > Hi,
> >> >>> > >
> >> >>> > > Are you talking about the po/*.gmo files?  They keep getting
> >> >>> > > autogenerated now witha 'make dist'.  That is what the first email
> >> >>> > > in this thread was asking about, in particular:
> >> >>> > >
> >> >>> > > |>> autogen.sh calls autoreconf which calls autopoint, which creates
> >> >>> > > |>> m4/po.m4, which creates po/Makefile.in.in, which creates a makefile
> >> >>> > > |>> which ends up calling
> >> >>> > > |>>
> >> >>> > > |>> cd $(srcdir) && rm -f $${lang}.gmo && $(GMSGFMT) -c --statistics -o t-$${lang}.gmo $${lang}.po && mv t-$${lang}.gmo $${lang}.gmo
> >> >>> > > |>>
> >> >>> > > |>> etc.  The *.gmo files are binary ones, which we don't want to be
> >> >>> > > |>> shipping iiuc.  So - what is an ignorant packager to do?  It seems
> >> >>> > > |>> like there must be an obvious flag to add to autoreconf in autogen.sh,
> >> >>> > > |>> but I can't find it.
> >> >>> > >
> >> >>> > > So they are not in the git tree but they are in fact in the upstream tarball.
> >> >>> > > I could manually pull them out of the packaging source.orig.gz if that's
> >> >>> > > the right thing to do...
> >> >>> >
> >> >>> >
> >> >>> > Please don't use make dist.
> >> >>>
> >> >>> Huh.  That's the first time I've heard that suggestion.
> >> >>
> >> >> it's a bad suggestion in this case.  some people try to be super strict
> >> >> in that the releases are always reproducible from git.  while that might
> >> >> work for some projects, it doesn't for ones that use a generated build
> >> >> system like autotools.  in order to pull it off, you'd have to actually
> >> >> commit the generated output (e.g. "configure" and "config.h.in" and all
> >> >> the rest) to git which is an even worse idea.
> >> >
> >> > I may not have been clear enough, but I had no intention to suggest
> >> > storing generated files in git. This would be a bad idea. I would like to ask
> >> > for basing the Debian package on a tarball _not_ containing generated
> >> > files such as Makefile.in.
> >> >
> >> > Reviewing changes when autogenerated files pollute the diff is harder
> >> > and shadow is an important package.
> >> >
> >> > Note that 4.2-3 did not have generated files in the source package:
> >> > $ git diff --stat debian/4.2-3  | head
> >> >  .gitignore                                         |    47 -
> >> >  ABOUT-NLS                                          |  1101 +
> >> >  Makefile.in                                        |   852 +
> >> >  aclocal.m4                                         | 12674 +++++++++++
> >> >  autogen.sh                                         |    12 -
> >> >  compile                                            |   347 +
> >> >  config.guess                                       |  1441 ++
> >> >  config.h.in                                        |   603 +
> >> >  config.rpath                                       |   614 +
> >> >  config.sub                                         |  1813 ++
> >> >
> >> >>
> >> >>
> >> >> so when making shadow releases, you should be using `make distcheck`.
> >> >> you can then attach the tarball to the github page under the releases
> >> >> section.
> >> >
> >> > Why? Who can't use the git archive output?
> >> > In Debian you have to regenerate all generated files in the source package
> >> > or prove that they can be regenerated. How do you prove that for all
> >> > the files in the dist tarball?
> >> >
> >> > Tomorrow I'll update the packaging repository and show what I meant.
> >>
> >> BTW when importing new upstream please push the upstream branch and
> >> tag to the packaging repo because git-buildpackage needs those.
> >
> > Hi,
> >
> > I hadn't wanted to pollute the git tree with my attempts, but I went ahead
> > and pushed an older branch.  Also, my most recent packaging is at
> >
> > https://mentors.debian.net/debian/pool/main/s/shadow/shadow_4.4-1.dsc
> >
> > Note the git tree is *behind* the package posted at mentors.  Sigh, I'm now
> > regretting having pushed that.
> >
> > I'll urge you to keep in mind that several debian developers appear to have
> > different opinions on the best way - so if you intend to maintain the package
> > then that's great, if not then insisting on specific workflows (like using
> > git) to sponsor a package seems unhealthy.  And in general, manufacturing a
> > git tree from another git tree and existing package, in order to re-generate
> > the package, seems like begging for trouble and frustration.
> >
> > Dropping the .gmo files certainly seems to be agreed-upon, and the package on
> > mentors does that.  I can drop the rest of the auto-generated files too, if you
> > like.  Please let know.
> 
> I have continued the pristine-tar, upstream and master branches in the
> packaging repo following the original repo structure.
> I offer (co-)maintaining the package to resolve the problems related
> to sponsorship
> and thank you for maintaining shadow as new upstream.
> 
> Could you please You or Christian add me as admin to the shadow team
> in the hope that I could then push tags to the repo?

Great, thanks.