Your message dated Mon, 29 Jun 2026 11:00:02 +0200
with message-id <[email protected]>
and subject line Re: Bug#1140384: transition: ldc
has caused the Debian Bug report #1140384,
regarding transition: ldc
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1140384: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140384
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: [email protected]
Control: affects -1 + src:ldc
User: [email protected]
Usertags: transition
ldc 1.42 was uploaded to unstable with a soname bump of the shared
D runtime (libphobos2-ldc-shared111 -> libphobos2-ldc-shared112).
It would be good to set up an auto transition tracker at
https://release.debian.org/transitions/ to keep track,
as is not possible fix all with a single binnmu.
There are 8 source packages whose binaries link the shared D runtime
and need to be rebuilt. I did a quick test rebuild of all of them in a
clean sid chroot.
These 4 rebuild cleanly against ldc 1.42 and can be binNMU'd directly
(verified: the resulting binaries depend on libphobos2-ldc-shared112):
diet-ng
mir-core
mustache-d
sambamba
Can you please do a binnmu of them?
The other 4 are not ready for a plain binNMU:
gir-to-d
FTBFS with ldc 1.42. Its associative-array usage with an inout
value type (source/gtd/LinkedHasMap.d) is rejected by the new
templated AA implementation (core.internal.newaa):
Error: variable
core.internal.newaa.Entry!(string, inout(Node)*).Entry.value
- only parameters or stack-based variables can be `inout`
A source fix is required. This blocks the whole gtkD chain below.
glib-d, gtk-d
Build-depend on gir-to-d, so they cannot be test-rebuilt until
gir-to-d is fixed and rebuilt (libphobos2-ldc-shared112 Conflicts
libphobos2-ldc-shared111, so the old gir-to-d binary is not
co-installable with the new toolchain). They need to be rebuilt
after gir-to-d; whether they also need source changes is still TBD.
tilix
Build-depends on libgtkd-3-dev / libvted-3-dev (from gtk-d), so it
can only be rebuilt after gtk-d.
Ben file:
title = "ldc";
is_affected = .depends ~ "libphobos2-ldc-shared111" | .depends ~
"libphobos2-ldc-shared112";
is_good = .depends ~ "libphobos2-ldc-shared112";
is_bad = .depends ~ "libphobos2-ldc-shared111";
--- End Message ---
--- Begin Message ---
On 24/06/2026 10:45, Fabio Fantoni wrote:
Il 24/06/2026 09:26, Emilio Pozuelo Monfort ha scritto:
These 4 rebuild cleanly against ldc 1.42 and can be binNMU'd directly
(verified: the resulting binaries depend on libphobos2-ldc-shared112):
diet-ng
mir-core
mustache-d
sambamba
Can you please do a binnmu of them?
Scheduled.
The other 4 are not ready for a plain binNMU:
gir-to-d
FTBFS with ldc 1.42. Its associative-array usage with an inout
value type (source/gtd/LinkedHasMap.d) is rejected by the new
templated AA implementation (core.internal.newaa):
Error: variable
core.internal.newaa.Entry!(string, inout(Node)*).Entry.value
- only parameters or stack-based variables can be `inout`
A source fix is required. This blocks the whole gtkD chain below.
glib-d, gtk-d
Build-depend on gir-to-d, so they cannot be test-rebuilt until
gir-to-d is fixed and rebuilt (libphobos2-ldc-shared112 Conflicts
libphobos2-ldc-shared111, so the old gir-to-d binary is not
co-installable with the new toolchain). They need to be rebuilt
after gir-to-d; whether they also need source changes is still TBD.
tilix
Build-depends on libgtkd-3-dev / libvted-3-dev (from gtk-d), so it
can only be rebuilt after gtk-d.
Note that ldc is not migrating to testing due to #1122608, which I
have downgraded (although it'd be nice if it was fixed). Additionally,
ldc has reproducibility issues, which prevent migration to testing,
see [1].
Thanks, fail to build is solved (workaround) forcing LLVM 19, I updated
to new upstream version of ldc but still don't support 21.
I saw also about reproducibility but is not simply to solve. From what
I've found trying to force fix it would take a long time, maybe not so
much if try with LLM but in any case they seem to me to be too
significant changes to maintain in Debian in addition to the fact that
they seem to me to be delicate things that could cause significant
regressions for reproducibility which seems unimportant in comparison.
Maybe file a bug against ldc and tag it help. Anyway since the package is not in
testing, there's little for us to do anymore, so I'm closing this.
And since there's no 'regression' here, I have added a hint to ignore the
reproducibility this time, but note that the next version that needs a SONAME
bump will hit this issue at least for the library package.
Cheers,
Emilio
--- End Message ---
