Re: Fedora 41 Python 3.13 mass rebuild status
On 10. 06. 24 17:34, Karolina Surma wrote: Hello, The Python 3.13 rebuild is in progress. We plan to merge the side tag soon. So far, we've successfully built 3528 out of 4109 source packages, with 581 remaining to be built. See the list of packages sorted by maintainers at the end of this mail. If your package fails because there is a non-dependency problem, you might have already received a bugzilla from us in the past. If the build failure is related to changes in Python 3.13, it should contain some hints about the problem. If you haven't received a bugzilla from us yet, feel free to open a new one and block the PYTHON3.13 tracking bug. You can verify your package builds with Python 3.13 via a scratch build: $ koji build --scratch f41-python or $ fedpkg build --scratch --target f41-python If successful, you can submit a build to the side tag from the rawhide branch in dist-git repository via: $ fedpkg build --target f41-python Please, don't build Python packages in regular rawhide now. After the side tag is merged, we'll let you know when it's safe to build in regular rawhide again. The remaining failures can be fixed afterwards. I requested the side tag to be merged. https://pagure.io/releng/issue/12155 If you build for f41-python now, there is a risk that the build will fail at tagging time if the side tag is merged during the build. I don't recommend building long builds. Please, still don't build Python packages in rawhide until the side tag is fully merged. Thank you for your patience. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 41 Python 3.13 mass rebuild status
On 10. 06. 24 17:34, Karolina Surma wrote: Hello, The Python 3.13 rebuild is in progress. We plan to merge the side tag soon. So far, we've successfully built 3528 out of 4109 source packages, with 581 remaining to be built. See the list of packages sorted by maintainers at the end of this mail. If your package fails because there is a non-dependency problem, you might have already received a bugzilla from us in the past. If the build failure is related to changes in Python 3.13, it should contain some hints about the problem. If you haven't received a bugzilla from us yet, feel free to open a new one and block the PYTHON3.13 tracking bug. You can verify your package builds with Python 3.13 via a scratch build: $ koji build --scratch f41-python or $ fedpkg build --scratch --target f41-python If successful, you can submit a build to the side tag from the rawhide branch in dist-git repository via: $ fedpkg build --target f41-python Please, don't build Python packages in regular rawhide now. After the side tag is merged, we'll let you know when it's safe to build in regular rawhide again. The remaining failures can be fixed afterwards. I requested the side tag to be merged. https://pagure.io/releng/issue/12155 If you build for f41-python now, there is a risk that the build will fail at tagging time if the side tag is merged during the build. I don't recommend building long builds. Please, still don't build Python packages in rawhide until the side tag is fully merged. Thank you 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
On 10. 06. 24 15:07, Tom Stellard wrote: On 5/31/24 01:55, Karolina Surma wrote: Hello, To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.13 Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build I'm in the middle of updating the LLVM packages in my own side tag, would it work if I tag python3.13.0b2 into my LLVM side-tag and rebuild the LLVM packages there? It works if you merge your side tag later than ours. If you merge it sooner, it breaks the world unless you untag python first (which would presumably break the Python packages built in your side tag). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
On 10. 06. 24 15:07, Tom Stellard wrote: On 5/31/24 01:55, Karolina Surma wrote: Hello, To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.13 Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build I'm in the middle of updating the LLVM packages in my own side tag, would it work if I tag python3.13.0b2 into my LLVM side-tag and rebuild the LLVM packages there? It works if you merge your side tag later than ours. If you merge it sooner, it breaks the world unless you untag python first (which would presumably break the Python packages built in your side tag). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
On 06. 06. 24 16:03, Michael J Gruber wrote: Karolina Surma venit, vidit, dixit 2024-06-06 14:17:10: Hi, On 6/6/24 12:41, Michael J Gruber wrote: Hi there, I'm somewhat confused by the two different coprs @python/python3.13-b1 @python/python3.13 What is the role of which? @python/python3.13 is the main copr used for the continuous Python rebuild since alpha1 and a testing bed for the package maintainers. As its environment rapidly changes, sometimes the obsolete package versions are pulled into the buildroot. In order to simulate the current Fedora environment as close as possible, last week we created a python3.13-b1 copr - a testing repository to bootstrap Python (again) from scratch and make sure we haven't omitted something by accident. I have a package (notmuch) which succeeds locally in mock (against python 3.13) and in @python/python3.13 but fails in @python/python3.13-b1. The failure is probably related to gdb (the python module) usage in a test. My guess is the "main" copr was still using some older package builds, while the python3.13-b1 only contains the newest versions and that exposed the issue in notmuch. We're currently rebuilding everything with Python 3.13.0~beta2 in the main copr and will know in a few hours whether notmuch is still affected. @python/python3.13-b1 was used as a basis for bugzilla, it appears. (The bz entry points to instructions which are not filled in, btw.) Apologies for the inconsistent instructions, that's an oversight. Thanks for the clarification, and no need to apologize :) BTW: With current @python/python3.13-b1, the problem seems to be scripting gdb: ``` /etc/gdbinit:9: Error in sourced command file: Scripting in the "Python" language is not supported in this copy of GDB. /builddir/build/BUILD/notmuch-0.38.3-build/notmuch-0.38.3/test/atomicity.py:11: Error in sourced command file: Undefined command: "import". Try "help". ``` This is from mock --shell. (notmuch's test suite makes it hard to spot these things the easy way.) So, let's hope gdb with py 3.13.0~beta2 will fix scripting. gdb is built twice in the rebuild. The first build is without_python. notmuch probably needs the second build, but there is no way to express that via RPM BuildRequires (unless gdb starts providing something like gdb(python)). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
On 06. 06. 24 9:57, Sandro wrote: On 31-05-2024 10:55, Karolina Surma wrote: TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. What about new packages? Can those be added to rawhide and will they be picked up for the rebuild? Or is it better to wait and submit them after the side tag has been merged? Feel free to add new packages, they will be picked. If you build them in rawhide, it will update the rawhide repo which we use as a source of our to-build package list. If you build them right before we merge the side tag, chances are the builds won't be part of the repo in time. In that case, we will rebuild it after the merge (as well as many others). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GenericError: srpm mismatch for [debuginfo file]
On 29. 05. 24 13:59, Richard W.M. Jones wrote: On Wed, May 29, 2024 at 01:46:43PM +0200, Miro Hrončok wrote: On 29. 05. 24 13:38, Richard W.M. Jones wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=118234666 It failed right at the end with this mysterious error: GenericError: srpm mismatch for /mnt/koji/work/tasks/4737/118234737/ocaml-ocamldoc-debuginfo-5.2.0-1.fc41.x86_64.rpm: (none) (expected ocaml-5.2.0-1.fc41.src.rpm) I have just now kicked off another build in case this was a one-off, but anyone got ideas about this? RPM 4.20 regression. Fix is being cooked at https://src.fedoraproject.org/rpms/rpm/c/9042b409567e8479d6ddafc26e33badbe3bb3457?branch=rawhide I see the rpm package build containing this one failed, with the same failure in debuginfo generation :-( (https://koji.fedoraproject.org/koji/taskinfo?taskID=118237702) Is the bad rpm package going to be untagged? We'll use side tags to build it with old rpm. I was planning to do the OCaml 5.2 rebuild today, but if RPM is full of regressions maybe that's not such a good idea. What do you think? I suggest waiting a day. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GenericError: srpm mismatch for [debuginfo file]
On 29. 05. 24 13:38, Richard W.M. Jones wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=118234666 It failed right at the end with this mysterious error: GenericError: srpm mismatch for /mnt/koji/work/tasks/4737/118234737/ocaml-ocamldoc-debuginfo-5.2.0-1.fc41.x86_64.rpm: (none) (expected ocaml-5.2.0-1.fc41.src.rpm) I have just now kicked off another build in case this was a one-off, but anyone got ideas about this? RPM 4.20 regression. Fix is being cooked at https://src.fedoraproject.org/rpms/rpm/c/9042b409567e8479d6ddafc26e33badbe3bb3457?branch=rawhide -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: are pyproject rpm macros supposed to pick up the license automatically?
On 29. 05. 24 9:48, Karolina Surma wrote: Hi Felix, The missing bit is whether the build backend of pypdf exposes the metadata that pyproject-rpm-macros use to detect the license file. pypdf uses flit-core as its build backend which doesn't implement `License-File` field (it's a part of PEP 639, still in draft and implemented only in a subset of build backends, like setuptools and hatch). Hopefully in the future it'll become a standard. For now, you've got to declare the license file via the %license macro manually. See "Generating the %files section" of https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/README.md for more details. Most importantly, this paragraph: """ %pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-File field are detected. PEP 639 is still a draft and can be changed in the future. It is possible to use the -l flag to declare that a missing license should terminate the build or -L (the default) to explicitly disable this check. Packagers are encouraged to use the -l flag when the %license file is not manually listed in %files to avoid accidentally losing the file in a future version. When the %license file is manually listed in %files, packagers can use the -L flag to ensure future compatibility in case the -l behavior eventually becomes a default. """ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Monday's FESCo Meeting (2024-05-20)
On 20. 05. 24 22:59, Stephen Gallagher wrote: * AGREED: FESCo will permit the inclusion of binaries provided by upstream Python and FFI exclusively for the purposes of loading the installer on MacOS since we have no reasonable way to cross-compile for that platform at this time. (+5, 0, -4) (@sgallagh:fedora.im, 20:01:08) I am a tad sad that this was approved by FESCo without being first discussed with the wider community. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to retire mlocate
On 21. 05. 24 12:29, Fabio Valentini wrote: On Mon, May 20, 2024 at 2:42 PM Michal Sekletar wrote: On Fri, May 17, 2024 at 6:14 PM Michal Sekletar wrote: Hi everyone, We have had a plocate as a drop-in replacement for mlocate for quite a while now. My intention is to retire the mlocate package next week in order to prevent duplication and so that we can focus only on plocate going forward. mlocate is now retired in Rawhide. https://src.fedoraproject.org/rpms/mlocate/c/7277dd5f59db126d1046a6aa5c4077a597dc?branch=rawhide Thanks for the heads-up! Should the package also be added to fedora-obsolete-packages so that it is - if installed - removed on upgrade to Fedora 41? If a specific replacement exists (plocate), I think it should Obsolete it explicitly. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Elections - Voting is now open!
On 20. 05. 24 16:37, Aoife Moloney wrote: Hi Folks, After _much_ troubleshooting and some wonderful folks working with me to help resolve the issues that littered the elections today, I am pleased to say all issues have been resolved, or at least I live in hope that they are! :crosses fingers: ... If you have voted in Council and/or Mindshare, and did not have a claim link for your badge, please revisit your vote as the link has been updated and you should be able to access it. If you can't, email me directly and I will manually award this to you (I cant see who voted so I can't do this without knowing who to send it to). I'm afraid the badge claim link is expired now: """ 410 Gone This resource is no longer available. No forwarding address is given. That invitation is expired. """ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Elections - Voting is now open!
On 20. 05. 24 1:04, Aoife Moloney wrote: Hi all, The F40 elections have now officially opened after a little delay. You can find all of the candidate details in the Elections blog post[1]. We have open positions in Fedora Council, EPEL Steering Committee, Mindshare and Fedora Engineering Steering Committee (FESCo) and the voting period will close on Thursday 30th May @ 23:59:59 UTC sharp so please do take some time to read the wonderful candidate interviews we have received for the various open positions, cast your vote and dont forget to claim your Fedora badge too! [1] https://communityblog.fedoraproject.org/elections-voting-is-now-open/ <https://communityblog.fedoraproject.org/elections-voting-is-now-open/> Hello, there is a "None None" candidate to the EPEL Steering Committee. The link leads to Troy Dawson (tdawson) interview. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 15. 05. 24 13:31, Vít Ondruch wrote: I am saying that Python is bad example and nobody should follow it. I respectfully disagree. The LLVM maintainers think it is a good example worth following. So did the NodeJS maintainers. Name-versioning all the components makes things so much easier for the maintainers. The component name does not matter to the "normal" users. It only matters to experienced packagers, but those should be capable of dealing with that. (The Python 3 vs Python thing obviously is horrible, and nobody should ever do anything like that 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 15. 05. 24 10:08, Vít Ondruch wrote: Dne 14. 05. 24 v 18:35 Miro Hrončok napsal(a): On 14. 05. 24 16:02, Vít Ondruch wrote: Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a): On 13. 05. 24 15:38, Vít Ondruch wrote: And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me. I guess that for the user, the easiest way is to look at the RPMs. Users barely look into our repositories. ~~~ $ rpm -q python package python is not installed ~~~ Why? Because it is called python3. $ rpm -q python3 python3-3.12.3-2.fc39.x86_64 I thought this discussion is about python3.12 vs python3.13, not about python vs python3. I supposed the reason it is called python3 and not python is well know at this point (but if it is not, let me know and I'll try to explain). We are in 2024, so I suppose we could rename everything python3 to python now, I just worry that it would be a lot of effort for not much benefit. Even if `# dnf install python` does something, it still won't install `python` package. Well, it installs the python-unverisoned-command package. Which requires python3. So it install python. Why does it matter? What are you trying to demonstrate here? (Don't take me wrong, I always appreciate good criticism, I juts don't understand what are you suggesting we should do.) Do you suggest to rename python-unversioned-command to python? Do you suggest to rename python3 to python? Do you suggest to rename the python3.12 component to python? (As names of the components started this discussion.) Or is it something else? Every time I bring up such discussion, I am told "the reason it is called python3 and not python is well know" and yes, it is know to some, including me. But advocating for less experienced users. I advocating for users which are not experts on Python ecosystem. I am advocating for conventions. I am trying to demonstrate that things should be obvious. There is "Python" language. Not "Python 3" language. There is e.g. https://www.python.org/ not https://www.python3.org/ etc. Therefore, I'd rather hear "you are right, that does not make too much sense (these days). It is confusing and it is about the time to make the things right (finally)". In your words "We are in 2024, so I suppose we could rename everything python3 to python now" is what I would appreciate. So you say "python3" should be renamed to "python". But this entire discussion started about component names (e.g. "python3.12") and your inability to tell which Python version is the default just by looking at the sources. I am not disagreeing with you. I just don't see how we suddenly discuss a completely different thing. Anyway, let me tell you: You are right, calling the package(s) "python3" does not make too much sense any more. It might be confusing and it might be about the time to make things right by renaming ~4200 packages back to "python". Feel free to propose a detailed plan of execution. Note that I won't do it, because I don't think the benefits outweighs the necessary work. However, if there is a volunteer to drive this, I am happy to review the proposal and share my feedback. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 14. 05. 24 16:02, Vít Ondruch wrote: Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a): On 13. 05. 24 15:38, Vít Ondruch wrote: And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me. I guess that for the user, the easiest way is to look at the RPMs. Users barely look into our repositories. ~~~ $ rpm -q python package python is not installed ~~~ Why? Because it is called python3. $ rpm -q python3 python3-3.12.3-2.fc39.x86_64 I thought this discussion is about python3.12 vs python3.13, not about python vs python3. I supposed the reason it is called python3 and not python is well know at this point (but if it is not, let me know and I'll try to explain). We are in 2024, so I suppose we could rename everything python3 to python now, I just worry that it would be a lot of effort for not much benefit. Even if `# dnf install python` does something, it still won't install `python` package. Well, it installs the python-unverisoned-command package. Which requires python3. So it install python. Why does it matter? What are you trying to demonstrate here? (Don't take me wrong, I always appreciate good criticism, I juts don't understand what are you suggesting we should do.) Do you suggest to rename python-unversioned-command to python? Do you suggest to rename python3 to python? Do you suggest to rename the python3.12 component to python? (As names of the components started this discussion.) Or is it something else? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
When is Fedora 38 going EOL?
Hi, When is Fedora 38 going EOL? https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html says today https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html say next week Which one is correct? 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Hulk edition
On 10. 05. 24 22:45, Miroslav Suchý wrote: Dne 10. 05. 24 v 11:29 dop. Miro Hrončok napsal(a): So we can now have packages with uppercase AND/ORs and packages with lowercase and/ors and we can no longer quickly recognize SPDX expression by observing uppercase AND/ORs? That does not sound like improvement to me :/ This is very very frequent mistake. Mistake for people that does not have time to study the specification and thinks that the case variant does not matter. Recognizing if something is SPDX expression using uppercase operators is IMHO bad idea. What is wrong with `license-validate`? license-validate does not fit into my head. Seeing uppercase AND/OR does not mean the SPDX expression is correct, it only means it is an attempt of an SPDX expression. Which is often enough for me, when I read a specfile. I won't run license-validate on it when I am there to bump a vertsion, but I will notice the License uses and/or and hence I can do the SPDX conversion shile touching it (that is, up until SPDX 3). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Smaller buildroot for Perl packages
On 13. 05. 24 17:11, Frank Ch. Eigler wrote: Hi - I also did a test rebuild of all packages directly build-requiring systemtap-sdt-devel and identified these packages that really need the dtrace script: [...] (The logistic challenge there will be side-tag rebuilding all those after a systemtap subrpm split.) I don't understand why that would be necessary. Could you please explain why do you believe it would? OK, build-time dependency changes may not need the side tag but do need a spec update to prevent a FTBFS at next build. Only those packages that actually need dtrace would require changes. Such changes could land gradually as 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
On 13. 05. 24 20:04, Tulio Magno Quites Machado Filho wrote: Miro Hrončok writes: It first showed up in https://src.fedoraproject.org/rpms/python3.13/pull-request/58 The Ci has all the logs, e.g. https://kojipkgs.fedoraproject.org//work/tasks/8452/117468452/build.log Thanks for these links. It looks like this is happening because the tests are still using annocheck 12.40. I can't reproduce this issue locally with the current annocheck version available in rawhide (v12.53). annocheck 12.53 reports the following message: skip: fortify test because LTO compilation discards preprocessor options I suspect the Zuul rpminspect test runs on Fedora 38 which still has annocheck 12.40. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 13. 05. 24 15:38, Vít Ondruch wrote: And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me. I guess that for the user, the easiest way is to look at the RPMs. Users barely look into our repositories. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GIMP 3.0 in F41?
On 13. 05. 24 12:34, Daniel P. Berrangé wrote: On Mon, May 13, 2024 at 12:14:14PM +0200, Fabio Valentini wrote: On Mon, May 13, 2024, 11:50 Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: On Monday, 13 May 2024 at 01:00, Neal Gompa wrote: On Sun, May 12, 2024 at 4:59 PM Sérgio Basto wrote: https://src.fedoraproject.org/rpms/gimp3 What the heck? This should have been gimp2 for the old version, not gimp3 for the new version... Also, how did this pass review? License:LGPLv3+ And I'll answer myself: it hasn't or at least I can't find any review ticket. Nils, could you explain how this package ended up in Fedora? Standard procedure, everything seems to be in order: https://pagure.io/releng/fedora-scm-requests/issue/62152 The review exception is valid because it's an alternative version of an existing package, and Nils is also the maintainer of the existing package. It that exception automatic ? I thought it had to be explicitly requested from FPC ? eg in https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure It says: "The FPC can grant exceptions to the normal package review process. This may happen, for instance, if a large number of similar packages are being submitted at once or if a package is being updated to a new major version while the old version is being kept in the distribution with a different name. .. Just file a ticket here, set the component to "Review Process Exception" and explain (with detail) why you're requesting the exemption and the committee will consider it in the next meeting. " So gimp3 falls under the 2nd example documented there, but still sounds like an FPC ticket was needed ? This is documented here: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process The section of the wiki page you linked should probably be updated/retired. Anyway, if packagers are abusing this exception to import packages which don't even build, perhaps we should revisit if this exception is 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 27. 04. 24 6:34, Tom Stellard wrote: ... * Switch to python-style compat/main packages. In order to make the packaging more consistent between the main package (e.g. llvm) and the compat package (e.g. llvm18), we would retire the un-versioned dist-git for llvm, and create a new versioned dist-git for each new release (e.g. llvm19, llvm20, llvm21 etc.). We would then designate one of these as the 'main version', and that version would produce binary rpms that look like the current main package (i.e. llvm-libs instead of llvm19-libs). In Python, we did it this way because it was hard to keep one "python3" component that was different version in different Fedoras + multiple "python3.X" components that did (not) exist on certain Fedoras. Git cherry-pciks between branches were... hard. Merges were impossible. Having the component names release-agnostic simplified things us a lot. * Invert the order of compat/main packages. Instead of having the compat package be the old version, and the main package be the new version, we would have the compat package be newer and the main package be older. This would allow us to introduce a new version of llvm without impacting other packages that depend on the main version of LLVM. This allowed us to package new pre-releases of Python as soon as alpha 1 was out (we could even do pre-alphas, but so far there was not enough motivation). That makes it easier for users to test things early. It also allows *us* to test the RPM build early. It also allowed users of e.g. Fedora 38 to use Python 3.12 if they needed to (however, without the entire RPM-Python packages stack on top), despite Python 3.12 being the main Python in F39+ only. Overall, it works quite nicely. If anyone has any feedback on these ideas we'd like to hear it and are happy to discuss these more. +100 Any chance this gets partially implemented in older Fedoras? I'd appreciate llvm18 and clang18 in Fedora 39 (for Python 3.13 experimental JIT). https://github.com/python/cpython/blob/3.13/Tools/jit/README.md 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Smaller buildroot for Perl packages
On 10. 05. 24 17:16, Frank Ch. Eigler wrote: [...] I also did a test rebuild of all packages directly build-requiring systemtap-sdt-devel and identified these packages that really need the dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16, perl, php, mariadb10.11, and libvirt. Those would newly depend on a new package where we move the script to. (The logistic challenge there will be side-tag rebuilding all those after a systemtap subrpm split.) I don't understand why that would be necessary. Could you please explain why do you believe it would? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
On 10. 05. 24 18:59, Tulio Magno Quites Machado Filho wrote: Siddhesh Poyarekar writes: _FORTIFY_SOURCE (any level) should work perfectly with -O (any level). Is this new? Or do you mean any level where optimization is enabled? i.e. -On, where n >= 1 Anyway, a warning should be printed when using -O0 unless -Wno-cpp is also used. The debug build is -O0 -Wno-cpp. The optimized build is -O3. annocheck's source code even mention that -O2 might be 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
On 10. 05. 24 15:58, Siddhesh Poyarekar wrote: On 2024-05-10 06:41, Miro Hrončok wrote: Hello, when we build Python 3.13 with -O3 https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3 I see the following annocheck problem: Hardened: /usr/bin/python3.13: MAYB: test: fortify, reason: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3 (lto) Looks like an annobin issue; do you you have build logs someone can look at? It first showed up in https://src.fedoraproject.org/rpms/python3.13/pull-request/58 The Ci has all the logs, e.g. https://kojipkgs.fedoraproject.org//work/tasks/8452/117468452/build.log The C flags have: -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -O3 Is -D_FORTIFY_SOURCE=3 not comaptible with -O3? Do I need to do somethign about this? _FORTIFY_SOURCE (any level) should work perfectly with -O (any level). That's what I thought as well. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
Hello, when we build Python 3.13 with -O3 https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3 I see the following annocheck problem: Hardened: /usr/bin/python3.13: MAYB: test: fortify, reason: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3 (lto) The C flags have: -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -O3 Is -D_FORTIFY_SOURCE=3 not comaptible with -O3? Do I need to do somethign about 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Hulk edition
On 10. 05. 24 10:55, Miroslav Suchý wrote: Hot news: SPDX v3 has been published. The biggest change for us is that license expression allows lowercase operators (and, or, with). This got into the specification because of your (Fedora maintainers) feedback! So we can now have packages with uppercase AND/ORs and packages with lowercase and/ors and we can no longer quickly recognize SPDX expression by observing uppercase AND/ORs? That does not sound like improvement 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Testing package version is spec file
On 08. 05. 24 19:38, Brad Smith wrote:
I help maintain a package where upstream changed the process to
generate installed documentation. In version 1.30 and newer, the spec
file needs to use process A; in versions older than 1.30 (e.g. 1.29.x,
etc) the spec file needs to use process B. I am struggling to find a
workable solution to testing the version like this.
Can someone please point me in the right direction? Or useful example?
Something like this?
%if v"%{version}" >= v"1.30"
do this
%else
do that
%endif
That said, please don't do that. Do the necessary changes for 1.30+ only in the
specfile for 1.30+ in new Fedora(s), keep the specfile as it was with 1.29 in
the older Fedoras you still need to support.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: pipenv removal in F40
On 30. 04. 24 8:13, Mattia Verga via devel wrote: I vaguely remember that pipenv retirement was briefly discussed here on the ML, yet I was surprised that F40 doesn't have pipenv anymore. IMO, this would have been announced more prominently as a self contained change, as I expect more python developers to find out this too late. Well, the package was orphaned and later retired because nobody stepped up to take it. We don't usually file change proposals for package orphaning and neither we should -- packagers who do no longer have the resources to maintain a package rarely have resources to write documents about it. If you wish to help, I guess you can send a pull request to the release notes... Also, the official guide on https://developer.fedoraproject.org/tech/languages/python/pipenv.html should have been updated as well. ...or to this guide. (I agree it needs to be updated and/or removed.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 18. 04. 24 1:00, Miro Hrončok wrote: On 18. 04. 24 0:37, Miro Hrončok wrote: On 17. 04. 24 23:10, Markus Falb wrote: I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. https://src.fedoraproject.org/rpms/python3.13/pull-request/54 -- other Pythons will follow after CI + review. Here is the Fedora 38 python3.10 update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-7736b7ce48 Other updates are available as well: https://bodhi.fedoraproject.org/updates/?packages=python3.8,python3.9,python3.10,python3.11,python3.12,python3.13 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 18. 04. 24 0:37, Miro Hrončok wrote: On 17. 04. 24 23:10, Markus Falb wrote: I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. https://src.fedoraproject.org/rpms/python3.13/pull-request/54 -- other Pythons will follow after CI + review. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 17. 04. 24 23:10, Markus Falb wrote: Hi, I noticed that creating virtualenvs did not work anymore with the latest python 3.10 package on Fedora 38 Hello Markus, Thanks for the report, this is indeed happening. [root@fe60c84b08f3 /]# python3.10 -m venv venv Error: Command '['/venv/bin/python3.10', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1. snap... And the error is (when I run the failed command): ImportError: /usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so: undefined symbol: XML_SetReparseDeferralEnabled Unfortunately this also happens with all python3.8 ... python3.13. 3.11 and 3.12 were still in updates testing, so I have blocked the autopush for now: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d615822702 https://bodhi.fedoraproject.org/updates/FEDORA-2024-98a723cb68 I am afraid this also impacts newer Fedoras once shipped with older expat. https://www.python.org/downloads/release/python-31014/ tells us ... bundled libexpat was updated to 2.6.0 to address CVE-2023-52425... And we unbundle it, yet we depend on the new symbol :( using the fedora container for CI runs without doing global dnf update to save resources I had to update expat from expat-2.5.0-2.fc38.x86_64 to expat-2.6.0-1.fc38.x86_64 Fortunately, fedora:39 from registry.fedoraproject.org already has expat-2.6.2-1.fc39. I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. --- I wonder how to prevent this in the future. There is https://github.com/rpm-software-management/rpm/pull/2372 but that will take a while. Perhaps we need to always Require expat >= version of expat used when building. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Handling --enable-experimental-jit in Python 3.13
On 17. 04. 24 14:27, Victor Stinner wrote: On Wed, Apr 10, 2024 at 8:23 PM Miro Hrončok wrote: Python 3.13 has an experimental JIT compiler: https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler Enabling it is a configure (hence build-time) option. How do we handle this in Fedora? - We can keep it disabled, as it is experimental. I concur with that. - We can enable it, but be ready to revert if it causes problems. - We can add yet another build variant, but we already have 4 of those (regular, debug, freethreading, freethreading-debug), so I'd rather not make it 6 (or 8, if we include freethreading+jit combinations). I don't know yet if it would be co-installable. I don't think it's worth it. Moreover, it doesn't build on Fedora 39 with clang-17, since Python 3.13 currently requires exactly clang-16. We have multiple clangs/llvms: https://src.fedoraproject.org/rpms/llvm16 https://src.fedoraproject.org/rpms/clang16 Victor, do you think it would be possible to build in the JIT support but have a runtime opt-out/opt-in switch? That way, we can build it, but disable it by default, unless our users want to experiment with it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
On 13. 04. 24 10:04, Miro Hrončok wrote: On 13. 04. 24 2:33, Kevin Kofler via devel wrote: How much larger is Python at -O3 compared to -O2? And other packages? That is a good question, will measure. -O2 RPM size: python3-3.12.2-3.fc41.x86_6432638 python3-libs-3.12.2-3.fc41.x86_644246 -O3 RPM size: python3-3.12.2-3.O3.fc41.x86_64 32638 python3-libs-3.12.2-3.O3.fc41.x86_64 43389702 Difference of python3-libs: 500856 == 489 kB = 1.1678 % increase in size of pytohn3-libs itself or 1.1669 % of python3-libs+python3 combined size. (I added this to the change proposal.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
On 13. 04. 24 2:33, Kevin Kofler via devel wrote: How much larger is Python at -O3 compared to -O2? And other packages? That is a good question, will measure. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On 07. 04. 24 17:47, Miro Hrončok wrote: Note that it produces incorrect results if the Release value is not numerical (or if it is a greater number than count of the commits since last bump). It will happily convert release 0.1 to 3, 29.20130501hg26242d0aa7b8 to 30 or even release 500 to 10. I converted all of my packages with it and in some cases I had to manually fix the results. E.g.: https://src.fedoraproject.org/rpms/printrun/pull-request/8 https://src.fedoraproject.org/rpms/pypy3.10/pull-request/15#comment-179619 https://src.fedoraproject.org/rpms/poly2tri/pull-request/2 + fixup commit on top https://src.fedoraproject.org/rpms/poly2tri/c/053f90 I had to push https://src.fedoraproject.org/rpms/simarrange/c/4ec0880c after a broked automated conversion. It's very hard to notice this when converting ~100 packages at the same 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change AGPLv3+ to AGPL-3.0-or-later
On 12. 04. 24 11:22, Miroslav Suchý wrote: Hi. I am going to do the mass change of the license from AGPLv3+ to AGPL-3.0-or-later The proposed diff is in attachment. Affected packages: simarrange I had a look at this package of mine and realized I borked the rpmautospec conversion, so I opened https://src.fedoraproject.org/rpms/simarrange/pull-request/3 -- it includes the SPDX conversion. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Django latest vs LTS maintenance plan
On 11. 04. 24 22:41, Michel Lind wrote: The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: pytohn3dist(django)`? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Django latest vs LTS maintenance plan
On 11. 04. 24 22:41, Michel Lind wrote: The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: pytohn3dist(django)`? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Idea: pynose as drop-in replacement for nose
On 11. 04. 24 15:05, Sandro wrote: On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Idea: pynose as drop-in replacement for nose
On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Handling --enable-experimental-jit in Python 3.13
Hello Pythonistas, Python 3.13 has an experimental JIT compiler: https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler Enabling it is a configure (hence build-time) option. How do we handle this in Fedora? - We can keep it disabled, as it is experimental. - We can enable it, but be ready to revert if it causes problems. - We can add yet another build variant, but we already have 4 of those (regular, debug, freethreading, freethreading-debug), so I'd rather not make it 6 (or 8, if we include freethreading+jit combinations). I don't know yet if it would be co-installable. Opinions? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Idea: pynose as drop-in replacement for nose
On 10. 04. 24 17:30, Sandro wrote: On 10-04-2024 12:04, Miro Hrončok wrote: On 09. 04. 24 19:30, Sandro wrote: Therefore, I'm thinking of introducing pynose as a drop in replacement of deprecated nose. Pynose uses the same namespace as nose, but provides python3dist(pynose). Thus adding Provides: for nose would make it a drop-in replacement for packages currently depending on nose. FTR We MUST NOT add RPM Provides for python3dist(nose) unless we package nose dist-info metadata. Thanks for pointing that out. I was indeed experimenting with it. Is there some documentation or example for packaging extra dist-info metadata? Not really, because it is a hack that should not be done if it can be avoided. You can see a working example in python-lark https://src.fedoraproject.org/rpms/python-lark/c/c7a9aa2e7b0b1d9d621ac60f73c854fdcc154ab2 I also played around pith setuptools' `provide` only to learn later on that pip ignores it entirely (as well as `obsoletes`, which is deprecated). So, the pyproject-rpm-macros are probably not honoring that either. For example %pyproject_buildrequires queries Python for installed packages (hence it reads the packaged dist-info/egg-info metadata) and it will see nose is not installed. It will then query dnf to install python3dist(nose). dnf will install pynose. %pyproject_buildrequires will see nose is not installed. It will query dnf to install python3dist(nose) again. dnf will install nothing. The %pyproject_buildrequires phase will end prematurely when dnf installs nothing. Agreed. If we do add python3dist(nose) it needs to work not cause more issues. Most packages I've looked at recently have a BR for python3-nose. That's covered by adding "%py_provides python3-nose". But dependency resolution in %pyproject_buildrequires uses python3dist. If the package configuration has a dependency on nose declared, I would like that to be satisfiable, both in RPM and pip, by installing python3-pynose. If that is too much hassle or simply (currently) not possible, a fallback to not providing nose at all, is also possible. In that case more packages might need to be patched and we need to educate people te replace dependencies on nose with pynose. My preference at the moment is for the former. If we are to retire python-nose at the same time, I'd do: - have python3-pynose %py_provides (and Obsolete) python3-nose - don't mess with dist metadata at all That way: - packages that use upstream requirements will need to be updated (preferably upstream first => good) - packages that manually BuildRequire python3-nose will likely keep working If the pynose package has a "nose" importable module, providing python3-nose even follows https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_for_importable_modules -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Idea: pynose as drop-in replacement for nose
On 09. 04. 24 19:30, Sandro wrote: Therefore, I'm thinking of introducing pynose as a drop in replacement of deprecated nose. Pynose uses the same namespace as nose, but provides python3dist(pynose). Thus adding Provides: for nose would make it a drop-in replacement for packages currently depending on nose. FTR We MUST NOT add RPM Provides for python3dist(nose) unless we package nose dist-info metadata. For example %pyproject_buildrequires queries Python for installed packages (hence it reads the packaged dist-info/egg-info metadata) and it will see nose is not installed. It will then query dnf to install python3dist(nose). dnf will install pynose. %pyproject_buildrequires will see nose is not installed. It will query dnf to install python3dist(nose) again. dnf will install nothing. The %pyproject_buildrequires phase will end prematurely when dnf installs nothing. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote: Not all commits correspond with a new release downstream, and not all commit messages are relevant to the end user to be part of the change log. For example, commits related with increasing gating test coverage efforts, or setting up gating.yaml itself. Another example is linting setting and/or configurations. How is that handled with autochangelog? Can we tell it to skip certain commits? Or should we include it all? Put [skip changelog] in the commit message. https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On 07. 04. 24 17:15, Zbigniew Jędrzejewski-Szmek wrote: Hi everyone, I'm revisting the topic of rpmautospec because I was doing some work on various packages, and it's annoying that some packages are using rpmautospec and others are not. All my packages have been converted, so in day-to-day work, I don't even think about %changelog. When working with other packages, I'll forget to update the Relase and/or %changelog. Today I was rebasing some pull requests in pagure, and the _only_ conflicts that I had were about Release and %changelog. I think it's time to switch to rpmautospec completely. Thus, the proposal: - new packages MUST use rpmautospec - packagers SHOULD convert their packages - provenpackagers MAY convert existing packages (e.g. when they want to push some fix or separately from other work) - people submitting pull requests against src.fp.o MAY also include a conversion in the pull request and packagers SHOULD merge it. I have some packages where the tooling isn't ready yet for %autorelease, so I put them on hold. I also have some packages with pre-release info still in the Release filed and moving it to Version with ~ (to use %autorelease) would make the package downgrade, so I am waiting for a next upstream release to do that. I think it's to early to force this. (FTR, 'rpmautospec convert' does the conversion, incl. the commit to dist-git. Manual conversion should not be used.) Note that it produces incorrect results if the Release value is not numerical (or if it is a greater number than count of the commits since last bump). It will happily convert release 0.1 to 3, 29.20130501hg26242d0aa7b8 to 30 or even release 500 to 10. I converted all of my packages with it and in some cases I had to manually fix the results. E.g.: https://src.fedoraproject.org/rpms/printrun/pull-request/8 https://src.fedoraproject.org/rpms/pypy3.10/pull-request/15#comment-179619 https://src.fedoraproject.org/rpms/poly2tri/pull-request/2 + fixup commit on top https://src.fedoraproject.org/rpms/poly2tri/c/053f90 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Module-Build-WithXSpp] PR #1: Convert to %autorelease and %autochangelog
churchyard merged a pull-request against the project: `perl-Module-Build-WithXSpp` that you are following. Merged pull-request: `` Convert to %autorelease and %autochangelog `` https://src.fedoraproject.org/rpms/perl-Module-Build-WithXSpp/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Wx-GLCanvas] PR #3: Convert to %autorelease and %autochangelog
churchyard merged a pull-request against the project: `perl-Wx-GLCanvas` that you are following. Merged pull-request: `` Convert to %autorelease and %autochangelog `` https://src.fedoraproject.org/rpms/perl-Wx-GLCanvas/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-ExtUtils-Typemaps-Default] PR #1: Convert to %autorelease and %autochangelog
churchyard merged a pull-request against the project: `perl-ExtUtils-Typemaps-Default` that you are following. Merged pull-request: `` Convert to %autorelease and %autochangelog `` https://src.fedoraproject.org/rpms/perl-ExtUtils-Typemaps-Default/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Growl-GNTP] PR #1: Convert to %autorelease and %autochangelog
churchyard merged a pull-request against the project: `perl-Growl-GNTP` that you are following. Merged pull-request: `` Convert to %autorelease and %autochangelog `` https://src.fedoraproject.org/rpms/perl-Growl-GNTP/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-ExtUtils-CppGuess] PR #2: Convert to %autorelease and %autochangelog
churchyard merged a pull-request against the project: `perl-ExtUtils-CppGuess` that you are following. Merged pull-request: `` Convert to %autorelease and %autochangelog `` https://src.fedoraproject.org/rpms/perl-ExtUtils-CppGuess/pull-request/2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %pyproject_buildrequires -r/-x: Attempt to read runtime dependencies from pyproject.toml?
On 27. 03. 24 23:15, Maxwell G wrote: One way to mitigate would be to make the proposed behavior opt-in only, with the possibility to either build wheel with -w option (already existing) or e.g. -p (now-proposed: reading from pyproject.toml) in case backend doesn't have prepare_metadata_for_build_wheel. Yeah, I think -p (for *p*yproject) is good flag name choice. Or even for [*p*roject] table. It is double good. I guess I will throw something out there, but I am not convinced it is a great idea: what about making the `-p` flag fail if `prepare_metadata_for_build_wheel` is available? In my opinion, this should only be a last resort for backends that do not implement the hook. I am not particularly keen on this. This means that once the backend starts supporting it, all the spec files using -p need to drop it. And if the backend only supports it in rawhide, the spec files need to diverge and/or %if-guard the flag. If the backend followed PEP 621 before adding the hook and now it added the hook, it is unlikely the PEP 621 support was dropped. OTHO if the backed was changed (e.g. meson -> poetry), this *could* happen. So I am not entirely opposed for this guard. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 27. 03. 24 16:03, Jens-Ulrik Petersen wrote: On Wed, Mar 27, 2024 at 9:46 PM Miro Hrončok <mailto:mhron...@redhat.com>> wrote: On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote: > Also botan got orphaned despite the FTI going away > <https://bugzilla.redhat.com/show_bug.cgi?id=2259559 <https://bugzilla.redhat.com/show_bug.cgi?id=2259559>> [1] ;-( > Could it be un-orphaned back? > [1] Seems FTI failed to close the bug fixed on 2024-03-07 It was closed after it was fixed. The update was stuck at beta freeze and nobody associated the FTI bugzilla with it. No, it was reported <https://bugzilla.redhat.com/show_bug.cgi?id=2259559#c5> installable (comment 5) on 7th March by fti-bugs but was not closed as it should have been then. On Fedora 41 only. Then it was orphaned <https://bugzilla.redhat.com/show_bug.cgi?id=2259559#c6> (comment 6) on 21st March. Yes, because it was still NEW and not acted upon by the maintainer. Then again reported <https://bugzilla.redhat.com/show_bug.cgi?id=2259559#c7> installable (comment 7) on 25th which actually closed the bug. On Fedora 40. Which is why I am asking if the orphaned can be reverted, please. Yes, if the previous maintainer is still interested in maintaining it, they can take the package back by clicking on the *Take* button. It makes no sense to me to assign it back to them if they are not interested. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote: Also botan got orphaned despite the FTI going away <https://bugzilla.redhat.com/show_bug.cgi?id=2259559> [1] ;-( Could it be un-orphaned back? Yes, by clicking the *Take* button. [1] Seems FTI failed to close the bug fixed on 2024-03-07 It was closed after it was fixed. The update was stuck at beta freeze and nobody associated the FTI bugzilla with 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Default NodeJS stream packages with versioned names are not available
On 20. 03. 24 17:35, Jan Staněk wrote:
Hello all,
recently, when trying to spin up a CI for NodeJS in Fedora, I ran into a
slight problem: when a NodeJS stream is the default one, versioned
packages (i.e. nodejs20) are not generated and are not installable.
For example, on current rawhide, I cannot install `nodejs20` package,
only `nodejs`; this will give me the version 20.x as expected.
The problem is that this complicates the CI setup,
and requires me to take into account which Fedora I'm currently on.
As an example, when adding tests for nodejs20 dist-git[1],
I would like to simply specify `requires: nodejs20` into the test
metadata. However, with the current setup, I would need something akin
to the following (pseudocode, I did not really test if that would work):
requires:
- {% if fedora == 40 %}nodejs{% else %}nodejs20{% fi %}
In addition to being more complicated, this will also break if the
default stream for a given Fedora version ever change
(which is not unlikely to happen, as the upstream release schedule
is not really synchronized with the Fedore one).
---
I recall that the current status is the result of already existing
long discussion, with associated debugging, so I would like to have this
solved with as minimal disruption as possible. That being said,
what is the reason for having the non-versioned packages (`nodejs`) *in
stead* of the versioned ones (`nodejs20`), as opposed to *in addition*
to them?
The non-versioned packages could then require the appropriate versioned
ones and contain only symlinks (/usr/bin/node → /usr/bin/node-20,
/usr/lib/node_modules → /usr/lib/node_modules_20, etc.).
Python does this similarly to nodejs (we have python3.11, pytohn3, python3.13
in rawhide today), with one difference. The python3 package provides
python3.12. So when you do:
requires:
- python3.12
It just works.
I believe nodejs should provide nodejs20, the same way.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] EPEL 8 Next rebuild blocked by modularity magic, please help
Hello, I opened this ticket 1+ month ago: https://pagure.io/releng/issue/11947 tl;dr RHEL modular python39-pip-wheel and python39-setuptools-wheel packages are available in epel8 Koji buildroot but not in epel8-next Koji buildroot. Can somebody please help to fix this? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Follow up for bash-completion pkgconfig file packaging change
On 18. 03. 24 17:07, Fabio Valentini wrote:
I wonder why these packages rely in pkg-config and don't just install
to `%{bash_completions_dir}`?
Because they either predate the macro or the thing was copied from another
package that predates 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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Follow up for bash-completion pkgconfig file packaging change
On 18. 03. 24 16:33, Mamoru TASAKA wrote: Hello, all: After investigating the recent Fedora-Security-Live livespin compose failure on F-41, it is found that this is caused because: - Recently on F-41, bash-completion packaging changed so that pkgconfig file is moved into -devel subpackage: (bash-completion-2.11-15.fc41) https://src.fedoraproject.org/rpms/bash-completion/c/d1f5dc48c0440cc68efdd519b78fccca416cad94?branch=rawhide - A package (lynis) installing bash-completion file into the directory $(pkg-config --variable=completionsdir bash-completion), had "BuildRequires: bash-completion", but did not have "BuildRequires: pkgconfig(bash-completion)". - So after the above bash-completion side packaging change, the above command line was expanded to the empty string, so the completion file was installed into the wrong directory, which caused conflict with filesystem rpm. I've commented about his at https://bugzilla.redhat.com/show_bug.cgi?id=1457164#c8 a month ago but so far no response. So on F-41(rawhide), the packages * trying to install bash-completion file using $(pkg-config --variable=completionsdir bash-completion) * which have "BuildRequires: bash-completion", but do NOT have "BuildRequires: pkgconfig(bash-completion)" may be installing completion file into wrong directories after rebuild. (At least, I tried rebuilding cowsay and actually it installs completion file into the wrong directory). The possible packages which may need fixing are: ... 13 python-django/rawhide/python-django.spec bashcompdir=$(pkg-config --variable=completionsdir bash-completion) I opened https://src.fedoraproject.org/rpms/python-django/pull-request/37 5 days ago. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guiding co-dependent RPM packages to swap nicely
On 08. 03. 24 11:43, Florian Weimer wrote: * Miro Hrončok: On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*. Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20 However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin. Is there something I can do as a package maintainer to "guide" the co-dependent swap case? Have you tried using “dnf shell” and entering both swap commands there/ I am actually looking for a metadata solution that would guide the package manager to do it for me, not for a way to swap them manually. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libxslxwriter (misspelled package) in zombie state
On 02. 03. 24 23:28, Richard W.M. Jones wrote: On Sat, Mar 02, 2024 at 10:16:02PM +0100, Miro Hrončok wrote: On 02. 03. 24 11:31, Richard W.M. Jones wrote: On Fri, Mar 01, 2024 at 10:00:20AM -0800, Kevin Fenzi wrote: On Fri, Mar 01, 2024 at 11:49:06AM +, Richard W.M. Jones wrote: We were discussing this on IRC, so just to bring the topic up on the mailing list ... (1) Package libxslxwriter (note: "xslx") with only automated activity and no builds: https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide https://koji.fedoraproject.org/koji/packageinfo?packageID=32741 (2) Package libxlsxwriter (note: "xlsx") which is normal: https://src.fedoraproject.org/rpms/libxlsxwriter/commits/rawhide https://koji.fedoraproject.org/koji/packageinfo?packageID=32754 It seems like the first package is in some sort of zombie state? Yeah, the package owner (or a provenpackager) should just be able to 'fedpkg retire' it... Well I took that as a hint and I ran the retire command. I'm not sure if it actually worked completely. There was an error towards the end: $ fedpkg retire "https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/; rm '.gitignore' rm 'README.md' rm 'libxlsxwriter.spec' rm 'libxlsxwriter_sover.patch' rm 'libxlsxwriter_zlib.patch' rm 'sources' [rawhide 922af46] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/ 7 files changed, 1 insertion(+), 143 deletions(-) delete mode 100644 .gitignore delete mode 100644 README.md create mode 100644 dead.package delete mode 100644 libxlsxwriter.spec delete mode 100644 libxlsxwriter_sover.patch delete mode 100644 libxlsxwriter_zlib.patch delete mode 100644 sources ... Could not execute retire: The following error occurred while disabling monitoring: You are not allowed to modify this project This seems like https://pagure.io/fedpkg/issue/505 The package is retired in dist-git: https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide OK .. but is it retired? It is now. When you asked, it might have been only partially retired. Package retirement is an asynchronous chain of events. 1. It is retired in rawhide distgit bacuase it has the dead.package file ✔️ 2. It is "active: false" in rawhide PDC ✔️ https://pdc.fedoraproject.org/rest_api/v1/component-branches/?name=rawhide_component=libxslxwriter 3. It is blocked in f41 Koji ✔️ $ koji list-pkgs --show-blocked --tag f41 --quiet --package libxslxwriter libxslxwriter f41 smani [BLOCKED] 4. It is not in the rawhide repository ✔️ This package never was, so :/ For docs, see https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_koji -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libxslxwriter (misspelled package) in zombie state
On 02. 03. 24 11:31, Richard W.M. Jones wrote: On Fri, Mar 01, 2024 at 10:00:20AM -0800, Kevin Fenzi wrote: On Fri, Mar 01, 2024 at 11:49:06AM +, Richard W.M. Jones wrote: We were discussing this on IRC, so just to bring the topic up on the mailing list ... (1) Package libxslxwriter (note: "xslx") with only automated activity and no builds: https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide https://koji.fedoraproject.org/koji/packageinfo?packageID=32741 (2) Package libxlsxwriter (note: "xlsx") which is normal: https://src.fedoraproject.org/rpms/libxlsxwriter/commits/rawhide https://koji.fedoraproject.org/koji/packageinfo?packageID=32754 It seems like the first package is in some sort of zombie state? Yeah, the package owner (or a provenpackager) should just be able to 'fedpkg retire' it... Well I took that as a hint and I ran the retire command. I'm not sure if it actually worked completely. There was an error towards the end: $ fedpkg retire "https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/; rm '.gitignore' rm 'README.md' rm 'libxlsxwriter.spec' rm 'libxlsxwriter_sover.patch' rm 'libxlsxwriter_zlib.patch' rm 'sources' [rawhide 922af46] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/ 7 files changed, 1 insertion(+), 143 deletions(-) delete mode 100644 .gitignore delete mode 100644 README.md create mode 100644 dead.package delete mode 100644 libxlsxwriter.spec delete mode 100644 libxlsxwriter_sover.patch delete mode 100644 libxlsxwriter_zlib.patch delete mode 100644 sources ... Could not execute retire: The following error occurred while disabling monitoring: You are not allowed to modify this project This seems like https://pagure.io/fedpkg/issue/505 The package is retired in dist-git: https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide The error is for monitoring only. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
List of long term FTBFS packages to be retired in 1 week
NOTE: This was not sent to individual maintainers, as @fedoraproject.org aliases are currently broken https://pagure.io/fedora-infrastructure/issue/11768 --- Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 1 week, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 erlang-jose@erlang-maint-sig, bowlofeggs, jcline, peter golang-github-acme-lego@go-sig, eclipseo golang-github-gobs-pretty @go-sig, eclipseo golang-gvisor @go-sig, eclipseo, elmarco golang-opentelemetry-otel-0.20 @go-sig, alexsaezm golang-sigs-k8s-kustomize @go-sig, dcavalca golang-vitess @go-sig, eclipseo infinipath-psm honli j4-dmenu-desktop ibotty jackson-dataformats-binary mbooth jackson-dataformats-text mbooth java-1.8.0-openjdk-aarch32 akasko, jvanek jreen rdieter libdeltacloud clalance mingw-clucene greghellings mingw-speexdsp janisozaur nbd-runner xiubli nodejs-generic-poolpatches, piotrp ofono njha, thunderbirdtr pesign-test-appjavierm, nfrayer, pjones, rharwood pthsem ixs rust-drg @rust-sig, jbtrystram The following packages require above mentioned packages: Depending on: erlang-jose (1) erlang-p1_acme (maintained by: @erlang-maint-sig, bowlofeggs, peter) erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose Depending on: golang-github-gobs-pretty (2) golang-github-vinyldns (maintained by: @go-sig, eclipseo) golang-github-vinyldns-0.9.13-1.fc40.2.src requires golang(github.com/gobs/pretty) golang-github-acme-lego (maintained by: @go-sig, eclipseo) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/vinyldns/go-vinyldns/vinyldns) golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/vinyldns/go-vinyldns/vinyldns) Depending on: golang-opentelemetry-otel-0.20 (26) golang-k8s-apiserver (maintained by: @go-sig, alexsaezm) golang-k8s-apiserver-1.22.0-12.fc40.src requires golang(go.opentelemetry.io/contrib-0.20/instrumentation/google.golang.org/grpc/otelgrpc), golang(go.opentelemetry.io/contrib-0.20/instrumentation/net/http/otelhttp), golang(go.opentelemetry.io/otel-0.20/exporters/otlp/otlpgrpc), golang(go.opentelemetry.io/otel-0.20/sdk/resource), golang(go.opentelemetry.io/otel-0.20/sdk/trace), golang(go.opentelemetry.io/otel-0.20/semconv), golang(go.opentelemetry.io/otel-0.20/trace), golang(k8s.io/component-base/cli/flag), golang(k8s.io/component-base/featuregate), golang(k8s.io/component-base/featuregate/testing), golang(k8s.io/component-base/logs), golang(k8s.io/component-base/metrics), golang(k8s.io/component-base/metrics/legacyregistry), golang(k8s.io/component-base/metrics/prometheus/workqueue), golang(k8s.io/component-base/metrics/testutil), golang(k8s.io/component-base/traces), golang(k8s.io/component-base/version) golang-k8s-apiserver-devel-1.22.0-12.fc40.noarch requires golang(go.opentelemetry.io/contrib-0.20/instrumentation/google.golang.org/grpc/otelgrpc), golang(go.opentelemetry.io/contrib-0.20/instrumentation/net/http/otelhttp), golang(go.opentelemetry.io/otel-0.20/exporters/otlp/otlpgrpc), golang(go.opentelemetry.io/otel-0.20/sdk/resource), golang(go.opentelemetry.io/otel-0.20/sdk/trace), golang(go.opentelemetry.io/otel-0.20/semconv), golang(go.opentelemetry.io/otel-0.20/trace), golang(k8s.io/component-base/cli/flag), golang(k8s.io/component-base/featuregate), golang(k8s.io/component-base/logs),
Re: List of long term FTBFS packages to be retired in 1 week
On 21. 02. 24 17:46, Kevin Fenzi wrote: On Wed, Feb 21, 2024 at 04:43:26PM +0100, Miro Hrončok wrote: NOTE: This was not sent to individual maintainers, as @fedoraproject.org aliases are currently broken https://pagure.io/fedora-infrastructure/issue/11768 (Side note: This should now be fixed) Thanks. I forwarded the email. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
List of long term FTBFS packages to be retired in 1 week
NOTE: This was not sent to individual maintainers, as @fedoraproject.org aliases are currently broken https://pagure.io/fedora-infrastructure/issue/11768 --- Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 1 week, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 erlang-jose@erlang-maint-sig, bowlofeggs, jcline, peter golang-github-acme-lego@go-sig, eclipseo golang-github-gobs-pretty @go-sig, eclipseo golang-gvisor @go-sig, eclipseo, elmarco golang-opentelemetry-otel-0.20 @go-sig, alexsaezm golang-sigs-k8s-kustomize @go-sig, dcavalca golang-vitess @go-sig, eclipseo infinipath-psm honli j4-dmenu-desktop ibotty jackson-dataformats-binary mbooth jackson-dataformats-text mbooth java-1.8.0-openjdk-aarch32 akasko, jvanek jreen rdieter libdeltacloud clalance mingw-clucene greghellings mingw-speexdsp janisozaur nbd-runner xiubli nodejs-generic-poolpatches, piotrp ofono njha, thunderbirdtr pesign-test-appjavierm, nfrayer, pjones, rharwood pthsem ixs rust-drg @rust-sig, jbtrystram The following packages require above mentioned packages: Depending on: erlang-jose (1) erlang-p1_acme (maintained by: @erlang-maint-sig, bowlofeggs, peter) erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose Depending on: golang-github-gobs-pretty (2) golang-github-vinyldns (maintained by: @go-sig, eclipseo) golang-github-vinyldns-0.9.13-1.fc40.2.src requires golang(github.com/gobs/pretty) golang-github-acme-lego (maintained by: @go-sig, eclipseo) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/vinyldns/go-vinyldns/vinyldns) golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/vinyldns/go-vinyldns/vinyldns) Depending on: golang-opentelemetry-otel-0.20 (26) golang-k8s-apiserver (maintained by: @go-sig, alexsaezm) golang-k8s-apiserver-1.22.0-12.fc40.src requires golang(go.opentelemetry.io/contrib-0.20/instrumentation/google.golang.org/grpc/otelgrpc), golang(go.opentelemetry.io/contrib-0.20/instrumentation/net/http/otelhttp), golang(go.opentelemetry.io/otel-0.20/exporters/otlp/otlpgrpc), golang(go.opentelemetry.io/otel-0.20/sdk/resource), golang(go.opentelemetry.io/otel-0.20/sdk/trace), golang(go.opentelemetry.io/otel-0.20/semconv), golang(go.opentelemetry.io/otel-0.20/trace), golang(k8s.io/component-base/cli/flag), golang(k8s.io/component-base/featuregate), golang(k8s.io/component-base/featuregate/testing), golang(k8s.io/component-base/logs), golang(k8s.io/component-base/metrics), golang(k8s.io/component-base/metrics/legacyregistry), golang(k8s.io/component-base/metrics/prometheus/workqueue), golang(k8s.io/component-base/metrics/testutil), golang(k8s.io/component-base/traces), golang(k8s.io/component-base/version) golang-k8s-apiserver-devel-1.22.0-12.fc40.noarch requires golang(go.opentelemetry.io/contrib-0.20/instrumentation/google.golang.org/grpc/otelgrpc), golang(go.opentelemetry.io/contrib-0.20/instrumentation/net/http/otelhttp), golang(go.opentelemetry.io/otel-0.20/exporters/otlp/otlpgrpc), golang(go.opentelemetry.io/otel-0.20/sdk/resource), golang(go.opentelemetry.io/otel-0.20/sdk/trace), golang(go.opentelemetry.io/otel-0.20/semconv), golang(go.opentelemetry.io/otel-0.20/trace), golang(k8s.io/component-base/cli/flag), golang(k8s.io/component-base/featuregate), golang(k8s.io/component-base/logs),
Guiding co-dependent RPM packages to swap nicely
Hello. Assume I have two "stacks" of RPM packages available: postgresql16 provides postgresql-any version 16 conflicts with other postgresql-any postgresql16-plugin provides postgresql-any-plugin requires postgresql16 conflicts with other postgresql-any-plugin postgresql20 provides postgresql-any version 20 conflicts with other postgresql-any postgresql20-plugin provides postgresql-any-plugin requires postgresql20 conflicts with other postgresql-any-plugin On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*. Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20 However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin. Is there something I can do as a package maintainer to "guide" the co-dependent swap case? I was thinking something like: postgresql20-plugin: Obsoletes: (postgresql-any-plugin if postgresql-any != 20) However that is not possible in RPM, "No rich dependencies allowed for this type: Obsoletes". Is there anything else? 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
List of long term FTBFS packages to be retired in 2 weeks
NOTE: This was not sent to individual maintainers, as @fedoraproject.org aliases are currently broken https://pagure.io/fedora-infrastructure/issue/11768 --- Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 2 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 erlang-jose@erlang-maint-sig, bowlofeggs, jcline, peter golang-github-acme-lego@go-sig, eclipseo golang-github-genuinetools-pkg @go-sig, eclipseo golang-github-gobs-pretty @go-sig, eclipseo golang-github-pierrre-compare @go-sig, eclipseo golang-github-smartystreets-goconvey @go-sig, alexsaezm, jchaloup golang-gvisor @go-sig, eclipseo, elmarco golang-opentelemetry-otel-0.20@go-sig, alexsaezm golang-sigs-k8s-kustomize @go-sig, dcavalca golang-vitess @go-sig, eclipseo infinipath-psmhonli j4-dmenu-desktop ibotty jackson-dataformats-binarymbooth jackson-dataformats-text mbooth java-1.8.0-openjdk-aarch32akasko, jvanek jreen rdieter libdeltacloud clalance mingw-clucene greghellings mingw-speexdspjanisozaur nbd-runnerxiubli nodejs-generic-pool patches, piotrp ofono njha, thunderbirdtr pesign-test-app javierm, nfrayer, pjones, rharwood pthsemixs rust-drg @rust-sig, jbtrystram The following packages require above mentioned packages: Depending on: erlang-jose (1) erlang-p1_acme (maintained by: @erlang-maint-sig, bowlofeggs, peter) erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose Depending on: golang-github-genuinetools-pkg (1) reg (maintained by: @go-sig, @infra-sig, mattia) reg-0.16.1-15.fc40.src requires golang(github.com/genuinetools/pkg/cli) Depending on: golang-github-gobs-pretty (2) golang-github-vinyldns (maintained by: @go-sig, eclipseo) golang-github-vinyldns-0.9.13-1.fc40.2.src requires golang(github.com/gobs/pretty) golang-github-acme-lego (maintained by: @go-sig, eclipseo) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/vinyldns/go-vinyldns/vinyldns) golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/vinyldns/go-vinyldns/vinyldns) Depending on: golang-github-smartystreets-goconvey (23) golang-github-afex-hystrix (maintained by: @go-sig, alexsaezm) golang-github-afex-hystrix-0-0.14.20190622gitfa1af6a.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-cucumber-godog (maintained by: @go-sig, eclipseo) golang-github-cucumber-godog-0.12.1-10.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-macaron-inject (maintained by: @go-sig, mikelo2) golang-github-macaron-inject-0-0.22.20210110git138e592.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-powerman-check (maintained by: @go-sig, eclipseo) golang-github-powerman-check-1.7.0-3.fc40.src requires golang(github.com/smartystreets/goconvey/convey), golang(github.com/smartystreets/goconvey/convey/reporting) golang-github-powerman-check-devel-1.7.0-3.fc40.noarch requires golang(github.com/smartystreets/goconvey/convey/reporting) golang-github-unknwon-com (maintained by: @go-sig, agerstmayr, nathans) golang-github-unknwon-com-1:1.0.1-9.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-unknwon-goconfig
Re: mock build for rawhide: Transaction failed: Signature verification failed.
On 20. 02. 24 13:31, Richard Shaw wrote: For about a week I've been seeing this when trying to test build packages for rawhide locally: Transaction failed: Signature verification failed. PGP check for package "bash-5.2.26-3.fc40.x86_64" (/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/bash-5.2.26-3.fc40.x86_64.rpm) from repo "fedora" has failed: Import of the key didn't help, wrong key? I've already done a --scrub=all a few times to no avail. Do you have distribution-gpg-keys 1.101 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %global __pytest_addopts or export PYTEST_ADDOPTS?
On 20. 02. 24 13:10, Richard W.M. Jones wrote:
For %{pytest} in Fedora there seem to be two possible ways to add
options eg for skipping tests, both working.
Either:
%global __pytest_addopts --options ...
(see attachment for example)
Or:
export PYTEST_ADDOPTS="--options ..."
(example:
https://src.fedoraproject.org/rpms/scipy/blob/rawhide/f/scipy.spec#_228)
Is there a preferred way?
The %__pytest_addopts macro exists for other macros to be able to inject stuff
into %pytest: e.g.
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/macros.pyproject#_28
The preferred (and I would say the most natural way) to pass options to pytest
is to pass them to %pytest directly, e.g.:
%pytest -m "not network"
However, in case the options are long, manipulating PYTEST_ADDOPTS is also an
option, as shown in scipy.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[rpms/slic3r] PR #13: Convert to %autorelease and %autochangelog
churchyard merged a pull-request against the project: `slic3r` that you are following. Merged pull-request: `` Convert to %autorelease and %autochangelog `` https://src.fedoraproject.org/rpms/slic3r/pull-request/13 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted - pruning old rawhide chroots in Copr
On 18. 02. 24 13:54, Miroslav Suchý wrote: In Copr build system, we noticed that Fedora rawhide chroots can became large and they stay forever as rawhide is never EOLed. We plan to work on this soon, but we are not sure what is best approach. I want to ask you - the users of Copr - what will be convenient for you? The problem is described here https://github.com/fedora-copr/copr/issues/2933 tl;dr version is: * when you build into fedora-39 chroot then the chroot is one day declared as EOLed and if you did not act, then the chroot from the project is deleted and we reclaim the storage space. * when you build into rawhide chroot, then we keep last builds. Even if you do not submit to this project anything for years, we still keep this chroot. And such chroots can occupy gigabytes of storage. The problem is that builds in the rawhide can be packaged configs, and they can be still usable despite the fact that no one rebuilds the RPM for years. Or it can be forgotten build that is not even installable in current chroot. We do not know. And testing installability of package regularly will be expensive task. What **you** would find as acceptable policy for pruning rawhide chroots? If a build wasn't done in the copr chroot for long time, I would consider it acceptable to get a notification that my chroot will be purged unless I take an action. I think the EOLed chroots behave similarly, correct? A long time could be defined as a fixed period (e.g. 1 year, 2 years), or by the meaning of rawhide (e.g. when the last build was done when rawhide was the Fedora that goes EOL now, consider this rawhide chroot for purging). Are there other chroots with the same problems? opensuse-tumbleweed, openmandriva-cooker, openmandriva-rolling, mageia-cauldron... -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
List of long term FTBFS packages to be retired in 2 weeks
NOTE: This was not sent to individual maintainers, as @fedoraproject.org aliases are currently broken https://pagure.io/fedora-infrastructure/issue/11768 --- Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 2 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 erlang-jose@erlang-maint-sig, bowlofeggs, jcline, peter golang-github-acme-lego@go-sig, eclipseo golang-github-genuinetools-pkg @go-sig, eclipseo golang-github-gobs-pretty @go-sig, eclipseo golang-github-pierrre-compare @go-sig, eclipseo golang-github-smartystreets-goconvey @go-sig, alexsaezm, jchaloup golang-gvisor @go-sig, eclipseo, elmarco golang-opentelemetry-otel-0.20@go-sig, alexsaezm golang-sigs-k8s-kustomize @go-sig, dcavalca golang-vitess @go-sig, eclipseo infinipath-psmhonli j4-dmenu-desktop ibotty jackson-dataformats-binarymbooth jackson-dataformats-text mbooth java-1.8.0-openjdk-aarch32akasko, jvanek jreen rdieter libdeltacloud clalance mingw-clucene greghellings mingw-speexdspjanisozaur nbd-runnerxiubli nodejs-generic-pool patches, piotrp ofono njha, thunderbirdtr pesign-test-app javierm, nfrayer, pjones, rharwood pthsemixs rust-drg @rust-sig, jbtrystram The following packages require above mentioned packages: Depending on: erlang-jose (1) erlang-p1_acme (maintained by: @erlang-maint-sig, bowlofeggs, peter) erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose Depending on: golang-github-genuinetools-pkg (1) reg (maintained by: @go-sig, @infra-sig, mattia) reg-0.16.1-15.fc40.src requires golang(github.com/genuinetools/pkg/cli) Depending on: golang-github-gobs-pretty (2) golang-github-vinyldns (maintained by: @go-sig, eclipseo) golang-github-vinyldns-0.9.13-1.fc40.2.src requires golang(github.com/gobs/pretty) golang-github-acme-lego (maintained by: @go-sig, eclipseo) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/vinyldns/go-vinyldns/vinyldns) golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/vinyldns/go-vinyldns/vinyldns) Depending on: golang-github-smartystreets-goconvey (23) golang-github-afex-hystrix (maintained by: @go-sig, alexsaezm) golang-github-afex-hystrix-0-0.14.20190622gitfa1af6a.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-cucumber-godog (maintained by: @go-sig, eclipseo) golang-github-cucumber-godog-0.12.1-10.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-macaron-inject (maintained by: @go-sig, mikelo2) golang-github-macaron-inject-0-0.22.20210110git138e592.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-powerman-check (maintained by: @go-sig, eclipseo) golang-github-powerman-check-1.7.0-3.fc40.src requires golang(github.com/smartystreets/goconvey/convey), golang(github.com/smartystreets/goconvey/convey/reporting) golang-github-powerman-check-devel-1.7.0-3.fc40.noarch requires golang(github.com/smartystreets/goconvey/convey/reporting) golang-github-unknwon-com (maintained by: @go-sig, agerstmayr, nathans) golang-github-unknwon-com-1:1.0.1-9.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-unknwon-goconfig
List of long term FTBFS packages to be retired in February
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 3 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 calendar dcantrell, egoode erlang-jose bowlofeggs, erlang-maint-sig, jcline, peter ghdl sailer git-secrets keesdejong golang-github-acme-lego eclipseo, go-sig golang-github-gatherstars-com-jwzeclipseo, go-sig golang-github-genuinetools-pkg eclipseo, go-sig golang-github-gobs-prettyeclipseo, go-sig golang-github-jhillyerd-enmime eclipseo, go-sig golang-github-pierrre-compareeclipseo, go-sig golang-github-smartystreets-goconvey alexsaezm, go-sig, jchaloup golang-gopkg-square-jose-2 alexsaezm, go-sig golang-gvisoreclipseo, elmarco, go-sig golang-opentelemetry-otel-0.20 alexsaezm, go-sig golang-sigs-k8s-kustomizedcavalca, go-sig golang-vitesseclipseo, go-sig infinipath-psm honli j4-dmenu-desktop ibotty jackson-dataformats-binary mbooth jackson-dataformats-text mbooth java-1.8.0-openjdk-aarch32 akasko, jvanek jreenrdieter libdeltacloudclalance mingw-clucenegreghellings mingw-speexdsp janisozaur nbd-runner xiubli nodejs-generic-pool patches, piotrp ofononjha, thunderbirdtr pesign-test-app javierm, nfrayer, pjones, rharwood pthsem ixs rust-drg jbtrystram, rust-sig The following packages require above mentioned packages: Depending on: erlang-jose (1) erlang-p1_acme (maintained by: bowlofeggs, erlang-maint-sig, peter) erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose Depending on: golang-github-gatherstars-com-jwz (1) aerc (maintained by: eclipseo, go-sig) aerc-0.15.2-2.fc39.src requires golang(github.com/gatherstars-com/jwz) Depending on: golang-github-genuinetools-pkg (1) reg (maintained by: go-sig, infra-sig, mattia) reg-0.16.1-15.fc40.src requires golang(github.com/genuinetools/pkg/cli) Depending on: golang-github-gobs-pretty (2) golang-github-vinyldns (maintained by: eclipseo, go-sig) golang-github-vinyldns-0.9.13-1.fc40.2.src requires golang(github.com/gobs/pretty) golang-github-acme-lego (maintained by: eclipseo, go-sig) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/vinyldns/go-vinyldns/vinyldns) golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/vinyldns/go-vinyldns/vinyldns) Depending on: golang-github-jhillyerd-enmime (2) golang-github-gatherstars-com-jwz (maintained by: eclipseo, go-sig) golang-github-gatherstars-com-jwz-1.3.0-1.fc37.src requires golang(github.com/jhillyerd/enmime) aerc (maintained by: eclipseo, go-sig) aerc-0.15.2-2.fc39.src requires golang(github.com/gatherstars-com/jwz) Depending on: golang-github-pierrre-compare (1) golang-github-pierrre-geohash (maintained by: eclipseo, go-sig) golang-github-pierrre-geohash-1.0.0-9.fc40.src requires golang(github.com/pierrre/compare) Depending on: golang-github-smartystreets-goconvey (23) golang-github-afex-hystrix (maintained by: alexsaezm, go-sig) golang-github-afex-hystrix-0-0.14.20190622gitfa1af6a.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-cucumber-godog (maintained by: eclipseo, go-sig)
List of long term FTBFS packages to be retired in February
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 3 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 calendar dcantrell, egoode erlang-jose bowlofeggs, erlang-maint-sig, jcline, peter ghdl sailer git-secrets keesdejong golang-github-acme-lego eclipseo, go-sig golang-github-gatherstars-com-jwzeclipseo, go-sig golang-github-genuinetools-pkg eclipseo, go-sig golang-github-gobs-prettyeclipseo, go-sig golang-github-jhillyerd-enmime eclipseo, go-sig golang-github-pierrre-compareeclipseo, go-sig golang-github-smartystreets-goconvey alexsaezm, go-sig, jchaloup golang-gopkg-square-jose-2 alexsaezm, go-sig golang-gvisoreclipseo, elmarco, go-sig golang-opentelemetry-otel-0.20 alexsaezm, go-sig golang-sigs-k8s-kustomizedcavalca, go-sig golang-vitesseclipseo, go-sig infinipath-psm honli j4-dmenu-desktop ibotty jackson-dataformats-binary mbooth jackson-dataformats-text mbooth java-1.8.0-openjdk-aarch32 akasko, jvanek jreenrdieter libdeltacloudclalance mingw-clucenegreghellings mingw-speexdsp janisozaur nbd-runner xiubli nodejs-generic-pool patches, piotrp ofononjha, thunderbirdtr pesign-test-app javierm, nfrayer, pjones, rharwood pthsem ixs rust-drg jbtrystram, rust-sig The following packages require above mentioned packages: Depending on: erlang-jose (1) erlang-p1_acme (maintained by: bowlofeggs, erlang-maint-sig, peter) erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose Depending on: golang-github-gatherstars-com-jwz (1) aerc (maintained by: eclipseo, go-sig) aerc-0.15.2-2.fc39.src requires golang(github.com/gatherstars-com/jwz) Depending on: golang-github-genuinetools-pkg (1) reg (maintained by: go-sig, infra-sig, mattia) reg-0.16.1-15.fc40.src requires golang(github.com/genuinetools/pkg/cli) Depending on: golang-github-gobs-pretty (2) golang-github-vinyldns (maintained by: eclipseo, go-sig) golang-github-vinyldns-0.9.13-1.fc40.2.src requires golang(github.com/gobs/pretty) golang-github-acme-lego (maintained by: eclipseo, go-sig) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/vinyldns/go-vinyldns/vinyldns) golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/vinyldns/go-vinyldns/vinyldns) Depending on: golang-github-jhillyerd-enmime (2) golang-github-gatherstars-com-jwz (maintained by: eclipseo, go-sig) golang-github-gatherstars-com-jwz-1.3.0-1.fc37.src requires golang(github.com/jhillyerd/enmime) aerc (maintained by: eclipseo, go-sig) aerc-0.15.2-2.fc39.src requires golang(github.com/gatherstars-com/jwz) Depending on: golang-github-pierrre-compare (1) golang-github-pierrre-geohash (maintained by: eclipseo, go-sig) golang-github-pierrre-geohash-1.0.0-9.fc40.src requires golang(github.com/pierrre/compare) Depending on: golang-github-smartystreets-goconvey (23) golang-github-afex-hystrix (maintained by: alexsaezm, go-sig) golang-github-afex-hystrix-0-0.14.20190622gitfa1af6a.fc40.src requires golang(github.com/smartystreets/goconvey/convey) golang-github-cucumber-godog (maintained by: eclipseo, go-sig)
List of long term FTBFS packages to be retired in February
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 4 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 calendardcantrell, egoode erlang-jose bowlofeggs, erlang-maint-sig, jcline, peter ghdlsailer git-secrets keesdejong golang-github-acme-lego eclipseo, go-sig golang-github-gatherstars-com-jwz eclipseo, go-sig golang-github-genuinetools-pkg eclipseo, go-sig golang-github-gobs-pretty eclipseo, go-sig golang-github-jhillyerd-enmime eclipseo, go-sig golang-github-pierrre-compare eclipseo, go-sig golang-github-smartystreets-goconvey alexsaezm, go-sig, jchaloup golang-gopkg-square-jose-2 alexsaezm, go-sig golang-gvisor eclipseo, elmarco, go-sig golang-opentelemetry-otel-0.20 alexsaezm, go-sig golang-sigs-k8s-kustomize dcavalca, go-sig golang-vitess eclipseo, go-sig infinipath-psm honli j4-dmenu-desktopibotty jackson-dataformats-binary mbooth jackson-dataformats-textmbooth java-1.8.0-openjdk-aarch32 akasko, jvanek jreen rdieter libdeltacloud clalance mingw-clucene greghellings mingw-speexdsp janisozaur nbd-runner xiubli nodejs-generic-pool patches, piotrp ofono njha, thunderbirdtr openni-primesense cottsay, jkastner, rmattes pesign-test-app javierm, nfrayer, pjones, rharwood pthsem ixs rust-drgjbtrystram, rust-sig telepathy-gabbleaperezbios The following packages require above mentioned packages: Depending on: erlang-jose (1) erlang-p1_acme (maintained by: bowlofeggs, erlang-maint-sig, peter) erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose Depending on: golang-github-gatherstars-com-jwz (1) aerc (maintained by: eclipseo, go-sig) aerc-0.15.2-2.fc39.src requires golang(github.com/gatherstars-com/jwz) Depending on: golang-github-genuinetools-pkg (1) reg (maintained by: go-sig, infra-sig, mattia) reg-0.16.1-15.fc40.src requires golang(github.com/genuinetools/pkg/cli) Depending on: golang-github-gobs-pretty (2) golang-github-vinyldns (maintained by: eclipseo, go-sig) golang-github-vinyldns-0.9.13-1.fc40.2.src requires golang(github.com/gobs/pretty) golang-github-acme-lego (maintained by: eclipseo, go-sig) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/vinyldns/go-vinyldns/vinyldns) golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/vinyldns/go-vinyldns/vinyldns) Depending on: golang-github-jhillyerd-enmime (2) golang-github-gatherstars-com-jwz (maintained by: eclipseo, go-sig) golang-github-gatherstars-com-jwz-1.3.0-1.fc37.src requires golang(github.com/jhillyerd/enmime) aerc (maintained by: eclipseo, go-sig) aerc-0.15.2-2.fc39.src requires golang(github.com/gatherstars-com/jwz) Depending on: golang-github-pierrre-compare (1) golang-github-pierrre-geohash (maintained by: eclipseo, go-sig) golang-github-pierrre-geohash-1.0.0-9.fc40.src requires golang(github.com/pierrre/compare) Depending on: golang-github-smartystreets-goconvey (23) golang-github-afex-hystrix (maintained by: alexsaezm, go-sig) golang-github-afex-hystrix-0-0.14.20190622gitfa1af6a.fc40.src requires golang(github.com/smartystreets/goconvey/convey)
List of long term FTBFS packages to be retired in February
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 4 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 calendardcantrell, egoode erlang-jose bowlofeggs, erlang-maint-sig, jcline, peter ghdlsailer git-secrets keesdejong golang-github-acme-lego eclipseo, go-sig golang-github-gatherstars-com-jwz eclipseo, go-sig golang-github-genuinetools-pkg eclipseo, go-sig golang-github-gobs-pretty eclipseo, go-sig golang-github-jhillyerd-enmime eclipseo, go-sig golang-github-pierrre-compare eclipseo, go-sig golang-github-smartystreets-goconvey alexsaezm, go-sig, jchaloup golang-gopkg-square-jose-2 alexsaezm, go-sig golang-gvisor eclipseo, elmarco, go-sig golang-opentelemetry-otel-0.20 alexsaezm, go-sig golang-sigs-k8s-kustomize dcavalca, go-sig golang-vitess eclipseo, go-sig infinipath-psm honli j4-dmenu-desktopibotty jackson-dataformats-binary mbooth jackson-dataformats-textmbooth java-1.8.0-openjdk-aarch32 akasko, jvanek jreen rdieter libdeltacloud clalance mingw-clucene greghellings mingw-speexdsp janisozaur nbd-runner xiubli nodejs-generic-pool patches, piotrp ofono njha, thunderbirdtr openni-primesense cottsay, jkastner, rmattes pesign-test-app javierm, nfrayer, pjones, rharwood pthsem ixs rust-drgjbtrystram, rust-sig telepathy-gabbleaperezbios The following packages require above mentioned packages: Depending on: erlang-jose (1) erlang-p1_acme (maintained by: bowlofeggs, erlang-maint-sig, peter) erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose Depending on: golang-github-gatherstars-com-jwz (1) aerc (maintained by: eclipseo, go-sig) aerc-0.15.2-2.fc39.src requires golang(github.com/gatherstars-com/jwz) Depending on: golang-github-genuinetools-pkg (1) reg (maintained by: go-sig, infra-sig, mattia) reg-0.16.1-15.fc40.src requires golang(github.com/genuinetools/pkg/cli) Depending on: golang-github-gobs-pretty (2) golang-github-vinyldns (maintained by: eclipseo, go-sig) golang-github-vinyldns-0.9.13-1.fc40.2.src requires golang(github.com/gobs/pretty) golang-github-acme-lego (maintained by: eclipseo, go-sig) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/vinyldns/go-vinyldns/vinyldns) golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/vinyldns/go-vinyldns/vinyldns) Depending on: golang-github-jhillyerd-enmime (2) golang-github-gatherstars-com-jwz (maintained by: eclipseo, go-sig) golang-github-gatherstars-com-jwz-1.3.0-1.fc37.src requires golang(github.com/jhillyerd/enmime) aerc (maintained by: eclipseo, go-sig) aerc-0.15.2-2.fc39.src requires golang(github.com/gatherstars-com/jwz) Depending on: golang-github-pierrre-compare (1) golang-github-pierrre-geohash (maintained by: eclipseo, go-sig) golang-github-pierrre-geohash-1.0.0-9.fc40.src requires golang(github.com/pierrre/compare) Depending on: golang-github-smartystreets-goconvey (23) golang-github-afex-hystrix (maintained by: alexsaezm, go-sig) golang-github-afex-hystrix-0-0.14.20190622gitfa1af6a.fc40.src requires golang(github.com/smartystreets/goconvey/convey)
Re: Orphaned python-mccabe (dependency of pylint)
On 01. 02. 24 0:51, Michel Lind wrote: I see limb already took the package (thanks limb) - note that the default bugzilla assignee still seems to be 'orphan', I'm assuming that will fix itself eventually Not by itself, the package has a epel bugzilla contact override, so when the main admin changes, the fedora bugzilla contact needs to be changed as well. I've just done 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Wx] PR #3: Remove unneeded complexity of the gtk requires hack
churchyard opened a new pull-request against the project: `perl-Wx` that you are following: `` Remove unneeded complexity of the gtk requires hack `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Wx/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned python-mccabe (dependency of pylint)
Hello.
I have orphaned python-mccabe.
It does not build with updated hypothesis, because the update broke
hypothesmith and I don't have time to look into it:
https://bugzilla.redhat.com/2261579
mccabe is a dependency of pylint.
Packages other than linters should not BuildRequire pylint in Fedora (but they
do).
The recursive dependency tree is very large. Here are some basics:
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe
pylint-0:3.0.3-3.fc40.src
python-f5-icontrol-rest-0:1.3.15-11.fc39.src
python-flake8-0:6.0.0-2.fc39.src
python-lsp-server-0:1.9.0-3.fc40.src
python-twitter-0:3.5-18.fc39.src
python3-flake8-0:6.0.0-2.fc39.noarch
python3-lsp-server+all-0:1.9.0-3.fc40.noarch
python3-pylint-0:3.0.3-3.fc40.noarch
$ repoquery -q --repo=rawhide{,-source} --whatrequires pylint --whatrequires
python3-pylint
crypto-policies-0:20231204-1.git1e3a2e4.fc40.src
distro-info-0:0.18-18.fc39.src
dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch
foomuuri-0:0.21-1.fc40.src
nordugrid-arc-0:6.18.0-2.fc40.src
nvme-stas-0:2.3.1-1.fc40.src
postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch
pylint-0:3.0.3-3.fc40.noarch
python-geoplot-0:0.5.1-7.fc40.src
python-guessit-0:3.8.0-1.fc40.src
python-hwdata-0:2.3.8-4.fc39.src
python-platformio-0:6.1.13-1.fc40.src
python-pocketlint-0:0.25-1.fc40.src
python-pylint-venv-0:3.0.2-1.fc40.src
python-rebulk-0:3.3.0-1.fc40.src
python3-pocketlint-0:0.25-1.fc40.noarch
python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch
thonny-0:4.1.4-1.fc40.noarch
thonny-0:4.1.4-1.fc40.src
vcs-diff-lint-0:4-3.fc39.noarch
vim-syntastic-python-0:3.10.0-21.fc39.noarch
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe
--recursive
crypto-policies-0:20231204-1.git1e3a2e4.fc40.src
diskimage-builder-0:3.31.0-2.fc40.noarch
distro-info-0:0.18-18.fc39.src
dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch
foomuuri-0:0.21-1.fc40.src
glances-0:3.4.0-3.fc39.src
mu-0:1.2.0-10.fc40.noarch
mu-0:1.2.0-10.fc40.src
nordugrid-arc-0:6.18.0-2.fc40.src
nvme-stas-0:2.3.1-1.fc40.src
ocaml-atd-0:2.15.0-3.fc40.src
piper-0:0.7-5.fc39.src
postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch
pyee-0:9.0.4-6.fc39.src
pylint-0:3.0.3-3.fc40.noarch
pylint-0:3.0.3-3.fc40.src
python-binary-memcached-0:0.31.2-2.fc39.src
python-croniter-0:1.4.1-1.fc40.src
python-debianbts-0:2.8.2-13.fc39.src
python-django-formtools-0:2.2-10.fc39.src
python-esbonio-0:0.16.4-3.fc40.src
python-f5-icontrol-rest-0:1.3.15-11.fc39.src
python-factory-boy-0:3.3.0-1.fc40.src
python-flake8-0:6.0.0-2.fc39.src
python-flake8-builtins-0:2.1.0-4.fc39.src
python-flake8-comprehensions-0:3.10.1-6.fc39.src
python-flake8-import-order-0:0.18.2-3.fc39.src
python-flake8-polyfill-0:1.0.2-19.fc39.src
python-flake8-quotes-0:3.3.2-4.fc39.src
python-flask-mailman-0:1.0.0-1.fc40.src
python-geoplot-0:0.5.1-7.fc40.src
python-gerritlib-0:0.6.0-24.fc39.src
python-guessit-0:3.8.0-1.fc40.src
python-hacking-0:6.0.1-1.fc40.src
python-hwdata-0:2.3.8-4.fc39.src
python-ipmi-0:0.5.4-3.fc39.src
python-lsp-server-0:1.9.0-3.fc40.src
python-nashpy-0:0.0.40-1.fc39.src
python-nikola-0:8.2.4-4.fc39.src
python-oslo-context-0:5.2.0-1.fc40.src
python-oslo-service-0:3.1.1-8.fc40.src
python-pep8-naming-0:0.13.3-3.fc39.src
python-platformio-0:6.1.13-1.fc40.src
python-pocketlint-0:0.25-1.fc40.src
python-pylint-venv-0:3.0.2-1.fc40.src
python-pymochad-0:0.2.0-10.fc39.src
python-pytest-flake8-path-0:1.5.0-1.fc39.src
python-rebulk-0:3.3.0-1.fc40.src
python-sqlalchemy-utils-0:0.41.1-2.fc39.src
python-twitter-0:3.5-18.fc39.src
python3-esbonio+dev-0:0.16.4-3.fc40.noarch
python3-flake8-0:6.0.0-2.fc39.noarch
python3-flake8-builtins-0:2.1.0-4.fc39.noarch
python3-flake8-comprehensions-0:3.10.1-6.fc39.noarch
python3-flake8-docstrings-0:1.6.0-6.fc39.noarch
python3-flake8-import-order-0:0.18.2-3.fc39.noarch
python3-flake8-polyfill-0:1.0.2-19.fc39.noarch
python3-flake8-quotes-0:3.3.2-4.fc39.noarch
python3-hacking-0:6.0.1-1.fc40.noarch
python3-lsp-server+all-0:1.9.0-3.fc40.noarch
python3-oslo-concurrency-tests-0:5.2.0-1.fc40.noarch
python3-oslo-service-tests-0:3.1.1-8.fc40.noarch
python3-oslo-utils-tests-0:6.2.1-1.fc40.noarch
python3-pep8-naming-0:0.13.3-3.fc39.noarch
python3-pocketlint-0:0.25-1.fc40.noarch
python3-pylint-0:3.0.3-3.fc40.noarch
python3-pytest-flake8-path-0:1.5.0-1.fc39.noarch
python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch
python3-tackerclient-tests-unit-0:1.14.0-1.fc40.noarch
quodlibet-0:4.6.0-1.fc40.src
repo-0:2.35-1.fc39.src
spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.src
thonny-0:4.1.4-1.fc40.noarch
thonny-0:4.1.4-1.fc40.src
vcs-diff-lint-0:4-3.fc39.noarch
vim-syntastic-python-0:3.10.0-21.fc39.noarch
xr-hardware-0:1.1.0-1.fc40.src
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct
Orphaned python-mccabe (dependency of pylint)
Hello.
I have orphaned python-mccabe.
It does not build with updated hypothesis, because the update broke
hypothesmith and I don't have time to look into it:
https://bugzilla.redhat.com/2261579
mccabe is a dependency of pylint.
Packages other than linters should not BuildRequire pylint in Fedora (but they
do).
The recursive dependency tree is very large. Here are some basics:
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe
pylint-0:3.0.3-3.fc40.src
python-f5-icontrol-rest-0:1.3.15-11.fc39.src
python-flake8-0:6.0.0-2.fc39.src
python-lsp-server-0:1.9.0-3.fc40.src
python-twitter-0:3.5-18.fc39.src
python3-flake8-0:6.0.0-2.fc39.noarch
python3-lsp-server+all-0:1.9.0-3.fc40.noarch
python3-pylint-0:3.0.3-3.fc40.noarch
$ repoquery -q --repo=rawhide{,-source} --whatrequires pylint --whatrequires
python3-pylint
crypto-policies-0:20231204-1.git1e3a2e4.fc40.src
distro-info-0:0.18-18.fc39.src
dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch
foomuuri-0:0.21-1.fc40.src
nordugrid-arc-0:6.18.0-2.fc40.src
nvme-stas-0:2.3.1-1.fc40.src
postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch
pylint-0:3.0.3-3.fc40.noarch
python-geoplot-0:0.5.1-7.fc40.src
python-guessit-0:3.8.0-1.fc40.src
python-hwdata-0:2.3.8-4.fc39.src
python-platformio-0:6.1.13-1.fc40.src
python-pocketlint-0:0.25-1.fc40.src
python-pylint-venv-0:3.0.2-1.fc40.src
python-rebulk-0:3.3.0-1.fc40.src
python3-pocketlint-0:0.25-1.fc40.noarch
python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch
thonny-0:4.1.4-1.fc40.noarch
thonny-0:4.1.4-1.fc40.src
vcs-diff-lint-0:4-3.fc39.noarch
vim-syntastic-python-0:3.10.0-21.fc39.noarch
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe
--recursive
crypto-policies-0:20231204-1.git1e3a2e4.fc40.src
diskimage-builder-0:3.31.0-2.fc40.noarch
distro-info-0:0.18-18.fc39.src
dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch
foomuuri-0:0.21-1.fc40.src
glances-0:3.4.0-3.fc39.src
mu-0:1.2.0-10.fc40.noarch
mu-0:1.2.0-10.fc40.src
nordugrid-arc-0:6.18.0-2.fc40.src
nvme-stas-0:2.3.1-1.fc40.src
ocaml-atd-0:2.15.0-3.fc40.src
piper-0:0.7-5.fc39.src
postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch
pyee-0:9.0.4-6.fc39.src
pylint-0:3.0.3-3.fc40.noarch
pylint-0:3.0.3-3.fc40.src
python-binary-memcached-0:0.31.2-2.fc39.src
python-croniter-0:1.4.1-1.fc40.src
python-debianbts-0:2.8.2-13.fc39.src
python-django-formtools-0:2.2-10.fc39.src
python-esbonio-0:0.16.4-3.fc40.src
python-f5-icontrol-rest-0:1.3.15-11.fc39.src
python-factory-boy-0:3.3.0-1.fc40.src
python-flake8-0:6.0.0-2.fc39.src
python-flake8-builtins-0:2.1.0-4.fc39.src
python-flake8-comprehensions-0:3.10.1-6.fc39.src
python-flake8-import-order-0:0.18.2-3.fc39.src
python-flake8-polyfill-0:1.0.2-19.fc39.src
python-flake8-quotes-0:3.3.2-4.fc39.src
python-flask-mailman-0:1.0.0-1.fc40.src
python-geoplot-0:0.5.1-7.fc40.src
python-gerritlib-0:0.6.0-24.fc39.src
python-guessit-0:3.8.0-1.fc40.src
python-hacking-0:6.0.1-1.fc40.src
python-hwdata-0:2.3.8-4.fc39.src
python-ipmi-0:0.5.4-3.fc39.src
python-lsp-server-0:1.9.0-3.fc40.src
python-nashpy-0:0.0.40-1.fc39.src
python-nikola-0:8.2.4-4.fc39.src
python-oslo-context-0:5.2.0-1.fc40.src
python-oslo-service-0:3.1.1-8.fc40.src
python-pep8-naming-0:0.13.3-3.fc39.src
python-platformio-0:6.1.13-1.fc40.src
python-pocketlint-0:0.25-1.fc40.src
python-pylint-venv-0:3.0.2-1.fc40.src
python-pymochad-0:0.2.0-10.fc39.src
python-pytest-flake8-path-0:1.5.0-1.fc39.src
python-rebulk-0:3.3.0-1.fc40.src
python-sqlalchemy-utils-0:0.41.1-2.fc39.src
python-twitter-0:3.5-18.fc39.src
python3-esbonio+dev-0:0.16.4-3.fc40.noarch
python3-flake8-0:6.0.0-2.fc39.noarch
python3-flake8-builtins-0:2.1.0-4.fc39.noarch
python3-flake8-comprehensions-0:3.10.1-6.fc39.noarch
python3-flake8-docstrings-0:1.6.0-6.fc39.noarch
python3-flake8-import-order-0:0.18.2-3.fc39.noarch
python3-flake8-polyfill-0:1.0.2-19.fc39.noarch
python3-flake8-quotes-0:3.3.2-4.fc39.noarch
python3-hacking-0:6.0.1-1.fc40.noarch
python3-lsp-server+all-0:1.9.0-3.fc40.noarch
python3-oslo-concurrency-tests-0:5.2.0-1.fc40.noarch
python3-oslo-service-tests-0:3.1.1-8.fc40.noarch
python3-oslo-utils-tests-0:6.2.1-1.fc40.noarch
python3-pep8-naming-0:0.13.3-3.fc39.noarch
python3-pocketlint-0:0.25-1.fc40.noarch
python3-pylint-0:3.0.3-3.fc40.noarch
python3-pytest-flake8-path-0:1.5.0-1.fc39.noarch
python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch
python3-tackerclient-tests-unit-0:1.14.0-1.fc40.noarch
quodlibet-0:4.6.0-1.fc40.src
repo-0:2.35-1.fc39.src
spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.src
thonny-0:4.1.4-1.fc40.noarch
thonny-0:4.1.4-1.fc40.src
vcs-diff-lint-0:4-3.fc39.noarch
vim-syntastic-python-0:3.10.0-21.fc39.noarch
xr-hardware-0:1.1.0-1.fc40.src
--
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
[rpms/slic3r] PR #13: Convert to %autorelease and %autochangelog
churchyard opened a new pull-request against the project: `slic3r` that you are following: `` Convert to %autorelease and %autochangelog `` To reply, visit the link below https://src.fedoraproject.org/rpms/slic3r/pull-request/13 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Wx-GLCanvas] PR #3: Convert to %autorelease and %autochangelog
churchyard opened a new pull-request against the project: `perl-Wx-GLCanvas` that you are following: `` Convert to %autorelease and %autochangelog `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Wx-GLCanvas/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Module-Build-WithXSpp] PR #1: Convert to %autorelease and %autochangelog
churchyard opened a new pull-request against the project: `perl-Module-Build-WithXSpp` that you are following: `` Convert to %autorelease and %autochangelog `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Module-Build-WithXSpp/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Growl-GNTP] PR #1: Convert to %autorelease and %autochangelog
churchyard opened a new pull-request against the project: `perl-Growl-GNTP` that you are following: `` Convert to %autorelease and %autochangelog `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Growl-GNTP/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-ExtUtils-Typemaps-Default] PR #1: Convert to %autorelease and %autochangelog
churchyard opened a new pull-request against the project: `perl-ExtUtils-Typemaps-Default` that you are following: `` Convert to %autorelease and %autochangelog `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-ExtUtils-Typemaps-Default/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-ExtUtils-CppGuess] PR #2: Convert to %autorelease and %autochangelog
churchyard opened a new pull-request against the project: `perl-ExtUtils-CppGuess` that you are following: `` Convert to %autorelease and %autochangelog `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-ExtUtils-CppGuess/pull-request/2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
List of long term FTBFS packages to be retired in February
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 5 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 cl-asdf green erlang-jose bowlofeggs, erlang-maint-sig, jcline, peter fwtsbenzea ghdlsailer git-secrets keesdejong golang-github-acme-lego eclipseo, go-sig golang-github-eclesh-welford abulimov, dcavalca, go-sig golang-github-gatherstars-com-jwzeclipseo, go-sig golang-github-genuinetools-pkg eclipseo, go-sig golang-github-gobs-prettyeclipseo, go-sig golang-github-google-gopacketgo-sig, salimma golang-github-jhillyerd-enmime eclipseo, go-sig golang-github-pierrre-compareeclipseo, go-sig golang-github-smartystreets-goconvey alexsaezm, go-sig, jchaloup golang-gopkg-square-jose-2 alexsaezm, go-sig golang-gvisoreclipseo, elmarco, go-sig golang-opentelemetry-otel-0.20 alexsaezm, go-sig golang-sigs-k8s-kustomizedcavalca, go-sig golang-vitesseclipseo, go-sig infinipath-psm honli j4-dmenu-desktop ibotty jackson-dataformats-binary mbooth jackson-dataformats-text mbooth java-1.8.0-openjdk-aarch32 akasko, jvanek jreenrdieter kdevelop-pg-qt jgrulich, kde-sig, rdieter, than libdeltacloudclalance libva-v4l2-request kwizart, rathann lmms thm lxc hguemar, sagarun, thm mingw-clucenegreghellings mingw-cppunitkwizart mingw-dirac kwizart mingw-speexdsp janisozaur nbd-runner xiubli nodejs-generic-pool patches, piotrp ofononjha, thunderbirdtr openni-primesensecottsay, jkastner, rmattes pcmciautils harald pesign-test-app javierm, nfrayer, pjones, rwood pthsem ixs rust-drg jbtrystram, rust-sig telepathy-gabble aperezbios yaksazbyszek The following packages require above mentioned packages: Depending on: cl-asdf (5) common-lisp-controller (maintained by: green) common-lisp-controller-7.4-26.fc39.noarch requires cl-asdf emacs-slime (maintained by: bkreuter, salimma) emacs-slime-2:2.28-2.fc39.noarch requires common-lisp-controller emacs-slime-2:2.28-2.fc39.src requires common-lisp-controller sbcl (maintained by: green, rdieter) sbcl-2.3.11-1.fc40.src requires common-lisp-controller sbcl-2.3.11-1.fc40.x86_64 requires common-lisp-controller maxima (maintained by: jamatos, rdieter) maxima-5.45.1-6.fc40.src requires sbcl wxMaxima (maintained by: jamatos, rdieter) wxMaxima-20.12.1-10.fc39.x86_64 requires maxima Depending on: erlang-jose (1) erlang-p1_acme (maintained by: bowlofeggs, erlang-maint-sig, peter) erlang-p1_acme-1.0.8-6.fc38.noarch requires erlang-jose erlang-p1_acme-1.0.8-6.fc38.src requires erlang-jose Depending on: golang-github-eclesh-welford (1) golang-github-facebook-time (maintained by: abulimov, dcavalca, go-sig, leoleovich, salimma) golang-github-facebook-time-0^20240118git2f194ba-1.fc40.src requires golang(github.com/eclesh/welford) golang-github-facebook-time-devel-0^20240118git2f194ba-1.fc40.noarch requires
Re: Orphaning python-flit
On 26. 01. 24 4:33, Nico Kadel-Garcia wrote: What is the*fascination* with splitting and renaming packages this way? No idea generally, but in the world of Python packaging, the two cases I know (poetry, flit) were motivated by folks not wanting to pull in full-blown package and environment management apps when they only want to pip install something that uses it. The split made a lot of sense. core - PEP517 backend https://peps.python.org/pep-0517/ the rest - an app that let's you "manage" your project Scenario: - The developer uses the full app to create and develop the project. - The user uses -core to build and install it. (Obviously a developer is free to just use -core as well, if they like it. Many upstream projects use flit-core only.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-flit
On 26. 01. 24 4:33, Nico Kadel-Garcia wrote: What is the*fascination* with splitting and renaming packages this way? No idea generally, but in the world of Python packaging, the two cases I know (poetry, flit) were motivated by folks not wanting to pull in full-blown package and environment management apps when they only want to pip install something that uses it. The split made a lot of sense. core - PEP517 backend https://peps.python.org/pep-0517/ the rest - an app that let's you "manage" your project Scenario: - The developer uses the full app to create and develop the project. - The user uses -core to build and install it. (Obviously a developer is free to just use -core as well, if they like it. Many upstream projects use flit-core only.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning python-flit
Hello.
Now when python-flit-core has been split out of python-flit, I do no longer
have a use-case for python-flit and hence I have orphaned it.
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
python-perky-0:0.8.2-3.fc39.src
python-pydyf-0:0.8.0-1.fc40.src
python-pyrpm-0:0.14.1-3.fc39.src
python-signature-dispatch-0:1.0.1-4.fc39.src
python-vecrec-0:0.3.1-11.fc40.src
weasyprint-0:60.2-1.fc40.src
The packages would probably build fine with flit-core (happy to help with that
if you are interested).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Orphaning python-flit
Hello.
Now when python-flit-core has been split out of python-flit, I do no longer
have a use-case for python-flit and hence I have orphaned it.
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
python-perky-0:0.8.2-3.fc39.src
python-pydyf-0:0.8.0-1.fc40.src
python-pyrpm-0:0.14.1-3.fc39.src
python-signature-dispatch-0:1.0.1-4.fc39.src
python-vecrec-0:0.3.1-11.fc40.src
weasyprint-0:60.2-1.fc40.src
The packages would probably build fine with flit-core (happy to help with that
if you are interested).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Staled PRs at https://src.fedoraproject.org/rpms/
On 25. 01. 24 19:17, Florian Weimer wrote: * Miroslav Suchý: I want to point to nice feature of Pagure - it can show you PR where you can act on: https://src.fedoraproject.org/user/msuchy/requests?type=actionable=open (your account icon -> My Pull Request -> PR I can act on) Please check it, maybe you will discover some PR that is waiting on your feedback and you are not aware of it. Is there a way to merge PR lists from multiple packages into a single backlog? We try to keep an eye on the bug list for our components, but that only works (to some extent …) because Bugzilla allows us to consolidate everything into a single list. If we had this for PRs, it would really help, I think. You can use the packager dashboard: https://packager-dashboard.fedoraproject.org/dashboard?users=fweimer,churchyard On the top right corner, you can click the git icon to only see PRs (probably not possible via a bookmarked URL but if that is the only blocker for your workflow, open an issue). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On 24. 01. 24 19:00, Ralf Corsépius wrote: Am 24.01.24 um 17:38 schrieb Miro Hrončok: Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 5 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 freefem++ (maintained by: cicku, corsepiu) freefem++-openmpi-4.14-3.fc40.x86_64 requires libmpi.so.40()(64bit)(openmpi-x86_64) WTH is this? Your script seems broken. This is a 2-level deep dependency on a package that fails to build. Thanks for your feedback. Occasionally, "my" script is broken, but what you reported is not actually incorrect. See further. Neither is cicku a maintainer of freefem++ They are listed as such at https://src.fedoraproject.org/rpms/freefem++ nor did it fail to build. It did not. It depends on openmpi which depends on infinipath-psm which fails to build. Actually this package had been built several times in recent months/weeks. Koji lists it as having been rebuilt today! Correct. And while we are at it: Why is cicku still listed as a maintainer? I don't know. He was removed from Fedora by force due to a FESCO decision many years ago. I don't recall the details, but this can easily be 10 years ago. Then, perhaps the removal was not complete. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On 24. 01. 24 17:50, Michel Lind wrote: On Wed, Jan 24, 2024 at 05:38:59PM +0100, Miro Hrončok wrote: Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. [snip] golang-github-eclesh-welford abulimov, dcavalca, go-sig I fixed this one last week - curious how it ended up on the list? No successful Rawhide build. https://bodhi.fedoraproject.org/updates/?packages=golang-github-eclesh-welford https://bugz.fedoraproject.org/golang-github-eclesh-welford shows no bug open (though I noticed it just failed in the mass rebuild) This report is not based on bugzillas, only Rawhide builds. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
List of long term FTBFS packages to be retired in February
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 5 weeks, i.e. around 2024-02-28. Since this is unfortunately after the branching, packages will be retired on rawhide and f40. I apologize for starting this process a bit later than required again. Unfortunately, I had other work obligations. Volunteers to take over this are always welcome. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 37. 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 cl-asdf green erlang-jose bowlofeggs, erlang-maint-sig, jcline, peter fwtsbenzea ghdlsailer git-secrets keesdejong golang-github-acme-lego eclipseo, go-sig golang-github-eclesh-welford abulimov, dcavalca, go-sig golang-github-gatherstars-com-jwzeclipseo, go-sig golang-github-genuinetools-pkg eclipseo, go-sig golang-github-gobs-prettyeclipseo, go-sig golang-github-google-gopacketgo-sig, salimma golang-github-jhillyerd-enmime eclipseo, go-sig golang-github-pierrre-compareeclipseo, go-sig golang-github-smartystreets-goconvey alexsaezm, go-sig, jchaloup golang-gopkg-square-jose-2 alexsaezm, go-sig golang-gvisoreclipseo, elmarco, go-sig golang-opentelemetry-otel-0.20 alexsaezm, go-sig golang-sigs-k8s-kustomizedcavalca, go-sig golang-vitesseclipseo, go-sig infinipath-psm honli j4-dmenu-desktop ibotty jackson-dataformats-binary mbooth jackson-dataformats-text mbooth java-1.8.0-openjdk-aarch32 akasko, jvanek jreenrdieter kdevelop-pg-qt jgrulich, kde-sig, rdieter, than libdeltacloudclalance libva-v4l2-request kwizart, rathann lmms thm lxc hguemar, sagarun, thm mingw-clucenegreghellings mingw-cppunitkwizart mingw-dirac kwizart mingw-speexdsp janisozaur nbd-runner xiubli nodejs-generic-pool patches, piotrp ofononjha, thunderbirdtr openni-primesensecottsay, jkastner, rmattes pcmciautils harald pesign-test-app javierm, nfrayer, pjones, rwood pthsem ixs rust-drg jbtrystram, rust-sig telepathy-gabble aperezbios yaksazbyszek The following packages require above mentioned packages: Depending on: cl-asdf (5) common-lisp-controller (maintained by: green) common-lisp-controller-7.4-26.fc39.noarch requires cl-asdf emacs-slime (maintained by: bkreuter, salimma) emacs-slime-2:2.28-2.fc39.noarch requires common-lisp-controller emacs-slime-2:2.28-2.fc39.src requires common-lisp-controller sbcl (maintained by: green, rdieter) sbcl-2.3.11-1.fc40.src requires common-lisp-controller sbcl-2.3.11-1.fc40.x86_64 requires common-lisp-controller maxima (maintained by: jamatos, rdieter) maxima-5.45.1-6.fc40.src requires sbcl wxMaxima (maintained by: jamatos, rdieter) wxMaxima-20.12.1-10.fc39.x86_64 requires maxima Depending on: erlang-jose (1) erlang-p1_acme (maintained by: bowlofeggs, erlang-maint-sig, peter) erlang-p1_acme-1.0.8-6.fc38.noarch requires erlang-jose erlang-p1_acme-1.0.8-6.fc38.src requires erlang-jose Depending on: golang-github-eclesh-welford (1) golang-github-facebook-time (maintained by: abulimov, dcavalca, go-sig, leoleovich, salimma) golang-github-facebook-time-0^20240118git2f194ba-1.fc40.src requires golang(github.com/eclesh/welford) golang-github-facebook-time-devel-0^20240118git2f194ba-1.fc40.noarch requires
Re: Lost KDC for FEDORAPROJECT.ORG realm
On 23. 01. 24 16:08, Steve Dickson wrote: Hello, I had to change my /etc/krb5.conf do to some realm changes... and now when I to a kinit to FEDORAPROJECT.ORG it hangs for a while then errors with kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while getting initial credentials My question is, what has to be in the /etc/krb5.conf for the FEDORAPROJECT.ORG realm to be found? In the past I didn't think there was anything in the file and assume the realm was found by the includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ Any ideas? There is an ongoing outage of FAS, see https://status.fedoraproject.org/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: Eliminate buildroot overrides
On 22. 01. 24 20:20, Stephen Gallagher wrote: On Mon, Jan 22, 2024 at 2:11 PM Miro Hrončok wrote: In the meantime, if we otherwise disabled free-access buildroot overrides, this would definitely be grounds for granting an exception. How would that work? Would I ask FESCo every time I need to do it? If it's something that a specific packager has justifiable cause to do on a regular basis, I think we could potentially grant them that privilege (at least until we get a proper solution in place). Or do you think this is the sort of thing where the number of people needing this access would be prohibitively high? Probably 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: Eliminate buildroot overrides
On 22. 01. 24 20:04, Stephen Gallagher wrote: On Mon, Jan 22, 2024 at 1:55 PM Miro Hrončok wrote: On 22. 01. 24 19:07, Stephen Gallagher wrote: I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up. Every time somebody asks this, I say: Pull Requests CI I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago. It works in CentOS Stream, but not in Fedora. Without that, I sometimes need to create a buildroot override to be able to test the the second package change before merging it. This sounds a lot more like a workaround than a use-case, but it's good to know about. So thank you. Yes, it is. Unfortunately, I feel like that workaround is dangerous, since it is putting untested code into the buildroot. In this case the PR-based CI has already passed for the build I add as a buidlroot override. I would like to see that get fixed properly with support for the side tags. I would like that very much. However, it seems it has not been a priority. In the meantime, if we otherwise disabled free-access buildroot overrides, this would definitely be grounds for granting an exception. How would that work? Would I ask FESCo every time I need to do 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: Eliminate buildroot overrides
On 22. 01. 24 19:07, Stephen Gallagher wrote: I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up. Every time somebody asks this, I say: Pull Requests CI I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago. It works in CentOS Stream, but not in Fedora. Without that, I sometimes need to create a buildroot override to be able to test the the second package change before merging 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/slic3r] PR #12: Fix FTBFS with GCC 14
churchyard merged a pull-request against the project: `slic3r` that you are following. Merged pull-request: `` Fix FTBFS with GCC 14 `` https://src.fedoraproject.org/rpms/slic3r/pull-request/12 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
