[PKG-Openstack-devel] Bug#835177: Bug#835177: Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Santiago Vila]

On Thu, Oct 13, 2016 at 01:02:30AM +0200, Thomas Goirand wrote:

> The issue is inter-(build-)dependencies. Let's say we have package A
> that build-depends on B, which itself build-depends on C. We then have
> to do a source-only upload of C, wait for the next dak run, wait for it
> to be built, then installed in the master repository. Then it has to
> reach the mirrors of buildd machines (hint: packages propagate at
> different speed on each dak run, depending on the mirror configuration,
> Internet connectivity, and so on).

No. Please take a look at any recent build log, you will see something
like this:

Get:7 http://incoming.debian.org/debian-buildd buildd-unstable/contrib Sources [920 B]
Get:8 http://incoming.debian.org/debian-buildd buildd-unstable/non-free Sources [32 B]
Get:9 http://incoming.debian.org/debian-buildd buildd-unstable/main arm64 Packages [213 kB]

I don't know the exact definition, but surely this "incoming" thing is
something you seem not to be taking in account at all.

> Then only, B can be built, which also
> takes so long. Then only A can be built.
> 
> All of this could take maybe 2 days.

No. If A "build-depends: B" and B "build-depends: C", that would be
three mirror pulses at most, and we have a mirror pulse every six
hours. Between the first and the third mirror pulse we would only have
12 hours of "breakage", but we are talking about unstable, so that's
normal and expected.

> [...]
> still much nicer than living unstable broken for days/weeks

No, 12 hours are not days or weeks, it's less than a single day.

Your theory is basically that "a little bit of cheating is ok".
Sorry, but that does not sound acceptable.

I didn't want to add to this discussion after the reply from Ondrej,
but since you insist, here is some data:

My autobuilder tried today to build in testing all the source packages
below, they were uploaded for unstable five days ago but they were
really unbuildable in unstable.

They are still unbuildable in testing and they will remain unbuildable
in testing for four additional days:

bandit
barbican
designate
glance
ironic-inspector
magnum
manila
python-cinderclient
python-congressclient
python-debtcollector
python-glance-store
python-heatclient
python-ironicclient
python-keystoneauth1
python-keystoneclient
python-keystonemiddleware
python-magnumclient
python-manilaclient
python-mistralclient
python-neutronclient
python-neutron-lib
python-novaclient
python-openstacksdk
python-osc-lib
python-oslo.concurrency
python-oslo.config
python-oslo.db
python-oslo.messaging
python-oslo.middleware
python-oslo.privsep
python-oslo.rootwrap
python-oslo.service
python-oslo.utils
python-oslo.vmware
python-pycadf
python-senlinclient
python-tooz
zaqar

If you really care about doing "nice" things, I can think of many
things a lot nicer than uploading 38 unbuildable source packages for
unstable and then letting them to propagate to testing.

IMHO, we should really have higher standards of quality.

The right thing is still to use a clean sid chroot or doing
source-only uploads.

Thanks.