Christian Kastner <c...@debian.org> writes: >>> The only "condition" would be that 2.73 migrates to testing before we >>> add a new package, just to ensure that trixie will be up to date, given >>> the 2025-03-15 freeze. But that's only 2-day delay, and we can use that >>> to finalize the Go package. >> >> No problem, I understand and agree -- when I can take a look at your >> 2.73 packaging, I'll try to propose a merge request for 'libcap2' on >> Salsa that adds NEW golang-*-dev package and the associated debian/rules >> changes. Hopefully adding that won't break anything in the non-Go part >> of the build... then you can see if it builds for you, and do the NEW >> upload, maybe to experimental as first. I think it is permitted to >> continue upload to sid if you really need to, but it causes some version >> sort confusion so better is to get what you want into testing first and >> then do the NEW upload. > > Sounds great, thanks!
There is now a crude patch that add Go package to libcap2 here: https://salsa.debian.org/jas/libcap2/-/commit/cc9f4c1554798f0baec9d2fe00d45a559458f866 The pipeline produces golang-kernel-pub-linux-libs-security-libcap-dev: https://salsa.debian.org/jas/libcap2/-/pipelines/817826 Which is used by the upcoming golang-github-landlock-lsm-go-landlock: https://salsa.debian.org/jas/golang-github-landlock-lsm-go-landlock/-/pipelines/817834 Which in turn is used by the upcoming sbctl: https://salsa.debian.org/jas/sbctl/-/pipelines/817836 As you can see, the 'sbctl' binaries build so the libcap2 Go package may be doing something useful. However I don't know how to test anything with confidence. I don't yet dare to run 'sbctl' on my machine. Christian, could you take a look at the patch? In particular, can you see if it modify anything in the OTHER binary packages? I tried to use debdiff and diffoscope to find any unintentional changes, but I may have failed. My hope is that if this patch doesn't change anything for non-Go packages, you may find it acceptable to upload to NEW since any breakage is purely for the Go package which I hope to maintain and help going forward. Nicolas, you said libcap2's Go packages was used by docker-buildx. Are you able to test the libcap2 Go packages above with docker-buildx? I'm thinking that if you are also able to get something useful out of the libcap2 Go packages, we are more likely to be on the right track. /Simon
signature.asc
Description: PGP signature
