Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Hi Paul, On 28 May 2020 at 08:23, Paul Gevers wrote: | Hi Dirk, | | On 28-05-2020 01:14, Dirk Eddelbuettel wrote: | > Shall I close this one 'by hand'? Or will it get closed by migrating | > quantlib-swig? I just close the other one (#956830) that was at the start of | > this by hand. | | I closed the bug the moment I filed it. Albeit that's a bit weird, I | have multiple reasons to do that (I use a template for these bugs): | | - The Release Team considers the version in TESTING from having an RC | issue. So, the version in unstable is fine, and if it migrates, the | Release Team's concern is addressed. | | - If the package migrates without a new upload, it's easy for the | maintainer to forget to close the issue. Then we need manual actions to | close it, or QA needs to find these unclosed bugs later. The BTS doesn't | archive unclosed bugs. Strange. I could swear I saw it as open when looking from my QA page... Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Hi Dirk, On 28-05-2020 01:14, Dirk Eddelbuettel wrote: > Shall I close this one 'by hand'? Or will it get closed by migrating > quantlib-swig? I just close the other one (#956830) that was at the start of > this by hand. I closed the bug the moment I filed it. Albeit that's a bit weird, I have multiple reasons to do that (I use a template for these bugs): - The Release Team considers the version in TESTING from having an RC issue. So, the version in unstable is fine, and if it migrates, the Release Team's concern is addressed. - If the package migrates without a new upload, it's easy for the maintainer to forget to close the issue. Then we need manual actions to close it, or QA needs to find these unclosed bugs later. The BTS doesn't archive unclosed bugs. Paul signature.asc Description: OpenPGP digital signature
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Paul, Shall I close this one 'by hand'? Or will it get closed by migrating quantlib-swig? I just close the other one (#956830) that was at the start of this by hand. Best, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Paul, Thanks for the hint. The package for mipsel is now gone, migration of quantlib-python should now resume. Leaves the second part. Come to think about it I have never written an debian/rules to _not_ build something. So maybe something like ifneq "$(findstring $(cpu), mipsel)" "" exit 1 endif in the build-arch == build-indep == build target? Are there examples I could look at? Thanks again, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Hi Paul, On 24 May 2020 at 20:31, Paul Gevers wrote: | Hi Dirk, | | On 24-05-2020 20:19, Dirk Eddelbuettel wrote: | > Hm. Easy to implement but won't it create a permanent 'fail' on that platform? | > (But then maybe that is the goal once I ask the release team to drop the old | > binary...) | | That's exactly what I meant. What did you think I meant? I was mostly thinking out loud chewing over how it can be seen as outright "sabotage" on the architecture ensuring success of a build. So it reflected my surprise. Nothing more. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Hi Dirk, On 24-05-2020 20:19, Dirk Eddelbuettel wrote: > Hm. Easy to implement but won't it create a permanent 'fail' on that platform? > (But then maybe that is the goal once I ask the release team to drop the old > binary...) That's exactly what I meant. What did you think I meant? Paul signature.asc Description: OpenPGP digital signature
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Hi Paul, On 24 May 2020 at 19:54, Paul Gevers wrote: | Hi Dirk, | | On 24-05-2020 19:09, Dirk Eddelbuettel wrote: | > But how I prevent the build in the future? | > | > Via 'Architecture: any [!xyx]' ? Last I checked I though we had no such | > explicit white/black listing mechanisms (but then I may have forgotten...) | | I also don't think blacklisting exists. I just checked policy and it Right. | doesn't mention anything like it. Instead of listing all archs except | for mipsel, I would just check the architecture in debian/rules and exit | non-zero if the architecture is mipsel. Hm. Easy to implement but won't it create a permanent 'fail' on that platform? (But then maybe that is the goal once I ask the release team to drop the old binary...) Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Hi Dirk, On 24-05-2020 19:09, Dirk Eddelbuettel wrote: > But how I prevent the build in the future? > > Via 'Architecture: any [!xyx]' ? Last I checked I though we had no such > explicit white/black listing mechanisms (but then I may have forgotten...) I also don't think blacklisting exists. I just checked policy and it doesn't mention anything like it. Instead of listing all archs except for mipsel, I would just check the architecture in debian/rules and exit non-zero if the architecture is mipsel. Paul signature.asc Description: OpenPGP digital signature
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
On 24 May 2020 at 18:47, Paul Gevers wrote: | Hi Dirk, | | On 24-05-2020 13:43, Dirk Eddelbuettel wrote: | > This used to build. It just takes a long as it is a library with old-school | > many templates "big C++". | > | > There is nothing I can do here. If it ends being removed because nobody can | > change the build toggle on that platform so be it. | > | > I understand the concern and agree with it. But there is nothing I think I | > can do. | | There is. If you think you can't reliably fix the issue, you can ask the | ftp-masters to remove the mipsel binary. Once the mipsel binary is gone, | the package can migrate. Please make sure that the binary isn't build by | accident in the future in that case. I can happily do either. But how I prevent the build in the future? Via 'Architecture: any [!xyx]' ? Last I checked I though we had no such explicit white/black listing mechanisms (but then I may have forgotten...) Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Hi Dirk, On 24-05-2020 13:43, Dirk Eddelbuettel wrote: > This used to build. It just takes a long as it is a library with old-school > many templates "big C++". > > There is nothing I can do here. If it ends being removed because nobody can > change the build toggle on that platform so be it. > > I understand the concern and agree with it. But there is nothing I think I > can do. There is. If you think you can't reliably fix the issue, you can ask the ftp-masters to remove the mipsel binary. Once the mipsel binary is gone, the package can migrate. Please make sure that the binary isn't build by accident in the future in that case. Paul signature.asc Description: OpenPGP digital signature
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
On 24 May 2020 at 07:57, Paul Gevers wrote: | Source: quantlib-swig | Version: 1.17-1 | Severity: serious | Control: close -1 1.18-1 | Tags: sid bullseye | User: release.debian@packages.debian.org | Usertags: out-of-sync | | Dear maintainer(s), | | As recently announced [1], the Release Team now considers packages that | are out-of-sync between testing and unstable for more than 60 days as | having a Release Critical bug in testing. Your package src:quantlib-swig | in its current version in unstable has been trying to migrate for 60 | days [2]. Hence, I am filing this bug. | | If a package is out of sync between unstable and testing for a longer | period, this usually means that bugs in the package in testing cannot be | fixed via unstable. Additionally, blocked packages can have impact on | other packages, which makes preparing for the release more difficult. | Finally, it often exposes issues with the package and/or | its (reverse-)dependencies. We expect maintainers to fix issues that | hamper the migration of their package in a timely manner. | | This bug will trigger auto-removal when appropriate. As with all new | bugs, there will be at least 30 days before the package is auto-removed. | | I have immediately closed this bug with the version in unstable, so if | that version or a later version migrates, this bug will no longer affect | testing. I have also tagged this bug to only affect sid and bullseye, so | it doesn't affect (old-)stable. | | If you believe your package is unable to migrate to testing due to | issues beyond your control, don't hesitate to contact the Release Team. It is. See the build logs: virtual memory exhausted: Cannot allocate memory error: command 'g++' failed with exit status 1 make: *** [debian/rules:101: build-stamp] Error 1 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 This used to build. It just takes a long as it is a library with old-school many templates "big C++". There is nothing I can do here. If it ends being removed because nobody can change the build toggle on that platform so be it. I understand the concern and agree with it. But there is nothing I think I can do. Dirk | Paul | | [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html | [2] https://qa.debian.org/excuses.php?package=quantlib-swig | | | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel
Source: quantlib-swig Version: 1.17-1 Severity: serious Control: close -1 1.18-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:quantlib-swig in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=quantlib-swig signature.asc Description: OpenPGP digital signature
