Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
> I'm fairly certain you should be > saying this to Kevin. I'm fairly certain it applies to everyone involved. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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
You were implying that Kevin was claiming to be an "unbiased observer" and that him being banned from the KDE SIG means he has ulterior motives for this beyond simply maintaining Plasma X11 packages. Call it what you want, but it doesn't make for a constructive discussion. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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 February 3, 2024 8:55:42 PM CST, Kevin Kofler via devel > > Wait, you're banned from all the KDE channels in Fedora? I have no idea what > led to > that, though the KDE SIG doesn't have a track record of handing those kind of > bans out > flippantly. But regardless, that calls into question your position as an > unbiased > observer. Jumping to an accusation of bad faith, rather than addressing anything that Kevin wrote, doesn't make for a productive discussion. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Mesa in F37- vaapi support disabled for h264/h265/vc1
It's very disappointing that Fedora will now be permanently crippled for a huge amount of video content. If Red Hat is largely alone in believing that this a credible legal risk, then ultimately this change will reflect poorly on the distribution regardless of any articles written. I hope this topic does get more publicity as the change was made without broad communication and it will negatively impact many Fedora users. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F35 to F36
> Does adding --allowerasing work? > > kevin Yes that worked, thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
It's been ~1 month and I am still unable to upgrade to F36 due to the same issue with lilv: Error: Problem: lilv-0.24.10-4.fc35.i686 has inferior architecture - lilv-0.24.10-4.fc35.x86_64 does not belong to a distupgrade repository - problem with installed package lilv-0.24.10-4.fc35.i686 Are there plans to fix this and/or is there a known workaround? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FESCo wants to know what you use i686 packages for
The i686 packages I use are: gamemode, gperftools-devel (to provide a working version of libtcmalloc_minimal), SDL2, steam, and their dependencies. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
Thanks, and thank you for maintaining chromium-freeworld in rpmfusion. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
> We ship VA-API integration, which Google doesn't offer. VAAPI hasn't worked for a long time on chromium. In "chrome://gpu" it shows "Video Decode: Software only. Hardware acceleration disabled" and it cannot be changed in "chrome://flags" either. This is the case for Fedora's packaged chromium and rpmfusion's chromium-freeworld. I encourage you to verify this yourself using intel or amd graphics. > Those features provide tangible benefits to the community at large > that we would lose by "sloppy packaging" An outdated browser that has many known vulnerabilities is a huge security problem and provides tangible drawbacks. If it's too much work to keep current then it should be removed from the repository. We do not want users to be under the illusion that the provided package is secure and maintained when it's not. > The same goes for everyone else on this thread so far. I'm > disappointed by the OP and everyone else in this thread who thinks > it's okay to do less than a good job on shipping software. I would argue that providing secure packages takes priority over most other packaging issues. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
How will multi-monitor users be able to configure the display arrangement for SDDM now? Currently on my desktop SDDM defaults to an incorrect arrangement and I have /etc/sddm/Xsetup call xrandr to correct it. With SDDM using wayland by default will users just be expected to deal with random monitor arrangements during the login experience? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
> I think there are two cases of interest: > > 1) a file or signature in the rpm is corrupted, the signature doesn't have a > matching > cert installed, etc... > in this case, if the plugin is present, when you attempt to install the rpm > the verity > enable ioctl will explicitly fail, and presumably so will the rpm install. > You can see > most of the details for this sort of case here in the rpm plugin code: > https://github.com/rpm-software-management/rpm/blob/master/plugins/fsveri > > 2) after installation, a file from an fs-verity enabled rpm gets one or more > blocks > corrupted > The first read of a corrupted block from disk (the good uncorrupted page > might survive in > page cache for a while) will result in EIO for read-like system calls and > SIGBUS if the > file is mapped (executables, mmap). Thanks for the information. So in the event of an error, it's expected that the user would be informed that the error was due to a rpm-fsverity check and they could potentially reinstall the rpm from a trusted source to resolve the problem? Of course there's the underlying issue of _why_ it happened, but from the standpoint of wanting an immediate path forward. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
Perhaps I glossed over it in the description, but what is the expected user experience in the event of a RPM fs-verity mismatch/error? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Pipeware issue in KDE after F34->F35
Looks like someone has reported this bug [1] feel free to add any additional details. I ran into this bug myself and consider it to be a pretty big problem if 34->35 upgrades are going to leave some users without working audio. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2016253 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] ** UPDATE ** 2021-10-08 @ 16:00 UTC - Special Fedora QA Meeting: Wireplumber Decision
Have there been updated F35 wireplumber packages pushed somewhere? I haven't seen anything on Bodhi this week, so I have not done any testing. I see the meeting is scheduled for tomorrow morning in my timezone, so it's likely that I (and potentially many others) will be not be able to test wireplumber before a decision is made on its readiness. Perhaps I am not understanding the plan, any clarification would be appreciated. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)
> This change proposal is the first I've heard of it. But since this is > being proposed by the author of Pipewire, I kind of assume it's good, > and I doubt Workstation WG would see the need to get involved unless > concerns are raised. Does WirePlumber have some sort of deficiencies > compared to pipewire-session-manager? Now that Fedora 35 is in beta and more people are testing it out, it appears that wireplumber does have some regressions compared to pipewire-media-session. Namely that audio output switching for flatpak applications does not work [1], and that desktop system sound volume (e.g. notification sounds) can not be controlled independently from the main system volume [2][3]. There is also an issue with changing bluetooth speaker volume [5]. From developer comments it may not be likely that all of these problems will be fixed in time for the F35 release, and the current workaround is to switch back to pipewire-media-session [4]. Clearly this is late in the release cycle, but I am concerned that wireplumber will provide an overall worse audio experience for F35 users. So ultimately I am asking if we should re-evaluate whether or not wireplumber should be the default pipewire session manager for F35. Are there other features landing in F35 that specifically depend on wireplumber, and if so do they outweigh the currently known regressions? [1] https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/59 [2] https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/51 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2003403 [4] https://bugzilla.redhat.com/show_bug.cgi?id=2003403#c4 [5] https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/58 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present
> Could you modify fprintd.service, to set G_MESSAGES_DEBUG=all[1] and
> then grab a log of that?
Here's what I see from systemctl status fprintd.service:
Getting authorization to perform Polkit action
net.reactivated.fprint.device.verify
Authorization granted to AuthenTec AES2550/AES2810 to call method
'ListEnrolledFingers' for device :1.72!
file_storage_discover_prints() for user 'tom' in '/var/lib/fprint/tom/aes2550/0'
scan_dev_storedir(): opendir("/var/lib/fprint/tom/aes2550/0") failed: Error
opening directory “/var/lib/fprint/tom/aes2550/0”: No such file or directory
Requesting device 'AuthenTec AES2550/AES2810' authorization for method
ListEnrolledFingers from :1.74
Getting authorization to perform Polkit action
net.reactivated.fprint.device.setusername
Getting authorization to perform Polkit action
net.reactivated.fprint.device.verify
Authorization granted to AuthenTec AES2550/AES2810 to call method
'ListEnrolledFingers' for device :1.74!
file_storage_discover_prints() for user 'tom' in '/var/lib/fprint/tom/aes2550/0'
scan_dev_storedir(): opendir("/var/lib/fprint/tom/aes2550/0") failed: Error
opening directory “/var/lib/fprint/tom/aes2550/0”: No such file or directory
It looks like "/var/lib/fprint/" is a completely empty directory on my system.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present
> Can you please provide output of `authselect current`? # authselect current Profile ID: sssd Enabled features: - with-fingerprint - with-silent-lastlog # authselect check Current configuration is valid. I have verified that both sssd and fprintd are running, and are not logging any errors. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present
> I think there's probably three things: Great summary Matthew, a big +1 from the peanut gallery. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present
> The problem is that every time this conversation starts... you end up with > 200 people all wanting some other program to be stopped/not run/removed but > not something they actually think is essential. And instead we end up > finding we needed to add one or two things because a lot of users wanted > this or that. Workstation like Server like Cloud are going to be general > operating systems which are built around fitting the majority of problems > people want solved versus a small set of things you or I want in a system. > This leads to compromises.. a lot of them. I think Hans is suggesting that these services are enabled on demand based on events, e.g. modemmanager only starting when a modem is present, rather than simply set to enabled (or disabled) by default. Perhaps that's not possible, but I don't think Hans is asking for services to simply be pruned at the expense of other users. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present
On rawhide I upgraded to authselect-1.2.2-3.fc35 yet I am still encountering the issue of gdm repeatedly complaining about authentication via fingerprint. I've checked and authselect is using the 'ssd' profile. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present
I'll add that I just hit this today on an old laptop running rawhide. I didn't spend much time debugging the problem, but I did not see any obvious errors being reported in the journal and simply disabling fprintd did not resolve the issue with gdm. Masking fprintd, as Hans noted, is the big hammer workaround. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)
> On 22/02/2021 21:18, Tom Seewald wrote: > > > > Personally, I have an older GPU, RX 580 Polaris series, I will only > spend dev time on the AMD Navi GPU issues after AMD makes the RX 6800 XT > available in my region. I simply don't have that card and I'm not going > to waste money buying the original Navi card, RX 5700, when the new card > will arrive imminently. There is no indication from the bug report that it requires a Navi card to reproduce. The reporter stated that they are using a RX Vega 56 which is the previous gpu generation. Why do you believe this is specific to Navi devices? > Ultimately, even if it isn't hard to bisect, it doesn't feel fair that > AMD is validating their drivers work on x86 before a release but the > ppc64le users have to check things after a buggy release. Unfortunately smaller platforms will almost always get less testing than the more popular platforms, and I don't see that trend changing in the foreseeable future. This is where motivated community members need to come in. I doubt amdgpu developers even have easy access to ppc64le hardware. I will also say that regardless of ISA there are going to be times where bisection is needed. I have personally had to bisect and report an issue with amdgpu and I am using x86 hardware. There's also a decent chance I'm going to be bisecting another amdgpu bug this evening. I am not expecting you or others to do things that I am not willing to do myself. > I'm all in favor of collaboration with the AMD and kernel developers > > Ultimately, the only way to ensure equality across different > architectures is to have upstream developers using all of these > architectures throughout their development cycle. It would of course be great if amd fully tested their drivers on every architecture that Linux supports, but I don't think that's currently a realistic expectation for *any* device/driver vendor. If amdgpu support is something that is important to IBM, Talos, or other members of OpenPower, then I think reaching out to developers and offering free ppc64le hardware or VM access for kernel development and testing would be an excellent start. Providing automated ppc64le build and boot testing for the amd-staging-drm-next tree would be great as well. > How can we encourage greater use of ppc64le and aarch64 in those > communities? While it may sound trivial, I made a post here last week > about how we can help people choose the right workstation through the wiki: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... > > I estimate spending one or two hours in my own comparison of the Raptor > motherboards and I hope the table allows other developers to save the > same amount of time. While there's no silver bullet, reaching out to the upstream developers (e.g. via their mailing list) and having a conversation with them can't hurt. Understanding their position and what they believe would help with testing is going to be an important part of the solution. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)
> I feel that you underestimate the impact of the GPU driver issue > > If the GPU driver doesn't work, people can't even log in and get started I still do not understand why no one from the talos/ppc64le community is following up on that amdgpu regression[1] that was introduced with the 5.9 kernel. Surely the time and effort already taken recompiling kernels with 4k pages along with formulating and discussing this proposal for Fedora 35 has eclipsed spending part of an evening bisecting and replying to the amd developers? I have replied to the bug report to give some guidance on how to bisect kernel bugs as the reporter was not familiar with git. Hopefully some progress will be made in the coming days. > If the GPU vendors don't test their code on ppc64le (and aarch64) then > those platforms will always lag behind x86. Users will experience > issues that have been fixed in the development phase for x86. Are there really pervasive issues with amdgpu and non-4k page sizes? If so, they are not being reported as there is only one bug open that mentions 64k pages in their bug tracker. I do not see sufficient evidence to suggest that it is not worthwhile to engage with upstream to fix real bugs. Being active participants with the upstream developers is a very good way to motivate them to care more about smaller platforms, and likewise not interacting with upstream is unfortunately a good way to decrease the mindshare of smaller desktop platforms. > Personally, I'm not opposed to the 64k page size in principle: my > concerns are about the practical issues. > > If both 4k and 64k can be supported, if users can choose between > installers for either page size, then the severity of the issue is reduced > > Regards, > > Daniel [1] https://gitlab.freedesktop.org/drm/amd/-/issues/1446 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] 2021-02-22 @ 17:00 UTC - Fedora 34 Blocker Review Meeting
> I understand it's bad UI/UX and I agree. But what I'm asking is *what > criterion*, i.e. I would argue that it fits best in the shutdown category [1], specifically that the system must cleanly shutdown such that "storage volumes (e.g. simple partitions, LVs and PVs, RAID arrays) are taken offline safely". Given that a 2 minute timeout will result in many users holding the power button rather than waiting, filesystem(s) will not be cleanly unmounted. I personally have interacted with a user who was force powering off his rawhide machine due to this bug, so this isn't pure theory. Have there been other recent Fedora Workstation releases that shipped knowing that the system is unable to reboot in less than 2 minutes by default? > https://fedoraproject.org/wiki/Basic_Release_Criteria > https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria > https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria > > Bugs don't become blockers only because they're nasty bugs, there's a > process. Could you please respond to the rest of my previous post in order to help me understand why this is not a gnome-session issue as Benjamin Berg seems to have indicated? I will also mention that after I manually added "Slice=-.slice" under the [Service] section of /usr/lib/systemd/user/gnome-session-restart-dbus.service (which is the exact change that Benjamin committed to gnome-session[2]), I no longer experience 2 minute timeouts. Overall I think there is very strong evidence that this bug is exactly the one Benjamin Berg describes, and hence this is an issue with F34 and rawhide's gnome-session package needing to be updated to include the commit previously referenced. [1] https://fedoraproject.org/wiki/Basic_Release_Criteria#Shutdown [2] https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/55/diffs?commit_id=9de6e40f12e8878f524f8d429d85724c156a0517 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] 2021-02-22 @ 17:00 UTC - Fedora 34 Blocker Review Meeting
> Under what criterion would it be a blocker? This affects (all?) users of Workstation running 34 or rawhide and causes users to unsafely force power off their machine due to the 2 minute timeout. Many will be led to think that their Fedora install or hardware is broken. Shipping a release of Fedora Workstation that reboots without running into major errors or timeouts by default seems reasonable to me. Why is this a bad candidate for being a blocker? > The gist of the problem is that (a) it's a reasonable goal to get > reboot/shutdown times below 30s, ideally 10s but that's a detail; (b) > it's not reasonable to just arbitrarily disregard the hierarchy of > timeouts and just blow away the user manager and all child processes. > The timeouts are there for a reason, so they all have to be taken into > account to make sure everything is folding in the proper sequence. > Otherwise we end up with new and possibly worse problems. I don't know why you are assuming that I want to ignore timeouts or that things should be force killed. This is ostensibly a bug that hopefully can be fixed before F34 is released. Being condescending and assuming I am totally ignorant of how systemd manages services is not productive. To be very clear, no one is suggesting that the fix is to disregard or otherwise bypass timeouts. > I might be wrong but I think it's specious to just make this a > blocker. Sounds good, but then upon closer inspection I think we'll > find the blocker process isn't going to be an effective way to fix the > problem, and then it'll just end up sucking people's time away from > isolating the problems. Why does making a bug a blocker suck time away from fixing said bug? I genuinely do not follow your logic here. > And not least of which is learning *how* to isolate these problems, so > maybe that's a conversation worth having is how to better understand > the information available to find out what to blame and find a bug > against. > > I filed that bug against pipewire only because it's mostly what's > remaining at the 2 minute mark; and if I use the early debug shell so > I can switch to tty9 during the timeout countdown, and kill off all > those processes, usually I get an immediate reboot. Correlation or > causation? *shrug* I don't know. Sometimes I see pipewire processes > with new PID! As in something is restarting them in the middle of the > timeout! That's pretty curious and unexpected, but I don't know what > it means. The bug is currently filed against gnome-session, not pipewire. In the ticket Benjamin Berg linked the following gnome-session bug report[1] and stated "I suppose we did not yet update gnome-session, so that is expected."[2], as a result I am led to believe that this is related to a known issue with gnome-session and a likely fix is to release an update to gnome-session for F34 and rawhide. Why do you believe this bug has not been isolated to a known issue with gnome-session? Please update the issue if it is now known that gnome-session is unrelated to the problem. [1] https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/55 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1909556#c5 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] 2021-02-22 @ 17:00 UTC - Fedora 34 Blocker Review Meeting
If Gnome is still hanging for 2 minutes on reboot [1] then I think we may want to consider that a blocking bug for F34. I can at least confirm that this bug is still affecting Rawhide. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1909556 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> Well, the idea would be for us to put it into Rawhide and do a series > of test days/weeks to get feedback and close any remaining gaps. If it > doesn't manage to pull through by beta freeze, then we would revert > and push it back to Fedora 35. Did these test days/weeks ever happen? I don't recall seeing an announcement or any talk about their results. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)
> A few people mention it in the Raptor forums[2] If there are actually many other page size issues with amdgpu (or other drivers), then from what I can see the raptor/power9 community is unfortunately not reporting these problems upstream which makes it difficult for the developers to be aware of them. > Right now I don't have a spare machine for reboots, testing kernel and > hardware issue like that. I try to keep the machine as stable as > possible. If I can generate revenue from doing POWER9-specific work > then I would be happy to have more of these machines. > > Also, I don't have one of the Radeon Navi GPUs anyway, I defer buying > one until I can get the new Radeon RX6800 XT. They were launched in > November but there is still no stock here. If anybody knows how to get > them for development then I can get a head start on these issues. The bug report I linked mentioned a RX Vega 56, which was released in ~2017. I don't think a Navi card is required to reproduce the problem. > Its not just about me though: I'm sure that if other people buy these > workstations too, that will spread the workload a lot more. Many hands > make light work. As long as the number of developers on the platform is > limited, we have to focus our efforts. > > For example, once we go back to 4k page size, we can divide and conquer: > any bugs that remain are not page size bugs and we can concentrate on > fixing those first. After making good progress there, we could try 64k > again. It's a bit concerning that the power9 community isn't already actively reporting bugs upstream and working to resolve these issues. All niche desktop platforms need at least a few people to really step up and put in work to test, report, and help fix bugs. Right now it appears that the desire to move to 4k pages is in large part motivated by a lack of people willing and able to file bug reports and assist developers (e.g. bisect). I hope I am wrong, but I have not seen anyone bisect an issue in the power9-related amdgpu bug reports. This doesn't bode well for getting desktop-related power9 issues fixed, whether or not it is due to a non-4k page size. My fear is that this is to some degree going against the ethos of Fedora by making a change solely to route around problems upstream rather than engaging with upstream to get the actual issues resolved. > Regards, > > Daniel > > 2. https://forums.raptorcs.com/index.php/topic,100.msg1318.html#msg1318 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)
> The GPUs also have firmware blobs Could you provide some links to mailing list posts or bug reports where AMD developers confirm that their GPU firmware requires 4k pages? I think having some definitive sources will make this situation more clear. So far the only amdgpu bug report I could find that relates to 64k pages[1] is a regression, as the reporter states the driver works with the 5.4 kernel. If someone with a power9 machine is willing to bisect the issue I think that would greatly increase the odds of this bug being resolved. [1] https://gitlab.freedesktop.org/drm/amd/-/issues/1446 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
> A few more things: > > * btrfs-progs tools don't yet have a way to report compression > information. While 'df' continues to report correctly about actual > blocks used and free, both regular 'du' (coreutils) and 'btrfs > filesystem du' will report uncompressed values. Are there plans for upstream to address this pretty major shortcoming in the next release of btrfs-progs? From what I can see on the btrfs wiki the user space support for compression is very rudimentary and with no real indication that it is being worked on or seen as a priority. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Radeon with 64k page size (ppc64 and others)
> We did some more troubleshooting of AMD Radeon issues on ppc64 > > As with Nouveau, it looks like a change from 64k to 4k page size got it > working again with RX 5700. I suspect it will be similar for RX 6800 if > we can get some of them, they are a good complement for the compute power. > > The issue is page size, not ppc64 This sounds like a kernel driver bug that needs to be bisected and reported upstream, do you have a link to the bug report(s)? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> On Tue, Dec 22, 2020 at 6:17 PM Anita Zhang wrote: > > > Another variation on this theme: enable by default in Fedora 34 Server > edition. And more broadly rolled out for Fedora 35. > > If it's broadly ready for Fedora 34, great. Otherwise, it seems like a > good fit for Fedora Server edition, given sd-oomd's server origin and > oomd2 been used in production for a number of years. It'd be a > significant headline feature for Server edition, especially fitting > for the in-progress reboot of that project. Any thoughts from Server > WG folks? I don't think enabling systemd-oomd for Fedora server by default makes a lot of sense right now. Why would we want to automatically enable systemd-oomd in cases where users either have to manually manage cgroups or risk a worse experience than what currently exists with earlyoom? If a user is already creating/managing cgroups themselves, then manually enabling systemd-oomd would be a minor extra step. But if the user isn't managing cgroups (which I believe is the common case), then that user would be pretty surprised if systemd-oomd wipes out a huge swath of running programs that happen to be in the same cgroup. With Gnome and KDE Plasma most of the cgroup creation is done automatically, so it makes more sense to enable systemd-oomd by default as those systems are already set up for systemd-oomd to work well. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
> Okay, and? There's five months between now and beta freeze. Do you > seriously think that the bugs there won't get fixed? Some of them > already *have* been fixed in Plasma 5.19. It looks like most of the issues listed [1] still have open bug reports. Are these bug reports just not getting closed or are these problems not getting fixed? [1] https://community.kde.org/Plasma/Wayland_Showstoppers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> This is intended to be a generic approach to user space oom > management, but it does tie into resource control too. And the > resource control organization of what processes are considered > critical are different between a desktop and a server. The idea of > "user wants to take control or see what's going on" is a generally > important goal for all of this work, regardless of the Fedora edition > or spin. So are you confirming that users are now going to need to place things in their own cgroup if they do not want systemd-oomd to potentially kill the single cgroup containing all of their running applications? I think this should at the very least be clearly documented in the change proposal, as this user experience is in stark contrast to what Gnome and KDE users will encounter. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> If your desktop doesn't segregate apps and services into cgroups, > systemd-oomd will kill the entire desktop whenever anything uses too > much memory, because the desktop is going to be running in the same > cgroup as the apps that it launches. So I think desktop spins (other > than KDE) ought to opt out of this. It should be good for all Fedora > editions, though (including Workstation, Server, Atomic, CoreOS), and > also for KDE spin. How will this work on headless systems like Fedora Server, Atomic, and CoreOS? Will it be expected that users manually create their own cgroups? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> On Mon, Dec 21, 2020 at 1:51 pm, Aleksei Bavshin wrote: > > Hm good point. I think only GNOME and KDE create systemd scopes when > launching apps; systemd-oomd is not going to work well in other > desktops. Probably other desktop spins should opt-out of this change > for now. > > Michael Does this change apply to *all* Fedora releases? Overall I like the change for desktop use, but I'm not sure it currently is a good fit for non-Workstation/KDE spins of Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> Gary Buhrmaster wrote on Mon, Dec 14, 2020: > > With updates-testing enabled here, it's much better than last month (no > more gdm being removed), but there still are a few pulseaudio direct > dependencies: Steam from rpmfusion still conflicts with pipewire-pulseaudio as well. Until that conflict is resolved it is going to prevent a lot of people from being able to test pipewire since it will mean removing their ability to use steam and all of the games tied to it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide PSA: systemd-247-1.fc34 crashing on system shutdown/reboot
I wonder how upstream missed this in testing their release candidates. I'm surprised this serious of a bug made it through to a stable release. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> Currently the PipeWire developers have been doing it by hand while > they are developing the software. I have been going through and fixing > things so that regular folks can do it semi-automatically. > > The packaging for PipeWire has been changing rapidly as the API shims > for PulseAudio changed from libraries to a replacement daemon, that's > why this is broken again. I know why it's currently broken, but that doesn't change the fact that this is being proposed before most people can assess the change. In fact the current amount of churn suggests that pipewire is still a ways off from stabilizing. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> "Premature" is a weird term to use here, considering the whole point > of these things is to be able to do integration work in the first > place. And it's not like we can't revert the change before release if > it turns out to be problematic. Yes, premature as in proposing a huge change to the next version of Fedora before ensuring current users can even test/evaluate said change. The fact that there are packaging conflicts when installing pipewire-pulseaudio strongly suggests that few people have actually been able to install and test the package. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> I am working with Wim (the change proposer), the Workstation WG, and > the KDE SIG to make the necessary adjustments in Rawhide to support > swapping between PulseAudio and PipeWire. So far, Wim has not been > interested in backporting the fixes I've made to Fedora 33, so the > plan would be to start producing media with PipeWire on it for Rawhide > and set up multiple events over the next few months to get things > tested. I really don't think a few test days are at all sufficient for such a sweeping change. The fact users cannot easily test this on F33 makes it even worse. I understand the desire for moving forward, but this change proposal comes off as premature. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> Dne 24. 11. 20 v 15:15 Vít Ondruch napsal(a): > > > Just FTR, this is the situation on Rawhide: > > > ~~~ > > $ sudo dnf swap pulseaudio pipewire-pulseaudio > Last metadata expiration check: 0:03:54 ago on Mon Nov 23 23:14:58 2020. > Error: > Problem 1: problem with installed package > pulseaudio-module-x11-13.99.3-1.fc34.x86_64 > - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires > libprotocol-native.so()(64bit), but none of the providers can be installed > - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires > libpulsecore-13.99.so()(64bit), but none of the providers can be installed > - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires > pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be > installed > - conflicting requests > Problem 2: problem with installed package > pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 > - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires > libpulsecore-13.99.so()(64bit), but none of the providers can be installed > - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires > pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be > installed > - package pipewire-pulseaudio-0.3.16-3.fc34.x86_64 conflicts with > pulseaudio provided by pulseaudio-13.99.3-1.fc34.x86_64 > - conflicting requests > (try to add '--allowerasing' to command line to replace conflicting > packages or '--skip-broken' to skip uninstallable packages) > > > $ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing > > Last metadata expiration check: 0:04:54 ago on Mon Nov 23 23:14:58 2020. > Error: > Problem: The operation would result in removing the following > protected packages: gnome-shell > (try to add '--skip-broken' to skip uninstallable packages) > > > $ sudo dnf remove pulseaudio-module-x11 > Dependencies resolved. > === > Package Architecture Version > Repository Size > === > Removing: > pulseaudio-module-x11 x86_64 13.99.3-1.fc34 > @rawhide 78 k > > Transaction Summary > === > Remove 1 Package > > Freed space: 78 k > Is this ok [y/N]: ^COperation aborted. > > $ sudo dnf remove pulseaudio-module-bluetooth > > Error: > Problem: The operation would result in removing the following > protected packages: gnome-shell > (try to add '--skip-broken' to skip uninstallable packages) > > ~~~ I've filed a bug report for this: https://bugzilla.redhat.com/show_bug.cgi?id=1900876 I think this definitely needs to be resolved quickly if this proposal is to go forward, otherwise the already small testing window will be even more narrow. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-11-22
> On Mon, 23 Nov 2020 at 05:54, Aoife Moloney > What is OSBS? Please don't use undefined acronyms. OSBS = OpenShift Build Service ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
How did you get past the issue of gnome-shell depending on pulseaudio? It's a bit disconcerting that the change proposal's guide on testing pipewire doesn't currently work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
So has this essentially been decided on by the working group? If not, what concerns would be listened to? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
Things like bluetooth support, audio for flatpak applications, and the new pulse server were just added in the last month or so and there are issues with stability and audio playback (look at the issue tracker [1]), for example HSP is still marked as WIP [2]. It seems premature to commit to this change before the core features have been stabilized and more testing has been done. Audio is an area where users really have no tolerance for it misbehaving. Pushing a change like this too early can create a negative perception of the project which is something we should try to avoid (within reason). I also don't know of any current documentation on switching to and testing pipewire with F33 or rawhide since the deprecation of pipewire-libpulse and the introduction of pipewire-pulseaudio, as the old guide relies on libpulse [3]. I think at the very least bluetooth support needs to mature, and pipewire-pulseaudio needs to be tested for 1 full Fedora release cycle, so I would vote for delaying this until F35. [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues [2] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/TODO [3] https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F32 to F33
During an attempted upgrade to F33 Beta I ran into: Error: Transaction test error: file /usr/lib/.build-id/0e/fd9f1f23d7cefd37989b7d1b401b4994fee742 conflicts between attempted installs of openjfx-11.0.3-1.fc33.x86_64 and openjfx8-8.0.202-24.b07.fc33.x86_64 file /usr/lib/.build-id/2d/747b771939ec456dadf18bfbec6a5db9d3a4cc conflicts between attempted installs of openjfx-11.0.3-1.fc33.x86_64 and openjfx8-8.0.202-24.b07.fc33.x86_64 If this needs to be formally filed as a bug, should it be opened against openjfx or fedora-upgrade or something else? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: btrfs and default page sizes (4k vs 64k)
> On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler wrote: > > I hate to break it to you, but this problem is not just in > filesystems, it's in basically everything in the kernel. And we've had > variations of problems like this for years (endianness, page size, > pointer size, single bit vs multi-bit booleans, etc.). I've personally > been bitten by all of these issues in some way. This comes from the > fact that there's no such thing as "internal implementation detail of > the kernel" by design. This is the "joy" of the monorepo > "design" > where everything leaks into everything else. > > This didn't become a serious problem until Red Hat made the > unfortunate (though not realized at the time) mistake of switching to > 64k pages for ARM and POWER. We got that change in Fedora for POWER > but not ARM. It has led to all kinds of unfortunate problems that are > gradually being worked on and fixed upstream. > > Coming back to Btrfs specifically, there is work underway upstream to > resolve this issue. My (semi-blind) estimate is that we'll see a fix > in Linux 5.11, but Josef (cc'd to this email) may know more about it. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! Frankly I'm disappointed that the response is to deflect criticism of btrfs by claiming that this is an expected issue with the kernel, and then placing the blame on Red Hat for using a larger page size. To my knowledge page size differences aren't an issue on ext4 or xfs as they default to using a 4kb block size, so saying that "it's in basically everything in the kernel" is at best inaccurate and at worst intentionally misleading. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
> KDE > spin is a blocker edition, so its default installation must pass our > release criterias. > https://fedoraproject.org/wiki/Fedora_Release_Criteria Right, but have there been any investigations to see if those release criteria are fulfilled on Plasma + Wayland? If it doesn't currently meet all criteria, what are the known blockers? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
Has anyone compiled a (non-exhaustive) list of known issues that are specific to KDE Plasma with Wayland? Are there currently any issues that would block Wayland from becoming the default if they aren't resolved in time for F34? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> What changes? I don't see a reason for this level of snark, in your next paragraph you described the changes I'm talking about. > Discussion is happening upstream to determine the best location for > such optimization to happen. I'm glad work is happening upstream and I hope it goes smoothly, but I don't see how there is a guarantee that everything will be done in time for Fedora 33. I'm not implying people aren't working on it, I'm suggesting that reality often doesn't go exactly as envisioned. > (open)SUSE has been doing this for six years, I don't think it's > correct to suggest these complexities aren't well understood, or that > it's possible they won't happen for Fedora 33. On one hand you're saying that all complexities are well understood and that it is incorrect of me to suggest that any of those changes could miss F33's release date. Yet on the other hand you mention that openSUSE has used btrfs by default for 6 years, so then why haven't these changes landed upstream years ago? Further, you stated that for databases it's not yet clear when/if nodatacow is a performance win. This suggests that it is not outlandish to say there are remaining complexities. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> (Yes, that means applications need to start being concious of what fs > they are being run on, or at least the fedora configuration needs to do > that check for them) Right, and it's concerning to me that Fedora is committing to btrfs by default before important applications have become more enlightened about running on btrfs. If upstream changes don't land in time for Fedora 33, we will be implicitly expecting users to be aware of these pitfalls and leave them to implement manual workarounds. I'd imagine a good bit of thought and work will have to go into creating, testing, and upstreaming those patches, so I think it's very possible that an appreciable number of changes will not land in time for Fedora 33. For example with virtualization I'd think that the changes would need to happen around the level of libvirt, and not to specific a front-end like GNOME boxes or virt-manager. It's also probably not sufficient to just set nodatacow on the default VM image directory as users may use a non-default directory for qcow2 images. Hence I don't think these issues will always have trivial solutions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> It doesn't use compression so not relevant to the cited statement? Well the paper compares ext2, ext4, xfs, f2fs, and btrfs in terms of IO amplification and states: "In fact, in all our experiments, btrfs was an outlier, producing the highest read, write, and space amplification." The results listed in Tables 1 and 2 show that btrfs does incur higher amounts of IO, so even with compression it's not at all obvious that this would bring btrfs down to levels comparable to (or lower than) the other file systems. Hence I believe Vitaly is linking this paper to suggest that evidence is needed before we can confidently assert that btrfs + compression is better at preserving nand than using ext4 or xfs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
> BIOS-based systems make up a miniscule minority of the current market. > Pretending otherwise is delusional, and delusions are no basis for > technical decisions. > > - Solomon In terms of physical x86 systems, you are right that UEFI is the overwhelming majority. But as stated elsewhere in this thread, a lot of cloud providers and virtualization software default to using BIOS. So I think Fedora should only start considering dropping BIOS support once the default is UEFI on most virtualization platforms. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: drop bfq scheduler, instead use mq-deadline across the board
> I'm not convinced it's the domain of an IO scheduler to be involved, > rather than it being explicit UX intended by the desktop environment. > Seems to me the desktop environment is in a better position to know > what users expect. Well wouldn't bfq just be enforcing the bandwidth weights, if any, that were explicitly set in the various groups? If something is already creating and modifying control groups, then that something should have total control over setting the bandwidth weights. It's not obvious to me how the IO scheduler would be bypassing or otherwise ignoring whatever manages control groups. It's also not clear to me how anything except an IO scheduler would be able to directly control how device bandwidth is shared. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: drop bfq scheduler, instead use mq-deadline across the board
I forgot to mention that bfq appears to be the only IO scheduler that supports cgroups-v2 IO controllers [1]. Perhaps I am wrong, but I wasn't able to find documentation indicating that mq-deadline is cgroup-aware, at the very least it's not documented in the official deadline tunables section [2]. I'm mentioning this because btrfs' support for cgroups-v2 (and the IO isolation/fairness capability it provides) was listed as one of the key reasons to move to btrfs. While I am not clear on exactly how the IO scheduler and files system interact when it comes to IO cgroups, I thought it was worth bringing up. [1] https://www.kernel.org/doc/html/latest/block/bfq-iosched.html#group-scheduling-with-bfq [2] https://www.kernel.org/doc/html/latest/block/deadline-iosched.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes > it beg the question if now would not be the time to stop supporting > booting in legacy bios mode and move to uefi only supported boot which > has been available on any common intel based x86 platform since atleast > 2005. > > Now in 2017 Intel's technical marketing engineer Brian Richardson > revealed in a presentation that the company will require UEFI Class 3 > and above as in it would remove legacy BIOS support from its client and > datacenter platforms by 2020 and one might expect AMD to follow Intel in > this regard. > > So Intel platforms produced this year presumably will be unable to run > 32-bit operating systems, unable to use related software (at least > natively), and unable to use older hardware, such as RAID HBAs (and > therefore older hard drives that are connected to those HBAs), network > cards, and even graphics cards that lack UEFI-compatible vBIOS (launched > before 2012 – 2013) etc. > > This post is just to gather feed back why Fedora should still continue > to support legacy BIOS boot as opposed to stop supporting it and > potentially drop grub2 and use sd-boot instead. > > Share your thoughts and comments on how such move might affect you so > feedback can be collected for the future on why such a change might be > bad, how it might affect the distribution and scope of such change can > be determined for potential system wide proposal. > > > Regards > > Jóhann B. > > > 1. > https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration The primary areas of concern I have about Fedora dropping grub2 and BIOS boot support are: 1. Users that are on systems that do not support UEFI, or that knowingly (or unknowingly) use BIOS boot on UEFI-capable systems. These people are likely to form a lasting negative impression of Fedora, as removing BIOS boot support would ostensibly mean that Fedora no longer runs on their systems (at least as configured). I have heard that the UEFI implementations on some (typically older) motherboards can be buggy, so many users may have a legitimate reason to still use BIOS boot on boards that advertise support for both. 2. How would dropping grub2 affect users that boot multiple operating systems? What manual steps, if any, would users need to take if they were previously using grub2 to support booting multiple operating systems. Would this change break existing multi-boot setups? 3. Virtual machines typically default to BIOS boot. It's my understanding that libvirt, Virtual Box, Hyper-V (gen1 VMs only?), and many cloud providers default to using BIOS boot when creating virtual machines. If Fedora no longer works *by default* with common virtualization stacks I'd imagine many users will simply choose to no longer run or recommend Fedora. 4. Support documentation for sd-boot Would this result in changes to how users access the boot menu, select a boot entry, or edit the kernel command line, etc? These actions of course aren't expected to be common but when they are needed it tends to be when a user is already experiencing problems and is under stress. Therefore if there are changes, hopefully these will be clearly documented to avoid confusion. 5. What does Fedora gain by dropping BIOS boot support? Perhaps it is obvious to others, but I think it is worth fully spelling out what the expected benefits are. This would help everyone more clearly see the trade-offs of this change. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: drop bfq scheduler, instead use mq-deadline across the board
> It's super annoying for me to post, because benchmarks drive me crazy, > and yet here I am posting one - this is almost like self flagellation > to paste this... > > https://www.phoronix.com/scan.php?page=article=linux-56-nvme;... > > None of these benchmarks are representative of a generic desktop. The > difficulty with desktop workloads is their heterogenetity. Some people > are mixing music, others compiling, still others lots of web browsing > (Chrome OS I guess went to bfq around the same time we did), and we > just don't really know what people are going to do. Some even use > Workstation as a base for more typical server operations. > > The geometric mean isn't helpful either, because none of the tests are > run concurrently or attempt to produce tag starvation which would > result in latency spikes. That's where mq-deadline would do better > than none. In case you find it useful, Paolo has posted his own results from testing IO schedulers on Linux [1][2] as well as the scripts he used to generate the load [3]. I don't claim that these results have been independently verified or that they are good representations of the real world, but they may be a useful set of data points. [1] http://algo.ing.unimo.it/people/paolo/disk_sched/results.php [2] https://www.youtube.com/watch?v=w2bREYTe0-0 [3] https://github.com/Algodev-github/S ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: drop bfq scheduler, instead use mq-deadline across the board
> The latter but considering they're a broad variety of workloads I > think it's misleading to call them server workloads as if that's one > particular type of thing, or not applicable to a desktop under IO > pressure. Why? (a) they're using consumer storage devices (b) these > are real workloads rather than simulations (c) even by upstream's own > descriptions of the various IO schedulers only mq-deadline is intended > to be generic. (d) it's really hard to prove anything in this area > without a lot of data. You are right that the difference between them is blurry. My question comes from being unsure if it's the case that Fedora users are experiencing problems with bfq but are not reporting them, or if there is something specific that is causing that pathological scheduling behavior at Facebook. It was also my understanding that Facebook primarily uses NVMe drives [1][2], and that is the class of storage Fedora does not use bfq with. Is it possible these latency problems occurred when using bfq with NVMe drives? I now see that Paolo was cc'd in comment #9 of the bugzilla ticket, so hopefully he responds. > But fair enough, I'll see about collecting some data before asking to > change the IO scheduler yet again. For the record, I definitely agree that mq-deadline should become the default scheduler for NVMe drives. [1] https://nvmexpress.org/how-facebook-leverages-nvme-cloud-storage-in-the-datacenter/ [2] https://engineering.fb.com/data-center-engineering/introducing-lightning-a-flexible-nvme-jbof/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: drop bfq scheduler, instead use mq-deadline across the board
> https://bugzilla.redhat.com/show_bug.cgi?id=1851783 > > The main argument is that for typical and varied workloads in Fedora, > mostly on consumer hardware, we should use mq-deadline scheduler > rather than either none or bfq. > > It may be true most folks with NVMe won't see anything bad with none, > but those who have heavier IO workloads are likely to be better off > with mq-deadline. > > Further details are in the bug, but let's discuss it on list. Thanks!g I'm a little confused by this proposal because last year the author of bfq, Paolo Valente, worked with the Fedora community to switch to bfq by default on non-NVMe drives [1]. Now another kernel developer is telling us that bfq has performance problems that ostensibly aren't being fixed. So my immediate question is: have these problems been reported to Paolo and what has his response been? From what I can tell bfq was chosen because it improved the responsiveness of the desktop, and so I'm curious where it's falling short. Are there performance issues with workloads that Fedora users are running, or have these latency spikes primarily been seen with Facebook's server workloads? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1738828 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: User experience issue on btrfs
> I don't want to give the impression that nodatacow (chattr +C) is what > apps should be doing "to be fast on btrfs". It might be that they can > reduce their fsync footprint. Or the problem might be lock contention > related, and an easy optimization for a heavy metadata writing apps > would be for this app to create+use their own subvolume for their data > files, rather than a directory - and now they get their own btree. Do we know what use cases are expected to not be transparent if run on top of btrfs? e.g. Will F33 users that run virtual machines and/or databases be expected to manually change settings in order to avoid performance degradation? Also do we know roughly how much of a performance hit those users will experience if they do not make any changes? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: User experience issue on btrfs
> I'd like to propose a few guidelines: > > 1. If btrfs causes noticeable performance issues for users, that's not > OK. It's understood and expected that it might be slower at many > workloads, but if the difference is large enough that users notice a > significant regression in desktop responsiveness, that's a serious > problem. (I have no doubt the change owners believe such cases are very > rare, as otherwise btrfs would surely not be under consideration at > all.) > > 2. Exception to above rule: applications are expected to be suitably > optimized for the operating system, not vice-versa. So if a > virtualization framework or database is not using the recommended > chattr +C, that's the fault of the application, not Fedora, and it's OK > for writes to be slow while the application is busy pounding the disk. > Applications will not be updated for btrfs until after distros start > using it by default, so we cannot reasonably wait for applications on > this, as we'd wind up waiting another decade probably. Sounds like this > is easy for applications to fix, at least. > > 3. Users should not be expected to customize anything or use the > command line, ever, period. So for the purposes of figuring out what's > causing this performance issue, it sounds very useful to test different > mount options. But an actual solution must not require any > customization. For users that run virtual machines, it sounds like they will need to set the "nodatacow" attribute for all vm images in order to get acceptable performance. If this isn't made clear I could imagine a lot of performance complaints from users. Also what can/should be done to help users that intend to run databases on Fedora? Does anyone know how openSUSE handles these use cases? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> You didn't make a mistake. Pretty sure it's a blocker bug too so I've > proposed it as such. Thank you for doing that, I appreciate it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> The context of that is: the default when the user does not specify. If > the user chooses 'raid1' in the installer, they get 'raid1' for both > data and metadata. This does not seem to be the case, and from what I can tell Garry experienced this problem as well. I tested this in a VM with two disks, I manually selected the "raid1" profile with btrfs in the advanced custom partitioning screen. After the installation I ran "btrfs filesystem df /", which output: Data, RAID0: total=2.00GiB, used=1.54GiB System, RAID1: total=8.00MiB, used=16.00KiB Metadata, RAID1: total=1.00GiB, used=46.28MiB GlobalReserve, single: total=4.39MiB, used=0.00B I interpret "Data, RAID0" to mean that the data is striped rather than mirrored, and thus my data will be lost if/when a single drive fails. I hope that I made some obvious mistake, as this appears to be a pretty serious problem otherwise. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> For btrfs, it's raid0 data, raid1 metadata. Surely this is considered a serious installer bug? Users who choose an option called "raid1" with btrfs would, and should, expect to have data redundancy. Even if this bug has existed for a long time, it doesn't make it any less dangerous. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> I'm not sure where it is in the priority list. > > If you're doing a preemptive replace, there's no degraded state. Even > if there's a crash during this replace, all devices are present, so > it'll boot normally. The difficulty is if a drive has died, and > there's a reboot before a replace has started. The main problem is that drive failures can occur when a system crashes, like a sudden power loss. In such a case all other raid 1 arrays would be able to boot normally and continue to be available with one failed drive. Given this honestly bizarre behavior of btrfs in the face of drive failure, I don't think its raid implementation can be considered production ready yet. I understand that raid setups are not the common case, but if it is an option in the installer I think it should at least come with a warning. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> On Sat, Jun 27, 2020 at 7:32 PM Garry T. Williams wrote: > > > Just a PSA: btrfs raid1 does not have a concept of automatic degraded > mount in the face of a device failure. By default systemd will not > even attempt to mount it if devices are missing. Is this hopefully seen by upstream as a bug that will be fixed? This removes the system availability benefits of raid, and I've never heard of another system that would behave like this, whether that's zfs, md, or hardware raid. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Yep, I just ran "dnf info kernel" and then right after that "dnf changelog kernel", in both cases dnf spent over 20 seconds syncing. I haven't seen other package managers require this much network traffic, and I wonder if a lot of it could be avoided. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java Dev Group and Fedora Quality
> On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel *snip* > True. Nobody cares about Java packages in fedora, not even Red Hat > employees. If you look at the members of the Java SIG, a lot of them > were (or still are) Red Hat employees. For example, even JBoss / > WildFly (a pretty big Java project by Red Hat) was unmaintained and > broken, and most of it has now been removed from future fedora > releases. I wonder what they are going to do with RHEL 9 - maybe > somebody notices their stuff isn't available on fedora anymore. Do you happen to know what the Red Hat employees who maintain Java-based products use as their desktop OS? RHEL? macOS? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update
I have some concerns about this proposal. Given that this change was essentially unanimously rejected, this line stood out to me: > * As soon as feature is accepted by the community, there will be a > smooth process to update baseline in the main Fedora, as all packages > will be already verified and tested to work against it. This makes it sound as if this change is inevitable and that the community is simply being stubborn or ignorant of its importance. The current (and foreseeable) situation is that Intel will continue to use SIMD extensions as a way to help segment its processor lines, for example we know that the new low power microarchitecture, Tremont, will not have AVX2 support [1]. Currently, Intel's atom [2], celeron [3], and pentium [4] processors do not have AVX2 support. Not to mention that this change would eliminate support for all AMD processors made before 2017 (pre-Zen) and all Intel processors made before 2013 (pre-Haswell) so I am worried that this is a step towards abandoning a large swath of processors for reasons and goals that have not been fully articulated. So here are some questions that would help me better understand this proposal: 1. The motivation behind the change is clearly performance, but what packages and/or use cases are expected to see a significant increase in performance? What testing/benchmarking has been done to demonstrate these improvements, and where can we see the results? 2. Since it is likely that new SIMD extensions will be implemented in the future, what are the factors considered for moving the baseline of Fedora? What is an acceptable age for a processor to be before it is unsupported? Do we want Fedora to only target mid and high end Intel processor SKUs? What performance increases (and for which packages) merit consideration for bumping the baseline? 3. Why was AVX2 chosen as the baseline? Specifically, why was it chosen over a more conservative increase to something like SSE4.1/4.2, or a more aggressive increase to AVX512? 4. Given that the author of the proposal is expecting this change in x86_64 baseline to be implemented at some point in the future, what is the projected timeline and what is currently blocking this change from being proposed again (besides the community)? [1] https://en.wikichip.org/wiki/intel/microarchitectures/tremont [2] https://ark.intel.com/content/www/us/en/ark/products/184994/intel-atom-processor-c3336-4m-cache-1-50-ghz.html [3] https://ark.intel.com/content/www/us/en/ark/products/134879/intel-celeron-processor-g4950-2m-cache-3-30-ghz.html [4] https://ark.intel.com/content/www/us/en/ark/products/135457/intel-pentium-gold-g5620-processor-4m-cache-4-00-ghz.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
I think this would be a really big improvement for workstation and other desktop spins, the handling of out of memory situations have been a consistent paint point on Linux. However, may I ask why EarlyOOM was chosen over something like NoHang [1]? I am a bit concerned that EarlyOOM's heuristics may be too coarse, as it does not take into account the newly-added PSI metrics [2][3] that other projects like NoHang, oomd, and low-memory-monitor utilize. For example, if the system is thrashing, but swap is not full, to my knowledge EarlyOOM will not see a problem, however it would be visible via PSI. To be clear, I'd rather have something in time for 32 to improve OOM handling than wait several release cycles for the ideal solution to be ready. I'm simply curious about what problems, if any, were encountered with the other potential candidates. [1] https://github.com/hakavlad/nohang [2] https://facebookmicrosites.github.io/psi/docs/overview [3] https://www.kernel.org/doc/html/latest/accounting/psi.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations
Hi Chris, Does zswap actually keep the data compressed when the DRAM-based swap is full, and it writes to the spill-over non-volatile swap device? I'm not an expert on this at all, however my understanding was that zswap must decompress the data before it writes to the backing swap. But perhaps I am misunderstanding the purpose of zswap_writeback_entry()[1] and/or what it does. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/zswap.c#n828 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F30 to F31
Here's the error I run into on my desktop: Error: Problem: problem with installed package eclipse-jgit-5.4.0-4.fc30.noarch - eclipse-jgit-5.4.0-4.fc30.noarch does not belong to a distupgrade repository - nothing provides jgit = 5.3.0-5.fc31 needed by eclipse-jgit-5.3.0-5.fc31.noarch Eclipse doesn't appear to be having a good time right now with the transition to 31 from what I see: https://apps.fedoraproject.org/koschei/groups/eclipse ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
