Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue
Control: tag -1 patch On Wed, Nov 10, 2021 at 7:55 AM Shengjing Zhu wrote: > > > > Cloud you backport following commit? > > > > > > > https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b > > > > > This patch updates libocispec/Makefile.am, which is needed to be > backported. > > This patch looks like doing nothing to C part, because the generated source > is removed in upstream repo. Theses files(which are added in Makefile.am) > can > be generated by `make -C libocispec generate`. So please also uncomment > this > line in debian/rules. > > > D'oh, my bad, I've overlooked the Makefile.am parts. So the generator *is* already invoked, but the automake system doesn't pick up all files, leading to the linker failures. I've implemented your suggestion in https://salsa.debian.org/debian/crun/-/merge_requests/1/diffs and can confirm that the package now builds fine. Dmitry, please let me know if you are comfortable with me NMU'ing the package with the patch from salsa. -- regards, Reinhard
Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue
On Wed, Nov 10, 2021 at 07:27:58AM -0500, Reinhard Tartler wrote: > That's not sufficient. > > the commit you point out does two things: > > - update the submodules for 'image-spec' and 'runtime-spec' (which the > Debian package currently overrides with the distro-provided copies) > - zos-related changes to the rust bindings (which the Debian package > doesn't have at all at this point) > > The missing definitions that the linker stumbles over are generated from > the json files. But I haven't found where that generation exactly happens > and what change is missing to it. > > Thanks for your swift reply! > > On Tue, Nov 9, 2021 at 8:47 PM Shengjing Zhu wrote: > > > Cloud you backport following commit? > > > > https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b > > This patch updates libocispec/Makefile.am, which is needed to be backported. This patch looks like doing nothing to C part, because the generated source is removed in upstream repo. Theses files(which are added in Makefile.am) can be generated by `make -C libocispec generate`. So please also uncomment this line in debian/rules. Thanks.
Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue
Looking more into it, here are more observations: - crun upstream has a git submodule on 'libocispec' (the repo you asked me to backport). The release tarballs contain a copy of the submodule contents at the time of the release - the 'libocispec' submodule contains two additional submodules 'image-spec' and 'runtime-spec' - the debian package replaces only the two "inner" submodules 'image-spec' and 'runtime-spec' with sources found in Debian packages, but not the outer 'libocispec', which isn't found in debian - the Debian packages of 'image-spec' and 'runtime-spec' have been updated last August, and contain specification for the "zos" platform - the 'libocispec' repository contains a generator that reads those specifications and generates code. It seems to me that this is the code generator that lacks some zos related definition and thus causes the linker failure - the 'libocispec' repository has last synced with 'image-spec' and 'runtime-spec' last January, and thus is missing the zos related changes This is very messy. I can totally understand upstream's stance to just vendor the specs so that the generator is only used with versions of the specifications that have actually been tested. I don't think it is a good use of Debian's developers' time to play this game of catching up. On Wed, Nov 10, 2021 at 7:27 AM Reinhard Tartler wrote: > That's not sufficient. > > the commit you point out does two things: > > - update the submodules for 'image-spec' and 'runtime-spec' (which the > Debian package currently overrides with the distro-provided copies) > - zos-related changes to the rust bindings (which the Debian package > doesn't have at all at this point) > > The missing definitions that the linker stumbles over are generated from > the json files. But I haven't found where that generation exactly happens > and what change is missing to it. > > Thanks for your swift reply! > > On Tue, Nov 9, 2021 at 8:47 PM Shengjing Zhu wrote: > >> Cloud you backport following commit? >> >> https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b >> >> >> (Sent on my mobile phone) >> >> Reinhard Tartler 于 2021年11月10日周三 07:05写道： >> >>> I took a look at the issue and here are my thoughts: >>> >>> - the build error is a failure to link some test binaries. excluding >>> them from the build might be possible with some patching. >>> - I've upgraded the package to the latest upstream 1.3, and was seeing >>> exactly the same build failure >>> - the build failure goes away when not stripping the bundled copies of >>> runtime-spec and image-spec >>> - Dimtry had a conversation about this with upstream at >>> https://github.com/containers/crun/issues/240. It seems to be that >>> upstream strongly recommends to just use the vendored copies of image-spc >>> and runtime-spec >>> - I've pushed my work to >>> https://salsa.debian.org/debian/crun/-/merge_requests/1 >>> - I believe the issue was introduced by Shengjing's update in >>> https://tracker.debian.org/news/1249177/accepted-golang-github-opencontainers-specs-10266g20a2d97-1-source-into-unstable/ >>> -- but that was already months ago. So that may not be true >>> >>> With this, I'd like to suggest to move ahead with my merge request and >>> don't strip image-spec and runtime-spec from the package. >>> >>> Any thoughts? >>> >>> -- >>> regards, >>> Reinhard >>> >> > > -- > regards, > Reinhard > -- regards, Reinhard
Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue
That's not sufficient. the commit you point out does two things: - update the submodules for 'image-spec' and 'runtime-spec' (which the Debian package currently overrides with the distro-provided copies) - zos-related changes to the rust bindings (which the Debian package doesn't have at all at this point) The missing definitions that the linker stumbles over are generated from the json files. But I haven't found where that generation exactly happens and what change is missing to it. Thanks for your swift reply! On Tue, Nov 9, 2021 at 8:47 PM Shengjing Zhu wrote: > Cloud you backport following commit? > > https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b > > > (Sent on my mobile phone) > > Reinhard Tartler 于 2021年11月10日周三 07:05写道： > >> I took a look at the issue and here are my thoughts: >> >> - the build error is a failure to link some test binaries. excluding them >> from the build might be possible with some patching. >> - I've upgraded the package to the latest upstream 1.3, and was seeing >> exactly the same build failure >> - the build failure goes away when not stripping the bundled copies of >> runtime-spec and image-spec >> - Dimtry had a conversation about this with upstream at >> https://github.com/containers/crun/issues/240. It seems to be that >> upstream strongly recommends to just use the vendored copies of image-spc >> and runtime-spec >> - I've pushed my work to >> https://salsa.debian.org/debian/crun/-/merge_requests/1 >> - I believe the issue was introduced by Shengjing's update in >> https://tracker.debian.org/news/1249177/accepted-golang-github-opencontainers-specs-10266g20a2d97-1-source-into-unstable/ >> -- but that was already months ago. So that may not be true >> >> With this, I'd like to suggest to move ahead with my merge request and >> don't strip image-spec and runtime-spec from the package. >> >> Any thoughts? >> >> -- >> regards, >> Reinhard >> > -- regards, Reinhard
Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue
Cloud you backport following commit? https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b (Sent on my mobile phone) Reinhard Tartler 于 2021年11月10日周三 07:05写道： > I took a look at the issue and here are my thoughts: > > - the build error is a failure to link some test binaries. excluding them > from the build might be possible with some patching. > - I've upgraded the package to the latest upstream 1.3, and was seeing > exactly the same build failure > - the build failure goes away when not stripping the bundled copies of > runtime-spec and image-spec > - Dimtry had a conversation about this with upstream at > https://github.com/containers/crun/issues/240. It seems to be that > upstream strongly recommends to just use the vendored copies of image-spc > and runtime-spec > - I've pushed my work to > https://salsa.debian.org/debian/crun/-/merge_requests/1 > - I believe the issue was introduced by Shengjing's update in > https://tracker.debian.org/news/1249177/accepted-golang-github-opencontainers-specs-10266g20a2d97-1-source-into-unstable/ > -- but that was already months ago. So that may not be true > > With this, I'd like to suggest to move ahead with my merge request and > don't strip image-spec and runtime-spec from the package. > > Any thoughts? > > -- > regards, > Reinhard >
Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue
I took a look at the issue and here are my thoughts: - the build error is a failure to link some test binaries. excluding them from the build might be possible with some patching. - I've upgraded the package to the latest upstream 1.3, and was seeing exactly the same build failure - the build failure goes away when not stripping the bundled copies of runtime-spec and image-spec - Dimtry had a conversation about this with upstream at https://github.com/containers/crun/issues/240. It seems to be that upstream strongly recommends to just use the vendored copies of image-spc and runtime-spec - I've pushed my work to https://salsa.debian.org/debian/crun/-/merge_requests/1 - I believe the issue was introduced by Shengjing's update in https://tracker.debian.org/news/1249177/accepted-golang-github-opencontainers-specs-10266g20a2d97-1-source-into-unstable/ -- but that was already months ago. So that may not be true With this, I'd like to suggest to move ahead with my merge request and don't strip image-spec and runtime-spec from the package. Any thoughts? -- regards, Reinhard
