[Pkg-shadow-devel] out of my depth
Bálint Réczey
balint at balintreczey.hu
Wed Nov 30 23:08:07 UTC 2016
2016-11-30 23:16 GMT+01:00 Serge E. Hallyn <serge at hallyn.com>:
> 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.
Thanks, but I still can't push tags.
Christian, could you please fix the rights/ACLs or chown -R the repo
to me to fix it myself?
Cheers,
Balint
More information about the Pkg-shadow-devel
mailing list