On Sat, 15 Jul 2017 at 22:13:14 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: stretch-pu: package flatpak, maybe want debdiff
> against security?"):
> > Yes, this update was proposed while stretch was still in freeze,
> > and I didn't want to annoy the release team with more pings if they
> > were deliberately leaving it dormant until after r1. Diff against
> > stretch-security attached (diffing patched tree against patched tree,
> > and excluding Autotools noise, translations, HTML docs, and the patches
> > that were dropped but not their effects).
>
> Thanks. This is IMO much better. I looked at the diff and almost
> everything in it is covered by your changelog entries. However:
>
> * document-portal/xdp-dbus.c was generated by a version of
> gdbus-codegen which seems to be only in Debian experimental. !
This is regenerated at build time. I sent patches upstream to exclude
it from the distributed orig.tar.gz, which were accepted, so this won't
be an issue in 0.9.x; but that patch isn't going to be included in the
0.8.x stable branch (unless someone from the stable release team asks
for it) because it isn't a fix for a user-observable bug.
I can exclude it from future diffs if desired.
> * gtk-doc.make has some noise (which seems to be just whitespace
> changes but which is a bit hard to review as-is)
gtk-doc.make is copied in from gtk-doc-tools by gtkdocize during the
upstream autogen.sh run. It isn't currently replaced by dh_autoreconf.
I could re-run gtkdocize with Debian's gtk-doc-tools at dh_autoreconf
time if the release team want, but my assumption had been that this
non-minimal change would be rejected.
I can confirm that
git diff --ignore-space-change debian/stretch..debian/stretch-proposed --
gtk-doc.make
eliminates all the changes except for deletion of one blank line,
and the re-wrapping in the last patch band.
> This is a bit odd. Are these generated files even though they are in
> the source package ?
Yes. Blame Autotools.
It's possible that Flatpak upstream will eventually follow GNOME into
using Meson instead of Autotools, at which point their source releases
will probably become a submodule-aware version of `git archive`; but I
don't think they are in any hurry to do so.
S
