Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
On Mon, Feb 05, 2018 at 02:27:50PM -0700, Sean Whitton wrote: > I would suggest that we require the user to pass/set > --build-products-dir rather than adding all the parsing code to dgit. FTR, I agree. Especially if you make it configurable instead of forcing a cli flag. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
Hello,
On Mon, Feb 05 2018, Ian Jackson wrote:
> Sean Whitton writes ("Re: Bug#844125: dgit: Built-in support for
>pbuilder [and 1 more messages]"):
>> I haven't yet read your older mail where you came to the conclusion
>> that it would be necessary for dgit to parse pbuilder's config, but
>> we should be really sure it's necessary before going for that.
>
> I don't think there was a mail. I looked for it but couldn't find it.
> Nor does my blather in ad-hoc git commits explain. My best guess now
> is that I wanted dgit to honour pbuilder's build area configuration.
> Let us proceed on that assumption, and therefore take your advice.
I would suggest that we require the user to pass/set
--build-products-dir rather than adding all the parsing code to dgit.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
Sean Whitton writes ("Re: Bug#844125: dgit: Built-in support for pbuilder [and
1 more messages]"):
> I haven't yet read your older mail where you came to the conclusion that
> it would be necessary for dgit to parse pbuilder's config, but we should
> be really sure it's necessary before going for that.
I don't think there was a mail. I looked for it but couldn't find it.
Nor does my blather in ad-hoc git commits explain. My best guess now
is that I wanted dgit to honour pbuilder's build area configuration.
Let us proceed on that assumption, and therefore take your advice.
Thanks,
Ian.
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
Hello,
On Mon, Jan 29 2018, Ian Jackson wrote:
> Mattia Rizzolo writes ("Bug#844125: dgit: Built-in support for
>pbuilder [and 1 more messages]"):
>> [lots of explanation]
>
> Thanks, that is very helpful information.
Indeed. Many thanks.
>> Anyway, isn't this discussion kind of moot? I understood that for
>> reasons you're thinking of specifying `--debbuiltopts -b`, so you'd
>> get a binary only build and that one would discard the .orig as well
>> (as with -b the source don't appear on the .changes at all).
>
> Yes, well, technically it is moot for supporting pbuilder as a dgit
> build option. But I think gbp users will probably want
> --build--products-dir more often than eg sbuild users, so proper
> pbuilder support means fixing #863582 (that --b-p-d does not always
> work properly) and #857316 (that it is not configurable).
Not fixing #863582 will make `dgit pbuilder` very confusing; on the
other hand, not fixing #857316 just makes it inconvenient. So I think
this bug is blocked by only the former (as indeed the BTS metadata says
ATM).
> It might be necessary for dgit to override some of the user's pbuilder
> config. (And, as I said in my other mail, it might also be desirable
> for dgit to interrogate the pbuilder config so that it can honour it.)
Like Mattia, I'm very queasy about this, because pbuilder's config is
not declarative. Indeed, everything seems to be shell scripts.
I haven't yet read your older mail where you came to the conclusion that
it would be necessary for dgit to parse pbuilder's config, but we should
be really sure it's necessary before going for that.
On Mon, Jan 29 2018, Mattia Rizzolo wrote:
> Then, there are other gotchas, that make the whole "ask pbuilder what
> its configuration is" kind of pointless: pbuilderrc is a shell script
> and therefore interpreted at runtime. If a user wants to (I do for
> some things) it can compute values according to what I've been asked
> to do, so for example somebody may have options with different values
> according to what subcommand is being run. But I believe this is very
> similar for sbuild as well, isn't it?
sbuild uses shell scripts to add things like tmpfs usage to the build,
but its configuration is a mixture of perl and ini, not shell. So the
situation is slightly better.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
On Mon, Jan 29, 2018 at 02:05:07PM +, Ian Jackson wrote: > Ah. But AIUI source-only upload *must not* be accompanied by an > _amd64.buildinfo (with the same name, anyway) because that *clashes* > with the buildd's .buildinfo. dak handles them correctly whenever there is not a queue in front of the suite. So for example doing that for sid and exp uploads is totally fine, whereas doing that for stable uploads ends up in headaches for everybody. > Right. I was aware of this. Of course `env' output is not reliably > parseable if the values might contain newlines but I think we can hope > that it doesn't and read it accordingly in dgit. haha, don't keep your hopes too high :P If you watch my own output you'll see that it does contain newlines within the variables :) And also it's not only `env` output, but it's `(set -o posix; set)` followed by `env` with random messages from pbuilder itself. Let's just say that `pbuilder dumpconfig` is not really usable for parsing, it's mostly a debugging tool IMHO. > (Ideally I think pbuilder dumpconfig would fail if the output is > misleading.) Of course it doesn't, and I don't believe it's its job to do it. Then, there are other gotchas, that make the whole "ask pbuilder what its configuration is" kind of pointless: pbuilderrc is a shell script and therefore interpreted at runtime. If a user wants to (I do for some things) it can compute values according to what I've been asked to do, so for example somebody may have options with different values according to what subcommand is being run. But I believe this is very similar for sbuild as well, isn't it? Anyway, that's all speculation, I believe we should check what the problems are, and what we'd need to do before worrying about how the world is not nice to us. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
Mattia Rizzolo writes ("Bug#844125: dgit: Built-in support for pbuilder [and 1
more messages]"):
> On Mon, Jan 29, 2018 at 01:09:25PM +, Ian Jackson wrote:
> > I'm not sure why anyone would use SOURCE_ONLY_CHANGES=yes so I don't
> > know why and how dgit should allow them to achieve the same result.
>
> Think of the original goal of buildinfo files: a DD uploads a *source*
> package AND a buildinfo, then the source is rebuild and the buildinfo
> compared.
> So, with that you can upload all the sources, plus a _amd64.buildinfo
> describing the build.
Ah. But AIUI source-only upload *must not* be accompanied by an
_amd64.buildinfo (with the same name, anyway) because that *clashes*
with the buildd's .buildinfo.
> > It might be necessary for dgit to override some of the user's pbuilder
> > config. (And, as I said in my other mail, it might also be desirable
> > for dgit to interrogate the pbuilder config so that it can honour it.)
>
> There is a command for this, but it may be a tad noisy:
> mattia@warren ~/devel/debian/limnoria % /usr/sbin/pbuilder dumpconfig >
> /tmp/dumpconfig
> mattia@warren ~/devel/debian/limnoria %
>
> File attached, so you can see all the crap and ends up in it, there is a
> whole `env` output, so…
Right. I was aware of this. Of course `env' output is not reliably
parseable if the values might contain newlines but I think we can hope
that it doesn't and read it accordingly in dgit. (Ideally I think
pbuilder dumpconfig would fail if the output is misleading.)
Ian.
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
On Mon, Jan 29, 2018 at 01:09:25PM +, Ian Jackson wrote: > > Obviously that doesn't include people with SOURCE_ONLY_CHANGES=yes, > > as those when doing a -b build would get a _amd64.changes with only > > .debs and a _source.changes with only source. > > I'm not sure why anyone would use SOURCE_ONLY_CHANGES=yes so I don't > know why and how dgit should allow them to achieve the same result. Think of the original goal of buildinfo files: a DD uploads a *source* package AND a buildinfo, then the source is rebuild and the buildinfo compared. So, with that you can upload all the sources, plus a _amd64.buildinfo describing the build. > My initial reaction is that if the user wants this, then dgit should > still make the source package itself. I haven't make up my mind on this. > It might be necessary for dgit to override some of the user's pbuilder > config. (And, as I said in my other mail, it might also be desirable > for dgit to interrogate the pbuilder config so that it can honour it.) There is a command for this, but it may be a tad noisy: mattia@warren ~/devel/debian/limnoria % /usr/sbin/pbuilder dumpconfig > /tmp/dumpconfig mattia@warren ~/devel/debian/limnoria % File attached, so you can see all the crap and ends up in it, there is a whole `env` output, so… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- [0;34mD: cmdline: dumpconfig [0m [0mI: start dump config[0m [0mI: (set -o posix; set)[0m ALLOWUNTRUSTED=no APTCACHE=/home/mattia/pbuilder/cache/apt/unstable/amd64 APTCACHEHARDLINK=no APTCONFDIR= APTGETOPT=() APTITUDEOPT=() APTKEYRINGS=() ARCHITECTURE=amd64 AUTOCLEANAPTCACHE=yes BASEBUILDPLACE=/home/mattia/pbuilder/build BASES=/home/mattia/pbuilder/chroots BASETGZ=/home/mattia/pbuilder/chroots/unstable-amd64-base.tgz BASH=/bin/bash BASHOPTS=cmdhist:complete_fullquote:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=([0]="1") BASH_ARGV=([0]="dumpconfig") BASH_CMDS=() BASH_LINENO=([0]="0") BASH_SOURCE=([0]="/usr/sbin/pbuilder") BASH_VERSINFO=([0]="4" [1]="4" [2]="12" [3]="1" [4]="release" [5]="x86_64-pc-linux-gnu") BASH_VERSION='4.4.12(1)-release' BINARY_ARCH=any BINDMOUNTS='/home/mattia/pbuilder/cache/ccache /home/mattia/pbuilder/repository /home/mattia/pbuilder/result' BINNMU_MAINTAINER='Mattia Rizzolo ' BIN_NMU=no BUILDDIR=/build BUILDPLACE=/home/mattia/pbuilder/build/31991 BUILDRESULT=/home/mattia/pbuilder/result/unstable/amd64 BUILDSOURCEROOTCMD=fakeroot BUILDUSERID=1234 BUILDUSERNAME=pbuilder BUILD_HOME=/nonexistent CCACHEDIR=/home/mattia/pbuilder/cache/ccache CHROOTEXEC='chroot /home/mattia/pbuilder/build/31991 ' CMDLINE= COLORTERM=yes COMPONENTS=main COMPRESSPROG=cat CONFDIR=/etc/pbuilder/conf_files DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DEBBUILDOPTS= DEBDELTA=no DEBEMAIL=mat...@debian.org DEBFULLNAME='Mattia Rizzolo' DEBIAN_FRONTEND=noninteractive DEBOOTSTRAP=debootstrap DEBOOTSTRAPOPTS=([0]="--variant=buildd" [1]="--force-check-gpg") DEB_BUILD_ARCH_OS=linux DEB_BUILD_OPTIONS=parallel=4 DESKTOP_SESSION=lightdm-xsession DH_VERBOSE=1 DIRSTACK=() DISPLAY=:0 DISTRIBUTION=unstable DPKG_GENSYMBOLS_CHECK_LEVEL=4 EATMYDATA=yes EDITOR=vim EMAIL=mat...@debian.org EUID=1000 EXPERIMENTAL= EXTRAPACKAGES='debian-ports-archive-keyring apt-utils' FORCE_CONFNEW=([0]="-o" [1]="DPkg::Options::=--force-confnew") GCC_COLORS=1 GDMSESSION=lightdm-xsession GDM_LANG=en_US.utf8 GPGKEY=66AE2B4AFCCF3F52DA184D184B043FCDB9444540 GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 GROUPS=() HOME=/home/mattia HOOKDIR=/home/mattia/pbuilder/hooks HOSTNAME=warren HOSTTYPE=x86_64 IFS=' ' IGNORE_UMOUNT= INTERNAL_BUILD_UML= LANG=C LANGUAGE=en_US:en LC_ALL=C LESS='-R -M' LESS_TERMCAP_mb='[01;31m' LESS_TERMCAP_md='[01;31m' LESS_TERMCAP_me='[0m' LESS_TERMCAP_se='[0m' LESS_TERMCAP_so='[01;44;33m' LESS_TERMCAP_ue='[0m' LESS_TERMCAP_us='[01;32m' LOGLEVEL=D LOGNAME=mattia LS_COLORS='rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
Mattia Rizzolo writes ("Bug#844125: dgit: Built-in support for pbuilder [and 1
more messages]"):
> [lots of explanation]
Thanks, that is very helpful information.
> Anyway, isn't this discussion kind of moot? I understood that for
> reasons you're thinking of specifying `--debbuiltopts -b`, so you'd get
> a binary only build and that one would discard the .orig as well (as
> with -b the source don't appear on the .changes at all).
Yes, well, technically it is moot for supporting pbuilder as a dgit
build option. But I think gbp users will probably want
--build--products-dir more often than eg sbuild users, so proper
pbuilder support means fixing #863582 (that --b-p-d does not always
work properly) and #857316 (that it is not configurable).
Also, dgit's divergence from pbuilder on the name
(--build-products-dir vs. --buildresult) is probably a bad thing.
> Obviously that doesn't include people with SOURCE_ONLY_CHANGES=yes,
> as those when doing a -b build would get a _amd64.changes with only
> .debs and a _source.changes with only source.
I'm not sure why anyone would use SOURCE_ONLY_CHANGES=yes so I don't
know why and how dgit should allow them to achieve the same result.
My initial reaction is that if the user wants this, then dgit should
still make the source package itself.
It might be necessary for dgit to override some of the user's pbuilder
config. (And, as I said in my other mail, it might also be desirable
for dgit to interrogate the pbuilder config so that it can honour it.)
Ian.
--
Ian JacksonThese 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.
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
On Mon, Jan 29, 2018 at 12:09:04PM +, Ian Jackson wrote: > Right. But if you're not doing a -1 upload the .orig is somewhere > else ? In that case the .orig is simply discarded after doing the build instead of being copied out of the chroot. > Right, but is the normal workflow to have the .orig in .. when working > in ../ ? That's what I do at least. mattia@warren ~/devel/debian/limnoria % tree -L 2 . ├── gpg │ └── ├── limnoria │ ├── debian │ ├── locales │ ├── limnoria_2017.10.01-1.debian.tar.xz ├── limnoria_2017.10.01-1.dsc ├── limnoria_2017.10.01.orig.tar.gz ├── limnoria_2017.10.01.orig.tar.gz.asc └── And when I try to build that .dsc I end up with: mattia@warren ~/devel/debian/limnoria % DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=nocheck pbuilder b limnoria_2017.10.01-1.dsc … mattia@warren ~/devel/debian/limnoria % ls ~/pbuilder/result/unstable/amd64/ limnoria_2017.10.01-1_all.deb limnoria_2017.10.01-1.dsc limnoria_2017.10.01-1_amd64.buildinfo limnoria_2017.10.01-1_source.changes limnoria_2017.10.01-1_amd64.changeslimnoria_2017.10.01.orig.tar.gz limnoria_2017.10.01-1.debian.tar.xzlimnoria_2017.10.01.orig.tar.gz.asc > Does that mean the origs end up in multiple places ? Well, you've got one in .., as you said. Then pbuilder copies it into the chroot for building. Some black boxes later the full build is done and comes the time to export the build artifacts out of the chroot into the original system, at this point: * you are doing a -1 build, so it copied out into --buildresult together with the .debs * you are doing a -2 build, so it is not copied out Here I'm writing 'a -1 build' and 'a -2 build', but clearly there are several other cases that makes a .orig appear or not in a .changes file. In the case of a -1 build (with the default configuration where --buildresult is not ..!) you effectively end up with two copies of the .orig: one in .. and one in --buildresult. Anyway, isn't this discussion kind of moot? I understood that for reasons you're thinking of specifying `--debbuiltopts -b`, so you'd get a binary only build and that one would discard the .orig as well (as with -b the source don't appear on the .changes at all). Obviously that doesn't include people with SOURCE_ONLY_CHANGES=yes, as those when doing a -b build would get a _amd64.changes with only .debs and a _source.changes with only source. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
Mattia Rizzolo writes ("Bug#844125: dgit: Built-in support for pbuilder [and 1
more messages]"):
> In the --build-products-dir (which pbuilder calls --buildresult) there
> is going to be whatever is referenced by the *.changes files (note the
> plural, if we are generating more than one due to --source-only-changes
> then all files referenced by all of them are considered).
> Which means, if you are doing a full build of a -1 upload, the .orig
> tarball is going to be there, if you are specifying -sa it's going be
> there, etc etc.
Right. But if you're not doing a -1 upload the .orig is somewhere
else ?
> Of course, pbuilder expects the .orig to be next to the .dsc as an
> input.
Right, but is the normal workflow to have the .orig in .. when working
in ../ ? Does that mean the origs end up in multiple
places ?
Ian.
--
Ian JacksonThese 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.
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
On Mon, Jan 29, 2018 at 11:29:25AM +, Ian Jackson wrote: > > 2. I am not sure where origs should go when --build-products-dir is > > being used. Is it pbuilder practice to put them in the build produts > > dir or in .. ? In the --build-products-dir (which pbuilder calls --buildresult) there is going to be whatever is referenced by the *.changes files (note the plural, if we are generating more than one due to --source-only-changes then all files referenced by all of them are considered). Which means, if you are doing a full build of a -1 upload, the .orig tarball is going to be there, if you are specifying -sa it's going be there, etc etc. > > If they go in build-products-dir then we need to do > > something extra in dgit, because many dgit operations - not limited to > > build operations - either consume or produce origs Of course, pbuilder expects the .orig to be next to the .dsc as an input. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
Ian Jackson writes ("Re: Bug#844125: dgit: Built-in support for pbuilder [and 1
more messages]"):
> 1. I think many pbuilder users expect to be able to set a build
> products directory. Currently there are bugs in dgit's
> --build-products-dir option; probably, too many hardcoded "../"
> (which should be fairly easy to fix, but rather whack-a-mole-ish).
I had a thought about this whack-a-mole game. We could change the
test suite to (unless specified otherwise by the specific test) set a
build-products-dir. And have a check sat the end that the toplevel
test tmp has not been polluted.
I may implement this if it would be useful, but I think I need to know
what the interaction between build-products-dir and .origs ought to be
like:
> 2. I am not sure where origs should go when --build-products-dir is
> being used. Is it pbuilder practice to put them in the build produts
> dir or in .. ? If they go in build-products-dir then we need to do
> something extra in dgit, because many dgit operations - not limited to
> build operations - either consume or produce origs; and then, we would
> want a config setting. Or maybe dgit should always do what pbuilder
> does and the build-products-dir should be precisely that setting.
> (Either way, that's more whack-a-mole removing "../".)
Ian.
Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]
Sean Whitton writes ("Bug#844125: dgit: Built-in support for pbuilder"):
> I'm thinking of working on this. I think it will be straightforward.
Cool.
> The only possibility for complexity is if I've missed something about
> how pbuilder works. Would the following work:
>
> 1. user runs `dgit pbuilder `
> 2. dgit builds a source package and _source.changes in its own way
> 3. dgit invokes `pbuilder build foo_1.2.3-1.dsc `
> 4. dgit invokes mergechanges to merge its _source.changes and the binary
>.changes produced by pbuilder.
FWIW I think this sounds like a good plan. But:
1. I think many pbuilder users expect to be able to set a build
products directory. Currently there are bugs in dgit's
--build-products-dir option; probably, too many hardcoded "../"
(which should be fairly easy to fix, but rather whack-a-mole-ish).
2. I am not sure where origs should go when --build-products-dir is
being used. Is it pbuilder practice to put them in the build produts
dir or in .. ? If they go in build-products-dir then we need to do
something extra in dgit, because many dgit operations - not limited to
build operations - either consume or produce origs; and then, we would
want a config setting. Or maybe dgit should always do what pbuilder
does and the build-products-dir should be precisely that setting.
(Either way, that's more whack-a-mole removing "../".)
Related bugs;
#857316 dgit: please make --build-products-dir configurable
#863582 --build-products-dir has inconsistent behaviour
3. For reasons that I don't clearly remember, but which seem to have
been related to --build-products-dir, I think I decided that proper
dgit pbuilder support would invovle dgit examining your pbuilder
configuration.
#848816 dgit: detect gbp export-dir configuration, and prefill
build-products-dir
Sean Whitton writes ("Bug#844125: dgit: Built-in support for pbuilder"):
> On IRC, Mattia reports a slight wrinkle here: the .changes produced by
> pbuilder will include a rebuilt .dsc. So we need to pass
> `--debbuildopts -b` to pbuilder.
Right.
> Note that the changes will include arch-indep and arch binaries by
> default. This differs from sbuild, which requires you to pass -A to get
> arch-indep binaries. I think it is fine for `dgit pbuilder` to include
> arch-indep binaries, because that is the pbuilder default.
Absolutely. The same is true for `dgit build' (which simply invokes
dpkg-buildpackage).
Also, one more related bug:
#863591 Mention --build-products-dir in dgit-maint-gbp(7)
I have the start of a branch to do some of this. But there's hardly
anything there and it's from late 2016 so it's probably useless. In
case it is any use I have pushed to my chiark branch
wip.pbuilder-config (base was base.pbuilder-config and I haven't
rebased it onto recent code).
Regards,
Ian.
--
Ian JacksonThese 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.
