On 2/6/25 18:38, Elliott Sales de Andrade wrote:
On Thu, Feb 6, 2025 at 8:09 PM Orion Poplawski <orion@xxxxxxxx> wrote:
python-cramjam dropped i686 with this:
commit 3ebdbdac596b6f01c97b89d3b67635519b10b944
Author: Benjamin A. Beasley <code@xxxxxxxxxxxxxxxxxx>
Date: Mon Sep 30 19:24:11 2024 -0400
F41+: Drop i686 support (leaf package on that architecture)
While many packages depend on this one, we believe we have correctly
verified that all directly or indirectly dependent packages either are
noarch or already exclude i686.
However, we are now seeing a build failure on i686 for python-pymongo:
DEBUG util.py:459: Problem: conflicting requests
DEBUG util.py:459: - nothing provides python3.13dist(cramjam) needed
by python3-snappy-0.7.2-4.fc42.noarch from build
So, apparently this determination was in error, or pymongo grew some deps.
The last build was 4.2.0 for the F41 Mass Rebuild:
https://src.fedoraproject.org/rpms/python-pymongo/c/df1367fd4fb442e0a31d7163db9e125d3a642654?branch=rawhide
Then it was updated to 4.9.1 5 months ago:
https://src.fedoraproject.org/rpms/python-pymongo/pull-request/8
And this PR also added %check. But this was never built until the F42
Mass Rebuild:
https://src.fedoraproject.org/rpms/python-pymongo/c/d4e8c56a38bbc7553cb842383b3ddfaaca047d68?branch=rawhide
There appears to be no mention of cramjam within that range:
https://github.com/mongodb/mongo-python-driver/compare/4.2.0...4.9.1
Looking at the log from x86_64, python3-cramjam is not a direct dependency.:
https://fedora.softwarefactory-project.io/zuul/build/b58460c63cd9495ead1737d9500d866c/log/repo/root.x86_64.log#3271-3292
The likely candidate there is `python3-snappy`, and it _does_ require
cramjam, but since it's noarch (which doesn't build on i686), they
likely would not have noticed.
At this point it would be nice to drop i686 from pymongo, but how can
one make the determination that this is a "leaf" i686 package?
You can use leafdrop https://pagure.io/leafdrop as mentioned on
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
Especially since it appears that some determinations of this were incorrect.
They weren't wrong per se, but due to a mix of a noarch package
depending on arched packages and noarch no longer building on i686.
Ah, the fact that pymongo was built so late was unfortunate then.
Does leafdrop do an analysis of what of the deps are noarch? It doesn't
seem like it. I get:
$ ./leafdrop python-pymongo
python3-bson is Required by:
- python3-dionaea
python3-pymongo is Required by:
- cobbler
- python3-mongoengine
- python3-pyphi
- python3-sentry-sdk+pymongo
python3-pymongo is BuildRequired by:
- ipython
- pcp
- python-APScheduler
- python-anykeystore
- python-jsonpickle
- python-kombu
- python-mongoengine
- python-pyphi
- python-pysaml2
- python-sentry-sdk
python3-pymongo-gridfs is Required by:
- python3-mongoengine
python3-pymongo-gridfs is BuildRequired by:
- python-mongoengine
NO: Package python-pymongo is not a leaf package on i686.
but ipython for one is noarch and so should not be a blocker here. And
pcp is ExcludeArch %{ix86}. So I guess I'm not sure how I am supposed
to interpret its output.
I guess it has:
TODO
filter out source packages that already have ExcludeArch: i686
(using similar heuristics as in repochecker)
so it doesn't seem terribly useful for addressing these more complicated
cases that I was asking about.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion@xxxxxxxx
Boulder, CO 80301 https://www.nwra.com/
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
