On 2022-01-07 22:46 +0100, Andrea Pappacoda wrote:

I am looking for a sponsor for my package "mbedtls":

* Package name : mbedtls
Version : 2.28.0-0.1

Thanks for doing that. I'm happy to upload it in principle (subject to
a look over the details).

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?

Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmHY7moACgkQ+4YyUahv nkd1ZhAAqMAZYr1idPPH6t3pd4fwk3lUyonAQ6vbq3QwyvNploeVjvVWcwesjRJi xtBewMWkfen7lPbqsKalEravYMXdROkPp/MwBSPihtUnuhcGIPfnsblvgcc6yIMw 9qJRY/wNuYrI/aIjyjd/P5miz79eji4lA2ipmfRoJw/tQgIojF4e1+/pX4HKeFY2 cMjKm5TV4xFKY6HmbSF4nXAn5cA3n201k/bpHQJyvdoVW6FGaUCe+BdeLfn5hv4a 91LLo7R7xFozsljU4TYdhpAM3Nto/ISMe7J5wdZFFNofu4CsdQwT3c4TgvOanX9V xIgmesNpJrGCXHIt4NzjHm/CHBRrWVZMP8qmBrkmk3T3vNOcft9WLhuphKx/3VPV 2KYzL4KjmiqO6H40ptdaXK9TxON99udgjOpcM515loLJnMAMaL0UuFXYFcVBXWpe RApJYx0c9cg+NseHtKTX24P5OVA+F+bziXMhmxuM+kYSP0jO2dh/4KqVGMRwvzfr 1piTpUu4D6qI0EzguXOXoHJbZFJRLNrp7pgTk/SjaRV7wepFymGSo6pZJiC2kWVZ 0HXCbXeR2SkcyY8UA5AwcVWb/CxVlrOA7Bc/YkqDrTmuhhO64mEFasqHy5jUHWCG 9AbglO3W2u/mStXUBtx6iy0nxldyxcfbiEBbP0jTwa4QhB5Airs=
=V6Xs
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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. Also, this is the same
approach that the original maintainer adopted, and until the package
gets officially orphaned I'd like to do things similarly, so that if he
comes back he'll find the package more or less how he left it.

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, a thing that many users really appreciate (correct me
if I'm wrong, but I believe that using Apache-2.0 libraries in GPL
software is not allowed).

Packaging LTS versions has the downside of only having "old" versions
of the library available, without all the cool features of the newest
releases, but I believe that Debian is not about this, right? :)

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...

Thanks for your interest, have a nice day :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2022-01-08 at 16:54 +0100, Andrea Pappacoda wrote:

(correct me if I'm wrong, but I believe that using Apache-2.0 libraries in GPL
software is not allowed).

It depends on the version of the GPL at play. If it's GPL 3.0 (or
later), then Apache 2.0 is usually regarded as fully compatible with it,
so that they may be combined in the same work.

However, the Apache 2.0 license is generally regarded as incompatible
with GPL < 3.0. This is due to Apache 2.0 having a patent clause,
meanwhile the GPL before 3.0 doesn't have one.

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, a thing that many users really appreciate

Indeed, sticking to LTS releases may be quite important for this reason
if there's any GPL-2.0-only software in Debian utilizing mbed TLS.



-----BEGIN PGP SIGNATURE-----

iIgEABYIADAWIQT287WtmxUhmhucNnhyvHFIwKstpwUCYdnMGRIcanNjb3R0QHBv c3Rlby5uZXQACgkQcrxxSMCrLafk8gEAzPbgJLIh1cR3OrLiuXHZZRE4xX/MTDw6 L5+a2CJ+mGwA/jiNf+mpVBatxzlGxr8x1W0aDWsfo7q+6H1QmUXCsIcL
=v1vz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmHaGS4ACgkQ+4YyUahv nkerjA//WLo8jtc5ytjvdHVtkWuNH6YKdljvFAXK8TEo9Tdnptnq/UizqWVSgKE7 pASGedh3WxDViZzikQEcecAx4r4ddx/gkT5p2yJ5hKrOHJm1QLraAblAhWwEOO71 7T5x2qn8ughoJUkA/atVs3dw0W2CKNhw5oCOtfn2dDDpUSGfHhuYSmPck7moDZK7 yncuWRsAhgiiaVfOFhIS7BVJ7kiPxuPGc/rZpEuSfuuL3eNg74FlfYfOMFE5Y8fT 1VJ3uYBgUSyDDzOuLXgsPfts9DCnsuC64cyTDWRyk28ftCWQXmVv3Kd/FMr7qWmM CH49vjQWhzvo4IJQC5iEla6WBmMki4m1bExTEUXDI4cX6Q/Qv7fvotXQk9bscLos khJG6+RY5S89ZD/CpZ6sEfHz7A1k33U/X8f2CdReM27mFaQJqskSsp4W+4GWQrN1 o+zFrHsgjc9+8B5roPupZyrfVetc9dKy8QdvkLaJmTUJ56IvIlAksYa0R2VybxV8 pn/NOQMFyjhAYgV+QbcCX5SX4kcqmPsVt5totIwDqIBOQgo5gIqaDwvv5tFvf2Su MnnjrghmtTOdQ1thhmPpN46p2w5D4fPdg++zZGHljUnCzqHDIlRgbS4FZAD96Zqr 3ggtR3rWPZ/jZv8Pad4mm43iWXnL7dHVpF0QmmG1CDiGhP7B0cE=
=oAdm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno sab 8 gen 2022 alle 23:07:32 +0000, Wookey
<wookey@wookware.org> ha scritto:

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?)

I honestly have no idea, but better safe than sorry.

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.

If you're interested in helping out that's always welcome, but feel
free to do as you wish (I don't desperately need help at the moment)

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

I believe I encountered this failures once, on my desktop pc, but then continued working on the package on my old laptop, that has a dual core
Celeron from 2013 clocked at 1.9 Ghz, and never saw them again. I
thought it was because of something wrong on my pc, but it doesn't seem
the case anymore. One thing my pc and yours have in common that my
laptop hasn't is the high number of cores / CPU power; maybe it is some
thread race of some sort?

We should probably take it off debian-mentors at this point to
discuss the boring details

Ops, guess we'll do it in another message :)

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 took inspiration from the nginx packaging, as they do the same thing.
I find watch to be useful to look up updates useful to packaging, and I
want to be notified only when I actually need to do something. I know
that newer non-LTS versions are available (as 3.0 was released before
2.28), but why should my d/watch care? Also, if I only track releases
that I actually have to package I can simply run `uscan` to update my
package source, without having to manually tell it that the release
that I'm interested in is not the latest but some other release. Yep,
personal preferences, but I think it makes sense.

As for using the GitHub API, I prefer using it because it has a well
defined, stable interface that can't unexpectedly change (as opposed to GitHub's web UI that already broke some of my d/watch files once...). I
also find it easier to understand, because with `searchmode=plain` I
know that uscan is going to look for a simple plain text string instead
of having to magically parse an HTML page to find related `a` tags, and
I can always look up GitHub's documentation to see exactly what my HTTP
query will return. And also because I'm not a regexp wizard and using
the API allows me to use less of them :)


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)