Building against Proposed, but Testing against Release

[Christian Ehrhardt ]

Hi,
I've run into an issue where I happened to build a package in a bileto ppa but failed testing.
In that particular case the reason is as following:
1. Upload Package to Bileto PPA
2. PPA Builds against proposed and picks up new library dependencies
3. Dep8 tests are scheduled later
4. Dep8 tests fail due to the new library not being in release (only proposed atm)
   The Tests appear as "failed due to uninstallable test dependencies", that comes from the
   package in the ppa requiring the new lib from proposed, but can't reach it in the Test env that
   Bileto/Britney set up.

Since I usually use Bileto as great sniff Tester of all-arch build+test before publishing or uploading to a devel release this kind of breaks my use case.
From the discussions we had before on Bileto I'd have assumed it builds AND tests against proposed.

Therefore my Questions would be:
1. is it intentional to test against Release and not proposed (even for a Dev release)?
2. (I assume there is a reason for #1), but would it make sense to provide a config switch on a ticket to select what it will be tested against on Britney.

It might just be a lack of understanding of the Bileto/Britney infrastructure on my side, but in that cases the bug can serve to educate me and anybody else finding it later.

[Christian Ehrhardt  (paelzer)]

I even found that when trying to mitigate the issue by uploading the source of the "only in proposed" lib that is missing in the test into the bileto ppa I get warnings like:
"Needs rebuild due to burned version number (zesty/xen). Pending binary packages"

I know the number is burnt, but it won't be there when testing it so I need you to burn :-)
Or just allow to run the dep8s against proposed.

[Christian Ehrhardt  (paelzer)]

It won't let me make Diffs/Tests due to the burnt version number (I understand), so +1 without really wanting it :-)

I hope you can see my case and help me to sort things out either by a fix/feature to Bileto or providing the missing piece to the puzzle for my understanding.

[Robert Bruce Park (robru)]

Burned version number? How did you copy the package? Did you download the source and then reupload the source package? Don't do that. Use copy-package to bincopy the package from the release to the PPA. "burned version number" means "I inspected this package and the package in the destination archive and determined that they have the same version number but the source contents don't match"

As for the release/proposed issue, yeah, I can't remember why it is the way it is. This has been a highly contentious issue that comes up from time to time. Every now and then somebody complains about it so we change it and then later somebody else complains so we change it back.

[Robert Bruce Park (robru)]

If you bincopy the package from proposed, you'll know it worked when the status on the ticket will be 'proposed pocket'

[Christian Ehrhardt  (paelzer)]

Thanks Robert for the explanations,
I'm totally good on the burned version part of this.

Yet on the "release/proposed" issue quoting you: "I can't remember why it is the way it is. This has been a highly contentious issue that comes up from time to time. Every now and then somebody complains about it so we change it and then later somebody else complains so we change it back."

Changing back and forth sounds like a config switch to me if that could be implemented.
That you changed it in the past also implies that the bits to do so are known right?

[Robert Bruce Park (robru)]

Yeah the bits are known, i just don't remember and would need to dig it up again. Sorry my memory is really hazy on this, need somebody like Rodney or Steve to weigh in on why it is the way it is and what are the consequences of changing it.

[Balint Reczey (rbalint)]

I think testing against release is intentional and better than testing against proposed, since the same tests would be run for archive uploads, too.