- Package:
- release.debian.org
- Source:
- release.debian.org
- Submitter:
- Fabio Fantoni
- Date:
- 2026-06-29 09:03:02 UTC
- Severity:
- normal
- Tags:
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";
Control: tags -1 confirmed The auto tracker is not created because ldc is not present in testing. Scheduled. 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]. Cheers, Emilio [1] https://tracker.debian.org/pkg/ldc
Il 24/06/2026 09:26, Emilio Pozuelo Monfort ha scritto: 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. About gir-to-d I solved the RC bug 4 days ago [1] but for now the DD of the team didn't reply. I also found that new ldc add a lintian error on any Dlang package generate with it, is not blocking and I solved in git [2] 4 days ago but still not reviewed by DD. Unfortunately, Dlang is used by few software and developer and packages is supported by few DD that seems busy also in other things, but there are useful programs built with it, so it's good to have at least the compilation tools in Debian. I also wanted to add btdu, for which there's no similar program in other languages, but unfortunately I don't have enough time to package the other dependencies. For now, I've already invested about ten hours for maintain at least the main packages in Debian. [1] https://salsa.debian.org/d-team/gir-to-d/-/commits/debian/latest?ref_type=HEADS [2] https://salsa.debian.org/d-team/ldc/-/commits/debian/master?ref_type=HEADS
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