Re: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-08)
On 8.7.2015 23:55, opensou...@till.name wrote: > Depending on: prelink (30), status change: 2014-05-14 (60 weeks ago) There are lot of my packages in there and also lot's of others. I haven't willingly chosen this package to be the dependency, so I guess this is happening automatically. Should I worry? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags
On 9.7.2015 14:48, Haïkel wrote: > * mass changing all specs => could be automated Actually, openSUSE has a tool for this: https://github.com/openSUSE/spec-cleaner It can convert their old license abbrevs to SPDX, I don't know if we are using the same ones, but the data set can be changed of course. Another thing is that this would most certainly also affect EPEL/RHEL, so it is probably not only Fedora's decision to make. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Removing packages that have broken dependencies in F23 tree
On 24.9.2015 16:34, Kalev Lember wrote: > python-Fionachurchyard, group::python-sig This one cannot work with Fedora 23 due to GDAL 2. Feel free to retire it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Flock 2014 reminder about decision making and thanks to organizers
Dne 11.8.2014 18:05, Kevin Fenzi napsal(a): > Also, I would like to say a heartfelt thank you to the many people who > organized flock 2104. It was a very smoothly run, great conference! > Kudos. Thanks for this. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning perl-Lingua-EN-Numbers-Easy
Hi, perl-Lingua-EN-Numbers-Easy FTBFS in rawhide. [1] While the fix seems trivial, I don not want to patch a (most probably) dead upstream project that I don't need any more (I packaged it as a dependency for something not needing it anymore). Facts: * Latest upstream release is ~5 years old * No other package requires this any more If anybody want this package, feel free to take it. Otherwise I'm fine with this being retired later. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1153134 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Anaconda goes Python 3
On 18.5.2015 11:01, Vratislav Podzimek wrote: > The F22 composes are at > https://m4rtink.fedorapeople.org/anaconda/images/python3/f22/ so feel > free to download and test them. Hi, what is the difference between latest and testing images? Which one should I test? Thanks for the summary and blogpost. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 28. 05. 20 0:42, Miro Hrončok wrote: On 27. 05. 20 20:24, Miro Hrončok wrote: I'm currently trying to build a live image, but it's running insanely slow for some reason, mock in general on my Rawhide box seems to be really slow and I'm not sure why. If it ever finishes I'll try it. But so far at least I see no problems. Hah, so it seems you're ahead of me =) The live image build finally finished, but when I booted it to check it, I found it includes both python3-3.8.3-1.fc33 and python3.9- 3.9.0~b1-1.fc33.x86_64 . Digging into this I figured out it's because of libreoffice: libreoffice-pyuno requires Python 3.8. So I went to Koji and saw...you're rebuilding it already :) https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799 I will test again when that's done. If it ever finishes. After 30 hours of s390x misery watching the build.log grow one line in 15 minutes, I decided to gamble and I have restarted the build: https://koji.fedoraproject.org/koji/taskinfo?taskID=45081892 Apparently, tough luck. Could you please test with x86_64 libreoffice packages downloaded from Koji before the build finishes? That way, we'll know that we can merge as soon as it is finally done. Thanks -- 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
Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 28. 05. 20 14:21, Fabio Valentini wrote: On Thu, May 28, 2020 at 2:16 PM Jonathan Wakely wrote: I've literally just started. The new boost hasn't even finished yet: https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034 I wonder if this build is actually broken and if it will ever finish: https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034 Because ... ppc64 hasn't been a valid arch since fedora 31 or so? It will not finish. The side tag configuration is busted: https://pagure.io/releng/issue/9474 -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 22. 05. 20 3:06, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.9 If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, please don't rebuild it in regular rawhide. If you need to, please let me know, so we can coordinate. Hello. I've seen more packages updated in rawhide after the "Rebuilt for Python 3.9" commit. Please don't rebuild the packages in regular rawhide unless it is critical. When it is critical, please let me know about it, so we can coordinate. Thanks. -- 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
Re: Schedule for Thursday's FPC Meeting (2020-05-28 16:00 UTC)
On 28. 05. 20 8:08, James Antill wrote: Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-05-28 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. I ma sorry, but I am too tired to attend. The Python 3.9 rebuilds are draining all my energy :( -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 22. 05. 20 3:06, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.9 If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, please don't rebuild it in regular rawhide. If you need to, please let me know, so we can coordinate. Hello. I've seen more packages updated in rawhide after the "Rebuilt for Python 3.9" commit. Please don't rebuild the packages in regular rawhide unless it is critical. When it is critical, please let me know about it, so we can coordinate. Thanks. -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 28. 05. 20 8:33, Adam Williamson wrote: On Wed, 2020-05-27 at 10:27 -0700, Adam Williamson wrote: Hah, so it seems you're ahead of me =) The live image build finally finished, but when I booted it to check it, I found it includes both python3-3.8.3-1.fc33 and python3.9- 3.9.0~b1-1.fc33.x86_64 . Digging into this I figured out it's because of libreoffice: libreoffice-pyuno requires Python 3.8. So I went to Koji and saw...you're rebuilding it already :) https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799 I will test again when that's done. In the mean time I tested a KDE live build, and that came up with just Python 3.9 in it. So that looks good. I'd like to merge the side tag as soon as libreoffice is built. Adam, do you want to ack it first? -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 22. 05. 20 3:06, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.9 If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, please don't rebuild it in regular rawhide. If you need to, please let me know, so we can coordinate. If you'd like to build the package, you should be able to build it in the side tag via: on branch master: $ fedpkg build --target=f33-python $ koji wait-repo f33-python --build Note that it will take a while before all the essential packages are rebuilt, so don't except all your dependencies to be available right away. When in trouble, ask here or on IRC (#fedora-python on Freenode). Builds: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=22287&order=-build_id&inherited=0 Please avoid any potentially disturbing changes in Python packages until the rebuild is over. The side tag is being merged right now. The builds are tagged into f33 in alphabetical order, hence expect a small window of very broken dependencies. -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 29. 05. 20 9:32, Felix Schwarz wrote: Am 29.05.20 um 09:19 schrieb Miro Hrončok: The side tag is being merged right now. Thank you for all the work (also in advance with all the alpha/beta versions) :-) Seems like quite a few Python packages were rebuilt in rawhide during your mass rebuild. Did that happen in the past as well? (I don't remember it that way but also I did not monitor previous python rebuilds closely). In previous upgrades, we haven't checked and after we asked releng to merge the side tag, we just realized several packages were rebuilt (incl. a small boostrap loop once and anaconda the other time). Hence this time, I've been monitoring the situation. Less then 10 packages were bumped and built in rawhide during the rebuilds this time. -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 29. 05. 20 11:49, Jonathan Wakely wrote: On 29/05/20 09:34 +0200, Miro Hrončok wrote: On 29. 05. 20 9:32, Felix Schwarz wrote: Am 29.05.20 um 09:19 schrieb Miro Hrončok: The side tag is being merged right now. Thank you for all the work (also in advance with all the alpha/beta versions) :-) Seems like quite a few Python packages were rebuilt in rawhide during your mass rebuild. Did that happen in the past as well? (I don't remember it that way but also I did not monitor previous python rebuilds closely). In previous upgrades, we haven't checked and after we asked releng to merge the side tag, we just realized several packages were rebuilt (incl. a small boostrap loop once and anaconda the other time). Hence this time, I've been monitoring the situation. Less then 10 packages were bumped and built in rawhide during the rebuilds this time. Could you send me the list of those packages, if you have it? I've rebuilt them all again. Are any of them in the list of packages that I need to rebuild anyway for the boost1.73+python3.9 combo? No. By the way, I accidentally rebuilt player in the f33-boost side tag, because my makefile incorrectly listed it as a prerequisite of gazebo and so automatically added it to my rebuilds (it *is* a prerequisite of gazebo, but doesn't use boost so I didn't need to do it). I noticed that your f33-python build of player didn't work, so I'll add that to the list of ones to rebuild in my tag after f33-python finishes merging (apparently they're still being signed). The signing is taking ages :/ -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 29. 05. 20 13:07, Jonathan Wakely wrote: On 29/05/20 12:17 +0200, Miro Hrončok wrote: On 29. 05. 20 11:49, Jonathan Wakely wrote: On 29/05/20 09:34 +0200, Miro Hrončok wrote: On 29. 05. 20 9:32, Felix Schwarz wrote: Am 29.05.20 um 09:19 schrieb Miro Hrončok: The side tag is being merged right now. Thank you for all the work (also in advance with all the alpha/beta versions) :-) Seems like quite a few Python packages were rebuilt in rawhide during your mass rebuild. Did that happen in the past as well? (I don't remember it that way but also I did not monitor previous python rebuilds closely). In previous upgrades, we haven't checked and after we asked releng to merge the side tag, we just realized several packages were rebuilt (incl. a small boostrap loop once and anaconda the other time). Hence this time, I've been monitoring the situation. Less then 10 packages were bumped and built in rawhide during the rebuilds this time. Could you send me the list of those packages, if you have it? I've rebuilt them all again. Are any of them in the list of packages that I need to rebuild anyway for the boost1.73+python3.9 combo? No. OK, great, nothing extra for me to do then :-) By the way, I accidentally rebuilt player in the f33-boost side tag, because my makefile incorrectly listed it as a prerequisite of gazebo and so automatically added it to my rebuilds (it *is* a prerequisite of gazebo, but doesn't use boost so I didn't need to do it). I noticed that your f33-python build of player didn't work, so I'll add that to the list of ones to rebuild in my tag after f33-python finishes merging (apparently they're still being signed). The signing is taking ages :/ Yes, but python3-3.8.3-1.fc33 is done, so I'll rebuild boost in my side tag and resume my rebuilds there. This was a Python 3.9 rebuild, not 3.8. We need to wait for: python3.9-3.9.0~b1-3.fc33 -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 22. 05. 20 3:06, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.9 If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, please don't rebuild it in regular rawhide. If you need to, please let me know, so we can coordinate. The side tag has been merged. Thank you all for your patience. -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 29. 05. 20 16:25, Richard Shaw wrote: On Fri, May 29, 2020 at 9:18 AM Miro Hrončok <mailto:mhron...@redhat.com>> wrote: The side tag has been merged. Thank you all for your patience. Woohoo! So now Python can be rebuilt with the fix for PySide2? :) Technically blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1839826 But I am sure Petr is working on it. -- 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
PSA: pytest 5 now finally available in rawhide
Hello,
the pytest package (python3-pytest) has been updated to 5.4.2.
In case it gives you trouble, you can pin an older version:
BuildRrequires: %{py3_dist pytest} < 5
Or:
BuildRrequires: python3dist(pytest) < 5
That will give you the python3-pytest4 package (4.6.10 now), not parallely
installable with python3-pytest.
Note that the python3-pytest4 package is deprecated, but no removal date has
been set. Likely, it will get orphaned or retired when no important packages
need it.
The pytest 4.6.x series is still being occasionally released, but:
https://docs.pytest.org/en/latest/py27-py34-deprecation.html#maintenance-of-4-6-x-versions
"From now on, the core team will no longer actively backport patches, but the
4.6.x branch will continue to exist so the community itself can contribute patches."
Side note: The Fedora 31/32 python3-pytest package does not provide
python3-pytest4, hence I recommend not to BuildRequire python3-pytest4 directly
by name, but using python3dist(pytest) or %py3_dist as in the examples above.
--
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
Re: Rawhide broken: crypto-policies
On 29. 05. 20 18:08, Jerry James wrote: Trying to build a package just now failed (https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531): Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction error: lua script failed: [string "%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19: attempt to call a nil value Error in PREIN scriptlet in rpm package crypto-policies error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install failed https://bugzilla.redhat.com/show_bug.cgi?id=1841851 Mohan and Igor are untagging the build now. -- 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
Packages that failed to build with Python 3.9
c python-gerritlib kevin ansible calibre python-IPy ktdreyer python-cram kubo py3status kumarpraveen python-flask-assets python-webassets kushal mu kushal124 python-docx kwizartblender libfreenect luxcorerender player larsks python-shade lbalharmicropipenv lbazan pydeps python-chaospy python-elpy python-hdmf python-ipmi python-missingno python-mne-bids python-netssh2 python-numpoly python-pynwb lberk pcp limb python-basemap python-pcodedmp python-slackclient lkundrak coreboot-utils lmackenpython-chameleon python-tw2-core louizatakk python-slixmpp lucilanga pyzor lupinixpython-astroML python-astroscrappy python-ccdproc python-gatspy luya blender luxcorerender lyessaadi komikku python-pure-protobuf maci python-apsw maha python-onionbalance major pre-commit marcindulak gpaw martinkg mlt maxamillion python-nikola mbarnescommissaire-client mchehabzbar melmorabity python-azure-sdk python-azure-storage python-googleapis-common-protos python-grpcio-gcp python-msal python-opencensus-proto python-uamqp mfabiannototools mgoodwin pcp michichpython-precis_i18n mikem module-build-service mimccune python-saharaclient minh kdevelop-python mitr libuser m2crypto mkrizeklibtaskotron mlisik pcs mlombard python-simpleparse mprahl module-build-service python-neo4j-driver mrunge pyflakes python-cherrypy python-django-formtools python-flake8 python-gnocchiclient python-hacking python-oslo-concurrency python-troveclient python-webpy msivak mom mstuchli python-peewee python-wtf-peewee msuchy osc nathanspcp ngompa ipsilon m2crypto osc python-pytest-flake8 nickblack notcurses nonamedotc python-jsonrpc-server python-language-server python-qdarkstyle python-rope python-spyder-kernels nphilipp lilv nsaje python-oslo-serialization nushio calibre ohaessler Zim omular pcs ondrejjTurboGears2 python-tw2-core python-tw2-forms orion Mayavi paraview python-AppTools python-Traits python-envisage python-pyface python-scikit-image python-traitsui python-x2go pabelanger python-keystoneauth1 python-os-client-config python-shade pbrobinson csound libcec pyee pcpa sagemath peter coreboot-utils pjppython-flask-assets python-webassets pkilambi python-gnocchiclient pmoravco 5minute pnemadeansible-inventory-grapher ansible-lint fonttools python-fs python-ufoLib2 transtats-cli woffTools puiterwijk ipsilon pwalterscribus pwunototools qulogicocrmypdf python-cartopy python-descartes python-fiona python-geopandas python-geoplot python-libpysal python-mapclassify python-mplcairo python-pep8-naming python-pikepdf python-pyshtools python-xarray python-xmp-toolkit qwan module-build-service radez python-ansible-runner python-cheroot python-cherrypy python-network-runner python-portend ralph module-build-service python-chameleon python-tw2-core python-tw2-forms ramkrsna gdeploy raphgropython-jep rathannlazygal mnemosyne rdietercantor rebus python-pyev python-yara rjmco python-novaclient-os-networks python-novaclient-os-virtual-interfaces rjones coccinelle rmatteslibfreenect player robert python-pcodedmp pyzor roma blender ryansb python-heatclient s4504krblender sacgdeploy sagitter paraview petsc4py pymol sandeeps woffTools sbonazzo imgbased mom pyflakes sdgathman cjdns sdzcsound senderek cryptlib sergiomb mlt pymol sergiopr python-photutils python-pywt python-scikit-image sgallagh python-flake8 sharkczscribus shlomifpython-freecell_solver simo ipsilon slaanesh blender zbar smani gmsh smilnercommissaire-client social python-hacking python-oslo-serialization suanandtranstats-cli sundaram python-flask-assets python-webassets suraia distro-info tagoh fonttools tartinalilv tc01 python-cocotb tdabasin python-chameleon than cantor tibbs pyzor timn player tojeline pcs tomh pyosmium toshio ansible tripledes scribus ttorling player ttrinksansible-review uwog abiword vkmc python-designateclient vkrizanpython-peewee vmaljulin module-build-service volter python-shapely wakko666 python-testinfra wzzrd ansible xavierbpython-f5-icontrol-rest python-f5-sdk yuvalturg imgbased zaitcevpython-manilaclient zaneb python-heatclient zbyszekcalibre diffoscope enjarify moose python-asttokens python-flake8-import-order zdohnalpython-pikepdf zultronfreecad zuul python-ws4py -- 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://fedoraprojec
Re: Packages that failed to build with Python 3.9
On 29. 05. 20 22:38, Gwyn Ciesla via devel wrote: ‐‐‐ Original Message ‐‐‐ On Friday, May 29, 2020 2:59 PM, Miro Hrončok wrote: Hello. As you might already know, we have recently merged in the Python 3.9 side tag, despite several builds have not succeeded. We always aim for some compromise between having the side tag open for too long and having too many failures. When will python3 in the rawhide buildroot be 3.9? It is. Note that the component name is python3.9, but the binary package is still python3. The python3 component is retired. -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 30. 05. 20 0:08, Orion Poplawski wrote: On 5/29/20 8:17 AM, Miro Hrončok wrote: On 22. 05. 20 3:06, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.9 If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, please don't rebuild it in regular rawhide. If you need to, please let me know, so we can coordinate. The side tag has been merged. Thank you all for your patience. Thank you Miro for all the hard work. You are welcome. Thanks for your help with vtk an other packages you maintain, I know you don't have that much time for Fedora nowadays. -- 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
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On 30. 05. 20 23:10, Jonathan Wakely wrote: On 29/05/20 16:17 +0200, Miro Hrončok wrote: On 22. 05. 20 3:06, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.9 If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, please don't rebuild it in regular rawhide. If you need to, please let me know, so we can coordinate. The side tag has been merged. Thank you all for your patience. https://koji.fedoraproject.org/koji/buildinfo?buildID=1512682 is still going for python-graph-tool-2.29-4.fc33 and will probably take another 15 hours at least, based on the comments in the spec file. I've already started python-graph-tool-2.29-5.fc33 for the boost rebuild, so if yours finishes it won't be needed anyway. I am afraid the build gets restarted every coupe hours. See: https://koji.fedoraproject.org/koji/taskinfo?taskID=45142331 Total time 32:37:26 Task time 2:33:39 Buildroots /var/lib/mock/f33-build-20969493-1558663 /var/lib/mock/f33-build-20951538-1558663 /var/lib/mock/f33-build-20962546-1558663 /var/lib/mock/f33-build-20957113-1558663 /var/lib/mock/f33-build-20953332-1558663 -- 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
Re: What's pulling in a bunch of texlive packages?
On 30. 05. 20 17:30, Zbigniew Jędrzejewski-Szmek wrote: On Sat, May 30, 2020 at 10:01:50AM -0500, Richard Shaw wrote: I'm working on updating FreeCAD both for Python 3.9 and coming VTK 9.0 and I noticed that something is pulling in a lot of texlive packages but I am not BR'ing any. I'm seeing this too, with ~100 texlive packages pulled in on upgrade in a VM. I think this is caused by new dependencies between texlive package. E.g. I had texlive-kpathsea installed, presumably because it is required by texlive-dvipng which is required by python3-matplotlib, and upon upgrade this pulls in texlive-context, which pulls in texlive-pstricks, which pulls in texlive-biblatex, which pulls in texlive-xpatch, and so on. The dep was added back in #1270202. Dunno. python3-matplotlib pulling in the whole latex stack is going to be painful. Maybe we could "downgrade" the dependency in python-matplotlib to something like Recommends: dvipng Requires: (dvipng if texlive-base) ? (Though of course in your case the dependency path might be different.) See also: https://bugzilla.redhat.com/show_bug.cgi?id=1509657 (couple years old) -- 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
Re: Packages that failed to build with Python 3.9
On 30. 05. 20 9:18, Przemo Firszt wrote: W dniu pią, 29.05.2020 o godzinie 23∶10 +0200, użytkownik Miro Hrončok napisał: [..] When will python3 in the rawhide buildroot be 3.9? It is. Note that the component name is python3.9, but the binary package is still python3. The python3 component is retired. Hi Miro, What's the time line for COPR? My FreeCAD nightly on rawhide still builds on python 3.8 As soon as the mirrors have the newest compose from yesterday. Should be now already. -- 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
Re: Packages that failed to build with Python 3.9
On 30. 05. 20 1:17, Adam Williamson wrote: On Fri, 2020-05-29 at 21:59 +0200, Miro Hrončok wrote: Hello. As you might already know, we have recently merged in the Python 3.9 side tag, despite several builds have not succeeded. We always aim for some compromise between having the side tag open for too long and having too many failures. The packages, when not rebuilt, are not installable in rawhide, hence fixing them should be our top priority. If you need help with Python related issues, we (the Python Maintenance team at Red Hat) are happy to help. Unfortunately, several packages fail to build for Python-unrelated reasons. Some of the actual build failures already have a bugzilla open from our copr rebuilds. Others don't have it yet because the error only manifested on some architecture other than x86_64. I'll get back to this next week and open the remaining bugzillas. Most of the packages only fail to build because their dependencies were not yet rebuilt. Chances are, you already got an automated bugzilla from Igor, that your package fails to install. It would be really helpful if you could find the missing dependency and mark the bugzilla for your package dependent on the bugzilla for the missing dep. I slowly progress to do that as well, but your help is crucial here. Let me know if you have questions. Here is the list: Maintainers by package: bugzilla2fedmsg abompard calibre chkr heliocastro kevin nushio zbyszek python-apsw cicku dfateyev maci python-stompest abompard I fixed apsw and rebuilt calibre, which needed it. Thanks. I'll close https://bugzilla.redhat.com/show_bug.cgi?id=1840234 -- 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
Re: Packages that failed to build with Python 3.9
On 30. 05. 20 11:56, Ján ONDREJ (SAL) wrote: Ahoj, Hey. I'll try to answer. som trocha zmateny z tych hlaseni. Je skoda, ze bugzilla priamo neobsahuje link na failed build. The bugzillas don't contain the failed build link, because they are primarily "fails to install" and not "fails to build" bugzillas. In this particular case, the first is caused by the latter, but Igor's automation cannot know that. Musim si ho pohladat sam. Skusal som rebuildnut tak ako si mi vravel, teda cez mock s konfiguraciou copr repo, ale neviem preco, tak ten build zbehne teraz bez problemov. Ale ked dam build priamo cez fedpkg build, tak to nezbehne. To este nie je mergnute? Ale divne je, ze preco mi mock -r fedora-rawhide-python39 ... zbehne. The Python 3.9 copr is debugging tool only. It contains builds of genshi and chameleon done with Python 3.9.0a1, a2... etc. In Koji, we have started with b1 and chameleon and genshi didn't build there. That's the reason why your packages build with copr-mock, but not in regular mock. Upravil som tie bugy a doplnil pozadovane depends. Hadam je to vsetko, pretoze ani z koji build logov mi nie je uplne jasne, co z toho naozaj treba a mozno ani nie. Pridal som aj pull-request pre chameleon, ale mam pocit, ze ten maintainer je unresponsible. I suggest you change the bugzillas to ASSIGNED, becasue you are clearly looking into it -- that way, others know you are on top of this and Igor's automation won't bother you. Indeed, the chameleon bug received no maintainer response for a very long time. This way, the automation may as well render the package orphan and you can take it. -- 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
Re: Packages that failed to build with Python 3.9
On 31. 05. 20 12:49, Leigh Scott wrote: Hello. As you might already know, we have recently merged in the Python 3.9 side tag, despite several builds have not succeeded. We always aim for some compromise between having the side tag open for too long and having too many failures. The packages, when not rebuilt, are not installable in rawhide, hence fixing them should be our top priority. If you need help with Python related issues, we (the Python Maintenance team at Red Hat) are happy to help. Unfortunately, several packages fail to build for Python-unrelated reasons. Some of the actual build failures already have a bugzilla open from our copr rebuilds. Others don't have it yet because the error only manifested on some architecture other than x86_64. I'll get back to this next week and open the remaining bugzillas. Most of the packages only fail to build because their dependencies were not yet rebuilt. Chances are, you already got an automated bugzilla from Igor, that your package fails to install. It would be really helpful if you could find the missing dependency and mark the bugzilla for your package dependent on the bugzilla for the missing dep. I slowly progress to do that as well, but your help is crucial here. Let me know if you have questions. Even if the package builds it doesn't mean it's functional. $ cinnamon-settings Traceback (most recent call last): File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 16, in from setproctitle import setproctitle ImportError: /usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: undefined symbol: Py_GetArgcArgv [leigh@leigh ~]$ python Python 3.9.0b1 (default, May 29 2020, 00:00:00) [GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. from setproctitle import setproctitle Traceback (most recent call last): File "", line 1, in ImportError: /usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: undefined symbol: Py_GetArgcArgv import setproctitle Traceback (most recent call last): File "", line 1, in ImportError: /usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: undefined symbol: Py_GetArgcArgv Note that python-setproctitle already failed to built with Python 3.8 and the "fix" was to comment out the tests: https://src.fedoraproject.org/rpms/python-setproctitle/c/d6d9620c3c4fa076b62ddfa7fdc39b0f70597dd6?branch=master Hence, it built with Python 3.9 even if it doesn't work 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
Re: Packages that failed to build with Python 3.9
On 31. 05. 20 13:04, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, May 31, 2020 at 10:49:28AM -, Leigh Scott wrote:
Even if the package builds it doesn't mean it's functional.
$ cinnamon-settings
Traceback (most recent call last):
File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 16, in
from setproctitle import setproctitle
ImportError:
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so:
undefined symbol: Py_GetArgcArgv
Idea for a global gating test for packages:
for rpm in $rpms; do
python3 -c "$(rpm -qP $rpm | sed -n -r 's/python3dist\((.*)\).*/import
\1/p')"
done
Unfortunately, this has a wrong assumption: python3dist(xxx) doesn't mean there
is an xxx module to import. See for example:
python3-beautifulsoup4 provides python3.9dist(beautifulsoup4) but is imported as
bs4. (I have plenty more examples like this... including python-fedora.)
A better thing might be to query for .py files, .so files and directories with
such in %{python_sitelib}/%{python_sitearch}.
--
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
Re: Packages that failed to build with Python 3.9
On 31. 05. 20 13:13, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, May 31, 2020 at 01:09:31PM +0200, Miro Hrončok wrote:
On 31. 05. 20 13:04, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, May 31, 2020 at 10:49:28AM -, Leigh Scott wrote:
Even if the package builds it doesn't mean it's functional.
$ cinnamon-settings
Traceback (most recent call last):
File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 16, in
from setproctitle import setproctitle
ImportError:
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so:
undefined symbol: Py_GetArgcArgv
Idea for a global gating test for packages:
for rpm in $rpms; do
python3 -c "$(rpm -qP $rpm | sed -n -r 's/python3dist\((.*)\).*/import
\1/p')"
done
Unfortunately, this has a wrong assumption: python3dist(xxx) doesn't mean
there is an xxx module to import. See for example:
python3-beautifulsoup4 provides python3.9dist(beautifulsoup4) but is
imported as bs4. (I have plenty more examples like this... including
python-fedora.)
A better thing might be to query for .py files, .so files and directories
with such in %{python_sitelib}/%{python_sitearch}.
I always thought python3dist(foo) means that the package provides the
foo module, so that if I want to install foo module, I can rely on this
provides.
This is a very common misconception. That's why we want to explain this better
in the new Python guidelines:
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/ZCNUQBJLDUJUJXK2EOPP2MWL6FJKLBPS/
Particularly:
---
Python packages have several different names, which should be kept in sync but
will sometimes differ for historical or practical reasons. They are:
* the Fedora *source package name* (or *component name*, %{name}),
* the Fedora *built RPM name*,
* the *project name* used on *PyPI* or by *pip*, and
* the *importable module name* used in Python (a single package may have
multiple importable modules).
Some examples (both good and worse):
| Fedora component | Built RPM | Project name | Importable module |
| - | -- | - | --- |
| `python-requests` | `python3-requests` | `requests`| `requests` |
| `PyYAML` | `python3-pyyaml` | `pyyaml` | `yaml` |
| `python-ldap` | `python3-ldap` | `python-ldap` | `ldap`, `ldif`, etc.|
| `python-pillow` | `python3-pillow` | `pillow` | `PIL` |
---
python3dist() holds the "project name" (more specifically, the canonical form).
We use upstream metadata to generate python3.Xdist() requires. Upstreams specify
dependencies in project names, not importable module names.
--
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
Re: Packages that failed to build with Python 3.9
On 29. 05. 20 21:59, Miro Hrončok wrote: Hello. As you might already know, we have recently merged in the Python 3.9 side tag, despite several builds have not succeeded. We always aim for some compromise between having the side tag open for too long and having too many failures. ... cinch greghellings libtaskotron mkrizek python-ansible-runner radez python-peewee cstratak mstuchli vkrizan python-testinfra chedi ignatenkobrain wakko666 python-wtf-peewee cstratak mstuchli I've rebuilt those. -- 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
Re: PSA: pytest 5 now finally available in rawhide
On 31. 05. 20 14:06, Ian McInerney wrote:
On Fri, May 29, 2020 at 4:58 PM Miro Hrončok <mailto:mhron...@redhat.com>> wrote:
Hello,
the pytest package (python3-pytest) has been updated to 5.4.2.
In case it gives you trouble, you can pin an older version:
BuildRrequires: %{py3_dist pytest} < 5
Or:
BuildRrequires: python3dist(pytest) < 5
That will give you the python3-pytest4 package (4.6.10 now), not parallely
installable with python3-pytest.
Note that the python3-pytest4 package is deprecated, but no removal date has
been set. Likely, it will get orphaned or retired when no important packages
need it.
The pytest 4.6.x series is still being occasionally released, but:
https://docs.pytest.org/en/latest/py27-py34-deprecation.html#maintenance-of-4-6-x-versions
"From now on, the core team will no longer actively backport patches, but
the
4.6.x branch will continue to exist so the community itself can contribute
patches."
Side note: The Fedora 31/32 python3-pytest package does not provide
python3-pytest4, hence I recommend not to BuildRequire python3-pytest4
directly
by name, but using python3dist(pytest) or %py3_dist as in the examples
above.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
When running the fedora-review tool on a package that has "BuildRequires:
python3dist(pytest)" in it (note there is no version dependency on the pytest
package), the review is complaining that:
- Package must not depend on deprecated() packages.
Note: python3-pytest4 is deprecated, you must not depend on it.
Looking in the build log, it is actually using pytest5 though:
+ /usr/bin/python3 -m pytest
= test session starts ==
platform linux -- Python 3.9.0b1, pytest-5.4.2, py-1.8.0, pluggy-0.13.0
I have already cleaned my mock cache, and ran mock --scrub=all and this
persists. Is there another cache that has to be cleaned, or a package that needs
updating?
No, this is a bug in fedora-review.
https://pagure.io/FedoraReview/issue/392
--
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
Re: Packages that failed to build with Python 3.9
On 31. 05. 20 17:09, Leigh Scott wrote: On 31. 05. 20 12:49, Leigh Scott wrote: Note that python-setproctitle already failed to built with Python 3.8 and the "fix" was to comment out the tests: https://src.fedoraproject.org/rpms/python-setproctitle/c/d6d9620c3c4fa076... Hence, it built with Python 3.9 even if it doesn't work at all. Would it be acceptable to comment out the Py_GetArgcArgv code? https://paste.centos.org/view/raw/779a12bd Doing this enables cinnamon, blueberry, cinnamon-screensaver and lightdm-settings to function That's up to the maintainer. Seems reasonable to me. -- 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
Re: Packages that failed to build with Python 3.9
On 01. 06. 20 4:14, Denis Arnaud wrote: Thanks for the follow up! | airinv airrac airtsp rmol sevmgr trademgen All those packages have been successfully rebuilt (after upstream upgrade): * airinv: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d6b3c81762 * airrac: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bd268627aa * airtsp: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bf40bfa645 * rmol: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5c004b8ae6 * sevmgr: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1cd31866cb * trademgen: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1966482401 Thank you, Denis! -- 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
Re: subtle issue with systemd, dnf 'greedy' obsoletes behaviour, and multiple repos
On 01. 06. 20 23:10, Adam Williamson wrote: It was actually a bit tricky to come up with a solution for this. I hacked up a minimal reproducer with empty packages, and experimented a bit, and the solution I was able to find that works is to have systemd- udev Obsoletes: systemd < 245.6-1. This seems to correctly clue DNF in to the situation and cause it to leave out anything from 245.4-1.fc32 in the upgrade. IMO this is the "correct" solution to the problem. Thanks. -- 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
Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 02. 06. 20 17:24, Jonathan Wakely wrote: ### Boost.Endian Several packages fail because they were using an implementation detail of Boost, the header. That no longer exists, but nobody should have been using it anyway :-P The Boost.Endian library exists now, and provides which should work instead. This Boost.Endian issue affects: openscad supercollider Also prusa-slicer and slic3r. -- 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
Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 02. 06. 20 19:51, Miro Hrončok wrote: On 02. 06. 20 17:24, Jonathan Wakely wrote: ### Boost.Endian Several packages fail because they were using an implementation detail of Boost, the header. That no longer exists, but nobody should have been using it anyway :-P The Boost.Endian library exists now, and provides which should work instead. This Boost.Endian issue affects: openscad supercollider Also prusa-slicer and slic3r. is deprecated: # error " is deprecated. Define BOOST_ENDIAN_DEPRECATED_NAMES to use." /usr/include/boost/endian/endian.hpp:19:1: note: '#pragma message: This header is deprecated. Use instead.' 19 | BOOST_HEADER_DEPRECATED( "" ) -- 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
Orphaning repsnapper, gtkglextmm
I've just orphaned repsnapper and gtkglextmm. repsnapper depends on gtkglextmm which depends on pangox-compat, which is already orphaned for 4 weeks. I haven't touched the packages in years and I don't use repsnapper. In case a new maintainer emerges, I can stay around if needed. -- 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
Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 03. 06. 20 13:32, Till Hofmann wrote: Yes, that's what I meant. I'm not going to test patches by submitting builds over and over again, that's not really time efficient. I'll just wait until it shows up in mock. $ mock -r fedora-rawhide-x86_64 --enablerepo=local install boost-devel ... Installed: boost-devel-1.73.0-3.fc33.x86_64 ... -- 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
Re: %configure broken in Rawhide
On 04. 06. 20 6:02, Michael Cronenworth wrote: On 6/3/20 8:23 PM, Igor Raits wrote: At least it did not break anything than %configure, so the world did not explode:) It hit at a very unfortunate time. With the reduced data center power it is taking a long time to hit the build root. Two hours and counting... :( That is IMHO https://pagure.io/fedora-infrastructure/issue/8922 (aka not a reduced power problem). -- 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
Re: Upcoming fedoraproject Datacenter move reminder and plans
On 02. 06. 20 18:40, Kevin Fenzi wrote: Greetings. As previously announced, fedoraproject is moving many of it's servers from one datacenter (phx2 near phoenix, arizona, usa) to another (iad2: near arlington, virginia, usa). As we move from the old datacenter to the new, we will have a temporary reduction in capacity. The new datacenter has a smaller, less-redundant, lower-capacity version of our infrastructure. Over the next two weeks, we will migrate services to it so that we can finish moving out of the old datacenter. After everything is moved from the old datacenter, many of the servers there will be shipped to the new datacenter and then re-added to bring us back to full redundency and capacity. Out detailed checklist for these migrations is available at https://hackmd.io/@fedorainfra2020/rJpsA4FLL ... snip ... Is there a publicly available more or less up to date mirror of src.fedoraproject.org git repos? I know there is https://fedoraproject.org/wiki/Infrastructure/Grokmirror But I'd rather not set it up myself, if there is some instance I can use. We'd like to build packages in Copr during the outage, because Copr is not affected, but we build packages from dist git sources, so when src.fp.o goes down, we need a backup plan. To have this, we need git repos + lookaside cache, but we can more or less workaround the lookaside cache problem (at least for packages with Sources with proper URLs). -- 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
Re: Let's standardize the way to disable tests during RPM build?
On 05. 06. 20 16:26, Richard W.M. Jones wrote:
On Fri, Jun 05, 2020 at 04:10:20PM +0200, Tomas Orsava wrote:
Hi,
I think it would be useful to have a standard way of disabling the
running of tests during RPM build (in the %check section of a spec
file).
I see a lot of packages already having %bcond's or other macro
definitions to archieve this, but each package has their own way,
there's no real standard. Thus you have to first look into the spec,
locate the appropriate %bcond or macro name and only then you can
disable the tests.
I would like to propose two approaches:
(a) Add a *SHOULD* rule to the guidelines that specifies what is the
preferred way to conditionalize the tests.
(b) Or, if that's too strong, mention in the guidelines the common
methods that are being used (e.g. %bcond tests and %bcond check) so
that new packagers have something to use.
What's the motivation for disabling tests globally?
Bootstrapping mostly.
I have some packages where tests fail on particular architectures at
particular times, and what I do there is (a) file a BZ (b) surround
the %check section with %ifarch/%ifnarch and a comment linking to the
bug, and this seems to me a practical and lightweight approach that
requires no special support in the toolchain.
Also rpmbuild itself can happily disable tests, just add the --nocheck
flag.
However rpmbuild itself doesn't support "CheckRequires", so the bcond often
looks like this:
BuildRequires: python3-devel
BuildRequires: python3-setuptools
%if %{with tests}
BuildRequires: python3-pytest
BuildRequires: python3-hypothesis
%endif
...
%if %{with tests}
%check
%pytest
%endif
--
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
Re: Is the name of this review package OK?
On 05. 06. 20 15:55, Richard W.M. Jones wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1825456 Proposed package name is "libvirt-test-api". Upstream name is "libvirt-test-API". It is, very very loosely, a Python 3 API and the package includes Python development files. But on the other hand it's a set of regression tests and the fact they're implemented in Python is rather incidental. Yes, in that case, the python- prefix is not useful. The rules say: "The source package for a Python library MUST be named with the python- prefix. A built package however must include the Python major version in the name, using the python3- prefix. This is accomplished by adding a subpackage. See example below. This rule does not apply to applications." I feel this is a bit of a grey area because it's a Python library primary used to construct the test suite. I think it applies here. The docs for the package are here: http://libvirt.org/sources/libvirt-test-API/Libvirt-test-API.pdf The docs say you invoke the test with python: """ The main.py file, located in the root directory of the test tool, is the file that runs the test and performs other operations in libvirt-test-API. To run a test, from the libvirt-test-API root directory enter: # python main.py """ Is this also True for the Fedora package? Seems kinda weird. -- 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
Re: [Fedora-packaging] Let's standardize the way to disable tests during RPM build?
On 05. 06. 20 16:45, Tomas Orsava wrote: On 6/5/20 4:39 PM, Richard W.M. Jones wrote: On Fri, Jun 05, 2020 at 10:28:39AM -0400, Paul Wouters wrote: Or just a new option to rpmbuild that skips %check ? It exists already: rpmbuild --nocheck. It's not wired into the rest of the stack - eg. you cannot start a Koji build with checks disabled. IMHO that's a good thing, although when we first started doing the RISC-V bootstrap we initially and briefly used this option to disable the tests, for convenience of getting packages built. It might be a good thing for regular builds, but it's sorely missed in scratch builds. Generally, the ability to flip bconds in scratchbuilds would be a huge help over uploading the entire SRPM. Something like: $ fedpkg build --scratch --without tests --without optimizations -- 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-06-08.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change CutyCapt orphan 3 weeks ago abgraph orphan 1 weeks ago accrete orphan 1 weeks ago amqp irina, orphan0 weeks ago apache-commons-vfsmizdebsk, orphan 3 weeks ago astronomy-backgrounds orphan 1 weeks ago astronomy-bookmarks orphan 1 weeks ago cdk cicku, fale, orphan 1 weeks ago cinnamon-applet-globalappmenu orphan 5 weeks ago cinnamon-themes jcpunk, orphan 5 weeks ago coro-mock orphan 0 weeks ago csvdiff orphan 0 weeks ago cvsgraph bojan, orphan1 weeks ago cvsplot orphan 1 weeks ago cvsweborphan 1 weeks ago dateformatorphan 3 weeks ago drawtkorphan 2 weeks ago eris bruno, orphan1 weeks ago felix-framework mizdebsk, msimacek, orphan 4 weeks ago felix-osgi-obr-resolver orphan 4 weeks ago fritzing logic, orphan0 weeks ago fritzing-partslogic, orphan0 weeks ago gcx orphan 1 weeks ago ggobi orphan 1 weeks ago glassfish-hk2 orphan 2 weeks ago gnome-themes alexl, caillon, caolanm, 3 weeks ago gnome-sig, johnp, mbarnes, orphan, rhughes, rstrode, ssp gpredict orphan 1 weeks ago gtkglextmmchurchyard, orphan 0 weeks ago invokebinder mmorsi, orphan 0 weeks ago ircd-ratbox orphan 1 weeks ago irssi huzaifas, jskarvad, orphan 1 weeks ago jasmine nodejs-sig, orphan, patches 3 weeks ago jasmine-node nodejs-sig, orphan, patches 3 weeks ago jp2a mayorga, orphan 0 weeks ago js-json nodejs-sig, orphan 3 weeks ago js-zlib nodejs-sig, orphan, patches, 3 weeks ago zbyszek json-tableorphan 0 weeks ago kchildlockorphan 2 weeks ago kitsune orphan 3 weeks ago libglade2 alexl, caillon, caolanm, 1 weeks ago gnome-sig, johnp, mbarnes, orphan, rhughes, rstrode, ssp maven-release jcapik, orphan 4 weeks ago mencalorphan 1 weeks ago mercator bruno, orphan1 weeks ago mocha nodejs-sig, orphan, patches 3 weeks ago nexcontrolorphan 1 weeks ago nightfall orphan 1 weeks ago nodejs-abbrev nodejs-sig, orphan, patches 3
Re: Schedule for Mondays's FESCo Meeting (2020-06-08) — proposal to cancel
On 08. 06. 20 13:36, Petr Šabata wrote: Hi, while we have some open tickets, we're waiting for the Modularity presentation later this week. In the meantime, the discussion continues in the tickets. There doesn't appear to be anything else to discuss today so I'm proposing we cancel the meeting. +1 I'll chair the next one. If it is needed, I can chair the next one (I'm not being re-elected this time). -- 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
[ELN] Opt out python2.7 from ELN
Hello, as a maintainer of the python2.7 package I was surprised to see it being built for ELN and I like to start a discussion on whether and how can I opt out this deprecated package from ELN. Since there is no tracker or dedicated mailing list, I am following the advice given somewhere else on devel, to use this list, possibly with the [ELN] marker in subject. Thanks, -- 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
Re: Upcoming fedoraproject Datacenter move reminder and plans
On 02. 06. 20 18:40, Kevin Fenzi wrote: Out detailed checklist for these migrations is available at https://hackmd.io/@fedorainfra2020/rJpsA4FLL The https://status.fedoraproject.org/ page links to a different but similar hackmd.io document. Should it be replaced by this one? -- 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
Re: Day one of the datacenter service migration
On 09. 06. 20 11:26, Kevin Kofler wrote: Kevin Fenzi wrote: The openshift apps move caused a outage for the elections app (both a short one while it was entirely down, and another short time when authentication wasn't yet working) Doing a migration of the elections app in the middle of a voting period sounds like very bad timing to me. Will the voting period be extended to compensate for the outage? The outage of elections app was very short and not near the deadline (so people affected had (still have) a chance to come back a bit later). I don't think it satisfies an extended voting period. -- 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
Re: [Fedora-packaging] Re: Let's standardize the way to disable tests during RPM build?
On 09. 06. 20 12:21, Vít Ondruch wrote: That won't be different for what was the original question here, i.e. conditionally disable tests. bconds are what we have for better or worse. And really, this seems about bootstrapping not disabling tests, which are not completely different, but nobody can objects bootstrapping, while disabling tests might be good just to improve build speed and nothing else. That should never happen in production environment IMO. FTR the discussion here is about packages that already have a bcond/macro to disable tests -- Tomáš proposed a common way of doing it. This discussion is not about adding new conditionals to packages that don't have them. Whether or not disabling tests has legitimate use cases is out of scope here. It happens. We just want it to be more predictable when dealing with packaging in bulk. As a metaphor (arguably not a very good one), imagine combustion motor vehicles. They pollute the environment. We are proposing to introduce colored emission stickers. You are discussing whether we should have such vehicles at all. While such discussion is certainly legitimate, it is out of scope. Sure, if we discard all gasoline- and diesel-powered cars and switch to electric or bicycles or perpetuum mobile, we don't have to put the energy into the emission stickers project. But how likely is that? -- 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
Re: [ELN] Opt out python2.7 from ELN
On 10. 06. 20 11:09, Vít Ondruch wrote: You should probably open PR modifying this file: https://github.com/minimization/content-resolver-input/blob/master/configs/view-eln.yaml Thanks. I don't understand that file and hence I won't open PRs to it (not until I understand the relation between this file and ELN). -- 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
Re: [ELN] Opt out python2.7 from ELN
On 08. 06. 20 16:49, Miro Hrončok wrote: Hello, as a maintainer of the python2.7 package I was surprised to see it being built for ELN and I like to start a discussion on whether and how can I opt out this deprecated package from ELN. I also see the python3.6 package being rebuilt for ELN and would also like for that one to be removed. It is packaged for developers so they can test their software, not as something to put to a next version of a enterprise distribution. Thanks, -- 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
Re: [ELN] Opt out python2.7 from ELN
On 11. 06. 20 13:09, Miro Hrončok wrote: On 08. 06. 20 16:49, Miro Hrončok wrote: Hello, as a maintainer of the python2.7 package I was surprised to see it being built for ELN and I like to start a discussion on whether and how can I opt out this deprecated package from ELN. I also see the python3.6 package being rebuilt for ELN and would also like for that one to be removed. It is packaged for developers so they can test their software, not as something to put to a next version of a enterprise distribution. Both packages are added via: https://github.com/minimization/content-resolver-input/pull/25 But I am not sure if this is enough to block them from ELN. -- 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
Re: git merge issue
On 11. 06. 20 13:41, Richard Shaw wrote: remote: *** Your commits contain a bad merge: remote: *** 47456e93 2020-06-10 Merge branch 'master' into tmp/mingw*** Please rebase on top of this commit in tmp/mingw: remote: *** a596a086 2020-06-10 Initial commit for MinGW 64bit builds. This sounds like some hook of their own. They are asking you to rebase your changes instead of merging. -- 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
Re: Searching a new home for my packages
On 12. 06. 20 21:37, Thomas Spura wrote: Hi all, unfortunately, I don't find much time anymore to look for my packages .. Due to that, I would like to step down as the primary maintainer and am searching for a new home for my packages! On most of them, I am co-maintainer and the following are the ones, where I am maintainer (and hope I didn't forget one, if so, please let me know): - python-jupyter-client - python-jupyter-core I can take the above two, I've been co-maintaining them for some time. FAS churchyard. - python-matplotlib I think qulogic would be the de facto maintainer here. - ipython Please assign this package to lbalhar who effectively maintains it. -- 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
Re: Searching a new home for my packages
> and hope I didn't forget one, if so, please let me know I found python-mglob python-minimock python-zmq scipy zeromq. Thanks for maintaining the package in the past and for doing this. ___ 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
Re: Searching a new home for my packages
On 13. 06. 20 13:54, Thomas Spura wrote: - *scipy* (seems to be mostly maintained by Orion/Miro now) I only "maintain" it when absolutely necessary and if there is a volunteer, I'd rather not. -- 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-06-15.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change CutyCapt orphan 4 weeks ago abgraph orphan 2 weeks ago accrete orphan 2 weeks ago amqp irina, orphan1 weeks ago apache-commons-vfsmizdebsk, orphan 4 weeks ago astronomy-backgrounds orphan 2 weeks ago astronomy-bookmarks orphan 2 weeks ago cdk cicku, fale, orphan 2 weeks ago cinnamon-applet-globalappmenu orphan 7 weeks ago coro-mock orphan 1 weeks ago csvdiff orphan 1 weeks ago cvsgraph bojan, orphan2 weeks ago cvsplot orphan 2 weeks ago cvsweborphan 2 weeks ago datanucleus-maven-parent orphan 0 weeks ago dateformatorphan 4 weeks ago drawtkorphan 3 weeks ago ebay-cors-filter orphan 0 weeks ago eris bruno, orphan2 weeks ago felix-framework mizdebsk, msimacek, orphan 5 weeks ago felix-osgi-obr-resolver orphan 5 weeks ago fritzing logic, orphan1 weeks ago fritzing-partslogic, orphan1 weeks ago gcx orphan 2 weeks ago ggobi orphan 2 weeks ago glassfish-hk2 orphan 3 weeks ago gnome-themes alexl, caillon, caolanm, 4 weeks ago gnome-sig, johnp, mbarnes, orphan, rhughes, rstrode, ssp gobby05 kevin, orphan1 weeks ago gpredict orphan 2 weeks ago gtkglextmmchurchyard, orphan 1 weeks ago invokebinder mmorsi, orphan 1 weeks ago ircd-ratbox orphan 2 weeks ago jasmine nodejs-sig, orphan, patches 4 weeks ago jasmine-node nodejs-sig, orphan, patches 4 weeks ago javolutionorphan 0 weeks ago jp2a mayorga, orphan 1 weeks ago js-jquery-datetimepicker orphan 0 weeks ago js-json nodejs-sig, orphan 4 weeks ago js-zlib nodejs-sig, orphan, patches, 4 weeks ago zbyszek json-tableorphan 1 weeks ago kchildlockorphan 3 weeks ago kitsune orphan 4 weeks ago maven-release jcapik, orphan 6 weeks ago mencalorphan 2 weeks ago mercator bruno, orphan2 weeks ago mnemosyne itamarjp, jpopelka, orphan, 0 weeks ago rathann mocha nodejs-sig, orphan, patches 4 weeks ago nexcontrolorphan 2 wee
Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages
On 15. 06. 20 21:56, Igor Raits wrote: I fully agree with the benefits, however I do not like the approach. Why not to teach DNF system-upgrade about special flag (like --remove- unmaintained-packages) that will take installed packages, available packages and remove those that do not exist in the target repo? I also think this is better than the proposed change. However, if we cannot have this yet, maybe the change is the best we could get now? That said, without 100 % automation, the proposed system is not manageable either. -- 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
Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package
On 16. 06. 20 1:31, Miroslav Suchý wrote: Dne 15. 06. 20 v 22:10 Ben Cotton napsal(a): We install/keep fedora-repos-modular by default, users (admins) can uninstall it if desired. No defaults are changed How you manage to have it installed by default? It is not obvious from the linked PR to me. I don't know yet. There are 3 possible ways I was abele to think of: - kickstarts - comps - compose configuration? Originally, I was thinking I'll just add it to the same kickstart/comps as fedora-repos, unfortunately, I cannot see fedora-repos in either, so I will have to figure out trough what does the fedora-repos go in (I guess it is fedora-release-common). I think we can add it to fedora-repo.ks or @core but I will yet to consult this with releng. I just want to be sure it will be installed when @buildsys-build group is installed. Otherwise some mock builds may fail. What kind of mock builds need Fedora modular repos? Could you elaborate? I thought mock uses repos defined in mock roots configuration. -- 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
Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages
On 15. 06. 20 21:47, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.
My general feedback:
+ I agree that removing retired and otherwise removed packages on release
boundary upgrade is a reasonable default (with possible opt out).
- I do not think that doing this via obsoletes is the best way to achieve that
goal. Already now, the situation is confusing to users wrt
fedora-obsolete-packages. (However I realize that this is something that can be
driven by a proposal like this easier than driving dnf system upgrade behavior
changes.)
- I do not want to maintain the information in the package metadata and keep it
up to date. Who does this? Note that releng does not follow the linked
sop_retire_orphaned_packages.rst at all. And even if we manage to get "fedpkg
retire" do the thing 100 % automatically, note that if a package gets removed
from Fedora N, and is obsoleted via fedora-obsolete-packages (or
fedora-retired-packages in case of this proposal), every time it is updated in
Fedora N-1 and/or Fedora N-2, the obsoleted version must be updated. There is no
automation for this and I have been doing it manually when people file bugzillas
or complain on the mailing lists. It is an ungrateful, tedious and never ending job.
- There are retired packages ("components", "source packages") and removed
packages ("built packages", "binary", "subpackages"). The problem is that when
we retire a component, we need to obsolete all packages it (used to) create.
Naturally, this is not always easy to grasp for packagers: Even the change does
not consider the difference at all. Retirement also isn't the only way to remove
a package (subpackages get removed as well).
Generally, I think we should instead strive to have configurable bahavior of dnf
system-upgrade:
option 1) broken deps block upgrades, user go figure (status quo)
option 2) broken deps of packages not part of distupgrade repository behave
like --allowerasing
option 3) all packages not part of distupgrade repository are removed on
distro boundary upgrade
option 4) --allowerasing (already possible)
With alterations for 2/3:
suboption a) this affects all packages
suboption b) this affects only packages installed from "system repos"
(Suboption b) can be achieved trough a .repo file configuration option.)
Then we can have a discussion about the best default for Fedora.
Such solution obviously requires somebody to design it, code it, test it,
support it and maintain it. I cannot speak for the software management team, but
I guess they would have reasons not to do that (such as capacity reasons).
The solution proposed in the change OTOH requires somebody to create the
package, create the automation, keep it up to date, explain to users how to opt
out, explain to packagers what to do, fight broken data, keep it up to date
after the data has been changed by a provenpackager who doesn't understand this
(happens every once in a while with fedora-obsolete-packages), test it
continuously, support different datasets for up to 4 different releases.
As one of the fedora-obsoelte-packages maintainers, I have capacity reasons not
to do this.
--
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
Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package
On 16. 06. 20 10:03, Panu Matilainen wrote: Yeah it's a hard dependency of fedora-release-common. I suppose one possibility would be adding a recommends on fedora-repos-modular to fedora-release-common, but weak dependencies have an annoying tendency to creep back in when you're not looking, a kickstart/comps defaults are nicer in that regard. I was originally thinking that fedora-repos should recommend fedora-repos-modular, but due to the annoying nature of getting recommends back on every upgrade of the related package I abandoned the idea. Relevant dnf bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1699672 -- 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
Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package
On 16. 06. 20 11:57, Vít Ondruch wrote: Not mentioned that weak dependencies are disabled in Mock. I don't understand why would the user need fedora-repos-modular automatically pulled into mock when they install fedora-repos there. Could you please elaborate? -- 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
Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package
On 17. 06. 20 12:01, Dridi Boukelmoune wrote: == How To Test == Install Fedora 33 (any edition or flavor), check that modular repos are still installed and enabled by default. Update to Fedora 33 (from Fedora 31 or 32), check that modular repos are still installed and enabled by default. Check that you can remove the fedora-repos-modular package (e.g. via sudo dnf remove fedora-repos-modular) and it removes the modular repos. Check that you can install the fedora-repos-modular package again (e.g. via sudo dnf install fedora-repos-modular) and it adds the modular repos, enabled. If someone manually disables the modular repositories prior to this change, uninstalling and reinstalling the package wouldn't make any difference because the files are %config(noreplace) and would be left alone because of the modification. Unless you had plans to deal with that too. I don't, I'll adapt the how to test section. -- 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
Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package
On 17. 06. 20 14:31, Vít Ondruch wrote: Quoting the original email which started this sub-thread: Dne 15. 06. 20 v 22:10 Ben Cotton napsal(a): We install/keep fedora-repos-modular by default, users (admins) can uninstall it if desired. No defaults are changed How you manage to have it installed by default? It is not obvious from the linked PR to me. I just want to be sure it will be installed when @buildsys-build group is installed. Otherwise some mock builds may fail. However, my question in the original email remains unanswered. What kind of mock builds need Fedora modular repos inside the mock root? I thought mock uses repos defined in mock roots configuration. -- 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
Re: RHEL 9 and modularity
On 18. 06. 20 15:24, Josh Boyer wrote: Basically this email just says "We decided for Modularity in RHEL 9 and we would like to do it in Fedora Infrastructure first". Mostly, yes. We were told there was ambiguity on whether modularity would be used in RHEL 9 or not. Very clearly it will, so I wanted to get ahead of that. I wonder where did this ambiguity came from. I always considered this as a very well known fact, but thanks for saying it explicitly, Josh. -- 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
Re: [ELN] Opt out python2.7 from ELN
On 11. 06. 20 18:04, Miro Hrončok wrote: On 11. 06. 20 13:09, Miro Hrončok wrote: On 08. 06. 20 16:49, Miro Hrončok wrote: Hello, as a maintainer of the python2.7 package I was surprised to see it being built for ELN and I like to start a discussion on whether and how can I opt out this deprecated package from ELN. I also see the python3.6 package being rebuilt for ELN and would also like for that one to be removed. It is packaged for developers so they can test their software, not as something to put to a next version of a enterprise distribution. Both packages are added via: https://github.com/minimization/content-resolver-input/pull/25 But I am not sure if this is enough to block them from ELN. Stephen, could you please clarify? Is this a proper way to get packages blocked from ELN? Also, Is this a proper way to discuss ELN content? There was no reply from the ELN SIG for quite some time, not sure if you were aware of the thread. Thanks, -- 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
Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros
On 19. 06. 20 23:11, Ben Cotton wrote: All make invocations in spec files that don't use the install target will be modified to use the %make_build macro Many Python packages build Sphinx documentation with variant of "make html". Such invocation will always be just 1 job. Hence there is no benefit of parallel make. Replacing it with %make_build will only make it harder to read. Can we exclude such cases? Or do we want all make invocations to be mecronized, even if there is no benefit? -- 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
Re: Orphaned 215 packages
On 20. 06. 20 3:11, Stuart D Gathman wrote: On Thu, 18 Jun 2020, Stephen Gallagher wrote: Stewardship SIG guy speaking :) If you have a limited set of packages that you want to keep working, e.g. to keep a minimal environment available to build other NodeJS rpm packages in fedora, then that's exactly what the Stewardship SIG was originally intended to to, albeit for a limited time only. We also have some tooling to check leaf package status and analyze dependency trees, which would also help here. I have some packages depending on indirectly on nodejs things being retired. How do I find out which ones I need to save? Try https://churchyard.fedorapeople.org/orphans.txt Search for your FAS username to get the list and also the dependency chain. (The data might be a bit outdated, see modification time of the file.) -- 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
Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros
On 20. 06. 20 14:47, Andy Mender wrote: On Sat, 20 Jun 2020 at 00:38, Miro Hrončok <mailto:mhron...@redhat.com>> wrote: On 19. 06. 20 23:11, Ben Cotton wrote: > All make invocations in spec files that don't use the install target will be > modified to use the %make_build macro Many Python packages build Sphinx documentation with variant of "make html". Such invocation will always be just 1 job. Hence there is no benefit of parallel make. Replacing it with %make_build will only make it harder to read. Can we exclude such cases? Or do we want all make invocations to be mecronized, even if there is no benefit? The way I understand it is that %make_build would be a replacement for the "make all" target with N jobs, which is called by default when you just run "make". The proposal says all make invocations. That would be the all-in-1 scenario when you want to build the main binaries, docs and examples. If there is only 1 target (html) and you run "make" with N jobs, there is no downside, because only that single target gets picked up. No downside when building, but downside when reading the spec file. I really like the proposal and kind of sort of agree with Tomasz that if a build requires -j1 explicitly and fails with -jN, it means the target dependency tree was not defined properly and should be fixed. That is not the case here. -- 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
Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros
On 20. 06. 20 23:18, Björn Persson wrote: Also: Is it set in stone that "make_build" means "make in parallel" and nothing else? If so, why isn't the macro called "parallel_make"? Or is it the case that "make_build" means "the typical make command to use in a build stage", and a future version of the macro may include other parameters that are considered useful in a build stage but may not be appropriate for other use cases? In that case the macro should only be applied in the %build section, and any make invocation that looks less than typical should be left alone. Excellent point, Björn! -- 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
Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-06-22.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change CutyCapt orphan 5 weeks ago ORBit2alexl, caillon, caolanm, danw, 0 weeks ago gnome-sig, johnp, mbarnes, orphan, rhughes, rstrode, ssp abgraph orphan 3 weeks ago accrete orphan 3 weeks ago amqp irina, orphan2 weeks ago apache-commons-vfsmizdebsk, orphan 5 weeks ago astronomy-backgrounds orphan 3 weeks ago astronomy-bookmarks orphan 3 weeks ago atoum orphan, trasher 0 weeks ago coro-mock orphan 2 weeks ago csvdiff orphan 2 weeks ago cvsgraph bojan, orphan3 weeks ago cvsplot orphan 3 weeks ago cvsweborphan 3 weeks ago datanucleus-maven-parent orphan 1 weeks ago dateformatorphan 5 weeks ago drawtkorphan 4 weeks ago ebay-cors-filter orphan 1 weeks ago eris bruno, orphan3 weeks ago felix-framework mizdebsk, msimacek, orphan 6 weeks ago felix-osgi-obr-resolver orphan 6 weeks ago gcx orphan 3 weeks ago ggobi orphan 3 weeks ago glassfish-hk2 orphan 4 weeks ago gnome-themes alexl, caillon, caolanm, 5 weeks ago gnome-sig, johnp, mbarnes, orphan, rhughes, rstrode, ssp gobby05 kevin, orphan1 weeks ago gpredict orphan 3 weeks ago gtkglextmmchurchyard, orphan 2 weeks ago icon-slicer alexl, caillon, caolanm, 0 weeks ago gnome-sig, johnp, mbarnes, orphan, rhughes, rstrode, ssp invokebinder mmorsi, orphan 2 weeks ago ircd-ratbox orphan 3 weeks ago jasmine nodejs-sig, orphan, patches 5 weeks ago jasmine-node nodejs-sig, orphan, patches 5 weeks ago javolutionorphan 1 weeks ago jp2a mayorga, orphan 2 weeks ago js-jquery-datetimepicker orphan 1 weeks ago js-json nodejs-sig, orphan 5 weeks ago js-zlib nodejs-sig, orphan, patches, 5 weeks ago zbyszek kchildlockorphan 4 weeks ago kitsune orphan 5 weeks ago libgnomecanvasalexl, caillon, caolanm, 0 weeks ago gnome-sig, johnp, mbarnes, orphan, rhughes, rstrode, ssp loudmouth fale, lkundrak, maha, orphan,0 weeks ago otaylor mencalorphan 3 weeks ago mercator
Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)
On 22. 06. 20 15:02, François Cami wrote: Hi, On Mon, Jun 22, 2020 at 2:38 PM Miro Hrončok wrote: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-06-22.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change nodejs-wordwrap nodejs-sig, orphan, patches 5 weeks ago nodejs-yargs (maintained by: fcami, nodejs-sig, pvoborni) nodejs-yargs-3.2.1-12.fc32.noarch requires npm(wordwrap) = 1.0.0 The FreeIPA project switched [0] from uglify-js to python-rjsmin. As a result, neither FreeIPA, Petr (pvoborni) nor myself are nodejs-yargs users anymore. Additionally, updating this package to the latest version would require bringing more dependencies into Fedora [1]. We do not plan to retire it ourselves just in case anyone needs it and would take nodejs-wordwrap too. In short: nodejs-yargs package will be retired unless someone adopts it. I suggest you explicitly orphan it in that case. Otherwise it won't be retired, but it will be broken and you will get bugzillas opened. -- 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
Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros
On 22. 06. 20 17:21, Tom Stellard wrote: On 06/19/2020 03:37 PM, Miro Hrončok wrote: On 19. 06. 20 23:11, Ben Cotton wrote: All make invocations in spec files that don't use the install target will be modified to use the %make_build macro Many Python packages build Sphinx documentation with variant of "make html". Such invocation will always be just 1 job. Hence there is no benefit of parallel make. Replacing it with %make_build will only make it harder to read. Can we exclude such cases? Or do we want all make invocations to be mecronized, even if there is no benefit? The reason I put in the proposal that all make invocations would be updated, is because this is easier to script and it would be hard for someone who doesn't know the package to make the call about which invocations don't need to use parallel make. However, this issue is also part of the reason I included a 1 week review period, for each change. I think it would be reasonable for a maintainer to reject a change for something like `make html` if they felt it was making the spec file worse with no benefit. And that works, however I am trying to save you some work as well :) What if I updated the proposed documentation change to say that %make_build must be used for 'code building targets', check, and install, but is optional otherwise? That would certainly %make_build more sense to me, thanks. -- 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
Re: RHEL 9 and modularity
On 18. 06. 20 21:22, Josh Boyer wrote: The introduction of default module streams was a direct result of wanting to help customers that are used to running 'yum install mariadb' still be able to do that. Hello Josh. I'd like to ask whether RHEL 9 has decided for default modular streams despite their failure in Fedora, whether this decision is final and what was the reasoning behind it. When discussing default modular streams in ELN, we have heard that ELN needs default streams because RHEL 9 needs them. I would like to know if this information is something that comes from RHEL leadership directly or whether it is a personal option of the people who said such things. Thanks, -- 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
Re: RHEL 9 and modularity
On 23. 06. 20 8:50, Zbigniew Jędrzejewski-Szmek wrote: Hi Josh, Miro, I think there has been a misunderstanding. I'm pretty sure Miro's question is about "default modules" not "default streams" (i.e. "modules enabled by default" vs. "the stream of a module to use when a different one is not explicitly selected"). Default streams are not subject of much discussion. There is no plan to limit them either in Fedora or ELN. But from your reply it is not clear which of those you have in mind. Let's please clarify what we're talking about first... Hello Zbyszek. My question is about "default modular streams" i.e. about the automatically enabled modular streams filtering non-modular content out of dnf transactions. The thing that is prohibited in Fedora. https://pagure.io/fedora-docs/modularity/blob/master/f/modules/ROOT/pages/glossary.adoc#_21 There is no "the stream of a module to use when a different one is not explicitly selected" concept in current modularity without also having "modules enabled by default". I would love to have that instead, but we don't. -- 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
Re: RHEL 9 and modularity
On 23. 06. 20 13:29, Josh Boyer wrote: (It*may* be possible to automatize this, but not as easily as with singular packages. And considering that non-modularized packages need to be handled too, there will be at least two paths.) - (hypothetically) if we have default modules in eln, and work is done in those modules and skipping rawhide (for example by not building the packages in rawhide), we have an unpleasant situation where eln and rawhide diverge. This is a very tenuous strawman. You could also run into a case where ELN forbids modules or default module streams and the maintainers simply choose not to maintain anything in Fedora at all. That's far worse than divergence in my opinion. When ELN was proposed and discussed, separate eln branches were proposed by several Fedora and RHEL maintainers. It was dismissed, and it was said repeatedly that rawhide/ELN divergence MUST be avoided. I wonder if that requirement has changed. Fortunately, I think neither are actually likely and this part of the conversation seems like it's pointless to debate. This has happened in the past when Fedora had default modular streams. Whether likely or not to repeat, we have experience with the problem, so the discussion is not pointless 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
Re: RHEL 9 and modularity
On 23. 06. 20 13:43, Josh Boyer wrote: On Tue, Jun 23, 2020 at 7:36 AM Miro Hrončok wrote: On 23. 06. 20 13:29, Josh Boyer wrote: (It*may* be possible to automatize this, but not as easily as with singular packages. And considering that non-modularized packages need to be handled too, there will be at least two paths.) - (hypothetically) if we have default modules in eln, and work is done in those modules and skipping rawhide (for example by not building the packages in rawhide), we have an unpleasant situation where eln and rawhide diverge. This is a very tenuous strawman. You could also run into a case where ELN forbids modules or default module streams and the maintainers simply choose not to maintain anything in Fedora at all. That's far worse than divergence in my opinion. When ELN was proposed and discussed, separate eln branches were proposed by several Fedora and RHEL maintainers. It was dismissed, and it was said repeatedly that rawhide/ELN divergence MUST be avoided. I wonder if that requirement has changed. Divergence where? At the source level? Why would the existence of a default module in ELN cause divergence at the source level? It wouldn't. The rawhide sources would be used for the module build in ELN. I ma concerned about divergence at source level. Modules in Fedora are built from stream branches. Rawhide content is built from the "master" branch. This is the first time I've heard that rawhide sources would be used for the module build in ELN and it certainly makes the entire thing more appealing. I've already asked about this in: https://pagure.io/fesco/issue/2390#comment-659188 If you mean at the binary level, then I have no idea how anyone possibly thinks ELN and Rawhide are the same because ELN is built with entirely different flags, settings, etc. No, I don't. Fortunately, I think neither are actually likely and this part of the conversation seems like it's pointless to debate. This has happened in the past when Fedora had default modular streams. Whether likely or not to repeat, we have experience with the problem, so the discussion is not pointless at all. You seem to be concerned less about divergence and more about abandonment of packages in Fedora, at least in ways counter to how the default distribution is built. You could come up with some guidelines on usage of ELN modules that require existing content to be maintained as it is in Fedora if that's what you want to ensure. It's onerous and causes extra work, but allows people to do their work in the open. However, if you prevent that from happening entirely, you run the risk of them abandoning the packages entirely which is counter to your goal (I think). I can totally support that. Thanks. -- 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
Re: RHEL 9 and modularity
ey are packaging, etc. It remains unclear to me why Fedora would go out of its way to disallow usage of default streams in ELN. I understand they can present some issues if used incorrectly, or for something that is core to non-modular content, but the concept of a default stream being forbidden outright is strange. Default streams in ELN don't impact the wider Fedora distribution and removing them eliminates options and flexibility, forcing their usage to become a downstream-only concept which is exactly what we're trying to avoid with ELN to begin with. I haven't asked the questions to argue about this. I just wanted to get things clarified, so we can have a discussion at FESCo based on some actual RHEL information instead of guesses. Frankly, I don't know how RHEL decisions are made or who makes them. As a Fedora package maintainer (and hence by extension an ELN package maintainer) I just want to know what decisions were made wrt default streams in RHEL 9 and why, so I can understand the request for default streams in ELN better. Thank you very much for sharing some RHEL information here. -- 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
Re: RHEL 9 and modularity
On 23. 06. 20 14:30, Josh Boyer wrote: On Tue, Jun 23, 2020 at 8:01 AM Miro Hrončok wrote: On 22. 06. 20 21:36, Josh Boyer wrote: I'd like to ask whether RHEL 9 has decided for default modular streams despite their failure in Fedora, whether this decision is final and what was the reasoning behind it. That's an interesting question. I think for the purposes of this discussion, we should acknowledge that usage of default module streams in Fedora and usage in RHEL aren't equivalent. Therefore, failure of adoption in Fedora doesn't necessarily equate to failure in RHEL. With that context, I'll continue. Before we continue with that context, could you please elaborate on this? If I must. Not at all, feel free to not continue this conversation if it bothers you in any way. But I think it is extremely helpful to have the things said here and I thank you for doing it. What makes RHEL so different that the failure is not relevant to it? Is it the stable nature of RHEL content? Is it the limited scope of RHEL content? Is it the less "wild" development process? Is it something different? Primarily, RHEL: - Moves much much slower - Has a base distribution that is extremely stable and does not version bump often across the "platform" layer of libraries, etc - Has a lifecycle that is equivalent to 20 Fedora releases (yes, twenty) - Has a broader downstream ecosystem of ISVs and products that require stability and continuity I can see technical challenges with default modular streams in ELN, because even thou ELN is RHEL-like, the content is Rawhide-like and hence most of the above does not apply. (Notice I say challenges: I don't say this is a reason why we should not have this.) You are smart enough to come up with your own reasons. The fact that you phrased them as questions rather than statements highlights your perspective on the discussion more than any actual merit of what I just provided above. I don't even know what to reply to this. If this is the way to handle the conversation, I'd rather end it here. Thanks for your replies, Josh. AFAIK Stephan and Igor are working on general guidelines for default streams in ELN and any further discussion should probably happen after that. -- 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
Re: RHEL 9 and modularity
On 23. 06. 20 15:42, Miro Hrončok wrote: AFAIK Stephan and Igor Sorry, I've meant Stephen. -- 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
Re: Please BuildRequire python3-setuptools explicitly
On 23. 06. 20 18:36, Adam Williamson wrote: IMBW, but I think I recall the Python packaging guidelines specifically said that you could or should (I forget which) just BR python-devel and not BR python-setuptools at some point. At this point there seems to be no explicit mention, but the sample spec file looks a lot like a project that uses setuptools, but does not explicitly BuildRequire it... I'll work towards adding the explicit BR there. -- 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
Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)
> On Mon, Jun 22, 2020 at 8:36 AM Miro Hrončok > We've been discussing this in the other thread about nodejs, but I > figured I'd post this here. I've already taken mocha, and I plan to > take the following 41 nodejs packages (at least temporarily...)-- > these appear to be the common dependencies of mocha and discord-irc > that are currently orphaned. > > > (I ran "dnf repoquery --requires --resolve --recursive" to get this > list, and then filtered it against what was orphaned-- there are other > nodejs packages I own that I care less about so I only wanted to take > what I actually needed for mocha and discord-irc. I think this is the > complete list; if I'm wrong, I guess I'll find out.) > > Can I do this via releng ticket or do I need to actually go to each > page on Pagure and click the button? I've done it in bulk. Thanks for talking them. ___ 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
Re: Please BuildRequire python3-setuptools explicitly
> On Tue, Jun 23, 2020 at 06:26:23PM +0200, Tomas Hrnciar wrote: > > This package depends on python3-devel. However the last build.log: > > > https://kojipkgs.fedoraproject.org//packages/qemu/5.0.0/2.fc33/data/logs/... > > does not contain the substring /setupto/ anywhere. Nor does the > upstream git repo. How do we know it is required? $ fedpkg prep $ rg setuptools qemu-5.0.0 qemu-5.0.0/capstone/bindings/python/setup.py 10:from setuptools import setup 14:from setuptools.command.bdist_egg import bdist_egg 176:from setuptools.command.develop import develop Is this file used during the build? If not, it's a false hit. ___ 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
Re: Please BuildRequire python3-setuptools explicitly
On 23. 06. 20 21:58, Michael J Gruber wrote: The hit on portmidi is a false positive: while it allows to be built with setuptools it by default does not, and the spec does not override the default. Is there a way to specify this (other than patching out anything "setuptools" from the source)? Would it make sense to explicitly enable setuptools based build instead? Among other things, it has richer metadata when the package is installed. -- 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
Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)
On 23. 06. 20 21:11, Ben Rosser wrote: Thanks Miro, much appreciated! You are welocme. However, I am afraid I have some bad news. The recent report in https://churchyard.fedorapeople.org/orphans.txt still mentions another 40 packages: tc01: nodejs-optimist, nodejs-burrito, nodejs-cookiejar, nodejs-exit, nodejs-bunker, nodejs-abbrev, nodejs-which, nodejs-reduce-component, nodejs-osenv, nodejs-methods, nodejs-resolve, nodejs-charm, nodejs-formidable, nodejs-temporary, nodejs-mime, nodejs-underscore-dot-string, nodejs-nopt, nodejs-expect-dot-js, nodejs-superagent, nodejs-findup-sync, nodejs-runforcover, nodejs-traverse, nodejs-supertest, nodejs-ejs, nodejs-yamlish, nodejs-through, nodejs-js-yaml, nodejs-buffer-equal, nodejs-getobject, nodejs-slide, nodejs-better-assert, nodejs-bindings, nodejs-npmlog, nodejs-defined, nodejs-package, nodejs-hooker, nodejs-ansi, nodejs-eventemitter2, nodejs-callsite, nodejs-component-emitter, nodejs-bytes -- 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
Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)
On 24. 06. 20 1:07, Ben Rosser wrote: Some of my nodejs packages are an artifact of a failed attempt to package quassel-webserver [1], which I eventually gave up on, and so those could probably be safely retired. But looking at the orphans report, I'm not confident I correctly separated out the dependency trees, and this is now somewhat time sensitive, so I suppose it's better safe than sorry. (At least this is "only" 80 out of 200 packages...) I will try to isolate the mocha deps. -- 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
Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)
On 24. 06. 20 1:10, Miro Hrončok wrote:
On 24. 06. 20 1:07, Ben Rosser wrote:
Some of my nodejs packages are an artifact of a failed attempt to
package quassel-webserver [1], which I eventually gave up on, and so
those could probably be safely retired. But looking at the orphans
report, I'm not confident I correctly separated out the dependency
trees, and this is now somewhat time sensitive, so I suppose it's
better safe than sorry. (At least this is "only" 80 out of 200
packages...)
I will try to isolate the mocha deps.
import requests
r = requests.get('https://churchyard.fedorapeople.org/orphans.json').json()
chain = r['affected_packages']
orphaned = set(r['status_change'].keys())
todo = {'mocha'}
needed = set()
while todo:
package = todo.pop()
for dep in chain[package]:
if dep not in needed:
needed.add(dep)
todo.add(dep)
needed & orphaned ->
nodejs-better-assert
nodejs-buffer-equal
nodejs-bunker
nodejs-burrito
nodejs-callsite
nodejs-charm
nodejs-ejs
nodejs-nopt
nodejs-runforcover
nodejs-slide
nodejs-traverse
nodejs-yamlish
Should I assign them to you?
--
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
Re: Please BuildRequire python3-setuptools explicitly
On 23. 06. 20 18:43, Miro Hrončok wrote: On 23. 06. 20 18:36, Adam Williamson wrote: IMBW, but I think I recall the Python packaging guidelines specifically said that you could or should (I forget which) just BR python-devel and not BR python-setuptools at some point. At this point there seems to be no explicit mention, but the sample spec file looks a lot like a project that uses setuptools, but does not explicitly BuildRequire it... I'll work towards adding the explicit BR there. https://pagure.io/packaging-committee/pull-request/992 -- 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
Re: RHEL 9 and modularity
On 24. 06. 20 14:41, Vít Ondruch wrote: Having python27 and python36 modules is fail, because these should be 2.7 and 3.6 streams of python module. Oh. We are so sorry for the failure. Could you please report is as a bug in RHEL 8 and explain why it is a problem? -- 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
Re: Please BuildRequire python3-setuptools explicitly
On 24. 06. 20 20:21, Andy Mender wrote: *Packages MAY use the automatic Python dependency generator. This generator uses upstream egg/dist metadata (such as setuptool’s install_requires <https://python-packaging.readthedocs.io/en/latest/dependencies.html>) This is about the runtime dependencies. -- 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
Re: Please BuildRequire python3-setuptools explicitly
On 23. 06. 20 18:26, Tomas Hrnciar wrote: churchyard python-django python-ipykernel python-more-itertools python-ndg_httpsclient thonny All fixed at least in git. The changes should be visible in repoquery upon the next rebuild. -- 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
Re: Avoiding the automatic /usr/bin/python3 dep
On 25. 06. 20 15:50, Richard Hughes wrote:
Hi all,
In fwupd we ship 4 *tiny* python scripts that are useful for ODMs and
other people working with low level firmware blobs. In
https://src.fedoraproject.org/rpms/fwupd/pull-request/2 it was
suggested we split them off as a subpackage to avoid the
/usr/bin/python3 dep which is unwanted on CoreOS. It does seem a bit
crazy to split off a subpackage when the rpm header will be bigger
than the contents. Given these are such small files and certainly not
warranting dragging python3 onto the image, I did hope I could use
%{?python_disable_dependency_generator} to tell rpmbuild to basically
ignore the .py files and not add a /usr/bin/python3 dep on my package
automatically. Unfortunately that seems not to work. Ideas welcome,
thanks!
The %{?python_disable_dependency_generator} will only disable the "Python
dependency generator", described in
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_automatically_generated_dependencies
What you need is to disable is the "shebang dependency generator" from RPM. The
easiest way is to use:
https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
%global __requires_exclude ^%{python3}$
--
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
Orphaned python-jupyterlab-launcher
I've orphaned python-jupyterlab-launcher. I've packaged it in an attempt to package jupyterlab, but I have never got to it :( The package now FTBFS because I have removed tests from the python3-notebook RPM. If somebody wants python-jupyterlab-launcher, I can add python3-notebook-tests subpackage to make it work again. -- 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
List of long term FTBFS packages to be retired in August
Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired from Fedora 33 approximately one week before branching (August 2020). Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ Note that some listed packages are orphaned and hence may be retired even sooner. The packages in rawhide were not successfully built at least since Fedora 31. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers Latest build OpenCoarrays jussilehtolaFedora 30 gpscorrelate tillFedora 30 js-jquery-jqplot xavierb Fedora 30 js-jquery1 nodejs-sig, patches, vondruch Fedora 30 js-jquery2 vondruchFedora 30 js-sizzle nodejs-sig, patches, vondruch Fedora 30 nodejs-path-type jsmith, nodejs-sig Fedora 30 nodejs-temp-write jsmith Fedora 30 nodejs-unique-stream jsmith, nodejs-sig Fedora 30 ocaml-pxp orphan Fedora 30 ocaml-ulex orphan Fedora 30 orpie bowlofeggs, jaredwallaceFedora 30 rubygem-ruby-hmac humaton, mmorsi Fedora 30 xvarstar orphan Fedora 30 The following packages require above mentioned packages: Depending on: gpscorrelate (1) foxtrotgps (maintained by: bubeck) foxtrotgps-1.2.2-5.fc33.x86_64 requires gpscorrelate = 1.6.1-27.fc30 Depending on: js-jquery-jqplot (1) sympa (maintained by: xavierb) sympa-6.2.56-1.fc33.src requires js-jquery-jqplot = 1.0.9-3.fc30 sympa-6.2.56-1.fc33.x86_64 requires js-jquery-jqplot = 1.0.9-3.fc30 Depending on: js-jquery1 (69) R-profvis (maintained by: qulogic) R-profvis-0.3.6-3.fc33.src requires js-jquery1 = 1.12.4-7.fc30 R-profvis-0.3.6-3.fc33.x86_64 requires js-jquery1 = 1.12.4-7.fc30 R-rmarkdown (maintained by: qulogic) R-rmarkdown-2.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 R-rmarkdown-2.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30 copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup) copr-frontend-1.166-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 ghc-pretty-show (maintained by: mathstuf) ghc-pretty-show-1.9.5-3.fc32.x86_64 requires js-jquery1 = 1.12.4-7.fc30 mkdocs (maintained by: cheeselee) mkdocs-1.1.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 mkdocs-1.1.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30 python-XStatic-jQuery (maintained by: mrunge, openstack-sig, rdopiera) python3-XStatic-jQuery-3.4.1.0-2.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 python-sphinx-bootstrap-theme (maintained by: besser82, sic) python3-sphinx-bootstrap-theme-0.8.0-3.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 rubygem-apipie-rails (maintained by: jaruga, ruby-packagers-sig, vondruch) rubygem-apipie-rails-0.5.5-6.fc32.noarch requires js-jquery1 = 1.12.4-7.fc30 R-BiocFileCache (maintained by: spot) R-BiocFileCache-1.12.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-DBItest (maintained by: qulogic) R-DBItest-1.7.0-1.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-V8 (maintained by: qulogic) R-V8-3.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-broom (maintained by: qulogic) R-broom-0.5.6-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-cellranger (maintained by: qulogic) R-cellranger-1.1.0-6.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-clipr (maintained by: qulogic) R-clipr-0.7.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-dbplyr (maintained by: qulogic) R-dbplyr-1.4.3-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-devtools (maintained by: qulogic) R-devtools-2.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-diffobj (maintained by: qulogic) R-diffobj-0.3.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-dplyr (maintained by: qulogic) R
Re: Lua 5.4.0
On 29. 06. 20 20:30, Tom Callaway wrote:
I just built lua 5.4.0 in Rawhide. As with previous major updates of lua, the
package also includes a copy of the lua 5.3 libraries so that rawhide does not
just become broken reps.
Not sure if that was enough to prevent broken deps:
$ repoquery --repo=koji{,-source} --whatrequires 'lua(abi) = 5.3'
lua-argparse-0:0.5.0-10.fc32.noarch
lua-cqueues-0:20190813-3.fc32.x86_64
lua-cyrussasl-0:1.1.0-8.fc32.x86_64
lua-dbi-0:0.7.2-2.fc32.x86_64
lua-event-0:0.4.6-4.fc32.x86_64
lua-expat-0:1.3.0-18.fc32.x86_64
lua-filesystem-0:1.6.3-12.fc32.x86_64
lua-fun-0:0.1.3-12.fc32.noarch
lua-json-0:1.3.2-14.fc32.noarch
lua-ldap-0:1.1.0-15.fc32.x86_64
lua-librs232-0:1.0.3-10.20190917git1c29a27.fc32.x86_64
lua-logging-0:1.3.0-15.fc32.noarch
lua-lpeg-0:1.0.2-2.fc32.x86_64
lua-luaossl-0:20190731-2.fc32.x86_64
lua-luv-0:1.36.0.0-1.fc33.x86_64
lua-moonscript-0:0.5.0-4.fc32.noarch
lua-mosquitto-0:0.3-2.fc32.x86_64
lua-mpack-0:1.0.8-3.fc32.x86_64
lua-posix-0:33.3.1-16.fc32.x86_64
lua-psl-0:0.3-4.fc32.x86_64
lua-sec-0:0.9-2.fc32.x86_64
lua-socket-0:3.0-0.22.rc1.fc32.x86_64
lua-socket-compat-0:3.0-0.22.rc1.fc32.x86_64
lua-term-0:0.07-10.fc32.x86_64
lua-wsapi-0:1.6.1-11.fc32.noarch
lua-wsapi-0:1.6.1-11.fc32.src
luadoc-0:3.0.1-22.fc32.noarch
luarocks-0:3.3.1-1.fc33.x86_64
prosody-0:0.11.5-1.fc33.x86_64
rrdtool-lua-0:1.7.2-10.fc33.x86_64
vicious-0:2.4.1-1.fc33.noarch
$ repoquery --repo=koji{,-source} --whatrequires 'lua(abi) = 5.3' --recursive |
wc -l
3144
$ repoquery --refresh --repo=koji{,-source} --whatprovides 'lua(abi) = 5.3'
(nada)
--
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
Re: Lua 5.4.0
On 30. 06. 20 6:40, Tom Callaway wrote: Okay. I duct taped lua-posix into a "working" state. Also did builds for lua-argparse, lua-expat, lua-lpeg, and rpm (so that the macros say "5.4"). Any and all help is appreciated. Rebuilding what I can. So far: lua-cyrussasl luadoc lua-filesystem lua-fun lua-logging lua-mosquitto lua-psl lua-sec lua-socket lua-wsapi rrdtool vicious -- 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
Re: Lua 5.4.0
On 30. 06. 20 11:02, Miro Hrončok wrote:
On 30. 06. 20 6:40, Tom Callaway wrote:
Okay. I duct taped lua-posix into a "working" state. Also did builds for
lua-argparse, lua-expat, lua-lpeg, and rpm (so that the macros say "5.4").
Any and all help is appreciated.
Rebuilding what I can. So far:
lua-cyrussasl luadoc lua-filesystem lua-fun lua-logging lua-mosquitto lua-psl
lua-sec lua-socket lua-wsapi rrdtool vicious
The current status is:
$ comm -23 <(repoquery --refresh --repo=koji --whatrequires 'lua(abi) = 5.3'
--source | pkgname | sort) <(repoquery --repo=koji --whatrequires 'lua(abi) =
5.4' --source | pkgname | sort)
librs232
lua-cqueues
lua-event
lua-ldap
lua-luaossl
lua-luv
prosody
I will post followups in the F33FailsToInstall bugzillas.
One thing that I found surprising is that all of the packages have a
in-spec-hardcoded Lua version macro that needs to be updated during the rebuild.
Would you accept a PR for lua that adds lua-rpm-macros subpackage with
%{lua_version} (now defined as 5.4)?
--
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
Re: Lua 5.4.0
On 30. 06. 20 16:06, Miro Hrončok wrote:
One thing that I found surprising is that all of the packages have a
in-spec-hardcoded Lua version macro that needs to be updated during the rebuild.
Would you accept a PR for lua that adds lua-rpm-macros subpackage with
%{lua_version} (now defined as 5.4)?
Oh, %{lua_version} already is 5.4, it's just that almost no packages use it.
Sorry for the confusion.
--
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
