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

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

Re: Orphaning python-flit

Am 25.01.24 um 20:34 schrieb Miro Hrončok: $ repoquery -q --repo=rawhide{,-source} --whatrequires flit ... python-pydyf-0:0.8.0-1.fc40.src ... weasyprint-0:60.2-1.fc40.src The packages would probably build fine with flit-core Indeed, python-pydyf and weasyprint build just fine with

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

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

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

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

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

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

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

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

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

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

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

[EPEL-devel] Re: Handling packages with missing dependencies provided by HA-RS repos?

Am 24.03.22 um 19:52 schrieb Carl George: I found python-certbot-dns-google and python-certbot-dns-route53 that require some of these packages. I did local mock builds using a custom one off config comprised of RHEL8, RHEL8 HA, and EPEL8 with the above packages excluded. The %check sections

[EPEL-devel] Re: Handling packages with missing dependencies provided by HA-RS repos?

Am 24.03.22 um 03:18 schrieb Carl George: python-boto3-1.6.1-2.el8 python-boto3-1.15.15-1.el8 python-botocore-1.9.1-2.el8 python-botocore-1.18.15-1.el8 python-fasteners-0.14.1-14.el8 python-fasteners-0.14.1-20.el8 python-oauth2client-4.1.2-6.el8 python-oauth2client-4.1.3-9.el8

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:

[EPEL-devel] new package repo not created despite review approval

Hi, I have submitted a review request [1] which passed ("fedora-review +") but somehow the package git repo was not created. For Fedora packages this happens pretty quickly after approval. Any idea who I should ping about this? Felix [1]

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

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

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.

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

Am 17.02.22 um 13:52 schrieb Stephen John Smoogen: The working assumption has been that the Fedora package is already cleaned up and dependencies are there because the main packager thought they were needed. I and other EPEL packagers have spent enough time 'cleaning up' a package and then

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

+1 I'd like to highlight python3-nose and python3-mock. If your package depends on one of these you should really fix your package and/or code upstream. Felix ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an

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

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

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

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

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

[EPEL-devel] Re: question about review process excemptions for Python 3

Am 23.01.22 um 10:57 schrieb Nick Howitt via epel-devel: A bit o/t, but will you be updating the python2-certbot-dns-* packages as well? All certbot plugins currently in EPEL 7 will transition to Python 3 as well (all packages will be in a single upgrade). So technically the Python 2

Re: MinGW & building wheels

Am 21.01.22 um 23:12 schrieb Scott Talbert: I'm using the mingw stack to cross-compile a Windows binary which shipped as part of an otherwise platform neutral Python wheel. The main problem I had with Fedora's mingw Python was that I could not create a Windows wheel. Yep, that's the same

question about review process excemptions for Python 3

Hi, 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

[EPEL-devel] question about review process excemptions for Python 3

Hi, 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

Re: MinGW & building wheels

Am 21.01.22 um 15:59 schrieb Scott Talbert: Does anyone have any experience with using Fedora's MinGW stack to cross-compile Python wheels for Windows? I'm using the mingw stack to cross-compile a Windows binary which shipped as part of an otherwise platform neutral Python wheel. The main

"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

Re: Proposal: Make -r (include runtime deps) the default for %pyproject_buildrequires

Am 10.01.22 um 13:55 schrieb Miro Hrončok: Hence, I propose we make the -r flag the default. In case some package needs to opt-out for legitimate reasons, a new flag would exist to disable it (most likely -R). +1 Felix ___ python-devel mailing

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

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

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

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

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

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:

Re: HEADS UP: Slightly more robust Python Requires generated by RPM

Am 30.10.21 um 21:42 schrieb Gordon Messmer: I'd suggest that we should instead strongly encourage the use of PyPI URLs. I agree that pypi downloads are usually preferable. However I had to use github tarballs sometimes as upstream did not ship the test suite for pypi tarballs... Just my 2

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

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

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.

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

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:

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

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

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

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

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

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

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

Re: How to track the build failure built on f35-python

Am 07.06.21 um 09:49 schrieb Chenxiong Qi: I just noticed that python-social-auth-core-4.1.0-2.fc35 keeps failing to build on f35-python. I'm wondering if there is any mechanism to report a bug in Bugzilla automatically, or how do we usually track such failure? The main Python wranglers

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

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

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

[EPEL-devel] Re: Fwd: fmt soname bump in EPEL7

