I've joined the list at Dan's suggestion, as I will be maintaining
waypipe now, and admittedly it could be useful for sway users, so why
Looking at the SIG page there is a wishlist item for "redshift with
wayland support", and as a big user myself I would be all for it.
The problem is that upstream has not been very active for a while -
merged one PR in 2019, but that aside pretty much nothing since 2018.
Frankly major DEs (gnome, KDE) incorporate the feature natively so users
of redshift on wayland will basically only ever be wlroots-based
compositors, so we shouldn't expect to get much help from anywhere on
this... I imagine the dev uses gnome as he wrote the gnome-clock
location helper redshift-gtk service files, so he's made the switch and
hasn't looked back much.
The wayland support issue suggests arch uses minus7's wayland
branch but that would appear to still be AUR and they are in the same
situation as us (some coprs have it alongside older versions of sway but
I would suggest the way forward would be to try to discuss with jonls
and minus7 if an official fork could start somewhere; either minus7 tree
if he is willing to do it or I suppose I could (I also have vested
interest, I am also using the stdin remote control patches discussed on
this issue, so "just" wayland wouldn't be enough for me, and whoever
takes over would need to be willing to deal with at least accepting PRs
So, what do you folks think? Worth a shot?
Hi folks (sway list CC'd as this also relevant for sway),
in case you missed the thread on devel about systemd-oomd, the (imho)
most important message for the i3 spin is below.
If I understand this correctly, we'll have to ensure that systemd-oomd
is disabled in the i3 spin, as it will simply kill the whole desktop if
anything starts consuming too much memory. Unless anyone has an idea how
to put every application that is launched from i3 into a cgroup in the
same way that gnome shell already does that? The later would be of
course preferable, as having apps in cgroups has a lot of advantages,
but I don't know how feasible it is for us to achieve this.
Cheers & happy holidays,
-------------------- Start of forwarded message --------------------
Date: Tue, 22 Dec 2020 13:03:14 -0600
From: Michael Catanzaro <mcatanzaro(a)gnome.org>
Subject: Re: Fedora 34 Change: Enable systemd-oomd by default for all
variants (System-Wide Change)
To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
On Tue, Dec 22, 2020 at 6:55 pm, Tom Seewald <tseewald(a)gmail.com> wrote:
> 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.
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.
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://firstname.lastname@example.org
-------------------- End of forwarded message --------------------