GNOME Bugzilla – Bug 768218
release tarball 3.20.3 contains empty ChangeLog
Last modified: 2016-07-09 18:32:37 UTC
The ChangeLog file shipped in the 3.20.3 release tarball is empty. I suspect this is related to commit 44dd3b90505c931a7cff5833760380e8b634fc02 Author: Michael Catanzaro <mcatanzaro@gnome.org> Date: Mon Jun 20 13:53:03 2016 -0500 Fix ChangeLog generation for srcdir != builddir
That said, could we do something about the size of the file: 6,1M ChangeLog That seems a bit excessive.
Ooops, probably should have opened the file to make sure it worked. (In reply to Michael Biebl from comment #1) > That said, could we do something about the size of the file: > 6,1M ChangeLog > > That seems a bit excessive. It's a history of all git commits, it's just gonna get bigger. I was thinking about just getting rid of it, since many (most?) GNOME apps don't install these anymore.
Alternatively we could truncate the file at some arbitrary point.
(In reply to Michael Catanzaro from comment #3) > Alternatively we could truncate the file at some arbitrary point. I would probably be ok with that. We already have a NEWS file and for more detailed changes a git checkout is much more convenient anyway.
Hmmm, I just built a new tarball and the ChangeLog is there, 6.4 MB. But I see that it's definitely not there on download.gnome.org. Strange.
It doesn't work because $(top_builddir) is defined as . and so after a cd it will always be the new cwd. Probably best to generate it in srcdir. All the autotools goo is already being generated in srcdir in a git checkout (seems to defeat the purpose of srcdir != builddir) so it's no big deal. I still prefer to remove it entirely; is it at all useful for Debian? You don't install it, right?
Created attachment 330626 [details] [review] build: Fix misleading changelog generation code $(top_builddir) is defined as . and so it's always the cwd, hence the ChangeLog is always being generated in $(srcdir). Make it clear that's what's going on.
Created attachment 330627 [details] [review] Limit size of ChangeLog file Take the last 500 commits; works out to a little over half a year of commits at the current rate. Reduces the ChangeLog to a reasonable size.
(In reply to Michael Catanzaro from comment #8) > Created attachment 330627 [details] [review] [review] > Limit size of ChangeLog file > > Take the last 500 commits; works out to a little over half a year of > commits at the current rate. Reduces the ChangeLog to a reasonable size. I think that will do nicely. I was about to suggest to only include the changes between release x and x+1, but your patch is equally fine I think.
Honestly still inclined to remove the ChangeLog file, but this is good enough for now. Attachment 330626 [details] pushed as bae5410 - build: Fix misleading changelog generation code Attachment 330627 [details] pushed as c2308d8 - Limit size of ChangeLog file
Just saw the commit and I was wondering if it shouldn't be generated rather in $(abs_top_builddir)?
(In reply to Krzesimir Nowak from comment #11) > Just saw the commit and I was wondering if it shouldn't be generated rather > in $(abs_top_builddir)? Ah, of course. Thank you.
The following fix has been pushed: 2b75aa1 Generate ChangeLog in builddir
Created attachment 331140 [details] [review] Generate ChangeLog in builddir