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

[Thomas Goirand]

On 10/13/2016 01:37 PM, Santiago Vila wrote:
> + set -e
> ++ mktemp -d /tmp/AODH-MONGODB-X
> + MONGO_DATA=/tmp/AODH-MONGODB-lZXDc
> + MONGO_PORT=29000
> + mkfifo /tmp/AODH-MONGODB-lZXDc/out
> + MONGO_PID=16886
> + wait_for_line 'waiting for connections on port 29000' 
> /tmp/AODH-MONGODB-lZXDc/out
> + mongod --maxConns 32 --nojournal --noprealloc --smallfiles --quiet --noauth 
> --port 29000 --dbpath /tmp/AODH-MONGODB-lZXDc --bind_ip localhost --config 
> /dev/null
> + read line
> 
> 
> I don't know what you did to try to fix this, but apparently it didn't
> work, so I'm reopening this (wishlist) bug, and I hope you are still
> willing to make this package compatible with eatmydata.
> 
> Thanks a lot.

I thought the issue was killing the processes *after* the unit tests are
run. But then I tried to use command-prefix=eatmydata in the chroot.d
file, and began to understood what happened.

If you prefix the start of mongod with eatmydata, then the daemon
produces no output at all, and the above script is in fact waiting for
such text output.

So I tried to write a script that would use netcat to see if the port
29000 is opened or not. And then I've seen that in fact, mongodb really
seem to be stuck, doing nothing, if invoked with eatmydata. A quick use
of strace shows that, with eatmydata, mongodb-server is looping on some
nanosleep() calls.

So I'm really not sure how to fix the issue. Any idea? Is there a way to
disable eatmydata explicitly in my package, maybe only when starting
mongodb? Is there a better way to setup schroot than adding
command-prefix=eatmydata in your chroot.d schroot config file?

Cheers,

Thomas Goirand (zigo)

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

[Santiago Vila]

On Thu, Oct 13, 2016 at 05:49:00PM +0200, Thomas Goirand wrote:
> On 10/13/2016 02:03 AM, Santiago Vila wrote:
>
> > 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.
> 
> I also need to sleep sometime, you know... :)

Well, it would be possible to use cron and upload in chunks automatically.

But I think the suggestion from Ondrej is even better: Upload everything
in source-only form at once and let the autobuilders do their job.

> [...]
> Though for the "propagate to testing", I need to find out a way to fix
> the current state of things, because right now, it's really done in a
> *very* messy way for which I'm not satisfied at all. We currently have
> half of Newton not yet migrated to Testing. Do you know if there's
> another way than just opening an RC bug on each and every package?

That's a very good question.

One possibility is to use the urgency field for the uploads.

For example, when uploading python-fixtures, using "high" instead of
"medium" would have reduced the time the packages are broken in
testing.

I think it is also possible to modify the urgency of an already
uploaded package by asking the release managers specifically.

For example, I think it would be possible to submit a bug against
release.debian.org saying "please modify the urgency for the following
source packages to be 20 days instead of the 5 days I used for the
uploads".

But maybe the thing that would help most to avoid the breakage
that happened in testing this time would be a britney script
which honors build-dependencies and not just dependencies.

Hopefully some FTPMaster some day will fix that. If not, the code for
"dak" is in git, so we would just need a little bit of time, patience,
and motivation...

Thanks.

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

[Santiago Vila]

On Thu, Oct 13, 2016 at 05:09:06PM +0200, Thomas Goirand wrote:

> Back to the issue: can you check if #835177 is really solved, and aodh
> builds fine for you with eatmydata?

I posted my findings several hours ago in the logs for this bug.
This is the link if you missed it:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835177#75

Thanks.

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

[Thomas Goirand]

On 10/13/2016 02:03 AM, Santiago Vila wrote:
>> 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.

I also need to sleep sometime, you know... :)

> They are still unbuildable in testing and they will remain unbuildable
> in testing for four additional days:
> 
> bandit
> [...]
> zaqar

All of that because I forgot to upload a single build-dependency:
python-fixtures. Sorry. Hopefully, I'll succeed convincing the current
package maintainers that everything from github.com/testing-cabal needs
to be maintained as a whole, by a single packaging team. Right now, it's
messy, with mock and fixtures maintained elsewhere.

