Hi, Am 31.05.25 um 11:39 schrieb Matthias Klose:
The transition is also discussed in https://bugs.debian.org/1102294
This one didn't discuss xmlsec1? (Contrary to what the title says) I am aware that xmlsec1 in sid might not work with the new libxml2 (wouldn't be surprised at least) and thus we would be forced to update xmlsec1, but...
Note, that I only filed bug reports that I was able to reproduce for Ubuntu, where this transition is almost done (at least migrated). There are still unfixed issues, however these seem to be outside key packages and didn't need initial fixing for starting this transition.
Hmm? libreoffice and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106645 is definitely a key package. And note a 25.8.x libreoffice (if this was fixed there, otherwise we'll simply need to disable affected tests for the time being, the one in the bug is a generic xslx test....) will definitely also needs a mdds/libixion/liborcus transition (which I didn't file yet.)
The auto tracker should be updated, or a new tracker be created: title = "libxml2"; is_affected = .build-depends ~ /libxml2-dev/ | .depends ~ /(^| )(libxml2-16|libxml2)([ ,]|$)/; is_good = .depends ~ /\b(libxml2-16)\b/; is_bad = .depends ~ /(^| )(libxml2)([ ,]|$)/;
This one doesn't include xmlsec1 either? I'd love to have the xmlsec1 transition to get a newer version into it (given upstreams constant ABI breakages without changing the SONAME... (which was worked around with this transition) I am smomewhat wary, as we would soon find in a situation like libxml2 in trixie.) And many of the xmlsec1 r-deps are not ready, as ratt rebuilds show (libreoffice is)... Regards, Rene
