On Sat, Feb 21, 2026 at 09:57:44PM +0000, Ian Jackson wrote:
Russ Allbery writes ("Re: Bug#1128520: please implement
dgit.default.tarball-dir"):
Oh! I think I see my confusion: I thought this didn't work but it actually
does. If build-products-dir is set, dgit does use that directory as an
*input* as well as an *output* get the orig.tar.gz file from that
directory.
Yes.
This is not the semantics of git-buildpackage as I recall (it's
been a few years), but it sort of makes sense.
I set dgit.default.build-products-dir to ../bpd soon after I
implemented the feature (after someone else's request) and haven't
looked back.
Sadly git-deborig and origtargz don't use it.
Are there bug reports requesting that?
The logging is a little weird in a way that makes that somewhat inobvious:
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building libnet-ldapapi-perl using existing
./libnet-ldapapi-perl_3.0.7.orig.tar.gz
I assume this is because dgit has already changed working directories to
the build-products-dir. But I guess I never actually tried it; sorry about
that!
In fact dgit is running dpkg-source in a secret hidden working area it
creates inside your .git directory. I don't think there is any way to
improve this output from dpkg-source.
"Changing work directory to ..."
I don't really care (I can just run origtargz to get the tarball again in
places where I use pristine-tar), so now that I know build-products-dir
works, I'm mostly happy. The missing piece is telling origtargz to always
use that directory as well, but that's not a dgit problem.
The difficult part isn't teaching origtargz to do it. The difficult
part is deciding on a common location where tools like this get their
information.
origtargz is in devscripts which doesn't really have a common
configuration scheme and I doubt trying to institute one there would
be either a good idea, or fun.
#include <zugschlus-default-rant-about-no-technical-leadership-in-debian.md>
I think it's a shame that gbp doesn't read git-buildpackage.whatever
things from git config.
Somebody should write a tool to generate .gbp.conf from git config.
Maybe we should invent a debian.* namespace for git config options
Sounds good to me.
Marc Haber writes ("Re: Bug#1128520: please implement
dgit.default.tarball-dir"):
Sadly, at the moment I don't remember which other software insists
on the tarball being in ..
We could institute a Debian-wide default for orig tarballs by putting
it in devscripts and making the tools there honour it. It would want
some negotiation with the gbp maintainers but it doesn't seem
impossible.
That's what I would try to do (in the scope of my limited
possibilities). Having dgit walk ahead would make that considerably
easier.
ยน I'd love to have export-dir templatable (for example, writing build
artifacts to ../build-area-<package>-<version>-<arch>), but gbp upstream
was not excited about that.
I think we should prioritise getting all these different programs to
agree and if that means the functionality is more restricted then
that's better.
Yes.
Personally I wouldn't object to such a scheme in principle but I am
already foreseeing difficulties with it: for example, dgit
doesn't always *know* what the architecture is.
I'd basically go with the distinction between "source" and "not source"
builds. It's a pain that doing a binary buildpackage (for example, to
run Lintian) over an already built source package will render the source
package unuploadable since the .dsc gets overwritten.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
