[Pkg-shadow-devel] out of my depth

[Serge E. Hallyn]

Quoting Mike Frysinger (vapier at gentoo.org):
> 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

Oh,

only because when I read the github docs about that process, I thought they
were saying that the the binaries I attach were going to be inserted into
the release tarball.

> (5) hit Publish Release
> 
> now the release page for that tag will have a lot more useful details

Sounds good.  I'll do that this week.  Using the same tarballs I have in the
shadow-releases tree (which I'll then delete).

thanks,
-serge