Re: Macros stored in a separate file
> Lately, I noticed that several SPEC files in Fedora use this syntax: > > Source: macros.vlc > > And this file defines macros that are loaded by rpmbuild during buildtime and > are used in > the SPEC file. This isn't how its done everywhere (and I honestly wasn't aware that this was done at all). Zig, for example, only ships it for other packages to make common operations simpler and integrate with the system. -- ___ 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
As the downstream maintainer of NodeJS, I want to express both thanks and deep understanding of your situation. Especially with the de-modularization effort, your work was always a godsend for us. Take care and good luck! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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
Major version update of reuse tool (3.0.2) incoming
Hello all! As of today, I have picked up maintenance of FSFE's reuse tool [1]. I have a major update in progress, which IIRC includes changes on how the CLI should be used. I do not know if any Fedora tooling uses this tool, but in case it does, consider this your heads-up. The update should land in rawhide sometime next week, and later also in F40 and F39. Let me know if that works for you or if I should change my plans. Have a nice weekend! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Major version update of reuse tool (3.0.2) incoming
Hello all! As of today, I have picked up maintenance of FSFE's reuse tool [1]. I have a major update in progress, which IIRC includes changes on how the CLI should be used. I do not know if any Fedora tooling uses this tool, but in case it does, consider this your heads-up. The update should land in rawhide sometime next week, and later also in F40 and F39. Let me know if that works for you or if I should change my plans. Have a nice weekend! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 End Of Life in one week
On Tue, May 14, 2024 at 11:03:07PM +0530, Samyak Jain wrote: > Hello all, > > Fedora Linux 38 will go end of life for updates and support on > 2024-05-21. This announce comes as a surprise becuase it does not match the https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html schedule which says the EOL should be today. This is also the information that https://endoflife.date/fedora seems to use. Where did the different date of 2024-05-21 come from and where was it tracked? > [1]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule > [2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades Neither of these have information specific about Fedora 38. -- Jan Pazdziora | OpenShift AI | Red Hat -- ___ 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
dnf5 default switch and soname bump in Rawhide
Hi, Given the positive feedback on the testing side-tag <https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2>, this is now moving into the stable along with the soname bump. Thanks for the feedback, everyone! Jan -- ___ 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
Self Introduction: Jan André Reuter
Hey everyone, I'd like to self introduce myself to the devel community. My name is Jan, I'm 27 years old and working in the Jülich Supercomputing Centre (JSC) at the Research Center Jülich as a software developer and researcher. I've started working at the Research Center back in 2015, initially as a part of the vocational training for a mathematical technical software developer and since 2018 as a researcher working on software for HPC systems (full time since 2020, after finishing my masters). In December 2022, I switched institutes and joined the Parallel Performance team at JSC to work on the open-source performance infrastructure Score-P and improve its support for OpenMP (mostly via the OpenMP Tools Interface), compilers, and accelerators in general. My interests in general involve everything around HPC development and performance analysis, and (on a less work-focused level) PC hardware and board games. After our last release mid March, I've noticed that the Fedora package of Score-P was a few versions behind the current one. As we update most of the available install methods ourselves (like EasyBuild/Spack), I was also interested in providing a newer version for Fedora. Therefore, I decided to learn a bit about the packaging and open a PR to update it to the latest release. I have still a lot to learn, but I'm eager to learn more about the packaging and everything around it. You can find my first PRs down below: - Update Score-P to v8.4: https://src.fedoraproject.org/rpms/scorep/pull-request/1 - Update OPARI2 to v2.0.8: https://src.fedoraproject.org/rpms/opari2/pull-request/1 - Fix for update, since Score-P requires libunwind-devel to be present: https://src.fedoraproject.org/rpms/scorep/pull-request/2 In the long term, I'd love to help maintaining Score-P <https://src.fedoraproject.org/rpms/scorep> and its associated packages (OPARI2 <https://src.fedoraproject.org/rpms/opari2>, Cube <https://src.fedoraproject.org/rpms/cube>, Scalasca <https://src.fedoraproject.org/rpms/scalasca/>, OTF2 <https://src.fedoraproject.org/rpms/otf2>) for Fedora, since our releases are often coupled together and I have close contact to the people working on these packages. Jan -- Jan André Reuter Jülich Supercomputing Centre (JSC) ATML Parallel Performance Phone: +49-2461-61-8871 E-Mail:j.reu...@fz-juelich.de Internet:http://www.fz-juelich.de - - Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschaeftsfuehrung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Frauke Melchior - - smime.p7s Description: S/MIME Cryptographic Signature -- ___ 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
Hi Adam, > Just to follow up on this: the Kiwi container build test failure > pointed to some changes that will be required to the Fedora kiwi config > when this change lands. I have filed a PR for that - > https://pagure.io/fedora-kiwi-descriptions/pull-request/46 - which > should only be merged when this update is getting pushed. I tweaked the > openQA test to make those changes on-the-fly when testing this update, > and now it passes. > > By inference it occurred to me to check the osbuild configs also and I > found a likely-required change there, so I sent a PR for that - > https://github.com/osbuild/images/pull/637 - which has been merged. We > would need the osbuild folks to deploy that change to prod before this > update lands in Rawhide, otherwise some osbuild-driven image builds > will most likely start to fail. > Oh, great! We were planning to handle these ourselves, so thanks a lot for help! > The Cockpit update test failures turned out to be just stricter > defaults in the new dnf exposing a bug in how the openQA tests handle > the advisory repo (the side repo that contains the packages from the > update under testing). I fixed that, and now the tests pass. > Great, thanks! Regards, Jan On Fri, Apr 26, 2024 at 8:20 PM Adam Williamson wrote: > On Wed, 2024-04-24 at 22:56 -0700, Adam Williamson wrote: > > On Thu, 2024-04-25 at 07:42 +0200, Jan Kolarik wrote: > > > Hello everyone, > > > > > > We've prepared a side-tag for testing Rawhide with dnf5 as the default > > > package manager. Instructions for installing the packages from the > side-tag > > > can be found at the following link [1]. > > > > > > Please provide feedback in Bodhi or on this mailing list regarding the > use > > > cases you're familiar with from the existing dnf command, and share > your > > > experience with this new version. > > > > > > If there's no negative feedback regarding any critical functionality, > we > > > plan to push the packages from the side-tag to Rawhide next week. > > > > > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2 > > > > The update failed a couple of openQA tests. I will take a closer look > > into the reason in the morning, I'm busy reneedling things for the GTK > > update at present. > > Just to follow up on this: the Kiwi container build test failure > pointed to some changes that will be required to the Fedora kiwi config > when this change lands. I have filed a PR for that - > https://pagure.io/fedora-kiwi-descriptions/pull-request/46 - which > should only be merged when this update is getting pushed. I tweaked the > openQA test to make those changes on-the-fly when testing this update, > and now it passes. > > By inference it occurred to me to check the osbuild configs also and I > found a likely-required change there, so I sent a PR for that - > https://github.com/osbuild/images/pull/637 - which has been merged. We > would need the osbuild folks to deploy that change to prod before this > update lands in Rawhide, otherwise some osbuild-driven image builds > will most likely start to fail. > > The Cockpit update test failures turned out to be just stricter > defaults in the new dnf exposing a bug in how the openQA tests handle > the advisory repo (the side repo that contains the packages from the > update under testing). I fixed that, and now the tests pass. > -- > Adam Williamson (he/him/his) > Fedora QA > Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org > https://www.happyassassin.net > > > > -- > ___ > 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 > -- ___ 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
Hi Kevin, Personally, I think this is a beta requirement. > IIUC the Fedora 41 Beta requirement is to successfully upgrade the system from Fedora 40, as mentioned here: https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation. So this still relates to the dnf4 package, which is used in Fedora 40. I expect this will become relevant for dnf5 at the Fedora 42 Beta. So, how do you rate the chances of having something ready by beta > freeze? > Talking about "something", there's already a system-upgrade command available in this dnf5 version from the side-tag :) However, as I mentioned earlier, it hasn't been thoroughly tested yet; that's our goal for the upcoming months. Regards, Jan On Thu, Apr 25, 2024 at 7:55 PM Kevin Fenzi wrote: > On Thu, Apr 25, 2024 at 11:42:57AM GMT, Jan Kolarik wrote: > > Hello Michael, > > > > Does this mean that distro-upgrade from F41 to F42 is supposed to work > > > at F41 release time (ideally at beta time)? > > > > > > > Yes, the system-upgrade functionality should be available before the > Fedora > > 41 > > release date. We're planning extensive testing for this, including a > Fedora > > Testing Day. > > Personally, I think this is a beta requirement. > > Lots of people upgrade around then to get on the new release, and also > having it available to test then is pretty important. > > Thats just my opinon... QE might have different opinions. > > > While our goal is to deliver the final system-upgrade functionality > before > > the stable release, > > some adjustments may be made during the Fedora 41 lifecycle to ensure > > smoother > > upgrades from F41 to F42. Before executing the system-upgrade, users are > > anyway > > advised to ensure that all installed packages are fully updated. > > So, how do you rate the chances of having something ready by beta > freeze? > > kevin > -- > ___ > 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 > -- ___ 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
Hi Maxwell, This contains an update to dnf 5.2.0 which has breaking API changes. I did > not > see these communicated anywhere and the Change Proposal did not mention > that > the update would include a major version bump at the same time as the > switch to > dnf5 as default. > You're right; we missed this. I'm sorry about that. Our initial intention wasn't to do a major version bump, but implementing the new functionality without breaking ABI and API would have required a lot of extra work. Would it be possible to provide a testing Copr ... > Sure, as mentioned earlier, there's a dnf5-testing COPR specifically for these purposes: https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing. ... and a porting guide so API users can fix their software > before this is pushed to rawhide? > We'll add a section about the API changes between dnf5 versions 5.1 and 5.2, and we'll reach out to the several teams affected by this. We'll also ensure that the builds for our reverse dependencies are passing with this update. We definitely don't want to push this before these projects are fixed. Still, I hope no harm has been done yet. That's actually the purpose of this side-tag, to identify any gaps we may have missed while working on the switch. The 5.2.0.0 API changes aren't significant, there are though many ABI-breaking changes. Thanks, Jan On Thu, Apr 25, 2024 at 5:29 PM Maxwell G wrote: > Hi Jan, > > On Thu Apr 25, 2024 at 07:42 +0200, Jan Kolarik wrote: > > We've prepared a side-tag for testing Rawhide with dnf5 as the default > > package manager. Instructions for installing the packages from the > side-tag > > can be found at the following link [1]. > > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2 > > Thank you for the announcement. I appreciate the oppurtunity to test the > update before it's pushed to rawhide. > > This contains an update to dnf 5.2.0 which has breaking API changes. I did > not > see these communicated anywhere and the Change Proposal did not mention > that > the update would include a major version bump at the same time as the > switch to > dnf5 as default. This update completely breaks fedrq due to the removed > methods. ansible, lorax, and osbuild also depend on libdnf5. Have these > applications had a chance to port to the new API? Would it be possible to > provide a testing Copr and a porting guide so API users can fix their > software > before this is pushed to rawhide? > > Best, > Maxwell > -- > ___ > 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 > -- ___ 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
Hello Michael, Does this mean that distro-upgrade from F41 to F42 is supposed to work > at F41 release time (ideally at beta time)? > Yes, the system-upgrade functionality should be available before the Fedora 41 release date. We're planning extensive testing for this, including a Fedora Testing Day. While our goal is to deliver the final system-upgrade functionality before the stable release, some adjustments may be made during the Fedora 41 lifecycle to ensure smoother upgrades from F41 to F42. Before executing the system-upgrade, users are anyway advised to ensure that all installed packages are fully updated. Jan On Thu, Apr 25, 2024 at 10:22 AM Michael J Gruber wrote: > Jan Kolarik venit, vidit, dixit 2024-04-25 07:42:10: > > Hello everyone, > > > > We've prepared a side-tag for testing Rawhide with dnf5 as the default > > package manager. Instructions for installing the packages from the > side-tag > > can be found at the following link [1]. > > > > Please provide feedback in Bodhi or on this mailing list regarding the > use > > cases you're familiar with from the existing dnf command, and share your > > experience with this new version. > > > > If there's no negative feedback regarding any critical functionality, we > > plan to push the packages from the side-tag to Rawhide next week. > > Does this mean that distro-upgrade from F41 to F42 is supposed to work > at F41 release time (ideally at beta time)? > > I'm all for dnf5 and would use it now (and hat an epsisode on F39), but > since distro-ugrades F40->F41 are off the table (as has been stated) > it's not a good idea to use it in F40 unless you are willing to deal > with autoremove trouble and the like. > > So, if we push dnf5 as default to rawhide now we have to be reasonably > sure that F41 will distro-ugrade to F42 using dnf5. > > Michael > > -- ___ 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
Hi Mattia, Yep, there's a dnf5-testing COPR that serves exactly this purpose: https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing. Jan On Thu, Apr 25, 2024 at 10:10 AM Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 25/04/24 07:42, Jan Kolarik ha scritto: > > Hello everyone, > > > > We've prepared a side-tag for testing Rawhide with dnf5 as the default > > package manager. Instructions for installing the packages from the > > side-tag can be found at the following link [1]. > > > > Please provide feedback in Bodhi or on this mailing list regarding the > > use cases you're familiar with from the existing dnf command, and > > share your experience with this new version. > > > > If there's no negative feedback regarding any critical functionality, > > we plan to push the packages from the side-tag to Rawhide next week. > > > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2 > > > > Thanks, > > Jan > > I'd also like to test it on a real F40 machine (I have been using mostly > dnf5 commands in a F40 VM without issues during the latest months), is > there maybe a COPR repo or something like which allows that? > > Mattia > > -- > ___ > 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 > -- ___ 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
Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
Hello everyone, We've prepared a side-tag for testing Rawhide with dnf5 as the default package manager. Instructions for installing the packages from the side-tag can be found at the following link [1]. Please provide feedback in Bodhi or on this mailing list regarding the use cases you're familiar with from the existing dnf command, and share your experience with this new version. If there's no negative feedback regarding any critical functionality, we plan to push the packages from the side-tag to Rawhide next week. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2 Thanks, Jan -- ___ 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: Switch to DNF5 (system-wide)
Hi guys, the dnf-automatic command will be obsoleted. > Oh, sorry about that. This portion of the text was inadvertently altered during the review process. I've already corrected the text on the wiki. The dnf-automatic command will still be available, now provided as a plugin and functionally compatible with dnf4. Although the configuration files' location has changed, it will be documented in the dnf4 vs. dnf5 changes documentation <https://dnf5.readthedocs.io/en/latest/changes.html>. Thanks, Jan On Thu, Apr 4, 2024 at 12:06 AM Kevin Fenzi wrote: > On Wed, Apr 03, 2024 at 11:57:48AM -0700, Adam Williamson wrote: > > On Wed, 2024-04-03 at 14:27 -0400, Przemek Klosowski via devel wrote: > > > On 4/3/24 06:36, Aoife Moloney wrote: > > > > the dnf-automatic command will be obsoleted. > > > > > > https://dnf5.readthedocs.io/en/latest/changes.html does not say > anything > > > about automatic updates, and > > > > > > https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/ > > > > > > simply suggests that dns update be executed from systemd timers or > cron > > > jobs. > > > > > > > > > dns-automatic provided a simple interface to a setup-and-forget > > > automatic updates; will DNF5 leave it to be set up by hand? > > > > > > I am asking because systemd timers have surprising behavior for > > > suspendable systems, which leads to problems if updates are scheduled > > > for off-hours. > > > > > > My experience is that even |WakeSystem=true does not make them > reliable, > > > but I am not sure how to debug this (because the system is suspended, > heh). > > > > > > > We do use dnf-automatic quite extensively within infra, I think. Has > > this been discussed with infra? > > Not that I know of. Yes, we do use dnf-automatic all over the place. ;( > > kevin > -- > ___ > 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 > -- ___ 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: Switch to DNF 5 (System-Wide)
> > Maybe the "isn't entirely removingdnf4 from the system" is the root of > the issue. Is this planned? > For now, the preliminary plan is to keep the dnf4 stack in Fedora for another one following release, meaning if dnf5 switch is implemented in Fedora 41, dnf4 stack should be removed in Fedora 43. Jan On Tue, Mar 26, 2024 at 10:04 AM Vít Ondruch wrote: > > Dne 26. 03. 24 v 8:02 Zbigniew Jędrzejewski-Szmek napsal(a): > > On Tue, Mar 26, 2024 at 06:39:35AM +0100, Jan Kolarik wrote: > >> Previously, I had issues that migration from DNF4 to DNF5 left a lot of > >>> data in /var/cache. How is this going to be addressed? I don't think > it is > >>> fair to leave those behind and waste disk space for regular users. > >>> > >> That's a good point. Though since this migration isn't entirely removing > >> dnf4 from the system but just altering the symlink, users can still > access > >> it. Hence, automated removal isn't feasible. However, we could consider > >> offering a user prompt after the transaction involving symlink > replacement, > >> advising users to delete /var/cache/dnf if they no longer intend to use > >> dnf4. > > What about adding the scriptlet to remove /var/cache/dnf to the > > dnf4 package? (That's how I understood the original ask.) > > > Maybe the "isn't entirely removingdnf4 from the system" is the root of > the issue. Is this planned? Because in that case, the cache would be > likely removed: > > > https://src.fedoraproject.org/rpms/dnf/blob/c7f6b4941a317bfde54b704e925152daecb17dda/f/dnf.spec#_292 > > > Vít > > > > > > Zbyszek > > -- > > ___ > > 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 > -- > ___ > 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 > -- ___ 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: Switch to DNF 5 (System-Wide)
Hi Zbyszek, Thanks for feedback. Second, I think that the lack of support for dnf5 in some areas is > going to be painful: in particular, as long as Anaconda and PackageKit > depend on dnf-3, we're going to be in a strange state the basic system > tools use two different versions of the code, and perhaps more > importantly, use two different databases of information about > installed packages. > I'd like to emphasize that the RPM DB, which contains the database of installed packages, remains the singular source in the system. However, the metadata containing the reasons for package installations now reside in a different format and location. Therefore, when concurrently using dnf4 and dnf5 on the system, packages installed by one of them as dependencies will appear as user-installed to the other one, potentially leading to them not being auto-removed later. Regards, Jan On Mon, Mar 25, 2024 at 7:11 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Mon, Mar 25, 2024 at 03:46:47PM +, Aoife Moloney wrote: > > == Summary == > > Change the default package manager from dnf to dnf5. > > > > == Owner == > > * Name: [[User:jkolarik| Jan Kolarik]] > > * Email: jkola...@redhat.com > > > > * Name: [[User:jmracek| Jaroslav Mracek]] > > * Email: jmra...@redhat.com > > First, thank you for putting together such a detailed proposal. > Having all the dependencies listed allows a proper evaluation of how > things are going to work during the upgrade. > > Second, I think that the lack of support for dnf5 in some areas is > going to be painful: in particular, as long as Anaconda and PackageKit > depend on dnf-3, we're going to be in a strange state the basic system > tools use two different versions of the code, and perhaps more > importantly, use two different databases of information about > installed packages. > > But, third, I think we should do the switch. Dnf5 is some aspects > significantly better than dnf-3, so users will really benefit from > the switch. And we cannot and should not maintain the situation where > the dnf team is working on two different versions of the code. We > need to switch to the new thing and devote the resources we have > to making it work great. > > Zbyszek > -- > ___ > 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 > -- ___ 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: Switch to DNF 5 (System-Wide)
Hello Vit, I don't understand this. So if GS going to use DNF, therefore the same > cache etc, or not? Or what other metadata PackageKit downloads on top of > DNF? > Yes, it will ultimately utilize the same cache. The paragraph you referenced is extracted from the "Early access for developmental branch users" section. This means that until integration is finalized, GNOME Software will use the libdnf backend, which can operate alongside dnf5 but maintains a separate cache. I'll revise the wiki paragraph to explicitly state this as a temporary arrangement until integration is complete. Previously, I had issues that migration from DNF4 to DNF5 left a lot of > data in /var/cache. How is this going to be addressed? I don't think it is > fair to leave those behind and waste disk space for regular users. > That's a good point. Though since this migration isn't entirely removing dnf4 from the system but just altering the symlink, users can still access it. Hence, automated removal isn't feasible. However, we could consider offering a user prompt after the transaction involving symlink replacement, advising users to delete /var/cache/dnf if they no longer intend to use dnf4. Thanks, Jan On Mon, Mar 25, 2024 at 5:59 PM Vít Ondruch wrote: > > Dne 25. 03. 24 v 16:46 Aoife Moloney napsal(a): > > === Reduced footprint === > The dnf5 package is a fully-featured package manager that doesn't > require Python dependencies. > > It also reduces the number of software management tools in Fedora by > replacing both the dnf and microdnf packages. > > The installation size of the dnf5 stack in an empty container is > approximately 60% smaller than the dnf installation. > > Currently, dnf, microdnf, and PackageKit use their own cache, leading > to significant metadata redundancy. With dnf5 and dnf5daemon, which > share metadata, this redundancy will be eliminated. > > > ... snip ... > > > = [https://github.com/rpm-software-management/dnf5/issues/169 > GNOME Software support] = > The integration of dnf5 support, particularly dnf5daemon, into GNOME > Software is currently underway. Developers from both DNF5 and GNOME > Software are closely connected and regularly synchronize the progress > of their work. > > > ... snip ... > > > = GNOME Software = > Rawhide users will continue to utilize the current PackageKit backend > connected to the existing libdnf interface. These libraries can > coexist with the new dnf5 package on the same system. Although the > setup is not ideal due to differences in package state metadata > formats stored at separate locations, resulting in inefficient storage > usage, this is generally imperceptible for typical GUI users. > Furthermore, the underlying RPM DB remains the sole shared source of > information about installed packages. > > > I don't understand this. So if GS going to use DNF, therefore the same > cache etc, or not? Or what other metadata PackageKit downloads on top of > DNF? > > > Before upgrade > > $ tree /usr/bin/ -P dnf* > /usr/bin/ > ├── dnf -> dnf-3 > ├── dnf-3 > └── dnf4 -> dnf-3 > > > After upgrade > > $ tree /usr/bin/ -P dnf* > /usr/bin/ > ├── dnf -> dnf5 > ├── dnf-3 > ├── dnf4 -> dnf-3 > └── dnf5 > > > > > > Love these versions, as always > > > > > === Different system state === > The transactional history in dnf and dnf5 is not shared, and they now > use different formats. Transactions performed in dnf will not be > visible in dnf5, and vice versa. > > While the history database is not migrated to dnf5, when running a > transaction in dnf5 for the first time, an attempt is made to convert > and load the existing system state from dnf. This should preserve > information about the reasons for installed packages and prevent them > from being treated as user-installed, requiring manual removal from > the system instead of being seen as dependencies of explicitly removed > packages. > > > Previously, I had issues that migration from DNF4 to DNF5 left a lot of > data in /var/cache. How is this going to be addressed? I don't think it is > fair to leave those behind and waste disk space for regular users. > > > Vít > -- > ___ > 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: >
Re: Default NodeJS stream packages with versioned names are not available
Miro Hrončok writes: > Python does this similarly to nodejs (we have python3.11, pytohn3, > python3.13 in rawhide today), with one difference. The python3 package > provides python3.12. So when you do: > > requires: > - python3.12 > > It just works. > > I believe nodejs should provide nodejs20, the same way. Thanks for the suggestion, I did not think about provides at all when mulling over the problem. Kudos! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Default NodeJS stream packages with versioned names are not available
Stephen Gallagher writes: > That said, I agree that it's completely reasonable to have the default > version also `Provides: nodejsXX` and I'll look into it. Provides is something I did not consider at all, and it looks like the easiest way forward! Let me know when you get around to it; alternatively, I can throw together a package PR. > I'm confused; it *is* in addition to the versioned ones. We just don't > duplicate the default version because it would be a complete waste. I meant having both versioned and unversioned packages for the *same* (default) stream available. Probably really overkill if the provides works. > The overly-simplified answer here is mainly that there are too many > symlinks to maintain for this to be practical. Acknowledged; thanks for info. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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
Default NodeJS stream packages with versioned names are not available
Hello all,
recently, when trying to spin up a CI for NodeJS in Fedora, I ran into a
slight problem: when a NodeJS stream is the default one, versioned
packages (i.e. nodejs20) are not generated and are not installable.
For example, on current rawhide, I cannot install `nodejs20` package,
only `nodejs`; this will give me the version 20.x as expected.
The problem is that this complicates the CI setup,
and requires me to take into account which Fedora I'm currently on.
As an example, when adding tests for nodejs20 dist-git[1],
I would like to simply specify `requires: nodejs20` into the test
metadata. However, with the current setup, I would need something akin
to the following (pseudocode, I did not really test if that would work):
requires:
- {% if fedora == 40 %}nodejs{% else %}nodejs20{% fi %}
In addition to being more complicated, this will also break if the
default stream for a given Fedora version ever change
(which is not unlikely to happen, as the upstream release schedule
is not really synchronized with the Fedore one).
---
I recall that the current status is the result of already existing
long discussion, with associated debugging, so I would like to have this
solved with as minimal disruption as possible. That being said,
what is the reason for having the non-versioned packages (`nodejs`) *in
stead* of the versioned ones (`nodejs20`), as opposed to *in addition*
to them?
The non-versioned packages could then require the appropriate versioned
ones and contain only symlinks (/usr/bin/node → /usr/bin/node-20,
/usr/lib/node_modules → /usr/lib/node_modules_20, etc.).
Let me know what you think!
Best regards,
--
Jan Staněk
Software Engineer, Red Hat
jsta...@redhat.com irc: jstanek
signature.asc
Description: PGP signature
--
___
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
Hi, if anyone is willing to make a review for wasi-sdk - build require for the Firefox rlbox sandboxing of the used c/c++ libraries, please have a look and let me know about your package: https://bugzilla.redhat.com/show_bug.cgi?id=2267683 -- Jan Horak Senior Software Engineer Red Hat -- ___ 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
Orphaned: multiple perl modules
Hello, I've orphaned perl-BackPAN-Index perl-Cache-FastMmap perl-Git-PurePerl perl-Git-Repository perl-Net-GitHub perl-SOAP-Lite perl-Spreadsheet-ParseExcel perl-Spreadsheet-ParseExcel-Simple perl-Spreadsheet-WriteExcel-Simple perl-String-Diff The packages have co-admins but when I reached out to them, they were not interested in being the main admins. So these packages are looking for someone who can focus on Fedora more than me. There are currently no open bugzillas against them and they are low to extremely low maintenance. -- Jan Pazdziora | OpenShift AI | Red Hat -- ___ 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: dnf-4.19.0 without filelists in Rawhide soon
Yep, this is a topic for potential improvement. Currently, there's a simple file path detection, like "arg[0] == '/' || (arg[0] == '*' && arg[1] == '/')", and filelists are always additionally downloaded in such cases. The situation aligns with dnf5 at the moment, and there's already a tracking issue for this: https://bugzilla.redhat.com/show_bug.cgi?id=2263771. Jan On Wed, Feb 14, 2024 at 12:09 PM Vít Ondruch wrote: > /usr/bin/BINARYNAME is part of the primary metadata AFAIK > > > Vít > > > Dne 14. 02. 24 v 10:49 Jan Kolarik napsal(a): > > Hi Marcin, > > > So no more "dnf install /usr/bin/BINARYNAME" in default setup? > > In the case where a file path argument is provided to dnf, it will > automatically attempt to download the missing filelists metadata. Sorry, I > forgot to explicitly mention this use case. > > Jan > > On Wed, Feb 14, 2024 at 10:42 AM Marcin Juszkiewicz < > mjuszkiew...@redhat.com> wrote: > >> W dniu 9.02.2024 o 14:02, Jan Kolarik pisze: >> > Just a heads up that a new DNF version (4.19.0) is on its way to >> Rawhide >> > and is expected to land within the next several hours. This update >> > brings a system-wide change >> > <https://fedoraproject.org/wiki/Changes/DNFConditionalFilelists> >> related >> > to not downloading filelists metadata by default. >> >> So no more "dnf install /usr/bin/BINARYNAME" in default setup? >> -- >> ___ >> 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 >> > > -- > ___ > 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 > > -- > ___ > 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 > -- ___ 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: dnf-4.19.0 without filelists in Rawhide soon
Hi Marcin, > So no more "dnf install /usr/bin/BINARYNAME" in default setup? In the case where a file path argument is provided to dnf, it will automatically attempt to download the missing filelists metadata. Sorry, I forgot to explicitly mention this use case. Jan On Wed, Feb 14, 2024 at 10:42 AM Marcin Juszkiewicz wrote: > W dniu 9.02.2024 o 14:02, Jan Kolarik pisze: > > Just a heads up that a new DNF version (4.19.0) is on its way to Rawhide > > and is expected to land within the next several hours. This update > > brings a system-wide change > > <https://fedoraproject.org/wiki/Changes/DNFConditionalFilelists> > related > > to not downloading filelists metadata by default. > > So no more "dnf install /usr/bin/BINARYNAME" in default setup? > -- > ___ > 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 > -- ___ 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: dnf-4.19.0 without filelists in Rawhide soon
Hi Florian, What's the impact on mock and older chroots? Just use bootstrap chroot? I don't expect any issues with existing environments. If the filelists metadata is already present on the system, DNF simply won't load them by default now. Or are you referring to something else? Regards, Jan On Fri, Feb 9, 2024 at 4:29 PM Florian Weimer wrote: > * Jan Kolarik: > > > From a Fedora user perspective, there won't be any changes in the way > > you operate the DNF package manager. The only difference is that > > typically there will be less metadata downloaded. Since all packages > > in Fedora should have already eliminated file dependencies requiring > > filelists metadata, no issues with official repositories are > > anticipated. > > What's the impact on mock and older chroots? Just use bootstrap chroot? > > Thanks, > Florian > > -- ___ 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
dnf-4.19.0 without filelists in Rawhide soon
Hello everyone, Just a heads up that a new DNF version (4.19.0) is on its way to Rawhide and is expected to land within the next several hours. This update brings a system-wide change <https://fedoraproject.org/wiki/Changes/DNFConditionalFilelists> related to not downloading filelists metadata by default. >From a Fedora user perspective, there won't be any changes in the way you operate the DNF package manager. The only difference is that typically there will be less metadata downloaded. Since all packages in Fedora should have already eliminated file dependencies requiring filelists metadata, no issues with official repositories are anticipated. If you encounter any problems while resolving a transaction with a third-party package that doesn't align with the Fedora Packaging Guidelines, DNF will provide a hint to the user. In such cases, you can manually fix the situation by explicitly requesting the filelists metadata using the `--setopt=optional_metadata_types=filelists` CLI parameter. Wishing everyone smooth and faster updates! Best regards, Jan -- ___ 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: Adding/creating wasi-libc++ into the wasi-libc package
Hello! Tom Stellard writes: > Would it be possible to re-use the existing libcxx package and > just build it twice, once for the host and once for wasm? Kind > of like what some packages do for mingw? Maybe; I assume nor me nor Jan have any previous experience with building libcxx, so we are not really qualified to answer. The upstream wasi-sdk project (which my wasi-libc is one part of) generally relies on llvm toolchain for everything. The SDK itself is basically a llvm/clang/clang++ built to emit WASM with associated standard libraries thrown in. Now it might be possible to just build the GNU libcxx for wasm32-wasi target (presumably using wasi-libc as the libc implementation) and that would be usable; on the other hand, it might not, and the llvm libcxx would be needed. Tom, would you be able to provide a test build of libcxx for wasm32-wasi, so the other Jan can see if that would work for him? Then we can decide what approach to take next. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Date-Manip] PR #4: Update rawhide to upstream release 6.93
adelton merged a pull-request against the project: `perl-Date-Manip` that you are following. Merged pull-request: `` Update rawhide to upstream release 6.93 `` https://src.fedoraproject.org/rpms/perl-Date-Manip/pull-request/4 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Date-Manip] PR #3: Fix Packit configuration
adelton commented on the pull-request: `Fix Packit configuration` that you are following: `` @nforro Thanks for the hint, I'm giving it a try. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Date-Manip/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Date-Manip] PR #3: Fix Packit configuration
adelton commented on the pull-request: `Fix Packit configuration` that you are following: `` /packit pull-from-upstream `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Date-Manip/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Date-Manip] PR #3: Fix Packit configuration
adelton merged a pull-request against the project: `perl-Date-Manip` that you are following. Merged pull-request: `` Fix Packit configuration `` https://src.fedoraproject.org/rpms/perl-Date-Manip/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Adding/creating wasi-libc++ into the wasi-libc package
Hi, I'm trying to make the sandboxing using the wasi available for the Firefox and for that I need the wasi-sdk [1] in the build root. Currently there's wasi-libc [2] available which is fine and it almost contains all the headers and libraries needed by the wasi-sdk, but there's libc++ stuff missing, namely: wasi-sysroot/include/c++/v1/* wasi-sysroot/lib/wasm32-wasi/libc++.a wasi-sysroot/lib/wasm32-wasi/libc++abi.a The Arch distro is dealing with that by having extra packages: wasi-libc++ and wasi-libc++abi: https://archlinux.org/packages/extra/any/wasi-libc++/ https://archlinux.org/packages/extra/any/wasi-libc++abi/ They use the llvm sources to build the c++ wasi package [3]. Could you help me out with that? [1] https://github.com/WebAssembly/wasi-sdk [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2288202 [3] https://gitlab.archlinux.org/archlinux/packaging/packages/wasi-libcplusplus/-/blob/main/PKGBUILD?ref_type=heads -- Jan Horak Senior Software Engineer Red Hat fedo -- ___ 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: Mysterious weak dependencies on qadwaitadecorations-qt5/qt6
Hi,
This is specified in the QAdwaitaDecorations package itself.
See
https://src.fedoraproject.org/rpms/qadwaitadecorations/blob/rawhide/f/qadwaitadecorations.spec#_31
.
Regards,
Jan
út 26. 9. 2023 v 9:47 odesílatel Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> napsal:
> Hello!
>
> I'm having hard time figuring out which package brought in the weak
> dependencies in my morning update:
> ...
> Installing weak dependencies:
> qadwaitadecorations-qt5 x86_64 0.1.1-1.fc38 updates 55 k
> qadwaitadecorations-qt6 x86_64 0.1.1-1.fc38 updates 62 k
>
> After the update completed, rpm says no package recommends these:
> $ rpm -q --provides qadwaitadecorations-qt6
> libqadwaitadecorations.so()(64bit)
> qadwaitadecorations-qt6 = 0.1.1-1.fc38
> qadwaitadecorations-qt6(x86-64) = 0.1.1-1.fc38
> $ rpm -q --whatrecommends qadwaitadecorations-qt6
> no package recommends qadwaitadecorations-qt6
> $ rpm -q --whatrecommends 'qadwaitadecorations-qt6(x86-64)'
> no package recommends qadwaitadecorations-qt6(x86-64)
> $ rpm -q --whatrecommends 'libqadwaitadecorations.so()(64bit)'
> no package recommends libqadwaitadecorations.so()(64bit)
>
> The only relevant packages that were part of this morning's update
> were qt5-qtbase{,-common,-gui}, qt6-base{,-common,-gui} and perhaps
> gnome-shell and mutter.
>
> Ideas?
>
> Regards,
> Dominik
> --
> Fedora https://fedoraproject.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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
>
___
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
Broken Discrete/Dedicated GPU support
Hey people, KDE recently merged in more support for discrete GPUs through swicheroo-control and I noticed that the logic both KDE and Gnome use does not probe if the GPU is actually discrete/dedicated or not, only if it was used at startup. On Desktop setups, it's not uncommon to see a discrete/dedicated GPU as the default and an integrated GPU on the side, which both desktop environments would assume to be the better one, with Gnome even adding a context option to "Launch using Dedicated Graphics Card" when in reality it would use the integrated GPU. I've looked into contributing to fix the issue, but from the outside, it appears that RedHat is no longer interested in spending resources on it, essentially leaving it unmaintained for the time being. This issue isn't new and has been bothering users for a while: https://github.com/ValveSoftware/steam-for-linux/issues/8074 https://github.com/flathub/com.valvesoftware.Steam/issues/784 https://github.com/ValveSoftware/steam-for-linux/issues/8069 https://github.com/ValveSoftware/steam-for-linux/issues/8179 https://github.com/ValveSoftware/steam-for-linux/issues/8983 https://github.com/bottlesdevs/Bottles/issues/2967 https://github.com/NixOS/nixpkgs/issues/246007 etc. Does anyone know if there is something that can be done about this? Jan ___ 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: dlmalloc CC0 license (was Re: Packaging a cross-compilation environment (wasi-libc))
Hi Daniel, "Daniel P. Berrangé" writes: > I'm reviewing another package (sgxsdk) which also includes a copy > of dlmalloc with the CC0 license declaration. I wondered if you > ever made contact with Doug Lea around this question ? I recall trying to reach him via mail and not being successful; however, since at that time we were pivoting to use another malloc implementation, I did not push that very far (i.e. trying to find other e-mails than the one from changelog). -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 libdnf-plugin-swidtags, planning to orphan swid-tools
On Tue, Jul 11, 2023 at 04:27:34PM +0200, Jan Pazdziora wrote: > > Hello, > > the SWID tag enablement introduced by > https://fedoraproject.org/wiki/Changes/SWID_Tag_Enablement did not lead > to a wider SWID tag adoption, and other technologies (IMA, SPDX) seem > to be more relevant for the purpose SWID tags were expected to play, > four years later. > > For that reason I've orphaned libdnf-plugin-swidtags. > > I'm looking for ways to reach out to the rpm-software-management-sig > who are co-maintainers of https://src.fedoraproject.org/rpms/swid-tools > to see what their interest / plang might be about swid-tools but > overall I'm leaning towards orphaning swid-tools as well shortly. I've now orphaned swid-tools in Fedora as well. -- Jan Pazdziora | Sr. Principal Software Engineer | Red Hat ___ 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
Orphaned libdnf-plugin-swidtags, planning to orphan swid-tools
Hello, the SWID tag enablement introduced by https://fedoraproject.org/wiki/Changes/SWID_Tag_Enablement did not lead to a wider SWID tag adoption, and other technologies (IMA, SPDX) seem to be more relevant for the purpose SWID tags were expected to play, four years later. For that reason I've orphaned libdnf-plugin-swidtags. I'm looking for ways to reach out to the rpm-software-management-sig who are co-maintainers of https://src.fedoraproject.org/rpms/swid-tools to see what their interest / plang might be about swid-tools but overall I'm leaning towards orphaning swid-tools as well shortly. The fact that latest python and dnf5 changes lead to FTBFS or FTI https://bugzilla.redhat.com/show_bug.cgi?id=2220605 are also contributing to my decision to orphan. -- Jan Pazdziora | Sr. Principal Software Engineer | Red Hat ___ 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: F39 Change Proposal: No custom Qt theming for Fedora Workstation (Self Contained)
Hi, po 26. 6. 2023 v 19:26 odesílatel Fabio Valentini napsal: > On Thu, Jun 22, 2023 at 6:21 PM Aoife Moloney wrote: > > > > (snip) > > > > > == Detailed Description == > > [https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] project is > > a Qt Platform Theme plugin. It reads GNOME configuration, like fonts > > or icons and applies this configuration to Qt applications. It also > > provides implementation of Client-Side Window Decorations or native > > dialogs. This project partially overlaps with Qt's default GTK > > Platform Theme plugin, but there are some additions that are existing > > only in QGnomePlatform, like Client-Side Window Decorations. > > How will this affect Qt-on-GNOME applications? > I remember there being problems in the past because gnome-shell / > mutter apparently did not support SSD. > Will windows still have decorations in all combinations of > Qt+X11/Wayland-on-GNOME+X11/Wayland? > > Yes, I would like to ideally bring GNOME-like decorations that are currently provided by QGnomePlatform directly to Qt upstream. In case I don't make it in time, we will most likely end up at least shipping that part of QGnomePlatform that gives you exactly that. Regards, Jan Grulich ___ 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: cups-2.4.2-11.fc39.src.rpm depends on autoconf-2.71 or newer, not mentioned in .spec file, fails build
On Sun, Mar 26, 2023 at 02:44:34PM +0300, ijaaskelai...@outlook.com wrote: > Kind regards, The Improvement Skeleton. Please show the exact steps you use to build the cups package and the exact error message you get. Technically you are correct because configure.ac has AC_PREREQ([2.71]). But autoconf is pulled in by the automake which is listed as BuildRequires in cups.spec file, and since Fedora rawhide only has autoconf-2.71-5.fc38.noarch, there really is not an older autoconf around to ruin your day. -- Jan Pazdziora | Sr. Principal Software Engineer | Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Date-Manip] PR #2: Enable rebase pull request filing for upstream releases.
adelton merged a pull-request against the project: `perl-Date-Manip` that you are following. Merged pull-request: `` Enable rebase pull request filing for upstream releases. `` https://src.fedoraproject.org/rpms/perl-Date-Manip/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Date-Manip] PR #2: Enable rebase pull request filing for upstream releases.
adelton opened a new pull-request against the project: `perl-Date-Manip` that you are following: `` Enable rebase pull request filing for upstream releases. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Date-Manip/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review swap – wasi-libc
Hello, I have a RR opened for wasi-libc, C standard library implementation on top of WebAssembly System Interface. There were already some back and forth discussion on the package, and I feel it is now ready for the formal review. https://bugzilla.redhat.com/show_bug.cgi?id=2166379 I'm willing to take a review or two in exchange for helping me push this forward. Thanks in advance! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-SOAP-Lite] PR #3: Remove obsolete filter-requires.sh script
adelton merged a pull-request against the project: `perl-SOAP-Lite` that you are following. Merged pull-request: `` Remove obsolete filter-requires.sh script `` https://src.fedoraproject.org/rpms/perl-SOAP-Lite/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-SOAP-Lite] PR #3: Remove obsolete filter-requires.sh script
adelton commented on the pull-request: `Remove obsolete filter-requires.sh script` that you are following: `` LGTM and the scratch build passed, merging. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-SOAP-Lite/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
procps-ng-4.0.2 rebase with new library and its name change
Hello, I've made a rebase to the newest procps-ng, which had switched to its newlib branch completely. This brings a massively-rewritten library, formerly libprocps.so. The library changed its name to libproc2. For this reason, I created a side-tag f39-build-side-63116. Please ping me any time in case of a question. Cheers, Jan (jrybar) ___ 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
Intent to retire openscap-daemon
Hi, I would like to retire openscap-daemon in Rawhide. This package isn't used by any other package. In past it was used as a plugin for Atomic scan which doesn't exist anymore. It has never been used in the original purpose as a compliance daemon. The upstream has been archived and there hasn't been any release in last 3 years. Therefore, I assume it's no longer useful for Fedora or its users. I plan to retire it in 1 week. If you want the package let me know before then. -- Jan Černý Security Technologies | Red Hat, Inc. ___ 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 a lot of (mostly) Go packages owned by @fpokorny
> I you want all your golang packages reassigned to eclipseo, all you need is > to tell me to do it and I'll do it. That would be great. By all means. Thank you. Also, thank you eclipseo for taking care of the packages. Jan ___ 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 a lot of (mostly) Go packages owned by @fpokorny
Hi Robert-André, Checking the consul it looks like I need to create a ticket for all orphaned package to change their point of contact. Assuming the same holds for all other orphaned packages one ticket with request to change their PoC is more practical than creating one for each. Feel free to open the ticket. I will give my +1 wherever needed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Git-Repository] PR #1: 2137877 - test compatilibity patch for git 2.38.1.
adelton merged a pull-request against the project: `perl-Git-Repository` that you are following. Merged pull-request: `` 2137877 - test compatilibity patch for git 2.38.1. `` https://src.fedoraproject.org/rpms/perl-Git-Repository/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Git-Repository] PR #1: 2137877 - test compatilibity patch for git 2.38.1.
adelton opened a new pull-request against the project: `perl-Git-Repository` that you are following: `` 2137877 - test compatilibity patch for git 2.38.1. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Git-Repository/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging a cross-compilation environment (wasi-libc)
Hi Jun, "Jun Aruga (he / him)" writes: > Do you have a plan to create the RPM package for wasi-sdk[1]? Not really, since we already (almost) have it available :) The wasi-sdk consists of llvm toolchain (clang & friends) compiled so that it can emit WASM code, and the wasi-libc, which implements standard C library atop WebAssembly System Interface "syscalls". Fedora's clang is already capable of emitting wasm (`clang --target=wasm32-wasi -nostdlib …` works), so I see no need to package it again. The thing we are missing is the wasi-libc, which I aimed to package. In other words, packaging wasi-sdk seems redundant to me – you would have to maintain separate version of clang, while the Fedora one is already able to compile what you need. We still need the C lib. Unfortunately, recent NodeJS releases had me occupied pretty much entirely, so I was unable to work on this. I hope I can get back to it this week. Fingers crossed. > But I > feel it takes more than 60 minutes, and is still in progress. > I wonder how other program languages supporting WebAssembly manage > this situation. Yeah, building entire compiler toolchain takes a while :) I had a COPR of the WIP wasi-sdk, but I set it to expire automatically, so it is currently not available. I'll try to spin in back up today and send you a link, in case you want to start testing the Ruby stuff with it already. Have a nice day! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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: Packaging a cross-compilation environment (wasi-libc)
To better collaborate on this, I've pushed my working copy of the package to gitlab [1]. It's a bit experimental (i.e. it tries to use source-git [2] approach to development), but should allow any interested party to review what I'm doing :) Integration with COPR is on my TODO list. [1]: https://gitlab.com/khx/fedora/wasi-libc [2]: https://docs.fedoraproject.org/en-US/ci/source-git/ Florian Weimer writes: > You can try to replace the current version with dlmalloc 2.7.2, which > still comes with the previous public domain dedication: > > <https://gee.cs.oswego.edu/pub/misc/> > > We can also ask Doug Lea if he can go back to the previous public domain > dedication. I've got some comments on the wasi-libc issue that another malloc might work as well. Nevertheless, I'll try to contact Doug Lea with the explanation and see where that leads. Thanks! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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: Packaging a cross-compilation environment (wasi-libc)
Hello all again! Some good news: With a gentle poking [1], the wasi-libc now have a tagged version(s) - or at least tags corresponding to the version used in a WASI-SDK. That should help us better agreement on which version to use down the road. [1]: https://github.com/WebAssembly/wasi-libc/issues/317 Josh Stone writes: > It might be fine to share this, as long as you are not patching upstream > wasi-libc in some weird way. Rust's use is pretty minimal from vanilla > sources, and mostly only updated when we need compatibility to build > with a new Clang, in wasi-libc's Makefile "check-symbols" target. I'm hoping we will be able to build it as-is; the only thing I'm now currently patching is the Makefile, so that it picks up CFLAGS from the environment. These flags get filtered to only those applicable to the wasm32-wasi target. The main issue I'm fighting with currently is the CC0-licensed dlmalloc and it's possible replacement with the musl one. It seems that the dlmalloc is used mainly because it does not need a mmap-like capabilities on the system; WebAssembly does not provide that. I'm yet to succesfully compile the libc with any other malloc implementation – any help or pointers appreciated. I've also opened an inquiry about this upstream [3]; we'll see how that goes. [3]: https://github.com/WebAssembly/wasi-libc/issues/319 -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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: Inactive packagers to be removed after the F37 release
Do I get removed, while waiting for packages to be approved ? Have been waiting for a year, may take another ... Jan FAS copperi From: Ben Cotton Sent: Friday, August 19, 2022 2:59 PM To: Development discussions related to Fedora Subject: Re: Inactive packagers to be removed after the F37 release On Fri, Aug 19, 2022 at 1:18 AM Adam Williamson wrote: > > Can we handle that? Can you manually flag those cases to continue > through the process, or something? It's like 10,000 spoons, when all you need is removal from the packager group. But yes, I'm manually handling those cases. Right now, it's by putting them on a list of "people who will show up as active but have acked removal". I have plans for how that can be handled in the future without me keeping a separate list on my Todoist task. But for now I am (slowly) going through every comment on tickets to make sure that everything gets handled correctly. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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 ___ 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: glibc 2.36 and DT_HASH (preserving it for F37+)
On 8/21/22 12:44, Jakub Jelinek wrote: On Sun, Aug 21, 2022 at 12:05:11PM +0200, Jan Drögehoff wrote: It's Epic's fault. They must update their anti-cheat to use the modern API. More reports have come out claiming this also affects the game Shovel Knight[2] and the open source library libstrangle[3], there is the non 0 chance that there are more programs out there in the wild that this will break. It feels irresponsible of the glibc maintainers to suddenly respect the toolchains desired hash type when they haven't for years and then do it with little to no announcement resulting in broken software To be precise, everything in Fedora except glibc is only built with DT_GNU_HASH and no DT_HASH since July 2006, glibc has been an exception that has been built with both because of statically linked programs from 16+ years ago that wouldn't support it. I think its worth putting an emphasis on the fact that this was glibc intentionally ignoring the toolchain hash type and simply going with both and not something Fedora explicitly decided to do. If all they want is be able to interpose dlsym, they could just use dlvsym to look up the original sym, instead of diving into the hash tables. I do not think the change on glibcs part is bad, the hack was terrible to begin with but removing it broke the ABI and the lack of any announcement of it beforehand is now causing problems that distro maintainers and software developers have to deal with ___ 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: glibc 2.36 and DT_HASH (preserving it for F37+)
On 8/21/22 10:59, Vitaly Zaitsev via devel wrote: On 20/08/2022 21:42, Neal Gompa wrote: It seems that upstream glibc disabled support for generating DT_HASH tables for its libraries and binaries, which breaks Linux games that use Epic Games' Easy Anti-Cheat (EAC). DT_HASH was deprecated for 15+ years. We shouldn't take care of proprietary DRMs. Can you cite a source for this? Things like the gabi still list DT_HASH is mandatory[1] (though if it truly is is debatable). Its also worth mentioning that DT_GNU_HASH is not a drop in replacement for DT_HASH and had no standardization or specification to speak of so its hard to follow. Can we turn this back on for Fedora glibc until we can get Epic to make fixes for this and roll them out? -1 from me. It's Epic's fault. They must update their anti-cheat to use the modern API. More reports have come out claiming this also affects the game Shovel Knight[2] and the open source library libstrangle[3], there is the non 0 chance that there are more programs out there in the wild that this will break. It feels irresponsible of the glibc maintainers to suddenly respect the toolchains desired hash type when they haven't for years and then do it with little to no announcement resulting in broken software [1] https://refspecs.linuxfoundation.org/elf/gabi4+/ch5.dynamic.html [2] https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1212748397 [3] https://bugs.gentoo.org/show_bug.cgi?id=863863 ___ 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: Packaging a cross-compilation environment (wasi-libc)
Hi again, thanks for all the suggestions! I'm taking the AVR approach so far; if you want to play with my drafts, I have a experimental COPR: https://copr.fedorainfracloud.org/coprs/jstanek/wasi-libc/ I plan to open a proper Fedora Review request on Monday; right now, I'm a bit too tired to go through the bureaucracy Have a nice weekend! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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
Packaging a cross-compilation environment (wasi-libc)
Hi list,
in order to be able to compile WASM natively on Fedora,
I'm trying to package wasi-libc[1] to provide the Web Assembly System
Interface.
[1]: https://github.com/WebAssembly/wasi-libc
My trouble is that this is in essence a cross-compilation environment,
and I have zero experience in trying to package these.
Also, I did not have much luck in trying to find any related
documentation.
Some issues I have run into so far:
- This is a libc implementation, which would probably conflict with the
glibc package by default. Looking at musl, the solution seems to be to
install into `/usr/{target}` prefix (i.e. `/usr/wasm32-wasi/include`).
Not really sure how this works, any pointers appreciated.
- Clang seems to have issue with `-fstack-clash-protection` flag for the
`wasm32-wasi` target. What's the proper way to adjust these?
Any additional tips on cross-compilation support in Fedora would also be
appreciated :)
Thanks in advance for any help!
--
Jan Staněk
Software Engineer, Red Hat
jsta...@redhat.com irc: jstanek
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: Qt 5.15 update and changes to private API deps
čt 14. 7. 2022 v 19:29 odesílatel Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> napsal: > On 14/07/2022 14:59, Jan Grulich wrote: > > This means that all the upcoming releases of Qt 5 are meant to be bugfix > > releases and therefore no API/ABI changes are expected. For that reason > > we have decided to no longer depend on the exact version of Qt that apps > > were built against. > > Are you sure? Telegram Desktop previously had major GUI breakages > between patch version of Qt 5. I asked Qt upstream and they replied that > Qt doesn't have ABI compatibility even between patch releases. > > Telegram is not a great example, or rather it's a great example of an app that should always depend on the exact Qt version it was built against. They are using private API more than any other application with tons of custom implementations. I'm 100% sure Qt doesn't break ABI compatibility between patch releases for public API. Would you be a happy paying customer if they break ABI for a library you are paying for? With private API there is no such promise, but I don't think ABI breakages will happen at this point. Regards, Jan ___ 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
Heads-up: Qt 5.15 update and changes to private API deps
Hi, I'm now working on Qt 5.15.5 update in Rawhide. As you probably know, Qt 5.15 is the last major release of Qt 5 and all the development is now focused to Qt 6. This means that all the upcoming releases of Qt 5 are meant to be bugfix releases and therefore no API/ABI changes are expected. For that reason we have decided to no longer depend on the exact version of Qt that apps were built against. We did this with all the applications using Qt's private API and this resulted in ~80 packages that needed to be rebuilt everytime we did just a Qt bugfix update, making the whole update process complicated and long. This change should result in faster and more simple updates allowing us to bring newer Qt sooner as no one was really rushing to do Qt updates before for all the complexity. There are just a few packages where I'm going to keep this requirement as we want to be sure to not break anything. These are: *qt5-qtwebengine, deepin-qt5integration, deepin-qt5platform-plugins, qgnomeplatform, fcitx-qt5, kf5-frameworkintegration, plasma-integration, qt5ct and python-qt5.* If you believe your package should depend on the exact Qt version it was built against then let me know so I can change it back and put it on my list for future rebuilds. Let me know even in case you think your package doesn't need to be rebuilt and I listed it above. Bug for reference: https://pagure.io/fedora-kde/SIG/issue/215 Thank you. Regards, -- Jan Grulich, Senior Software Engineer, Desktop Team Red Hat ___ 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 ID and HTTPS
Kevin Fenzi writes: > On Thu, Feb 03, 2022 at 07:16:01AM -0800, Jan Staněk wrote: > > Hi list, > > > > tl;dr: Why is the Fedora ID server using HTTP communication by default? > > Fedora openid is using http because long ago when we started offering > openid users were 'http://username.id.fedoraproject.org' and thus were > tied to this identity. If we changed it, everyone using that openid > would be a new different person to whoever they were authenticating. That makes sense – thanks for the explanation! > Some things to note: > > * openid is old, most places have dropped it. > ... > > really these days you want to move to OIDC or the like. Probably, but this is not a new app, and given it's projected lifespan, I do not consider it worthwhile to redo the authentication method. Thanks for the insight! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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
Fedora ID and HTTPS
Hi list, tl;dr: Why is the Fedora ID server using HTTP communication by default? Some context: I was debugging a login process for the www.softwarecollections.org website, which utilizes Fedora ID. After pulling my hair for a bit, it turned out that the somewhere along the network road, any un-encrypted HTTP requests were getting blocked, while HTTPS requests were allowed. This causes the login process to timeout in the middle, since it tried to do OpenID discovery using HTTP. Now, I really do not understand how the OpenID is *supposed* to work, but unless I missed something, the HTTP requests were issued in reaction to initial response from the Fedora ID service. To put it differently, my app was instructed to issue next request in the process on HTTP, even if the original one was over HTTPS. AFAIK that requests is immediately 302'd to HTTPS afterwards, but given the network settings, I have never get that far. That got me wandering – why is the HTTPS not used in the communication by default? In other words, why are the URLs returned in responses from Fedora ID using HTTP instead of HTTPS, when the redirect suggests that HTTPS is preferred? As stated above, I have no real idea about how OpenID actually works, so link to the docs and "That's why" is considered a perfectly valid answer :) Preliminary thanks to anyone who takes the time to educate me on this! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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: [Sway] wlroots 0.15 update is coming to rawhide
Hi Aleksei, that's awesome news! Thanks for the continous work you do. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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: Is it okay to use /usr/bin/python again?
According to the guidelines its still required to change the shebang to python3 https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_shebangs Jan Jan 4, 2022 11:09:40 AM Florian Weimer : > Or is it still banned in Fedora? > > We have some scripts that are dual Python 2/Python 3, and Fedora tooling > forced us to carry a downstream-only patch to replace /usr/bin/python > with /usr/bin/python3. I'd like to remove this patch. > > Thanks, > Florian > ___ > 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 ___ 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: Orphaning python-bsddb3
As announced in the OP of this thread, I have now orphaned the package. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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: Orphaned packages looking for new maintainers
Most seem to come because of dependency of truth. I have not been able to take it due to lacking rights, so someone should take it for now and can transfer it to me once I have needed access rights. Jan fas: copperi From: Miro Hrončok Sent: Monday, November 22, 2021 2:12 PM To: devel-annou...@lists.fedoraproject.org ; Development discussions related to Fedora Subject: Orphaned packages looking for new maintainers The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2021-11-22.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change Java-WebSocketorphan 3 weeks ago PyPAM orphan, tmraz1 weeks ago arduino-ctags orphan 3 weeks ago asl orphan 3 weeks ago bitlbee-discord orphan 6 weeks ago bytelist lef, orphan 3 weeks ago cAudioorphan 6 weeks ago chaos-client go-sig, orphan 3 weeks ago chck fale, orphan, zvetlik3 weeks ago concurrent-trees hhorak, orphan 3 weeks ago conky-manager orphan 3 weeks ago couchdb orphan 3 weeks ago crlfuzz go-sig, orphan 3 weeks ago cuetools orphan 3 weeks ago dummy-test-package-rubino asaleh, orphan, packagerbot, 3 weeks ago patrikp, scoady, wwoods edac-utilsorphan 3 weeks ago elog orphan 6 weeks ago erlang-certifierlang-maint-sig, orphan 4 weeks ago erlang-cf erlang-maint-sig, orphan 4 weeks ago erlang-cth_readable erlang-maint-sig, orphan 4 weeks ago erlang-erlware_commonserlang-maint-sig, orphan 4 weeks ago erlang-eunit_formatters erlang-maint-sig, orphan 4 weeks ago erlang-exometer_core orphan 3 weeks ago erlang-hex_core erlang-maint-sig, orphan 4 weeks ago erlang-protobuffs orphan 3 weeks ago erlang-providers erlang-maint-sig, orphan 4 weeks ago erlang-relx erlang-maint-sig, orphan 4 weeks ago erlang-riak_api bowlofeggs, erlang-maint-sig,3 weeks ago orphan erlang-riak_core bowlofeggs, erlang-maint-sig,3 weeks ago orphan erlang-ssl_verify_fun erlang-maint-sig, orphan 4 weeks ago erlang-triq orphan 3 weeks ago fennelepel-packagers-sig, lua- 3 weeks ago packagers-sig, orphan forbidden-apisjvanek, orphan 3 weeks ago gdata-sharp moezroy, orphan, tpokorra3 weeks ago gfm orphan 6 weeks ago gnu-getoptdwalluck, mizdebsk, orphan 3 weeks ago golang-github-beevik-ntp go-sig, orphan 2 weeks ago golang-github-dgraph-io-badgerorphan 6 weeks ago golang-github-dgraph-io- orphan 6 weeks ago ristretto golang-github-ema-qdisc go-sig, orphan
Package review requests from games-sig
Forwarding following review requests on behalf of games SIG. Jan fas copperi From: Dennis Payne Sent: Thursday, November 18, 2021 3:51 PM To: Fedora Games Subject: [games-sig] Cataclysm: Dark Days Ahead Finally got the latest Cataclysm: Dark Days Ahead working. I've now adopted the package. Still looking for reviewers on two new packages. https://bugzilla.redhat.com/show_bug.cgi?id=2008736 https://bugzilla.redhat.com/show_bug.cgi?id=2010111 -- Dennis Payne du...@identicalsoftware.com https://mastodon.gamedev.place/@dulsi ___ Fedora Games SIG mailing list -- ga...@lists.fedoraproject.org To unsubscribe send an email to games-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ga...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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: Add a game grou;p to https://src.fedoraproject.org/groups
I see no reason not to do so. Jan From: Reon Beon via devel Sent: Thursday, November 18, 2021 5:48 AM To: devel@lists.fedoraproject.org Cc: Reon Beon Subject: Add a game grou;p to https://src.fedoraproject.org/groups https://src.fedoraproject.org/groups Thoughts? ___ 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 ___ 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
Orphaned package plantuml
PlantUML package is free to take. It has few open bugs, mostly related to Java dependencies and it needs an update from upstream. Otherwise it requires very low effort to maintain it, upstream is stable and friendly. https://plantuml.com/ https://src.fedoraproject.org/rpms/plantuml https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=plantuml=Fedora=Fedora%20EPEL Jan ___ 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
Intro and ownership of orphaned package.
My name is Jan Kuparinen I work as a DevOps engineer. In the past I have made rpm packages of a private project, so I have some idea of packaging progress. I have also made some contributions to various Fedora projects. I took a look at the orphaned package list for packages needing maintenance and found that https://src.fedoraproject.org/rpms/truth is in retired state, but is needed by quite a few other packages. There have been several commits in the last few weeks to the repo, so is this actually maintained? If indeed this package is in need of a maintainer, I think I can help with that. Jan Kuparinen FAS copperi copp...@fedoraproject.org ___ 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
Orphaning python-bsddb3
Hello all, I'm the current maintainer for the python-bsddb3. Recently, it FTBFS in Rawhide [1], and the upstream now considers it deprecated [2], replaced with the `berkeleydb` python package. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2019310 [2]: https://www.jcea.es/programacion/pybsddb.htm I have packaged the `bsddb3` back when I was also maintainer of libdb in Fedora. I no longer take care of it, and I'm not interested in packaging the newer bindings. I've reached out to libdb maintainer, and they are not interested either [3]. [3]: https://bugzilla.redhat.com/show_bug.cgi?id=2019310#c4 The only packages that require the python-bsddb3 packages seem to be: exaile (runtime and buildtime) gramps (runtime) python-zarr (buildtime only) The maintainers are CC'd; feel free to reach to me if you want to take over python-bsddb3. If not, be advised that I intend to orphan it in a week or two, and your package will probably need changes. Best regards, -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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
Self Introduction: Jan Baudisch
Hi, I am a computer science student from Germany and have used Fedora for at least 2 years by now. Using COPR I gained some experience in buidling packages but recently I wanted to try building packages conforming to the guidelines and getting them into Fedora. My interest is mostly in Rust and that is why I would like to contribute Rust packages. I already got started here: https://copr.fedorainfracloud.org/coprs/janbaudisch/rust/packages For now my main interest would be to get the Rocket framework packaged, as many projects rely on it and on the way I discovered some key Rust crates not packaged yet. I feel like some of them are ready for submission and will file the first review requests soon. Looking forward to working on this! Jan ___ 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: LLD compatibility package
> On Sat, Aug 21, 2021 at 7:55 PM Jan Drögehoff wrote: > > tstellar already answered in a different thread: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... I can understand if there is no compatibility package because there hasn't been a use for one though I don't know if thats really the case so I'm asking in case a reason for this has already been established and I simply didn't find it > Though if you know that your project is for sure not compatible with > lld 12, working with tstellar to create an lld12 compat package will > probably be the way to go (if that's possible). I don't think its worth creating an entire compatibility package for lld just for one package and I'm fine waiting > Fabio ___ 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
LLD compatibility package
I've been wondering for a while but I haven't had time to ask this, why is there no lld compatibility package? clang and llvm have them and only lld seems to lack it. I'd understand it if lld was just a linker but it also provides many libraries and development files that can have brekaing changes between releases. One package I maintain, zig, is currently halted because it depends on lld 12 (though I have not yet had time to test if it would work with lld 13 out of the box) and they only plan to update to 13 once LLVM 13 actually releases. ___ 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: Seemingly wrong FailsToInstall (unannounced soname bump: lld - liblldCore, liblldCommon etc.)
On 8/18/21 6:02 PM, Adam Williamson wrote: On Wed, 2021-08-18 at 17:21 +0200, Jan Drögehoff wrote: I've received 2 automated bugzilla reports for F35[1] and F36[2] that my package FailsToInstall. I tried to replicate this with a Fedora 35 and Rawhide VM created from the last known good ISOs provided by the nightly compose finder and found everything to be working as expected. Is there something I am overlooking or did the automatic process fall flat? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1994972 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1994961 I don't think the process is wrong, but rather your VMs were outdated. (Note this line in the report: "P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors.") It looks like lld got bumped to 13.0rc1 yesterday: https://koji.fedoraproject.org/koji/buildinfo?buildID=1819661 which probably wouldn't have made it into the package set in your VMs. So, you'll need to rebuild your packages against the new lld libs. Yeah that was it I completely missed the soname bump and because its not on the mirrors yet it obviously wouldn't cause a problem on a VM Thanks This looks like an unannounced soname bump, which is against the packaging policy. Tom, please remember to announce soname bumps in advance and co-ordinate with the packagers of packages that build against the library. We now have the multi-build update process you can use to handle soname bumps smoothly, and it would be a good idea to do this: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ ___ 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
Seemingly wrong FailsToInstall
I've received 2 automated bugzilla reports for F35[1] and F36[2] that my package FailsToInstall. I tried to replicate this with a Fedora 35 and Rawhide VM created from the last known good ISOs provided by the nightly compose finder and found everything to be working as expected. Is there something I am overlooking or did the automatic process fall flat? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1994972 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1994961 ___ 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
Review swap: rust-clang-ast
Hi all, one of my packages (newsboat) grew yet another rust dependency, and I need that dependency RPM reviewed [1]. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1974377 I'm willing to take a review in exchange, if you need any. Note that I tried to write directly to rust-sig ML, but that list is moderated and I do not know if anyone actually checks the queue :) If any Rust SIG members picks this one up, then I'm sorry for the double offer. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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: discord fedora .rpm and repo
It doesnt package discord but a script that does it for you Jun 12, 2021 12:55:32 PM Vitaly Zaitsev via devel : > On 11.06.2021 20:29, Jan Drögehoff wrote: >> - copr https://copr.fedorainfracloud.org/coprs/duskmourn/discord > > Non-free software cannot be packaged in COPR too as it violates Fedora legal > policy: > https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Shareware > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) > ___ > 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 ___ 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: discord fedora .rpm and repo
Made the mistake of hitting the wrong button and sending this just to Cătălin George Feștilă so I'm reposting this As its stand Discord cannot be put into the official fedora repositories due to it being proprietary software. But that hasn't stopped people from putting it in places you can install from Fedora - flatpak https://flathub.org/repo/appstream/com.discordapp.Discord.flatpakref - rpmfusion - copr https://copr.fedorainfracloud.org/coprs/duskmourn/discord the copr is of note because instead of packaging Discord directly it packages a systemd service that does it for you https://github.com/LaurentTreguier/Discord-installer Jan On 6/11/21 7:54 PM, Cătălin George Feștilă wrote: Dear team Dear team. I would like to know if anyone took care of integrating the discord application in the Fedora distribution? Do we have a repo for this application? On the official website, I saw packet deb and tar. Thank you. ___ 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 ___ 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
Review Request: icemon - A GUI monitor for Icecream
Hi, Review Request: icemon - A GUI monitor for Icecream https://bugzilla.redhat.com/show_bug.cgi?id=1965529 Spec URL: http://people.redhat.com/jkratoch/icemon.spec SRPM URL: http://people.redhat.com/jkratoch/icemon-3.3-6.fc34.src.rpm It should be very simple IMO, it is an unretirement. Thanks, Jan ___ 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: Replace SDL 1.2 with sdl12-compat using SDL 2.0 (Self-Contained Change proposal)
On 5/18/21 9:17 PM, Jan Drögehoff wrote: It uses the exact same code as SDL 1.2 which has a version for i386 systems with inline assembly so that might need some eyes looking at it. Actually scratch that I had misinterpreted a contributors response to the issue and it has a completely fresh implementation apologies ___ 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: Replace SDL 1.2 with sdl12-compat using SDL 2.0 (Self-Contained Change proposal)
On 5/18/21 12:45 PM, Kevin Kofler via devel wrote: Ben Cotton wrote: This Change proposes to replace SDL 1.2 with sdl12-compat, which uses SDL 2.0. FYI, it took me just a few minutes of casually browsing commits to spot a memory corruption bug in this code: https://github.com/libsdl-org/sdl12-compat/commit/4c5e3b22593c4b48ac8129ae2096af5c00569dd4#commitcomment-50963635 Opened an issue for it[1] and was correctly shortly after[2] It uses the exact same code as SDL 1.2 which has a version for i386 systems with inline assembly so that might need some eyes looking at it. [1] https://github.com/libsdl-org/sdl12-compat/issues/56 [2] https://github.com/libsdl-org/sdl12-compat/commit/dacb4cf935ba3a6faee53c67d8973e2b375a3fe9 ___ 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: Replace SDL 1.2 with sdl12-compat using SDL 2.0 (Self-Contained Change proposal)
On 5/17/21 9:53 PM, Vitaly Zaitsev via devel wrote: > On 17.05.2021 20:50, Jan Drögehoff wrote: >> the Steam runtime ships its own SDL 1.2 so I don't think anything >> will change on that front > > Steam was just an example. There are lots of other proprietary > applications and games without their own runtime. > Well in the case an application depends on the system libraries I would assume sdl12-compat to be a drop in solution. Back in 2019[1] Ryan Gordon showed that the original Unreal Tournament 2004 runs fine under the compatibility layer so I would assume the same for everything that doesn't depend on quirks or bugs. [1] https://youtu.be/3uVmUCuJpF4 ___ 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: Replace SDL 1.2 with sdl12-compat using SDL 2.0 (Self-Contained Change proposal)
On 5/17/21 7:29 PM, Vitaly Zaitsev via devel wrote: On 17.05.2021 16:19, Ben Cotton wrote: In order to help move SDL 1.2 games into the modern world, let's replace SDL 1.2 with sdl12-compat, which uses SDL 2.0. What about third-party **proprietary** games from Steam for example? the Steam runtime ships its own SDL 1.2 so I don't think anything will change on that front ___ 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: GNOME only: KeepassXC quirks
Hi, ne 2. 5. 2021 v 10:26 odesílatel David Edmundson napsal: > > > On Sat, 1 May 2021, 20:10 Jan Grulich, wrote: > >> >> so 1. 5. 2021 v 17:51 odesílatel Jonas Ådahl napsal: >> >>> On Sat, May 01, 2021 at 10:49:57AM -0400, Owen Taylor wrote: >>> > On Sat, May 1, 2021 at 10:09 AM Neal Gompa wrote: >>> > > >>> > > On Sat, May 1, 2021 at 9:48 AM Owen Taylor >>> wrote: >>> > > >>> > > I agree, do we know anyone who understands Mutter that could work >>> with >>> > > someone who understands Qt to figure this out? I've got a couple of >>> > > folks in mind who could help on the KDE side (who I've CC'd to this >>> > > email). >>> > >>> > Added Jonas Adahl (all things output), Carlos Garnacho (all things >>> > input) and Oliver Fourdan (compat problems expert) to the Cc:- one of >>> > them should be able to help. >>> > >>> > Since the context is trimmed, the thread here is: >>> > >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PZCV4KM5W2PI34GT2PK6QUGOVODVA6HW/ >>> >>> I have yet to find any recent bugs in mutter that causes issues that >>> happens only with Qt; last time I and Jan debugged some issues with >>> Dolphin and Kate resizing wierdly, there were still some Qt issues with >>> incorrectly committed surface state. I think he is still looking into >>> those. >>> >> >> Yes, still working on those, but I don't think this issue is relevant >> here. And I would really like to know whether the "unable to type... " >> issue is KeepassXC only thing, because so far I haven't seen it and didn't >> get any other report. >> >> >> >>> Some issues likely doesn't cause issues on kwin because kwin takes over >>> window decoration from Qt applications, meaning Qts inability to commit >>> correct state is papered over by the incorrect intermediate state not >>> existing, but for example oddly placed menus (that I have seen and can >>> reproduce) behave exactly the same in e.g. weston as in mutter. >>> >> > Oddly placed menus is something we hit with fractional scaling, it's a > known Qt bug. > > I'm unaware of issues with QtWayland committing invalid state. > > This is the weird resizing issue I mentioned here https://codereview.qt-project.org/c/qt/qtwayland/+/339395. It's happening when you move for example with a window from maximized state. I attached a debug output with some comments from Jonas when we were trying to investigate why it's happening. It doesn't happen in KDE Plasma as it doesn't use the shared memory backingstore (I think). I'm still trying to find out how to fix it. Regards, Jan [3002676,379] xdg_toplevel@30.configure(1271, 922, array) [3002676,386] xdg_surface@29.configure(10274) [3002678,052] -> wl_shm_pool@57.create_buffer(new id wl_buffer@54, 0, 2558, 1860, 10232, 0) buffer size: 1279 x 930 * 2 (scale) [3002692,047] -> xdg_surface@29.set_window_geometry(10, 10, 1271, 922) needs: 1271 + 10 x 922 + 10 sized buffer (1281 x 932, or 2562 x 1864) [3002692,131] -> xdg_surface@29.ack_configure(10274) [3002728,516] -> wl_surface@24.attach(wl_buffer@54, 0, 0) [3002728,530] -> wl_surface@24.commit() !! Committed impossible window geometry !! Mutter shrinks window geometry to work around, some how. [3002729,112] -> wl_shm_pool@44.create_buffer(new id wl_buffer@43, 0, 2582, 1884, 10328, 0) [3002750,509] -> wl_surface@24.commit() Committed large enough buffer, but window geometry is unchanged (not what Qt thinks) [3002750,717] xdg_toplevel@30.configure(1259, 910, array) This is probably a result of guess mutter made to work around the impossible window geometry. I.e. it remembered the 10,10 offset, but the window size was shrunk to 1269 x 920, which when you then add the 10,10 offset becomes 1259 x 910 ___ 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: GNOME only: KeepassXC quirks
pá 30. 4. 2021 v 13:29 odesílatel Otto Urpelainen napsal: > Germano Massullo kirjoitti 30.4.2021 klo 13.23: > > KeepassXC comaintainer here. > > > > There are many Fedora GNOME Wayland users experiencing quirks in using > > KeepassXC. Textboxes not showing text that is being written, other > > quirks with GNOME, etc. > > > > Upstream developers said many times that this only happen with Fedora > users. > > > > Myself I do use KDE Spin and I do not experience these issues (tested on > > Wayland too) > > > > I don't paste bugs titles since they are misleading > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1925130 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8) > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1954742 > > > > https://github.com/keepassxreboot/keepassxc/issues/5608 > > > > plus others that I cannot find again at the moment > > > > I would like to ask if you have any idea about why this happens on GNOME > > only (and not on other distros too) > > > > Octave is suffering from similar problems. I have reported this: > > https://bugzilla.redhat.com/show_bug.cgi?id=1954181 > > and also saw another issue where menus opened in strange places on the > screen, or even partially off-screen. I did not report that yet, because > I do know how to reproduce reliably. > > The best assumption I could produce was simply that Qt5 and Wayland do > not play well together. Maybe Gnome also needs to be involved. Is there > a distribution that has that combination, but does not have these problems? > > As far as I know, Qt 5 reached end of life when Qt 6 came out. To me it > seems unlikely that remaining Qt 5 Wayland problems will ever get fixed. > Is there some downside to forcing XWayland through QT_QPA_PLATFORM=xcb > for Qt 5 applications with problems on Wayland? > That's not true. Fixes are still happening in 5.15 and there is even a public repository for Qt 5.15 in KDE's Gitlab instance. Also, given that Qt6 is not really different from Qt5 that much (at least in QtWayland), then all fixes in Qt6 are easily backportable to Qt5, which is something I do quite often. Jan ___ 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: GNOME only: KeepassXC quirks
so 1. 5. 2021 v 17:51 odesílatel Jonas Ådahl napsal: > On Sat, May 01, 2021 at 10:49:57AM -0400, Owen Taylor wrote: > > On Sat, May 1, 2021 at 10:09 AM Neal Gompa wrote: > > > > > > On Sat, May 1, 2021 at 9:48 AM Owen Taylor wrote: > > > > > > I agree, do we know anyone who understands Mutter that could work with > > > someone who understands Qt to figure this out? I've got a couple of > > > folks in mind who could help on the KDE side (who I've CC'd to this > > > email). > > > > Added Jonas Adahl (all things output), Carlos Garnacho (all things > > input) and Oliver Fourdan (compat problems expert) to the Cc:- one of > > them should be able to help. > > > > Since the context is trimmed, the thread here is: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PZCV4KM5W2PI34GT2PK6QUGOVODVA6HW/ > > I have yet to find any recent bugs in mutter that causes issues that > happens only with Qt; last time I and Jan debugged some issues with > Dolphin and Kate resizing wierdly, there were still some Qt issues with > incorrectly committed surface state. I think he is still looking into > those. > Yes, still working on those, but I don't think this issue is relevant here. And I would really like to know whether the "unable to type... " issue is KeepassXC only thing, because so far I haven't seen it and didn't get any other report. > Some issues likely doesn't cause issues on kwin because kwin takes over > window decoration from Qt applications, meaning Qts inability to commit > correct state is papered over by the incorrect intermediate state not > existing, but for example oddly placed menus (that I have seen and can > reproduce) behave exactly the same in e.g. weston as in mutter. > That's a Qt issue, a known one, and it's probably about time to finally fix it for good so once I fix the resizing issue, I think I can look into this one as well. Jan ___ 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: GNOME only: KeepassXC quirks
Hi, pá 30. 4. 2021 v 12:30 odesílatel Germano Massullo < germano.massu...@gmail.com> napsal: > KeepassXC comaintainer here. > > There are many Fedora GNOME Wayland users experiencing quirks in using > KeepassXC. Textboxes not showing text that is being written, other quirks > with GNOME, etc. > > Upstream developers said many times that this only happen with Fedora > users. > > Myself I do use KDE Spin and I do not experience these issues (tested on > Wayland too) > > I don't paste bugs titles since they are misleading > > https://bugzilla.redhat.com/show_bug.cgi?id=1925130 > I haven't seen any other application having this issue and I've been using lots of Qt/KDE apps under GNOME. It might be an issue in KeepassXC as they have some custom theme. > https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8) > CentOS doesn't really use Qt Wayland by default. > https://bugzilla.redhat.com/show_bug.cgi?id=1954742 > Again, can be a KeepassXC issue as any other application I've been using doesn't have such problem. > https://github.com/keepassxreboot/keepassxc/issues/5608 > This is the same issue as the first one (about missing focus). There is only one issue I'm aware of and that's misplaced popups/menus. There is a bug in Qt opened for it https://bugreports.qt.io/browse/QTBUG-68636 and it's the only one blocking upstream decision to switch to Wayland by default. I know that there might be some other issues in certain apps, but those issues would be really specific to those apps given their implementation and would need to be probably fixed case by case. I think it's something I can look into for Fedora 35, but reverting this change to use xcb by default will result in not having properly/natively scaled apps in GNOME. Btw. even KDE flatpak runtime uses Wayland by default on GNOME. Regards, Jan ___ 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's GPG key in DNS(SEC)
On 3/10/21 1:32 PM, Petr Menšík wrote: I think Björn's point is valid note. Because DNSSEC is used to verify email of used key, but fedora.repo does not contain any hint about how email in GPG key should look like. Also does not contain fingerprint of such key. It would be nice to include email of included GPG key in repo file itself. If actual email in GPG did not match, dnf would refuse such key unless explicitly requested by user. What if we added to repos: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch gpgkeyid=mailto:fedora-$releasever-prim...@fedoraproject.org This way dnf could map DNSSEC validated email to repository. It would be user-verifiable, when he or she would add a new repository downloaded from any site. Excuse me if I am overthinking this, but "from any site" is that detail wherein the proverbial devil is, I think. I'd say you would want DNF to a priori realize that the domain part from said "gpgkeyid=" indeed (partially) matches the domain you obtained this very repo file from (prior to redirections[*]) be it either in the form of "dnf install .rpm" or hypothetical "--repofromrepopath" counterpart of "--repofrompath" command (since baseurl= can generally differ from where you obtain the repo from, but the same logic could be applied when that's not the case). In turn, that would restrict the location from where you can obtain the repo file smoothly without alerts to only the domain(s) stricly bound to the domain used in the address within gpgkeyid= (creating thus a concept of authoritative repo file source). That would apply on the surfacing URL only[*]. Otherwise, I think someone could be tricked to start from installing https://rpmfusion-mirror.seams-leg.it/rpmfusion-free-release.noarch.rpm and crafted gpgkeyid= in the installed repo would not exactly help. Of course, applies only to cases of entirely foreign by then repositories, like RPM Fusion (use case: visit its web [DNS must have been trusted already], follow the instructions here, be spared from a fraudulent mirror right from the start). For Fedora (Linux) incremental versions, there should really be some kind of a seamless "rolling trust" mechanism as discussed in other part of the above message. [*] feels like a compromise of redirect chain would still be captured with the whole mechanism, but I might have missed something/a lot -- Jan (poki) ___ 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: Review swap: newsboat rust dependencies
Hi, Jerry James wrote: > I took them all. Thanks! Your OCaml packages should now be also reviewed, althoug Dan has beaten me to #1927441 :) -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek OpenPGP_signature Description: OpenPGP digital signature ___ 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
Review swap: newsboat rust dependencies
Hi all, I maintain newsboat [1], which in the latest version(s) grew new rust dependencies. I have prepared a review request for all of them, and I'm willing to review other packages in return. The reviews are the following bugs: 1927183, 1927210, 1927248, 1927353, 1927362, 1927385, 1927763, 1927790 All of them are generated with rust2rpm, so the review should be a quick one. Note however that they might depend on one another – I suggest using the TreeView+ in bugzilla to see their relations. As a rule of thumb, lower numbers generally needs to be reviewed/built before a higher one could begin. Thanks in advance to the brave soul(s) that are willing to pick this up :) [1]: https://newsboat.org -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek OpenPGP_signature Description: OpenPGP digital signature ___ 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: Proposal to deprecated `fedpkg local`
Hi, please don't force me to change my workflow which I'm using regularly without having any benefit from it. -- Jan Horak On 1/27/21 5:17 PM, Vít Ondruch wrote: Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? Vít ___ 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 ___ 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
Self Introduction: Jan Zerdik
Hi. My name is Jan and I'm a new red hatter. I'll be a TuneD co-maintainer. My experience with open source projects is mostly just as a user, but I'm looking forward to joining the community. ___ 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: Change in glibc about _STAT_VER in Fedora rawhide?
On Fri, Nov 27, 2020 at 12:28:36PM +0100, Florian Weimer wrote: > * Jan Pazdziora: > > >> There's a Fedora-specific hack in rawhide glibc to bring back the > >> __xstat and related symbols for linking. This in the process of being > >> upstreamed. > > > > Does that include __fxstatat64? And is the hack already in > > glibc-2.32.9000-16.fc34 or is it on the way to rawhide? > > Looking at the current rawhide buildroot, it's already there: > > # eu-readelf --symbols=.dynsym /lib64/libc.so.6 | grep __fxstat64 > 1059: 000f1880 84 FUNCGLOBAL DEFAULT 15 > __fxstat64@@GLIBC_2.2.5 > > The @@ means it's available for linking. Nod, I see it there. What would you recommend to software that wants to compile against these symbols? -- Jan Pazdziora | adelton at #security, #brno Product Owner, Platform Security Readiness, Red Hat ___ 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: Change in glibc about _STAT_VER in Fedora rawhide?
On Wed, Nov 25, 2020 at 11:57:38AM +0100, Florian Weimer wrote: > * Jan Pazdziora: > > > it seems that both fakeroot and fakechroot fail to build in Fedora > > rawhide (at least partially) because _STAT_VER is no longer declared > > in the current glibc (or rather, its headers): > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1889862 > > https://bugzilla.redhat.com/show_bug.cgi?id=1901049 > > > > The bugzillas are filed against their respective components but > > I wonder if we have any guidance from the glibc point of view about > > how these components should proceed. Or is the loss of _STAT_VER an > > omission and will it come back? > > _STAT_VER will not come back, these packages have to define the value > locally. glibc won't add any _STAT_VER values. Thank you. So do you recommend for fakechroot to hardcode something like --- a/src/libfakechroot.h +++ b/src/libfakechroot.h @@ -224,4 +224,14 @@ int fakechroot_try_cmd_subst (char *, const char *, char *); int snprintf(char *, size_t, const char *, ...); #endif +#ifndef _STAT_VER +#if defined (__aarch64__) +#define _STAT_VER 0 +#elif defined (__x86_64__) +#define _STAT_VER 1 +#else +#define _STAT_VER 3 +#endif +#endif + #endif for all the arches? > There's a Fedora-specific hack in rawhide glibc to bring back the > __xstat and related symbols for linking. This in the process of being > upstreamed. Does that include __fxstatat64? And is the hack already in glibc-2.32.9000-16.fc34 or is it on the way to rawhide? -- Jan Pazdziora | adelton at #security, #brno Product Owner, Platform Security Readiness, Red Hat ___ 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
Change in glibc about _STAT_VER in Fedora rawhide?
Hello, it seems that both fakeroot and fakechroot fail to build in Fedora rawhide (at least partially) because _STAT_VER is no longer declared in the current glibc (or rather, its headers): https://bugzilla.redhat.com/show_bug.cgi?id=1889862 https://bugzilla.redhat.com/show_bug.cgi?id=1901049 The bugzillas are filed against their respective components but I wonder if we have any guidance from the glibc point of view about how these components should proceed. Or is the loss of _STAT_VER an omission and will it come back? -- Jan Pazdziora Product Owner, Platform Security Readiness, Red Hat ___ 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
Orpahing notepadqq
Hi list, Due to limited/no movement in the upstream[1] and more and more dependencies (nodejs packages) being orphaned within Fedora, I'm planning to orphan notepadqq. If someone wants to step up and try to get it back working, let me/Sagitter know. Kind regards, Jan [1] https://github.com/notepadqq/notepadqq/commits/master___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages
I orphaned my packages, feel free to take them: https://src.fedoraproject.org/rpms/arpwatch https://src.fedoraproject.org/rpms/compat-guile18 https://src.fedoraproject.org/rpms/emacs https://src.fedoraproject.org/rpms/environment-modules https://src.fedoraproject.org/rpms/ghc-pipes-safe https://src.fedoraproject.org/rpms/iputils https://src.fedoraproject.org/rpms/logwatch https://src.fedoraproject.org/rpms/numad https://src.fedoraproject.org/rpms/perl-Sys-MemInfo https://src.fedoraproject.org/rpms/purple-plugin_pack https://src.fedoraproject.org/rpms/sgpio https://src.fedoraproject.org/rpms/xinetd -- Jan Synacek Software Engineer, Red Hat ___ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On Mon, 28 Sep 2020 17:58:58 +0200, Jakub Jelinek wrote: > On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote: > > On Mon, 28 Sep 2020 17:35:26 +0200, Jakub Jelinek wrote: > > > A way out of this could be either to use comdat .debug_info etc. sections > > > (but that would result in quite large increase of *.o file sizes), or let > > > the linker or a tool like DWZ discard or simplify such DIEs. > > > I don't see how could you see at compile time that the linker will not > > > choose the particular copy. > > > > Another option is to use clang which should have such optimization > > implemented > > soon: > > https://whova.com/embedded/session/llvm_202010/1193947/ > > If you do it on the compiler side, you'll get a lot of those pesky partial > units you so hate on the lldb side. No. The LLVM patches from Sony are using COMDAT groups you mentioned above: https://youtu.be/oSCbzLC46Vg?t=312 Jan ___ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On Wed, 07 Oct 2020 09:58:37 +0200, Jan Kratochvil wrote: > On Wed, 07 Oct 2020 00:46:24 +0200, Jeff Law wrote: > > On 9/30/20 3:50 AM, Jan Kratochvil wrote: > > > When we start talking about RHEL (and CentOS) DWZ is completely pointless > > > then > > > as DWZ there saves only 0.28% of *-debuginfo.rpm (20MB of 7.2GB). > > > Therefore approx. 0.14% of the distribution size. > > > > Umm, we're fighting with PM these days over things in the 10M range. > > So it is better to slow down getting a finally usable debugger by years to > save 10MB of distro size? I really do not believe that. :-) I think you mean 10MB of normal rpm size. That is important for containers and other small devices. But the 20MB are only *-debuginfo.rpm size, those are only for developer machines. Developer machines are not concerned by 20MB. Jan ___ 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
