Re: Bug#1003306: RFS: mbedtls/2.28.0-0.1 [NMU] -- lightweight crypto and SSL/TLS library
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 :)
Reply to: