Simon McVittie writes ("Re: Bug#939280: dgit push-source rejects source-only
.changes containing .orig.tar.gz.asc"):
> On Wed, 04 Sep 2019 at 00:02:06 +0100, Ian Jackson wrote:
> > I think the -C option should not be necessary. Indeed I'm
> > not even sure what it does (or should mean) with push-source. dgit
> > push-source is supposed to be used without a prior build step.
> > Without -C it builds its own dsc.
>
> The man page says:
>
> With -C, performs a dgit push, additionally ensuring that no binary
> packages are uploaded.
Oh! I had forgotten that. (The push-source feature was invented and
implemented by Sean.) That is a sensible meaning for this option :-).
> which I think is exactly what I want whenever I am not going through NEW.
> I already have a way to produce a "clean" source.changes file, and I'm
> trying to do all my uploads with dgit to be nice to people who use
> the dgit data model more heavily than I do. (I continue to prefer a
> patches-unapplied maintainer view, which I think is something we will
> have to "agree to disagree" on - but now that dgit can cope gracefully
> with that, we can both have what we want.)
Right.
I'm about to get into the discussion of your workflow and other
possible workflows. I want to frame that first by saying:
Your workflow is fine and the reason it's not working with push-source
right now is purely a dgit bug.
I think the discussion of why you do what you're doing is interesting,
and I hope you'll find discussion of other possible workflows
interesting too. But I'm not trying to talk you into doing anything
different.
Having tried it, I think
dgit push-source
*without* a -C option, will also work. Probably this is because
the "polluted by ..." check isn't done on that path. (I guess dgit
can be confident that its own-generated source-only changes is right.)
Of course that will generate a fresh .dsc and upload that, so it's not
the same as your intended workflow and doesn't have all the properties
you want (which you discuss in your mail).
My own practice for local tests of formal binary builds is to do all
of this *before* finalising the changelog (stripping the ~ from the
version). I don't redo the formal binary build myself after
finalising the changelog: at that point I just do dgit push-source.
That way my locally-built formal test binaries have a different
version to the official Debia buildd ones, which means I can always
tell whether I'm running my own builds.
> For context, my current workflow goes something like this:
>
> - gbp buildpackage --git-builder='vectis sbuild'
> - (vectis produces source-only and source+binary changes files)
> - (test resulting binaries)
> - dgit push-source -C .../*_source.changes
>
> vectis <https://salsa.debian.org/smcv/vectis> isn't among the builders
> supported by dgit, because right now I'm probably its only user.
The only reason dgit needs to wrap all of these builders is this bug:
#908747 [n| | ] [dpkg-dev] dpkg-source: Default -I and -i option
should not exclude .<vcs>ignore
If your git tree doesn't have changes to the upstream .gitignore then
you don't need the dgit builder wrappers.
> It does the builds in a stable VM using stable's sbuild, in a way
> that resembles production buildds as closely as possible, so that I
> don't get nasty surprises when the behaviour of production buildds
> differs from my laptop's sbuild (for example during the buster
> development cycle, sbuild from unstable would have done builds with
> LC_ALL=C.UTF-8, but the production buildds used LC_ALL=POSIX, which
> makes some of my packages fail build-time tests because they want to
> print strings that are not representable in ASCII).
Glerk. We should probably change the buildd locale...
> vectis transfers the source code to be built into a chroot that matches
> the target suite, and uses sbuild there to build a "clean" source package,
> which avoids the contents of the built source package being dependent
> on whatever outdated, modified or experimental packages I might have
> installed on my main system. Perhaps that isn't necessary, but I was
> using sbuild already, so it was easy to add that step; and it wasn't
> clear to me that the .dsc generation is entirely deterministic from a
> particular source tree in git.
I can see why you would want to do that. dgit's source package
builder is more controlled than gbp's, and I have confidence in it, so
I don't feel the need to build my dscs in a chroot.
Ideally we would publish git tags and an official Debian service would
make dscs from them - that's my tag2upload proposal, which is
strangely currently being blocked because of worries about the
verifiability of the relationship between git ags and dsc contents.
> I don't use any of the subcommands resembling 'dgit build' because they
> tend to expect/assume ../ as the directory for orig tarballs and build
> products, which I want to avoid because my source code directory is
> included in backups, but in general I don't want the orig tarballs and
> build products to be in backups (I can always re-download or rebuild
> them so there's no point).
dgit --build-products-dir and the corresponding config are supposed to
address this.
But as I say you do not need to use the dgit build wrapper stuff.
That that has to exist at all is quite annoying ...
> > Ie ISTM that you ought not to need step 3 of your list above, nor the
> > -C option. Just dgit push-source ought to pick up and use the .asc.
>
> Pick up from where, though? I would prefer not to have to specify the
> --build-products-dir, because vectis normally outputs each build and all
> its logs, autopkgtest results, etc. into its own directory to make it
> easier to copy around as a unit (in my case, I copy it from a tmpfs onto
> persistent storage if my final testing is going to involve a reboot). -C
> conveniently looks for all files next to the requested .changes file.
See above. I'm not sure why --build-products-dir and -C are
particularly differently convenient but I think your desire to make
the dsc in a chroot is a comprehensible reason for your existing
workflow.
> > For my reference: it's not clear to me whether dgit used the specified
> > -C at all. It may have built a correct .changes file an then
> > complained about its own output.
>
> In the case of dbus-python, it definitely signed and uploaded the .changes
> file that I specified, and not one in the --build-products-dir (breaking
> the hard-link in the process), so I think it's behaving as I expected.
OK good.
Regards,
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
