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
[EPEL-devel] Re: Contact to Oracle Linux EPEL repo maintainer
On Fri, May 31, 2024 at 9:31 AM Troy Dawson wrote: > > On Fri, May 31, 2024 at 2:48 AM Peter Soppe wrote: >> >> Hello EPEL Team, >> >> I am trying to find out how to contact the maintainer of the Oracle Linux >> EPEL repository. >> The only website I found about EPEL and Contact is >> https://fedoraproject.org/wiki/EPEL/FAQ#contact >> >> My current issue is that I use the Oracle Linux 8 EPEL package "cacti" - and >> there is a security issue that is solved in cacti Version 1.2.27 >> (2024-05-12). >> >> This version is available in the Fedora/RHEL Epel >> https://packages.fedoraproject.org/pkgs/cacti/cacti/ since 2024-05-21 (9 >> days after release) >> but not in the Oracle Linux EPEL: >> https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/x86_64/index.html >> Here the latest available Version is 1.2.23 (2023-01-13) which is about 19 >> months old. >> >> I want to know if there are plans to update the cacti version in the Oracle >> EPEL repo and if yes what is the planned timeline to do so. >> >> Best regards, >> Peter Soppe > > > Although the Oracle Linux EPEL repository has the word "EPEL" in it, it is a > repository supported and maintained by Oracle Linux. Similar to the CentOS > Extras repo. > As such, we can only point you back to the distribution and its community. > > https://support.oracle.com/ > > I did try looking for other information, but everything I found only had a > heading and to get more information I needed to create an Oracle account and > log in, which I am not willing to do. > Last time I talked to the Oracle folks about "EPOL" (as I call it) a few years ago, the main point of contact was Avi Miller (CC'd to this email). He should be able to help out here. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: 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: Handling --enable-experimental-jit in Python 3.13
On Wed, Apr 10, 2024 at 2:23 PM Miro Hrončok wrote: > > Hello Pythonistas, > > Python 3.13 has an experimental JIT compiler: > > https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler > > Enabling it is a configure (hence build-time) option. > > How do we handle this in Fedora? > > - We can keep it disabled, as it is experimental. > - We can enable it, but be ready to revert if it causes problems. > - We can add yet another build variant, but we already have 4 of those > (regular, debug, freethreading, freethreading-debug), so I'd rather not make > it > 6 (or 8, if we include freethreading+jit combinations). I don't know yet if it > would be co-installable. > > Opinions? > I lean toward just going ahead and shipping it and reverting if it causes enough problems that cannot be fixed. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On 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
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> > I wrote:
> > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
> > >> detection of python, and it found /usr/bin/python3.13t that I have
> > >> installed, and subsequently it got all the paths wrong.
> > >
> > > That's why you should never build packages outside of mock.
>
> That's another way of saying "it's broken" ;]
> Mock is great, but I'm doing local development and a local build
> against my envirnoment is what I need.
>
> > PS: Autotools also loves to autodetect random libraries that happen to be
> > installed on the system. It is in no way specific to CMake.
> >
> > >> How do I override this?
> > >> ('cmake -LAH' doesn't yield anything useful.)
> >
> > Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake for
> > the variables it uses. (First, try to figure out whether RPM is using a
> > system-installed FindPython or its own custom version, so you look at the
> > correct version.)
>
> Exactly. I'm sure it doable, but CMake ecosystem somehow doesn't
> want to integrate with the Linux userspace in the normal way.
>
You know that pkgconfig *also* uses variables too, right? It's
perfectly "normal" to do it this way. Arguably, the fact that every
variable is known and saved in the CMakeLists and CMakeCache data for
you to read is a boon, because if you need to know a variable to
override, you can find it easily in the logs.
And this your statement on normalcy is silly since we don't *have* a
normal way. The GNU Build System (Autotools), Meson, and CMake all do
things differently, and all three have significant share in our
packages. Projects that use plain Makefiles are even *more*
non-standard, as they do whatever they want 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: convert everything to rpmautospec?
On Sun, Apr 7, 2024 at 11:16 AM Zbigniew Jędrzejewski-Szmek wrote: > > Hi everyone, > > I'm revisting the topic of rpmautospec because I was doing some work > on various packages, and it's annoying that some packages are using > rpmautospec and others are not. > > All my packages have been converted, so in day-to-day work, I don't > even think about %changelog. When working with other packages, I'll > forget to update the Relase and/or %changelog. Today I was rebasing > some pull requests in pagure, and the _only_ conflicts that I had were > about Release and %changelog. > > I think it's time to switch to rpmautospec completely. > Thus, the proposal: > - new packages MUST use rpmautospec > - packagers SHOULD convert their packages > - provenpackagers MAY convert existing packages > (e.g. when they want to push some fix or separately from other >work) > - people submitting pull requests against src.fp.o MAY also > include a conversion in the pull request and packagers SHOULD > merge it. > > (FTR, 'rpmautospec convert' does the conversion, incl. the commit > to dist-git. Manual conversion should not be used.) > No. I do not want to use rpmautospec as it currently exists. It does not help me. It does not achieve anything for me. It breaks my packages for building outside of Fedora Koji. It doesn't even make things better for supporting automation. I do not want to use it unless I absolutely have to (e.g. Rust packages since rust2rpm sets it up that way). -100. No. I do not want to use this unless it is finally fixed to enable rebuild automation. And since that will not happen anytime soon, I have no compelling reason to use it and tremendous disadvantages otherwise. It makes building things in COPR terrible, it makes building things locally annoying, and I can't use it at all reasonably in non-VCS oriented build systems. -- 真実はいつも一つ！/ 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: Fedora Plasma Workstation (System-Wide)
On Fri, Apr 5, 2024 at 3:03 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Apr 04, 2024 at 04:26:52PM -0700, Adam Williamson wrote: > > On Thu, 2024-04-04 at 18:35 -0400, Neal Gompa wrote: > > > On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > > On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote: > > > > > So here are three brainstorming proposals: > > > > > > > > > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to > > > > > be > > > > > careful about how we do it. I would still promote Fedora Workstation > > > > > as the > > > > > main/recommended "leading" desktop, would call Plasma an "alternative > > > > > desktop option," and would strongly caution against use of the word > > > > > "Workstation" anywhere in the branding for the Plasma version. That > > > > > is, > > > > > let's continue to steer undecided users towards Fedora Workstation, > > > > > while > > > > > making Plasma easier to find and presenting it more prominently than > > > > > it is > > > > > today. > > > > > > > > I like this proposal. It would give the KDE spin more prominence and > > > > would be a good reply to the huge work that has been put into the spin > > > > in recent times. It also wouldn't disrupt our story about Fedora > > > > Workstation. > > > > > > > > If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be > > > > confused with Fedora Workstation. > > > > > > > > > > So, effectively no change other than it moves from the Spins section > > > to the Editions section? That would also mean it should be on the > > > front page too, like the other Editions. > > > > Being an Edition is a very significant thing, though, as we conceive of > > Fedora more widely than just the download page. We put a bunch of hoops > > in the way of IoT and CoreOS becoming editions, and there are hoops in > > the way of Silverblue becoming one (or, you know, wherever we go with > > that path in the end). > > My silent assumption was that the current change proposal would be > withdrawn and replaced by a new proposal. We have a formal procedure in [1]. > Looking at that list, it seems all fine. The only sticky point is whether > KDE desktop serves a different purpose than Workstation with GNOME. > I'd say it does: desktop preferences are like religion, and people don't > just switch (except when they do). > > [1] > https://docs.fedoraproject.org/en-US/council/policy/edition-promotion-policy/ > I have asked that the proposal only be withdrawn once an alternative arrangement has been successfully made[1]. I don't expect it to be withdrawn until that is figured out, since Matthew Miller didn't promise anything to resolve the underlying request to make Fedora KDE Plasma Desktop as visible as Fedora GNOME Workstation[2]. [1]: https://discussion.fedoraproject.org/t/111343/44 [2]: https://discussion.fedoraproject.org/t/111343/41 -- 真実はいつも一つ！/ 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: Fedora Plasma Workstation (System-Wide)
On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote: > > So here are three brainstorming proposals: > > > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be > > careful about how we do it. I would still promote Fedora Workstation as the > > main/recommended "leading" desktop, would call Plasma an "alternative > > desktop option," and would strongly caution against use of the word > > "Workstation" anywhere in the branding for the Plasma version. That is, > > let's continue to steer undecided users towards Fedora Workstation, while > > making Plasma easier to find and presenting it more prominently than it is > > today. > > I like this proposal. It would give the KDE spin more prominence and > would be a good reply to the huge work that has been put into the spin > in recent times. It also wouldn't disrupt our story about Fedora Workstation. > > If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be > confused with Fedora Workstation. > So, effectively no change other than it moves from the Spins section to the Editions section? That would also mean it should be on the front page too, like the other Editions. > > (b) Alternatively, elevate the positioning of all spins on the > > fedoraproject.org homepage. Place the link to the spins right next to the > > link to Fedora Workstation, above the atomic desktops (which are sadly still > > experimental), above the Fedora labs and ALT downloads, and honestly > > probably above the non-desktop Fedora editions. Nobody is going to be > > confused as to which one is the primary product. > > I'm not sure. I think the getfedora.o page could use some work, but > just moving one or two things might not be enough. For me, when using > the website is the huge list semi-orthogonal categories: > the top-level split is: > - editions, as individual items > - atomic desktops > - spins > - labs > - alt downloads > Alt downloads is split into: > - Fedora 40 beta > - network installer > - torrent downloads > - alternate architectures (even though download pages also have > architectures?) > - cloud base images > - testing images > - rawhide > The Fedora Spins looks great, IMO. > The Fedora Labs page looks nice too. > > There's also a visual split > I also always struggle to find Beta releases when I need them. > In some places there's a banner with a link, in other places there's a toogle. > > And there are at least three domains: > getfedora.org, fedoraproject.org, alt.fedoraproject.org. > > This is hard to navigate. It seems that each subpage uses a different > categorization and way to split things. And the different subpages > use different visual styles. > > I think we should have: > a) one domain > > b) a flat categorization where you first select the type > (one of the editions or the desktops or spins or labs or network > installer or cloud image). > > The editions should be listed prominently, and the other things can > lower in the page or require a click to show. > > c) at all subpages there should be a toggle button to show > pre-release > > d) once you know what to download, you can see > the architecture and format options and torrent vs. iso. > > In such a structure the same "procedure" would be used to navigate > different choices, making it easier to figure out what all the options > are. > There are only two artifacts left on alt.fedoraproject.org that really need to be moved to the main site: - the Everything netinstall ISO - the Fedora base container images We should maybe consider adding the torrent downloads to the main site, I guess? The alternative architecture images page needs to be decommissioned, as it's redundant with the content on the main site. The rest of alt.fedoraproject.org is probably fine as it is, as I doubt we want to put Rawhide somewhere on the main site. (Also, as an aside, I learned that Workstation has a ppc64le ISO, I guess we should ensure KDE has one too, it's not like we don't have it for Kinoite already.) -- 真実はいつも一つ！/ 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: Fedora Plasma Workstation (System-Wide)
On Thu, Apr 4, 2024 at 4:38 AM Vít Ondruch wrote: > > > Dne 04. 04. 24 v 0:44 Kevin Kofler via devel napsal(a): > > Leon Fauster via devel wrote: > >> I already had RHL installed on a Sun IPX with Gnome, so I'm biased. > > Interesting that you were not put off by the changes that have happened to > > GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was > > actually pretty good. (It was very configurable back then. Remember when it > > shipped Enlightenment as the window manager, how many options that had?) > > Then GNOME 2 came, removing much of the configurability of GNOME 1. And then > > GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME > > 2, leading to a very hardcoded experience. GNOME 2 was already too much for > > me, and I switched back to KDE, back because I had already tried KDE 1.1.1 > > on another distro. And I have never looked back. > > > > Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it > > out once. But it took less than 10 minutes for me to realize that it is not > > for me. The user experience is just too unfamiliar (the unified application > > menu and open window selector (launch menu AND task bar replacement), the > > always maximized windows, the lack of a system tray, the shut down options > > in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does > > not make it easy for you to change it. (You can actually get a pretty > > standard desktop experience nowadays if you install a lot of "unbreak this", > > "unbreak that" GNOME Shell extensions, but that kinda defeats the point of > > GNOME.) The default experience felt pretty much unusable to me personally. > > > Uh, from your description, I would really have hard time to decipher you > are talking about Gnome 3. > > "the always maximized windows" what is this about? Maybe you are missing > some maximize/normalize buttons. > By default, GNOME only presents the close window button. The other buttons are missing, and there isn't really an intuitive way to discover the other window management actions. > "the shut down options in the mouse menu hidden behind a keyboard dead > key, etc.)" this is also not the case for ages, or at least not in its > completeness. > Yes, this did change a few GNOME releases ago. -- 真実はいつも一つ！/ 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: Fedora Plasma Workstation (System-Wide)
On Wed, Apr 3, 2024 at 12:22 PM Michael Catanzaro wrote: > > > > On Tue, Apr 2 2024 at 06:18:31 PM -07:00:00, Adam Williamson > wrote: > > I mean, we really don't need to speculate about this much. We did an > > entire overhaul of the project - Fedora.next - which was explicitly > > based around making it much more focused and less of a > > choose-your-own- > > adventure, specifically including making the download page much more > > opinionated. AFAIR, the numbers Matthew tracks strongly indicate this > > was associated with a very significant immediate bump in Fedora usage. > > Yes, promoting Fedora Workstation over all the other desktops has been > key to the success of Fedora over the past 10 years. I suspect it was > the right choice, because Fedora has grown considerably from our > unrelenting focus on attracting so many GNOME desktop users to the > Fedora edition that receives the most investment. But there is a > continuum of strategies we can use to promote our default desktop over > other options, and I wonder if we've erred too far in favor of Fedora > Workstation and against Fedora KDE Plasma Desktop here. The Plasma spin > is much "bigger" than the other spins, it's of comparable quality to > Fedora Workstation, and it is release blocking. It just seems strange > to relegate it to a secondary downloads page regardless of how popular > it is, while the non-desktop editions (some of which are frankly > relatively niche) get featured very prominently. > > I'm not sure what the solution is here. Kevin's suggestion of featuring > all spins equally risks overloading users with difficult choices and > diluting our focus on what we do well, and I hesitate to open the doors > for all spins to request a place on the main download page. I suppose I > think of KDE Plasma as "special" relative to all the others due to its > relatively large upstream developer community and user base, so I guess > I'd like to see some way to elevate the status of Plasma in Fedora > without also jeopardizing the special status of Fedora Workstation. We > should have a very compelling reason if we're going to continue hiding > one of our strongest products, and I don't think we do anymore. Our > reputation as a quality GNOME distro has become so strong that it's not > going to be damaged by other Fedora desktop offerings. > > So here are three brainstorming proposals: > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to > be careful about how we do it. I would still promote Fedora Workstation > as the main/recommended "leading" desktop, would call Plasma an > "alternative desktop option," and would strongly caution against use of > the word "Workstation" anywhere in the branding for the Plasma version. > That is, let's continue to steer undecided users towards Fedora > Workstation, while making Plasma easier to find and presenting it more > prominently than it is today. > What would be wrong with "Fedora GNOME Workstation" and "Fedora KDE Plasma Desktop"? I think once we're both at the same level, the desktop name as a distinguishing property is valuable. > (b) Alternatively, elevate the positioning of all spins on the > fedoraproject.org homepage. Place the link to the spins right next to > the link to Fedora Workstation, above the atomic desktops (which are > sadly still experimental), above the Fedora labs and ALT downloads, and > honestly probably above the non-desktop Fedora editions. Nobody is > going to be confused as to which one is the primary product. > I think this would be rather chaotic, but I do think we need something to show that the spins exist more. I suspect that a big part of why some of them languish and fade is the lack of visibility. It makes it a foregone conclusion, which is a huge problem with how we handle non-edition variants in general. > (c) Do both of the above, because they aren't mutually exclusive > proposals. > Indeed. -- 真実はいつも一つ！/ 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: Self Introduction: Matthew Kosarek
On Tue, Apr 2, 2024 at 3:44 PM Matthew Kosarek via devel wrote: > > Hello all, > > My name is Matthew (Matt) Kosarek and I am a developer on the Mir team at > Canonical. I am currently developing a tiling window manager based on Mir > called miracle-wm (https://github.com/mattkae/miracle-wm). The goal is to > have a tiling experience similar to sway/i3, but with a bit more flair by > default. I am in the process of packaging the project for Fedora at the > moment, which is why I am introducing myself here. Here's a link to the > review request for miracle-wm: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2272744. Feel free to > check out the project and file bugs/feedback if you have any! I am aiming to > have release 0.2.0 later this month > > Nice to meet you all, > Welcome to Fedora, Matt! I've picked up your package to review. I hope you have a great time here. :) -- 真実はいつも一つ！/ 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: Three steps we could take to make supply chain attacks a bit harder
On Tue, Apr 2, 2024 at 4:59 AM Florian Weimer wrote: > > * Richard W. M. Jones: > > > I'm not pretending these will solve everything, but they should make > > attacks a little harder in future. > > > > > > (1) We should routinely delete autoconf-generated cruft from upstream > > projects and regenerate it in %prep. It is easier to study the real > > source rather than dig through the convoluted, generated shell script > > in an upstream './configure' looking for back doors. > > > > For most projects, just running "autoreconf -fiv" is enough. > > > > Yes, there are some projects that depend on a specific or old version > > of autoconf. We should fix those. But that doesn't need to delay us > > from using autoreconf on many projects today. > > Not shipping the m4 files and other artifacts required for regenerating > autoconf scripts is not exactly rare, unfortunately. I have filed a > bunch of bugs because it's my understanding that this incomplete source > code is against Fedora policies, but in the end, there isn't much we can > do about it. > > But I sympathize with this approach, we should build from sources as > much as we can. Maybe not regenerate everything in %prep though, this > really belongs into %build. It's invoking a compiler, after all. > We have a %conf stage for this purpose. We should start using 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: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 1, 2024 at 12:22 PM Adam Williamson wrote: > > On Mon, 2024-04-01 at 10:56 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote: > > > Adam Williamson wrote: > > > > Maybe this needs to go on the growing pile of reasons why the > > > > traditional Linux model *does* need to go away. Maybe Fedora, with its > > > > foundation of First, should be kind of at the forefront of making that > > > > happen. > > > > > > Switching to a container-based model is just going to introduce more > > > different library versions (in the worst case, one per container) with a > > > higher probability that one of them is compromised. > > > > Our traditional distro model is not perfect — far from it — and we > > certainly try to improve it. But I agree with Kevin that in _this > > particular case_, the other models have smaller chances of catching > > the issue. > > > > Here the upstream was compromised, so 2FA, upstream signatures, and any > > other checks don't help at all. > > Yes, to be clear, my "this" was not "the specific technical details of > this attack". It was more: > > i) the factors I listed in my email about just how many people are > trusted to build 'Fedora', when 'Fedora' is essentially a collection of > arbitrary scripts executed as root > > ii) the fact that this attack reinforces the painful truth that > sophisticated attackers *are* extremely interested in attacking the > supply chain of which we form a significant component Can we please reframe it for what it actually is? This is an attack on open source communities. "Supply chain" implies a lot of things that simply don't exist in open source development. Almost the entirety of the sophistication of the attack was social engineering, not technical engineering. There *are* technical things to improve, for sure, but let's not try to make it sound like it's a wholly technical thing that can be solved with technical solutions exclusively. There are people and community problems that need addressing 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: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote: > > On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote: > > > Adam, > > > > > > Is there a way already to achieve test isolation during the rpm build? > > > > Nothing systematic that I'm aware of, no. It would be tricky because > > there is no one universal Standard Test System (not even within a > > single language ecosystem, let alone across all of them). Currently > > you'd have to design something unique, if you wanted to implement this > > for your package. > > If we wanted to pursue that, I'd suggest the following: > remount $RPM_BUILD_ROOT read-only for the %check phase > (or maybe overmount it with a writable overlayfs that is thrown > away after %check finishes, and warn if any modifications were made.) > %check is executed after %install, so everything should be in place > before %check, and %check may be skipped, so no modifications to > installed files should be done in %check. > > Considering possible implemention details, machinectl has 'bind' and > 'bind --read-only' that might be useful here. But mock uses > systemd-nspawn in a way that does register the container with machined. > So maybe it'd be more reasonable to just execute a mount command directly > from mock. > > This is independent of the test system and does not require splitting > of the test sources. > Another thing to consider is making RPM unshare each build phase like it can for scriptlets now at install time[1]. Sandboxing and limiting in rpmbuild itself like we can with rpm can also help with this. I believe moss[2]' boulder tool does this. [1]: https://github.com/rpm-software-management/rpm/pull/2666 [2]: https://github.com/serpent-os/moss/tree/main/boulder -- 真実はいつも一つ！/ 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: Three steps we could take to make supply chain attacks a bit harder
On Sun, Mar 31, 2024 at 7:36 AM Arthur Bols wrote: > > On 31/03/2024 13:03, Kevin Kofler via devel wrote: > > This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for > contributors for a while, starting with "important" projects, then getting > stricter and stricter. It has done absolutely nothing to stop this attack. > How could it, when the backdoor was apparently introduced by the authorized > maintainer? (Or if not, the attacker must have had access to their 2FA > secret as well.) So, 2FA DOES NOT SOLVE THIS PROBLEM! STOP FORCING 2FA ON > US! And especially DO NOT abuse this incident as an excuse to force 2FA down > our throats, since 2FA DOES NOT SOLVE THIS PROBLEM. Sorry for being > repetitive, but you were, too. THIS 2FA NONSENSE NEEDS TO STOP! > > > 2FA for Fedora packagers doesn't solve this issue, but that wasn't Adam's > point. What Adam is saying is that we're in danger of focusing too much on a > specific issue while we should spent our time and energy on the general > security aspect of Fedora. 2FA isn't nonsense, it strengthens security by a > lot. A compromised (proven)packager account can do a lot of harm and can take > a while to be noticed. If this would happen to us, Fedora's reputation would > tank immediately. Mint is still regarded as a insecure distro (in my circles) > for things that happened before I even entered the linux scene... > > Like it or not, this is 2024 and passwords are not as secure as they used to > be. Yelling about it isn't going to solve anything. Meanwhile, enabling 2FA > helps A LOT even if used incorrectly (e.g. storing it in the same keepassxc > database). > At this point, I'm used to MFA for stuff (and I use a password manager that handles 2FA OTPs too), but the Fedora implementation of MFA is uniquely bad because we have to do a lot in the terminal, and our MFA implementation sucks for terminal usage. If MFA is turned on: 1. The Fedora account integration in GNOME breaks 2. You need to concatenate password and OTP for getting a krb5 session ticket 3. The recovery mechanism involves GPG signed emails The experience using 2FA for Fedora accounts is sufficiently unpleasant that I really don't want to 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: xz backdoor
On Sun, Mar 31, 2024 at 6:50 AM Kevin Kofler via devel wrote: > > Kevin Fenzi wrote: > > Branched enables updates-testing... so if you installed f40 anytime, you > > will have it enabled and if you then applied updates it would be in them > > Yet another thing I always said was a bad idea, and this incident proves it. > This would have been filtered before reaching most people if we made people > only test what actually ends up in the composed Beta and Final images, i.e., > updates that made it out to stable. In addition, having updates-testing > enabled makes it unsafe to upgrade a Beta installation to Final because > suddenly updates-testing gets disabled, but people still have packages from > updates-testing (such as the backdoored xz, but also tons of untested > packages or ones that explicitly failed testing) installed. > Well, an easy solution is to make it so "dnf update" is coerced to "dnf distro-sync" for development releases. Then it doesn't matter. We could make that happen for Fedora 41 with the DNF 5 transition (there's already code to make this possible with PackageKit with the current DNF backend, it needs to be migrated into DNF 5). Disabling updates-testing is a bad plan, because we want updates more aggressively tested during the development cycle. -- 真実はいつも一つ！/ 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 12:10 PM Richard W.M. Jones wrote: > > On Sat, Mar 30, 2024 at 02:44:32PM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Mar 30, 2024 at 08:23:48AM -0400, Neal Gompa wrote: > > > On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel > > > wrote: > > > > > (At which point I'd suggest it's probably faster to convert it all to > > > > > meson or another new shiny, and saner, build system, but getting > > > > > upstreams > > > > > to agree will be fun) > > > > > > > > CMake! :-) > > > > Meson outclasses CMake in functionality, clarity, and brevity. > > I doesn't make sense to consider switching to CMake at this point. > > Which is the better build system doesn't much matter here, as they all > let you run shell scripts so source level backdoors could be inserted > in all of them. > > The big difference they all have over autoconf is that they don't > usually distribute a giant obfuscated (basically binary) shell script. > > We can fix autoconf now by running autoreconf and we don't need to > boil the ocean to do so. > > > > > This drags in libsystemd > > > > for sd_notify, and libsystemd is linked to way too much stuff including > > > > liblzma. Either we need a split libsdnotify that contains only > > > > sd_notify, or > > > > we should just stop using sd_notify at all. It increases the attack > > > > surface > > > > of daemons a lot just to allow the service to be "Type=notify" rather > > > > than > > > > one of the other available approaches. Arch Linux is also systemd-based > > > > nowadays, but still does not link OpenSSH against libsystemd. > > > > > > > > > > This is related to philosophical differences between Arch and Fedora. > > > > > > That said, it probably makes sense for sd_notify to be its own library > > > instead of being part of libsystemd. I'm sure systemd upstream will > > > consider it now. :) > > > > I don't think a separate library would be particularly useful. > > sd_notify() as used by sshd just writes a static string to a unix > > socket. This can be implemented in ~10 lines of C, including error handling. > > > > If that is the _only_ thing needed from libsystemd, then open-coding it > > is a good option. I guess it'd make sense for systemd to provide a header > > file that provides a reference documentation as an inline function. > > I think systemd should do this, just so we have one implementation, > and not loads of buggy ones. > > > One thing which is happening, mostly for unrelated reasons, it that > > systemd code is being changed to use dlopen() for various libraries which > > are usually not needed at runtime. The primary motivation for this is to > > omit such libraries from the initrd. But this also helps with overlinking. > > > > In systemd git main, libsystemd is only linked to libc, libcap, > > and libgcrypt + libgpg-error. A pull request to convert that that last > > pair to dlopen is under review. > > Also a good change, thanks. > Note that dlopen() doesn't fix the problem of the giant libsystemd in the first place. It just obfuscates the true dependency graph of libsystemd. Long ago (I think like ~10 years ago), libsystemd was actually several separate smaller libraries. Perhaps we could consider asking upstream to switch back to that model? -- 真実はいつも一つ！/ 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 11:36 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Mar 30, 2024 at 10:02:42AM -0500, Michael Catanzaro wrote: > > On Sat, Mar 30 2024 at 02:55:21 PM +00:00:00, Zbigniew Jędrzejewski-Szmek > > wrote: > > > CMake for many years fought against pkgconf and pushed people towards > > > copying those scripts into sources. It is still very common for projects > > > using CMake to come with a whole directory of badly written detection > > > scripts that each replace a single-line pkgconf invocation. > > > > > > And of course nobody has time to look into those scripts, making it > > > easy to smuggle something through there. > > > > It's still better than Autotools, though. If a project doesn't want to > > switch to Meson for whatever reason, then CMake is a reasonable alternative. > > > > I agree that CMake is not as good as Meson, and that CMake find modules are > > inferior to pkg-config. > > But then we shouldn't describe them as equivalent alternatives ;) > If we say "switch to a modern build systemd, e.g. cmake or meson", > people will randomly choose on or the other and since the whole CMake > ecosystem is built around find modules, we'll end with a bazillion of > those. > > Instead we should say: "Use meson. If you can't for some reason, consider > CMake, but come talk to us first." > Meson's own module instability and lack of extensibility make it unsuitable for a wide range of projects, especially complex ones. The lack of stability in Meson itself is so bad that Meson upgrades break GNOME, libvirt, and others. And the lack of extensibility is an anti-feature. It means that Meson cannot scale to the infinite world of project needs because everything has to be bent around it or hacks need to be written in the projects to work around its weaknesses. No way would I personally recommend it. I'm not going to go as far as to recommend one explicitly over the other from a distribution perspective, but personally I would never choose Meson anymore. -- 真実はいつも一つ！/ 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 11:47 AM Miroslav Suchý wrote: > > Dne 30. 03. 24 v 1:25 odp. Chris Adams napsal(a): > > Using a signed tarball is ideally better than a git tag (it's an extra > level of author attestation). > > In this case signed tarball would not help at all. And git-tag would prevent > this attack. > Only because that person didn't think to check it in and tag it. They very well could have since they had direct commit access. -- 真実はいつも一つ！/ 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 8:53 AM Kevin Kofler via devel wrote: > > Neal Gompa wrote: > > This is not helpful in the slightest and the tone is not appreciated at > > all. > > Well, I have been arguing against this exception (exempting prebuilt > autotools output) from the "no prebuilt blobs" rule for years, and it > saddens me that something like this had to happen for Fedora to finally > realize that that exception has always been a bad idea. > > > That said, this is being tracked by the Packaging Committee: > > https://pagure.io/packaging-committee/issue/1350 > > Finally, thanks! (But you filed that only now after this incident, see > above. Still, thanks that you are bringing this up now!) > > > Yes, we should scrutinize things like this. Though I will note that we > > didn't actually suffer an attack through this venue with library code, > > just the build scripts. Generally, people do not pay attention to > > build scripts, and that was how this slipped by for so long. But even > > so, Autotools is particularly difficult to understand and I don't > > think we would have ordinarily caught it anyway. > > I definitely agree there, build scripts are indeed an attractive target for > backdoor authors, and autotools is indeed a big part of the problem. > > The whole architecture of autotools was designed for a situation that is > mostly obsolete these days: people running some proprietary Unix with some > buggy implementation of a Bourne-like shell and no centralized build tools > who want to just untar a tarball and build it with only what they already > have installed (the buggy shell). Hence all this concept of shipping > prebuilt obfuscated shell blobs full of workarounds for bugs in ancient > shell implementations. Nowadays, people are either running GNU/Linux, where > centralized build tools such as CMake or Meson are readily installable from > the repository (and where most builds are done by distributions, for whom it > is just a matter of adding, e.g., "BuildRequires: cmake"), or Microsoft > Windows, where an environment that can run autotools scripts (e.g., MSYS2) > is NOT part of the system and actually as hard or harder to install than > something like CMake. So, nowadays, pregenerating shell scripts is a > completely outdated and unhelpful way of working. > And in CMake's favor, there's a huge ecosystem of helpers and integrations that make it easier for people to understand what CMake is doing as it's being developed, built, and shipped. That makes it much more attractive than Autotools simply because the knowledge and the tooling is there for developers and users to dig into it. > > That said, I agree that pretty much every display manager and > > compositor for every Fedora variant should be critpath'd. > > Well, where we disagree is that I actually want to see LESS stuff in > critpath, not more. It cannot be scrutinized well enough because there is > just too much stuff in it. E.g., at times, we had MySQL/MariaDB in critpath > because Akonadi required it. (Nowadays, Akonadi actually recommends using > SQLite instead.) That just does not make sense. > I didn't say every single one we package, just the ones shipped in deliverables. I think it's worth making sure those are on the critpath. -- 真実はいつも一つ！/ 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel wrote: > > Dominique Martinet wrote: > > I'm not 100% sure about the theory, but it looks like `autoreconf -fi` > > looks at the 'serial' in the first line of the script. > > The one bundled in the xz sources was marked very high: > > # build-to-host.m4 serial 30 > > But the one in the system (as of f39) is only 'serial 1'. > > > > Artificially lowering the serial back to 0 in the file and running > > `autoreconf -fi` again properly reinstall the one from the system over > > it, but anything higher will keep it... > > > > So if we want to go this route, we should remove the full m4 dir, but > > unfortunately I've seen quite a few projects that depend on non-standard > > m4 scripts so we'll need to fix these as we go... > > Well, it all depends on whether those m4 scripts are really source code or > whether they are autoimported from somewhere like gnulib. True source code > needs to be retained, anything that can be autoimported should be > autoimported at build time. (And upstreams should stop using imported > copylibs to begin with, but that is a different story.) > > > (At which point I'd suggest it's probably faster to convert it all to > > meson or another new shiny, and saner, build system, but getting upstreams > > to agree will be fun) > > CMake! :-) > Funnily enough, xz can also be built with CMake. :) I don't know whether the CMake scripts are complete enough to switch to yet, but we should consider doing it. > >> (2) We should discourage gnulib as much as possible. > >> [...] > >> In the xz case it was a gnulib-derived script which was modified to do > >> the initial injection (original: > >> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). > > > > (Honestly I did compare the backdoored script and the real one this > > morning and I would be hard pressed to say if either is backdoored just > > looking at either version... Admitedly it was 3AM when I looked at it, > > but I don't think it's just a late hour problem) > > That is exactly the problem with autotools code, almost nobody understands > what the heck it does, almost everybody just copies and pastes somebody > else's snippet hoping it does not do bad things. And gnulib is a > particularly ugly piece of the puzzle. > > > Before making each of these safer we should make sshd not link with so > > many things in the first place. > > Indeed. E.g., Arch Linux does not transitively link sshd against liblzma. > Fedora does because of this innocuous-looking patch: > https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch > which is what ultimately allowed this to happen. This drags in libsystemd > for sd_notify, and libsystemd is linked to way too much stuff including > liblzma. Either we need a split libsdnotify that contains only sd_notify, or > we should just stop using sd_notify at all. It increases the attack surface > of daemons a lot just to allow the service to be "Type=notify" rather than > one of the other available approaches. Arch Linux is also systemd-based > nowadays, but still does not link OpenSSH against libsystemd. > This is related to philosophical differences between Arch and Fedora. That said, it probably makes sense for sd_notify to be its own library instead of being part of libsystemd. I'm sure systemd upstream will consider it 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 7:54 AM Kevin Kofler via devel wrote: > > Richard W.M. Jones wrote: > > (1) We should routinely delete autoconf-generated cruft from upstream > > projects and regenerate it in %prep. It is easier to study the real > > source rather than dig through the convoluted, generated shell script > > in an upstream './configure' looking for back doors. > > > > For most projects, just running "autoreconf -fiv" is enough. > > > > Yes, there are some projects that depend on a specific or old version > > of autoconf. We should fix those. But that doesn't need to delay us > > from using autoreconf on many projects today. > > I have always said that. We do not allow other prebuilt binary blobs and > require rebuilding everything from source. I do not see how the obfuscated > autogenerated shell scripts from the autotools are any different. Sadly, I > was ignored. Now you folks (Fedora) see where this leads. Told You So. > This is not helpful in the slightest and the tone is not appreciated at all. That said, this is being tracked by the Packaging Committee: https://pagure.io/packaging-committee/issue/1350 > > In the xz case this wouldn't have been enough, it turns out we would > > also have to delete m4/build-to-host.m4, which then autoreconf > > regenerates. I don't fully understand why that is. > > Looks like autoreconf does not work as advertised. With -f, it is supposed > to regenerate all files that it knows how to regenerate. It clearly does not > do what it is supposed to and ought to be fixed. > > > (2) We should discourage gnulib as much as possible. > > > > In libvirt we took the decision a few years ago to remove gnulib. > > It's extremely convoluted and almost no one understands how it really > > works. It's written in obscure m4 macros and shell script. > > > > It's also not necessary for Linux since gnulib is mainly about > > porting to non-Linux platforms. There are better ways to do this. > > > > In the xz case it was a gnulib-derived script which was modified to do > > the initial injection (original: > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). > > There too, I agree completely. Also because gnulib is a "copylib", which is > a very broken concept. A true library would not be subject to this kind of > "take the file from the copylib and inject bad code into it" attack. > Yes, we should scrutinize things like this. Though I will note that we didn't actually suffer an attack through this venue with library code, just the build scripts. Generally, people do not pay attention to build scripts, and that was how this slipped by for so long. But even so, Autotools is particularly difficult to understand and I don't think we would have ordinarily caught it anyway. > > (3) We should have a "security path", like "critical path". > > > > sshd is linked to a lot of libraries: > > > > /lib64/libaudit.so.1audit-libs > > /lib64/libc.so.6glibc > > /lib64/libcap-ng.so.0 libcap-ng > > /lib64/libcap.so.2 libcap > > /lib64/libcom_err.so.2 libcom_err > > /lib64/libcrypt.so.2libxcrypt > > /lib64/libcrypto.so.3 openssl-libs > > /lib64/libeconf.so.0libeconf > > /lib64/libgcc_s.so.1libgcc > > /lib64/libgssapi_krb5.so.2 krb5-libs > > /lib64/libk5crypto.so.3 krb5-libs > > /lib64/libkeyutils.so.1 keyutils-libs > > /lib64/libkrb5.so.3 krb5-libs > > /lib64/libkrb5support.so.0 krb5-libs > > /lib64/liblz4.so.1 lz4-libs > > /lib64/liblzma.so.5 xz-libs > > /lib64/libm.so.6glibc > > /lib64/libpam.so.0 pam-libs > > /lib64/libpcre2-8.so.0 pcre2 > > /lib64/libresolv.so.2 glibc > > /lib64/libselinux.so.1 libselinux > > /lib64/libsystemd.so.0 systemd-libs > > /lib64/libz.so.1zlib / zlib-ng > > /lib64/libzstd.so.1 zstd > > > > Should we have a higher level of attention to these packages? We > > already have "critical path", but that's a broad category now. These > > seem like they are "security path" packages, an intentionally small > > subset associated with very secure services which are enabled by > > default. > > I think the issue is that there is just too much stuff in critpath these > days. Whole desktop environments and all their transitive dependencies > probably ought to not be in there. If at all, I would put the display > manager in there, maybe the window manager, and no further. > I don't know if the security path package list would help any, since we still have no one to do security work. That said, I agree that pretty much every display manager and compositor for every Fedora variant should be critpath'd. -- 真実はいつも一つ！/ 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
Re: xz backdoor
On Fri, Mar 29, 2024 at 2:08 PM Richard W.M. Jones wrote: > > > On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote: > > Hi, > > > > wow: https://www.openwall.com/lists/oss-security/2024/ > > > > I think at this point we clearly cannot trust xz upstream anymore and should > > probably fork the project. > > I kind of agree here, though it saddens me to say it. Any commit or > release by "Jia Tan" or "Hans Jansen" [1] is suspect until proven > otherwise, and those go back 2 or more years. > I've been rolling in my head for a while now the idea of picking at things where we use gzip or xz to move to zstd where possible, given the benefits of the algorithm. This compromise has kind of raised the profile for me to seriously consider looking into 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: Feedback wanted: Kvantum 1.1.0 spec changes
On Thu, Mar 28, 2024 at 10:33 AM Arthur Bols wrote: > > On 28/03/2024 12:22, Neal Gompa wrote: > > On Thu, Mar 28, 2024 at 6:11 AM Arthur Bols wrote: > > This seems reasonable to me. Do we have any packaged themes that need > > to be adjusted alongside it? > Thanks for taking a look! > > I don't think so. There is nothing breaking in the changelog for themes > and everything still works fine on my systems. Themes should require the > kvantum package and put their files in /usr/share/Kvantum, so > packaging-wise everything stays the same. > Then I say let's do 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: Feedback wanted: Kvantum 1.1.0 spec changes
On Thu, Mar 28, 2024 at 6:11 AM Arthur Bols wrote: > > Hi all, > > Kvantum 1.1.0 has been released and changed the default compilation to > Qt6. Due to this change, I would like to change the packaging such that > the base package is Qt6 and a subpackage provides the Qt5 plugin. This > causes major changes to the spec and resulting packages, so I would like > some feedback on that. I also removed the dependency on the base package > for the data subpackage. The circular dependency was a bit strange, and > separating it allows installing kvantum-qt5 and kvantum-data separately. > > Attached is the patch outlining these changes. Your feedback would be > greatly appreciated. > This seems reasonable to me. Do we have any packaged themes that need to be adjusted alongside 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: on dnf autoremove aggressive behaviour
On Wed, Mar 27, 2024 at 11:00 AM Germano Massullo wrote: > > I recently updated to F40 KDE, but Jami software [1] bundled Qt6 RPM > package messed up with system Qt6 (see later fix at [2]), so I had to run: > # dnf autoremove > # dnf reinstall $(rpm -qa) > > I have noticed an aggressive packaging removal behaviour from "dnf > autoremove", indeed it removed various essential packages, some of them > even installed by default during Fedora installation (complete list at > [3]) For example: > - gdisk > - openssl > - lz4 > - java-21-openjdk > > dnf man page, says: > > dnf [options] autoremove > Removes all "leaf" packages from the system that were originally > installed as dependencies of user-installed packages, but which are no > longer required by any such package. > Packages listed in installonlypkgs are never automatically removed by > this command. > > I wonder: > 1) where installonlypkgs is defined, I could not find it in /etc/dnf > 2) why it removed also packages that are shipped by default during a > Fedora installation, like gdisk and openssl > 1) installonlypkgs is determined in the code. It is any package that has "installonlypkg(kernel)", "installonlypkg(kernel-module)", or "multiversion(kernel)" Provides. Basically the kernel packages. 2) None of those packages are installed directly, they are installed as dependencies, and if the thing that depended on it no longer is on the system, they are considered safe to remove. -- 真実はいつも一つ！/ 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: Change Compose Settings (system-wide)
On Mon, Mar 25, 2024 at 4:40 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Mar 25, 2024 at 07:29:09PM +0100, Kevin Kofler via devel wrote: > > Daniel Alley wrote: > > > One more point: createrepo_c uses zstd compression level 10, but the range > > > goes all the way up to level 22. I would oppose making the default much > > > computationally heavier than it is currently, but if spending 20x longer > > > to compress the repo 10% more is desirable to the fedora project, then > > > createrepo_c could perhaps add a the ability to select a compression > > > level. > > > > > > zstd at high compression levels is very nearly as good at compressing as > > > xz and sometimes better, while remaining much faster to decompress. -- > > > > Considering that compression happens once on the server and downloading and > > decompression happens many times on many computers, I think we should use > > the highest possible compression level. > > +1 > Keep in mind we also want to make the compose process faster too, I don't know if it's worth it to spend 20x more time compressing repodata when we keep trying to get back hours and minutes in the compose 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: Redis will no longer be OSS... now what?
On Thu, Mar 21, 2024 at 2:24 PM Scott Williams wrote: > > > If we have some clue that a v7 merge/release > > is on the very near horizon for KeyDB > > This doesn't look promising for v7 in time for Fedora 40 or shortly after, > unfortunately: https://github.com/Snapchat/KeyDB/issues/420 > > The choice of shipping an ever-stale v7 database versus a maintainable v6 one > is not a fun one, but leaving it up to Fedora package maintainers to have to > potentially come up with their own out-of-band patches for CVEs for redis-7 > seems like the worse choice to me. I think the immediate fix is pulling in redict once it makes its first release: https://codeberg.org/redict/redict -- 真実はいつも一つ！/ 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: Change Compose Settings (system-wide)
On Thu, Mar 21, 2024 at 8:20 AM Stephen Smoogen wrote: > > > > On Wed, 20 Mar 2024 at 22:01, Kevin Kofler via devel > wrote: >> >> Aoife Moloney wrote: >> > The zstd compression type was chosen to match createrepo_c settings. >> > As an alternative, we might want to choose xz, >> >> Since xz consistently compresses better than zstd, I would strongly suggest >> using xz everywhere to minimize download sizes. However: >> >> > especially after zlib-ng has been made the default in Fedora and brought >> > performance improvements. >> >> zlib-ng is for gz, not xz, and gz is fast, but compresses extremely poorly >> (which is mostly due to the format, so, while some implementations manage to >> do better than others at the expense of more compression time, there is a >> limit to how well they can do and it is nowhere near xz or even zstd) and >> should hence never be used at all. >> > > There are two parts to this which users will see as 'slowness'. Part one is > downloading the data from a mirror. Part two is uncompressing the data. In > work I have been a part of, we have found that while xz gave us much smaller > files, the time to uncompress was so much larger that our download gains were > lost. Using zstd gave larger downloads (maybe 10 to 20% bigger) but > uncompressed much faster than xz. This is data dependent though so it would > be good to see if someone could test to see if xz uncompression of the > datafiles will be too slow. > Fedora has been using optimized zstd compression "by default" since Fedora 30 anyway with Zchunk metadata: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata Regular zstd compression is less optimized due to the lack of dictionaries, but it's also effectively the fallback path, though much faster to decompress while providing pretty good compression (which is why we have been gradually switching *everything* to zstd). -- 真実はいつも一つ！/ 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: Redis will no longer be OSS... now what?
On Wed, Mar 20, 2024 at 8:13 PM Aaron Rainbolt wrote: > > On 3/20/24 17:19, Neal Gompa wrote: > > Hey everyone, > > It looks like Redis, Inc. has announced that future versions of Redis > are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a > fork of Redis coming up, we will likely need to remove Redis from > Fedora. > > All I can say is... :( > > [1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/ > > In addition to KeyDB, there's also DragonflyDB: > https://github.com/dragonflydb/dragonfly I mentioned Redis going > source-available to the KDE devs and one of them linked this. DragonFlyDB is not an open source database. It uses the BuSL license. -- 真実はいつも一つ！/ 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: Redis will no longer be OSS... now what?
On Wed, Mar 20, 2024 at 6:26 PM Jonathan Wright via devel wrote: > > We can potentially look to https://github.com/Snapchat/KeyDB which I've been > loosely working on packaging anyway. > I'll want to test this for Pagure at least, since we're going to have to switch our recommendations around soon because of 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
Redis will no longer be OSS... now what?
Hey everyone, It looks like Redis, Inc. has announced that future versions of Redis are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a fork of Redis coming up, we will likely need to remove Redis from Fedora. All I can say is... :( [1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/ -- 真実はいつも一つ！/ 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: Disable openSSL Engine Support (system-wide)
On Wed, Mar 20, 2024 at 11:24 AM Daniel P. Berrangé wrote: > > On Wed, Mar 20, 2024 at 03:27:34PM +0100, Petr Pisar wrote: > > V Wed, Mar 20, 2024 at 02:05:52PM +, Daniel P. Berrangé napsal(a): > > > Consider you've built your own app on Fedora 39 that uses these > > > symbols, and now upgrade to F40. RPM will consider the dependency > > > still satisfied, as the SONAME hasn't changed on libcrypto. The > > > app throws linker errors at some point due to the missing symbols. > > > > > > Another alternative is to continue providing fully functional engine > > > symbols, but remove the header files so in practice you can't compile > > > something new that uses it. This is still forking the API, but at least > > > has not forked the ELF ABI, so the upgrade doesn't explode. > > > > > Another option is remove the symbols, change soname, and rebuild reverse > > dependencies. > > Changing soname is something I don't think distros should ever do. ELF > soname designation belongs to the upstream project maintainers. > I agree with this. It was a royal pain to get us to stop doing that with OpenSSL 1.1, I don't want to go back to having to field bug reports about broken OpenSSL sonames again. While it is technically out of scope to discuss CentOS Stream 10 here, I am not sure it is wise to drop the engines API there either. It will result in tremendous problems for consumers and while deprecated, OpenSSL 4.0 (which removes deprecated APIs) has no currently planned release date: https://github.com/openssl/openssl/milestone/24 Even if we're being generous and saying it'll arrive in 3 years, that's still far enough away that we're talking about Fedora 46 (!!) and RHEL 11. The amount of damage and breakage for third-parties by disabling engine support is unconscionable, in my opinion. From the Fedora perspective, I just see no reason to do this anytime soon. -- 真実はいつも一つ！/ 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: [Test-Announce] Fedora 40 Candidate Beta-1.9 Available Now!
On Wed, Mar 20, 2024 at 8:45 AM Dan Horák wrote: > > On Tue, 19 Mar 2024 12:41:48 + (UTC) > rawh...@fedoraproject.org wrote: > > > According to [the schedule][1], Fedora 40 Candidate Beta-1.9 is now > > available for testing. Please help us complete all the validation > > testing! For more information on release validation testing, see: > > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > > > Test coverage information for the current release can be seen at: > > https://openqa.fedoraproject.org/testcase_stats/40 > > > > You can see all results, find testing instructions and image download > > locations, and enter results on the Summary page: > > > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Summary > > > > The individual test result pages are: > > > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Installation > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Base > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Server > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Cloud > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Desktop > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Security_Lab > > > > All Beta priority test cases for each of these [test pages][2] must > > pass in order to meet the [Beta Release Criteria][3]. > > > > Help is available on [the Fedora Quality chat channel][4], [the Fedora > > Quality tag on Discourse][5], or on [the test list][6]. > > > > Current Blocker and Freeze Exception bugs: > > https://qa.fedoraproject.org/blockerbugs/current > > > > [1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html > > [2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > [3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria > > [4]: > > https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org > > [5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team > > [6]: > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ > > the Cloud and Container image filenames miss the "Beta" string in the > name, not sure, but someone might have mentioned it already ... > > for example > Fedora-Cloud-Base-Generic.ppc64le-40-1.9.qcow2 > should be > Fedora-Cloud-Base-Generic.ppc64le-40-Beta_1.9.qcow2 > I believe. The checksum filename is correct. > This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2270197 We have an upstream fix to kiwi for this, but some code will need to be written for the koji plugin and pungi to resolve 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, Mar 19, 2024 at 6:49 AM Jonathan Wakely wrote: > > On Tue, 20 Feb 2024 at 14:55, Kevin Kofler via devel > wrote: > > > > I have just found another essential feature that is missing in Plasma > > Wayland: > > The big one for me is that Synergy and similar tools barrier and > input-leap don't work under Wayland. I don't see that mentioned at > https://community.kde.org/Plasma/Wayland_Known_Significant_Issues > > My understanding is that it's now possible using libEI, but only Gnome > makes use of that. Support for KDE is tracked by > https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 but > doesn't look close to being ready. It is targeted for Plasma 6.1, with the first step written for kwin: https://invent.kde.org/plasma/kwin/-/merge_requests/5412 -- 真実はいつも一つ！/ 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: Guiding co-dependent RPM packages to swap nicely
On Fri, Mar 8, 2024 at 5:51 AM Miro Hrončok wrote: > > On 08. 03. 24 11:43, Florian Weimer wrote: > > * Miro Hrončok: > > > >> On my system, I have postgresql16 and postgresql16-plugin installed > >> and I want to "upgrade" to postgresql20*. > >> > >> Using my distribution package manager, I would want to run something like: > >>dnf swap postgresql16 postgresql20 > >> > >> However that will fail, as the package manager does not know I want to > >> also swap postgresql16-plugin with postgresql20-plugin. > >> > >> Is there something I can do as a package maintainer to "guide" the > >> co-dependent swap case? > > > > Have you tried using “dnf shell” and entering both swap commands there/ > > I am actually looking for a metadata solution that would guide the package > manager to do it for me, not for a way to swap them manually. > There isn't one right now. It's something that could be added, but we don't have any in DNF currently. It might also require plumbing in libsolv, I'm not sure. -- 真実はいつも一つ！/ 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: remnants of modularity in mock configs
On Tue, Feb 27, 2024 at 9:52 AM Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > I was looking into mock configs, and mock-core-configs-40.1-1.fc39 still lists > for rawhide buildroots, repositories called rawhide-modular, > rawhide-modular-debuginfo, rawhide-modular-source, with enabled=0. > > Those urls lead to content like > http://ftp.nluug.nl/pub/os/Linux/distr/fedora/linux/development/rawhide/Modular/x86_64/os/Packages/ > i.e. a bunch of modular packages built for F39 in early 2023. > IIUC, those will not get updated… Can we just drop those repo definitions > from mock so simplify things? > Yes. https://github.com/rpm-software-management/mock/pull/1340 -- 真実はいつも一つ！/ 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: package reviews for Pandoc and CVE-2023-35936
On Mon, Feb 26, 2024 at 8:22 AM Jens-Ulrik Petersen wrote: > > Another day, another needed package (this would also be part of the postponed > Stackage LTS 22 change): > I forgot that pandoc > 3.1.3 had moved to the new crypton stack that replaces > cryptonite: > > crypton: https://bugzilla.redhat.com/show_bug.cgi?id=2266044 > > Next would be crypton-x509... > > Is it better I just pump the whole stack straight to bz, though my preference > is to only open RRs which can actually build. > But if it is less painful to review them together/back-to-back I can pump > them out faster (maybe a few of the next crypto-x509-* packages can be done > in parallel). > Put the whole stack and set the BZ dependencies. IIRC, the fedora-review bot will process them all in order 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: pygobject3 orphaned?
On Sun, Feb 25, 2024 at 9:46 AM Arthur Bols wrote: > > Hi, > > pygobject3 was orphaned yesterday for lack of time, but it seems it > wasn't announced on the devel list. Is this intended and are the other > admins not interested in maintaining the package? > > Please let me know if that is the case, I'll be happy to take it as it's > a dependency of power-profiles-daemon. I don't think the other admins are aware... -- 真実はいつも一つ！/ 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: koji news and 1.34.0 upgrade
On Sat, Feb 24, 2024 at 12:59 PM Otto Liljalaakso
wrote:
>
> Kevin Fenzi kirjoitti 22.2.2024 klo 1.43:
> > Greetings. After the outage that just completed, koji has been upgraded
> > to 1.34.0 plus a few patches from upstream. Some highlights:
> >
> > * A patch has been added allowing us to set 'noarch_arches' on build
> > tags. This allows us to specify what arch builders will do noarch
> > builds. Without any setting it's any arch, but this presents problems
> > for noarch packages that have some dependencies that have dropped i686.
> > For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
> > (ie, excluding i686). If this works well we can extend it to other build
> > tags.
> What does this mean in practice for packagers? Can I now stop adding
> `ExcludeArch: %{ix86}` to noarch packages in Rawhide, or should I still
> keep doing that until we know "if this works well"?
You should no longer need to do that.
--
真実はいつも一つ！/ 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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Fri, Feb 23, 2024 at 8:04 AM Sérgio Basto wrote: > > On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote: > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto > > wrote: > > > > > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > > > wrote: > > > > > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > > > > > > > > wrote: > > > > > > > > > > > > Wiki -> > > > > > > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > > > > > > > One additional item to consider is to review > > > > > the packager guidelines for use of /sbin > > > > > (and /usr/sbin) in additional locations from > > > > > those involved directly with installing binaries. > > > > > > > > > > In particular, I am thinking of the sysusers > > > > > examples where the use of /sbin/nologin > > > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > > > > > There are almost certainly other places > > > > > in the docs/guidelines. > > > > > > > > > > The documentation updates are always > > > > > the most annoying in my experience. > > > > > > > > We cannot change this without breaking backward compatibility. > > > > It'll > > > > have to stay that way until RHEL 9 falls out of support. > > > > > > > > > That is a good argument to not change it , why we need break > > > backward > > > compatibility ? > > > > > > > Nah. It just means we don't change any configuration or PATH stuff, > > which is fine because the sbin -> bin symlink will cover it. > > > > I strongly disagree with you , we should avoid break backward > compatibility , unless we got a very good reason , which is not the > case > We're not breaking backward compatibility. We would install a symlink pointing sbin to bin, which ensures any absolute path usage of binaries formerly in sbin will still work. > > > is not sbin for super users and bin for users ? > > > > > > > No. This is one of those many myths about the "Unix FHS". And it > > doesn't even matter much these days anyway, since most newer > > administrative tools don't install in sbin anyway. > > > > name it one , I'm not aware. > Sure: dnf. -- 真実はいつも一つ！/ 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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Fri, Feb 23, 2024 at 5:44 AM Roy Bekken wrote: > > On fredag 23. februar 2024 02:36:38 CET Neal Gompa wrote: > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto wrote: > > > > > > > > > > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > > > > > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > > > wrote: > > > > > > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One additional item to consider is to review > > > > > the packager guidelines for use of /sbin > > > > > (and /usr/sbin) in additional locations from > > > > > those involved directly with installing binaries. > > > > > > > > > > > > > > > > > > > > In particular, I am thinking of the sysusers > > > > > examples where the use of /sbin/nologin > > > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > > > > > > > > > > > > > > > There are almost certainly other places > > > > > in the docs/guidelines. > > > > > > > > > > > > > > > > > > > > The documentation updates are always > > > > > the most annoying in my experience. > > > > > > > > > > > > > > > > We cannot change this without breaking backward compatibility. It'll > > > > have to stay that way until RHEL 9 falls out of support. > > > > > > > > > > > > > > > That is a good argument to not change it , why we need break backward > > > compatibility ? > > > > > > > > > > > > Nah. It just means we don't change any configuration or PATH stuff, > > which is fine because the sbin -> bin symlink will cover it. > > > > > Shouldn't sbin be removed from the path with this change? > > The only reason normal users have sbin in the first place is because of the > convenience of tab completion with sudo. > We *could*, but we don't really have to. > When normal users got sbin, it was important that it was at the end of the > variable or it would break consolehelper. I’m not sure if consolehelper is > ever used anymore but its still part the repo. > consolehelper is still used for mock and a few other 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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto wrote: > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > wrote: > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > wrote: > > > > > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > One additional item to consider is to review > > > the packager guidelines for use of /sbin > > > (and /usr/sbin) in additional locations from > > > those involved directly with installing binaries. > > > > > > In particular, I am thinking of the sysusers > > > examples where the use of /sbin/nologin > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > There are almost certainly other places > > > in the docs/guidelines. > > > > > > The documentation updates are always > > > the most annoying in my experience. > > > > We cannot change this without breaking backward compatibility. It'll > > have to stay that way until RHEL 9 falls out of support. > > > That is a good argument to not change it , why we need break backward > compatibility ? > Nah. It just means we don't change any configuration or PATH stuff, which is fine because the sbin -> bin symlink will cover it. > is not sbin for super users and bin for users ? > No. This is one of those many myths about the "Unix FHS". And it doesn't even matter much these days anyway, since most newer administrative tools don't install in sbin 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, Feb 20, 2024 at 11:32 AM Kevin Kofler via devel wrote: > > Neal Gompa wrote: > > Or 3. you could go ask for the feature to be exposed, because in > > Wayland, we have more flexibility on how outputs are managed at all. > > Well, Plasma has had decades to get multiple outputs and scaling working. It > has always been a lost cause. (At least for the one configuration I care > about, which is mirrored displays stretched to display identical contents no > matter the aspect ratio, for presentations and meetings.) The introduction > of the XRandR X11 extension has been a godsend. Ever since, the one way to > get things working has always been to talk to XRandR directly over the CLI > and bypass Plasma entirely. Even fractional scaling on X11 is a non-issue if > you just let X11 do the scaling, so that neither Plasma nor the applications > even realize that their display is being scaled, let alone that it is being > fractionally scaled with a different fraction horizontally and vertically. > They just see a framebuffer of the size they want, and everything is scaled > by X11/XRandR behind their back. So it just works. (Yes, it is blurry and/or > some pixels are lost. But it does not look that bad in practice.) > Unfortunately, this is not an option in Wayland because there is no X server > that can do the scaling behind Plasma's back under Wayland. > Have you considered that perhaps the reason it wasn't possible before was *because* of the X server? I do think plenty of people would disagree with your statement about how good it looks when you warp the display like you propose, but not even bothering to ask for the feature at all guarantees that it won't exist. I know you're capable of filing requests for features on the KDE bug tracker, so if this is something you believe you need, then you should request it. If you won't even bother with that much, I don't think I or anyone else can take you seriously when it comes to your criticism of Plasma Wayland, especially since upstream KDE is oriented around it and has been for many years 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, Feb 20, 2024 at 9:55 AM Kevin Kofler via devel wrote: > > I have just found another essential feature that is missing in Plasma > Wayland: Under X11, I can scale outputs (at X11 level) ignoring the aspect > ratio. This is essential to unify outputs with different aspect ratios. > E.g., my notebook has a 1280×800 (8:5/16:10) display. Using xrandr --scale- > from, I can stretch this to 16:9, or even to 1024×768 4:3 which is then > stretched to 16:9 by the TV. So I see the same thing on the notebook's > built-in screen and on the TV, slightly distorted, but workable. > > Today, I tried to do this trick with my PinePhone (using the convergence > dock and HDMI output). Plasma Mobile forces Wayland on me. So I look at the > options of kscreen-doctor, which is purportedly the replacement of xrandr, > and well, that dumb thing can only apply one scale factor, not different > ones for horizontal and vertical. So I cannot get truly unified outputs, > meaning the experience completely sucks. (One or the other display ends up > truncated and impossible to work with. Also because Plasma insists on > filling the larger display and truncating the smaller one instead of filling > the smaller one and letterboxing the larger one as it should.) So this means > 1. Wayland will never be suitable for my notebook, and 2. one of these days > I am going to have to port Plasma Mobile to X11. > Or 3. you could go ask for the feature to be exposed, because in Wayland, we have more flexibility on how outputs are managed 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: Schedule for Monday's FESCo Meeting (2024-02-19)
On Mon, Feb 19, 2024 at 9:33 AM Zbigniew Jędrzejewski-Szmek wrote: > > Following is the list of topics that will be discussed in the > FESCo meeting Monday at 19:30 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-02-19 19:30 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 = > > (none) > > = Followups = > > (none) > > = New business = > > #3158 Change: Arm Minimal Image OS Build > https://pagure.io/fesco/issue/3158 > I've also added one more at the request of Adam Williamson during blocker review: #3169 Weigh in on installer storage setup issue https://pagure.io/fesco/issue/3169 -- 真実はいつも一つ！/ 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: Feedback wanted - pruning old rawhide chroots in Copr
On Mon, Feb 19, 2024 at 10:18 AM Stephen Smoogen wrote: > > > > On Mon, 19 Feb 2024 at 10:08, Kevin Kofler via devel > wrote: >> >> Stephen Smoogen wrote: >> > 1. Drive size is not just what is needed but also throughput. The large >> > drives needed to store the data COPR uses for its hundreds of chroots are >> > much 'slower' on reads and writes even when adding in layers of RAID 1+0. >> > Faster drives are possible but the price goes up considerably. >> > 2. Throughput of individual drives also requires backplane speeds which >> > match peek throughput of all the drives. Otherwise you end up with lots of >> > weird stalling (as seen on certain builders which have such drives). >> >> What kind of throughput is needed for a repository that has not seen any new >> builds for 2 years? Such a repository is going get only a handful downloads >> and no uploads. Instead of deleting old repositories, they can be moved to a >> low-throughput archive storage. This can be made transparent through >> symlinks, union file systems, or even just at the HTTPS level if Copr itself >> knows how to unarchive a repository when internally needed (e.g., if a new >> build is submitted after 2 years of inactivity). >> > > The throughput is actually in several places even for low/no usage > repositories. > 1. RAID rebuilds will need to go through and check data. RAID-1 might seem > like a no-brainer but you tend to end up with 'which of these two disks is > the correct bit' over time problems. > 2. web-spiders and such regularly peruse pretty much every package regularly. > Putting some repositories on slow disks and some on fast tend to cause web > front ends to pause out for unrelated tasks unless you set up your caching > and other middleware to deal with it. [This I know from when I tried to make > something more 'efficient' on downloads.fedoraproject.org and from some other > tooling.] It becomes a complete project of setting up the infrastructure to > best handle mixed loads. If you have a limited staff then it may be too much > work. > > That said, the above does sound like an interesting project to add to copr. I > do not know how much work it would take or who would be able to do it these > days. [My understanding is that COPR is 'one of many things' that the various > developers work on with most of the work done as a volunteer task.] > A lot of these problems may go away in the future once the Pulp backend for COPR is ready. That will allow repository storage to move from EBS to S3, and repositories in S3 can be set with different policies wrt to CloudFront for transparent CDN performance. https://github.com/fedora-copr/copr/issues/2533 -- 真実はいつも一つ！/ 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: Proposing a Fedora SIG for the upcoming COSMIC desktop environment
On Fri, Feb 16, 2024 at 4:00 PM Ryan Brue wrote: > > Hello all! This is my first time using a mailing list, but I want to do this > more often in the future :) > > System76, makers of Linux computers and creators of Pop!_OS are currently > working on a desktop environment entirely built in rust, called COSMIC. > (https://github.com/pop-os/cosmic-epoch). They use and contribute to a lot of > base Linux development components written in rust, including: > Smithay: A wayland compositor library https://github.com/Smithay/smithay > Iced: A GUI library https://github.com/iced-rs/iced > WGPU: A graphics library https://github.com/gfx-rs/wgpu > ZBus: A rust D-Bus crate https://github.com/dbus2/zbus > > I have been closely following its development and I am even dipping my toes > in rust for the first time to help contribute to its development. > > I happen to enjoy Fedora quite a bit, and I use Silverblue on my main machine > myself, but in order to try COSMIC in its current state (and to create a test > environment for my code changes) I started creating Fedora atomic images with > the COSMIC desktop environment installed (see: > https://github.com/ryanabx/fedora-cosmic-atomic). The image is very > primitive, and simply compiles COSMIC components and puts the files where > they need to be in their various directories, no RPM packaging involved at > this phase. > > I would like to gauge interest in creating a COSMIC SIG for Fedora. The > initial major goals of such a group would be: > > * Creating RPM packaging for COSMIC's components > * Laying out a plan for and promoting a Fedora COSMIC Spin > * Contributing to COSMIC development (for those interested, of course nothing > is required) > * Creating an accompanying Fedora COSMIC Atomic variant > > If you happen to like rust, or are simply excited to see another desktop > environment join the space, share your interest! This sounds great! > If there is enough interest, I would suggest we then create a matrix group, > similar to what the Fedora KDE SIG has. I believe the KDE SIG uses an IRC > bridge as well, for those interested in using IRC. We do not use IRC for Fedora KDE 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Sun, Feb 11, 2024 at 1:50 AM Kilian Hanich wrote: > > Am 10.02.24 um 09:47 schrieb Neal Gompa: > > Technically, turning off display sync completely is quite difficult > > right now since the actual driver stack in Linux underneath everything > > (both Wayland and X11) uses implicit sync right now (Linux kernel > > drivers, Mesa drivers, etc.). > > > > Interesting considering that I once read (but haven't fact check) that > the Vulkan spec explicitly requires explicit sync instead of implicit, > even if you for parts of it. > I don't know enough about Vulkan to confidently say one way or another. Especially since I'm pretty sure parts of it are one and the other. > > That said, there's a move to support explicit sync in Wayland[1], and > > the first steps of that for KWin have been written up as a merge > > request[2]. Once there's an agreed upon mechanism for explicit sync, > > it would be possible to support something like that. > > > > [1]:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 > > [2]:https://invent.kde.org/plasma/kwin/-/merge_requests/4800 > > Interesting read. I will just hope that this won't be something which > ends up in "noone actually still looks at it"-land as some things > sometimes end up in because people focused on different things and then > forgot about it (well, kind natural for volunteer projects I guess). > That's not going to happen because Direct3D 12 requires explicit sync. That's been driving the change to support it in the Linux graphics stack in the first place. -- 真実はいつも一つ！/ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 9, 2024 at 9:10 PM Kilian Hanich via devel wrote: > > > > Am 09.02.24 um 18:28 schrieb Neal Gompa: > > On Fri, Feb 9, 2024 at 12:16 PM Roy Bekken wrote: > >> > >> On fredag 9. februar 2024 17:41:33 CET Neal Gompa wrote: > >>> On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken wrote: > >>> > >>>> > >>>> > >>>> On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote: > >>>> > >>>>> I am not gonna reply to all of that because all we are doing at this > >>>>> point > >>>>> is repeating the same thing. But we are NOT stopping you from using > >>>>> x11. > >>>>> You can either build it yourself and put it on a copr (it’s not like > >>>>> neal > >>>>> is using voodoo in his copr), use the copr we provide or … > >>>>> > >>>>> > >>>> > >>>> This is extremely hostile towards new people trying linux for the very > >>>> first time, asking them to add a copr repo if they have problems with > >>>> wayland to try X11, its unlikely they ever heard this stuff before. > >>>> > >>>> > >>>> > >>>> Most likely they are trying out Fedora on a live media. > >>>> > >>>> > >>> > >>> > >>> And they're not going to get an X11 experience on live media even now. > >>> Wayland has been used for all environment modes since Fedora 36. > >> I am aware if this. So you are saying that its perfectly fine that someone > >> new > >> to linux boot into a desktop that microstutters when they move windows > >> around? > > > > No, it's not fine. Just like it's not fine to get random > > tear/corruption snow when moving things around or opening windows on > > X11. > > > > The difference is that we can actually do something about those issues > > with Plasma Wayland when people report them. *Tons* of these kinds of > > issues were fixed over the past 3 years, and Plasma 6 brings a huge > > upgrade around this stuff too. And the whole graphics pipeline is > > fully under the control of KDE Plasma, so we can do things we've never > > done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional > > scaling, and so much more. > > > > We can do things that even other Wayland desktops can't do because our > > architecture is flexible enough to do it. With Plasma X11, our necks > > are hanging to the dying albatross that is the X server and our hands > > are tied behind our backs when we want to actually do something to > > improve the experience. These are not issues with Plasma Wayland. > > > > Because Plasma Wayland... is just KDE Plasma. > > > > > > > > Quite a bit of topic from my part, but is your pipeline for Wayland > flexible enough to turn off any kind of display sync (even in windowed > mode) if the user wants that? > > Sure, it has its downside (e.g. tearing can happen), but I rather have > that than the added latency (even if very minimal) of such a sync (and > yes, that includes VRR which has a considerable smaller one than normal > V-SYNC). Technically, turning off display sync completely is quite difficult right now since the actual driver stack in Linux underneath everything (both Wayland and X11) uses implicit sync right now (Linux kernel drivers, Mesa drivers, etc.). That said, there's a move to support explicit sync in Wayland[1], and the first steps of that for KWin have been written up as a merge request[2]. Once there's an agreed upon mechanism for explicit sync, it would be possible to support something like that. [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 [2]: https://invent.kde.org/plasma/kwin/-/merge_requests/4800 -- 真実はいつも一つ！/ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 9, 2024 at 2:25 PM Roy Bekken wrote: > > On fredag 9. februar 2024 18:28:15 CET Neal Gompa wrote: > > The difference is that we can actually do something about those issues > > with Plasma Wayland when people report them. *Tons* of these kinds of > > issues were fixed over the past 3 years, and Plasma 6 brings a huge > > upgrade around this stuff too. And the whole graphics pipeline is > > fully under the control of KDE Plasma, so we can do things we've never > > done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional > > scaling, and so much more. > > > Nobody is saying that this is not awesome stuff but as of today, on some > hardware, Wayland is not a great experience. > > I just booted Fedora-KDE-Live-x86_64-Rawhide-20240207.n.0.iso > First impression is great but I’ll start moving(fast) the welcome center > window around and the desktop randomly freezes from 30sec to 90ses. > > This is on a 1080 with nouveau, im not sure if its better with the proprietary > drivers. > It will definitely be better with the proprietary drivers. One of the members of Fedora KDE has the same graphics card and daily drives Plasma Wayland with the proprietary drivers. GTX 16, RTX 20, RTX 30, and RTX 40 series GPUs will hopefully work much better out of the box starting with tonight's compose since we will have the new nouveau driver stack fully enabled for those cards. Sadly, that doesn't help folks with older GPUs (like my GTX 960 or your GTX 1080), but it'll still be an improvement overall. -- 真実はいつも一つ！/ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 9, 2024 at 12:16 PM Roy Bekken wrote: > > On fredag 9. februar 2024 17:41:33 CET Neal Gompa wrote: > > On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken wrote: > > > > > > > > > > > On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote: > > > > > > > I am not gonna reply to all of that because all we are doing at this > > > > point > > > > is repeating the same thing. But we are NOT stopping you from using > > > > x11. > > > > You can either build it yourself and put it on a copr (it’s not like > > > > neal > > > > is using voodoo in his copr), use the copr we provide or … > > > > > > > > > > > > > > This is extremely hostile towards new people trying linux for the very > > > first time, asking them to add a copr repo if they have problems with > > > wayland to try X11, its unlikely they ever heard this stuff before. > > > > > > > > > > > > Most likely they are trying out Fedora on a live media. > > > > > > > > > > > > And they're not going to get an X11 experience on live media even now. > > Wayland has been used for all environment modes since Fedora 36. > I am aware if this. So you are saying that its perfectly fine that someone new > to linux boot into a desktop that microstutters when they move windows around? No, it's not fine. Just like it's not fine to get random tear/corruption snow when moving things around or opening windows on X11. The difference is that we can actually do something about those issues with Plasma Wayland when people report them. *Tons* of these kinds of issues were fixed over the past 3 years, and Plasma 6 brings a huge upgrade around this stuff too. And the whole graphics pipeline is fully under the control of KDE Plasma, so we can do things we've never done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional scaling, and so much more. We can do things that even other Wayland desktops can't do because our architecture is flexible enough to do it. With Plasma X11, our necks are hanging to the dying albatross that is the X server and our hands are tied behind our backs when we want to actually do something to improve the experience. These are not issues with Plasma Wayland. Because Plasma Wayland... is just KDE Plasma. -- 真実はいつも一つ！/ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken wrote: > > On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote: > > I am not gonna reply to all of that because all we are doing at this point > > is repeating the same thing. But we are NOT stopping you from using x11. > > You can either build it yourself and put it on a copr (it’s not like neal > > is using voodoo in his copr), use the copr we provide or … > > > This is extremely hostile towards new people trying linux for the very > first time, asking them to add a copr repo if they have problems with wayland > to try X11, its unlikely they ever heard this stuff before. > > Most likely they are trying out Fedora on a live media. > And they're not going to get an X11 experience on live media even now. Wayland has been used for all environment modes since Fedora 36. > > With the change proposal, fedora (as a distro) the kde sig has proposed to > > move away from packaging x11 for plasma 6, and by accepting the proposal, > > fedora (as an entity) agreed. > > > > Fedora has a reputation of moving forwards, not going backwards. > > > Moving so fast forward that they are leaving the users behind. > > If Fedora is so great then why do I find stuff like this? > https://github.com/Zer0CoolX/Fedora-KDE-Minimal-Install-Guide > > 15 Forks and 167 Stars btw > That is not a particularly good indication of popularity. Also, it's 4 years out of date. -- 真実はいつも一つ！/ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Wed, Feb 7, 2024 at 11:12 PM Kevin Kofler via devel wrote: > > Steve Cossette wrote: > > But to be fair as well, that doesn't exist on Windows (Windows can > > reopen the programs you are working on but it doesn't save what you were > > doing) > > And even that, it does not do automatically, it is an application feature to > request this through the registry. (Something Wayland applications could in > theory also due through XDG autostart or systemd user units, but in practice > do not do, because application developers are used from X11 to this just > working.) > > > Xorg I've been told has it, but each program has to support it. > > Of course, saving and restoring the application state requires application > support. But many desktop applications have that code already for X11 > session restore and it would probably only take a toolkit (Qt/GTK) update to > pick up a Wayland protocol for this without the application having to do > anything. (By the way, mobile or convergent applications are supposed to > have support for this because Android requires it for power management, so > there too, there is code that could likely be enabled with minimal effort, > though it would probably need application code changes to bring it out of an > Android-only code path if they do not already support this on X11.) > The Wayland protocol in question is this one: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 That said, even X11's version isn't widely supported. Typically, support for this is plumbed through linking libSM, and GTK notably does not use it. Qt does, of course. This is one of the things I've had on my radar for quite some time. macOS-style automatic relaunch of applications is slated upstream for 6.1: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3523 Support for the Wayland protocol will come after, but the combination of the two approaches means that pretty much everything will be able to relaunch as desired in some form on restart. -- 真実はいつも一つ！/ 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: Introduction
On Sun, Feb 4, 2024 at 6:08 PM Luis Correia wrote: > > Hi, I'm a long time Fedora user and used to help develop the Ralink Wireless > driver (rt2x00) that's been present in the kernel for a long time. > > I'm now entering the process of helping maintain the mixxx package over at > rpmfusion. > > Hope to be useful with this new venture. > Welcome! Have you considered bringing mixxx over to Fedora? I'm pretty sure it can be packaged in Fedora proper these 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 2, 2024 at 1:05 PM Sérgio Basto wrote: > > On Fri, 2024-02-02 at 01:34 -0600, Jonathan Bennett via devel wrote: > > Hey folks, outside observer, and long-time Fedora user weighing in > > with > > some thoughts. First off, I've been hyped to see Fedora lead the way > > with finally making a real move to Wayland, and retire X11. And now > > I'm > > fairly disappointed to hear that there's a real chance that move will > > get killed. And especially that it's not because of a technical > > problem > > or blocker bug. > > I don't understand , why you want the others use a crap of software, > fully buggy, without many features , which is not supported by many > (like nvidia) , because is new ? > > Who wants use Wayland and test it, may use wayland and test it, it is > even the default . > > It is really difficult to me understand your point of view , users > should be free to use what they want and have choices, It is really > weird (for me) that you want that I use wayland and test wayland . > All of us in the KDE SIG daily drive Plasma Wayland, and have done so for quite a while. I (as well as most of the members) have since 2020, with the two members using NVIDIA beginning daily driving it in 2022 with the 515 driver release. I would not be pushing "crap" or "fully buggy" software "without many features" that is "not supported by many (like nvidia)". We literally waited until NVIDIA started properly supporting it, and spent a lot of time with upstream to improve the experience. With regards to NVIDIA, this cycle provides a lot of light at the end of the tunnel because the proprietary driver is optional for the newest generation of GPUs and eventually will be optional for the last six years of NVIDIA GPUs. Yes, it's not everything, but it's a lot and that's a big deal. The SIG has worked methodically and patiently toward this, in conjunction with upstream (the Fedora way), for three years. We're also gathering empirical data through our test week, and the results have been largely positive: https://testdays.fedoraproject.org/events/174 It's extremely obvious that people want to use it. You replied to someone who did and denigrated their opinion. Frankly, I'm disappointed in your response as well as the tone of you and Kevin. Neither of you are aligning with the Fedora Foundation of Friends, and the personal attacks were unwarranted and unwanted. What we're doing is bold for sure, but aligns with two more of the Fedora Foundations, First and Features. And for the first time in a long time, Fedora KDE has generated significant buzz in the community and media. I'm excited for the future of Fedora KDE with Plasma Wayland, as well as what we're doing with the upstream KDE community. :) -- 真実はいつも一つ！/ 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: Package review ticket status change after approval
On Sat, Feb 3, 2024, 11:04 AM Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 01/02/24 22:44, Fabio Valentini ha scritto: > > On Mon, Jan 29, 2024 at 7:47 PM Mattia Verga via devel > > wrote: > > (snip) > > > >> That said, I'd like to make a request and maybe make all reviewers aware > >> of a feature which was implemented some time ago. I've noticed many > >> reviewers change the ticket status from ASSIGNED to POST when they flag > >> the package as approved: I'd like to request to not do that. > >> > >> The Package Review Tracker webpages make a distinction between packages > >> approved (fedora-review flag set to +) and packages approved AND being > >> built in Fedora. That distinction relies on the ticket status change to > >> POST, which is automatically set when the repository is created in > src.fp.o. > > Hum ... am I missing something here? > > > > The bot that creates the dist-git repos does *NOT*, in fact, set the > > bug status to POST: > > https://bugzilla.redhat.com/show_bug.cgi?id=2260350#c5 > > > > Fabio > > Well... it should: > https://pagure.io/fedora-infra/toddlers/pull-request/158 That has never worked. Also, POST is the wrong status for that. RELEASE_PENDING would make more sense instead. > > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 2, 2024 at 10:47 AM Peter Hutterer wrote: > > On Thu, Feb 01, 2024 at 03:40:24PM +, Sérgio Basto wrote: > > On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote: > > > Am 01.02.24 um 14:18 schrieb Sérgio Basto: > > > > > > > > > > The problem is not KDE SIG not support X11, the problem is KDE SIG > > > > want > > > > drop X11 and force user to use wayland . > > > > > > > > > Looking from the side I wonder If its the SIG or more the > > > circumstances > > > that everything is in a forward flow and the SIG is facing it. So, if > > > the best time was not two or one year ago, and obviously also not > > > now. > > > When then? The fact is that there must be a point in time when the > > > display server takes an evolution step forward. > > > > > > Pressure in such transition helps to get forward, so I understand the > > > SIGs POV. Albeit, from the practical POV there are some issue and > > > therefore X11 is still the place to be. > > > > > > Maybe some elaboration should be done about the current state of X11 > > > vs > > > Wayland (is it just nvidia?) and a timeframe calculation to have a > > > resolution. Maybe it won't look so bad then and a interim solution is > > > then more acceptable. > > > > > > I have an obvious answer is when the authors decide, in this case Xorg, > > when Xorg decides that it will stop supporting X11, like happened to > > Python2 or PHP5 and 7 or Gnome > > X.org (the ppl doing X development) doesn't work that way, there won't > be an official "we're no longer supporting this". More likely > development will languish (except for Xwayland) and actual Xorg releases > will be few and far in between, at unpredictable cadence and subject to > someone wanting to do it. > > The last Xorg release (21.0) from the master branch was in Oct 2021. The > only reason that one happened was because Povilas (who wanted a new > feature in X) stepped up and did the work of collecting the MRs and > doing the release maintainership. Every 21.x release since has been > backports and, especially more recently, a huge percentage are CVE fixes. > > Fedora still ships the previous release, server 1.20.x, which was > originally released from git master in 2018, the 1.20.14 version we're > on (excluding fixes and CVEs) is from Dec 2021. > > Xwayland on the other hand (which lives in the same git repo) continues > on its merry way with the 23.2 series branched as recently as last > August. But an Xwayland release does not include Xorg because, well, > there is little motivation to do more Xorg releases. > > When it comes down to it it "just" needs someone (trustworthy enough) to > step up and do them. Whether the releases get picked up immediately like in > the olden days is a different matter. But I doubt there'll be an X.org > statement of "we no longer support Xorg" anytime soon, even though that > is, to some extent functionally already true. > And even before that, things were already only limping along. That was happening for over a decade and in that timeframe *nobody* has wanted to step up and work on it. Wayland is the future because otherwise we have no graphics future, as things currently stand. This is why *every* graphical environment is *finally* working on their Wayland environments if they have any development resources at all. Last year, we had Cinnamon release its own experimental Wayland session with v6.0. Budgie is working on replacing X11 with Wayland this year. LXQt will be on Wayland with v2. Xfce is working on the same for v4.20. MATE is looking at Wayfire after previously looking at Mirco for Wayland. Pantheon has been working on it for over a year now and has an experimental session. Everyone is making a path to Wayland a priority because finally enough is done so that they can. -- 真実はいつも一つ！/ 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: Failure on fedora default backgrounds
On Fri, Feb 2, 2024 at 2:04 AM Mamoru TASAKA wrote:
>
> Luya Tshimbalanga wrote on 2024/02/02 10:25:
> > Hello team,
> >
> > It appears a change within %{_kde4_datadir} macro caused failures on
> > Rawhide affecting default Fedora backgrounds starting from 21.
> > Could someone from KDE SIG address that issue? Thanks.
> >
> >
> > Here is an extract of failure[1] on for f35-backgrounds built on Rawhide:
> >
> >
> >
> > RPM build errors:
> > error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > Child return code was: 1
> > '''
> >
> > Reference:
> > [1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075
> >
>
> I am not KDE sig member, but the above failure is most likely due to
> the following change:
>
> https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32
>
> /usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir} macro
> definition)
> was moved from kde-filesystem.rpm to kde4-filesystem.rpm .
>
Yes, just add "BuildRequires: kde4-filesystem".
--
真実はいつも一つ！/ 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: Self Introduction: Leo Sandoval
On Fri, Feb 2, 2024 at 12:48 AM Leo Sandoval wrote: > > Dear Fedora Community! > > My name is Leonardo Sandoval, a software developer living in Guadalajara, > Mexico. I have been in the industry since 2006, most of the time close to the > Linux kernel (openmax, gstreamer, glibc, yocto project, ltib, toolchains) and > recently doing gitlab CI/CD, but all the time under GNU/Linux (and emacs). > Also, I recently started teaching Fundamentals of OS in a local university, > trying to get new students involved into the Linux internals. > > Since Dic 2023 I have been working at RedHat (remote), in particular I > joined the bootloader team to co-maintain Fedora grub2 and other bootloader > tasks. I have the fortune to be surrounded by amazing technical people so I > am glad to be part of this team and Fedora community in general. > Welcome to Fedora, Leo! -- 真実はいつも一つ！/ 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