> 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.

I do feel bad about it, and hopefully, I will have less time pressure
moving forward. I was clearly a bit late for Newton.

Though for the "propagate to testing", I need to find out a way to fix
the current state of things, because right now, it's really done in a
*very* messy way for which I'm not satisfied at all. We currently have
half of Newton not yet migrated to Testing. Do you know if there's
another way than just opening an RC bug on each and every package?

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

The right thing, IMO, is having a sid CI comparable to what I have for
Jessie. Yes, what you wrote works, but it would take too much time.

Cheers,

Thomas Goirand (zigo)

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

[Thomas Goirand]

On 10/13/2016 02:29 AM, Santiago Vila wrote:
> For the record, here is a tarball for the 38 unbuildable source
> packages in testing I detected today related to OpenStack.
> 
> It could be that the intention was to avoid FTBFS, but this has been
> the result.
> 
> We might better have FTBFS happen in buildd.debian.org in unstable,
> as that's really the best way to ensure that packages are buildable.
> 
> Thanks.

Santiago,

It's very easy to throw stones at me for not following the best practice
in this way. Checking if a package builds correctly is indeed important,
but I consider that runtime is even more important, as it impacts
directly our users. On this ground, I did the correct work, and the
disruption in unstable was very short. I was also able to reach the
deadline of the OpenStack release on time for this release, just right
after finishing to move all packages to upstream Gerrit. This wasn't a
trivial task.

For the next release, I hope to have more time and build all in sbuild,
as I used to, with a local repository of already built packages, which
I'll be able to upload all at once as well. I've done that in the past,
and I'll do again. I have no doubts that this is the correct way to do
things, don't worry about that, you don't need to convince me on this.
This is by the way my plans for building jessie-backports of OpenStack
Newton, which is what I did for Mitaka (and uploaded all just right
before debconf 16, all at once, without any issue).

Back to the issue: can you check if #835177 is really solved, and aodh
builds fine for you with eatmydata?

Cheers,

Thomas Goirand (zigo)

Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Santiago Vila]

found 835177 3.0.0-2
thanks

On Mon, 10 Oct 2016, Thomas Goirand wrote:

> I have uploaded what I believe is a fix for #835177. Though as I am not
> sure how to reproduce your build env, it'd be really nice if you could
> try to build aodh 3.0.0-2 and check that the bug is really closed.
> 
> If that is the case (that my change fixes the FTBFS of aodh in your
> env), then I will apply the same kind of fix for #835178 and #835179.
> 
> Thanks a lot if you can help here,

Ok, now that all the build-depends are finally in unstable, I tried
again. I have triggered two different builds, one with eatmydata, and
another one without it.

The build without eatmydata finished successfully in 6 minutes.

The build with eatmydata is stuck at this point:

set -e ; \
TEMP_REZ=`mktemp -t` ; \
bash -x ./debian/setup-test-env-mongodb.sh testr run --subunit 
--parallel 
'aodh\.tests\.unit\.(?!(.*test_bin.*|.*test_messaging\.MessagingTests\.test_get_transport_optional.*))'
 | tee $TEMP_REZ | subunit2pyunit ; \
cat $TEMP_REZ | subunit-filter -s --no-passthrough | subunit-stats ; \
rm -f $TEMP_REZ ;
+ set -e
++ mktemp -d /tmp/AODH-MONGODB-X
+ MONGO_DATA=/tmp/AODH-MONGODB-lZXDc
+ MONGO_PORT=29000
+ mkfifo /tmp/AODH-MONGODB-lZXDc/out
+ MONGO_PID=16886
+ wait_for_line 'waiting for connections on port 29000' 
/tmp/AODH-MONGODB-lZXDc/out
+ mongod --maxConns 32 --nojournal --noprealloc --smallfiles --quiet --noauth 
--port 29000 --dbpath /tmp/AODH-MONGODB-lZXDc --bind_ip localhost --config 
/dev/null
+ read line


I don't know what you did to try to fix this, but apparently it didn't
work, so I'm reopening this (wishlist) bug, and I hope you are still
willing to make this package compatible with eatmydata.

Thanks a lot.

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

[Santiago Vila]

For the record, here is a tarball for the 38 unbuildable source
packages in testing I detected today related to OpenStack.

