© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Here's the amd64 build log for lunar:
https:/
In there I see:
Run-time dependency libcryptsetup found: YES 2.5.0
Dependency libcryptsetup found: NO found 2.5.0 but need: '>=2.6.0' (cached)
../src/
Here's the mantic build log:
https:/
There I see:
Run-time dependency libcryptsetup found: YES 2.6.1
Dependency libcryptsetup found: YES 2.6.1 (cached)
Message: cryptsetup version supports existing token id
clevis built on 05-Feb, and cryptsetup 2.6.1 wasn't uploaded until 19-Feb, so it does seem like your theory is plausible.
I think the right way to fix this is to add a versioned build-dep on whatever cryptsetup package it is testing so that it will refuse to build with a version that does not have this feature. We inherit this package from Debian, so we'd want to make a pull request there. Are you comfortable proposing that? There's already a build-dep on cryptsetup-bin, but this version dependency might be on libcryptsetup-dev? We'd have to look to see what exactly clevis is testing during build.
Once accepted, we can merge that into the dev release (mantic), and then look into a lunar backport. For the lunar backport, we'll need to reformat the description of this bug using the SRU template:
https:/
That will communicate to our stable release team why we want to do this, and why we believe it is safe to do so. Could you make an attempt at drafting that?