[Python-modules-team] Bug#836585: celery: FTBFS in testing (failing tests)

Michael Fladischer fladi at debian.org
Wed Sep 14 11:06:43 UTC 2016


On 2016-09-14 12:08, Santiago Vila wrote:
> (The "some hint" thing I surely did: I clearly put "testing" in the
> subject and "stretch" in the body).

I did notice this and as I commented when lowering the severity, I used
a testing buildroot with cowbuilder accordingly.

> For completeness, here is a build log that was created the same day I
> reported this, so you can check that this problem was indeed real.
> 
> I didn't include it in the initial report for two reasons:
> 
> * The bug was very easy to reproduce in testing and it was not a
> random FTBFS bug at all.
> 
> * I naively thought, being a FTBFS bug, that you would try to
> reproduce it sooner. I reported this on 2016-09-04 and the first reply
> from Paul was on 2016-09-13.

You do realize that I'm a volunteer and therefore offer up my spare time
to work on those packages. One of the implications of this is that I'm
not always able to jump immediately when someone files a bugreport,
regardless if it's RC or not. Daily job and personal life comes first.
Please be patient with people.

> This was already diagnosed by Paul and it was due to the
> python-openssl package in testing at the time not being ok to build
> the celery package in testing at the time.
> 
> So this problem happened in stretch at least between 2016-09-04 and
> 2016-09-09, the last date being the time pyopenssl 16.1.0-1 migrated
> to testing.
> 
> In case you still want to verify the problem, you can use
> snapshot.debian.org and try building with python-openssl 16.0.0-2.

I don't think anyone thought that your report was not based on hard
facts, it was just that once Paul did his rebuild, a newer
python-openssl has already migrated to testing.

I could have reassigned the bug to python-openssl and annoy its
maintainer with a bugreport that would have to be closed there. But I
decided not to.

> So: It is really so much work to add a versioned build-depends?
> (I see that a lot of them are already versioned).
> 
> We really *never* use versioned build-depends to avoid FTBFS bugs
> as some people claim?

To me, versioned dependencies were used to prevent FTBFS in unstable.
But you have a point here, I'll probably add a version constraint to
python-openssl in my next upload to unstable.

> Agreed, this does not happen anymore in stretch (I assure you that it
> did when I reported it), but the source package claims buildability
> with the build-dependencies shown in the build-depends field in the
> control file, so it may be argued this is still a bug in the source
> package. What about Ubuntu or any other Debian-derived distro which
> forks unstable and not testing?

Someone on debian-devel mentioned checking for passing builds before
migration packages to testing … maybe this is the way to go.

Cheers,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/python-modules-team/attachments/20160914/48c48c47/attachment.sig>


More information about the Python-modules-team mailing list