On 2022-01-08 16:54 +0100, Andrea Pappacoda wrote: > > Il giorno sab 8 gen 2022 alle 01:52:47 +0000, Wookey <wookey@wookware.org> > ha scritto: > > However, I have already packaged v3.0.0. It's not been uploaded yet > > because it fails some tests intermittently, and I am in discussion > > with upstream about why this only happens sometimes. That has been > > stalled for a while so maybe I should just upload this 2.28, but it > > might be worth me giving them a prod and us waiting another week or so > > to see if v3.0.0 will happen? > > Hi, thank you for your reply! I have not packaged 3.0.0 myself because it is > not an LTS release, and I believe that packaging an LTS version is > preferable for how Debian releases work. That's a very good point. Although I kind of assume we'll get another LTS release before bookworm so it may not matter that much in practice. I guess we shouldn't rely on there being another LTS release in time (or that it gets packaged) so sticking with 2.28 does make sense. > Also, packaging LTS versions is preferable for licensing issues. MbedTLS is > usually released under the terms of the Apache 2.0 license, while LTS > versions are licensed under the Apache-2.0 OR GPL-2.0-or-later OK. I had not appreciated that the LTS and dev versions have different licencing. I don't see how they can do that in practice. The requirement is to make all contributions under both apache-2 and GPl2-or-later, so surely that always applies to whatever is in the dev repo, whether or not it is officially sanctioned as a dual-licenced LTS release? (maybe they miss some non-GPL bits out of the LTS releases?) > When the MbedTLS developers will release an LTS version of the 3.x branch > I'll be happy to work on it, and we could help each other too - we could > even unofficially co-maintain the MbedTLS package starting from now, as the > original maintainer has not responded to my emails in months... My interest was primarily via work as there have been significant optimisations on the ARM side in recent versions, hence updating what was in bullseye. But I didn't go beyond 2.16 then because there were API changes which would require updates in other packages and that would have been too intrusive at that time. I don't actually use this code, so I'm very happy if you actually want to look after it without me sticking my oar in. But equally I can help out too if you'd prefer to do it that way. I just tested 3.1.0 and it has the same problem as 3.0.0 with test failures. So I'll pester upstream. Hmm. And with your 2.28. That's interesting (maybe it's my sbuild setup?): The following tests FAILED: 79 - psa_crypto_persistent_key-suite (Failed) 82 - psa_crypto_slot_management-suite (Failed) 84 - psa_crypto_storage_format.current-suite (Failed) 85 - psa_crypto_storage_format.v0-suite (Failed) 86 - psa_its-suite (Failed) Errors while running CTest make[2]: *** [Makefile:74: test] Error 8 make[2]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu' dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j12 test ARGS\+=--verbose ARGS\+=-j12 returned exit code 2 We should probably take it off debian-mentors at this point to discuss the boring details Although one item is worth public discussion: You changed the watch file to only look for updates to version 2.28, as opposed to updates in general. So if I run uscan under 2.28 it tells me there are no updates, even though 3.1.0 is available upstream. I'm not sure if that's the right thing to do? Even if we've decided that only LTS releases are going in debian, as a packager I still expect uscan to show me what's available? Not sure if polcy has anything to say about this? (also is it really better to rely on the github API than just downloading files?) I guess we could put sections for both 'this LTS' and 'all versions' into the watch and one could uncomment-as-desired. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature