Heh, this can indeed be surprising, the only reason I knew is because
I've been bitten by this in the past.
Neither me nor Paul immediately why that built-tree detection and
treatment is needed; what I can see is that it was implemented a long
time ago, likely for good reasons we'll need to
After a bit more reflexion, I'd even argue that this 'built tree'
exception shouldn't exist in the first place as it seems like a nice
footgun, but I'm guessing it's not that simple, so in the mean time I'll
just go and amend my wrapper script to not use `autopkgtest .` but
rather
I'll be damned. That's the issue, indeed. I tried to reproduce with a
fresh `hello` but couldn't so I wrongly concluded that it was because it
wasn't on the image.
I'd argue it's still a bug, as in *this should be documented*! I'd never
consider that an unpackage source package would be in a
Hi, autopkgtest should already setup pinning to ensure that the tested
package is the built one.
Before digging any deeper let's check one thing. When you specify a
source package directory, autopkgtest distinguishes between a "built
tree" and an "unbuilt tree". In the case of a "built tree", all
I'm not sure if it's going to help us much, but can you run with `-ddd`
and attached the (compressed) log to this log for inspection?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056334
Title:
Confirmed on salsa, and yes I'm using noble, 5.32ubuntu3, sorry about
that.
One solution I could think of is to go through the list of dependencies
and add a strict version if it's a binary generated by the tested source
package (lib/adt_testbed.py, install_apt)
--
You received this bug
Thanks for the report.
What version of autopkgtest are you using? I expect 5.32ubuntu3 from Noble?
Is the same issue also happening using upstream's master branch?
```
git clone https://salsa.debian.org/ci-team/autopkgtest/
./autopkgtest/runner/autopkgtest . -U -- lxd
