Bug#998903: src:libidn: fails to migrate to testing for too long
Hi Simon, On 11-11-2021 22:52, Simon Josefsson wrote: James, let us drop building jxmpp-stringprep-libidn for now and drop dependency on libidn11-java. Sounds great, please upload to unstable -- let me know if eventually there is demand for libidn11-java, otherwise let's hope it can finally be removed as cruft. Pending the removal, I'll ensure again that libidn migrates if all else remains OK the moment I tend to it (which should be real soon). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#998903: src:libidn: fails to migrate to testing for too long
On 11/10/21 16:25, Simon Josefsson wrote: James Valleroy via "Discussion list for GNU Internationalized Domain Name library (Libidn)" writes: On 11/10/21 6:40 AM, Simon Josefsson wrote: James, what do you think? Is the libidn11-java package important for you to have in Debian? My perception was that nobody really used it, and IDNA2003/StringPrep is old technology so it feels strange that new code is coming around using. While I am also upstream of this Java code, I'm not familiar with how Java stuff is packaged/used in Debian, and maybe there is another way of doing things that is just as easy for you. Hello, (Adding Sunil who did most of the packaging work for libjxmpp-java.) libjxmpp-java was packaged as a dependency of jitsi-videobridge. Specifically for Jitsi we need the -core, -jid, and -util-cache modules. It looks like libidn is only used for jxmpp-stringprep-libidn module. Possibly we can disable building this module. Is it not used by anything else? If so, I agree it makes sense to disable it, unless you think it is useful elsewhere. I could add libidn11-java back if there is real usage of it, but if it is not needed for anything particular right now, I would prefer if you disable it until there is real interest in using it. When/if that occurs, we can always add libidn11-java and jxmpp-stringprep-libidn back again. Hopefully, XMPP will be updated to use something newer than StringPrep meanwhile. Simon, thank you for offering to build the library again if needed. My understanding was that one of the three stringprep implementations is needed to use the jxmpp library. They are based on libidn, icu4j and rocksxmppprecis. Of these, we have only built the stringprep library based on libidn and assumed it to be critical. However, I dug up a bit more in jitsi-xmpp-extenstions and other jitsi-videobridge code. To use the jxmpp-stringprep-libidn library one needs to import the class and call setup() on it. This does seem to be happening anywhere as far as I can tell. In this case, the jxmpp library seems to use a fallback implementation. It appears we can drop building the library jxmpp-stringprep-libidn although I can't say for sure without going through jitsi and all of its dependencies more thoroughly. When we progress more on the packaging effort we might know better and can then request libidn to build libidn11-java again. James, let us drop building jxmpp-stringprep-libidn for now and drop dependency on libidn11-java. Thanks, -- Sunil
Bug#998903: src:libidn: fails to migrate to testing for too long
Source: libidn Version: 1.38-3 Severity: serious Control: close -1 1.38-4 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 998901 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:libidn has been trying to migrate for 62 days [2]. Hence, I am filing this bug. The problem is that arch:all cruft is not automatically cleaned up, but in this case, the dropped binary also had a reverse dependency (just filed a bug about that), so I don't know if the cruft binary should just be removed (with the new source package that added the binary that depends on it). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=libidn OpenPGP_signature Description: OpenPGP digital signature