It could be that the intention was to avoid FTBFS, but this has been
the result.

We might better have FTBFS happen in buildd.debian.org in unstable,
as that's really the best way to ensure that packages are buildable.

Thanks.


build-logs.tar.gz
Description: application/gzip

Bug#835177: [PKG-Openstack-devel] 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.

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

[Thomas Goirand]

On 10/11/2016 08:13 PM, Ondrej Novy wrote:
> Hi,
> 
> 2016-10-11 18:58 GMT+02:00 Thomas Goirand  >:
> 
> It is impossible maintain 400+ interacting packages the way you would
> with your single pet package.
> 
> 
> I don't see any problem using source-only upload for all OS packages.
> buildd will wait for missed deps automatically and it's cross-check of
> your work.
> 
> The only way I see to fix this, is deploying the same kind of CI/CD we
> have designed in the OpenStack infrastructure, but using Sid, and
> 
> 
> this is not needed. We should use source-only upload, that's all. We
> already have something like CI/CD - buildd with source-only uploads +
> repro builds.

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). 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.

And that's not the only issue. In the OpenStack packages, there's cyclic
build-dependencies. We'd have to (temporarily) remove some unit tests
and build-dependencies for some packages to be buildable.

While you do all of this, as soon as package C is uploaded, maybe all of
OpenStack is broken (who knows? I wouldn't be surprised, I have seen
such things in the past...).

What I tried to achieve was uploading everything in a single Dak run, in
order to minimize the time when we're switching from Mitaka to Newton.
That's the best service I can do to both our users (so they get updates
at once if they run unstable), and to everyone that is contributing bug
reports, as it avoids FTBFS, runtime problems and such, just because we
don't have the correct working together set of packages.

So yeah, really, source-only uploads are nice, but it will never replace
a real CI, and it prevents mass-uploads. Yes, I did forget a
build-dependency, though that's still much nicer than living unstable
broken for days/weeks with the workflow you're both proposing.

If you still don't agree, let me know. I'd love to hear counter
arguments, or a solution if there's one.

Cheers,

Thomas Goirand (zigo)

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

[Ondrej Novy]

Hi,

2016-10-11 18:58 GMT+02:00 Thomas Goirand :

> It is impossible maintain 400+ interacting packages the way you would
> with your single pet package.
>

I don't see any problem using source-only upload for all OS packages.
buildd will wait for missed deps automatically and it's cross-check of your
work.

The only way I see to fix this, is deploying the same kind of CI/CD we
> have designed in the OpenStack infrastructure, but using Sid, and
>

this is not needed. We should use source-only upload, that's all. We
already have something like CI/CD - buildd with source-only uploads + repro
builds.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

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

[Thomas Goirand]

On 10/11/2016 05:41 PM, Santiago Vila wrote:
> On Tue, 11 Oct 2016, Thomas Goirand wrote:
> 
>> The problem was python-fixtures, which is maintained within the PKG
>> OpenStack, but for some reason, the Maintainer: field still has Robert
>> Collins, which is why it didn't appear in the PKG OpenStack QA page, and
>> I missed the upload to unstable.
> 
> That was really only half of the problem.
> 
> The other half was not building the package in a clean sid chroot.
> Hence my suggestion to always upload in source-only form.
> 
> Thanks.

Santiago,

Before throwing stone at me, you should consider the amount of package
we maintain within the OpenStack PKG group:
https://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org

It is impossible maintain 400+ interacting packages the way you would
with your single pet package.

