[Pkg-shadow-devel] out of my depth

[Bálint Réczey]

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?

Cheers,
Balint