[Pkg-shadow-devel] out of my depth

[Mike Frysinger]

On Thu, Dec 1, 2016 at 4:36 PM, Serge E. Hallyn wrote:
> Quoting Mike Frysinger (vapier at gentoo.org):
>> On Thu, Dec 1, 2016 at 3:48 PM, Serge E. Hallyn wrote:
>> > Quoting Mike Frysinger (vapier at gentoo.org):
>> >> On Thu, Dec 1, 2016 at 2:49 PM, Serge E. Hallyn wrote:
>> >> > Quoting Mike Frysinger (vapier at gentoo.org):
>> >> >> On Thu, Dec 1, 2016 at 8:57 AM, Bálint Réczey wrote:
>> >> >> > 2016-12-01 8:25 GMT+01:00 Mike Frysinger:
>> >> >> >> On Tue, Nov 29, 2016 at 6:45 PM, Bálint Réczey wrote:
>> >> >> >>> 2016-11-27 9:02 GMT+01:00 Mike Frysinger:
>> >> >> >>>> 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:
>> >> >> >>>>> > 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.
>> >> >> >>
>> >> >> >> i have no opinion at all how Debian wants to maintain their .deb sources
>> >> >> >
>> >> >> > This thread was about that question.
>> >> >>
>> >> >> no, this thread was about including gmo files in the dist tarball.  it
>> >> >> then spiraled into the weeds with people giving bad advice for how to
>> >> >> do a release.
>> >> >>
>> >> >> >>> Reviewing changes when autogenerated files pollute the diff is harder
>> >> >> >>> and shadow is an important package.
>> >> >> >>
>> >> >> >> yes, but as a general thing, always rebuilding autotools from scratch
>> >> >> >> is kind of wasteful and can be a pain when the sources aren't kept up
>> >> >> >> to date (and you try to use newer autotools which have new
>> >> >> >> warnings/errors).  i'm not familiar with how Debian typically builds
>> >> >> >> things though, so maybe that's "normal".
>> >> >> >>
>> >> >> >>>> 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?
>> >> >> >>
>> >> >> >> forcing all users of shadow to build autotools from scratch is
>> >> >> >> fundamentally wrong.  it defeats the entire purpose of autotools.  if
>> >> >> >> *you* don't want to use them, then fine, don't, but Debian is not the
>> >> >> >> entire ecosystem.
>> >> >> >
>> >> >> > Please open an issue at upstream if you really need ./configure
>> >> >> > generated for you:
>> >> >> > https://github.com/shadow-maint/shadow
>> >> >>
>> >> >> opening a bug report for an issue that can't be solved by a
>> >> >> creating&pushing a commit won't help.  the release process here is
>> >> >> broken and that's external to the code in git.
>> >> >
>> >> > I've uploaded a new tarball and signature to
>> >> >         http://people.ubuntu.com/~serge-hallyn/shadow-4.4
>> >> > (just to not pollute github right now).  Could you take a look and tell
>> >> > me whether that looks ok to you?
>> >>
>> >> running a few sanity tests on it looks good.  there's a few build
>> >> errors, but it's unrelated to the packaging tarball, so i'll send PRs
>> >> for them :).
>> >
>> > Great, thanks.
>> >
>> >> while we're looking at this, how do people feel about dropping bzip2
>> >> and moving to xz instead ?  some larger projects (like everyone hosted
>> >> on kernel.org) have opted to only release gzip (for legacy/wide
>> >> compatibility) & xz (for smaller size) now and no longer post bz2's.
>> >
>> > make dist created both gz and bz2.  I'll post the gz for now, and once
>> > there is a patch to make 'make dist' produce xz i'll post those :)
>>
>> np, i can send a PR for that
>
> Great, thanks.
>
>> it'll be a few days though ... i just moved houses and my main dev box
>> hasn't been reconnected yet
>
> Given the delays over the last few months that should be no a big deal :)
>
> For now I've pushed the release tarball to
> github.com/shadow-maint/shadow-releases.

that's a very uncommon method of release.  why not use the standard GH method ?

(1) go to the tag page e.g.
https://github.com/shadow-maint/shadow/releases/tag/4.4
(2) click the Edit Tag button on the right side
(3) paste in the release notes (usually taken from the NEWS or
ChangeLog file in the source tree)
(4) use the attach binaries form at the bottom of the page to attach the tarball
(5) hit Publish Release

now the release page for that tag will have a lot more useful details
-mike