[SONAME BUMP] ffmpeg upgrade from v6 to v7
Hey folks, The Fedora Multimedia SIG is beginning the effort to upgrade to ffmpeg v7 in Rawhide. So far, this is what I've determined to be the list of reverse dependencies: alsa-plugins-1.2.12-2.fc41.src.rpm aqualung-1.2-7.fc41.src.rpm atomes-1.1.14-3.fc41.src.rpm attract-mode-2.7.0-12.fc41.src.rpm audacious-plugins-4.4-4.fc41.src.rpm blender-4.2.1-3.fc42.src.rpm cantata-2.5.0-5.fc41.src.rpm chromaprint-1.5.1-18.fc41.src.rpm chromium-128.0.6613.137-1.fc42.src.rpm digikam-8.4.0-3.fc41.src.rpm ffmpeg-6.1.2-1.fc42.src.rpm ffmpegthumbnailer-2.2.2-2.20240105git1b5a779.fc41.src.rpm ffmpegthumbs-24.08.0-1.fc42.src.rpm goldendict-ng-24.05.05-3.fc41.src.rpm gpac-2.4.0-3.fc42.src.rpm gstreamer1-plugin-libav-1.24.7-1.fc42.src.rpm guacamole-server-1.5.5-2.fc41.src.rpm guvcview-2.1.0-3.fc41.src.rpm haruna-1.2.0-1.fc42.src.rpm indi-3rdparty-drivers-2.0.9-1.fc42.src.rpm k3b-24.08.0-1.fc42.src.rpm kf5-kfilemetadata-5.116.0-3.fc41.src.rpm kf6-kfilemetadata-6.6.0-1.fc42.src.rpm kpipewire-6.1.90-1.fc42.src.rpm libcamera-apps-1.5.0-3.fc41.src.rpm libopenshot-0.3.3-3.fc41.src.rpm minidlna-1.3.3-8.fc41.src.rpm mlt-7.28.0-1.fc42.src.rpm mpv-0.38.0-3.fc41.src.rpm mpv-mpris-1.1-4.fc42.src.rpm musescore-4.3.2-13.fc41.src.rpm neatvnc-0.8.1-1.fc41.src.rpm notcurses-3.0.9-4.fc41.src.rpm obs-cef-5060^cr103.0.5060.134~git20231010.17f8588-6.fc41.src.rpm obs-studio-30.2.2-1.fc41.src.rpm opencv-4.10.0-1.fc41.src.rpm pianobar-2022.04.01-9.fc41.src.rpm python-torchvision-0.19.0-2.fc42.src.rpm qmmp-2.1.9-1.fc41.src.rpm qmmp-plugin-pack-2.1.2-1.fc41.src.rpm qmplay2-24.06.16-2.fc41.src.rpm qt5-qtwebengine-5.15.17-9.fc42.src.rpm qt6-qtmultimedia-6.7.2-2.fc41.src.rpm qt6-qtwebengine-6.7.2-3.fc41.src.rpm retroarch-1.19.0-5.fc41.src.rpm rsgain-3.5.2-1.fc41.src.rpm siril-1.2.4-1.fc42.src.rpm squeezelite-2.0.0.1486-5.20240508gitfd4a82e.fc41.src.rpm timg-1.6.0-5.fc41.src.rpm unpaper-7.0.0-10.fc41.src.rpm vlc-3.0.21-7.fc42.src.rpm waypipe-0.9.1-2.fc42.src.rpm wf-recorder-0.4.0-6.fc41.src.rpm wxsvg-1.5.25-2.fc41.src.rpm xine-lib-1.2.13-16.fc41.src.rpm xpra-5.0.6-4.fc42.src.rpm xscreensaver-6.09-2.fc41.src.rpm The Multimedia SIG will be building everything in the f42-build-side-96586 side tag. I have already addressed the ffmpeg->chromaprint->ffmpeg bootstrap cycle in the side tag, so now it's just building the rest of them. We hope to have this all done over the coming days. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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] dracut-103 soon in Fedora Rawhide
On Thu, Sep 19, 2024 at 4:13 PM Pavel Valena wrote: > > Hi! > > $SUBJ > > PRs: > https://src.fedoraproject.org/rpms/dracut/pull-request/65 > https://src.fedoraproject.org/rpms/dracut/pull-request/64 > > Please let me know if anything breaks! > It doesn't look like you actually *built* it yet? https://koji.fedoraproject.org/koji/packageinfo?packageID=8714 -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: "The Bugzilla review bug creator didn't match the requester in Pagure."
On Thu, Sep 19, 2024 at 7:18 AM Richard W.M. Jones wrote: > > My sponsoree(?) Min Lei has a completed review request: > > https://bugzilla.redhat.com/show_bug.cgi?id=2305524 > > However creating the new branch is a problem: > > https://pagure.io/releng/fedora-scm-requests/issue/67376 > "The Bugzilla review bug creator didn't match the requester in Pagure." > > This is speculation, but I think this may be related to him creating a > new Fedora account as apparently the password for the old account was > lost & couldn't be recovered for some reason: > > Old account: https://accounts.fedoraproject.org/user/minlei/ > New account: https://accounts.fedoraproject.org/user/minlei2/ > > What can he do about this? > Request the old account gets disabled. That can be requested in https://pagure.io/fedora-infrastructure (We really need a reset flow so creating new accounts isn't required in this scenario.) > Actually I'm surprised that the person who files the bug has to be the > same person who requests the branch. There seems no reason for that > restriction. > The reason is fairly simple: it's the only way we can authenticate the request in a reasonably automated way. Otherwise human validation is required to ensure it's not something worse. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Request for help for packaging new potential Workstation default apps
Hey folks, The Fedora Workstation WG is considering replacing several preloaded apps with alternatives: * Rhythmbox -> (gnome-music + Decibels[1]) or Amberol[2] * Evince -> Papers[3] * Totem -> Showtime[4] Of these apps, only Papers has a currently active package review[5]. The Fedora Workstation WG would like some help from interested Fedora Workstation users to contribute to the success of the Fedora Workstation offering by packaging these applications in Fedora. Members of the Working Group can help review packaging by anyone who takes this on to package the applications in a manner consistent with the Fedora packaging guidelines and general practices. If anyone is interested, please let us know and we can work out arrangements to assist new contributors. :) [1]: https://gitlab.gnome.org/GNOME/Incubator/decibels (TypeScript) [2]: https://gitlab.gnome.org/World/amberol (Rust) [3]: https://gitlab.gnome.org/GNOME/Incubator/papers (C + Rust) [4]: https://gitlab.gnome.org/GNOME/Incubator/showtime (Python) [5]: https://bugzilla.redhat.com/show_bug.cgi?id=2305882 -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Integrate FEX in Fedora Linux (Self-Contained)
On Fri, Sep 13, 2024 at 9:05 PM Michel Lind wrote: > > On Thu, Sep 12, 2024 at 04:50:39PM +0100, Aoife Moloney wrote: > > == Scope == > > * Proposal owners: > > ** DONE: Package [https://github.com/FEX-Emu/FEX FEX] in Fedora Linux > > - https://src.fedoraproject.org/rpms/fex-emu > > ** WIP: Create a [https://pagure.io/fedora-kiwi-descriptions/ Kiwi > > definition] to produce a FEX root filesystem - > > https://pagure.io/fedora-kiwi-descriptions/pull-request/83 > > ** TODO: Package the root filesystem in Fedora Linux as an RPM > > ** DONE: Package > > [https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/vm_tools/sommelier/ > > sommelier] -- https://src.fedoraproject.org/rpms/chromiumos-platform > > ** TODO: Package [https://github.com/slp/krun krun] > > ** TODO: Integrate FEX with krun to support 16k page-size systems > > ** TODO: Create a comps group for FEX and supporting components > > ** TODO: Attach the comps group to the kde-desktop-environment group > > Is there a reason this will get preinstalled only for KDE? Is that > only because it's the Fedora Asahi default desktop, or are there > actually some desktop integration that is harder to achieve on other > desktops? > Mostly the former, but it also ties into some future target work for Fedora KDE too, so it makes sense to ship there. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Integrate FEX in Fedora Linux (Self-Contained)
On Fri, Sep 13, 2024 at 7:25 PM Rob Clark wrote: > > On Thu, Sep 12, 2024 at 8:53 AM Aoife Moloney wrote: > > > > Wiki - https://fedoraproject.org/wiki/Changes/FEX > > Discussion Post - > > https://discussion.fedoraproject.org/t/f42-change-proposal-integrate-fex-in-fedora-linux-self-contained/131147 > > > > This is a proposed Change for Fedora Linux. > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > > > > > == Summary == > > [https://fex-emu.com/ FEX] is a fast emulator that allows one to run > > x86 and x86-64 binaries on an AArch64 Linux host. FEX requires a > > number of supporting components, including a RootFS image, and > > integration with krun to support 16k page-size hosts. The purpose of > > this Change is to integrate FEX itself and its supporting components > > into Fedora Linux, to provide a delightful out-of-box experience for > > users that want to run x86 and x86-64 binaries on their aarch64 > > systems. This also includes integration into the AArch64 Fedora KDE > > spin as a non-blocking component of the spin. > > Hopefully the krun integration is only used when the host page size is not 4k? > I think that's the idea, but yes, we should try to make sure that's the case. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Anaconda WebUI Partitioning (System-Wide)
On Thu, Sep 12, 2024 at 8:02 PM Przemek Klosowski via devel wrote: > > On 9/12/24 12:12, Aoife Moloney wrote: > > Anaconda will replace root and should have a possibility to > > preserve /home with user data. > > This is great, but in a default setup /home is just a btrfs subvolume. > Would this method be able to preserve /home while recreating the system > part, in the 2-subvolume scenario? > "2-subvolume scenario"? We already split root and home into separate subvolumes, and Cloud images even split var into its own subvolume too. > A related question: when rebuilding because of a failed btrfs, the > recommendation is to reinstall on a brand new filesystem, and restore > /home from backup. If anaconda could easily preserve /home, maybe the > default should be switched back to separate / and /home, so that when / > is damaged but /home isn't the system rebuild is easier? > It doesn't really change much when everything is on the same disk, and just reintroduces the space contention issues we intentionally wanted to eliminate. As it stands, the subvolumes are separate hierarchies and can be independently managed today, but share the same pool of disk space. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: abrt to be retired from F41 one week before the final freeze
On Wed, Sep 11, 2024 at 12:57 PM Neal Gompa wrote: > > On Wed, Sep 11, 2024 at 12:14 PM Miro Hrončok wrote: > > > > Hello, > > > > according to the policy: > > > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs > > > > The abrt package will be retired one week before the Fedora 41 final freeze, > > due to https://bugzilla.redhat.com/show_bug.cgi?id=2295150 > > > > Are we ready to ditch abrt, or is somebody planning to solve this (e.,g. by > > dropping the python3-abrt-container-addon subpackage only)? > > > > I've made a fix and will submit an update to Bodhi for the bug. > This is now submitted: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b5e0e43e8c -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: abrt to be retired from F41 one week before the final freeze
On Wed, Sep 11, 2024 at 12:14 PM Miro Hrončok wrote: > > Hello, > > according to the policy: > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs > > The abrt package will be retired one week before the Fedora 41 final freeze, > due to https://bugzilla.redhat.com/show_bug.cgi?id=2295150 > > Are we ready to ditch abrt, or is somebody planning to solve this (e.,g. by > dropping the python3-abrt-container-addon subpackage only)? > I've made a fix and will submit an update to Bodhi for the bug. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Updating xorg-x11-server
On Fri, Sep 6, 2024 at 1:47 PM Sérgio Basto wrote: > > On Thu, 2024-09-05 at 18:54 +0200, Neal Gompa wrote: > > My understanding is the reason we hadn't was because of the NVIDIA > > binary driver. For the desktops that still use X11 and the X11 DDX > > instead of the modesetting driver, that could be a problem if the ABI > > broke. > > Here it says, some NVIDIA binary driver needs X11 DDX , that why I > wrote that seems possible re-add X11 DDX > > https://www.phoronix.com/news/DMX-DDX-Dropping-2021 > https://www.phoronix.com/news/X.Org-DMX-Dropped > > https://gitlab.freedesktop.org/xorg/xserver/-/commit/b3b81c8c2090cd49410960a021baf0d27fdd2ab3 DDX refers to Device-Dependent-X11 driver, the NVIDIA driver provides its own binary module for it. Of course, it's also not necessary if the NVIDIA driver exposes kernel modesetting, then the regular modesetting DDX that Xorg uses by default should be sufficient. DMX is something else entirely. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Updating xorg-x11-server
On Thu, Sep 5, 2024 at 5:30 PM Simone Caronni wrote: > > Hi Sergio, > > On Thu, Sep 5, 2024 at 5:26 PM Sérgio Basto wrote: >> >> I already did the PR >> >> https://src.fedoraproject.org/rpms/xorg-x11-server/pull-request/21 >> >> https://copr.fedorainfracloud.org/coprs/sergiomb/xorg-x11-server/builds/ > > > Yes, that's the merge request I was mentioning. > My understanding is the reason we hadn't was because of the NVIDIA binary driver. For the desktops that still use X11 and the X11 DDX instead of the modesetting driver, that could be a problem if the ABI broke. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Summary/Minutes from today's FESCo Meeting (2024-09-03)
= # #meeting:fedoraproject.org: fesco = Meeting started by @conan_kudo:matrix.org at 2024-09-03 17:02:28 Meeting summary --- * TOPIC: Init Process (@conan_kudo:matrix.org, 17:03:21) * TOPIC: #3264 Incomplete Changes Report for Fedora Linux 41 (@conan_kudo:matrix.org, 17:07:52) * TOPIC: Taskwarrior 3 (@conan_kudo:matrix.org, 17:09:15) * LINK: https://fedoraproject.org/wiki/Changes/Taskwarrior3 (@conan_kudo:matrix.org, 17:09:29) * AGREED: This is in progress and on-track. As it is self-contained and not on any deliverable media, FESCo permits this to land whenever, but it is deferred as a Change if it lands after Final Freeze. (+7, 0, -0) (@conan_kudo:matrix.org, 17:17:05) * TOPIC: Switch to dnf5 (@conan_kudo:matrix.org, 17:17:43) * LINK: https://fedoraproject.org/wiki/Changes/SwitchToDnf5 (@conan_kudo:matrix.org, 17:17:50) * ACTION: dcantrell will follow up with the DNF team on getting a status update. We will revisit this next week. (@conan_kudo:matrix.org, 17:27:21) * ACTION: dcantrell to ask the DNF team to update the Change tracker with the latest status (@sgallagh:fedora.im, 17:27:25) * TOPIC: Next week's chair (@conan_kudo:matrix.org, 17:28:09) * ACTION: Fabio Valentini will chair the next meeting (@conan_kudo:matrix.org, 17:33:31) * TOPIC: Open Floor (@conan_kudo:matrix.org, 17:33:42) * AGREED: Resuming generation of retired deliverables requires a new Change. For the Phosh request, FESCo would like them to make a Change for Fedora 42 to restart production of the images. (+8, 0, -0) (@conan_kudo:matrix.org, 17:44:00) * INFO: The above agreed statement is for a request by the Mobility SIG to restart production of Phosh images. (@conan_kudo:matrix.org, 17:45:04) * LINK: https://pagure.io/fesco/issue/3265 (@conan_kudo:matrix.org, 17:45:17) * INFO: The Raspberry Pi platform makes up the bulk of our blocker bugs this cycle. The most significant issues are graphics oriented with GTK4 and v3dv not working well together. František Zatloukal is working on filing bug reports with gtk and mesa on this. (@conan_kudo:matrix.org, 18:21:47) * ACTION: Conan Kudo will try to help adamw find people to look into and assist fixing the various bugs discovered this cycle. (@conan_kudo:matrix.org, 18:22:23) Meeting ended at 2024-09-03 18:26:58 Action items * dcantrell will follow up with the DNF team on getting a status update. We will revisit this next week. * dcantrell to ask the DNF team to update the Change tracker with the latest status * Fabio Valentini will chair the next meeting * Conan Kudo will try to help adamw find people to look into and assist fixing the various bugs discovered this cycle. People Present (lines said) --- * @conan_kudo:matrix.org (90) * @sgallagh:fedora.im (54) * @adamwill:fedora.im (31) * @nirik:matrix.scrye.com (19) * @salimma:fedora.im (18) * @zodbot:fedora.im (16) * @dcantrell:fedora.im (14) * @jistone:fedora.im (10) * @humaton:fedora.im (7) * @decathorpe:fedora.im (6) * @ankursinha:fedora.im (4) * @meetbot:fedora.im (3) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Schedule for Tuesday's FESCo Meeting (2024-09-03)
On Tue, Sep 3, 2024 at 11:45 AM Neal Gompa wrote: > > Following is the list of topics that will be discussed in the > FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org > on Matrix. > And of course I mean Tuesday in the subject, not Thursday. Which is today. -- Neal Gompa (FAS: ngompa) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Schedule for Thursday's FESCo Meeting (2024-09-03)
Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-09-03 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Go 1.22 in Fedora 39 https://pagure.io/fesco/issue/3261 APPROVED (+5, 0, -0) = Followups = #3264 Incomplete Changes Report for Fedora Linux 41 https://pagure.io/fesco/issue/3264 = New business = N/A = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
License corrected for Weston (BSD and CC-BY-SA -> MIT and CC-BY-SA-3.0)
Hey all, As an FYI, Weston's licensing was corrected when I upgraded it to 14.0.0~rc3 (13.0.95) to "MIT and CC-BY-SA-3.0" (from the previous "BSD and CC-BY-SA"). I expect this has no meaningful impact for anyone. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Need volunteers to pick up my packages incl. wf-recorder and wayvnc
On Thu, Aug 29, 2024 at 3:09 AM Bob Hepple wrote: > > so that just leaves: > > bookworm > i3blocks > src > wf-recorder > > ... any takers? > I'll take wf-recorder, too. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Need volunteers to pick up my packages incl. wf-recorder and wayvnc
On Wed, Aug 28, 2024 at 11:58 PM Bob Hepple wrote: > > Due to lack of time, I need to hand over these packages. I thought I'd > put it here rather than just becoming 'unresponsive'. > I'd be happy to take over aml, clipman, lavalauncher, libevdevPlus, libuInputPlus, neatvnc, nwg-wrapper, swappy, wayvnc, wdisplays, web, wl-gammactl, wlogout, wlr-sunclock, wob, wshowkeys, ydotool. All these things are used by various Wayland-y things I care about anyway. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 m2crypto
Hey all,
I've just orphaned m2crypto. I and a couple of other folks tried to
fix it this cycle and it's too difficult for us to deal with. I have
no need for this anymore, and upstream is moribund and more or less
recommending people to port away from it.
Here's the list of reverse dependencies from DNF:
ngompa@fedora ~> dnf rq --qf "%{SOURCERPM}" --whatrequires "python3-m2crypto"
dmlite-1.15.2-21.fc41.src.rpm
dnsviz-0.10.0-3.fc41.src.rpm
fts-rest-client-3.13.2-1.fc41.src.rpm
hash-slinger-3.2-5.fc41.src.rpm
module-build-service-3.9.2-9.fc41.src.rpm
oz-0.18.1-15.fc41.src.rpm
ursa-major-0.4.2-12.fc41.src.rpm
If you need it, be aware that it's also busted from the OpenSSL engine
API deprecation Change too, so that needs fixing up as well.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: How to contact Fedora Security Team
On Sun, Aug 18, 2024 at 8:16 AM Andrew Bauer wrote: > > I've got a question regarding a new crypto library that falls under this > policy: > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/ > > Per the documentation, I should contact the Fedora Security Team, but > unfortunately the link provided in the documentation is no good: > https://lists.fedoraproject.org/mailman/listinfo/security > > This points to a list that no longer exists. What is a good way to ping this > team? Thank you. The URL is wrong, it is: https://lists.fedoraproject.org/admin/lists/security.lists.fedoraproject.org/ That said, the list is inactive and the formal security team disbanded many years ago. You may want to check the Matrix room, which does have some activity: https://matrix.to/#/#security:fedoraproject.org -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Upcoming libpkgconf soname bump in Rawhide
On Sat, Aug 17, 2024 at 9:12 AM Matthew Krupcale wrote:
>
> On Fri, Aug 16, 2024 at 10:59 PM Neal Gompa wrote:
> >
> > On Tue, Aug 13, 2024 at 7:09 AM Neal Gompa wrote:
> > >
> > > On Wed, Aug 7, 2024 at 5:32 AM Neal Gompa wrote:
> > > >
> > > > On Wed, Aug 7, 2024 at 4:49 AM Fabio Valentini
> > > > wrote:
> > > > >
> > > > > On Wed, Aug 7, 2024, 10:28 Neal Gompa wrote:
> > > > >>
> > > > >> Hey all,
> > > > >>
> > > > >> pkgconf 2.3.0 just released and the jump from 2.1.1 to 2.3.0 brings
> > > > >> with us a soname bump. I will be updating pkgconf and rebuilding
> > > > >> dependents in a side-tag, and hopefully get everything done later
> > > > >> today.
> > > > >>
> > > > >> The identified packages are:
> > > > >> * build2
> > > > >> * perl-PkgConfig-LibPkgConf
> > > > >>
> > > > >> I identified them with the following commands:
> > > > >> * dnf rq --qf "%{SOURCERPM}" --whatrequires
> > > > >> "libpkgconf.so.4()(64bit)"
> > > > >> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf"
> > > > >>
> > > > >> If there are any I missed, please let me know and I will add it to my
> > > > >> list of packages to build.
> > > > >
> > > > >
> > > > > I might be misremembering, but weren't odd-numbered minor releases
> > > > > "unstable" and shouldn't be packaged because they might break ABI?
> > > > > Which was a problem with 2.1 when we added that version?
> > > > >
> > > >
> > > > No, the soname bump happened in 2.2.0. We're just getting it now
> > > > because I'm upgrading to 2.3.0. Only GNOME libraries follow that
> > > > convention of breaking things on odd number versions.
> > > >
> > > >
> > > >
> > > > --
> > > > 真実はいつも一つ！/ Always, there's only one truth!
> > >
> > >
> > >
> > > --
> > > 真実はいつも一つ！/ Always, there's only one truth!
> > >
> > > Hey all,
> > >
> > > I've been able to take care of everything except build2, and I'm not
> > > sure why it's broken. Could someone take a look at it and submit it to
> > > f41-build-side-93739?
> > >
> > > Here's the task:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=121891824
> > >
> >
> > Another ping to request for help with build2. It's not building
> > properly and if it isn't able to get fixed in the next couple of days,
> > I will merge the side-tag without it and it will need to be fixed
> > independently.
>
> Hey Neal,
>
> Sorry I missed this. Go ahead and merge the side tag. Upstream build2
> upstream now bundles a forked version of pkgconf [1, 2], and I just
> need to update to the latest version still. I'll try and finish that
> this weekend.
>
> Best,
> Matthew
>
> [1] https://github.com/build2/build2/issues/381#issuecomment-2099699208
> [2] https://lists.build2.org/archives/users/2024-June/001117.html
>
Alright, this is done now.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Upcoming libpkgconf soname bump in Rawhide
On Tue, Aug 13, 2024 at 7:09 AM Neal Gompa wrote:
>
> On Wed, Aug 7, 2024 at 5:32 AM Neal Gompa wrote:
> >
> > On Wed, Aug 7, 2024 at 4:49 AM Fabio Valentini wrote:
> > >
> > > On Wed, Aug 7, 2024, 10:28 Neal Gompa wrote:
> > >>
> > >> Hey all,
> > >>
> > >> pkgconf 2.3.0 just released and the jump from 2.1.1 to 2.3.0 brings
> > >> with us a soname bump. I will be updating pkgconf and rebuilding
> > >> dependents in a side-tag, and hopefully get everything done later
> > >> today.
> > >>
> > >> The identified packages are:
> > >> * build2
> > >> * perl-PkgConfig-LibPkgConf
> > >>
> > >> I identified them with the following commands:
> > >> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf.so.4()(64bit)"
> > >> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf"
> > >>
> > >> If there are any I missed, please let me know and I will add it to my
> > >> list of packages to build.
> > >
> > >
> > > I might be misremembering, but weren't odd-numbered minor releases
> > > "unstable" and shouldn't be packaged because they might break ABI? Which
> > > was a problem with 2.1 when we added that version?
> > >
> >
> > No, the soname bump happened in 2.2.0. We're just getting it now
> > because I'm upgrading to 2.3.0. Only GNOME libraries follow that
> > convention of breaking things on odd number versions.
> >
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
> Hey all,
>
> I've been able to take care of everything except build2, and I'm not
> sure why it's broken. Could someone take a look at it and submit it to
> f41-build-side-93739?
>
> Here's the task: https://koji.fedoraproject.org/koji/taskinfo?taskID=121891824
>
Another ping to request for help with build2. It's not building
properly and if it isn't able to get fixed in the next couple of days,
I will merge the side-tag without it and it will need to be fixed
independently.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Early adopting EPEL 10 in Fedora Copr?
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup wrote: > > The epel-8-* and epel-9-* chroots in Fedora Copr are aliases > to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd > like to have the same approach for `epel-10` once there's a released > variant of RHEL 10 GA. > > For now though, there's the variant `centos-stream+epel-10` in the new > mock-core-configs release, though: > > https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1 > > So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the > time being, and do the switch to `rhel+epel-10` later on. Do you think > this makes sense? Or is it just too early? > For EPEL 10, we would never do that switch. CentOS Stream + EPEL is the default case for EPEL 10 now. RHEL + EPEL configs are the alternative. So we would just have the alias and keep it "forever". -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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)
On Wed, Aug 14, 2024 at 10:30 AM Marcus Müller wrote: > > Hi! > > I've got a question regarding > https://fedoraproject.org/wiki/Changes/SwitchToDnf5#Background_service_support > : > > > A new daemonized service, dnf5daemon, utilizing the D-Bus interface, is > prepared for > clients as a sub-package. This will serve as an alternative or replacement > for the > PackageKit layer. Integration of dnf5daemon support into the default Fedora > user > interface, GNOME Software, is currently in progress > > So, is moving away from PackageKit and doing its own, distro-specific > abstraction daemon, > the goal here? > > I ask because I remarked, a while back, in > https://github.com/rpm-software-management/dnf5/discussions/924 that > PackageKit > integration is paramount for users of shell "command-not-found" functionality. > The intent is to have a dnf5 PackageKit backend too. It hasn't been started because the API wasn't stabilized enough to start work on. It should be settling down now, though. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Upcoming libpkgconf soname bump in Rawhide
Hey all,
I've been able to take care of everything except build2, and I'm not
sure why it's broken. Could someone take a look at it and submit it to
f41-build-side-93739?
Here's the task: https://koji.fedoraproject.org/koji/taskinfo?taskID=121891824
On Wed, Aug 7, 2024 at 5:32 AM Neal Gompa wrote:
>
> On Wed, Aug 7, 2024 at 4:49 AM Fabio Valentini wrote:
> >
> > On Wed, Aug 7, 2024, 10:28 Neal Gompa wrote:
> >>
> >> Hey all,
> >>
> >> pkgconf 2.3.0 just released and the jump from 2.1.1 to 2.3.0 brings
> >> with us a soname bump. I will be updating pkgconf and rebuilding
> >> dependents in a side-tag, and hopefully get everything done later
> >> today.
> >>
> >> The identified packages are:
> >> * build2
> >> * perl-PkgConfig-LibPkgConf
> >>
> >> I identified them with the following commands:
> >> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf.so.4()(64bit)"
> >> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf"
> >>
> >> If there are any I missed, please let me know and I will add it to my
> >> list of packages to build.
> >
> >
> > I might be misremembering, but weren't odd-numbered minor releases
> > "unstable" and shouldn't be packaged because they might break ABI? Which
> > was a problem with 2.1 when we added that version?
> >
>
> No, the soname bump happened in 2.2.0. We're just getting it now
> because I'm upgrading to 2.3.0. Only GNOME libraries follow that
> convention of breaking things on odd number versions.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Upcoming libpkgconf soname bump in Rawhide
On Wed, Aug 7, 2024 at 4:49 AM Fabio Valentini wrote:
>
> On Wed, Aug 7, 2024, 10:28 Neal Gompa wrote:
>>
>> Hey all,
>>
>> pkgconf 2.3.0 just released and the jump from 2.1.1 to 2.3.0 brings
>> with us a soname bump. I will be updating pkgconf and rebuilding
>> dependents in a side-tag, and hopefully get everything done later
>> today.
>>
>> The identified packages are:
>> * build2
>> * perl-PkgConfig-LibPkgConf
>>
>> I identified them with the following commands:
>> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf.so.4()(64bit)"
>> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf"
>>
>> If there are any I missed, please let me know and I will add it to my
>> list of packages to build.
>
>
> I might be misremembering, but weren't odd-numbered minor releases "unstable"
> and shouldn't be packaged because they might break ABI? Which was a problem
> with 2.1 when we added that version?
>
No, the soname bump happened in 2.2.0. We're just getting it now
because I'm upgrading to 2.3.0. Only GNOME libraries follow that
convention of breaking things on odd number versions.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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
Upcoming libpkgconf soname bump in Rawhide
Hey all,
pkgconf 2.3.0 just released and the jump from 2.1.1 to 2.3.0 brings
with us a soname bump. I will be updating pkgconf and rebuilding
dependents in a side-tag, and hopefully get everything done later
today.
The identified packages are:
* build2
* perl-PkgConfig-LibPkgConf
I identified them with the following commands:
* dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf.so.4()(64bit)"
* dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf"
If there are any I missed, please let me know and I will add it to my
list of packages to build.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: dnf5 can't remove some qemu packages on rawhide
On Tue, Aug 6, 2024 at 10:32 AM Richard W.M. Jones wrote: > > On Tue, Aug 06, 2024 at 12:40:33AM -0700, Gordon Messmer wrote: > > root@localhost:~# dnf install kiwi-cli > > ... > > > > root@localhost:~# dnf5 remove kiwi-cli > > Failed to resolve the transaction: > > Problem: The operation would result in removing the following > > protected packages: grub2-efi-ia32, grub2-efi-x64 > > Does it work if you add --noautoremove ? > > > root@localhost:~# rpm -q dnf5 rpm > > dnf5-5.2.5.0-2.fc41.x86_64 > > rpm-4.19.92-6.fc41.x86_64 > > > > I get the error that removing a package would remove grub2 when I > > try to remove qemu-user-static-x86-9.0.0-2.fc41.x86_64, > > qemu-user-static-arm-9.0.0-2.fc41.x86_64, > > qemu-user-static-aarch64-9.0.0-2.fc41.x86_64, but not any of the > > other qemu-user-static packages that kiwi pulls in. > > I am able to remove qemu-user-static-arm (even without > --noautoremove), so I suspect the dependency path could be something > else starting from kiwi. > > I have the same versions of qemu & dnf5 here. > I'm not sure why removing kiwi-cli is triggering this, but I can answer what's going on. This is the dependency relationship: kiwi-cli -> python3-kiwi -> kiwi-systemdeps -> kiwi-systemdeps-disk-images -> kiwi-systemdeps-bootloaders -> grub2-efi-x64 and grub2-efi-ia32 However, uninstalling kiwi-cli should not trigger this error. It should just uninstall all parts of the set that are not protected, since not autoremoving something should not be a critical failure. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: egl-wayland, egl-gbm and eglexternalplatform
On Thu, Aug 1, 2024 at 6:59 PM Leigh Scott wrote: > > I have decided to orphan these packages as they are useless replacements for > the nvidia driver provided libs. > The rpmfusion 560+ driver will use the bundled libs. > > I believe it's time fedora dropped eglstream support. > Thanks for your efforts maintaining this. I've picked up the packages as they are still needed for now. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: flatpak vs pkg-config system libdir
On Thu, Aug 1, 2024 at 9:13 AM Owen Taylor wrote: > > Hi Neal - > > Daniel's original suggestion here (make pkg-config always look in /app too) > actually seems fine to me and simple, and I don't see any downsides. But > certainly flatpak-rpm-macros doesn't *just* modify RPM macros, it currently > also: > > - Changes the installation prefix for Python by dropping a distutils.cfg > - Adds a configuration file for Maven to change install and search paths > > So it's sort of a more general "flatpak-rpm-build" environment. If there was > a way to set PKG_CONFIG_PATH globally for the buildroot upon install of the > package, that could work too. (Or, yes, we could set FLATPAK_RPM_BUILD and > make pkg-config react to that). But how would you do that? mock --chroot > doesn't seem to pick things up from /etc/profile.d or /etc/environment. > > The only way I can think of doing it would be by configuring rpm.env.* for > the Flatpak build tags in Koji, and losing the property that you can "just" > drop flatpak-rpm-macros in to get the Flatpak RPM build environment. Do you > see any other way? > Well, if you have a general package that's shipped in every buildroot for flatpak builds, you can ship your own wrapper, and I can make it check if RPM_BUILD_ROOT is defined *and* this file exists, it would redirect to that wrapper automatically. Or some variation of this. We used to do something similar for MinGW, I believe, so I think it'd work. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: flatpak vs pkg-config system libdir
On Tue, Jul 9, 2024 at 9:38 AM Daniel P. Berrangé wrote:
>
> There have been a number of PRs[1] opened to workaround problems
> with pkg-config not finding .pc files when dependencies have
> been built in flatpak context.
>
> Normally pkg-config would always find .pc files in any system
> dirs. ie
>
> /usr/local/lib64/pkgconfig
> /usr/local/share/pkgconfig
> /usr/lib64/pkgconfig
> /usr/share/pkgconfig
>
> but when a package is built as a flatpak, there are additional
> system dirs defined
>
> /app/lib64/pkgconfig
> /app/share/pkgconfig
>
> and an apps' .pc files go into /app, rather than /usr.
> pkg-config / pkgconf is not searching those by default.
>
> flatpkg-rpm-macros overrides the definition of %___build_pre
> to set PKG_CONFIG_PATH to point to the /app tree.
>
> This only works when cases where pkg-config is invoked under
> the RPM %build section. Fine for the normal build process
> stage.
>
> It fails, though, if an RPM spec needs to call pkg-config
> separately from %build. eg if doing
>
> %define wireshark_plugindir %(pkg-config --variable plugindir
> wireshark)/epan
>
>
> The proposed fix in the PRs is to add a call to %___build_pre
> for any invokation of 'pkg-config' in spec files.
>
> Functionally that works, but to me this feels like a suboptimal
> approach.
>
> I tend to view /app/{lib64,share}/pkgconfig as being standard
> system libdirs, and thus would expect pkg-config to automatically
> search them, without requiring PKG_CONFIG_PATH to be set.
>
> Is there a reason we can't build pkgconfig such that it includes
> the /app dirs out of the box.
>
> AFAICT, such a change should not negatively affect normal Fedora
> builds since the /app dirs won't exist, and would make pkg-config
> "do the right thing" in Flatpak context, avoiding whack-a-mole
> fixing of RPMs to call %___build_pre
>
> Incidentally is %___build_pre a macro we can rely on long term ?
>
> Is there any rule for what the different number of leading "_"
> mean in macros ? ie are macros with three leading _ still fair
> game to reference in specs, or are they considered an unstable
> impl detail that's subject to change ?
>
Note that pkg-config(1) is already a wrapper:
https://src.fedoraproject.org/rpms/pkgconf/blob/rawhide/f/pkg-config.in
It points to a multi-arch wrapper too:
https://src.fedoraproject.org/rpms/pkgconf/blob/rawhide/f/platform-pkg-config.in
If there's a variable that always exists when building Flatpaks, we
can use that to automatically reconfigure the PKG_CONFIG_PATH as
appropriate.
If such a variable doesn't already exist, we should add something to
make it so, because Flatpak builds have enough differences that it's
useful to be able to propagate that into the build environment anyway.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: GRUB2 rebase (from 2.06 to 2.12) landing soon on rawhide
On Thu, Jul 18, 2024 at 10:56 AM Leo Sandoval wrote: > > > > On Wed, Jul 10, 2024 at 4:11 AM Andrea Bolognani wrote: >> >> On Wed, Jun 19, 2024 at 11:02:57AM GMT, Andrea Bolognani wrote: >> > On Tue, May 21, 2024 at 10:57:42AM GMT, Leo Sandoval wrote: >> > > Hi team, >> > > >> > > We (the Red Hat bootloader team) are completing the work of >> > > rebasing/reviewing/testing current rawhide patches, from GRUB2 2.06 to >> > > 2.12, so at >> > > some point in the near future these would land finally into rawhide. Once >> > > everything is in place, we would like your help to start testing the >> > > package and report any boot issue found. >> > > >> > > If there is any concern on this work, please let me know. >> > >> > Any updates on this? >> > >> > Me and the other folks working on RISC-V support are eagerly waiting >> > for this rebase, since 2.06 can't do UEFI boot on the architecture. >> >> Hi, >> >> still looking for an update on the progress. > > > Hi Andrea & team, > > sorry for the delay in my response :( > > We have completed the rebase task (including some NX patches that were not > included in the first phase) and currently the corresponding packages are in > the QA phase (also internal RHEL work). As indicated in the first email, all > work is based on Fedora rawhide and the intention is to land all this work at > least in Fedora 41 and RHEL 10.0. > > Again, once we have something solid, I will share relevant links for further > community reviewing & testing. > Any progress on this? We're gearing up to Flock and branching will be the week after Flock... -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: FedoraWorkstation default firewall rules unsafe
On Sun, Jul 28, 2024 at 8:40 AM Chuck Anderson wrote: > > On Sun, Jul 28, 2024 at 12:49:51PM GMT, Arthur Bols via devel wrote: > > Sure. But why do those ports need to be open by default at all? What is > > the benefit of adding those extra 2 lines? Does it enhance user > > friendliness? I doubt it, as users will still need to open ports for > > e.g. slp or mdsn. What it does is put users at risk. > > dhcpv6-client, samba-client, and ssh are opened by default. Perhaps > mdns should be added to this list. > > > I wouldn't have this conversation if we had no firewall rules like arch > > or Debian, but we do. We even go as far as install and enable Firewalld > > by default. As far as I know Fedora is positioning itself as a > > beginner-friendly Linux distro, thus we should strive to protect users. > > Enabling a firewall that blocks traffic up to port 1024 is strange and > > confusing, especially for security minded beginners. > > Historically, "privileged services" run on ports 0-1024. The idea was > to protect those privileged services, while keeping 1025-65535 open > for developers to develop applications using those ports. Unfortunately nowadays privileged production-grade services run by default on ports above 1024, so the distinction is somewhat meaningless. :( -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Enable Drm Panic (system-wide)
On Tue, Jul 23, 2024 at 8:32 AM Jocelyn Falempe wrote: > > Hi, > > It's no longer necessary to disable VT_CONSOLE to enable DRM_PANIC. > So I have updated the wiki page, and also moved it to > self-contained-change, as there are no more system-wide impact by > enabling DRM_PANIC. > > I've also made a new kernel build, with VT_CONSOLE and DRM_PANIC > enabled, so you can check by yourself that it works: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=120743811 Awesome, thank you! -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 rawhide (to be f41) and openssl engines
On Mon, Jul 22, 2024 at 8:57 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jul 22, 2024 at 01:34:39PM +0200, Dmitry Belyavskiy wrote: > > So I wonder if it's worth changing the engine deprecation mechanism in > > Fedora to the one we have in CentOS and if yes, what is the mechanism > > for such a change. > > Does is make sense at this point? The mass rebuild is (almost?) finished > and I would expect that packages that needed to be updated for this > already were. > > Do you have any statistics about how many packages still fail to > build because of the lacking header file? > The CentOS approach isn't a deprecation, it's flat out removal. It's a completely different change. Is anyone helping to migrate users of the engine API to newer APIs? If that's not happening, then there's no way to support removing the engine API from Fedora's OpenSSL. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On Thu, Jul 18, 2024 at 3:39 AM Miro Hrončok wrote: > > On 18. 07. 24 1:30, Neal Gompa wrote: > > You are conflating license tag conversion with a license audit. Tag > > conversion is explicitly*not* an audit exercise. > > No, I state the old GPL tags and the new GPL identifiers have different > meanings. > This is not the case. Even going back to the beginning when the case was first made and all the identifiers were being categorized, all the GNU license tags we had for the Fedora system were matched 1:1 to the SPDX ones. They do not have different meanings. That the form of how GNU license identifiers differ from how we did it before is why I *explicitly* asked and got confirmation about when it happened. Everyone was forced to deal with it when SPDX deprecated the "+" modifier and the associated GNU license tags that used it. The *only* actual difference between "time of Fedora identifiers" and "time of now" is that we have this quest to use SPDX identifiers everywhere and our ability to simplify *informational* license tags has been removed. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On Wed, Jul 17, 2024 at 7:14 PM Miro Hrončok wrote: > > On 17. 07. 24 22:15, Neal Gompa wrote: > > On Wed, Jul 17, 2024 at 3:41 PM Miroslav Suchý wrote: > >> > >> Dne 17. 07. 24 v 6:41 odp. Miro Hrončok napsal(a): > >> > >>> Done. > >> > >> Hi Mirek, > >> I am a bit confused. > >> > >> I thought there was a clear nonconsensus about the *GPL conversion [1] > >> which resulted to the FESCo ticket [2]. It is kinda surprising to see the > >> "Done." comment here and in the LGPL thread as well. > >> > >> [1] > >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5VAL3I26A4ACWCXWWFHTKV6OXO2GISZ/ > >> [2] https://pagure.io/fesco/issue/3230 > >> > >> Ouch, now I am confused too. > >> > >> You are right that the final wording is: > >> > >>> !agreed FESCo is in favor of standardizing on the SPDX format and > >>> understands that not all licenses are ready for direct conversion. Those > >>> licenses that are unreviewed or otherwise not yet fully compliant should > >>> be converted to SPDX licenses of the format LicenseRef- >>> indicating Fedora legacy>-* where * is the old Fedora identifier. (+8, 1, > >>> -0) > >> > >> which means that I should stop doing that 1:1 (aka trivial) conversion and > >> convert *everything* to LicenseRef-Callaway-*. But I was on that meeting - > >> and if you read the log: > >> > >> https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-16/fesco.2024-07-16-17.00.log.html > >> > >> There was: > >> > >> <@sgallagh:fedora.im> > >> 17:52:01 > >> Proposal: FESCo is in favor of standardizing on the SPDX format and > >> understands that not all licenses are ready for this. Those that are not > >> should be converted to SPDX licenses to a format `LicenseRef- >> indicating Fedora legacy>-*` where "*" is the old format. > >> > >> ... > >> <@msuchy:matrix.org> > >> 17:52:24 > >> Can I have a clear statement what to do with GPL* ? > >> > >> <@zbyszek:fedora.im> > >> 17:54:04 > >> The whole point is to convert everything. > >> <@conan_kudo:matrix.org> > >> 17:54:08 > >> nirik: it'd be GPLv2 -> GPL-2.0-only, GPLv2+ -> GPL-2.0-or-later > >> <@conan_kudo:matrix.org> > >> 17:54:20 > >> and so on > >> <@zbyszek:fedora.im> > >> 17:54:22 > >> Otherwise, it's not syntactically valid. > >> <@salimma:fedora.im> > >> 17:54:26 > >> sorry, I mixed up msuchy's question with Neal's original response > >> <@nirik:matrix.scrye.com> > >> 17:54:32 > >> but then we have 0 way to tell what was converted? I guess we could look > >> at commits > >> <@conan_kudo:matrix.org> > >> 17:54:56 > >> after everything is said and done, audits still need to be done separately > >> <@conan_kudo:matrix.org> > >> 17:55:00 > >> don't mistake conversions for audits > >> <@salimma:fedora.im> > >> 17:55:05 > >> we might need a second vote to clarify what to do with ambiguous licenses > >> > >> <@salimma:fedora.im> > >> 17:58:24 > >> so Stephen's new proposal is quite clear that every legacy license we > >> can't convert to SPDX would be marked as LicenseRef--* ... I think > >> that addresses the ambiguity > >> > >> So I'd say that Neal statement in 17:54:08 put me in mistake that I should > >> continue with 1:1 but it is not in the final decision/statement. > >> > > > > What you're doing is what we expected in FESCo. GNU license > > identifiers *are* trivial conversions. The main ones that aren't are > > the older "BSD" and "MIT" ones, which have no meaningful analogue in > > SPDX. > > That is your opinion. My opinion differs: > > The *GPL conversions *are not* trivial because they may hide several other > "weaker" licenses in them following the old rules, which is no longer allowed > by the new rules that were created when we approved the entire SPDX thing. > > --- > > The disagreement on this is what spawned the discussion and the FESCo ticket > in > the first place. > > If FESCo wanted to autoconvert all the ol
Re: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On Wed, Jul 17, 2024 at 3:41 PM Miroslav Suchý wrote: > > Dne 17. 07. 24 v 6:41 odp. Miro Hrončok napsal(a): > > > Done. > > Hi Mirek, > I am a bit confused. > > I thought there was a clear nonconsensus about the *GPL conversion [1] which > resulted to the FESCo ticket [2]. It is kinda surprising to see the "Done." > comment here and in the LGPL thread as well. > > [1] > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5VAL3I26A4ACWCXWWFHTKV6OXO2GISZ/ > [2] https://pagure.io/fesco/issue/3230 > > Ouch, now I am confused too. > > You are right that the final wording is: > > > !agreed FESCo is in favor of standardizing on the SPDX format and > > understands that not all licenses are ready for direct conversion. Those > > licenses that are unreviewed or otherwise not yet fully compliant should be > > converted to SPDX licenses of the format LicenseRef- > Fedora legacy>-* where * is the old Fedora identifier. (+8, 1, -0) > > which means that I should stop doing that 1:1 (aka trivial) conversion and > convert *everything* to LicenseRef-Callaway-*. But I was on that meeting - > and if you read the log: > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-16/fesco.2024-07-16-17.00.log.html > > There was: > > <@sgallagh:fedora.im> > 17:52:01 > Proposal: FESCo is in favor of standardizing on the SPDX format and > understands that not all licenses are ready for this. Those that are not > should be converted to SPDX licenses to a format `LicenseRef- indicating Fedora legacy>-*` where "*" is the old format. > > ... > <@msuchy:matrix.org> > 17:52:24 > Can I have a clear statement what to do with GPL* ? > > <@zbyszek:fedora.im> > 17:54:04 > The whole point is to convert everything. > <@conan_kudo:matrix.org> > 17:54:08 > nirik: it'd be GPLv2 -> GPL-2.0-only, GPLv2+ -> GPL-2.0-or-later > <@conan_kudo:matrix.org> > 17:54:20 > and so on > <@zbyszek:fedora.im> > 17:54:22 > Otherwise, it's not syntactically valid. > <@salimma:fedora.im> > 17:54:26 > sorry, I mixed up msuchy's question with Neal's original response > <@nirik:matrix.scrye.com> > 17:54:32 > but then we have 0 way to tell what was converted? I guess we could look at > commits > <@conan_kudo:matrix.org> > 17:54:56 > after everything is said and done, audits still need to be done separately > <@conan_kudo:matrix.org> > 17:55:00 > don't mistake conversions for audits > <@salimma:fedora.im> > 17:55:05 > we might need a second vote to clarify what to do with ambiguous licenses > > <@salimma:fedora.im> > 17:58:24 > so Stephen's new proposal is quite clear that every legacy license we can't > convert to SPDX would be marked as LicenseRef--* ... I think that > addresses the ambiguity > > So I'd say that Neal statement in 17:54:08 put me in mistake that I should > continue with 1:1 but it is not in the final decision/statement. > What you're doing is what we expected in FESCo. GNU license identifiers *are* trivial conversions. The main ones that aren't are the older "BSD" and "MIT" ones, which have no meaningful analogue in SPDX. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: sbin-merge: what to do?
On Tue, Jul 16, 2024 at 11:13 AM Adam Williamson wrote: > > On Tue, 2024-07-16 at 08:08 +0100, Daniel P. Berrangé wrote: > > On Mon, Jul 15, 2024 at 05:07:57PM -0700, Kevin Fenzi wrote: > > > On Mon, Jul 15, 2024 at 08:23:05AM GMT, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > So… the question now: should I pull the plug on the change for F41, > > > > dump the side tag, and try again for F42? Or wait for some of the > > > > patches > > > > above to be merged? The mass rebuild is supposed to start in two days… > > > > > > How hard would it be to move back to the old state? > > > Does that mean a bunch of reverts and rebuilds? or ? > > > > Assuming there was nothing impactful outside of the mentioned side tag, > > then no rebuilds should be required, just abandon the tag, and do > > dist-git reverts. > > > > > It sounds to me like there's still a lot of outstanding questions, so I > > > would say moving it to f42 (and trying to land it after branching in > > > rawhide) would be best, but that depends somewhat on how hard the revert > > > is... if it's hard it might be better to power on through? > > > > Agree it sounds like the wise thing to do is to postpone to F42, to give > > further time to fully explore the implications. If done right at the > > start of the F42 dev cycle, there'll be a greater window for finding > > and resolving any fallout before the F42 beta freeze point. > > Yeah, +1 to this. What concerns me about the openQA experience so far > is the broad range of issues we hit, including ones that were kinda > 'coincidental' (not actually the thing the test was trying to test). > Since openQA is nowhere close to comprehensive, this implies more weird > failures will show up even once it passes all the openQA update tests, > and we will need time to identify and fix those. I will note that unless this is done right after F41 is branched from Rawhide, we won't actually have a lot of time to get it sorted out. Spring Fedora releases have a lot less time than fall ones because of all the holidays leading up to it. So this needs to be planned to be started again *right* after branching completes to maximize time to fix things. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Enable Drm Panic (system-wide)
On Tue, Jul 16, 2024 at 8:35 AM Jocelyn Falempe wrote: > > > > On 16/07/2024 14:05, Neal Gompa wrote: > > On Tue, Jul 16, 2024 at 7:49 AM Jocelyn Falempe wrote: > >> > >> I've made a test kernel build with drm_panic enabled (and VT_CONSOLE > >> disabled): > >> > >> https://koji.fedoraproject.org/koji/taskinfo?taskID=120544794 > >> > >> I've backported a few patches, that are not in v6.10, like: > >> short panic description: > >> https://patchwork.freedesktop.org/series/135356/ > >> kmsg panic_screen: > >> https://patchwork.freedesktop.org/series/134286/ > >> draft nouveau support (tested on 1650X, might be garbage on other GPU): > >> https://patchwork.freedesktop.org/series/133963/ > >> And also virtio-gpu support, so you can test it easily on a VM. > >> > >> To install the test kernel, download the rpms kernel, kernel-core, > >> kernel-modules, kernel-modules-core, kernel-modules-extra, and install > >> them with dnf. > >> It's a Fedora rawhide kernel, but can be installed on F40. > >> > >> i915, amdgpu, and nvidia are not yet supported, so you need to blacklist > >> them, in order to use simpledrm, if you want to see the panic screen. > >> > > > > Do you expect to see the rest of the drivers supported by the time > > Fedora 42 rolls around? Because if it only works with nouveau, it's > > probably not worth enabling. > > > > I think it's a bit of a chicken and egg problem. If no distro enables > it, there will be little incentive for the drivers to add support. > > Also, on all hardware, simpledrm is used at boot, so common kernel panic > like "unable to mount /", or "failed to execute /init", will use drm_panic. > > FYI, I opened an issue for amdgpu here: > https://gitlab.freedesktop.org/drm/amd/-/issues/3340 > > And for i915 here: > https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10954 > Forgive me for the potentially dumb question, but why does every driver have to individually implement support for it? DRM is a framework, right? So how come it's not implemented in a way such that all DRM drivers get it "for free"? -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Enable Drm Panic (system-wide)
On Tue, Jul 16, 2024 at 7:49 AM Jocelyn Falempe wrote: > > I've made a test kernel build with drm_panic enabled (and VT_CONSOLE > disabled): > > https://koji.fedoraproject.org/koji/taskinfo?taskID=120544794 > > I've backported a few patches, that are not in v6.10, like: > short panic description: > https://patchwork.freedesktop.org/series/135356/ > kmsg panic_screen: > https://patchwork.freedesktop.org/series/134286/ > draft nouveau support (tested on 1650X, might be garbage on other GPU): > https://patchwork.freedesktop.org/series/133963/ > And also virtio-gpu support, so you can test it easily on a VM. > > To install the test kernel, download the rpms kernel, kernel-core, > kernel-modules, kernel-modules-core, kernel-modules-extra, and install > them with dnf. > It's a Fedora rawhide kernel, but can be installed on F40. > > i915, amdgpu, and nvidia are not yet supported, so you need to blacklist > them, in order to use simpledrm, if you want to see the panic screen. > Do you expect to see the rest of the drivers supported by the time Fedora 42 rolls around? Because if it only works with nouveau, it's probably not worth enabling. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Enable Drm Panic (system-wide)
On Fri, Jul 12, 2024 at 1:12 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jul 12, 2024 at 05:53:25PM +0100, Aoife Moloney wrote: > > In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the > > kernel > > The idea for DRM_PANIC is nice, but I worry about the impact of disabling > VT_CONSOLE. Plymouth is not used everywhere, e.g. what about cloud images > and such? Also, when debugging boot troubles, removing 'rhbg' and 'quiet' > are the often first steps. > > I cannot actually recall the last time when I had a kernel crash > on any of my machines… It seems like we might be sacrificing debugability > for a feature which would be used very rarely. > Do we lose the serial console as part of this? Or is there a serial console "thing" somewhere still? -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Wed, Jul 10, 2024 at 8:16 AM wrote: > > On Tue, 2024-07-09 at 20:53 -0400, Neal Gompa wrote: > > On Tue, Jul 9, 2024 at 2:49 PM Wolfgang Ulbrich > > wrote: > > > > > > Btw. Why not splitting anconda RPM in a main part which support > > > only wayland with a new sub package for X11? > > > Than you can reduce package size for workstation and desktops which > > > are ready for wayland. > > > In my opinion this is way to go to support X11 desktops until X11 > > > itself is obsolete. > > > > > > > Anaconda will still start as an X11 application for X11 live > > environments, so the impact on MATE is minimal. > Exactly - its just the boot.iso/netinst image that is switching > directly from X11 to Wayland. > > For all the Live image spins, Anaconda still runs like a regular GTK3 > application - if the spin uses X11, Anaconda (or rathher GTK I guess ?) > will run as an X11 application. If the spin uses Wayland, then I guess > it will run as native Wayland client if possible. > > To only change that could impact spins is that we would ideally like to > drop the X11-only libXklavier library we have used for keaboard > handling so far and replace it with the universal localed keyboard > handling API. IIRC Jiri Konecny already notified all spin owners and > started some discussions about this. > > In an ideal case all the spins add support for the localed API & we can > drop libXklvaier. If this turns out to not be possible in the given > time frame, we have some workaround available (using a keyboard > handling helper script or keeping libXklavier in a limited role). > It is probably possible to create a helper application to do the same thing that we do in KWin and Sway for X11 environments. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Tue, Jul 9, 2024 at 2:49 PM Wolfgang Ulbrich wrote: > > Btw. Why not splitting anconda RPM in a main part which support only wayland > with a new sub package for X11? > Than you can reduce package size for workstation and desktops which are ready > for wayland. > In my opinion this is way to go to support X11 desktops until X11 itself is > obsolete. > Anaconda will still start as an X11 application for X11 live environments, so the impact on MATE is minimal. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: discuss f41 schedule adjustment for branching
On Tue, Jul 9, 2024 at 2:58 PM Kevin Fenzi wrote: > > Hey folks. > > I happened to notice the other day that f41 branching is currently > scheduled for 2024-08-06. This is the day before flock. > > https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html > > I don't think this is a good time. :) > > While Samyak (who will be doing most/all of the releng work for > branching) is unfortunately not going to be able to attend flock, there > are often issues or things that need adjustment from others, and I think > it's pretty unreasonable to ask those people to do these things and also > be present at flock. > > So, we could: > > 1. Do nothing, but branching may be in a weird state or messed up or > people going to flock may not be able to give their talks or interact > with others because they are fixing things. > > 2. Move the branching a week later: 2024-08-13 > and just leave it at that. That would leave one less week to clean up > branching stuff and get updates through before bodhi enablement. > > 3. Move the branching a week later: 2024-08-13 > and move the entire rest of the schedule out a week. > > 4. Move the branching a week sooner: 2024-07-30 > and leave everything the same after. This would mean less time for the > mass rebuild fixes, less time for maintainers to land changes that they > wanted to land before branching. > > I probibly like 3 the best myself, with 2 pretty close. I don't like 1 > or 4 much at all. :) > > Thoughts? > I've seen what option 2 looks like with F40. Let's not please. Option 4 would be disastrous. Let's do option 3. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Mon, Jul 8, 2024 at 8:52 AM Tim Landscheidt wrote: > > Solomon Peachy wrote: > > >> But with that knowledge comes the ability to work for a va- > >> riety of organizations who will spend many resources on > >> nudging their users to behave in a way that is not necessar- > >> ily in their best interests. > > > What does "a developer's ability to choose who they work for" have to do > > with end-user's ability to trust (and verify!) what data is being sent > > (or not) to Fedora? > > Developers might not want to work for a project any longer > that engages in behaviour that is perceived as being at odds > with why they chose to work for that project in the first > place. > > > Because what you're describing is a complete non-sequiter, and > > represents what has been the status quo for most of Humanity's history. > > No metrics necessary, because who cares what the peasants actually want? > > Looking at the proposed metrics > (https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect.md), > the "peasants" who do not form part of the majority of the > users might indeed worry about how bug reports, etc. are > processed if they (objectively) only affect x % of all in- > stallations. > My biggest issue with this is that it's only useful for Fedora Workstation. As it is currently designed, nobody else can benefit from it. I would have preferred a design that allows all Fedora variants to be able to offer this so that we have more holistic understanding and useful data for each team. :( Additionally, there's also the concern of whether the Red Hat Display Systems Team (fka Red Hat Desktop Team) will actually *do* anything once this data is available. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Sat, Jul 6, 2024 at 8:22 AM Vitaly Zaitsev via devel wrote: > > On 06/07/2024 14:06, Neal Gompa wrote: > > For KDE Plasma, you need to enable 3D acceleration (which is not on by > > default). > > What about KVM/qemu? AFAIK, 3D acceleration is still not supported > without forwarding a physical GPU into a VM. > Both modes work reasonably okay for me in GNOME Boxes and Virtual Machine Manager, though no-acceleration is still faster. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Sat, Jul 6, 2024 at 7:55 AM Sérgio Basto wrote: > > On Tue, 2024-06-04 at 10:34 +0200, Hans de Goede wrote: > > Hi Ian, > > > > On 6/4/24 5:39 AM, Ian Laurie via devel wrote: > > > On 6/1/24 1:04 AM, Adam Williamson wrote: > > > > On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote: > > > > > To my knowledge it shouldn't be. Fedora Workstation is already > > > > > running > > > > > on Wayland by default for quite some time and even Live ISO is > > > > > already > > > > > Wayland. To my knowledge Wayland don't have issues with > > > > > graphics cards > > > > > in general. > > > > > > > > GNOME has a fallback mechanism where it automatically runs the > > > > X.org > > > > session if the Wayland session doesn't work. I believe that is > > > > active > > > > on the live image. Of course, as telemetry is evil, we have > > > > absolutely > > > > no idea how many Fedora users actually hit this mechanism. > > > > > > One comment I would make is that VirtualBox doesn't *properly* > > > support > > > Wayland [yet] requiring GNOME to be run as an Xorg session (of > > > course > > > not an issue for Xfce etc). > > > > I'm a bit surprised by this. I use VirtualBox both as host under a > > GNOME > > wayland session and the guests inside that VirtualBox host also use > > Wayland. > > > > The only feature which I'm aware of which does not work is the mode > > where only the guest windows are shown. Everything else works fine. > > > > What exactly is not working for you when you run a GNOME Wayland > > session inside a VirtualBox guest ? > > > I think kde sessions and sddm-wayland as guest and VirtualBox as server > on KDE , are all broken with wayland > > Also this may impact on this subject (Anaconda as native Wayland > application) > > We receive an email from a user report that reports that: > https://lists.rpmfusion.org/archives/list/rpmfusion-us...@lists.rpmfusion.org/thread/XL4XR5X2JAOFV3N2CP2KGA2A7ASLZD5R/?sort=thread > > I don't want to start this discussion again, but I think people should > be aware of what's going on around them. > > And Hans, you are the only person I know who has the knowledge to fix > this. > For KDE Plasma, you need to enable 3D acceleration (which is not on by default). See this post: https://pointieststick.com/2024/03/08/psa-enable-3d-acceleration-in-your-virtualbox-vms/ -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Unprivileged management of system Flatpaks (system-wide)
On Wed, Jul 3, 2024 at 9:17 AM Vít Ondruch wrote:
>
>
> Dne 02. 07. 24 v 13:49 Neal Becker napsal(a):
>
>
>
> On Tue, Jul 2, 2024 at 5:59 AM Vít Ondruch wrote:
>>
>>
>> Dne 01. 07. 24 v 22:58 Aoife Moloney napsal(a):
>> > Wiki -
>> > https://fedoraproject.org/wiki/Changes/UnprivilegedSystemFlatpakManagement
>> > Discussion thread -
>> > https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-management-of-system-flatpaks-system-wide/124336
>> >
>> > This is a proposed Change for Fedora Linux.
>> > This document represents a proposed Change. As part of the Changes
>> > process, proposals are publicly announced in order to receive
>> > community feedback. This proposal will only be implemented if approved
>> > by the Fedora Engineering Steering Committee.
>> >
>> > == Summary ==
>> > This proposal adds a new dedicated `flatpak` group, allowing users to
>> > manage system Flatpaks without needing to be in the `wheel` group.
>> >
>> > == Owner ==
>> > * Name: [[User:boredsquirrel| Henning]]
>> > * Email: boredsquir...@secure.mailbox.org
>> >
>> >
>> > == Detailed Description ==
>> > Currently, to install, uninstall and modify apps or repositories,
>> > users need to be in the `wheel` group. Removing a user from the wheel
>> > group would interfere with the currently default (systemwide)
>> > configuration of Flatpaks.
>> >
>> > All users can add a `user` repository, and manage their own user
>> > Flatpaks. But a dedicated group to manage system flatpaks, without
>> > relying on `wheel` allows more fine grained privileges.
>>
>>
>> I am not Flatpak user, but I wonder why Flatpaks are system wide
>> installed by default? And if it would not be better to make them user
>> installed instead of this proposal.
>>
>>
>> Vít
>>
>>
>>
>> > This enables an "admin" permission that is not tied to full root
>> > access on the host system.
>> >
>> > It will be a change of the polkit rule `org.freedesktop.Flatpak.rules`
>> > like following:
>> >
>> >
>> >polkit.addRule(function(action, subject) {
>> >if ((action.id == "org.freedesktop.Flatpak.app-install" ||
>> >action.id == "org.freedesktop.Flatpak.runtime-install"||
>> >action.id == "org.freedesktop.Flatpak.app-uninstall" ||
>> >action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
>> >action.id == "org.freedesktop.Flatpak.modify-repo") &&
>> >subject.active == true && subject.local == true && (
>> >subject.isInGroup("wheel") || subject.isInGroup("flatpak"))) {
>> >return polkit.Result.YES;
>> >}
>> >
>> >return polkit.Result.NOT_HANDLED;
>> >});
>> >
>> >polkit.addRule(function(action, subject) {
>> >if (action.id ==
>> > "org.freedesktop.Flatpak.override-parental-controls") {
>> >return polkit.Result.AUTH_ADMIN;
>> >}
>> >
>> >return polkit.Result.NOT_HANDLED;
>> >});
>> >
>> >
>> > == Feedback ==
>> > none yet
>> >
>> > == Benefit to Fedora ==
>> > This is a step towards the Confined Users goal. It enables a dedicated
>> > action, the management of Flatpaks, without needing all the other
>> > privileges that `wheel` users have.
>> >
>> > == Scope ==
>> > * Proposal owners: changing a single rule, testing with nonwheel users
>> > in the `flatpak` group
>> >
>> > * Other developers: none
>> >
>> > * Release engineering: [https://pagure.io/releng/issues #Releng issue
>> > number]
>> >
>> > * Policies and guidelines: Documentation needs to get an additional
>> > chapter on Flatpak management with the `flatpak` group.
>> >
>> > * Trademark approval: N/A (not needed for this Change)
>> >
>> > * Alignment with the Fedora Strategy: Yes
>> >
>> >
>> > == Upgrade/compatibility impact ==
>> > The polkit rule will be overwritten, there will be no changes in
>> > behavior. It just enables a new feature.
>> >
>> > == How To Test ==
>> > On Atomic or traditional Fedora, place the above rule in
>> > `/etc/polkit-1/rules.d/org.freedesktop.Flatpak.rules`.
>> >
>> > This will be preferred over the default rule and you can test if it works.
>> >
>> > == User Experience ==
>> > By default, Anaconda puts users into the `wheel` group. There will be no
>> > change.
>> >
>> > But it enables to manage Flatpaks without being in that privileged group.
>> >
>> > == Dependencies ==
>> > None
>> >
>> >
>> > == Contingency Plan ==
>> >
>> > * Contingency mechanism: this is a simple fix, not adding it will keep
>> > the previous wheel need
>> > * Contingency deadline: N/A
>> > * Blocks release? N/A
>> >
>> >
>> > == Documentation ==
>> > Will be added afterwards.
>> >
>> > Nonwheel users can be added to the `flatpak` group:
>> >
>> >
>> >sudo groupadd flatpak
>> >sudo usermod -aG flatpak USERNAME
>> >
>> >
>> >
>> > == Release Notes ==
>> >
>> > Permission to manage systemwide flatpaks is now granted to users in
>> > the 'flatpak' group.
>>
> Currently wheel is required in order to install packages wit
Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Wed, Jul 3, 2024 at 7:30 AM Richard W.M. Jones wrote: > > On Wed, Jul 03, 2024 at 06:39:04AM -0400, Neal Gompa wrote: > > On Wed, Jul 3, 2024 at 4:53 AM Richard W.M. Jones wrote: > > > > > > On Tue, Jul 02, 2024 at 06:32:17PM +0200, Ralf Corsépius wrote: > > > > > > > > > > > > Am 02.07.24 um 4:44 PM schrieb Michael Catanzaro: > > > > >On Tue, Jul 2 2024 at 04:05:11 PM +02:00:00, Ralf Corsépius > > > > > wrote: > > > > >>Is this the same cheat as with Fedora's "installation ids" and > > > > >>Firefox's > > > > >>"phone home" features? > > > > >> > > > > >>This stuff is activated by default, which means at the point a user > > > > >>deactivates them, he already is "collected". > > > > > > > > > >This metrics system will be really disabled until it is enabled. > > > > > > > > > >This only works because the dnf installation counting metrics are > > > > >enabled by default, though. > > > > > > > > IMO, this and firefox's behavior needs to be changed, ASAP. Their > > > > behavior is intolerable. > > > > > > > > >Without the dnf metrics to compare to, we wouldn't be able to know > > > > >how many users agree to enable metrics collection unless we send > > > > >one metrics event to indicate that metrics are being turned off. > > > > >This is going to be a pretty imperfect comparison, but it will > > > > >have to suffice because I figured an "I don't want to enable > > > > >metrics" metric would not be well-received. > > > > > > > > My point is: Any "metrics", which makes individuals identifiable > > > > must be strictly optional. One way to make this possible would be to > > > > make the packages implementing this strictly optional. > > > > > > And to make this point clearer, in many countries this isn't just a > > > "nice to have", it's the law that it should work this way. > > > > > > > That is clearly not true, or otherwise Microsoft Windows and Apple > > macOS/iOS would be architected quite differently. > > I obviously can't comment on what Microsoft or Apple do or don't do, > but GDPR is very clear on consent: > > https://www.gdpreu.org/the-regulation/key-concepts/consent/ > > and in UK law: > > https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/lawful-basis-for-processing/consent/ > > > Not being active is not the same thing as requiring a particular > > software architecture. > > There's no requirement for software to be written in any particular > way, but it has to obey the law. > It's already not enabled by default and you have to explicitly consent to collect these metrics. Upgrades don't get it enabled, and new installs ask the users on first boot. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Wed, Jul 3, 2024 at 4:53 AM Richard W.M. Jones wrote: > > On Tue, Jul 02, 2024 at 06:32:17PM +0200, Ralf Corsépius wrote: > > > > > > Am 02.07.24 um 4:44 PM schrieb Michael Catanzaro: > > >On Tue, Jul 2 2024 at 04:05:11 PM +02:00:00, Ralf Corsépius > > > wrote: > > >>Is this the same cheat as with Fedora's "installation ids" and Firefox's > > >>"phone home" features? > > >> > > >>This stuff is activated by default, which means at the point a user > > >>deactivates them, he already is "collected". > > > > > >This metrics system will be really disabled until it is enabled. > > > > > >This only works because the dnf installation counting metrics are > > >enabled by default, though. > > > > IMO, this and firefox's behavior needs to be changed, ASAP. Their > > behavior is intolerable. > > > > >Without the dnf metrics to compare to, we wouldn't be able to know > > >how many users agree to enable metrics collection unless we send > > >one metrics event to indicate that metrics are being turned off. > > >This is going to be a pretty imperfect comparison, but it will > > >have to suffice because I figured an "I don't want to enable > > >metrics" metric would not be well-received. > > > > My point is: Any "metrics", which makes individuals identifiable > > must be strictly optional. One way to make this possible would be to > > make the packages implementing this strictly optional. > > And to make this point clearer, in many countries this isn't just a > "nice to have", it's the law that it should work this way. > That is clearly not true, or otherwise Microsoft Windows and Apple macOS/iOS would be architected quite differently. Not being active is not the same thing as requiring a particular software architecture. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: openssl engine-related FTBFS and Boost
On Tue, Jul 2, 2024 at 7:35 AM Iñaki Ucar wrote: > > Hi, > > This recent commit [1] in rawhide moves the engine API to a > openssl-devel-engine subpackage following [2] (BTW this change announced that > it would be openssl-engine-devel instead, but that's not the point). I'm > surprised that FESCo approved this change without any analysis of the impact > and the packages that required adaptation and how. Also, change owners are > now allowed to commit and just let things break? > > One major concern is that I see this in a package that does **not** use the > engine API: > > /usr/include/boost/asio/ssl/detail/openssl_types.hpp:26:11: fatal error: > openssl/engine.h: No such file or directory >26 | # include > | ^~ > compilation terminated. > > What are we supposed to do here? Aren't we allowed to add new packages to > Fedora that require Boost ASIO because we would need to add a deprecated > package to BR, even if the package itself doesn't use that API? > > [1] > https://src.fedoraproject.org/rpms/openssl/c/e67e9d9c40cd2cb9547e539c658e2b63f2736762?branch=rawhide > [2] https://fedoraproject.org/wiki/Changes/OpensslDeprecateEngine > The subpackage will probably need to lose its deprecated status, since it cannot be deprecated anytime in the next decade, due to insufficient alternatives. Notably, we need it for Fedora itself, so it would kind of suck if we can't use it. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Tue, Jul 2, 2024 at 7:14 AM Vitaly Zaitsev via devel wrote: > > On 02/07/2024 12:52, Michael Catanzaro wrote: > > Please remember the data collected will be anonymous and the data points > > will not be aggregated together with other data points. > > The government can ask "How many users are there from the > $country_name", and if the number is greater than N, they can force > Fedora to block access for users from that $country_name. > > It's much safer for the project not to ask about such things. > No government needs that to request the block. They'll just tell us to do it anyway. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Tue, Jul 2, 2024 at 3:27 AM Vitaly Zaitsev via devel wrote: > > On 01/07/2024 21:47, Aoife Moloney wrote: > > As a result of this feedback, we have changed the proposal: we now > > propose that initial setup will show an explicit yes/no prompt which > > has no default value. > > What about existing systems? > As it is, it will remain off by default. There is currently no way to trigger a prompt to activate it on existing systems. There will be a toggle in GNOME Settings (gnome-control-center) for turning it on if you so desire. > > Which metrics will be collected > > Country where device is physically located (this will need discussion) > > This definitely MUST be removed from telemetry. > Why? It can be useful for determining where to boost investment in l10n and i18n efforts. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 & AI Survey Now Live Until July 16th
On Tue, Jul 2, 2024 at 4:19 AM Daniel P. Berrangé wrote: > > On Mon, Jul 01, 2024 at 08:07:46PM +0100, Aoife Moloney wrote: > > DJ & Tom - thank you for that clarification on how to interpret your > > ranking, and I can assure you and other folks who feel similar about > > answering that question that that is indeed the way we will be analysing > > the results - top ranked being best fit, 5th or last ranked being least or > > worst fit. Also for anyone who has yet to complete the survey, the last > > question is an optional, free format answer so I would suggest using that > > to expand on reasons why you ranked certain areas #1, #2 etc for what > > problems you see AI addressing in those parts of the project. > > > > I would also like to add that we deliberately took a positive tone for this > > survey as it is far too easy to find (many) negatives for AI (and for good > > reason!), and we wanted to try to look at the benefits we could get from AI > > instead if applied properly and wit the best interest of Fedora driving the > > use of AI in parts of the projects ecosystem. > > > > This survey is just trying to understand the preferences and wants of the > > Fedora community when it comes to AI, and not a guarantee that the project > > will be introducing AI in all of the mentioned areas. > > I can't see how this helps understand the Fedora contributor's preferences > about the use of AI, when the survey is restricting the possible answers > to "yes", "definitely yes", "very much yes". I would question the validity > of any actions taken / priorities set in Fedora based on results of this > survey. > Indeed. This creates a skewed dataset because the questions you've asked essentially prevent a set of responses from being captured. The two choices people have are: pick the least worst option or just don't participate in the survey. Neither of which are good things. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 transaction with a command line?
On Mon, Jul 1, 2024, 11:40 AM Barry Scott wrote: > In this discuss topic there is a user that is surprised by > removal of some RPMs. > > See > https://discussion.fedoraproject.org/t/troubles-with-rpmfusion-nvidia-drivers-secureboot-setup/124205/41 > > The dnf history showz the removal, but the command that caused > the removal is blank for ID 83. > > $ sudo dnf history > [sudo] password for luc: > ID | Command line | Date and time | Action(s) | Altered > > > 87 | -y install --nogpgcheck - | 2024-07-01 11:00 | Install | 1 > 86 | install xorg-x11-drv-nvid | 2024-07-01 10:59 | Install | 3 > 85 | install akmod-nvidia | 2024-07-01 10:58 | Install | 53 EE > 84 | update | 2024-07-01 10:55 | Upgrade | 9 > 83 | | 2024-07-01 01:59 | Removed > > What does it mean when the command is blank? > Is this when some other software ran the transaction like Gnome Software? > Yes, when a non command-line action occurs, it is blank. Notably, when PackageKit or DNF Daemon are used. > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Hosted login for mailing lists error
On Fri, Jun 28, 2024 at 9:04 AM Michal Konecny wrote: > > I can see what is happening here, in OIDC we have entry only for > lists.fedoraproject.org. > > I created a ticket on infra tracker for you > https://pagure.io/fedora-infrastructure/issue/12013, but I'm not sure > how to solve this as the OIDC entry is shared between all instances and > it doesn't allow us to have more client URLs than one. As workaround you > can use lists.fedoraproject.org for now, the list can be found there as > well > https://lists.fedoraproject.org/archives/list/firewalld-us...@lists.fedorahosted.org/ > How did the custom FAS/OpenID plugin work around this? I know it worked with that deployment... -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: 2FA policy for provenpackagers is now active
On Sun, Jun 23, 2024 at 11:59 AM Miroslav Suchý wrote: > > Dne 23. 06. 24 v 11:50 dop. Leigh Scott napsal(a): > > it has made kerberos login much harder > > Can you elaborate? > > I use Kerberos login without a problem. > > I'm considering ditching provenpackager rights if that is a condition. > > Or you can help us to improve the user experience. > What reasonable path do any of us have to improve that user experience? Most of the problems are tied up in FreeIPA. This is not exactly a system that any Fedora contributor is necessarily skilled in, and the complexity of the stack makes it difficult for a newcomer to grasp. It's not like the old FAS which was all in Python, even if it was custom. I've asked before about making GOA and KAccounts support Kerberos-FAS fully even with MFA, and I've been told that it's basically not possible as things currently stand. I've been against the move to MFA for the sole reason that there has been no effort around supporting it in GOA in a decade. What makes me think it would change now? -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 19, 2024 at 9:29 AM Vitaly Zaitsev via devel wrote: > > On 19/06/2024 09:13, Daniel P. Berrangé wrote: > > If Fedora cares > > about optimal performance it should just declare we're going to stop > > being held back by compat with ancient hardware and use -v2 baseline > > for everything, but obviously that's been rejected previously. > > Maybe it's a good time for the Fedora 41 System-Wide change proposal? > Switching to AVX2 will give significant performance boost for many > applications. > Last time, the approach was to do the RHEL approach (ie. lie to RPM about the architecture level we support). Two things have changed since then: * I suspect more of the hardware that don't support -v2 have failed out of use naturally * RPM now lets us "tell the truth" about what x86_64 sublevel we expect If we're now starting to have software that *requires* x86_64-v2, then we should visit this with that idea in mind. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 12, 2024 at 9:15 PM Przemek Klosowski via devel wrote: > > On 6/12/24 14:07, Ben Cotton wrote: > > Yeah, maintaining that long-term seems like a bad idea. [...] But it > > would at least buy us some time so that we don't end up with the > > "surprise, you can't use this release on your hardware if you want to > > use QEMU!" situation. > > > The root cause seems to be the QEMU upstream's switch to x86_64_v2 ABI > without a backwards compatiblity. If the software is not compatible with > a given hardware, it just should not install; Fedora should not be stuck > at an obsolete version for everyone, or expected to backport > alternatives, or be blamed for the breakage on old systems. > > I am an old man, but even I understand that sometimes backwards > compatibility has to go if there are tangible benefits to breaking > changes and no practical workarounds, whether it's 32-bit-only support, > or X11, or QEMU; I accept it even if I am personally affected. > > To prevent the surprise, I wonder if Fedora could detect and warn for > old hardware : > > "The future upstream changes to QEMU will require x86_64_v2 > hardware, making it incompatible with your system" > > before the upstream changes arrive. After that, I like Neal's suggestion > of declaring it via RPM attributes, and making it > non-installable/non-upgradeable on old architectures. I guess people > will have to decide then if they uninstall or lock out updates with > 'versionlock' or '--skip-broken'. I understand that locking updates > would still eventually result in nonfunctional QEMU because of diverging > dependencies. This is supported since RPM 4.19, so we should just do it. We may also want to start having a conversation about moving to x86_64-v2 RPM arch for x86_64 across the board if we're going to start encountering stuff like this. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 12, 2024 at 4:00 PM Stephen Gallagher wrote: > > On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé > wrote: > > > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote: > > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé > > > wrote: > > > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users > > > > with older x86_64 hardware would likely be unable to run QEMU, from F41 > > > > onwards, unless some TBD action is taken. > > > > > > > > Thus I'm wondering whether Fedora has any policy or guidance on handling > > > > such a situation both in general, and more specifically for "critical > > > > path" > > > > packages, if that difference is relevant ? The packaging guidelines > > > > aren't > > > > especially explicit about this situation, unless I've missed something > > > > beyond the "compiler flags" and "architecture support" sections. > > > > > > > > > > Absent a project-wide decision to move to the newer baseline, I think > > > the best approach we can take would be to find some way to communicate > > > to the user that the software isn't usable. In the case of Qemu, does > > > the application report an error or crash if it's run on hardware > > > without the requisite baseline? > > > > I've not tested, but I would expect it to crash attempting to execute an > > illegal instruction > > > > OK, that's a situation that will lead to annoying and unresolvable bug > reports. Would it be possible to put something in place that would > check processor capabilities early in execution before hitting any of > the affected instructions? Build the package as x86_64_v2 instead of x86_64. Not lying about the architecture will ensure that we don't bypass RPM's own compatible architecture check. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Tue, Jun 11, 2024 at 4:22 PM Jiri Konecny wrote: > > On 11. 06. 24 11:53, Neal Gompa wrote: > > On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny wrote: > > On 04. 06. 24 14:27, Neal Gompa wrote: > > On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny wrote: > > On 03. 06. 24 21:57, Jason L Tibbitts III wrote: > > Aoife Moloney writes: > > === VNC switch to RDP for remote GUI installations === > > I'm curious how my usual install workflow will be affected by this > change. I use the kickstart "vnc --connect" option extensively in my > workflow; I may have a bunch of installs running in parallel, and they > just connect and display when they are ready. I use vinagre as the vnc > client. > > It's not a huge thing; I could come up with another workflow but that's > the one I've used since before Fedora existed. The installs are fully > automated and the display connection is only used so that I can see the > progress and potentially interact with a machine if it encounters a > problem. I guess in the worst case I could just do the install blind > and ssh in if something takes too long. > > Hi, the only change should be that you will change "vnc --connect" with > the new API we will provide and also use RDP as your client instead of VNC. > > Given that gnome-remote-desktop supports both VNC and RDP, can't VNC > support still be wired up? > > Hi, it is theoretically possible but we are not planning to do that > until there will be a reason for that. AFAIK it's not that simple change > to do that. > > I think the reason is pretty obvious: there are many more high quality > VNC clients than there are RDP ones. And even ignoring that, the > existing Anaconda workflows for remote GUI expect VNC. There is no > technical limitation preventing us from having VNC support through > grd. In fact, one of the original reasons I wrote the Weston backend > for Anaconda was so that I could have VNC for Linux and web clients, > because the RDP clients are not very good in my experience. > > In any case, I would see this more like a future improvement if we agree to > go this way. I would like to simplify things for now, it's already a big > change. > As long as the mechanism to wire things up for inst.vnc to work isn't deleted, then I think that's fine. It can be added after-the-fact and maybe even still land for F41. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny wrote: > > On 04. 06. 24 14:27, Neal Gompa wrote: > > On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny wrote: > >> > >> > >> On 03. 06. 24 21:57, Jason L Tibbitts III wrote: > >>>>>>>> Aoife Moloney writes: > >>>> === VNC switch to RDP for remote GUI installations === > >>> I'm curious how my usual install workflow will be affected by this > >>> change. I use the kickstart "vnc --connect" option extensively in my > >>> workflow; I may have a bunch of installs running in parallel, and they > >>> just connect and display when they are ready. I use vinagre as the vnc > >>> client. > >>> > >>> It's not a huge thing; I could come up with another workflow but that's > >>> the one I've used since before Fedora existed. The installs are fully > >>> automated and the display connection is only used so that I can see the > >>> progress and potentially interact with a machine if it encounters a > >>> problem. I guess in the worst case I could just do the install blind > >>> and ssh in if something takes too long. > >> Hi, the only change should be that you will change "vnc --connect" with > >> the new API we will provide and also use RDP as your client instead of VNC. > >> > > Given that gnome-remote-desktop supports both VNC and RDP, can't VNC > > support still be wired up? > > > Hi, it is theoretically possible but we are not planning to do that > until there will be a reason for that. AFAIK it's not that simple change > to do that. > I think the reason is pretty obvious: there are many more high quality VNC clients than there are RDP ones. And even ignoring that, the existing Anaconda workflows for remote GUI expect VNC. There is no technical limitation preventing us from having VNC support through grd. In fact, one of the original reasons I wrote the Weston backend for Anaconda was so that I could have VNC for Linux and web clients, because the RDP clients are not very good in my experience. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Fri, Jun 7, 2024 at 8:32 AM Adam Williamson wrote: > > On Fri, 2024-06-07 at 13:19 +0200, mkol...@redhat.com wrote: > > > > > > Does RDP support this kind of "reverse connection" mode that VNC has? > > > https://serverfault.com/questions/1100655/is-it-possible-to-make-a-reverse-rdp-connection-on-windows-server > > > says not, which seems like a significant loss of functionality. > > Yeah, I don't think this is really a thing in the RDP world as far as I > > can tell. > > > > Also, we are using GNOME remote desktop to provide the RDP access & its > > remote desktop control tool (grdctl) does not seem to provide a way to > > configure something like that: > > > > https://www.mankier.com/1/grdctl > > > > For the record, it does not seem to support the VNC connect mode as as > > well. > > > > I'm also not sure how well is VNC actually supported in GNOME remote > > desktop, as IIRC it is not even exposed as an option in modern Fedora > > Workstation options page - only RDP can be configured from there. > > Well, all you need is any VNC app, and there are lots of those. For the > openQA tests we use vinagre for the regular client test and tigervnc > for the reverse connection test. GNOME Connections supports regular > VNC, I just didn't get around to changing that test to use it yet. Note that gnome-remote-desktop supports VNC. It can be configured using the grdctl commandline tool. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny wrote: > > > > On 03. 06. 24 21:57, Jason L Tibbitts III wrote: > >> Aoife Moloney writes: > >> === VNC switch to RDP for remote GUI installations === > > I'm curious how my usual install workflow will be affected by this > > change. I use the kickstart "vnc --connect" option extensively in my > > workflow; I may have a bunch of installs running in parallel, and they > > just connect and display when they are ready. I use vinagre as the vnc > > client. > > > > It's not a huge thing; I could come up with another workflow but that's > > the one I've used since before Fedora existed. The installs are fully > > automated and the display connection is only used so that I can see the > > progress and potentially interact with a machine if it encounters a > > problem. I guess in the worst case I could just do the install blind > > and ssh in if something takes too long. > Hi, the only change should be that you will change "vnc --connect" with > the new API we will provide and also use RDP as your client instead of VNC. > Given that gnome-remote-desktop supports both VNC and RDP, can't VNC support still be wired up? -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: rpm-4.20 and __debug_install_post
On Tue, Jun 4, 2024 at 4:24 AM Sandro Mani wrote:
>
>
> On 04.06.24 10:12, Daniel P. Berrangé wrote:
> > On Tue, Jun 04, 2024 at 08:40:15AM +0200, Sandro Mani wrote:
> >> Hi
> >>
> >> In rpm 4.20 as currently available in rawhide, defining
> >> __debug_install_post
> >> seems to have no effect. The %mingw_package_header sets
> >> __debug_install_post
> >> as follows
> >>
> >> %mingw_package_header \
> >> %global __strip %{mingw_strip}\
> >> %global __objdump %{mingw_objdump}\
> > FWIW, I don't think these two overrides should be required
> > anymore. The standard strip/objdump commands in /usr/bin
> > work with PE files these days, and for the pacakges where
> > we have merged mingw+native specs these overrides aren't
> > used.
> >
> > Given that, I'd question whether %mingw_package_header needs
> > to continue to exist either ? it is no harder / great lines
> > of code to simply call %mingw_debug_install_post in %install,
> > thus avoiding the rpm 4.20 compat issue.
>
> We could indeed to that, as we already require for unified native/mingw
> specs. Perhaps there also exists a way to trigger this automatically
> with a mechanism similar to the %{_rpmconfigdir}/fileattrs/*.attr?
>
I don't know about that, we don't yet have subpackage generators. But
we *do* have the ability to run scripts to make spec snippets that
rpmbuild picks up for dynamic packaging.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Anaconda as native Wayland application (System Wide)
On Tue, Jun 4, 2024 at 4:34 AM Hans de Goede wrote: > > Hi Ian, > > On 6/4/24 5:39 AM, Ian Laurie via devel wrote: > > On 6/1/24 1:04 AM, Adam Williamson wrote: > >> On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote: > >>> To my knowledge it shouldn't be. Fedora Workstation is already running > >>> on Wayland by default for quite some time and even Live ISO is already > >>> Wayland. To my knowledge Wayland don't have issues with graphics cards > >>> in general. > >> > >> GNOME has a fallback mechanism where it automatically runs the X.org > >> session if the Wayland session doesn't work. I believe that is active > >> on the live image. Of course, as telemetry is evil, we have absolutely > >> no idea how many Fedora users actually hit this mechanism. > > > > One comment I would make is that VirtualBox doesn't *properly* support > > Wayland [yet] requiring GNOME to be run as an Xorg session (of course > > not an issue for Xfce etc). > > I'm a bit surprised by this. I use VirtualBox both as host under a GNOME > wayland session and the guests inside that VirtualBox host also use > Wayland. > > The only feature which I'm aware of which does not work is the mode > where only the guest windows are shown. Everything else works fine. > > What exactly is not working for you when you run a GNOME Wayland > session inside a VirtualBox guest ? > There have been significant issues with GNOME and KDE Plasma on VirtualBox over the past few years. Honestly, we need to start regularly testing it, because the guest integration is brittle and nobody notices until it's too late. I personally do testing on VMware for KDE Plasma because otherwise it'd never get tested and issues would never get fixed. The most recent issue is that it's unbearably slow and sometimes suffers serious graphics corruption unless 3D acceleration is turned on. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: updates for "Change: Replace Redis with Valkey"
On Mon, Jun 3, 2024 at 5:34 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jun 03, 2024 at 04:09:51AM -0500, Jonathan Wright wrote: > > I think it is time to get this discussed (and hopefully approved) in the > > meeting. Valkey is the clear leader in my opinion, seems to be gaining the > > most traction, and is well on the way to making improvements with their > > first major release of 8.0 due later this year. > > Thanks. I'll send out the meeting agenda with this item in a sec. > Alpine 3.20 replaced Redis with Valkey: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0#Redis -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [Fedocal] Reminder meeting : ELN SIG
On Mon, Jun 3, 2024 at 2:56 AM Tomáš Popela wrote: > > Hi Stephen > > On Fri, May 31, 2024 at 7:15 PM Stephen Gallagher wrote: >> >> * AGREED: All packages currently included in ELN Extras will have >> an EPEL 10 branch created for them (@sgallagh:fedora.im, 16:28:51) > > > Please exclude Thunderbird and Firefox from the EPEL 10 as they are packaged > in RHEL. See https://github.com/minimization/content-resolver-input/pull/1019 > on why they're there and not in ELN (to not "pollute" the ELN buildroot). Unless plans have changed compared to what was stated in the pull request, someone can and may request that both Firefox and Thunderbird be made available as RPMs in EPEL, especially if they don't want to use Flatpak for whatever particular reason. Flatpaks are not a reason to exclude from EPEL, since RPM content does not conflict with Flatpak content. But yes, we don't have to auto-branch it. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: 41 Change Proposal: Make Tuned the Default Power Profile Management Daemon (System-Wide)
On Fri, May 31, 2024 at 7:20 AM Vitaly Zaitsev via devel wrote: > > Just a note. Users of DEs other than KDE and GNOME can use the Tuned > Switcher app. > > Available both in the main Fedora repository and as a Flatpak: > > - sudo dnf install tuned-switcher > - flatpak install org.easycoding.TunedSwitcher > Yeah, this probably makes things easier for everyone who hasn't integrated the power-profiles-daemon API because there are alternative frontends for tuned available. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 additional flag in cmake-rpm-macros to disallow the use of the FetchContent module
On Sun, May 26, 2024 at 8:47 PM Kan-Ru Chen wrote: > > On Mon, May 27, 2024, at 9:22 AM, Byoungchan Lee via devel wrote: > > In well-maintained Fedora packages, the use of the FetchContent module > > is generally discouraged because dependencies are already available in > > the Fedora repositories. > > > > While it's uncertain if build workers in Fedora have internet access, > > to improve security, I believe it is recommended to entirely disallow > > the use of the FetchContent module. To achieve this, I propose adding a > > flag in the cmake-rpm-macros to disable the FetchContent module. > > > > According to the CMake manual > > (https://cmake.org/cmake/help/latest/module/FetchContent.html), > > FETCHCONTENT_FULLY_DISCONNECTED=ON seems the flag that disables the use > > of the FetchContent module. > > Homebrew recently implemented a similar restriction > https://github.com/Homebrew/brew/pull/17310 which follows a recommendation > from a CMake maintainer https://github.com/Homebrew/brew/pull/17075. > > In summary FETCHCONTENT_FULLY_DISCONNECTED should not be used to disable > FetchContent, instead a trap macro is recommended. > > However, I think the Homebrew implementation is not correct either. It is > documented that FIND_PACKAGE_ARGS argument in FetchContent_Declare should > instruct it to find system packages first. It will break packages that follow > this pattern if we trap all FetchContent usage. > > It would be better if we can set FindPackage the only dependency provider > https://cmake.org/cmake/help/latest/command/cmake_language.html#dependency-providers > > > Do I need a formal process to propose this change? Or can I just submit > > a pull request to the cmake (https://src.fedoraproject.org/rpms/cmake) > > repository? > > This is probably going to break packages. I think a change proposal would be > good. > It's probably not necessary for a Change document, since FetchContent already fails inside the build system since there's no internet access there. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Workstation 40 aarch64 download -- How to run Live CD installer?
On Tue, May 21, 2024 at 8:11 PM Samuel Sieb wrote: > > On 5/21/24 5:08 PM, Brian Masney wrote: > > I want to put Fedora 40 on my Lenovo Thinkpad x13s laptop, which is an > > aarch64-based laptop with a Qualcomm SoC. I downloaded the Fedora raw > > image from [1], and I can boot from USB using the directions at [2]. > > All of the other supported architectures have an ISO available, > > however aarch64 only has a raw image available. > > > > In the past, I would dd the Fedora image directly to my nvme drive, > > however this time I'd like to go through the installer so that I can > > easily setup LUKS encryption on my nvme drive through the installer. > > The raw image doesn't have the installer, and I didn't have luck > > installing the anaconda-livecd package. > > > > Is there a Live ISO available for aarch64 anywhere with an installer? > > https://dl.fedoraproject.org/pub/fedora/linux/releases/40/Workstation/aarch64/iso/ That is the experimental osbuild one. There is no official ISO, as it failed to build. It affected Fedora KDE and other variants too. :( -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: GRUB2 rebase (from 2.06 to 2.12) landing soon on rawhide
On Tue, May 21, 2024 at 12:58 PM Leo Sandoval wrote: > > Hi team, > > We (the Red Hat bootloader team) are completing the work of > rebasing/reviewing/testing current rawhide patches, from GRUB2 2.06 to 2.12, > so at > some point in the near future these would land finally into rawhide. Once > everything is in place, we would like your help to start testing the > package and report any boot issue found. > > If there is any concern on this work, please let me know. > Thank you for doing this! :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: rich deps result in packages being uninstalled from buildroot
On Thu, May 16, 2024 at 3:10 AM Fabio Valentini wrote: > > On Thu, May 16, 2024 at 9:25 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > Hi, > > > > I've been trying to get 'add-determinism' deployed in buildroots. This > > has been unsuccessful because of the following issue. > > > > The dependency chain is: > > redhat-rpm-config has > > Requires build-reproducibility-srpm-macros > > and build-reproducibility-srpm-macros has > > Requires:(add-determinism if python3-libs else > > add-determinism-nopython) > > Suggests:add-determinism-nopython > > > > (The idea is that we install 'add-determinism-nopython' which is > > self-contained, > > but if python3 is installed into the buildroot, we pull in the heavier > > version > > which has a dependency on python3-libs.) > > > > This works well enough when installing packages using dnf on a test system. > > But, in koji and mock builds, this results in rpm-build being unistalled > > (!). > > > > For example, see > > https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626 > > and root.log there: first rpm-build is installed along with a bunch of other > > packages expected in the buildroot, but then cargo-rpm-macros is requested > > (presumably via %generate_buildrequires), which depends on python3 and > > python3-libs. > > > > Dnf5 realizes that to satisfy all bounds, it can either: > > a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and > > remove add-determinism-nopython > > b) install cargo-rpm-macros, python3, python3-libs, and remove > > build-reproducibility-srpm-macros, > >rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other > > packages. > > and picks option b). > > This looks like you're putting the resolver between a rock and a hard > place. :thinking: > I don't think I've ever seen packages being *removed* when installing > BuildRequires on top of the minimal buildroot ... > > Would it be possible to adapt the packages so that add-determinism and > add-determinism-nopython are parallel-installable, and have the macro > fall back to the add-determinism-nopython executable if the > add-determinism executable is not available? > That way BuildRequires are additive and wouldn't force package removal > from the buildroot, and the rich dependency could be simpler - i.e. > `Requires: (add-determinism if python3-libs)`, without Suggests or > else branch. I have the question of why is dnf5 running as if "--allow-erasing" is always passed to it? Older versions of DNF explicitly didn't do that because we get weird behaviors like this. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Upgrading Xwayland to version 24.1.0 in Fedora 40
On Wed, May 15, 2024 at 8:31 AM Olivier Fourdan wrote: > > Hi all, > > Today was released Xwayland 24.1.0, a new stable branch of Xwayland. > > That version brings quite a few improvements, among which is support for > explicit GPU synchronization. > > This is required to enable explicit GPU synchronization with the next version > of the NVIDIA proprietary graphics driver on Wayland, meaning that rendering > on Wayland and Xwayland with the NVIDIA proprietary graphics driver should be > greatly improved eventually. See the merge request upstream [1] for more > details. > > However, that new version of Xwayland also dropped support for EGLStream [2], > since that's not required anymore and and unused with recent versions of the > NVIDIA proprietary driver, which means that anyone with a Kepler GPU who are > stuck with the 470 legacy NVIDIA proprietary graphics driver won't have > hardware acceleration with Xwayland 24.1.0. > > For what it's worth, not too long ago EGLStream support was not working in > GNOME Shell for quite some time [3] and that remained mostly unnoticed, as > far as I know. > > This message is meant as a heads up because I am considering upgrading > Xwayland to version 24.1.0 in Fedora 40. > The package in rawhide has been updated already [4]. > As a follow up, KDE Plasma has not supported EGLStreams either since Plasma 5.23 (it was dropped in 5.24). So in practice, Xwayland support for EGLStreams meant nothing for KDE Plasma Wayland users. All wlroots-based environments don't support EGLStreams either, so I don't expect this to be a significant issue. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Hulk edition
On Mon, May 13, 2024 at 3:28 PM Richard Fontana wrote: > > On Mon, May 13, 2024 at 11:44 AM Fabio Valentini wrote: > > > > On Fri, May 10, 2024 at 11:29 AM Miro Hrončok wrote: > > > > > > On 10. 05. 24 10:55, Miroslav Suchý wrote: > > > > Hot news: > > > > > > > > SPDX v3 has been published. The biggest change for us is that > > > > license > > > > expression allows lowercase operators (and, or, with). This got into the > > > > specification because of your (Fedora maintainers) feedback! > > > > > > So we can now have packages with uppercase AND/ORs and packages with > > > lowercase > > > and/ors and we can no longer quickly recognize SPDX expression by > > > observing > > > uppercase AND/ORs? > > > > > > That does not sound like improvement to me :/ > > > > I agree, this is just making things more confusing. > > Can we at least still recommend to use the AND / OR / WITH > > capitalization for Fedora license tags, even if the lower-case ones > > are technically considered valid now? > > This all resulted from some Fedora contributors complaining about > capitalized operators on (I think) aesthetic grounds. I guess you > can't please everyone. :) > The only way to recognize SPDX expressions is to read the identifiers. Everything else is a coincidence. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GIMP 3.0 in F41?
On Sun, May 12, 2024 at 5:09 PM Sérgio Basto wrote: > > On Sun, 2024-05-12 at 17:00 -0600, Neal Gompa wrote: > > On Sun, May 12, 2024 at 4:59 PM Sérgio Basto > > wrote: > > > > > > > > > > > > https://src.fedoraproject.org/rpms/gimp3 > > > > > > > What the heck? This should have been gimp2 for the old version, not > > gimp3 for the new version... > > Well I'm thinking how build imageMagick 7 on epel 9 > > could be an idea , So you suggest on epel9, ImageMagick move to > ImageMagick6 ? and build imagemagick 7 on imagemagick ? > Since it's not present in RHEL, yes. But we should absolutely avoid offering ImageMagick6 in EPEL. Having both is a recipe for a maintenance nightmare. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GIMP 3.0 in F41?
On Sun, May 12, 2024 at 4:59 PM Sérgio Basto wrote: > > > > https://src.fedoraproject.org/rpms/gimp3 > What the heck? This should have been gimp2 for the old version, not gimp3 for the new version... -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel wrote: > > Am 06.05.24 um 13:56 schrieb Florian Festi: > > Hi everyone, > > > > RPM has deprecated the %patchN syntax in favor of %patch -PN where N is > > the patch number for a year now. See the RPM documentation for more > > information [1]. In current RPM versions, this syntax only emits a > > deprecation warning, but support for this syntax has been removed > > completely in the upcoming RPM 4.20 release. As it will be added in > > Fedora soon [2] it is time to switch over to the new syntax now. > > > > There are around 1800 packages that still use the old syntax. Later this > > week/next week, we will run this script [3] over the affected packages > > [4][5] to update them to the modern patch syntax. For example, the > > script will change: > > > > %patch0 -p1 → %patch -P0 -p1 > > %patch0005 -p2 → %patch -P0005 -p2 > > > > > Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)? > Yes. It's been supported for a very long time. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On Sat, Apr 27, 2024 at 5:59 AM Tom Stellard wrote: > > On 4/27/24 05:57, Neal Gompa wrote: > > On Sat, Apr 27, 2024 at 5:53 AM Tom Stellard wrote: > >> > >> On 4/26/24 21:58, Neal Gompa wrote: > >>> On Fri, Apr 26, 2024 at 9:35 PM Tom Stellard wrote: > >>>> > >>>> Hi, > >>>> > >>>> After each Fedora release we do a retrospective with the LLVM package > >>>> maintainers > >>>> and talk about how we can improve the LLVM packages[1] in Fedora. We've > >>>> come up > >>>> with some ideas for Fedora 41 that we'd like to share to raise awareness > >>>> and > >>>> get feedback. Right now these are just ideas, and we plan to write up a > >>>> formal > >>>> change proposal once we have decided which of these we are going to > >>>> implement: > >>>> > >>> > >>> Here's some feedback below for each of these ideas. > >>> > >>>> * Spec file merge. We plan to merge the clang, compiler-rt, and libomp > >>>> packages > >>>> in with llvm and have them be sub-packages of the llvm package. This > >>>> will allow > >>>> us to use the build configuration recommended by upstream and also make > >>>> it possible > >>>> to optimize the packages using Profile-Guided Optimizations (PGO). > >>>> > >>> > >>> Are these actually released together or are they separately developed > >>> and lifecycled? If it's the latter, this would make things much more > >>> complex down the road because you'll have to deal with a lot of the > >>> weirdness that Nodejs deals with by having to subpackage with > >>> different versions and trying to keep the release values coherent so > >>> that every NVR of every subpackage is correctly unique. It's not worth > >>> it in that case. > >>> > >> > >> These projects are all part of the same git repository upstream. > >> > > > > That doesn't actually matter from the perspective of Fedora. What > > matters is if these components are versioned, released, and supported > > together. > > > > They are, this is main reason why they were put in the monorepo together. > Then the only tradeoff is that it makes the LLVM build take longer. But if you're okay with that, then it's fine, I suppose. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On Sat, Apr 27, 2024 at 5:53 AM Tom Stellard wrote: > > On 4/26/24 21:58, Neal Gompa wrote: > > On Fri, Apr 26, 2024 at 9:35 PM Tom Stellard wrote: > >> > >> Hi, > >> > >> After each Fedora release we do a retrospective with the LLVM package > >> maintainers > >> and talk about how we can improve the LLVM packages[1] in Fedora. We've > >> come up > >> with some ideas for Fedora 41 that we'd like to share to raise awareness > >> and > >> get feedback. Right now these are just ideas, and we plan to write up a > >> formal > >> change proposal once we have decided which of these we are going to > >> implement: > >> > > > > Here's some feedback below for each of these ideas. > > > >> * Spec file merge. We plan to merge the clang, compiler-rt, and libomp > >> packages > >> in with llvm and have them be sub-packages of the llvm package. This will > >> allow > >> us to use the build configuration recommended by upstream and also make it > >> possible > >> to optimize the packages using Profile-Guided Optimizations (PGO). > >> > > > > Are these actually released together or are they separately developed > > and lifecycled? If it's the latter, this would make things much more > > complex down the road because you'll have to deal with a lot of the > > weirdness that Nodejs deals with by having to subpackage with > > different versions and trying to keep the release values coherent so > > that every NVR of every subpackage is correctly unique. It's not worth > > it in that case. > > > > These projects are all part of the same git repository upstream. > That doesn't actually matter from the perspective of Fedora. What matters is if these components are versioned, released, and supported together. To put it in developer terms: a monorepo is a Git repo of multiple projects that have independent release lifecycles. The only reason they are there is because the developer wants them there. That's in contrast to say the Linux kernel, which has a huge uniform repository of components developed by separate people that are released together and considered a single unit from a release lifecycle perspective and share versioning. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On Fri, Apr 26, 2024 at 9:35 PM Tom Stellard wrote: > > Hi, > > After each Fedora release we do a retrospective with the LLVM package > maintainers > and talk about how we can improve the LLVM packages[1] in Fedora. We've come > up > with some ideas for Fedora 41 that we'd like to share to raise awareness and > get feedback. Right now these are just ideas, and we plan to write up a > formal > change proposal once we have decided which of these we are going to implement: > Here's some feedback below for each of these ideas. > * Spec file merge. We plan to merge the clang, compiler-rt, and libomp > packages > in with llvm and have them be sub-packages of the llvm package. This will > allow > us to use the build configuration recommended by upstream and also make it > possible > to optimize the packages using Profile-Guided Optimizations (PGO). > Are these actually released together or are they separately developed and lifecycled? If it's the latter, this would make things much more complex down the road because you'll have to deal with a lot of the weirdness that Nodejs deals with by having to subpackage with different versions and trying to keep the release values coherent so that every NVR of every subpackage is correctly unique. It's not worth it in that case. > * Build compat packages (e.g. llvm18) as early as possible. When we package > a new > major release of llvm, we create a compat package so that packages that aren't > compatible with the new version can still use the old version. In the past, > we've > waited to introduce the compat packages until the new version of LLVM was > ready > (typically during the Beta Freeze). However, this proved to be an issue this > release for packages the were ready to switch to the compat packages early in > the release cycle, but then had to wait for Beta freeze. > This is definitely a good idea. It would also mean you can ship the new version faster in Rawhide and use the corpus to properly influence upstream to do the right things before they enter stabilization. Right now, everyone finds out too late and there's never enough time to fix it. > * Switch to python-style compat/main packages. In order to make the > packaging more > consistent between the main package (e.g. llvm) and the compat package (e.g. > llvm18), > we would retire the un-versioned dist-git for llvm, and create a new > versioned dist-git > for each new release (e.g. llvm19, llvm20, llvm21 etc.). We would then > designate one > of these as the 'main version', and that version would produce binary rpms > that look > like the current main package (i.e. llvm-libs instead of llvm19-libs). > Ehh? I guess? I don't think this buys us that much. > * Invert the order of compat/main packages. Instead of having the compat > package be > the old version, and the main package be the new version, we would have the > compat package > be newer and the main package be older. This would allow us to introduce a > new version of > llvm without impacting other packages that depend on the main version of LLVM. > I don't like this idea, it makes things harder to reason about and doesn't actually solve any problems. You also have to do new package reviews for each new version instead of using the compatibility package exception to branch older releases into compatibility packages. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Fedora Miracle Spin (self-contained)
On Thu, Apr 25, 2024 at 5:31 AM Peter Robinson wrote:
>
> On Thu, 25 Apr 2024 at 12:32, Neal Gompa wrote:
> >
> > On Wed, Apr 24, 2024 at 10:49 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Wed, Apr 24, 2024 at 10:33:51PM -0500, Neal Gompa wrote:
> > > > On Wed, Apr 24, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek
> > > > wrote:
> > > > >
> > > > > On Wed, Apr 24, 2024 at 04:57:40PM +0100, Aoife Moloney wrote:
> > > > > > Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
> > > > >
> > > > > > {{package|miracle-wm}} is available in Fedora Linux 40, so it can be
> > > > > > installed on top of something like the existing Sway spin and
> > > > > > configured to reuse much of the tools used there.
> > > > > >
> > > > > > For Fedora Linux 41, once the spin is produced, people can download
> > > > > > and try the experience intended to be released.
> > > > >
> > > > > I applaud people trying out new window managers and doing stuff with
> > > > > Fedora. But the overhead of creating and distributing a spin is quite
> > > > > high… It seems that the contents of this spin would overlap very
> > > > > strongly with Sway Spin. Would it make sense to combine them and
> > > > > allow users to easily select one or the other? Even during boot, there
> > > > > could be two boot menu entries and we could provide simple
> > > > > instructions
> > > > > to switch between the desktops on an installed system.
> > > > >
> > > >
> > > > Aside from actually being unintuitive and confusing to people to smush
> > > > two spins together like that, the experience will eventually differ
> > > > because different tools will be used.
> > >
> > > What tools?
> > >
> >
> > Well, since it's based on Mir instead of wlroots, some Mir specific
> > tooling may be developed. One of the goals is to have Fedora Miracle
> > as a reference platform for showcasing and developing a community and
> > ecosystem around the Mir compositor library.
> >
> > Two things being discussed upstream are how to support server-side
> > decorations and how to support portals. Both of these are going to be
> > Mir specific and at least the portal stuff will likely conflict with
> > another spin's configuration.
> >
> > Miracle has only very slight compatibility with the Sway/i3 IPC, just
> > barely enough for waybar to function. Most of the Sway tooling isn't
> > going to work on Miracle because they rely on that IPC.
> >
> > > > Also, you overestimate the burden of creating a spin. Aside from
> > > > comps, kickstart definitions, and pungi config being done initially
> > > > (which isn't too high to begin with either), the effort required to
> > > > maintain a spin image is extremely low.
> > >
> > > There's also the effort of distribuiting and archiving a few
> > > additional gigabytes, putting up the links on the website and browsing
> > > through them, some additional time and and additional step that can
> > > fail during builds…
> > >
> > > > A large chunk of our spins are essentially semi-automatic these days,
> > > > and people don't really notice because at the end of the day, it's a
> > > > bundle of things configured together.
> > >
> > > Yes. And my point is that we can come up with a hundred or a thousands
> > > of such bundle definitions, and my question is whether we should
> > > create a separate deliverable for each possible definition.
> > >
> >
> > If a SIG is willing to do it and support it, I don't see why not.
>
> There's also QE efforts required to test it, and how many users will
> it even get, is it worth it if there's a dozen users?
Nonblocking spins *don't* get QA efforts aside from community users
who test it and report issues. Of course the users of the spin would
be encouraged to test and help with the evolution of the spin.
The only variants that get QA attention as a matter of course are
GNOME/Workstation, KDE, Server, Cloud, CoreOS, IoT, the base
containers, and the toolbox container.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Fedora Miracle Spin (self-contained)
On Wed, Apr 24, 2024 at 10:49 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Apr 24, 2024 at 10:33:51PM -0500, Neal Gompa wrote:
> > On Wed, Apr 24, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Wed, Apr 24, 2024 at 04:57:40PM +0100, Aoife Moloney wrote:
> > > > Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
> > >
> > > > {{package|miracle-wm}} is available in Fedora Linux 40, so it can be
> > > > installed on top of something like the existing Sway spin and
> > > > configured to reuse much of the tools used there.
> > > >
> > > > For Fedora Linux 41, once the spin is produced, people can download
> > > > and try the experience intended to be released.
> > >
> > > I applaud people trying out new window managers and doing stuff with
> > > Fedora. But the overhead of creating and distributing a spin is quite
> > > high… It seems that the contents of this spin would overlap very
> > > strongly with Sway Spin. Would it make sense to combine them and
> > > allow users to easily select one or the other? Even during boot, there
> > > could be two boot menu entries and we could provide simple instructions
> > > to switch between the desktops on an installed system.
> > >
> >
> > Aside from actually being unintuitive and confusing to people to smush
> > two spins together like that, the experience will eventually differ
> > because different tools will be used.
>
> What tools?
>
Well, since it's based on Mir instead of wlroots, some Mir specific
tooling may be developed. One of the goals is to have Fedora Miracle
as a reference platform for showcasing and developing a community and
ecosystem around the Mir compositor library.
Two things being discussed upstream are how to support server-side
decorations and how to support portals. Both of these are going to be
Mir specific and at least the portal stuff will likely conflict with
another spin's configuration.
Miracle has only very slight compatibility with the Sway/i3 IPC, just
barely enough for waybar to function. Most of the Sway tooling isn't
going to work on Miracle because they rely on that IPC.
> > Also, you overestimate the burden of creating a spin. Aside from
> > comps, kickstart definitions, and pungi config being done initially
> > (which isn't too high to begin with either), the effort required to
> > maintain a spin image is extremely low.
>
> There's also the effort of distribuiting and archiving a few
> additional gigabytes, putting up the links on the website and browsing
> through them, some additional time and and additional step that can
> fail during builds…
>
> > A large chunk of our spins are essentially semi-automatic these days,
> > and people don't really notice because at the end of the day, it's a
> > bundle of things configured together.
>
> Yes. And my point is that we can come up with a hundred or a thousands
> of such bundle definitions, and my question is whether we should
> create a separate deliverable for each possible definition.
>
If a SIG is willing to do it and support it, I don't see why not.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Fedora Miracle Spin (self-contained)
On Wed, Apr 24, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Apr 24, 2024 at 04:57:40PM +0100, Aoife Moloney wrote:
> > Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
>
> > {{package|miracle-wm}} is available in Fedora Linux 40, so it can be
> > installed on top of something like the existing Sway spin and
> > configured to reuse much of the tools used there.
> >
> > For Fedora Linux 41, once the spin is produced, people can download
> > and try the experience intended to be released.
>
> I applaud people trying out new window managers and doing stuff with
> Fedora. But the overhead of creating and distributing a spin is quite
> high… It seems that the contents of this spin would overlap very
> strongly with Sway Spin. Would it make sense to combine them and
> allow users to easily select one or the other? Even during boot, there
> could be two boot menu entries and we could provide simple instructions
> to switch between the desktops on an installed system.
>
Aside from actually being unintuitive and confusing to people to smush
two spins together like that, the experience will eventually differ
because different tools will be used.
Also, you overestimate the burden of creating a spin. Aside from
comps, kickstart definitions, and pungi config being done initially
(which isn't too high to begin with either), the effort required to
maintain a spin image is extremely low.
A large chunk of our spins are essentially semi-automatic these days,
and people don't really notice because at the end of the day, it's a
bundle of things configured together.
--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 40 Elections are now open!
On Wed, Apr 24, 2024 at 11:31 AM Aoife Moloney wrote: > Hello everyone, > > I hope you all are enjoying Fedora 40, and this release also marks the > start of a new election cycle[1]. As of now, the nomination period for > positions on Fedora Council, Fedora Mindshare, FESCo and EPEL Steering > Committee is now open! 🎉 > > We have some slight changes to some elections this cycle, with more detail > available to read on the Elections blog post coming tomorrow as part of the > Fedora Council hackfest mini-series, but for now the main things you need > to know are the following: > > >- We are welcoming the EPEL Steering Committee to our elections cycle! >There are currently four seats available for the EPEL Steering Committee, >so if you or someone you know would like to serve for a term of 12 months >on this committee, you can nominate yourself or someone else on their >candidate nominations page[2]. > > > >- The Fedora Council is moving to a once-per-year election, and we >will be electing two new members for this cycle for a 12-month term. If you >would like to serve on the council, or know someone who would be a great >fit, you can nominate yourself or other(s) on the council nominations >page[3]. > > > >- The Fedora Engineering Steering Committee (FESCo) will have four >seats open this cycle, and will remain on the current twice per year >elections cadence. If you would like to nominate yourself, or someone you >know who would be a great addition to FESCo, you can nominate yourself or >others on their nominations page[4]. > > > >- The Fedora Mindshare Committee has one seat open for this election >term, and their election schedule will also stay on the twice-per-year >cadence. If you would like to get involved, or know someone who would be a >great person to be considered for the Mindshare committee activities like >budget management with the FCA, ambassador work, outreachy work, etc, you >can nominate yourself and/or them now on the nominations page[5]. > > > *Very Important:* Please do not nominate someone for a seat on any of the > above governance bodies without their explicit consent. > > > The nominations period will be open until Wednesday, May 8th and events > during the F40 elections period can be found on the schedule[6]. > > > [1] > https://docs.fedoraproject.org/en-US/program_management/pgm_guide/elections/ > [2] https://fedoraproject.org/wiki/EPEL/Nominations > [3] https://fedoraproject.org/wiki/Council/Nominations > [4] > https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations > [5] https://fedoraproject.org/wiki/Mindshare/Nominations > [6] > https://fedorapeople.org/groups/schedule/f-40/f-40-elections-tasks.html > The nomination pages seem to be locked, I can't edit them? At least not the Council, FESCo, or Mindshare ones. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 RISC-V port needs to put shared objects into /usr/lib64/lp64d
On Wed, Apr 24, 2024 at 8:35 AM Andrea Bolognani wrote: > > On Wed, Apr 24, 2024 at 07:43:08AM -0400, Neal Gompa wrote: > > On Wed, Apr 24, 2024 at 7:16 AM Florian Weimer wrote: > > > > Wouldn't changing -mabi effectively make the result a new Fedora > > > > architecture? IIUC, binaries built with -mabi=lp64d wouldn't be able > > > > to load libraries built with -mabi=lp64dv and vice versa. > > > > > > > > If that's correct, then we can't simply have a single "riscv64" > > > > architecture: instead, we need to call what we have today > > > > riscv64_lp64d, and be ready for riscv64_lp64dv as well as whatever > > > > comes next. > > > > > > Right. > > > > > > > It would be somewhat similar to existing architectures that can be > > > > used in both Little-Endian (ppc64le) and Big-Endian (ppc64) modes. > > > > > > With different paths, it would be more like i686 and x86_64. That is, > > > you can build and run software for both variants from the same operating > > > system image. That's not the case for ppc64 and ppc64le. > > > > As I recall, outside of the x86 family and s390x, all CPU platforms we > > support are actually bi-endian and can have applications operate in > > either mode. So I'm not sure that's a good example other than nobody > > cared to specify parallel install paths for that. > > So would you be able to natively run ppc64 binaries under a ppc64le > kernel? I don't think that'd be possible, but I don't have conclusive > proof so I could be wrong. > > Similarly, would you be able to run riscv64_lp64dv binaries under a > riscv64_lp64d kernel? That doesn't sounds like it would work either. > > And even if it did, you would still be unable to mix and match > binaries and libraries built for the two ABIs, so that makes them > separate Fedora architectures. > That's only the case if we don't have binary loaders that can deal with it. Which admittedly nobody has done on Linux, but it's not unheard of to have mixed ABI loading. In particular the situation of running binaries of one ABI under the kernel of another is something that has been done before even on x86. x32-on-x64 as well as i686-on-x86_64 are both examples of this, as is arm7hl-on-aarch64. That *we* don't do it in Fedora doesn't mean it's not possible. > > > > This is quite different from just bumping the ISA baseline, where > > > > existing binaries and libraries are still usable in the new > > > > environment. > > > > > > Right, changing the vector calling convention may change the size of > > > jmp_buf, and then you have a new ABI even if use of the vector features > > > is optional. > > > > Arguably bumping the baseline should *also* be a new architecture > > because it's a total compatibility break. > > No, you're just cutting off support for hardware that doesn't satsify > the new baseline. Which is obviously not something that should be > done lightly, but at least compatibility with existing binaries is > retained. Changing the ABI means starting from scratch. > Changing the baseline doesn't necessarily imply the ABI doesn't change. The fact that it generally *doesn't* doesn't mean that it *won't*. This is up to the compiler toolchain to handle, and since that's an implementation specific detail, I generally would not make that assumption. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 RISC-V port needs to put shared objects into /usr/lib64/lp64d
On Wed, Apr 24, 2024 at 7:16 AM Florian Weimer wrote: > > * Andrea Bolognani: > > > Wouldn't changing -mabi effectively make the result a new Fedora > > architecture? IIUC, binaries built with -mabi=lp64d wouldn't be able > > to load libraries built with -mabi=lp64dv and vice versa. > > > > If that's correct, then we can't simply have a single "riscv64" > > architecture: instead, we need to call what we have today > > riscv64_lp64d, and be ready for riscv64_lp64dv as well as whatever > > comes next. > > Right. > > > It would be somewhat similar to existing architectures that can be > > used in both Little-Endian (ppc64le) and Big-Endian (ppc64) modes. > > With different paths, it would be more like i686 and x86_64. That is, > you can build and run software for both variants from the same operating > system image. That's not the case for ppc64 and ppc64le. > As I recall, outside of the x86 family and s390x, all CPU platforms we support are actually bi-endian and can have applications operate in either mode. So I'm not sure that's a good example other than nobody cared to specify parallel install paths for that. > > This is quite different from just bumping the ISA baseline, where > > existing binaries and libraries are still usable in the new > > environment. > > Right, changing the vector calling convention may change the size of > jmp_buf, and then you have a new ABI even if use of the vector features > is optional. > Arguably bumping the baseline should *also* be a new architecture because it's a total compatibility break. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 RISC-V port needs to put shared objects into /usr/lib64/lp64d
On Fri, Apr 19, 2024 at 8:23 AM Florian Weimer wrote: > > There are multiple PRs and patches floating around that make RISC-V use > the /usr/lib64 directory, like other 64-bit ports. However, RISC-V > recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and > various upstream projects follow that. > > I think we should follow upstream, so that it's possible to use Fedora > to do upstream development without patching the sources, or elaborate > Fedora-specific configure invocations. The other reasons is to > future-proof the Fedora port against the arrival of an alternative ABI > that is not fully backwards-compatible (the same reason why the official > RISC-V documentation requires use of these paths). > Then we probably need to change the way our arch handling works to encode the ABI too in RPM. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Picking up protobuf
On Thu, Apr 18, 2024 at 3:06 PM Michel Lind wrote: > > Hi Major, > > On 4/18/24 13:25, Major Hayden wrote: > > On Wed, Apr 17, 2024, at 21:51, Michel Lind wrote: > >> Hi all, > >> > >> protobuf was recently orphaned without any announcement to this list. > >> > >> I've picked it up since et depends on it. > > > > Thanks for picking that up, Michel. I intended to mail the list yesterday > > and totally lost track of time. 🤦♂️ > > > No worries! I was wondering who the previous maintainer was - the RHBZ > overrides made it super confusing :) > > > The big challenge we had with protobuf is that updating it broke quite a > > few things built against the old version. But staying put with the same > > version led to problems with newer packages that were coming along day by > > day. > > > Yeah... it might be worth just upgrading in Rawhide and not touch the stable > releases, as Sérgio suggested, > unless there is an urgent security update? We should let maintainers of > protobuf dependents chime in too. > I do the same for capnproto for the same reason. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Replace Redis with Valkey (system-wide)
On Wed, Apr 17, 2024 at 10:43 PM Nathan Scott wrote: > > Hi Neal, > > On Thu, Apr 18, 2024 at 12:29 PM Neal Gompa wrote: > > [...] > > retaining Redis will just hurt us in the long term. > > Noone is saying we should retain Redis. I'm advocating for a more > appropriate transition that is respectful of the work and expertise the > existing package maintainers bring. > > I think f41 is appropriate and possible, but "more haste, less speed" > is the way to get there, with minimal breakage to Fedora and users. > From my perspective, I don't see any breakage happening. We also haven't *done* anything yet. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Replace Redis with Valkey (system-wide)
On Wed, Apr 17, 2024 at 9:52 PM Nathan Scott wrote: > > Hi all, > > On Thu, Apr 18, 2024 at 2:38 AM Maxwell G wrote: > > > > Thank you for submitting this! > > +1 > > > > == Owner == > > > * Name: [[User:jonathanspw|Jonathan Wright]] > > > * Email: jonat...@almalinux.org > > > > It would be nice to have Remi who currently maintains redis on board as > > well. > > > > This is the second time this has been requested, but not yet actioned. > > https://bugzilla.redhat.com/show_bug.cgi?id=2274206 > https://src.fedoraproject.org/rpms/valkey > https://src.fedoraproject.org/rpms/redis > > Can we resolve this before allowing this Change Proposal to proceed, > please? I think its in Fedora's interest to see 'new redis' maintained > by group, rather than an individual, if the existing maintainers wish to > (continue to) be involved. > > The 'new' valkey package is very closely derived from redis packaging > which other Fedora maintainers have been looking after for ~14 years. > > There is no big rush to switch AFAICT though, as Redis[Labs] stated > they continue to provide updates for redis-7.2.4 (including CVE fixes, > which is a big part of the Fedora workload) for the foreseeable future. > On the contrary, we *have* to do it sooner rather than later. As divergence among the forks occurs and the community shifts away, retaining Redis will just hurt us in the long term. Not to mention, now that they've pulled this change on us (after saying they wouldn't five years ago), there's no guarantee that they'd continue to do anything. Their word isn't worth a lot anymore. > Some other technical questions: > - it could be advantageous if the new compat sub-package contained > the redis binary symlinks & not the primary valkey package (this could > allow valkey and redict packages to coexist, for example). Long-term > we may want to drop those entirely (along with the compat package, to > complete the transition away from Redis). We will probably never be able to completely drop this, as stuff may exist for a very long time that needs it. > - what happened to the man page patch Remi made? we should carry > it forward into the new package (and try again with new upstream folks > to get it merged there). That patch should be completely rewritten for upstreaming anyway. It's not written in a maintainable format, which really doesn't help for upstreaming at all. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024 at 5:30 AM Fabio Valentini wrote: > > On Wed, Apr 17, 2024, 08:45 Tim Landscheidt wrote: >> >> Zbigniew Jędrzejewski-Szmek wrote: >> >> > […] >> >> >> - use dynamic buildrequires to detect what plugins are needed >> >> > My problem is that the binary is linked to the libpython3.12.so shared >> > library… The detection part is easy, the hard part is how to have the >> > binary work when the shared lib is not installed. >> >> Quick 'n' dirty: Have two binaries, unconditionally call >> add-determinism-python for *.pyc files, either from >> add-determinism or the BRP macro (which essentially should >> be called when %__brp_python_bytecompile is called?), rely >> on the packager to build-require add-determinism-python or >> require that from python3-devel (the missing binary should >> fail the build otherwise). > > > Something like this could be even made automatic. > > - split Python-specific functionality into a separate binary and subpackage > of add-determinism > - add only add-determinism to the default buildroot > - add "Requires: (add-determinism-python if python3)" to add-determinism > > That way the pyc processing functionality would only be pulled in iff python3 > is already getting installed by something else. Because this is written in Rust instead of Python, you will need a build variant for *every* Python interpreter shipped in Fedora. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'
On Mon, Apr 15, 2024 at 4:56 AM Richard W.M. Jones wrote: > > > Anyone got any idea about this build failure? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=116395331 > > [+] All set and ready to build. > clang: warning: -Wl,-z,relro: 'linker' input unused > [-Wunused-command-line-argument] > clang: warning: -Wl,--as-needed: 'linker' input unused > [-Wunused-command-line-argument] > clang: warning: -Wl,-z,pack-relative-relocs: 'linker' input unused > [-Wunused-command-line-argument] > clang: warning: -Wl,-z,now: 'linker' input unused > [-Wunused-command-line-argument] > clang: warning: -Wl,--build-id=sha1: 'linker' input unused > [-Wunused-command-line-argument] > clang: warning: -ldl: 'linker' input unused [-Wunused-command-line-argument] > clang: warning: -lrt: 'linker' input unused [-Wunused-command-line-argument] > clang: warning: -lm: 'linker' input unused [-Wunused-command-line-argument] > clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for > target 'x86_64-redhat-linux-gnu' > > AFAICT -mtls-dialect=gnu2 is not added by anything in the spec file or > in AFL++ sources, so it must be coming from RPM macros? > It was added a month ago to redhat-rpm-config: https://src.fedoraproject.org/rpms/redhat-rpm-config/c/b7d1bfae1fb673c4d8a21a8866ba4e37b2cd6eaf -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 - Reproducible Package Builds (System-Wide)
On Sat, Apr 13, 2024 at 3:59 AM Richard W.M. Jones wrote: > > On Fri, Apr 12, 2024 at 10:41:43PM +0100, Aoife Moloney wrote: > > [https://github.com/keszybz/add-determinism add-determinism] is a Rust > > program which, as its name suggests, adds determinism to files that > > are given as input by attempting to standardize metadata contained in > > binary or source files to ensure consistency and clamping to > > $SOURCE_DATE_EPOCH in all instances. `add-determinism` is the "Fedora > > version" of > > [https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > strip-nondeterminism] from the Debian project. Since > > strip-nondeterminism is written in perl, it is undesirable for use in > > Fedora, as we don't want to pull perl in the buildroot for every > > package. > > https://github.com/keszybz/add-determinism looks like a package with a > lot of Rust dependencies just to make some small changes to four > different file types. Isn't there an easier way to do this? I would > have thought a Python library would be more suitable as the most > complicated bit is the *.pyc change which is done using Python code. > Considering Debian's version is in Perl, yes, it's quite reasonable to consider that. It could have been written in Python, C++, or even shell (if you truly hated yourself). I'm not a big fan of Rust for this either. But unless someone offers to make another version that is more appealing, this is what we have. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
On Fri, Apr 12, 2024 at 4:54 PM Aoife Moloney wrote: > > Wiki - https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3 > Discussion.fpo - > https://discussion.fedoraproject.org/t/f41-change-proposal-python-built-with-gcc-03-self-contained/112743 > > > This is a proposed Change for Fedora Linux. > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > > > == Summary == > Instead of > [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags > Fedora's default `-O2` compiler flag], we will use `-O3` to build > CPython. > This only impacts the interpreter and Python standard library, not any > 3rd party extension modules built as RPM or on developer machines. > This aligns with the way Python is built upstream. > According to our performance measurements, it makes Python > significantly faster (pyperformance geometric mean: 1.04x faster). > > == Owner == > * Name: [[User:churchyard|Miro Hrončok]] > * Email: mhron...@redhat.com > > > == Detailed Description == > > We will replace the `-O2` compiler flag with `-O3` when building the > python3.13 package. This change may be backported to older Pythons if > desired. [[Changes/Python3.13|Python 3.13 should be the main Python > version in Fedora 41+]]. > > The > [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags > Fedora packaging guidelines] about compiler flags explicitly say: > > ''> Overriding these flags for performance optimizations (for > instance, `-O3` instead of `-O2`) is generally discouraged. If you can > present benchmarks that show a significant speedup for this particular > code, this could be revisited on a case-by-case basis.'' > > This change proposal presents such benchmarks and a case for Python to > use `-O3`. > > This change is limited to CPython interpreter and extension modules > from the Python standard library only thanks to > [[Changes/Python_Extension_Flags_Reduction]] (since Fedora 39). Other > Python extension modules will remain bulidng as before, e.g. in RPM > packages, they will still be built with `-O2`, unless Fedora changes > that globally. The extension modules built with `-O2` still work with > Python built with `-O3`. I would like for us to consider evaluating a global change to -O3. I am not convinced that there's a good reason anymore to remain at -O2. If we get this kind of benefit from Python, I would be interested in seeing what we'd get elsewhere. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: network service removed in Fedora 40 without a Change proposal(?)
On Fri, Apr 12, 2024 at 4:41 PM Adam Williamson wrote: > > Michel Lind just prompted me to notice that the 'network' service > appears to have been removed from initscripts in Fedora 40+. This > change seems to have landed in February without any fanfare - > https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd043b75963f7cac?branch=rawhide > . There is no Change for it, AFAICS. > > This does not appear to be driven by upstream removing it, because the > commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove > it from the build. Presumably without that, it would still be built. > > I'm a bit worried about this arriving unannounced and apparently mostly > unnoticed. There *are* still reasons to use the network service; I > still use it on the openQA worker hosts, for instance, because there is > integration between openvswitch and the legacy network service, but no > integration between openvswitch and NetworkManager. I also use an ifup- > pre-local script to pre-create tap devices; NetworkManager apparently > does not support this natively. There's a suggested workaround at > https://access.redhat.com/solutions/6900331 , which is helpful, but > still, it's a significant change if you're using that mechanism. > > As a user of this service, I would've expected more of a heads-up that > it was going away; if I hadn't happened to catch Michel's message I > might have upgraded openQA staging to F40 immediately on release (as I > usually do) and been rather surprised that the network setup stopped > working. I'm sure I will find a way to re-engineer this rather > complicated network setup without network.service, but a bit more of a > heads up would have been nice. > > Should this have been a Change? How worried are we about it going out > in Fedora 40 without having been through the Change process? This should have been an announced Change. This is a significant change with wide impact. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote: > > > > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a): > > > And we already have a significant fraction of packages using rpmautospec, > > > > > > Actually, could you quantify the "significant fraction"? > > 7399 / 23912 = 31%. > How much of it is non-Rust and non-Go? -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 8, 2024 at 5:22 PM Leon Fauster via devel wrote: > > Am 08.04.24 um 22:22 schrieb Michel Lind: > > On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote: > >> Am 08.04.24 um 20:12 schrieb Michel Lind: > >>> (this might require coordination with RH's Leapp developers and > >>> AlmaLinux's ELevate developers, to make sure those support upgrading > >>> to lower NEVRAs too) > >> > >> Would have a major EL release have a lower package NEVRA? > >> Mmmh, how many fedora releases are in between? :-) > >> > > If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we > > allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a > > Fedora 40 package with epoch reset to 0 (change as suitable - more > > likely to be EL10 from F40 and EL11 from F46, but in general there are 6 > > Fedora releases in between) -- then even if the version is higher > > because the epoch is dropped, the EL(N+1) NEVRA will be lower. > > > Fair enough. Such change could be scoped just for fedora and keeping > the epoch for RHEL (I know it contradicts the plan). Anyway, as far as > I understand it, epoch support will still be available and its not > forbidden to use it, right? For some cases similar to xz-5.6-to-xz-5.4 > downgrades even necessary. Just wondering, why a reset of epoch in > rawhide is desirable? > When the RHEL people notice, they conditionally drop the Epoch for RHEL already. Epochs are not really necessary at all across distribution release boundaries. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote: > > V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek > napsal(a): > > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote: > > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL > > > minor > > > releases). > > > > Hmm, can you provide describe the workflow that is broken in more > > detail? > > > RHEL do updates into older minor distribution versions. E.g. you might want to > build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that > build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading > from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to > the 9.2 build before or not. > > It's bascially the same problem as Fedora has when users upgrade from Fredora > 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade path > between Fedoras is not maintained anymore and users need to do "dnf > distro-sync" to ignore the RPM versioning. > > All that stems from tha fact that a number of commits between parallelly > supported braches is not monotonic. > We did this long before rpmautospec existed. We switched to this behavior in Fedora 23 because we have never fully maintained "upgrade paths" across releases. RHEL is *even worse* in this regard because there is no active testing or handling of distribution upgrades within the distribution itself (hence why no equivalent to fedora-obsolete-packages in CentOS/RHEL), which is why distribution upgrades are the bane of every RHEL admin's existence. The Leapp tooling more or less externally does the same thing now, but that's generally not available to CentOS users. The distro-sync behavior is the right way to handle distribution upgrades, the "upgrade path" is the right way *within* a distribution release. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: "fedpkg local" builds fail for rust packages
On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones wrote: > > On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote: > > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber > > wrote: > > > > > > So you're saying that those packages are in the repos for everyone but > > > not meant to be installed by anyone (besides mock chroots), and that is > > > how and why they are packaged. > > > > Yes. That is the best we can do given how cargo + Rust work. > > > > > `This package contains library source intended for building other > > > packages which > > > use the "xyz" crate.` > > > > So the description matches what I said? > > > > > Unless you `fedpkg local` build it. Or maybe only if you `fedpkg > > > mockbuild` it. Does a rebuild from `fedpkg srpm` even work? > > > > > > Wow! > > > > Sorry to burst your bubble, but "fedpkg local" is an ugly hack > > (independent of Rust peculiarities). > > fedpkg local works fine for almost all cases. > > > And I am not interested in adding workarounds to the Rust packaging > > toolchain to support it. > > > > "fedpkg mockbuild" and "fedpkg srpm" all work as expected ... > > > > > Is there any other set of packages which we package like that? > > > > Probably golang ... maybe Haskell, OCaml? > > OCaml is definitely _not_ packaged like this. ocaml-* and > ocaml-*-devel packages are normal packages that can be installed by > end users if they want, although usually only if they're developing > OCaml software. > Packaged Rust crates work *fine* for local development as long as you are willing to cut yourself off from crates.io. Unlike *every other language package manager*, Cargo does not support multiple concurrent indexes. This is ultimately the bottleneck, and there's been very little interest in resolving this upstream. Upstream issue: https://github.com/rust-lang/cargo/issues/4883 Without this feature, it becomes difficult to do development using packaged crates. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