For the every day work, I do build all of the OpenStack packages into a
clean Jessie chroot within the OpenStack CI (which produces a
jessie-backport repository) using Gerrit. All of that is automated.
Within that, I know that, within the subset of OpenStack packages,
(build-)dependencies are correct (there's no way to cheat this system).

I would very much like to build the same way for Sid, using sbuild also.
Unfortunately, given the fact that I need to manually trigger the
builds, and given the number of packages, it is not feasible within a
reasonable amount of time. And I really wanted the migration from
Experimental (containing OpenStack Newton) to Sid (which had OpenStack
Mitaka) to take the least amount of time, to avoid brokenness which such
move would inevitably do. The shortcut I took was the only way to move
all packages from Experimental to Unstable. I just wish we had
automation within Debian to do it, unfortunately, this isn't the case.

If considering all of the packages as a single set, everything is fine
though, and all (build-)dependencies are satisfied. Python-fixtures
really is an exception here, that I wouldn't have missed if it appeared
in the group's QA page.

The only way I see to fix this, is deploying the same kind of CI/CD we
have designed in the OpenStack infrastructure, but using Sid, and
allowing this to upload to the archive directly. It is one of the
projects I would like to achieve within Debian (and the DSA machines).
Hopefully, this will happen one day. I'm not sure if I'll succeed
convincing the FTP masters that it is safe to have a CI to upload
packages on the behalf of maintainers, but that's another story.

Hoping you enjoyed reading the insights,
Cheers,

Thomas Goirand (zigo)

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

[Santiago Vila]

On Tue, 11 Oct 2016, Thomas Goirand wrote:

> The problem was python-fixtures, which is maintained within the PKG
> OpenStack, but for some reason, the Maintainer: field still has Robert
> Collins, which is why it didn't appear in the PKG OpenStack QA page, and
> I missed the upload to unstable.

That was really only half of the problem.

The other half was not building the package in a clean sid chroot.
Hence my suggestion to always upload in source-only form.

Thanks.

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

[Thomas Goirand]

On 10/11/2016 04:46 PM, Santiago Vila wrote:
> In a sid chroot, please try:
> 
> apt-get install python-oslotest
> 
> and you will see why the package is unbuildable.
> 
> (Hopefully, you will also see why we all should be always doing
> source-only uploads).
> 
> Thanks.

Hi,

The problem was python-fixtures, which is maintained within the PKG
OpenStack, but for some reason, the Maintainer: field still has Robert
Collins, which is why it didn't appear in the PKG OpenStack QA page, and
I missed the upload to unstable.

This is fixed,
Cheers,

Thomas Goirand (zigo)

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

[Santiago Vila]

In a sid chroot, please try:

apt-get install python-oslotest

and you will see why the package is unbuildable.

(Hopefully, you will also see why we all should be always doing
source-only uploads).

Thanks.

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

[Thomas Goirand]

On 10/11/2016 02:26 PM, Santiago Vila wrote:
> Hmm, the package is currently unbuildable. This is what I got:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-aodh-dummy : Depends: python-oslotest (>= 1:1.5.1) but 
> it is not going to be installed

# rmadison --suite=unstable python-oslotest
python-oslotest | 1:2.10.0-2| unstable   | source, all

So it's really there. Are you building in Sid? Did you update your
chroot? Most packages were updated last week (I uploaded more than 200
times last week), so you should check you're up-to-date.

> and it's also in dep-wait state here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/aodh.html

I wonder if the mirror used by reproducible-builds.org is up-to-date.

Cheers,

Thomas Goirand (zigo)

Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Santiago Vila]

Hmm, the package is currently unbuildable. This is what I got:

The following packages have unmet dependencies:
 sbuild-build-depends-aodh-dummy : Depends: python-oslotest (>= 1:1.5.1) but it 
is not going to be installed

and it's also in dep-wait state here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/aodh.html

[ This is why I prefer building packages in testing, among other things... ]

Thanks.

Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Santiago Vila]

On Mon, 10 Oct 2016, Thomas Goirand wrote:

> I have uploaded what I believe is a fix for #835177. Though as I am not
> sure how to reproduce your build env, it'd be really nice if you could
> try to build aodh 3.0.0-2 and check that the bug is really closed.
> 
> If that is the case (that my change fixes the FTBFS of aodh in your
> env), then I will apply the same kind of fix for #835178 and #835179.

Ok, triggered builds for aodh in sid (with and without eatmydata).

Will let you know about the results in a few hours...

In either case, please note that my build environment is not special
at all. For this bug report, it's just sbuild + eatmydata, on a single
CPU virtual machine, and that's all.

To use sbuild + eatmydata, you just need a file
/etc/schroot/chroot.d/stretch like this:

[stretch]
type=directory
description=Debian stretch
directory=/chroot/stretch
groups=sbuild
root-groups=sbuild
preserve-environment=true
command-prefix=eatmydata

