[opensuse-releaseteam] Newer version of libsolv-tools required on packagelists for repo-checker
openSUSE:Factory:Staging:adi:1 contains packages that use rich deps syntax which confuse the installcheck tool which intern causes repo-checker to spit out an error. This error would have caused the previous repo-checker to silently crash and accept the review. :) Running repo-checker on a Tumbleweed machine results in a pass, but on the packagelists machine results in a failure. The difference appears to be libsolv-tools: Tumbleweed = 0.6.28 SLE-12-SP2 = 0.6.26 The resulting error: could not add repo /tmp/repochecker-iewAELU/packages: susetags: line 5466484: unknown relation: 'if' It seems the most straightforward approach would be to use a newer version libsolv on the machine. SLE-12-SP3 provides libsolv-0.6.27 which seems to handle the syntax when run in a test container. As such the best solution is likely to update the machine to SP3. On a more general note this is likely to reoccur when new features are introduced into rpm and used in Factory as the packagelists machine will always be using trailing versions of libsolv. As such it might make more sense to run the repo-checker within a docker container running the latest Tumbleweed snapshot to ensure access to the latest underlying tooling. Any opinions on doing this? I'll file an issue in osc-plugin-factory to track discussion. With the rpm package built that contains the repo-checker it should not be hard to run things in a docker container. What is the workflow for updating the packagelists machine? -- Jimmy -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
- created github issue [1] to track the root problem. - accepted adi:1 repo-checker reviews using local run on TW to unblock For the adi:1 run I copied credentials locally and ran: ./repo_checker.py --debug id 517039 517040 517041 517042 517054 Having the machine updated soon would be preferable to avoid having to do this for other requests. [1] https://github.com/openSUSE/osc-plugin-factory/issues/1054 -- Jimmy -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
Jimmy Berry wrote:
[...] On a more general note this is likely to reoccur when new features are introduced into rpm and used in Factory as the packagelists machine will always be using trailing versions of libsolv. As such it might make more sense to run the repo-checker within a docker container running the latest Tumbleweed snapshot to ensure access to the latest underlying tooling. Any opinions on doing this? I'll file an issue in osc-plugin-factory to track discussion.
With the rpm package built that contains the repo-checker it should not be hard to run things in a docker container.
A simple chroot or systemd machined mananged chroot should suffice too. I guess we'd need a proper testsuite fist to make sure results are not unintentionally influenced by changes in Tumbleweed.
What is the workflow for updating the packagelists machine?
Asing infra probably. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
On Wednesday, August 16, 2017 3:25:40 AM CDT Ludwig Nussel wrote:
Jimmy Berry wrote:
[...] On a more general note this is likely to reoccur when new features are introduced into rpm and used in Factory as the packagelists machine will always be using trailing versions of libsolv. As such it might make more sense to run the repo-checker within a docker container running the latest Tumbleweed snapshot to ensure access to the latest underlying tooling. Any opinions on doing this? I'll file an issue in osc-plugin-factory to track discussion.
With the rpm package built that contains the repo-checker it should not be hard to run things in a docker container.
A simple chroot or systemd machined mananged chroot should suffice too. I guess we'd need a proper testsuite fist to make sure results are not unintentionally influenced by changes in Tumbleweed.
chroot containing entire distribution or just a couple tool updates? A test suite would be nice, but the alternative is the tool unintentionally fails due to changes introduced in Tumbleweed.
What is the workflow for updating the packagelists machine?
Asing infra probably.
Submitted ticket #90566. -- Jimmy -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
participants (2)
-
Jimmy Berry
-
Ludwig Nussel