[06:40] <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:41] <fnordahl> An alternative is of course to wait out the SRU cycle for the openvswitch package, but that would cause delays
[07:50] <Skia> fnordahl: yes, adding the right trigger in a retry request will do exactly that
[07:51] <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
[08:03] <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:04] <Skia> sorry XD   yes, I don't think there is a way to automate that kind of behavior for certain packages :/
[08:08] <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:30] <fnordahl> Ah, yes.  I guess we should do some SEO to get that one higher up on the google search results ;)
[08:32] <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:47] <ginggs> fnordahl: if ovn needs openvswitch from -proposed, shouldn't it declare that dependency in debian/control?
[08:49] <fnordahl> ginggs: it does declare the expected version
[08:51] <ginggs> then autopkgtest should do the right thing, without needing extra triggers
[09:20] <paride> fnordahl, hi
[09:22] <paride> fnordahl, looking at https://git.launchpad.net/ubuntu/+source/ovn/tree/debian/control?h=ubuntu/noble-proposed
[09:23] <paride> fnordahl, which dependency are you referring to exactly?
[09:28] <paride> fnordahl, I think I understand the problem
[09:30] <fnordahl> paride: specifically this one: openvswitch-source (>= 3.3.0-1ubuntu3~)
[09:32] <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:33] <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:35] <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:37] <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:38] <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:40] <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:56] <paride> fnordahl, let's see how this goes https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/358/diffs
[10:07] <fnordahl> paride: yay, I'll leave a supporting comment to it