The new Miniflux package gives me 404s on the frontend. I could tell the
backend is working from logs. I investigated and tried rebuilding,
eventually finding that the switching away from gorilla/mux mentioned at
https://miniflux.app/releases/2.2.19.html changed the way the frontend
routes requests (internal/http/server/routes.go and internal/ui/ui.go).

By finding that the static routes listed in routes.go work (e.g.,
/liveness) I knew that it was likely a routing problem, and I also
noticed ui.go has a static route at /robots.txt that did not work. I
tried moving it to routes.go, and it still didn't work until I removed
the [METHOD ] portion of the pattern (i.e., "GET ").

I looked up to see when that form of routing was added to golang:
https://go.dev/blog/routing-enhancements says 1.22 in 2024. Debian is
using 1.26 in sid, so I don’t know why it's failing with the newer form
of patterns in routing, but I can confirm that when I removed GET from
one of the simpler entries in ui.go, /about, it renders (without CSS,
but that's the price of progress).

That's as far as I got. The documentation says GODEBUG=httpmux121=1
would disable the newer form, but I didn't find anything like that in a
grep of the package source. Hopefully y'all have some idea why it's
breaking despite being a version of golang that supports that style.

Thanks,

Adam

After more digging, I found
https://sources.debian.org/src/openvpn-auth-oauth2/1.27.3-1/cmd/openvpn-auth-oauth2/root.go?hl=1#L1
via code search, which points to
https://github.com/jkroepke/openvpn-auth-oauth2/issues/680#issuecomment-3686988447
explaining that dh-golang currently results in turning the old servemux
code on.

The change there lines up with the fix I'd already found for now:
explicitly adding `//go:debug httpmuxgo121=0` above the package
declaration (in main.go in miniflux's case).

I'll leave it up to y'all if that's sufficient or if there can be some
change at dh-golang to avoid this for other packages?

Thanks,

Adam

Forgot to mention that as miniflux no longer uses gorilla/mux, that
build dependency can be dropped from the control file.

Thanks,

Adam

Hi Adam,
Thanks for the bug report! I didn't notice at all since I hadn't
upgraded my installed miniflux package yet.

I've patched main.go and it looks like it works fine now.

Since this is a runtime flag rather than a build flag, there's not much
that can be done in dh-golang. It's really weird that GO111MODULE=off
causes httpmuxgo121=1, but the only thing that *could* be done in dh-
golang is passing -ldflags="-X 'runtime.godebugDefault=httpmuxgo121=0'"
(which I just found out is a thing), but many Go packages set their own
-ldflags (for passing current version etc) which would override this.

So yeah, the best thing to do is patch main.go.

Thanks,
Maytham

Hello,

Bug #1134839 in miniflux reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/miniflux/-/commit/d63d2acc8dd84f1f9f1a0abce1dce95d3a001e41
------------------------------------------------------------------------
Set httpmuxgo121=0 flag during execution to fix 1.22-style routing

GO111MODULE=off causes httpmuxgo121=1 (for some reason) which breaks Go
1.22-style routing as described in
https://go.dev/blog/routing-enhancements

Closes: #1134839
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1134839

We believe that the bug you reported is fixed in the latest version of
miniflux, 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 1134839@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Maytham Alsudany <maytham@debian.org> (supplier of updated miniflux 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, 26 Apr 2026 10:21:39 +0800
Source: miniflux
Architecture: source
Version: 2.2.19-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
Changed-By: Maytham Alsudany <maytham@debian.org>
Closes: 1134839
Changes:
 miniflux (2.2.19-2) unstable; urgency=medium
 .
   * Update Build-Depends to reflect changes in upstream deps
   * Set httpmuxgo121=0 flag during execution to fix 1.22-style routing
     (Closes: #1134839)
Checksums-Sha1:
 b93f280640601f5521a5cb2c6001ec059c4b7d64 2482 miniflux_2.2.19-2.dsc
 711877525f5f00d7e2e7da0f60901b523857f1bd 7116 miniflux_2.2.19-2.debian.tar.xz
 e3a07175474a2ee2a8de3770a5bd04e4ad68ef6e 14598 miniflux_2.2.19-2_amd64.buildinfo
Checksums-Sha256:
 539effa10c40258f44d208e40140871a0a53aa5142e3ac4ed84277b199612911 2482 miniflux_2.2.19-2.dsc
 e972d8bfac2b5862294b49e62ecbf0123be2cc1b0aa26a08e7fc61fa6552d4e3 7116 miniflux_2.2.19-2.debian.tar.xz
 39924bf4e2fba194f50336768e8ec4ee23addfa87e99300bf79236de1058ebfb 14598 miniflux_2.2.19-2_amd64.buildinfo
Files:
 7a2b6a09bbc5a16414ccd772d6350035 2482 web optional miniflux_2.2.19-2.dsc
 c8387ac4f2c75ea9ed1d7a92517a95f4 7116 web optional miniflux_2.2.19-2.debian.tar.xz
 f8d8151a04110697076ee46603026cd7 14598 web optional miniflux_2.2.19-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEESl/RzRFQh8wD3DXB1ZeJcgbF8H8FAmnteLAACgkQ1ZeJcgbF
8H8c5w//QCgKxLZ2bGzj4XsVeDVlXBedJsKxguks4J4b0KZGoj64iCts/Z5JwS61
Opros3/x0z37gMwq+6vryW31lu9GPvtUX45exi1gLJRvJbsjXWFNI1eZrFntgmqz
LnLh7YczM6yscjJUFbS7KyPfcFdDI8222TgmKqFURbrk0vX6SQ9zIeB6P0Iq6Ktr
bVCXvNgBMe6UJG0QQIX2vL77+S0tUpcVve+Atm7Nz2dyx2HbInkRsNqTUUXU8MhC
wPmo6IugCuirzhy9HBjezdy2O7jdmQat7169RG5uzuR2a9XsbdJ9jsLQYqFVuovY
A0G8ndvQfoLcwwZvOM1YWtisY3drtPF8JTZzY8C1ftfg1lIchsk6yrNt2zZIlJ7X
zzmDcscqrDdPFsioTgbTdQtvupaqXmK6A/FRgsI9gjoMB2g8kDMol2RxylF3rhnE
28la3TxNOJjCzzV/+AygGEHtcvy6aG7g8FY+iZ3DsX8HTWjBcXRjehlebF3zqUBm
fdL9VrUE5soH88QXfGu4eWdl1mcO/mssVTRuwfv51KniDQNTukoFG6ausoW5/xuc
7Ho6+VwVKqbLAGsccnpwaki+/D0+6rCLPoz1/IZY0pJB5GYQ8QG+yQoOhXPb2vMK
36OKKY6IVK8K1wX5THiNiN04PswKZfigPkr/IwwEC2OSEm6RK1Y=
=LSuC
-----END PGP SIGNATURE-----

I'm afraid more and more bugs will come if we are still using old
GOPATH mode to build packages. However dh-golang and the whole Go
ecosystem in Debian are tied to GOPATH. Rewriting them to the Go
module mode is not trivial, which should have happened 7 years ago...

Understood. But you don't need that in testing and backports while
only use that package locally to bootstrap a -cloud package first. And
then build an update -cloud package to newer upstream version that
doesn't depends on it.
I think you can do both locally with your
pbuilder/cowbuilder/sbuild...for bootstrapping packages.
You are allowed to do whatever locally for bootstraping even for cross
building. Just ensure in the end, you rebuild the package cleanly and
tested the clean package with ratt. And then upload package
cleanly(ensure the source package may builds on buildd) as well.

----
To Go Team, Backports Team and Security Team,

This is a reminder that the current Go ecosystem is Debian makes
responding to Security fix in LTS and Backports exceptionally
difficult. I have fixed some CVEs in Sid and Forky recently. I known
how difficutlts are there for fixing the same in backports.

In Debian, we currently builds Go packages with legacy
`GO111MODULE=off` flag creates many issues including security issues
across Trixie, Forky and Sid. (If you don't know why, watch my talk in
mini DebConf Hamburg.) We need re-implementation and re-design how the
Go packages builds in Debian.

I believe we need to address the following key areas:

1. Migrating to Module-Aware Builds
We must stop working acround broken Go binaries and skip/disable tests
caused by the legacy `GO111MODULE=off`, and switch to Module-Aware
Builds.

* The GOPROXY Approach:
  - There is an existing Policy Merge Request on Salsa suggesting use
GOPROXY method but doesn't provide any info how to make it works.
After I checked, a true GOPROXY required upstream .zip files and
go.mod for each module. And we also need to setup a private GOPROXY in
Debian infrastructure for buildd to use which may not be the most
practical path forward.
* The Go Workspace (go.work) Approach:
  - As a Proof of Concept, I tested in bash script that use Go
Workspace(go.work) method to map go.mod requires directly to to local
installed Debian packages paths. This works perfectly when build
dependencies provide proper go.mod files.
  - However, integrate this into dh-golang, would require updating and
around 90% of golang packages in Debian of our exist golang source
packages. (Some packages provided broken or mismatch go.mod file and
some package is out of date that doesn't provide a go.mod file. And
some package has dead or legacy upstream has no go.mod file exist.)

2. Enhance Security Tracking
  - Upstream Go security fixes usually just a single-line version bump
in go.mod file for it's dependencies.
  - Because Debian currently buils Go packages without strictly
tracking these upstream module versions, upstream security advisories
do not accurately reflect the state of our packages in Debian.
  - In practice, many Go packages in Debian behave like un-trackable
upstream forks. A lot of hacks that changed the upstream module
versions to force the package builds with skipped/disabled tests and
untested broken binaries.

3. Transitioning to Binary-Only Shipping (The `icingadb` Model)
  - To resolve the dependency hell that blocks backports and security
responses (such as circlar build-dependencies with -google-cloud/api
packages, deal with build-dependencies not exist in Debian anymore),
we should consider moving forward to a binary-only model in Debian.
  - Use `GO111MODULE=on` method by default.
  - Allow app/binary packages to ship their sepcific upstream security
tested/tracked dependencies.
    This ensures the package can be easily backported to older stable,
oldstable, oldoldstable distributions when we received upstream
security advisories.
  - Get rid of out of date or obsolated Go related -dev packages in
Debian. This would reduce a lot of space in our archive and free up a
lot of maintainer resources.
  - Shift maintainer's focus into the quality of the Go binary/app
packages we ship. No more incompatible competitions between -dev
pacakges amond us, and also eliminating bootstrap and backport
burdens.

To resolve these challenges, we should schedule a dedicate discussion
on the Go Ecosystem. A BoF session at DebConf26 would be an idel place
in my mind. But I welcome any suggestions on how we can kickstart this
transition sooner.

Best regards,
-- 
-Andrew