(To prevent a chichen-and-egg problem, eatmydata has to be installed
before you can use the last line saying command-prefix...)

In my experience, when eatmydata is to blame for a build failure, it
usually fails always (i.e. this is not one of those difficult random
build failures).

Thanks.

Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Thomas Goirand]

Hi Santiago,

I have uploaded what I believe is a fix for #835177. Though as I am not
sure how to reproduce your build env, it'd be really nice if you could
try to build aodh 3.0.0-2 and check that the bug is really closed.

If that is the case (that my change fixes the FTBFS of aodh in your
env), then I will apply the same kind of fix for #835178 and #835179.

Thanks a lot if you can help here,
Cheers,

Thomas Goirand (zigo)

Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Santiago Vila]

Package: src:aodh
Version: 2.0.0-2
Severity: wishlist

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep  --with python2,systemd,sphinxdoc
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions

[... snipped ...]

warning: no previously-included files matching '*.pyc' found anywhere in 
distribution
writing manifest file 'aodh.egg-info/SOURCES.txt'
/usr/share/openstack-pkg-tools/pkgos_insert_include pkgos_func 
aodh-common.config
/usr/share/openstack-pkg-tools/pkgos_insert_include pkgos_func 
aodh-common.postinst
/usr/share/openstack-pkg-tools/pkgos_insert_include pkgos_func aodh-api.config
/usr/share/openstack-pkg-tools/pkgos_insert_include pkgos_func aodh-api.postinst
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
rm -rf .testrepository
testr init
set -e ; \
TEMP_REZ=`mktemp -t` ; \
bash -x ./debian/setup-test-env-mongodb.sh testr run --subunit 
'aodh\.tests\.unit\.(?!.*test_bin.*)' | tee $TEMP_REZ | subunit2pyunit ; \
cat $TEMP_REZ | subunit-filter -s --no-passthrough | subunit-stats ; \
rm -f $TEMP_REZ ;
+ set -e
+ source functions.sh
+ '[' testr = --coverage ']'
+ export 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/sbin:/usr/sbin
+ 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/sbin:/usr/sbin
+ check_for_cmd mongod
+ which mongod
++ mktemp -d /tmp/AODH-MONGODB-X
+ MONGO_DATA=/tmp/AODH-MONGODB-GzbuK
+ MONGO_PORT=29000
+ trap 'clean_exit /tmp/AODH-MONGODB-GzbuK' EXIT
+ mkfifo /tmp/AODH-MONGODB-GzbuK/out
+ wait_for_line 'waiting for connections on port 29000' 
/tmp/AODH-MONGODB-GzbuK/out
+ mongod --maxConns 32 --nojournal --noprealloc --smallfiles --quiet --noauth 
--port 29000 --dbpath /tmp/AODH-MONGODB-GzbuK --bind_ip localhost --config 
/dev/null
+ read line
functions.sh: line 1: 30608 Terminated  mongod --maxConns 32 
--nojournal --noprealloc --smallfiles --quiet --noauth --port ${MONGO_PORT} 
--dbpath "${MONGO_DATA}" --bind_ip localhost --config /dev/null &> 
${MONGO_DATA}/out
++ clean_exit /tmp/AODH-MONGODB-GzbuK
++ local error_code=0
++ rm -rf /tmp/AODH-MONGODB-GzbuK
make[1]: *** wait: No child processes.  Stop.
make[1]: *** Waiting for unfinished jobs
make[1]: *** wait: No child processes.  Stop.
make: *** wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No child processes.  Stop.
+++ jobs -p
++ kill
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill 
-l [sigspec]
E: Build killed with signal TERM after 60 minutes of inactivity


The build was made with eatmydata. When I don't use eatmydata, it builds ok
(but it takes a lot more time to build).

Can you confirm that eatmydata is the reason for the failures
and / or forward this upstream?

I'm currently checking that "dpkg-buildpackage -A" always work, and
the ability to use eatmydata is a real time and disk I/O saver.

I attach three different build logs.

Thanks.

aodh_2.0.0-2_amd64-20160809T1459Z.gz
Description: application/gzip


aodh_2.0.0-2_amd64-20160817T2002Z.gz
Description: application/gzip


aodh_2.0.0-2_amd64-20160822T225302Z.gz
Description: application/gzip