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/luks/meson.build:23: WARNING: cryptsetup version does not support existing token id
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:
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?
Here's the amd64 build log for lunar: /launchpadlibra rian.net/ 649772129/ buildlog_ ubuntu- lunar-amd64. clevis_ 19-2_BUILDING. txt.gz
https:/
In there I see: luks/meson. build:23: WARNING: cryptsetup version does not support existing token id
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: /launchpadlibra rian.net/ 678645100/ buildlog_ ubuntu- mantic- amd64.clevis_ 19-3_BUILDING. txt.gz
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:/ /wiki.ubuntu. com/StableRelea seUpdates
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?