Source: golang-defaults
Version: 2:1.14~1
Tags: patch
User: debian-cross@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:canid src:go-qrcode src:golang-bindata src:golang-github-benbjohnson-tmpl src:golang-github-calmh-xdr src:golang-github-eknkc-amber src:golang-github-odeke-em-cli-spinner src:golang-github-odeke-em-ripper src:golang-github-rakyll-statik src:golang-gogoprotobuf
relatively obvious and uncontroversial to me.

In my draft, I argued that for supporting cross compilation with
golang-any, one must ensure that the triplet-prefixed go is called in
order to support gccgo. But then, the golang go will also have to
provide a triplet-prefixed go to provide a shared interface.

For that reason, I'm attaching a patch that adds these go wrappers to
golang-defaults. It adds new binary packages golang-go-<triplet> and a
package golang-go-for-host.

A few remarks about the patch:
 * It adds new binary packages. Uploading golang-defaults with the patch
   will make it stuck in NEW.
 * debian/control becomes a generated file. The generator is
   debian/control.sh.
 * It fixes a typo in debian/control where one "mips64el" was misspelled
   as "mips64".

This is not a full solution to cross compiling go packages. Like my
previous patches, it is to be considered an incremental step.

Once this is in place, I suggest that we can reduce complexity in
dh-golang. Instead of setting up the magic variables there, we can now
call into the cross wrapper.

Helmut

Wow, nice work!

I'm curious though, is there a technical reason we need so many extra
binary packages, especially when each binary package amounts to
essentially a single very short shell script?  Couldn't we instead
package them all together into one binary package, something like
"golang-go-multiarch-wrappers" ?

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Hi,

We could try fusing the golang-go-<triplet> either into
golang-go-for-host or into a shared golang-go-multiarch-wrappers.  If we
try the former, golang-go-for-host would have to depend on a native
golang-go. My patch expresses that by going via arch:all m-a:foreign
packages. The golang-go-for-host -> golang-go-<triplet> dependency
looses its architecture constraint due to Multi-Arch: foreign. If
golang-go-for-host were to depend on golang-go directly, we'd have to
make it Multi-Arch: foreign or we'd have to make it Multi-Arch: allowed
and annotate the dependency with :any. The outcome of that isn't
obvious.

So the other way would be golang-go-multiarch-wrappers. Unlike with gcc,
this is actually feasible, because we know the available targets ahead
of time. We cannot retroactively add architectures without rebuilding
all of go. So that actually works. It just didn't occur to me any
earlier. I'd prefer to have this package provide all the
golang-go-<triplet> instances as virtual packages though.

Another issue with fusing into golang-go-for-host (but not the other
way) is that it requires adding the relevant target architecture using
dpkg --add-architecture.

A weak argument is consistency with gccgo. This is precisely the layout
that gccgo uses (except that gccgo uses Arch:any packages instead of
Arch:all). Keeping this layout as virtual packages seems sensible
though.

So yeah, I think it's actually possible to fuse them into a
golang-go-multiarch-wrappers package. Let me propose a different name
though: golang-go-for-build. That way it'd precisely mirrors what we do
for binutils already and what we will be doing for the gcc frontends.

Here you go. Thank you for the valuable question.

Helmut

Looking at this again, and I'm kind of concerned by how similar this
new script is to
https://salsa.debian.org/go-team/compiler/golang/-/blob/0b1574525525719281c84cfa55ec7ca7719be8d9/debian/helpers/goenv.sh
which we already maintain in the compiler packages -- I bet there's
some way we could make either the new script work for the
bootstrapping use case or better would be the other way around?  That
raises the question of which source package the script should live in.
🤔

I think it would be pretty reasonable/easy to split that script into
"things we need to set for bootstrapping" and "things we need to set
for cross-building with Go", especially given I just removed a bunch
of bootstrap-specific logic from it in my latest touching of it (while
making src:golang-X.Y itself cross-buildable).

Maybe it does make sense to have a variant of that script that lives
in every src:golang-X.Y?  I don't know, because there's very little in
it right now that's specific to a particular version of Go (although
it *has* had to have complicated logic that in the past, like when the
value for GO386 had to change, and getting it right across the
bootstrapping boundary was extra complicated).

Personally, I'm not very convinced by any gccgo compatibility,
especially since I don't think gccgo has kept/reasonably can keep up
with modern Go versions very well (and in the meantime, Go has gotten
better at officially supporting all the architectures we might care
about for which we used to lean on gccgo).  As evidence, gcc-15
appears to still contain Go 1.18 (since gcc-12, in fact), but also
apparently doesn't support generics so it's not really quite 1.18. 😬
I think it's probably not even enough to be a sufficient bootstrapper
for Go itself anymore, but I haven't checked that recently.

