> On 17 Nov 2022, at 10:39, Dodji Seketeli wrote: > > Hello Sam, > > Sam James via Libabigail a écrit: > >>> On 8 Nov 2022, at 07:35, Sam James wrote: >>> >>> On master at 9db716e3b15912b7162def1faa704eb7823bbf34: >>> .rw-r--r-- 406M sam 8 Nov 07:27  libabigail-2.2.tar.gz >>> .rw-r--r-- 348M sam 8 Nov 07:26  libabigail-2.2.tar.xz >>> >>> xz is quite a common format for software to be distributed >>> in nowadays because of its size reductions. > > This is a good idea! > > Thank you for suggesting this and coming up with this patch. > Thanks! > I just have a few comments below. > > [...] > > >>> diff --git a/ChangeLog b/ChangeLog >>> index 33944561..f7f8d6f8 100644 >>> --- a/ChangeLog >>> +++ b/ChangeLog >>> @@ -1,3 +1,11 @@ >>> +2022-11-08 Sam James >>> + >>> + build: Create an xz distribution tarball in addition to gzip. >>> + >>> + * configure.ac: add dist-xz to AM_INIT_AUTOMAKE. >>> + * Makefile.am: adjust $(TARBALL) to new extension. >>> + * Makefile.am: pass XZ_OPT="-0" for distcheck-fast. >>> + >>> 2022-09-24 Dodji Seketeli >>> >>> ir: Avoid cancelling a "confirmed" propagated canonical type > > In the format of the patches sent to the list, what is going to be added > to the ChangeLog is just put in the commit log. That part is later > automatically extracted and added to the ChangeLog at release time. In > other words, you don't have to add a ChangeLog entry in the patch. This > is explained at https://sourceware.org/git/?p=libabigail.git;a=blob_plain;f=COMMIT-LOG-GUIDELINES;hb=HEAD. > > Sorry, this seems obvious now -- I don't know how I missed it. Apologies! > So, I have edited the patch accordingly to show you what I would apply > instead. The amended patch can be found at the end of this message. > >>> diff --git a/Makefile.am b/Makefile.am >>> index 65a1b121..a0310368 100644 >>> --- a/Makefile.am >>> +++ b/Makefile.am >>> @@ -53,7 +53,7 @@ check-valgrind-recursive: >>> update-changelog: >>> python $(srcdir)/gen-changelog.py > $(srcdir)/ChangeLog >>> >>> -TARBALL = $(PACKAGE_NAME)-$(VERSION).tar.gz >>> +TARBALL = $(PACKAGE_NAME)-$(VERSION).tar.xz >>> RELEASED_BRANCH = master >> >> I should've just changed this to take two so we keep gzip (as make >> will produce one anyway), but I'll wait until feedback about if >> we want to do this at all first. > > Right, I was wondering if there could be an option to chose between .tar > and .xz for the compression format. We would then keep .xz as the > default format. > > What do you think? In any case, thanks a lot for doing this. It is > appreciated. I've tweaked it to take TARBALL as both .gz and .xz, but tbh, I think we could very uncontroversially drop .gz too. A lot of software is .xz only (like all of GNOME) and it doesn't really bother anyone. My gut is it's not worth adding additional machinery to allow disabling xz creation because it kind of conflicts with the dist-* stuff from automake (I think we could do it, but it's a bit awkward). The gzip creation is pretty cheap though. The libabigail tarball is by necessity quite large (which was the motivation originally) so I think we have decent justification. TL;DR: I'll send a patch now with fixed TARBALL variable to include both .gz and .xz but not sure it's worth the complexity to allow specifically disabling either. If I had to choose, I'd just drop gzip entirely given other projects do that fine without problems. > > Please find below the format of this patch that I would apply to the > tree if it was to get in at this point. > Thank you for the extra mile there - I've always kind of struggled with ChangeLog format for some reason. > Cheers Best, sam