#1140384#5
Date:
2026-06-19 12:31:00 UTC
From:
To:
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";

#1140384#12
Date:
2026-06-24 07:26:54 UTC
From:
To:
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

#1140384#19
Date:
2026-06-24 08:45:18 UTC
From:
To:
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

#1140384#24
Date:
2026-06-29 09:00:02 UTC
From:
To:
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