9:03 a.m.
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
4:40 p.m.
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
4:44 p.m.
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
4:58 p.m.
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
5:15 a.m.
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
11:19 a.m.
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
1:46 p.m.
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(a)lists.fedoraproject.org To unsubscribe send an email to
devel-leave(a)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
7:21 a.m.
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
2:43 a.m.
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
356
days inactive
359
days old
8 comments
4 participants
participants (4)
-
Kevin Fenzi -
Mattia Verga -
Miro Hrončok -
Zbigniew Jędrzejewski-Szmek