Am 11.05.21 um 06:45 schrieb kefu chai: i pushed the updated libfmt v6 to EPEL7 as a fix of [1]. it upgraded libfmt v3.01 to libfmt 6.2.1, and introduced a soname bump for libfmt.so. so packages depending on libfmt should be rebuilt to pick up the new library. It would be helpful if you could

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

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

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

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

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).

Re: Self Introduction | Harsh Mangal

Am 19.02.21 um 16:13 schrieb Harsh Mangal: I am Harsh having intermediate experience working with Python and I am interested in contributing to this SIG can anyone help me out on "How to get started". I could use some help e.g. with WeasyPrint/cairo: The latest cairo in Fedora 34+ did

Re: Plan to deprecate pytz in Fedora 35+

Hi Miro, I can understand the desire to remove pytz and I have to mention that I don't have any specific upstream feedback. However certbot/babel do support pretty old versions of Python. Adding a separate code path for Python 3.x+ might be a pretty tough sell and might contribute to the

[EPEL-devel] how to request access for EPEL-only package which existed in Fedora previously?

Hi, I created a review request for python3-configobj which is needed to update certbot in EPEL 7. (certbot now only supports Python 3). The python3-configobj repo was used in Fedora (in ancient history) but I think it can be "reused" to provide an EPEL7-only package. Now my review request

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

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

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

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

[EPEL-devel] Re: EPEL, Playground, CentOS Stream, etc

Am 08.12.20 um 19:56 schrieb Japheth Cleaver: With point releases, at least there was the possibility of flag days around EPEL ABI changes, however with a rolling release format there seems to need to be an active synchronization around such changes, as "expected" breakages aren't really

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/...

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

Re: %pyproject_install: .dist-info vs .egg-info

On 30.11.20 10:54, Miro Hrončok wrote: Hence wrt backwards compatibility: pip might now refuse to uninstall the RPM installed package, while previously it would have done so happily. That is an improvement, but technically is not 100% backwards compatible behavior. Oh, I can live with THAT

Re: %pyproject_install: .dist-info vs .egg-info

Am 29.11.20 um 23:11 schrieb Donald Stufft: Unless there’s something fedora specific going on, that should be correct. Upstream side, anytime pip installs from a Wheel it produces a dist-info instead of a egg-info, so if there was some compatibility issue, it should have been exposed awhile

%pyproject_install: .dist-info vs .egg-info

Hey, I just noticed that the new packaging macros create a .dist-info directory instead of .egg-info. Just to be sure: There is no incompatibility between these two, right? So setuptools-based code can still retrieve all the package metadata in .dist-info directories? (If so I can just

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:

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

Re: help wanted with modern Python packaging macros (%generate_buildrequires, %tox)

Hi Miro, just wanted to say thank you. It took me much longer than expected to actually try your suggestions but they were spot-on. :-) Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to

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

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

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

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

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

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. >

help wanted with modern Python packaging macros (%generate_buildrequires, %tox)

Hi, I wanted to update python-dns-lexicon. Version 3.4 uses poetry and tox so I thought it would be a good idea to get a grip on %generate_buildrequires, %tox etc. Unfortunately I'm a bit stuck at the moment. Maybe this is just because I'm starring for too long on some spec file (and probably my

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 --

ability to move just some Python files (+pyc) in subpackage?

Hi, I'm working towards updating python-dns-lexicon. It can handle many different dns APIs and for some APIs the code needs additional libraries (some of these are not packaged for Fedora). Upstream handles this by using "extras" requirements and the CLI throws an error message if you try to use

how to depend on 'requests[security]'?

Hey, I'm trying to update a package which now depends on "requests[security]" instead of just "requests". If I understand https://fedoraproject.org/wiki/Changes/PythonExtras correctly there no mechanism right now to pull in "requests[security]" (along with its dependencies) so I need to patch

[EPEL-devel] Re: EPEL 8: modular libnghttp2 replaces package from RHEL base

Hi Troy, thank you for the pointer and sorry if my tone was a bit harsh. I filed also https://bugzilla.redhat.com/show_bug.cgi?id=1851642 - is that the right place? Felix ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe

[EPEL-devel] EPEL 8: modular libnghttp2 replaces package from RHEL base

This morning I got an email notification: Package Arch Version Repository Size

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

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

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

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

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?

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

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

[EPEL-devel] Re: unable to submit updates to stable: 504 Gateway Time-out

Am 04.06.20 um 07:07 schrieb Sérgio Basto: > Please what ticket ? I think Troy was referring to "bodhi times out on update with many (almost 300) packages" https://pagure.io/fedora-infrastructure/issue/8949 Felix ___ epel-devel mailing list --

  1   2   3   >