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.
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.)
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. 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).
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 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).
> 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.
I do normally have hard-links to the build products in the common
parent directory of the per-build directories, but it's a tmpfs, so
those go away if I have rebooted.
> 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.
smcv
