Santiago Vila <sanv...@unex.es>:
> This is still happening, both in reproducible-builds and also in my
> own autobuilders. The reproducible-builds logs are available here:
>
>
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neutron.html
>
> and I've just put my build logs here:
>
> https://people.debian.org/~sanvila/build-logs/neutron/

What's weird, is that it's not the same amount of failures.

> (I'm still using eatmydata, since you said you use it yourself and
> it's supposed to work).

Correct.

> Please take a look at this. Just saying "it works for me" does not
> help.

Here, you're recognizing that there's a pattern, and that we've seen
already a few times that, building works for me, but fails in your
environment. So, quite the opposite, the "it works for me" is important,
and needs to be addressed. We need to figure out what is different in
your environment and mine.

To investigate this, I've just tried building in a porter box, which
normally should be very close (if not identical) to what we have in the
buildd network. What I did was really only download the build
dependencies in the schroot, and run dpkg-buildpackage in the schroot:
so nothing special, really. The build was on barriere.debian.org.

The result is that it works perfectly. I do expect to see the same
result if uploading source only.

One thing I've observed, is that most of the times (or every time?), the
test errors we've seen are in SQLite, with a "table doesn't exist"
error. I have no idea (yet) why it's like that.

> While we are at it, I have yet to see how this is not serious,
> being a FTBFS bug in a supported architecture, but I will be happy to
> skip the discussion about the severity as far as you are really
> willing to solve the problem.

An FTBFS which we would observe everywhere, including in porter boxes
(which are normally the same as the buildds), in all configurations
including the most basic one (like mine), would indeed qualify as an RC
bug. Though if there's an FTBFS only in some specific environments,
which we aren't even able to explain, doesn't look like a good candidate
for an RC bug.

> If you still need a machine to reproduce this, please contact me
> privately.

Unfortunately, last time I tried, I could indeed see the FTBFS, but I
wasn't able to understand why it was happening in your build env and not
the standard one (ie: porter box or my own sbuild setup). As you're
actually paying for the VM to be hosted, I don't dare to ask you to
leave it up, and I'm unsure what to do... :/

I'm open to ideas and I am willing to spend the time to understand, if
you have some clues,
Cheers,

Thomas Goirand (zigo)

Reply via email to