| fnordahl | is there a way to declare that certain dependencies need to come from -proposed for autopkgtests? The openvswitch and ovn packages have a inter-dependency and often need to be updated together, looking at https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-noble/noble/amd64/o/ovn/20240606_224327_59694@/log.gz it fails because it tries to use | 06:40 |
|---|---|---|
| fnordahl | openvswitch-source from release/updates while it needs to come from -proposed | 06:40 |
| fnordahl | An alternative is of course to wait out the SRU cycle for the openvswitch package, but that would cause delays | 06:41 |
| Skia | fnordahl: yes, adding the right trigger in a retry request will do exactly that | 07:50 |
| Skia | fnordahl: there are explanations here for this use-case: https://wiki.ubuntu.com/ProposedMigration#How_to_re-run_autopkgtests_with_dependencies_on_other_packages_in_the_proposed_pocket | 07:51 |
| Skia | let me know if you struggle with that | 07:51 |
| fnordahl | Skia: ah, excellent, thank you for that pointer. So we would essentially have to do that manually in these situations then, I guess that's ok. I checked for any hints in the control format in https://people.debian.org/~eriberto/README.package-tests.html but did not find anything there, so I guess this is the way | 08:03 |
| Skia | this is the way | 08:03 |
| Skia | sorry XD yes, I don't think there is a way to automate that kind of behavior for certain packages :/ | 08:04 |
| Skia | also, just for the sake of it: here is the most up to date version of the document you pointed: https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst | 08:08 |
| fnordahl | Ah, yes. I guess we should do some SEO to get that one higher up on the google search results ;) | 08:30 |
| Skia | well, we have some ongoing work to improve autopkgtest documentation in overall, that might be part of it | 08:32 |
| Skia | I'll log that to our document | 08:32 |
| ginggs | fnordahl: if ovn needs openvswitch from -proposed, shouldn't it declare that dependency in debian/control? | 08:47 |
| fnordahl | ginggs: it does declare the expected version | 08:49 |
| ginggs | then autopkgtest should do the right thing, without needing extra triggers | 08:51 |
| paride | fnordahl, hi | 09:20 |
| paride | fnordahl, looking at https://git.launchpad.net/ubuntu/+source/ovn/tree/debian/control?h=ubuntu/noble-proposed | 09:22 |
| paride | fnordahl, which dependency are you referring to exactly? | 09:23 |
| paride | fnordahl, I think I understand the problem | 09:28 |
| fnordahl | paride: specifically this one: openvswitch-source (>= 3.3.0-1ubuntu3~) | 09:30 |
| paride | fnordahl, first, you install the ovn build-deps from the debian/tests/* test scripts by calling `mk-build-deps`. You could use @builddeps@ in d/t/control, which should do exactly that. | 09:32 |
| paride | fnordahl, doing that, autopkgtest should take care of relaxing pinning if test deps (which now include the builddeps) are not installable with strict pinning | 09:32 |
| paride | fnordahl, that basically turns the "pinned" test in an all-proposed test, but that's what we have for now | 09:33 |
| paride | fnordahl, with the apt solver3, we'll be able to use --no-strict-pinning, which will do smarter things | 09:33 |
| paride | fnordahl, but that's a work in progress on all fronts for now | 09:33 |
| paride | fnordahl, I see that you manually dpkg-buildpackage because you want to build with nocheck, and Restrictions: build-needed doesn't set that profile. Maybe we should do that by default | 09:35 |
| paride | fnordahl, for now, I suggest trying with @builddeps@, which will put the test deps resolution in the hands of autopkgtest, which should know what to try | 09:37 |
| paride | makes sense? | 09:37 |
| fnordahl | paride: thanks alot for looking and for your insights, I had forgotten about that bit. While I can't use `build-needed` for exactly that reason I guess I could still use @builddeps@ as dependency to avoid this issue | 09:37 |
| fnordahl | the only undesired side effect of that is that the test might succeed by proxy of build depends being present, shadowing any missing `Depends` statements | 09:38 |
| fnordahl | But I guess I can do both, i.e. do a mk-build-deps step to understand what to remove | 09:38 |
| fnordahl | thanks alot paride ! | 09:38 |
| paride | fnordahl, yw! maybe build-needed makes sure that builds-deps are not kept by default during the test run, I am not sure right now | 09:40 |
| paride | fnordahl, let's see how this goes https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/358/diffs | 09:56 |
| fnordahl | paride: yay, I'll leave a supporting comment to it | 10:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!