I also need to admit that I don't actually understand the need for so
many explicit package names -- is there some existing convention that
will automatically install the correct package based on existing
Build-Depends or something that warrants all this extra complexity?

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Hi Tianon,

There is another angle here. The proposed wrappers need to work without
using DEB_HOST_* environment variables as those are Debian-isms, but the
wrappers are supposed to be outside package building.

Effectively, we may avoid a dependency on dpkg-architecture at runtime
by calling it at build time and recording the output. So instead of
having one goenv.sh for all architectures, the script could be
interpolated per architecture and included in an Arch:any package. The
existing goenv.sh entry point may be kept for compatibility and may then
forward to the appropriately interpolated script selecting it via its
DEB_HOST_GNU_TYPE. So it's shuffling things around rather than
increasing maintenance cost.

But then when I talked to Mathias Gibbens in Brest, we basically agreed
that compatibility with gccgo was a minor concern given that it is
horribly outdated and that we might forget about those wrappers and have
dh-golang handle the environment setup. Then turn things upside down and
turn gccgo into a wrapper that reverses the process and turns
GOARCH/GOOS/GO386/GOARM back into a GNU triplet to call the right gccgo
executable when such a need arises (if ever).

That gets us back to the question of where that script should live.
Basically any go package (including the compiler itself), would have to
transitively build-depend on this, so building this script should not
require a go compiler (to avoid a cycle). golang-defaults might be a
good fit here even though adding a binary package just for shipping a
script may feel odd.

That is a good alternative to golang-defaults, because it avoids the
aforementioned cycle and the duplication is limited to a few versions
all maintained by the same people (making it feasible to keep the copies
in sync).

Seems like that's a consensus item then.
toolchain dependency translation". Given a compiler supporting the
convention (e.g. gcc or gfortran), you may annotate your Build-Depends
as either COMPILER-for-build or COMPILER-for-host (both lacking :native
and :any). In the latter case, you are expected to prefix all compiler
invocations (even when building natively) with the GNU triplet (e.g.
x86_64-linux-gnu-gcc) and then you get object files for the explicitly
selected architecture. In the former case, you are expected to call the
compiler without a prefix and then you get object files for some
architecture that your CPU can actually execute without emulation. This
typically is the architecture of the dpkg package, but it may change
e.g. when cross grading.

The big question now becomes what the Multi-Arch field of golang-VER-go
should be. It presently is implicitly "no", but that means that you
cannot depend on a runnable go compiler. Keep in mind that :native is
not applicable to Depends. We may argue that it should be Multi-Arch:
foreign. Doing is a quite lax interpretation of the proposed policy
text, because it effectively means that invoking the go compiler without
exporting GOARCH/GOOS and so on would not be a supported interface, but
that's what is happening a lot presently. On the flip side, I see little
use cases for actually requiring the Go compiler executable to have a
particular architecture. Possibly, some packages cannot work with CGO,
which is practically required for any kind of cross compilation and
there we would want to force the Go compiler executable to be a host
architecture one (thus requiring CPU emulation to run it). If that is a
sensible use case, it should likely be Multi-Arch: allowed, but then we
got to update every single source package changing golang-go to
golang-go:native or golang-go:any (their effect is the same, but the
former is more explicit in Build-Depends).

Do you have an opinion here? I think the main two questions are:
 * Do we want to support selecting a Go compiler executable of a
   particular architecture?
   + If yes, it cannot be M-A:foreign.
 * Do we want to update the Build-Depends of every Go thing to enable
   cross compilation?
   + If no, it must be M-A:foreign.

There is a slightly more complex scheme that may be easier on the
consumer side:
 * Rename golang-VER-go to golang-VER-go-compiler (name TBD).
 * Mark the renamed golang-VER-go-compiler M-A:allowed.
 * Introduce a new, empyt Arch:any M-A:same package using the freed name
   golang-VER-go. It depends on golang-VER-go-compiler:any.
 * Move the golang-1.24-src dependency from golang-VER-go-compiler to
   golang-VER-go.
 * Do a similar thing in golang-defaults for golang-go.

Then the many packages that presently depend on golang-go would get the
native Go compiler. Many of them would cross build, because dh-golang
already exports the right environment variables. Those that really do
need a Go compiler executable for the host architecture (expected to be
rare and incompatible with cross compilation) could additionally depend
on golang-go-compiler (without :any or :native) to express this. This
scheme would thus allow answering the two questions above as yes and no
respectively.

If going that more complex route, we may add the interpolated goenv.sh
to the golang-VER-go package in an architecture-dependent path.

Whether to incur this additional complexity depends on whether we
anticipate any dependencies on a Go compiler executable of a particular
architecture. We may also go for M-A:foreign without the shuffling now
and do the shuffling later if such a need arises practically.

