Bileto driven Builds differ from "real" LP Builds

[Christian Ehrhardt ]

Hi,
it might just be a spurious dependency change e.g. slighly changed python versions or something similar. But I'm confused enough that I think it is worth to report, althou at low prio.

Among other things https://bileto.ubuntu.com/#/ticket/2290 was meant to test if invasive changes still build fine on LP without polluting the main archive with version bumps.
It built just fine there.

I later uploaded to LP and there build failed for all architectures.
I wonder if we have a hidden issue of the builds being not 100% equivalent.

There are slight changes (one patch more applied), but that is totally unrelated to where the error occurs.

I'll attach build logs and point to where the critical difference starts.

[Christian Ehrhardt  (paelzer)]

Search for "apibuild" in both build logs while running e.g. in a vimdiff.

It is only occuring on the failing ones, and I don't see why it should do so.

xsltproc (the path the working one takes) is a build dependency, so it should be available in both cases.

[Christian Ehrhardt  (paelzer)]

As there is a chance that this is either transient or an issue in the libvirt packaging that I'm not yet understanding - Also while I doubt several build deps got minor bumps between the two days this was built - so please rate it as low prio.

But given that there is a (slight) chance that builds would not match I wanted to report to be sure. And I'd be happy if one could for 5 minutes check with a second pair of eyes if I'm overlooking something in this case.

[Christian Ehrhardt  (paelzer)]

I'll keep the ticket for a few days more, but the chance that we abandon and loose logs is the reason I attached the build logs to begin with:

Failed builds belong to https://launchpad.net/ubuntu/+source/libvirt/2.1.0-1ubuntu15

[Christian Ehrhardt  (paelzer)]

Here a local build log of the same case with a fix applied:
If looking for apibuild we can see:
  srcdir=../../../docs builddir=. /usr/bin/python2 ../../../docs/apibuild.py
  touch ../../../docs/apibuild.py.stamp
  if [ -x /usr/bin/xsltproc ] ; then \

The fix we have applied makes the apibuild not to fail.
And then it hits:
  touch ../../../docs/apibuild.py.stamp
and goes on as the working bileto build.

It almost seems that in the bileto env there would have been a valid ../../../docs/apibuild.py.stamp around to skip that part - which IMHO should be impossible.

[Robert Bruce Park (robru)]

Yeah as far as I know PPA builds are using the exact same builders as what launchpad uses for the archive, so it should really be impossible for them to be different. Please escalate this to #launchpad people as it's well outside my area of expertise.

[Christian Ehrhardt  (paelzer)]

On Wed, Dec 14, 2016 at 12:19 PM, Robert Bruce Park <
<email address hidden>> wrote:

> Please escalate this to #launchpad people as
> it's well outside my area of expertise.
>

I'll upload "the same" into the ppa and check if it does the same this time
- just to get rid of the little difference that was left.

[Christian Ehrhardt  (paelzer)]

Hrm,
I uploaded the libvirt - 2.1.0-1ubuntu16 to the ppa.
The same that I uploaded to the archive via dput this morning.

But some 10 minutes after I got:
2016-12-14 15:10:44 +0100 (bileto-bot) Landed
2016-12-14 15:10:24 +0100 (bileto-bot) Release pocket

Which is a bit tricky, the ppa now reports it is deleted

No Finalize/Publish or anything like it was pressed.
I'd assume that it picked up that the same version just migrated and killed finalized the ticket on its own.

That makes it impossible to test/verify the case from now on.
While I wonder about the auto-land/release that might just be one more automation of bileto I don't know about it yet.

@Robert - if you agree we can set this bug to "invalid" for now and I can re-open if I see something like it again someday.

[Robert Bruce Park (robru)]

Yes, when bileto detects that all the packages in the PPA are in zesty, it deletes the PPA and closes the ticket (and also merges merges but you didn't have any of those).

What you could do if you wanted to investigate this further is to upload some other package into the PPA (eg like just make a new upload of gnu hello), this upload would then not be released in zesty and would stop bileto from deleting the PPA.

[Launchpad Janitor (janitor)]

[Expired for Bileto because there has been no activity for 60 days.]