> 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
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.
--
> 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
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
> 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:
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
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
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:
> 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
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
> 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
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
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
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
> 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
>
> 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
> 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.
> 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:
> 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
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 --
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
> 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
&g
> 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
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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.
>
>
> 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
> 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
> 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
> 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)
> 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
> 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
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
> 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
> "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
> 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
> 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
>
> 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
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
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:
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
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
> 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
> 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
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
> 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
> (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
> 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
> 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
> 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
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
> 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
>
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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.
> 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
> 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
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.
> 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
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
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
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
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
73 matches
Mail list logo