Helmut

We believe that the bug you reported is fixed in the latest version of
gobuster, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 960842@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thiago Andrade Marques <andrade@debian.org> (supplier of updated gobuster package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 04 Jan 2026 22:38:06 -0300
Source: gobuster
Architecture: source
Version: 3.8.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Security Tools <team+pkg-security@tracker.debian.org>
Changed-By: Thiago Andrade Marques <andrade@debian.org>
Closes: 960842
Changes:
 gobuster (3.8.2-1) unstable; urgency=medium
 .
   * New upstream version 3.8.2.
   * Close firejail security integration bug (Closes: #960842).
   * debian/control:
       - Bumped Standards-Version to 4.7.3.
       - Updated 'Description' field.
       - Removed 'Priority' and 'Rules-Requires-Root' fields. These fields are
         now redundant and can be removed.
   * debian/copyright: updated packaging copyright years (Happy New Year!).
   * debian/gobuster.1: Updated manpage.
   * debian/rules: exclude vhs directory from build.
   * debian/watch: updated to version 5.
Checksums-Sha1:
 51d8fd7e162a35bab7607bbddb2962e4d0d14248 2329 gobuster_3.8.2-1.dsc
 c274b87becc9a3585a4bb8a2a5baf8e63265cc60 337375 gobuster_3.8.2.orig.tar.gz
 3e35d76f86e91db7d5fe73d8aa57a9ed4cbf28e6 4664 gobuster_3.8.2-1.debian.tar.xz
 7436623119573027a258aad82cfdbb29974b4e55 7983 gobuster_3.8.2-1_source.buildinfo
Checksums-Sha256:
 64c3a1f546273e815ad094752f9f53330f9ef8e0dbc55bc2935c899902589570 2329 gobuster_3.8.2-1.dsc
 6919232eafbd0c4bbc9664d7f434b6a8d82133aa09f1400341ef6985ceff208a 337375 gobuster_3.8.2.orig.tar.gz
 c2506b6cfc5743f0638fe95c6117a2d42a6c42e39b9998d87131a8050249233d 4664 gobuster_3.8.2-1.debian.tar.xz
 b75c20b055af7c7554161c269219511220e7d8c18f43b497e904dfda70c464aa 7983 gobuster_3.8.2-1_source.buildinfo
Files:
 a2c7874e515b682c2ed5d77f459ae897 2329 utils optional gobuster_3.8.2-1.dsc
 456f3772e47415e1927522bfe32d0388 337375 utils optional gobuster_3.8.2.orig.tar.gz
 c9ff7caedc49988b9dc885717bddbd88 4664 utils optional gobuster_3.8.2-1.debian.tar.xz
 e53dc7a63d7ad2fa20130d503753ac0c 7983 utils optional gobuster_3.8.2-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0QFl3Wbn1VHx/3vxIDym/u8GotMFAmlbG0sACgkQIDym/u8G
otO9EA//cdq2CSn06QZNt8h1x8JBQXMZyJqjs9cG5NluJbrZAo9i83RjhXcyDOqB
FC6KdUbofvitpzgOk1QA+HiqR+DK++/VruYYW7/MruSCE/P+DNW2WD4Z9ZeJ6Xho
JChr1KI+s32a/Faol7qmNuBy+Nu7pLZzdq4jF/7oqU5HtQGhSKLAsbUFSkh4mMIn
4vLzReGs4xfGFJAbA9Is/VNOb29fUZOj/ZGbHEj0+zEk4NJp2aJQEE+p1oyf0++v
7LAKECpMm48hZXpGZP7zfyEqmWhcijSAk8m8N3Ph1cWP/g5D9SHr271+b9PnvU0O
p2XPJK9Ug0Jj0BVd4VW7HkDL4zb1XEUv6FFHMI1xqsktjWYh/4EoEn2NoYaEyWam
GpKZZoB+hzFEzbiTL2qi0QbLpSp0Wi7xlH6T9adqb/dvl2vMZe+dzR919c3XjQqk
3hwkcFjrk+k3OclDz2fcB5RULmkbk8L4AnJrMrJdJAzT02DYApI1N9pF0maTzDD1
V/1LG7oIdiEOTpzTFZst/npDyjAv8FjBASjZBcb9u7obz7hT49/HCl4qXM1p6VeT
RQBT9DLIHeRYvQCED1XzczkYD/sU1Cw0wAUXIyTCY+4tK4mlfqiFNZlQhpkZBxQT
uuXUObwrT8PnPZtzWPeLy2IpBe3Cv5vHtHTZc2EyFWDt0DkdQ5Q=
=x6EM
-----END PGP SIGNATURE-----

Control: reopen -1

The closure message of the bug very much does not match the bug
description. This very likely is a mixed up bug.

Helmut