Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Hi Dirk On Thu, 20 Jun 2024 at 12:17, Dirk Eddelbuettel wrote: > It is a (very) big package, but it has not grown much lately. Not being able > to build may lead to auto-removal which is bad, excluding an architecture is > also not good. Not clear what the least bad move is here... I think the thing to do here is file a bug against ftp.debian.org and request removal of the quantlib-python binary package on riscv64. There's no need for a new upload of quantlib-swig with the architectures restricted. This way, users of testing get the new version right away, and should the riscv64 build succeed later, it will automatically become available there too. Regards Graham
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Hi Dirk, On 20-06-2024 2:17 p.m., Dirk Eddelbuettel wrote: It is a (very) big package, but it has not grown much lately. Not being able to build may lead to auto-removal which is bad, excluding an architecture is also not good. Not clear what the least bad move is here... You might be aware, but pinging the bug resets the removal timer (if not done mere hours before the actual removal). So if you intent to keep the architecture supported and you and/or the riscv64 porters are working on it, feel free to keep pinging the bug to prevent removal. If nobody finds a solution keeping riscv64, removing the architecture is a good solution. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
On 20 June 2024 at 12:16, Bo YU wrote: | hi, | | On Mon, Jun 17, 2024 at 7:16 AM Bo YU wrote: | > | > Hi, | > | > On Mon, Jun 17, 2024 at 6:41 AM Dirk Eddelbuettel wrote: | > > | > > | > > Hi Paul, | > > | > > Thanks for the prompt and detailed reply. | > > | > > On 16 June 2024 at 16:13, Paul Gevers wrote: | > > | Hi Dirk, | > > | | > > | On 16-06-2024 2:42 p.m., Dirk Eddelbuettel wrote: | > > | > I may need a hgand with riscv64. | > > | | > > | That's normally a question to the porters, in CC now, so they can have a | > > | look. | > > | | > > | > The 1.34-1 revision needed some build | > > | > changes I had done poorly in such a way that the -O0 no longer applied to | > > | > some arches, this has been fixed in 1.34-2 so armel, armhf, i386 are good. | > > | > But riskv64 still times out. | > > | | > > | Ack. | > > | | > > | > Can we expand the build-time window from the | > > | > (arguably already large) value? | > > | | > > | Not that I know of. | > > | | > > | > Or can we (worst case) turn riskv64 builds | > > | > off? | > > | | > > | That's up to you as a maintainer, but this should be last resort [1]. | > > | Don't forget to request for removal of the existing riscv64 binaries if | > > | you go this route. Please be aware of [2] if you aren't already. | > > | > > True true, and I think I had to pull this 'safety value' once or twice before | > > with challenging / large package. I will re-read [1] and [2] and ponder. | > > | > > riscv64 porters: I would of course also love to hear if you can offer any | > > advice. The package is a tricky one as it contains (a lot of) heavily | > > templated C++ code that is autogenerated via Swig for these Python | > > bindings. The compilation of that one file is tricky. | > > | | I am always trying to build it on my local Unmatched boards with many | attempts. But unfortunately, they all failed so far and each building | will last > 1d.:( | | But this does not mean it does not work on riscv. On sg2042, it can be built: | ``` | Build Architecture: riscv64 | Build Type: binary | Build-Space: 1463468 | Build-Time: 21213 | Distribution: unstable | Host Architecture: riscv64 | Install-Time: 88 | Job: /home/vimer/ftbfs/quantlib-swig/quantlib-swig_1.34-2.dsc | Lintian: warn | Machine Architecture: riscv64 | Package: quantlib-swig | Package-Time: 21368 | Source-Version: 1.34-2 | Space: 1463468 | Status: successful | Version: 1.34-2 | | Finished at 2024-06-19T21:08:10Z | Build needed 05:56:08, 1463468k disk space | ``` | I am looking at other optimization methods, but this will take more time again. Thank you! It is a (very) big package, but it has not grown much lately. Not being able to build may lead to auto-removal which is bad, excluding an architecture is also not good. Not clear what the least bad move is here... Dirk | BR, | Bo | | | | > Okay, I will have a look at this package. | > | > After a quick look, there are a lot of architecture-related build | > flags here, so I might start there first. | > | > BR, | > Bo | > > Best, Dirk | > > | > > | Paul | > > | | > > | [1] https://release.debian.org/testing/rc_policy.txt : Packages must be | > > | supported on as many architectures as is *reasonably* possible. | > > | (Emphasis mine). | > > | [2] https://lists.debian.org/debian-devel/2022/09/msg00105.html | > > | [DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] | > > | > > -- | > > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > > -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
hi, On Mon, Jun 17, 2024 at 7:16 AM Bo YU wrote: > > Hi, > > On Mon, Jun 17, 2024 at 6:41 AM Dirk Eddelbuettel wrote: > > > > > > Hi Paul, > > > > Thanks for the prompt and detailed reply. > > > > On 16 June 2024 at 16:13, Paul Gevers wrote: > > | Hi Dirk, > > | > > | On 16-06-2024 2:42 p.m., Dirk Eddelbuettel wrote: > > | > I may need a hgand with riscv64. > > | > > | That's normally a question to the porters, in CC now, so they can have a > > | look. > > | > > | > The 1.34-1 revision needed some build > > | > changes I had done poorly in such a way that the -O0 no longer applied > > to > > | > some arches, this has been fixed in 1.34-2 so armel, armhf, i386 are > > good. > > | > But riskv64 still times out. > > | > > | Ack. > > | > > | > Can we expand the build-time window from the > > | > (arguably already large) value? > > | > > | Not that I know of. > > | > > | > Or can we (worst case) turn riskv64 builds > > | > off? > > | > > | That's up to you as a maintainer, but this should be last resort [1]. > > | Don't forget to request for removal of the existing riscv64 binaries if > > | you go this route. Please be aware of [2] if you aren't already. > > > > True true, and I think I had to pull this 'safety value' once or twice > > before > > with challenging / large package. I will re-read [1] and [2] and ponder. > > > > riscv64 porters: I would of course also love to hear if you can offer any > > advice. The package is a tricky one as it contains (a lot of) heavily > > templated C++ code that is autogenerated via Swig for these Python > > bindings. The compilation of that one file is tricky. > > I am always trying to build it on my local Unmatched boards with many attempts. But unfortunately, they all failed so far and each building will last > 1d.:( But this does not mean it does not work on riscv. On sg2042, it can be built: ``` Build Architecture: riscv64 Build Type: binary Build-Space: 1463468 Build-Time: 21213 Distribution: unstable Host Architecture: riscv64 Install-Time: 88 Job: /home/vimer/ftbfs/quantlib-swig/quantlib-swig_1.34-2.dsc Lintian: warn Machine Architecture: riscv64 Package: quantlib-swig Package-Time: 21368 Source-Version: 1.34-2 Space: 1463468 Status: successful Version: 1.34-2 Finished at 2024-06-19T21:08:10Z Build needed 05:56:08, 1463468k disk space ``` I am looking at other optimization methods, but this will take more time again. BR, Bo > Okay, I will have a look at this package. > > After a quick look, there are a lot of architecture-related build > flags here, so I might start there first. > > BR, > Bo > > Best, Dirk > > > > | Paul > > | > > | [1] https://release.debian.org/testing/rc_policy.txt : Packages must be > > | supported on as many architectures as is *reasonably* possible. > > | (Emphasis mine). > > | [2] https://lists.debian.org/debian-devel/2022/09/msg00105.html > > | [DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] > > > > -- > > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > >
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Hi, On Mon, Jun 17, 2024 at 6:41 AM Dirk Eddelbuettel wrote: > > > Hi Paul, > > Thanks for the prompt and detailed reply. > > On 16 June 2024 at 16:13, Paul Gevers wrote: > | Hi Dirk, > | > | On 16-06-2024 2:42 p.m., Dirk Eddelbuettel wrote: > | > I may need a hgand with riscv64. > | > | That's normally a question to the porters, in CC now, so they can have a > | look. > | > | > The 1.34-1 revision needed some build > | > changes I had done poorly in such a way that the -O0 no longer applied to > | > some arches, this has been fixed in 1.34-2 so armel, armhf, i386 are good. > | > But riskv64 still times out. > | > | Ack. > | > | > Can we expand the build-time window from the > | > (arguably already large) value? > | > | Not that I know of. > | > | > Or can we (worst case) turn riskv64 builds > | > off? > | > | That's up to you as a maintainer, but this should be last resort [1]. > | Don't forget to request for removal of the existing riscv64 binaries if > | you go this route. Please be aware of [2] if you aren't already. > > True true, and I think I had to pull this 'safety value' once or twice before > with challenging / large package. I will re-read [1] and [2] and ponder. > > riscv64 porters: I would of course also love to hear if you can offer any > advice. The package is a tricky one as it contains (a lot of) heavily > templated C++ code that is autogenerated via Swig for these Python > bindings. The compilation of that one file is tricky. > Okay, I will have a look at this package. After a quick look, there are a lot of architecture-related build flags here, so I might start there first. BR, Bo > Best, Dirk > > | Paul > | > | [1] https://release.debian.org/testing/rc_policy.txt : Packages must be > | supported on as many architectures as is *reasonably* possible. > | (Emphasis mine). > | [2] https://lists.debian.org/debian-devel/2022/09/msg00105.html > | [DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Hi Paul, Thanks for the prompt and detailed reply. On 16 June 2024 at 16:13, Paul Gevers wrote: | Hi Dirk, | | On 16-06-2024 2:42 p.m., Dirk Eddelbuettel wrote: | > I may need a hgand with riscv64. | | That's normally a question to the porters, in CC now, so they can have a | look. | | > The 1.34-1 revision needed some build | > changes I had done poorly in such a way that the -O0 no longer applied to | > some arches, this has been fixed in 1.34-2 so armel, armhf, i386 are good. | > But riskv64 still times out. | | Ack. | | > Can we expand the build-time window from the | > (arguably already large) value? | | Not that I know of. | | > Or can we (worst case) turn riskv64 builds | > off? | | That's up to you as a maintainer, but this should be last resort [1]. | Don't forget to request for removal of the existing riscv64 binaries if | you go this route. Please be aware of [2] if you aren't already. True true, and I think I had to pull this 'safety value' once or twice before with challenging / large package. I will re-read [1] and [2] and ponder. riscv64 porters: I would of course also love to hear if you can offer any advice. The package is a tricky one as it contains (a lot of) heavily templated C++ code that is autogenerated via Swig for these Python bindings. The compilation of that one file is tricky. Best, Dirk | Paul | | [1] https://release.debian.org/testing/rc_policy.txt : Packages must be | supported on as many architectures as is *reasonably* possible. | (Emphasis mine). | [2] https://lists.debian.org/debian-devel/2022/09/msg00105.html | [DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Hi Dirk, On 16-06-2024 2:42 p.m., Dirk Eddelbuettel wrote: I may need a hgand with riscv64. That's normally a question to the porters, in CC now, so they can have a look. The 1.34-1 revision needed some build changes I had done poorly in such a way that the -O0 no longer applied to some arches, this has been fixed in 1.34-2 so armel, armhf, i386 are good. But riskv64 still times out. Ack. Can we expand the build-time window from the (arguably already large) value? Not that I know of. Or can we (worst case) turn riskv64 builds off? That's up to you as a maintainer, but this should be last resort [1]. Don't forget to request for removal of the existing riscv64 binaries if you go this route. Please be aware of [2] if you aren't already. Paul [1] https://release.debian.org/testing/rc_policy.txt : Packages must be supported on as many architectures as is *reasonably* possible. (Emphasis mine). [2] https://lists.debian.org/debian-devel/2022/09/msg00105.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Paul, Graham, I may need a hgand with riscv64. The 1.34-1 revision needed some build changes I had done poorly in such a way that the -O0 no longer applied to some arches, this has been fixed in 1.34-2 so armel, armhf, i386 are good. But riskv64 still times out. Can we expand the build-time window from the (arguably already large) value? Or can we (worst case) turn riskv64 builds off? The package risks an autorm on July 4 unless we find 'some way' for this. https://tracker.debian.org/pkg/quantlib-swig https://buildd.debian.org/status/package.php?p=quantlib-swig Thanks, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
On 5 June 2024 at 21:57, Paul Gevers wrote: | Source: quantlib-swig | Version: 1.33-1 | Severity: serious | Control: close -1 1.34-1 | Tags: sid trixie ftbfs | User: release.debian@packages.debian.org | Usertags: out-of-sync | | Dear maintainer(s), | | The Release Team considers packages that are out-of-sync between testing | and unstable for more than 30 days as having a Release Critical bug in | testing [1]. Your package src:quantlib-swig has been trying to migrate | for 40 days [2]. Hence, I am filing this bug. The version in unstable | failed to build on armel, armhf, i386 and riscv64. | | 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 trixie, 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. I have seen this, and I am torn. Maybe it is just best to let quantlib-swig die and keep keep just quantlib (the C++ library). Dirk | Paul | | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html | [2] https://qa.debian.org/excuses.php?package=quantlib-swig | | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Source: quantlib-swig Version: 1.33-1 Severity: serious Control: close -1 1.34-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:quantlib-swig has been trying to migrate for 40 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel, armhf, i386 and riscv64. 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 trixie, 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/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=quantlib-swig OpenPGP_signature.asc Description: OpenPGP digital signature
