Re: Self Introduction: Alexey Lunev (xbt573)
Hey, Am 25.09.24 um 20:43 schrieb Alexey Lunev: I'm planning to contribute software that i like, but it is currently unavailable in repos (gdu, navidrome, openmw). Oh, navidrome would be nice. Thank you for joining the Fedora packager community. Felix -- ___ 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
systemd timers are not enabled by default even though listed in preset files
There is a long-standing issue with certbot that the certbot-renew timer is not enabled by default even though it is listed in "90-default.preset" (fedora-release/epel-release): https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/90-default.preset Any idea how to debug this? I think it is not specific to certbot - for example x509watch.timer seems to be affected as well. Felix -- ___ 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: review swap: aactivator (Python)
Am 08.08.24 um 13:25 schrieb Peter Lemenkov: Sure, I still have a few Python packages sitting in my queue. maybe you can have a look at this one if you have time: https://bugzilla.redhat.com/show_bug.cgi?id=2303756 Felix -- ___ 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: review swap: aactivator (Python)
Hi Peter, Am 05.08.24 um 20:16 schrieb Peter Lemenkov: I've just reviewed it. Could you please pick any of these Python packages and review it? All these packages are quite straightforward. * https://bugzilla.redhat.com/2302539 - python-lazy_load - A minimalistic interface that allows lazy evaluation * https://bugzilla.redhat.com/2302731 - python-baseconv - A basic baseconv implementation in python * https://bugzilla.redhat.com/2302931 - python-multicodec - Multicodec implementation in Python * https://bugzilla.redhat.com/2302932 - python-multihash - Multihash implementation in Python Thanks for your review, I reviewed the three from your list which were not yet taken. I may have another (very simple) python package to review soon, maybe I can ping you when/if I submit that one? Felix -- ___ 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: review swap: aactivator (Python)
Hi Peter, thanks for the review, I'll check your packages later. Am 05.08.24 um 20:16 schrieb Peter Lemenkov: * https://bugzilla.redhat.com/2302731 - python-baseconv - A basic baseconv implementation in python non-existing github repo? https://github.com/semente/baseconv * https://bugzilla.redhat.com/2302931 - python-multicodec - Multicodec implementation in Python Are you sure it is a good idea to package this one? The github repo was archived more than a year ago. Felix -- ___ 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
review swap: aactivator (Python)
Hi, I would like to get this package reviewed: https://bugzilla.redhat.com/show_bug.cgi?id=2275769 Of course I can review something in exchange, preferrably Python-related. Felix -- ___ 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: PyTorch 2.4 (self-contained)
Am 18.07.24 um 13:07 schrieb Zbigniew Jędrzejewski-Szmek: On Wed, Jul 17, 2024 at 10:00:52PM +0100, Aoife Moloney wrote: * Proposal owners: Update base to 2.4 when upstream releases. Any details on when that'll happen? We need to know how this aligns with the Fedora release dates… pytorch 2.4 was planned for release on 2024-07-24 according to the initial planning: https://dev-discuss.pytorch.org/t/pytorch-release-2-4-0-call-for-features/2051 AFAIK RC1 was a bit delayed but the final RC was produced two weeks ago: https://dev-discuss.pytorch.org/t/pytorch-release-2-4-0-final-rc-is-available/2213 Felix -- ___ 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 python-astunparse
Am 17.06.24 um 16:05 schrieb Miro Hrončok: python-astunparse is currently broken on Python 3.13 and I have not investigated why. The latest upstream commit is 5 years old. Comment from the upstream issue tracker: "In theory, no current Python package supporting Python since version 3.9 should be required to use this package, as the functionality is available in the stdlib now: https://docs.python.org/3/library/ast.html#ast.unparse python/cpython@27fc3b6" https://github.com/simonpercivall/astunparse/issues/67#issuecomment-1438351272 So I guess it is really not worth keeping this package alive in Fedora. -- ___ 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: [Node.js] Stepping down as Node.js Maintainer in Fedora
Hi Stephen, also a huge thank you from my side. You did an excellent job to keep nodejs in Fedora! Also this serves as a reminder for me to try getting new packagers in Fedora which hopefully helps to mitigate situations like yours eventually. Felix -- ___ 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: Donate 1 minute of your time to test upgrades from F39 to F40
I just found that my visidata issue is likely being handled via https://bugzilla.redhat.com/show_bug.cgi?id=2264975 https://bugzilla.redhat.com/show_bug.cgi?id=2265038 https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/285 -- ___ 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: Donate 1 minute of your time to test upgrades from F39 to F40
Last metadata expiration check: 0:00:24 ago on Wed Feb 21 10:16:20 2024. Error: Problem: problem with installed package visidata-2.11.1-2.fc39.noarch - visidata-2.11.1-2.fc39.noarch from @System does not belong to a distupgrade repository - nothing provides /usr/bin/-S needed by visidata-3.0.2-1.fc40.noarch from fedora (try to add '--skip-broken' to skip uninstallable packages) Other than that the process works. -- ___ 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: Proven to be sickened
Am 02.12.23 um 09:46 schrieb Michal Schorm: In my experience through the years, I've found very little proven packagers that would work in what *I would see* as the right way. I fully agree with you but I wanted to mention Miro + the Python team. From my experience in the Python packaging space it works pretty well there. I regularly see new PRs by the "Python wranglers" for packages I (co-)maintain even though (technically) they could just push directly. Felix -- ___ 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 - ZX Spectrum edition
Am 24.04.23 um 12:41 schrieb Miroslav Suchý: For example take python-pydyf: https://src.fedoraproject.org/rpms/python-pydyf/commits/rawhide After git-push it is gone now in the updated stats. Sorry. Thank you for your time to drive this effort + the quick fix :-) Felix ___ 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 - ZX Spectrum edition
Am 23.04.23 um 11:59 schrieb Mattia Verga via devel: I have updated some of my packages, but they're still listed there. I've used "Update license tag to SPDX" in the changelog. similar for me. For example take python-pydyf: https://src.fedoraproject.org/rpms/python-pydyf/commits/rawhide Should I use a different license tag? Felix ___ 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: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Am 24.06.22 um 11:27 schrieb Florian Weimer: * Felix Schwarz: Are these Python 2.7 dependencies only used at build time? In that case Fedora could maybe announce that openssl1.1 might not get the full security suport so the burden for openssl1.1 packagers is lower without removing the functionality? I'm pretty sure it's used for Python's own HTTPS implementation, among other things, so it's not really an optional feature (although Python can be built without it, I believe). What I meant is: Is Python 2.7 only used as a build dependency? If so, I think we might be able to state that Python 2.7 + openssl might get reduced security support. At build time we don't have any network access anyway. I guess it is clear that removing openssl1.1 is not really feasible unless we remove Python 2.7. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Am 24.06.22 um 11:23 schrieb Dmitry Belyavskiy: What I'm afraid of is that if we just declare the deprecation, we will stay with this package forever. Well, RHEL 7 maintenance support 2 phase ends in June 2024. I'd expect that we should be able to drop Python 2.7 from Fedora at that point at least (probably even before). And yes, I think removing really important packages like OpenSSL 1 or Python 2.7 is not an easy task for a general-purpose Linux distribution. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Am 24.06.22 um 11:13 schrieb Dmitry Belyavskiy: I'm not sure that if we don't remove the devel package, we will provide strong enough motivation to get rid of the deprecating packages. imho removing the devel packages is basically the same as removing openssl1.1 entirely. To me the idea of "deprecation" is to warn users that something is going away WITHOUT removing functionality immediately. And yes, Python 2.7 might be a pain point for packagers but fact is that important packages still rely on it. Removing openssl just shifts the burden to (many more) packagers who just need Python 2.7 for their packages. Are these Python 2.7 dependencies only used at build time? In that case Fedora could maybe announce that openssl1.1 might not get the full security suport so the burden for openssl1.1 packagers is lower without removing the functionality? Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: intend to orphan python-cairosvg
Hi Neal, I made you an admin and orphaned python-cairosvg so you can claim it as "main admin" if you like. You should probably also take a look at cairocffi which is FTBFS due to failures in the test suite: https://src.fedoraproject.org/rpms/python-cairocffi Technically Eric Smith is the main admin for this package but he did not push any commits in the last months and there is a history of non-responsive maintainer requests so I consider the package as "unmaintained". Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
intend to orphan python-cairosvg
Hi *, I'd like to orphan python-cairosvg. This package was required by older WeasyPrint releases but WeasyPrint v53 (Fedora 35+) stopped using cairo so I don't use this package anymore. The package should be ok however I expect very little upstream maintainance as the code was maintained by the WeasyPrint. The most pressing problem is likely an FTBFS bug for python-cairocffi. If you need cairosvg, this is the time to step forward :-) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
intend to orphan python-cairocffi
Hi *, I'd like to orphan python-cairocffi. This package was required by older WeasyPrint releases but WeasyPrint v53 (Fedora 35+) stopped using cairo so I don't use this package anymore. On top of this cairocffi was developed by the WeasyPrint developers and they stopped maintaining it once WeasyPrint v53 got rid of this dependency. So right now cairocffi's test suite fails in rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=2082558 If you need cairocffi, this is the time to step forward :-) Otherwise the package will likely be removed from Fedora due to the FTBFS policy. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: ROCm-OpenCL package
Hi Jeremy, just wanted to thank you for your contributions to ROCm on Fedora + your upstream work to make the stack more distro-friendly. I'm pretty much swamped right now. Maybe I find some time to chime in but I hope someone else could review this. Debian has a pretty active ROCm packaging team so a potential reviewer could also double-check with Debian to verify the packaging. Really, upstream is in a much better shape than it was 3 years ago with hcc so don't be afraid to take this review. If anyone is concerned due to the lack of hardware I can offer to do some functional testing. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Am 18.05.22 um 11:27 schrieb Peter Boy: We didn’t lost Eclipse, we switched from RPM to another distribution method. Do you mean the Eclipse flatpak? I tried the flatpak but in the end went back to upstream's plain binaries as the Flatpak does not work well when using pydev. So for my use case Fedora lost Eclipse. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: FESCo wants to know what you use i686 packages for
I use wine and lutris (+ 32bit mingw packages). ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to debug failures inside mock when building takes a long time?
Hi Kevin, Am 08.03.22 um 01:33 schrieb Kevin Kofler via devel: There is actually a "mock shell" command that opens a shell inside the mock chroot. You can also run arbitrary shell commands (including scripts that you have previously manually copied in using the "copyin" command) in it. I knew "mock shell" (via "fedpkg mockbuild --shell") but that only gave me a shell at the very beginning of the build process while (ideally) I wanted to set a kind of "breakpoint"+gdb/pdb at an arbitrary point in the build process. (For example most of the build process works just fine so I want all the %prep/%build steps to run automatically while only fiddling around inside %check.) After reading your answer + mock manpages I discovered mock's "--no-cleanup-after" which could help inspecting the state after a failed run. That should be pretty helpful, I'll try that next time I need to figure out why some test suite is failing. :-) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
how to debug failures inside mock when building takes a long time?
Am 07.03.22 um 13:25 schrieb Miro Hrončok: Building pypy is nontrivial. I don't know if you can "just" build it on x86_64 for i686 without using mock, but you should be able to do it in mock: Btw: How do you handle/fix build issues when you can only build inside mock? So for example your mock build fails because some paths or binaries are wrong and it is not obvious from the error what needs to be changed. In these situations I'd like to have some kind of interactive repl shell similar to pdb. Is there something like that for mock? Or some other trick to fix such problems? I found that fixing a build is really time consuming especially if the error only happens in the %check section and build times are high. I thought about using a reverse shell (+ enable network for mock) but I guess there is a better way to do this? Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Yunmei Li
Am 18.02.22 um 07:40 schrieb Yunmei LI: We are looking to contribute Milvus to the fedora community to help more users with their AI applications. I have already filled out a Milvus package review request in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2055596 Welcome to Fedora. I'm always glad if companies help maintaining their software in Fedora (or other distros) :-) One just a little hint for your package: I think you'll have to rework this a bit. For example a Fedora package must not not depend on "epel-release" or "centos-release-scl-rh" (this is also true for EPEL packages). BuildRequiring "wget" seems strange. I guess the build process tries to download something from the internet which is also forbidden in Fedora. You MUST include all sources in your package or use packages already included in Fedora. I see that you list OpenBLAS, cmake, go, boost and tbb in your sources. You should remove all of these from your package and use only the packages already included in Fedora. This might be a bit of work especially for somewhat complex packages but it ensures that Fedora can provide some level of quality. So again, thank you for your contribution. It's a good start and I'm pretty sure that streamlining your software to match Fedora's processes will also help your upstream quality. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self-Introduction: Steve Cossette
Hi Steve, welcome to Fedora :-) Am 14.02.22 um 14:46 schrieb Steve Cossette: But I'm not really aiming to help maintain a specific package (I don't really mind which), is there a place where maintainers look for co-maintainers? I don't think so. The main reason is that data on any list gets outdated immediately. Usually it is best to work on a package you are using yourself or some tech you find fascinating. Once you start looking you'll find outdated Fedora packages almost immediately and you can start submitting some version updates via pull requests. You might notice non-responsive maintainers - otherwise these packages probably would have been updated already. However you send an email to this list (or some other Fedorian you trust) to get help. Once you are familiar with Fedora's processes and you still have free time you can also help tackling bigger issues (e.g. packaging .NET, getting a working AMD ROCm stack, helping with reproducible builds, ...) but I guess these projects are not a good fit for a "newcomer". Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Am 07.02.22 um 18:08 schrieb Neal Gompa: If anything, our MinGW stack is an amazing selling point compared to other distributions, because we provide a usable framework to build applications for Windows. I'd like to second this. I felt relieved once I found out that I could build a tiny in-house C application for Windows (using DBUS via glib + a proprietary 32 bit black box DLL) purely on Linux. meson can do all the cross-compilation, mingw glib provides .pc files and everything works beautifully just like you would compile a Linux executable. Since I got this working a year ago all of our release builds were done on Windows. I completely wiped Visual Studio and there was no bug report related to compilation or the build process since. :-) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Am 04.02.22 um 23:43 schrieb Richard W.M. Jones: We build using mingw precisely to avoid touching Windows at all. Yup - same here. We are using Fedora's mingw packages to create Windows executables which link to a proprietary 32 bit library. This really has been a huge time saver for me and I would really like to keep that ability. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: question about review process excemptions for Python 3
Am 25.01.22 um 21:22 schrieb Miro Hrončok: If I assume correctlty that both python-augeas and python-boto3 are in RHEL 7, yes. this exception applies: """ > The package exists in both Fedora and RHEL, but the packager wants to ship it in EPEL under an alternative name (as required by EPEL policy) to provide a subpackage that exists in Fedora but does not exist (or is not shipped) in RHEL. """ Well, I'm not exactly sure. For python-boto3 I plan on shipping exactly the same code as RHEL 7. python-augeas might be a bit different as RHEL ships 0.5 but I'd like to use 1.1 as that version fixed many bugs. I guess the exemption only applies when using the same source code as present in RHEL, right? I don't think this rule applies to python3-josepy, as python-josepy exists in EPEL7, not RHEL7. I was thinking about this exemption: """ The package is being created so that multiple versions of the same package can coexist in the distribution (or coexist between EPEL and RHEL). The package MUST be properly named according to the naming guidelines and MUST NOT conflict with all other versions of the same package. > """ We need a newer version of josepy which only supports Python 3. Given the age/maturity of RHEL 7 I don't want to remove python2-josepy from EPEL 7 and introduce a newer python3-josepy. Thank you very much, Miro ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
question about review process excemptions for Python 3
Hi, (I sent this to epel-devel but did not get any reply there so maybe fedora-devel is a better place for this question even though this is about EPEL packages?) the packaging guidelines have a few excemptions for the package review process [1]. I'm working on updating certbot to Python 3 in EPEL 7 (rhbz 1797129, [2]). I need some additional Python 3 packages in EPEL 7 to achieve that and my question is which of these packages should get a proper review. A) python3-augeas https://bugzilla.redhat.com/show_bug.cgi?id=2043744 This is mostly the Fedora spec with just on additional bugfix (already upstream). B) python3-josepy intended spec file: https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-josepy/python-josepy.spec I did not want to upgrade the existing EPEL 7 package as the required version is Python 3 only. We can not use some newer macros like %pytest but otherwise the spec is the same as in Fedora. C) python3-boto3 python-boto3 (Python 2) version is in RHEL and won't get a Python3 package. intended spec file: https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-boto3/python3-boto3.spec The spec file is very close to the RHEL spec file just with some customizations removed. Should I try to get reviews for each of the three packages or can I skip some of these according to the Fedora review policy? Felix [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797129 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
"Firefox 96.0 hangs after a while - loses connectivity": workaround for rhbz 2040189
Hi, I guess this might affect quite a few people so I hope I can save you a few minutes to find the workaround: Firefox 96.0 hangs after a while - loses connectivity https://bugzilla.redhat.com/show_bug.cgi?id=2040189 upstream bug: Infinite loop in HTTP3 hangs socket thread https://bugzilla.mozilla.org/show_bug.cgi?id=1749908 Workarounds (from the upstream bug): If anyone need to fix it, please open "about:config" in a new tab. Search : "network.http.http3.enabled" change to false, then restart firefox. Other workaround: Go to preferences -> Firefox Data Collection and uncheck everything. Then restart Firefox Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive maintainer check for Eric Smith (brouhaha)
Am 20.12.21 um 12:49 schrieb Dominik 'Rathann' Mierzejewski: This is a non-responsive maintainer check for Eric Smith (brouhaha). I've been maintaining solaar for over two years now. It was maintained by tibbs before. I asked the original maintainer, Eric Smith to change the default bugzilla assignee to myself several times in the past. The last time was on September 13th this year. There was no response. I've just filed the required Non-responsive maintainer check bug: https://bugzilla.redhat.com/show_bug.cgi?id=2034199 This might be relevant: https://pagure.io/fesco/issue/2283#comment-615251 Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
Am 17.12.21 um 02:39 schrieb Jeremy Newton: Well I think OpenCL would be a good starting point since it's been around for a while and lots of applications use it. Also I'd be interested in using pytorch (installed via pip) on my AMD system. Years ago when Tom Stellard started to package rocm things for Fedora I tried to review some of the packages but found it really hard to tweak the sources/build process to produce something acceptable to Fedora. I'd love to see this being improved so I could use my GPU for smaller compute tasks. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 update failure from libjxl
Am 03.12.21 um 16:19 schrieb Steven A. Falco: What is the proper procedure to escalate this? Should I create a bug? Either create a bug or write to this mailing list (as you did). I use bodhi only to give simple feedback or post easy workarounds. The interface is not suitable for discussions. Regarding your last bodhi comment [1]: > @fschwarz, so I get it right next time, are the errors below sufficient to > justify the negative karma? Not sure which package causes the problem. I could update libjxl to 0.6.1-6.fc35 (which worked after removing the gimp heif plugin). In general negative karma is not useful after the package went to stable. Just file a bug in that case and don't be afraid of filing issues which may get closed as "CANTFIX" or "NOTABUG". As long as you are respectful and employ common courtesy everything should be ok :-) Felix [1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee6b5b458e#comment-2300180 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 update failure from libjxl
Hi Steven, Am 03.12.21 um 16:19 schrieb Steven A. Falco: There was an update [1] to libjxl that appears to have broken some dependencies (gimp-jxl-plugin, jxl-pixbuf-loader, libaom, etc.). I'm not sure if the negative karma is helpful, since this update has already been pushed to stable a few days ago. libheif is not part of Fedora (likely installed from rpmfusion-free) and the update was not coordinated between Fedora + RPM Fusion (as expected - RPMFusion is an independent 3rd party repo. I think there is some progress to rebuild the package but you should watch RPMFusion bug 6158: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6158 HTH Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: How to reach the certbot SIG?
Am 25.11.21 um 09:21 schrieb spike: I've been trying to contact Fedora's certbot SIG for a while now. Back then I wanted to help fix some issues with python-dns-lexicon (which are resolved upstream now and an update has trickled down to Fedora 35 with the latest release) but currently I'm trying to find somebody who's willing to review https://bugzilla.redhat.com/show_bug.cgi?id=2019398 You can always write to certbot-maintain...@fedoraproject.org but asking here worked as well :-) I'll check this later this week (please ping me if I don't - lots of other stuff going on in my area unfortunately). There is one (minor) issue with certbot plugins though: As far as I could see certbot upstream will rethink its approach to plugins and packaging extra plugins for Fedora/EPEL often introduces additional dependencies. The latter caused quite a bit of work when I tried to uplift certbot to Python 3 for EPEL 7 (I've completed the builds locally but I still need to submit a few new review requests + coordinate updates for many more packages). So I'm not super keen on adding new certbot plugins to Fedora but if we have some additional hands that of course changes the equation :-) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Keeping track of inconsistent backports
Hi, I have a similar problem (but on a much smaller scale): The certbot stack comprises ~ a dozen packages which should be updated in lockstep. We push the same version to all supported Fedora releases + EPEL (mostly). To do that somewhat efficiently I built/extended some scripts: https://github.com/FelixSchwarz/fedpkgscripts Basically these handle issues like: - merge a branch to N other branches - push git changes in N branches - build branch X for N packages (either in mock, in COPR or with koji) - check for unpushed/uncommitted changes in a repo - pull git changes for N packages - set the new version in a spec file based on bugzilla queries, download the new sources, verify with gpg and run "fedpkg new-sources" if verification is successful + some other stuff I probably just did not remember currently really a lot of "ad hoc" code but I'd be happy to contribute to a common set of tools :-) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 💔 Java: The Death of Two SIGs
Am 27.09.21 um 15:09 schrieb Mario Torre: However the majority of people just usually download Eclipse (or IntelliJ for what matters) from the upstream website anyway, further suggesting that maintaining Eclipse is not really a rewarding nor useful task. Just my 2 ¢: Since I switched from upstream Eclipse tarballs to Fedora's Eclipse packages my developer experience improved so much. Previously I had to make Eclipse cleaning up its temporary files quite often. With Fedora's Eclipse mostly just worked fine. So a big thanks to the previous Java/Eclipse maintainers from me. I really appreciate the effort. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: karma question
Am 24.08.21 um 22:47 schrieb Steven A. Falco: Should I edit the criteria in f33 so I can mark it stable before the 7 days elapse, or should I let it wait? It seems weird that one release would have to wait longer than the other releases when the fix is identical for all of them. Also I'd even prefer F33 getting the update a bit later: I assume F33 users are valuing stability over "latest versions and fixes" (otherwise they would have upgraded to F34 already). On the other hand the bug is probably not too bad (otherwise the bug would have been fixed earlier or users would have stopped using the package altogether). So as a F33 user I'd prefer only getting "rock solid" fixes over newer stuff which might introduce regressions. just a personal opinion though :-) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
Hi Stephen, thank you for your interest in contributing to Fedora. I can totally understand that the current policies may seem overwhelming so that becoming a packager might be seen as some kind of "elite" status. I think I would feel the same way if I didn't become a packager ~10 years ago. However I would like to emphasize Ben's point: I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing. Maybe you do 1-2 package updates or fixes (pull request via src.fedoraproject.org) and check the Fedora wiki pages for a list of sponsors. Try contacting some of them directly after you verified they are still active (mailing list/src.fedoraproject.org). Also it helps usually if these sponsors are interested in the languages/tech stack which you tried to improve. That being said: Java in Fedora is one of the hardest areas to tackle. Several "high profile" packagers had to give up on that task (despite heroic efforts) because it is just too much for one person (or a small team). Part of the problem is that the Java upstream "culture" does not matches the processes of a traditional Linux distribution like Fedora. Lots of bundled dependencies, "secret" build processes and on top a huge number of small packages. I can understand that "keeping Eclipse in Fedora" is a worthy goal for sure but really a lot of work. Other areas like Python packaging are much easier as applications tend to be smaller and bundling is less common in the Python world. (Also great efforts by our Python team!) One of the things I'd be interested in is "reprocible builds" which I think might be easier to contribute. While there is a lot of infrastructure to build (= a lot of work) you can also just fix one package at a time (probably with a few upstream commits). Even if you stop contributing to Fedora after some months or years you advanced the state of Fedora/Linux anyway. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze
Am 05.08.21 um 14:00 schrieb Miro Hrončok: eclipse akurtakov, dbhole, eclipse-sig, 11 weeks jerboaa, jjohnstn, lef, mbooth, oliver, rgrunber What is the idea here? Is that a fallout of the Javapocalypse/the state of Java in Fedora? Will users be able to get Eclipse from Fedora for F35+? (I'm using Eclipse + pydev a lot so I'm interested in having these packages available. However I can't take any more packages.) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package requests: mingw-glfw, gtkmm-4
Am 29.07.21 um 12:42 schrieb Sandro Mani: mingw packages are dedicated like any other packages, with a respecitve maintainer. Though there was some initiative in March 2021 of building (some?) mingw packages directly from the regular linux specs. Not sure if something happened there: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FR5OEMAIROHKECQB2NGLMMXQGG7IQMHM/ Felix PS: I'd like thank all mingw packagers in Fedora. I'm actively using it to cross-compile an in-house Windows application with Linux. Not having to use Windows for development is really a time saver :-) ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
Am 09.07.21 um 17:45 schrieb Ben Cotton: == Detailed Description == The use of SHA-1 is no longer permitted for Digital Signatures or authentication in RHEL-9. Due to this reason, there is a need to remove SHA-1 extension from sqlite in RHEL-9 and therefore also Fedora. I don't think that this is a valid logical conclusion. Fedora is (should be?) upstream to RHEL 9 so you can disable SHA1 in RHEL 9 but keep it enabled in Fedora. There is certainly no "need" for this change as demonstrated by the various packaging changes done in RHEL. (FWIW I don't particularly care about SHA1 functionality in sqlite.) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Python libraries problem with F34
Hi Fred,
your code works for me without printing any warnings.
Am 05.07.21 um 10:01 schrieb Frederic Muller:> I install all my libraries using
pip.
The important thing is that you never use pip to install anything into Fedora's
site-packages /usr/lib64/python3.9/site-packages/ . That can (and will) cause a
lot of trouble. Use "dnf" only to install stuff into your system site-packages
directory. Use virtualenvs (or similar mechanisms) to install your own libraries
with pip.
Actually I see a lot of bug reports about certbot in Fedora/EPEL where users
installed custom Python libraries which break Fedora's certbot. For Python
packages included in Fedora we can check that everything works fine (though
sometimes a bug might go unnoticed).
I suggest you revert all manual changes first, reinstall all Python packages and
then create a custom virtualenv if you need additional libraries:
$ rpm -qf /usr/lib64/python3.9/site-packages/* | grep 'is not owned by any
package'
-> you will see a list of files/directories which are not part of Fedora's
packages. You should delete those.
Once you did that, check all remaining Python packages which might have been
replaced by pip:
$ rpm -qf /usr/lib64/python3.9/site-packages/* | xargs rpm --verify
You'll see a list of changed files, e.g.:
S.5T./usr/share/glib-2.0/schemas/gschemas.compiled
If these files are in /usr/lib64/python3.9/site-packages/ you can check which
python package these belong to ("rpm -qf /path/to/file") and reinstall those
packages using "dnf reinstall ...".
Once you have done that you Fedora system should be fine again and you can start
using virtualenvs.
Felix
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Python libraries problem with F34
- Can you post a small code snippet which reproduces the problem? - I can use requests on F34 without any warnings. Any chance you manually installed other libraries/versions in Fedora's site-packages? (/usr/lib64/python3.9) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Macro to smoke-test-import a Python module in %check
Am 28.06.21 um 21:44 schrieb Miro Hrončok: The semantics is quite simple: %check %py3_check_import mymodule mymodule.submodule Looks great! Thank you. Please let us know when we should start adding that to our Python packages. :-) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [HEADS UP] Planned Sphinx update to 4.x - many packages fail to build
Am 22.06.21 um 18:34 schrieb Karolina Surma: borgbackup fschwarz Thank you for your work on Sphinx. borgbackup should be fixed in rawhide. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Introduction: Trevor McKay
Am 16.06.21 um 05:12 schrieb Trevor McKay: My name is Trevor and I was hoping to contribute to the Fedora project in the form of packaging. Welcome! introduce myself here. I have a few years of Linux experience as well as Rust, Python and C/C++ development. I am, however, completely new to packaging and contributing to open-source, so any advice is very much welcome. I think Fedora has pretty nice Python packaging and I think rust skills are also a welcome addition as there is a growing number of rust software in the open source ecosystem. You can check out the SIG pages for Rust+Python. There are separate mailing lists for these SIGs (though fedora-devel works as well): https://fedoraproject.org/wiki/SIGs/Python https://fedoraproject.org/wiki/SIGs/Rust I am interested in packing `bottom`, a package for system monitoring that I find fairly useful. There is a Fedora package by "atim" (real name AFAIK "Artem Polishchuk", ego.corda...@gmail.com) in COPR: https://copr.fedorainfracloud.org/coprs/atim/bottom/ Probably there is a reason why this is not yet in Fedora (missing dependencies? licensing?) so you could ask him and maybe help getting this into Fedora. Sometimes you need to spend a lot of effort to get upstream's build system in line with Fedora's policies (no network access during build, so all dependencies must be packaged inside Fedora) but together we can create a really nice platform which can be used for stuff nobody envisioned at the beginning. (For example I'm using Fedora's mingw packaging to cross-compile a commercial application for Windows and I spent several days before discovering Fedora's packages. Also more time with Linux instead of fighting Visual Studio => sanity++) Anyway: If you have any questions, just ask. (And if you are not comfortable asking publicly, just contact me privately. Not much time here but I'm happy to help new Fedora contributors.) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [cdparanoia] License field fix awaiting to be merged
Am 02.06.21 um 17:42 schrieb Neal Gompa: For what it's worth, I prefer the effective license approach too. I'm just working with what people tell me. :( If we just mention the source license(s) in the License tag this means it will become harder to check if some software can depend on a specific RPM. For example I maintain a package which has a test suite under the AGPL (which is not shipped) but the actual software uses a 3-clause BSD. I guess some users might prefer not to use the packaged library if they see the AGPL even though that only affects tests. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Xiaofeng, FAS: wasphin
Am 02.06.21 um 05:20 schrieb Xiaofeng Wang: This sounds fine, thanks. You are welcome. If there are any problems just ask here. Thank you for contributing to a better Fedora. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Xiaofeng, FAS: wasphin
Am 01.06.21 um 14:15 schrieb xiaofeng: Actually, I just have trouble following the guide. Would you mind explaining a bit what part you are struggeling with? Having a first PR is great! Actually if the maintainer of qt-creator is responsive you could work quite a while without the need of getting sponsored. (If possible, just contributing a few PRs should get you on the way of becoming a Fedora contributor as you build a track record.) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Stefano Prina
Hi Stefano, a few months ago certbot switched to Python 3 only. certbot on EPEL 7 still uses Python 2 because EPEL 7 does not have all required Python 3 packages. So we need to bring the missing packages to EPEL 7. The main bug for this is: https://bugzilla.redhat.com/show_bug.cgi?id=1797129 (Click on "TreeView+ depends on" / "Expand all") As you can see I already added quite a few packages but some are still missing (the list is probably incomplete but we need less than 10 additional packages). - If python-X is in RHEL and does not offer a Python 3 version, we need to create a new python3-X package (new package review). - Package is in EPEL but Python 2 only - is version recent enough for certbot? -> submit pull request for package to build also a Python 3 version. otherwise: create new review request for python3-X in EPEL 7. - python3-X is already in RHEL or EPEL but too old. -> tricky case, we need to check if certbot also works with the older version. - once we know that it works we should file a bug upstream to relax the requirements From the top of my head: - python3-augeas (bug 1823761), there is a non-responsive maintainer process at the moment for the Fedora maintainer. Once there is an active maintainer again I hope to (s)he will update the Fedora package so we can add that latest version to EPEL. - python-certbot-dns-route53: - requires python3-boto3, python3-botocore - need to package new versions - python-dns-lexicon - requires boto3, PyYAML I didn't have time to work on that for many months now so I'm not sure what is the best place to start. However I created a COPR repo which contains some Python 3 packages: https://copr.fedorainfracloud.org/coprs/fschwarz/certbot-python3-epel7/ So probably you could start by getting python-dns-lexicon 3.3.28 packaged for EPEL 7 + Python 3. I hope the long email does not deter you - in the end you do one step after the next. The email is only so long because I don't have the exact state in my head anymore so it takes longer to explain. Please let me know if you are still interested so I can check for local changes so you don't have to duplicate work. Felix PS: I just noticed that I had to disable some tests in python-dns-lexicon (rawhide). If you know Python maybe you also want to check how to run more of these tests (without new dependencies). ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Stefano Prina
Hi Stefano, Am 10.05.21 um 14:25 schrieb Stefano Prina: I'm good with python programming and as sys admin. Now I'm loking for a project or a task to work on, let me know if someone need help :) Welcome to Fedora. Fedora+Python is a pretty good match so you'll find plenty of packages to maintain/help out. You might want to check out Fedora's Python mailing list: https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org If you are interested in Fedora EPEL 7 I could use some help getting all the required Python 3 packages for certbot (Let's Encrypt) in EPEL 7 so we can ship newer versions of certbot. Otherwise just keep using Fedora - you'll find bugs/outdated version soon enough you'll maintain a bazillion packages... ;-) Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
Am 29.04.21 um 21:27 schrieb Joan Moreau via devel: Isn´t there a muh more systemic (and simpler) process to push a RPM in the distribution ? Fedora tries to ship working software. This means there has to be at least one person who really cares about each Fedora package. All these processes to try ensure that someone is sufficiently motivated and knowledgeable so users can trust on Fedora packages. That being said I can see that some of these docs can feel "overwhelming" and from my observation not all packages follow the guidelines all the time. So I'd like to encourage you to join even if you feel that you are lacking some skills. However you should be willing to spend some time for at least 1-2 years when trying to get a new package into Fedora. If you just want to package something for Fedora users without long-term commitments you can also try COPR: https://copr.fedorainfracloud.org/ This is similar to Ubuntu's PPAs or the OpenSuse build service. Your contribution will have a much lower impact (as the software is not available by default for all Fedora users) but you can push your package without any review and it is easily available in a somewhat well-known location. Also it can provide a starting point for others to submit the package for inclusion in Fedora. Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: boolean dependencies and "rpm -e" (python3-urllib3 / python3-requests)
Am 15.03.21 um 11:09 schrieb Miro Hrončok: # rpm -e python3-py error: Failed dependencies: python3.9dist(py) >= 1.4.17 is needed by (installed) python3-tox-3.19.0-1.fc33.noarch Hence, I believe this is a bug in rpm --erase. Thank you for confirming this. Actually I noticed that there is already an issue in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1902420 Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
boolean dependencies and "rpm -e" (python3-urllib3 / python3-requests)
Hi, I'm trying to make sense of a bug report a user submitted via bugzilla and I think the root cause might be boolean dependencies. So basically python3-urllib3 was not present on the user's system even though python3-requests was installed (and of course triggered an exception when used). Now I'm trying to understand how boolean dependencies work (in F33). It seems "rpm" let's me uninstall python3-urllib3 even though python3-requests is installed and requires it: # rpm -q --requires python3-requests ((python3.9dist(urllib3) < 1.25 or python3.9dist(urllib3) > 1.25) with (python3.9dist(urllib3) < 1.25.1 or python3.9dist(urllib3) > 1.25.1) with python3.9dist(urllib3) < 1.26 with python3.9dist(urllib3) >= 1.21.1) (python3.9dist(chardet) < 4 with python3.9dist(chardet) >= 3.0.2) (python3.9dist(idna) < 3 with python3.9dist(idna) >= 2.5) python(abi) = 3.9 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rpmlib(RichDependencies) <= 4.12.0-1 # rpm -q --whatrequires 'python3.9dist(urllib3)' python3-requests-2.24.0-3.fc33.noarch # rpm -e python3-urllib3 (no output, package is removed) Is that the expected outcome? Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
hotplug headphone detection in pipewire? (was: Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change))
I switched a desktop F33 machine from pulseaudio to pipewire and it seems to work fine at a quick glance: $ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing $ systemctl --user enable pipewire pipewire-pulse Now I have the problem when I re-plug my headphones (old-fashioned headphone jack) that I don't see the headphones as output device via "pactl list sinks" (neither via pavucontrol, gnome's audio settings, ...). However the low-level alsa tools can see the headphone jacks (e.g. "alsamixer") and I can use "aplay" to get sound output one the headphone jacks. With pulseaudio I had the same situation but $ pacmd unload-module module-udev-detect && pacmd load-module module-udev-detect fixed the situation for me (though I saw duplicated sinks via pulseaudio for the rest of the session). -> Is there a way to force pipewire to rescan the available sinks? (Ideally there would be auto-detection of course) I guess this is more a support question but I assumed that it might be on topic here as the main goal is to get some testing for pipewire in Fedora :-) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What should I do, without being in the packager group, to get updates for a package?
Hi Cristian, thank you for contributing to Fedora :-) Am 07.01.21 um 13:05 schrieb Cristian Morales Vega: My failed attempt has left me with some questions. I think I don't understand what you tried so far and what failed exactly (maybe I misunderstood your email). - Can this be done? I may be able to push to my own fork and create Pull Requests. But to update a package I am going to need to upload the updated tarball to the Lookaside Cache, and I guess I need to be in the packager group to be able to do that (I get a 403 error). Yes. For a package update don't bother with the lookaside cache. Just fork the package, create a pull request and the maintainer can do "fedpkg new-sources ..." (assuming "spectool -g *.spec" can download the necessary tarballs). - How did this happen? I am not trying to blame the maintainer. Stuff happens, people have a life outside Fedora. But he probably knows (https://bugzilla.redhat.com/show_bug.cgi?id=1899163), there is even a person comment in there asking about the update, and for whatever reason he has not done it. Two weeks ago I sent him an email but have got no reply yet. This was the holiday season and of course there is always real life so people may be distracted/non-responsive. However I have to say that non-responsive maintainers are a bit of dark spot in Fedora. Especially when touching more than a few packages I took me many weeks until all my patches were applied (and there is at least one pull request for the high-profile mesa package which just open without any comments for more than a year or so). But I don't think this should be a problem in your case. How does Fedora handle this? For all I know he may have transcended into a pure-energy being and we will never get more updates from him. If that's the case, when does Fedora notice and assigns a new maintainer to the package? There is any defined process? In terms of policy there is the "Non-responsive maintainer policy": https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ However in your case I think you should first submit a pull request and mention that PR in the bugzilla issue. If you don't get any response within 1-2 weeks maybe you could send another email to this list. cmake has some well-known maintainers so I'm sure the version update will be handled somehow. Also cmake is a pretty important package so there might be the need to coordinate updating with the rest of Fedora - but the cmake package maintainers will let you know if that is the case. - What's wrong with the the-new-hotness? https://bugzilla.redhat.com/show_bug.cgi?id=1899163 has been complaining that "An HTTP error occurred downloading the package's new Source URLs: Getting https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5482.patch to ./5482.patch" since 18 November. I can open https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5482.patch in my browser without any issues, "An HTTP error" is not too helpful here. Yes, not sure what is wrong exactly but I'm seeing this quite often. Not important though... Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Frédéric Pierret (fepitre)
Am 05.01.21 um 16:01 schrieb Neal Gompa: Welcome to Fedora, Frédéric! I'm looking forward to see efforts around reproducible builds in Fedora. :) +1 from me. I think this is really on example where free software can really show its strengths and if there is some easy tooling in Fedora to ensure packages are reproducible I'd start migrating my (mostly Python) packages to ensure they can be built reproducibly (or at least nag upstream about it). Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GitLab AMA Topic Follow Up: Branches
Am 13.12.20 um 17:18 schrieb Aoife Moloney: Hiding branches - Question: Is it possible to hide these retired branches from the UI? Say, hide branch names with f30 or lower? - Answer: This is not possible currently I think it would be more useful (also in the general sense) to make "inactive" branches less visible. Many projects keep ancient branches but these are not really relevant for most users so gitlab might want to make these less visible in the UI (I don't think they do this currently). The same concept could be applied to EOL Fedora branches. I really dislike the idea of "hiding" old branches completely. I hope you have been finding this concentrated topic email useful and informative. Yes, thank you very much. (Though it seems there is a lot of work to be done until gitlab could replace pagure/dist-git for Fedora.) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
Am 04.12.20 um 21:35 schrieb Stephen John Smoogen: Anecdata which is as 'useful' as any other. just some additional experience from my side: - Fedora provides a recent PHP (unlike RHEL 7) but also ships the full PHP stack required to run popular PHP applications like WordPress/NextCloud/... AFAIK due to modularity and build-only RPMs it is still quite hard (on RHEL 8) to get PHP-related rpms required to deploy these PHP applications. With Fedora it works like a breeze. - Fedora works well, no breaking updates in our server use - also a lot of recent tech available: wireguard, systemd daemons Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change proposal: Xwayland as a standalone package (System-Wide Change)
(Disclaimer: Just an XWayland user, so I might be totally wrong) Am 01.12.20 um 10:58 schrieb Fabio Valentini: I assume there are also at least *some* improvements (other than XWayland improvements) in the xserver repo that are not released yet? I think one example could be: xwayland: Add EGL-backed GLX provider https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/195 which fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98272 Basically this fixes some well-known (sort of) Steam games from "Paradox Interactive" to launch when using a wayland desktop session. Right now users have to resort to X.org to play these games on Linux. These fixes were merged in May 2019 with some follow-up fix in December 2019 but only in master so it is quite difficult for users to benefit from these. Could we at least get one final, last, xserver release, maybe even with XWayland split out as a separate component upstream? As far as I know nobody is really keen on spending time on xserver releases: Adam Jackson (@ajax): "on abandoning the X server" https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html Also Daniel Vetter (Intel) is on record that the xserver might be considered "abandonware". https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/533#note_670522 If I am reading Adam's comments correctly we would need some kind of release manager who herds all the cats and publishes a release. It's kind of sad that there is still Xorg development even though users do not benefit as there are no release being made. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: new Radeon RX 6800/6900/Big Navi on Fedora
Hi Daniel, Am 18.11.20 um 18:41 schrieb Daniel Pocock: Firmware binary code that isn't yet present in linux-firmware.git - is there any way to extract that binary from another platform? you probably noticed this yourself, but just in case: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DWHTL7DIYPZ5GPAW2RQC4EKOXH3B4BL2/ Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve
Am 16.11.20 um 14:03 schrieb Vitaly Zaitsev via devel: Most of casual packagers simply ignore all pull requests and don't even check their mail. It is much more easier to fix the package manually than waiting 2-3 weeks for a response. I think this is the root cause and a real problem (I complained about this myself several few times on this list). However I argue it is wrong starting to shortcut existing rules as this causes additional fallout for responsive maintainers who might feel disenfranchised. Instead we should start thinking about ways to actually fix the root cause problem (and also how to integrate Fedora packaging much better with actual users, hopefully "converting" some users into packagers). Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve
Am 16.11.20 um 13:16 schrieb Vitaly Zaitsev via devel: The main upstream for Fedora packages is the Fedora Package Sources. If the package need to be fixed, it must be fixed. I agree with you here. The only point (though important imho) I want to make is that provenpackagers should not "circumvent" the package maintainer by default - even though I can imagine it is way faster just to push your change. The main idea is that "everyone plays by the same rules" except for some special situations: - pre-announced mass changes - urgent fixes and maintainer does not react immediately Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve
Am 16.11.20 um 10:28 schrieb Miro Hrončok: If it is not urgent, provnpackagers should not go and make packaging changes without talking to the maintainer first. +1 I think the main idea is that we try not to create artificial "hierarchies". Especially for a volunteer maintainer who maintains a few packages there might be a pretty strong emotional attachment to his packages which try to keep up to the highest packaging standards. If some provenpackager just goes into "his" package and seems to play by a different set of rules this can be pretty demotivating. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Non-responsive maintainer check avsej for grpc
Am 09.11.20 um 22:35 schrieb Dan Čermák: I have filed the respective ticket in Bugzilla [1] as I have seen no development in the tracking bug to update grpc[2]. The outdated version of grpc is currently blocking me from updating Bear to anything beyond 3.0.0. Not directly relatived but: I think Gwyn is working on updating grpc but as far as I understand there is an (upstream) bug which prevents grpc from compiling. The issue has been raised upstream but with little progress as far as I can tell. Probably the best course of action would be to bundle the problematic git submodules yourself. Felix ___ 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
intending to retire thunderbird-enigmail in F34+
Hey, Thunderbird 78 changed its tech stack and integrated OpenPGP support so the enigmail plugin does not work anymore. Enigmail 2.2.x does not contain any OpenPGP functionality besides a migration tool which migrates keys to Thunderbird's internal keyring. Since Thunderbird 78 was pushed to F31+ I also updated thunderbird-enigmail. However I'd like to retire the package in rawhide (F34+) as the new version does not provide any features once users migrated their keys to Thunderbird. (I'll ship enigmail in F33 as a zero-day update as I think we can not remove a package anymore from F33 at this point.) Objections? Felix PS: Worst case users can always install the add-on manually via Thunderbird's extension manager. ___ 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
Packager Dashboard out of sync? - https://packager.fedorainfracloud.org
Hi,
it seems that the packager dashboard does not synchronize my data anymore:
https://packager.fedorainfracloud.org/fschwarz
For example it still shows bug #1874669 ("Please build python-cssselect2 for
EPEL8") as NEW even though that bug is closed since 2020-09-19.
Also a lot of new bugs are not displayed at all.
Where can I report these issues? Is that a known bug?
Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package downgrades from fedora 32 -> fedora 33 (updated + annotated list inside)
Am 03.10.20 um 00:53 schrieb Fabio Valentini: > - python3-certbot-dns-google is newer in 32 than in 33: > 0:1.7.0-1.fc32 > 0:1.5.0-1.fc33 > > This is caused by python-certbot-dns-google being FTBFS for fedora 33+. > There was no FTBFS bug reported for it, but both releng builds have failed. > The subsequent update to 1.7.0 was also not pushed to f33 and rawhide ... This is due to a missing dependency in F33+. I think this got fixed only very recently but I'll check again. It's on my TODO list (though that became quite long over the last month). Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Firefox 78.0.2 for F32
Just wanted to mention that the F31 update needs one more karma so it can be pushed to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-dd4e4e78ef Maybe a F31 user can take a look? Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packagers with no corresponding valid bugzilla accounts
Am 25.06.20 um 14:55 schrieb Pierre-Yves Chibon: > Here is an updated list: > > @certbot-sig > > Please do try to fix this soon! I'd love to but unfortunately I'm only a user for the certbot sig and even though I think I'm probably the de-facto maintainer of the certbot stack now I was not really successful in getting responses from other sig members (trying for ~6 months now). Also I only learned about the sig mailing lists via this thread here (but I'm not subscribed there and I don't know how to fix that). Is there a "non-functional sig" process? Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please BuildRequire python3-setuptools explicitly
Am 23.06.20 um 18:26 schrieb Tomas Hrnciar: > fschwarz pdfarranger python-ndg_httpsclient python-pdfrw python-pyrfc3339 > python-tinycss2 I fixed python-ndg_httpsclient, python-pdfrw, python-pyrfc3339 and python-tinycss2 dreua fixed pdfarranger. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-06-15)
Am 15.06.20 um 19:00 schrieb Petr Šabata: * What is the scope of Modularity? (contyk, 15:35:03) * AGREED: Modular-only packages are not allowed and modular versions are only be allowed as alternatives to non-modular packages. (+9, 0, -0) (contyk, 15:58:47) (...) Thank you, FESCo :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packagers with no corresponding valid bugzilla accounts
Am 13.06.20 um 22:10 schrieb Pierre-Yves Chibon: > bpereto Benjamin was a previous maintainer of borgbackup. After the Python 3.9 rebuild I noticed that a new ticket was still assigned to him [1]. If I understood your email correctly this is because there is no corresponding bugzilla account? Any idea how to fix this? There was a non-responsive maintainer process a while ago and I did not hear from him ever since. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1838161#c1 [2] https://pagure.io/fesco/issue/2242 > @certbot-sig What can we do here? I'm a member of the sig but I don't know if it has an email address. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Increasing the packaging team: regular workshops/vFADs/classroom sessions on packaging
Am 21.05.20 um 10:52 schrieb Ankur Sinha: > The packaging team is generally quite stretched, and we frankly need > more people helping us out. Agreed. There might be another simple thing how we could get new contributors: I noticed that sometimes users asked in bugzilla/on a mailing list if they could help in maintaining some (more or less orphaned/unmaintained) package. IIRC they never got an answer (as nobody reads bugzilla comments for unmaintained packages). Also there was a similar post on epel-devel. I think we have a pretty big hole in the process here - it is too easy for interested people to "fall through the cracks". Also requiring them to review some unrelated packages to demonstrate their knowlegde is a pretty big hurdle. Last year there was a user who submitted a review request (which was approved) but did not find a sponsor because reviewing more packages (without some guidance to ensure the efforts won't go unnoticed) seemed to be too time consuming. Instead he chose to spend more time in upstream development. I noticed that he seemed to be aware of the most important things about packaging in Fedora and was able to connect him with a sponsor (and vouched for him by ensuring that sponsor I would be co-maintaining the new package so I could fix any fallout). Long story short: He got sponsored soon after and maintains the application in Fedora since then pretty successfully. I tried to act as primary point of contact for any questions and help solving some minor issues. => Maybe we could also scale-out if regular packagers could "mentor" (not sponsor) new packagers. To do so it would be helpful to me which sponsors have free cycles to take new packagers. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Datacenter move days 3 and 4
Am 12.06.20 um 06:09 schrieb Kevin Fenzi: > Overall things went pretty good from my view, and I would really like to > thank the awesome fedora community for being patient with us. Well - thank you (and the other awesome admins). I hit a few issues but as you communicated the move pretty well (imho) I refrained from posting but just waited a few hours or days (and everything went fine then). Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
Am 29.05.20 um 09:19 schrieb Miro Hrončok: > The side tag is being merged right now. Thank you for all the work (also in advance with all the alpha/beta versions) :-) Seems like quite a few Python packages were rebuilt in rawhide during your mass rebuild. Did that happen in the past as well? (I don't remember it that way but also I did not monitor previous python rebuilds closely). Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
builds for borgbackup done (finally): - borgbackup-1.1.11-3.el7 - borgbackup-1.1.11-5.fc31 Please add these once you submit the final update. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
Am 24.05.20 um 18:47 schrieb Antonio Trande: > This mail for asking to the maintainers of `R-argon2` `borgbackup` > `gtkhash` how we want to rebuild the packages against latest `libb2` > update as required by rhbz#1836534 and rhbz#1836535. > > By buildroot override? > By a side-tag method? > (https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/) My buildroot overrides are still active so feel free to use these: https://bodhi.fedoraproject.org/overrides/libb2-0.98.1-2.fc31 https://bodhi.fedoraproject.org/overrides/libb2-0.98.1-2.el7 Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
Am 24.05.20 um 11:49 schrieb Antonio Trande: > Can i include all dependent packages without related permissions? (i'm > not the maintainer of `R-argon2` `borgbackup` `gtkhash`) > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812 Yes. Submitting an update does not require git-level permissions to commit changes. Here is what I'd like to see: 1. unpush the update 2. create tracking bugs for maintainers of dependent projects a) wait maybe a week or so for maintainers to submit a new build) b) if you don't get any response from a maintainer, please ask here for some provenpackager to trigger a build 3. create an update for libb2 + all dependent packages borgbackup: - EPEL 7 build is ready - In F31 I experienced strange test failures which only happen when doing "real" builds (all scratch builds work fine). I believe this is due to a flaky test suite but I will need some more days to investigate this. Maybe I will just disable the tests but I'm not yet sure. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
Am 22.05.20 um 23:16 schrieb Felix Schwarz: > We should push broken updates to EPEL 7/F31. obviously this should read "We should NOT push broken updates" ;-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
Hey, seems like you already built libb2? I hoped we could coordinate the update a bit more so there won't be any breakage. I just added buildroot override (still waiting for it to become active) and I can rebuild borgbackup. I hoped you could do the koji build and then dependent packages would be rebuilt either by you with provenpackager powers or by the packager maintainers. Afterwards you would create a single koji update. Do you know if the gtkhash maintainers are ready for a rebuild? There are no related commits: https://src.fedoraproject.org/rpms/gtkhash -> Please ensure the current update does not go to stable so all dependent packages can be rebuilt + added to the update. (Please disable auto-stable by karma and time) We should push broken updates to EPEL 7/F31. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
Am 22.05.20 um 12:47 schrieb Miro Hrončok: >> I was not aware that python-genshi is still part of the initial bootstrap >> sequence. The package does not work with Python 3.9 (upstream problem, the >> usual AST changes). I hope that won't make your life too difficult. > > genshi is used in some html5lib tests, hence it is in this list, but don't > worry too much, the genshi tests are optional and can be skipped if needed. Good to know :-) >> I started to debug the failures but it seems it is not a one line fix. Then >> I got distracted by trying to fix up borgbackup for Python 3.9. > > Sorry about the distraction. No problem. I think it's hardly possible to run these mass rebuilds without an occasional mistake. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
Am 22.05.20 um 03:06 schrieb Miro Hrončok: fschwarz babel python-genshi I was not aware that python-genshi is still part of the initial bootstrap sequence. The package does not work with Python 3.9 (upstream problem, the usual AST changes). I hope that won't make your life too difficult. I started to debug the failures but it seems it is not a one line fix. Then I got distracted by trying to fix up borgbackup for Python 3.9. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Aggressive updating (Python 3.9): Are we trying to hard?
Am 19.05.20 um 15:55 schrieb Richard Shaw: > Thanks! I do overall enjoy contributing to Fedora but like a lot of us 10 year > plus packagers, I'm accumulated many packages (some a lot more trouble than > others!) and while I have no intention of taking a hiatus or anything I'm > trying to find a packager life balance :) I can totally feel your pain. Just a few days ago Miro promised me some cookies and added me to the python-sig. Now pagure says I can commit to 435 packages :-/ Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Aggressive updating (Python 3.9): Are we trying to hard?
Am 19.05.20 um 14:56 schrieb Igor Raits: > I think we should get people who maintain Qt on board when updating > Python so that they make sure to backport necessary patches from > upstream when we upgrade Python. Yeah, I think Richard got pretty unlucky when it comes to PySide2 (though congrats for his efforts - not a small feat). Historically PySide is lagging quite a bit behind in terms of Python 3 support and iirc most (all?) development is done by the QT Company so it works pretty much like other closed-source company projects (commercial priorities, wait for stuff to stabilize, only adopt new versions when necessary). On top PySide2 (and QT) are really a massive amount of complicated code so just adding a quick Python 3.9 fix is not going to work. So PySide2 is likely a package which gets the heat from updating QT AND Python... However: Thank you Richard for taking care of PySide2. I contributed (tiny bits) to Fedora's PySide/Shiboken packages in the past and I can only guess how many hours you spent to get the new versions into Fedora. Felix PS: And to make things worse I'm not sure how this could work in the future if the QT Company actually restricts releasing the QT source code by 12 months (AFAIK this is a rumor and not confirmed). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FAS group as default assignee for Bugzilla?
I see that the server returns "401 Unauthorized" when I try to change this via s.f.o. Is changing the bugzilla assignee only allowed for main admins? Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FAS group as default assignee for Bugzilla?
Am 19.05.20 um 11:25 schrieb Fabio Valentini: > Maybe the reason is that the @certbot-sig is registered as a > "tracking" type group, whereas e.g. the new @java-maint-sig is > registered as a "pkgdb" type group? I was able to successfully set > overrides for the latter one. You are probably right but honestly you could speak as well Chinese as I don't have any clue what this means... So I guess I need a helping hand to set the bugzilla assignee. Can we convert a "tracking" group to a "pkgdb" group? Any downsides to this? Felix ___ 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
FAS group as default assignee for Bugzilla?
Hi, it seems it is possible to use a -sig group as default bugzilla assignee but I don't know how to do it. If I go to pagure (src.fedoraproject.org) I can edit the bugzilla assignee but using "@certbot-sig" (or "certbot-sig") does not work (error message "Unable to update the bugzilla assignee(s)"). I guess getting that to work requires manual work from some infra folks? Background: I'm maintaining the "certbot" stack in Fedora/EPEL. There are ~20 different packages in the stack. In order to ease granting permissions for new packagers we have "@certbot-sig" group which has commit privileges for most of these packages. However new bugzilla tickets are assigned to the main package admins by default. These "main admins" is a group of maybe 5 people and none of them is really active in Fedora at the moment. I'd like to be aware of new bugzilla issues so I can help users more effectively. Therefore I'd like to set the sig as default bugzilla assignee. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: moreutils newly in PowerTools repo in centos-8
Am 16.05.20 um 20:42 schrieb clime: > I am a long term epel user and I had no idea about PowerTools. Yeah, I don't think you are the only one. Most EPEL 8 users do not need anything from PowerTools so it goes pretty much unnoticed. I got 3 or 4 bug reports about this when I added certbot to EPEL 8 and it required python3-mock from PowerTools. (The good thing was that this prompted upstream to change its code. With the latest version I could drop the dependency on python3-mock :-) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [EPEL-devel] Soname bump of libb2 on F31/EPEL7
Am 16.05.20 um 19:39 schrieb Antonio Trande: > `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a > soname bump, so all dependent packages need to be rebuilt: > > $ repoquery --whatrequires libb2-devel --disablerepo=* > --enablerepo=*-source > R-argon2-0:0.2.0-8.fc32.src > borgbackup-0:1.1.11-1.fc32.src > gtkhash-0:1.2-2.fc32.src fine by me. Ideally we could push out all the updated packages in a single update to avoid inconsistencies. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Re-Launching the Java SIG
Am 12.05.20 um 12:32 schrieb Ty Young: > Right, I figured it was some Fedora policy and not up to you. I suppose I > should have been more clear there. Sorry for any confusion, it was aimed at > the Fedora project as a whole as this is a Fedora issue. This is not a Fedora issue but a consequence of Fedora's core values. You not agree with it but "building from source" is so fundamental that it does not make sense to even start a discussion about it on fedora-devel. I suggest you read up on the rationale behind that policy (which is why I linked the policy document in the first place). I understand that missing components/features due to the source requirement are annoying but Fedora (and other distros) decided to take the "high road" here and actually fix stuff instead of shipping whatever upstream came up with. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Re-Launching the Java SIG
Hey Fabio, thank you very much for your work. I can't take on more Fedora work but still wanted to express my gratitude :-) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Re-Launching the Java SIG
Am 12.05.20 um 10:35 schrieb Ty Young: > JUST PACKAGE THE PRE-COMPILED BUILDS!!! Don't take me as rude but this is not possible. This is documented in Fedora's packaging policies: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is there a way to mockbuild systemd?
Am 16.04.20 um 20:05 schrieb Göran Uddeborg: > As the suggestion was sent off list, I didn't want to say that. No reason to keep it secret :-) Until now I did not realize I sent you a private message (just wondered about the privat reply ;-) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-msgpack
Am 24.03.20 um 12:04 schrieb Felix Schwarz: > If I have some spare cycles I'll try to run the upstream test suite with > msgpack 1.0. just fyi: borgbackup upstream was not compatible with python-msgpack 1.0 but upstream was (again) very helpful so the next version of borgbackup will also support msgpack 1.0. Felix ___ 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
non-responsive maintainer: elyscape (Eli Young)
Hi, following the policy for non-responsive package maintainers [0], I'm asking here if anybody knows how to contact elyscape (Eli Young). Eli, if you're still interested in maintaining your packages, please respond. Open bugs: - python-digitalocean-1.15.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=1793188 - python-digitalocean: please provide a package for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1813735 - python-tldextract-2.2.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1762086 Felix [0]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
Am 01.04.20 um 08:42 schrieb Clement Verna: > I think this feeling comes from the mixing of git forge and dist-git use case > that you have pointed out. That seems to be the core of all the talk about "feature gaps" - obviously pagure is not nearly as advanced as gitlab/github when you want "some space for generic software development" (and probably will never be). However using a generic git forge means we need a separate "self-service application" for administration of Fedora packages. We had that in the past (packagedb). I don't want to presume too much but I just hope you researched why packagedb was decommissioned and why people thought integrating the functionality into pagure was a good idea? Right now this really feels like a kind of ping-pong (from packagedb to pagure to packagedb2?). I'm not against reversing decisions when the environment changes or just because after careful consideration something seems like a better choice. Still I'm worried that the CPE team might have missed some of the lessons learned in the past... Felix ___ 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
