Thanks for the review, Nadzeya.
The idea behind checking `gfortran-15` in the fallback was to protect
minimal environments where only the versioned package might be
installed, but I agree that adding version 15 into the generic table is
unnecessary. I've simplified it to `_detect_default_compiler("gfortran",
"gfortran-16")` as suggested.
Re-tested on stonking: the test suite passes and `FC_DEFAULT=gfortran`
resolves cleanly to `gfortran-15` via the active symlink.
Also, thanks for the note on the SRU template - applied it out of habit
from recent stable backports. Cleaned up the bug description to remove
it. I've also followed up on Debian bug #1146496 to link it with
#1149705.
Attached updated debdiff `dh-fortran_0.85ubuntu2.debdiff`.
** Description changed:
- [ Impact ]
- When FC_DEFAULT=gfortran is set, dh-fortran looks for gfortran-16 instead of
the installed default compiler. gfortran-16 does not exist in stonking (default
is 15), causing packages like fortran-assert to FTBFS.
-
- The 0.85ubuntu1 fix (LP: #2166191) only touched get_fc_flavor_arch().
- get_fc_default() checks os.environ["FC_DEFAULT"] before that and calls
- canon(), which still returns default_compilers["gfortran"] =
- "gfortran-16".
-
- [ Fix ]
- Resolve the symlink for default_compilers["gfortran"] and in canon() using
which("gfortran"). Strip architecture triplets from the target binary name so
it matches the compiler table key. Add a test in dhfortran/tests/compilers.py
for FC_DEFAULT=gfortran.
-
- [ Test Plan ]
- 1. Run pytest dhfortran/tests/compilers.py (all 4 tests pass).
- 2. Run FC_DEFAULT=gfortran dh_fortran get_env --fc gfortran and check that
FC=gfortran-15 is returned.
- 3. Run debian/tests/debhelper-interaction (exits 0).
-
- [ Where problems could occur ]
- If /usr/bin/gfortran points to a binary with an unexpected name format or a
broken link, it falls back to gfortran-15 (or gfortran-16).
-
- [ Other Info ]
- Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149705
- Target: stonking
-
- --- [ Original Report ]
-
The fix for LP: #2166191 in dh-fortran 0.85ubuntu1 ("Resolve 'gfortran'
via its symlink instead of the hardcoded gfortran-16") is incomplete.
Packages that set FC_DEFAULT=gfortran still get gfortran-16, which is
not installed in stonking (the default gfortran there is 15).
Example: fortran-assert 3.1.2-1 fails to build on all architectures. The
2026-09-24 amd64 retry ran with dh-fortran 0.85ubuntu1 installed:
https://launchpad.net/ubuntu/+source/fortran-assert/3.1.2-1/+build/33466705
dh_fortran_build gfortran-16
Error: Compiler gfortran-16 not on PATH; is it installed?
FAIL: dh_fortran_build : error Command '['dh_fortran', 'get_env', '--fc',
'gfortran-16']' returned non-zero exit status 2.
The build has gfortran 4:15.2.0-5ubuntu1 and gfortran-15 installed, and
no gfortran-16. fortran-assert's debian/rules has:
export FC_DEFAULT=gfortran
== Cause ==
The 0.85ubuntu1 change fixed get_fc_flavor_arch() in
dhfortran/compilers.py, which now tries which("gfortran") and resolves
the symlink. But get_fc_default() checks the environment first and
returns before reaching that code:
def get_fc_default(fc=None) -> str:
def canon(f):
return default_compilers[f] if f in default_compilers else f
if "FC_DEFAULT" in os.environ:
return canon(os.environ["FC_DEFAULT"])
...
canon() still maps "gfortran" to the hardcoded
default_compilers["gfortran"] = "gfortran-16". So any package that sets
FC_DEFAULT=gfortran bypasses the fix.
- == Suggested fix (untested) ==
+ == Fix ==
- Make canon() resolve the symlink first, the same way
- get_fc_flavor_arch() does, and only use the table as a fallback:
+ Resolve the symlink for default_compilers["gfortran"] and in canon()
+ using which("gfortran") via _detect_default_compiler(). Strip
+ architecture triplets from the target binary name so it matches the
+ compiler table key. Add a test in dhfortran/tests/compilers.py for
+ FC_DEFAULT=gfortran.
- def canon(f):
- if f in default_compilers:
- p = which(f)
- if p is not None:
- return Path(p).resolve().name
- return default_compilers[f]
- return f
-
- Other places that use default_compilers["gfortran"] directly (e.g. the
- flavor defaults around compilers.py lines 359-385, and get_f77()) may
- need the same treatment.
-
- == Note for fortran-assert ==
-
- Fixing this alone will not make fortran-assert build. Its fpm.toml uses
- "[library] type = ['shared', 'static']", which needs fpm >= 0.13.0.
- Ubuntu still has fortran-fpm 0.12.0-5ubuntu1:
-
- <ERROR>*cmd_build* Package error: Key type is not allowed in library
-
- Debian has fortran-fpm 0.13.0-6. Ubuntu is stuck on 0.12 because of the
- 0.12.0-5ubuntu1 delta ("Drop build-dependencies for bootstrapping"),
- which blocks auto-sync. That needs a separate merge or sync.
+ Debian bugs:
+ - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146496
+ - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149705
** Patch added: "dh-fortran 0.85ubuntu2 debdiff for stonking (v2, generic
fallback)"
https://bugs.launchpad.net/ubuntu/+source/dh-fortran/+bug/2169224/+attachment/6005995/+files/dh-fortran_0.85ubuntu2.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2169224
Title:
dh-fortran: FC_DEFAULT=gfortran still resolves to gfortran-16
(incomplete fix for LP: #2166191)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dh-fortran/+bug/2169224/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
