On Wed, 14 Sep 2016, Michael Fladischer wrote: > close 836585 > thanks > > Santiago, please provide full build logs and some hint on how you tried your > rebuild the next time you do some sort of MBF. This would have spared > maintainers > a lot of trouble and time.
You are right and I'm sorry if the lack of a build log caused you any trouble. (The "some hint" thing I surely did: I clearly put "testing" in the subject and "stretch" in the body). 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. 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. 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? 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? Thanks a lot.
celery_3.1.23-5_amd64-20160904T091402Z.gz
Description: application/gzip