[Pkg-shadow-devel] out of my depth

[Bálint Réczey]

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.

Cheers,
Balint