Re: How to drop 32bit support from the scientific Python stack
On 05. 05. 23 18:19, Kevin Fenzi wrote: On Fri, May 05, 2023 at 12:15:31PM +0200, Miro Hrončok wrote: On 04. 05. 23 23:58, Kevin Fenzi wrote: On Thu, May 04, 2023 at 11:44:33PM +0200, Miro Hrončok wrote: On 04. 05. 23 23:40, Kevin Fenzi wrote: On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: Hello folks, ...snip... Would that be possible? I don't think it currently is... but sounds like a reasonable RFE to koji to me. The way koji handles noarch packages is that it builds them on all arches, checks to make sure they are all the same and just picks one to be the 'output' build. This is true for noarch subpackages of arched packages. For fully noarch packages, it just builds them on one architecture. Yep. You are correct, sorry for confusing the issue there. I still think it could be something that koji would let us do. When Koji triggers a noarch build job, it somehow knows it can select *any* builder we have. Is this a matter of our configuration or upstream code? As far as I can tell, upstream. I could be missing something, but I think noarch tasks just get the 'default' channel and any builder from any arch thats in it. E.g. do I need to file an issue at pagure.io/koji or infra or releng? Upstream pagure.io/koji. If I am missing something and we can do it in config they should be able to tell us. ;) -> https://pagure.io/koji/issue/3809 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to drop 32bit support from the scientific Python stack
On Thu, May 04, 2023 at 02:40:41PM -0700, Kevin Fenzi wrote: > On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: > > Hello folks, > ...snip... > > > > Would that be possible? > > I don't think it currently is... but sounds like a reasonable RFE to > koji to me. > > The way koji handles noarch packages is that it builds them on all > arches, checks to make sure they are all the same and just picks one to > be the 'output' build. > > I think it would make sense to let us exclude some arch in this case > (i686). I mean normally you would want it to do all arches or it could > be completely broken on some, but in this case since we only keep i686 > around as a multiarch thing, it shouldn't matter. Yes, please! If we got this working, it'd also be useful in other cases. And the good thing is that it would be self-contained within koji: koji picks some builder, and we just tweak the rules of how that builder is picked. This wouldn't "leak" into other layers. The alternative of modifying hundreds of packages is much worse. > I guess the only downside I see is that it might be confusing if there's > someone who manually installs some noarch package on a i686 install and > it breaks. As already written in the other replies, this is already possible to some extent and is not much of a problem. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to drop 32bit support from the scientific Python stack
There is already an ancient similar request upstream with some hints how to achieve that (it was to disable s390 buikders for noarch packages, though): https://pagure.io/koji/issue/2229 Inviato da Proton Mail mobile Messaggio originale Il 5 Mag 2023, 18:19, Kevin Fenzi ha scritto: > On Fri, May 05, 2023 at 12:15:31PM +0200, Miro Hrončok wrote: > On 04. 05. 23 > 23:58, Kevin Fenzi wrote: > > On Thu, May 04, 2023 at 11:44:33PM +0200, Miro > Hrončok wrote: > > > On 04. 05. 23 23:40, Kevin Fenzi wrote: > > > > On Thu, > May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: > > > > > Hello folks, > > > > > ...snip... > > > > > Would that be possible? > > > > I don't think it > currently is... but sounds like a reasonable RFE to > > > > koji to me. > > > > > > > > > The way koji handles noarch packages is that it builds them on all > > > > > arches, checks to make sure they are all the same and just picks one > to > > > > be the 'output' build. > > > This is true for noarch subpackages > of arched packages. > > > > > > For fully noarch packages, it just builds > them on one architecture. > > Yep. You are correct, sorry for confusing the > issue there. > > > > I still think it could be something that koji would let > us do. > > When Koji triggers a noarch build job, it somehow knows it can > select *any* > builder we have. Is this a matter of our configuration or > upstream code? As far as I can tell, upstream. I could be missing something, > but I think noarch tasks just get the 'default' channel and any builder from > any arch thats in it. > E.g. do I need to file an issue at pagure.io/koji or > infra or releng? Upstream pagure.io/koji. If I am missing something and we > can do it in config they should be able to tell us. ;) kevin > ___ devel mailing list -- > devel@lists.fedoraproject.org To unsubscribe send an email to > devel-le...@lists.fedoraproject.org Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to drop 32bit support from the scientific Python stack
On Fri, May 05, 2023 at 12:15:31PM +0200, Miro Hrončok wrote: > On 04. 05. 23 23:58, Kevin Fenzi wrote: > > On Thu, May 04, 2023 at 11:44:33PM +0200, Miro Hrončok wrote: > > > On 04. 05. 23 23:40, Kevin Fenzi wrote: > > > > On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: > > > > > Hello folks, > > > > ...snip... > > > > > Would that be possible? > > > > I don't think it currently is... but sounds like a reasonable RFE to > > > > koji to me. > > > > > > > > The way koji handles noarch packages is that it builds them on all > > > > arches, checks to make sure they are all the same and just picks one to > > > > be the 'output' build. > > > This is true for noarch subpackages of arched packages. > > > > > > For fully noarch packages, it just builds them on one architecture. > > Yep. You are correct, sorry for confusing the issue there. > > > > I still think it could be something that koji would let us do. > > When Koji triggers a noarch build job, it somehow knows it can select *any* > builder we have. Is this a matter of our configuration or upstream code? As far as I can tell, upstream. I could be missing something, but I think noarch tasks just get the 'default' channel and any builder from any arch thats in it. > E.g. do I need to file an issue at pagure.io/koji or infra or releng? Upstream pagure.io/koji. If I am missing something and we can do it in config they should be able to tell us. ;) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to drop 32bit support from the scientific Python stack
On 04. 05. 23 23:58, Kevin Fenzi wrote: On Thu, May 04, 2023 at 11:44:33PM +0200, Miro Hrončok wrote: On 04. 05. 23 23:40, Kevin Fenzi wrote: On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: Hello folks, ...snip... Would that be possible? I don't think it currently is... but sounds like a reasonable RFE to koji to me. The way koji handles noarch packages is that it builds them on all arches, checks to make sure they are all the same and just picks one to be the 'output' build. This is true for noarch subpackages of arched packages. For fully noarch packages, it just builds them on one architecture. Yep. You are correct, sorry for confusing the issue there. I still think it could be something that koji would let us do. When Koji triggers a noarch build job, it somehow knows it can select *any* builder we have. Is this a matter of our configuration or upstream code? E.g. do I need to file an issue at pagure.io/koji or infra or releng? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to drop 32bit support from the scientific Python stack
On Thu, May 04, 2023 at 11:44:33PM +0200, Miro Hrončok wrote: > On 04. 05. 23 23:40, Kevin Fenzi wrote: > > On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: > > > Hello folks, > > ...snip... > > > > > > Would that be possible? > > > > I don't think it currently is... but sounds like a reasonable RFE to > > koji to me. > > > > The way koji handles noarch packages is that it builds them on all > > arches, checks to make sure they are all the same and just picks one to > > be the 'output' build. > > This is true for noarch subpackages of arched packages. > > For fully noarch packages, it just builds them on one architecture. Yep. You are correct, sorry for confusing the issue there. I still think it could be something that koji would let us do. > > I think it would make sense to let us exclude some arch in this case > > (i686). I mean normally you would want it to do all arches or it could > > be completely broken on some, but in this case since we only keep i686 > > around as a multiarch thing, it shouldn't matter. > > > > I guess the only downside I see is that it might be confusing if there's > > someone who manually installs some noarch package on a i686 install and > > it breaks. > > This can still happen today anyway, if the package was built and tested on > different arch or if it doesn't run tests at all. yep. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to drop 32bit support from the scientific Python stack
On 04. 05. 23 23:40, Kevin Fenzi wrote: On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: Hello folks, ...snip... Would that be possible? I don't think it currently is... but sounds like a reasonable RFE to koji to me. The way koji handles noarch packages is that it builds them on all arches, checks to make sure they are all the same and just picks one to be the 'output' build. This is true for noarch subpackages of arched packages. For fully noarch packages, it just builds them on one architecture. I think it would make sense to let us exclude some arch in this case (i686). I mean normally you would want it to do all arches or it could be completely broken on some, but in this case since we only keep i686 around as a multiarch thing, it shouldn't matter. I guess the only downside I see is that it might be confusing if there's someone who manually installs some noarch package on a i686 install and it breaks. This can still happen today anyway, if the package was built and tested on different arch or if it doesn't run tests at all. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to drop 32bit support from the scientific Python stack
On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: > Hello folks, ...snip... > > Would that be possible? I don't think it currently is... but sounds like a reasonable RFE to koji to me. The way koji handles noarch packages is that it builds them on all arches, checks to make sure they are all the same and just picks one to be the 'output' build. I think it would make sense to let us exclude some arch in this case (i686). I mean normally you would want it to do all arches or it could be completely broken on some, but in this case since we only keep i686 around as a multiarch thing, it shouldn't matter. I guess the only downside I see is that it might be confusing if there's someone who manually installs some noarch package on a i686 install and it breaks. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
How to drop 32bit support from the scientific Python stack
Hello folks, Couple months ago, we discussed with @psimovec if it's possible to ExcludeArch i686 from scipy. This Python discussion brought the topic back: https://discuss.python.org/t/dropping-32-bit-packages/5476/9 I've tried to see how many packages would be affected and the short answer is: all of them, unless we break the dependency chains somewhere. There are many deep transitive build dependency chains on scipy, but the perhaps most interesting one is: (everything) <- rpm <- rust-rpm-sequoia <- rust-packaging <- pytest <- python-hypothesis <- python-pandas <- scipy Another interesting fact is that the majority of the dependency chains I found traverses through a path of noarch Python packages (such as pytest). If scipy drops i686 we would need to conditionalize the test-related BuildRequires of such noarch packages -- unfortunately that would mean that based on randomness (noarch packages are built on random archotcture), not all tests would always run and we could potentially ship packages that are broken / untested properly. And if we don't conditionalize the dependencies, the packages would randomly fail to build. An alternative is to make all the related packages archful with noarch python3-xxx subpackages -- which would be quite tedious and wasteful resource-wise. The best way forward for this use case (and many others that will show up sooner or later) would be to stop building noarch packages on i686. That way, only archful packages that (Build)Require scipy would need to be changed. Would that be possible? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
How to drop 32bit support from the scientific Python stack
Hello folks, Couple months ago, we discussed with @psimovec if it's possible to ExcludeArch i686 from scipy. This Python discussion brought the topic back: https://discuss.python.org/t/dropping-32-bit-packages/5476/9 I've tried to see how many packages would be affected and the short answer is: all of them, unless we break the dependency chains somewhere. There are many deep transitive build dependency chains on scipy, but the perhaps most interesting one is: (everything) <- rpm <- rust-rpm-sequoia <- rust-packaging <- pytest <- python-hypothesis <- python-pandas <- scipy Another interesting fact is that the majority of the dependency chains I found traverses through a path of noarch Python packages (such as pytest). If scipy drops i686 we would need to conditionalize the test-related BuildRequires of such noarch packages -- unfortunately that would mean that based on randomness (noarch packages are built on random archotcture), not all tests would always run and we could potentially ship packages that are broken / untested properly. And if we don't conditionalize the dependencies, the packages would randomly fail to build. An alternative is to make all the related packages archful with noarch python3-xxx subpackages -- which would be quite tedious and wasteful resource-wise. The best way forward for this use case (and many others that will show up sooner or later) would be to stop building noarch packages on i686. That way, only archful packages that (Build)Require scipy would need to be changed. Would that be possible? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
