using extensions.gnome.org in epiphany
by Kamil Paral
Hello folks,
I've always used Epiphany to manage my gnome shell extensions (through
extensions.gnome.org), because it just worked out of the box, without any
need of additional plugins being installed (I think you just needed to
install chrome-gnome-shell rpm to the system). But in F29, that no longer
works, I see just a generic "We cannot detect a running copy of GNOME on
this system" when showing the web page in Epiphany. I also don't see any
way to install any plugin into it (Chrome store plugin is not compatible).
Is this a bug, or am I doing something wrong, or did Epiphany lose the
ability to integrate with extensions.gnome.org intentionally?
PS: Installing chrome-gnome-shell RPM and the right plugin into
Firefox/Chromium from their store works fine. It's just Epiphany that's
problematic.
Thanks.
5 years, 6 months
F29: power notification on gnome lock screen, no journal messages
by Chris Murphy
Crossposting
test@
desktop@
Hi,
I keep getting this weird behavior on Fedora 29 for which there are no
journal messages at all. This is the setup:
1. on battery power
2. Settings>Power>Blank Power = 5 minutes
3. Settings>Power>Dim Screen when inactive = On
4. Settings>Power>Automatic Suspend>Battery = On, 15 minutes
---
5. Use is inactive for more than 5 minutes, and less than 15. (At 15
minutes it definitely goes into suspend successfully).
6. I look up and see the GNOME lock screen with multiple yakyak
notifications, and also see a power notification (international stop
sign symbol). The power notification doesn't itself make the display
come on, it's yakyak. If I don't receive an incoming message on
yakyak, I have no idea the power notification is present. And if I
take a screenshot while the display is off, the screenshot file is all
black.
7. The instant I click on any key or the trackpad, only the power
notification vanishes. The yakyak message remain in the list, and once
I log back into my user session, the power notification is not in the
drop down list of notifications when clicking on the time. And yet all
the yakyak notifications are in the list.
8. Nothing in the journal related to power
https://paste.fedoraproject.org/paste/p1Y-B8Sq3446sM4H5FtvgQ/raw
Is there a way to make the environment spit out more verbose messages
into the journal? I don't see a debug or verbose option with
gnome-shell -h
gnome-shell-3.30.0-7.fc29.x86_64
--
Chris Murphy
5 years, 6 months
Disabling kernel's hibernate support by default, allow re-enabling it
with a kernel cmdline option
by Hans de Goede
Hello Fedora kernel team,
On the Fedora desktop list there has been a discussion about
systemd now offering a new suspend-then-hibernate option and
gnome-settings-daemon's media-keys plugin using this when
the power-button gets pressed and systemd saying this is
available on the system.
What this does is suspend the system normally and set
a RTC wakeup 3 hours in the future, then when the RTC wake
happens it hibernates the system.
As discussed on the desktop list this is not really desirable
as default behavior for F29 (and later) since the hibernate
code is not really something which gets used enough to be
well tested and is really not something which we can support.
So after that the discussion has gone in the direction of
how to disable the new suspend-then-hibernate behavior.
Lennart made a really interesting observation here, systemd
is just proxying if "cat /sys/power/disk" indicates that
hibernate is supported.
So if we really don't want to support hibernation as a normal
option, while still allowing adventurous user to use it, what
really should happen is for the kernel to stop advertising
hibernate support. Thinking about this I agree, if we say
that we cannot support it, the kernel really should not be
advertising support for it by default.
So Bastien suggested to change the nohibernate setting in
kernel/power/hibernate.c which can be set from the kernel
commandline to default to 1, and allow setting it back
to 0 by adding "hibernate=yes" to the kernel commandline.
I kinda like this idea and I'm willing to spend some time
to write a patch for this and submit it upstream, which allows
selecting nohibernate=1 as the default through Kconfig.
But before I spend (some) time on this, I wonder what the
kernel team's opinion on this is ?
My own 2 cents on this are:
Pro:
Not advertising hibernate by default means users will not
accidentally try to use it (through e.g gnome-tweaks) and if
they do use it by specifying the kernel commandline option
we can easily explain that using that commandline option is
not supported by Fedora and kindly request them to file bugs
upstream. TL;DR: less kernel issues for Fedora to deal with,
good.
Against:
Currently we do have some users using hibernation without
adding any options to the kernel commandline. These users
will have to now add "hibernate=yes" to their kernel commandline.
I'm thinking that yes we want this, but maybe this needs to
go through the change process for proper communication, so for
F29 we need another fix, and we can do this for F30?
Regards,
Hans
5 years, 6 months
Disable (or make configurable and default to off)
suspend-then-hibernate behavior in GNOME-3.30
by Hans de Goede
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really
ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is
a huge change and involves code paths which no other major
distro has been using sofar.
So we really need to disable this for Fedora 29. And as
mentioned in the thread when we decide to enable this for
a future release, it really needs to go through the changes
process so that it is well document we are changing this
and people will have a clue what is the likely culprit
if leaving their laptop suspend for > 3h all of a sudden
breaks.
Regards,
Hans
5 years, 6 months
Re: raise fileno limit to make Steam Proton / Wine+esync work well
in Fedora
by Lennart Poettering
On Fr, 05.10.18 12:28, Nicholas Miell (nmiell(a)gmail.com) wrote:
> >> This is not quite the 1M you appear to ask for though… I picked 256K
> >> mostly because I wanted to stay lower than the kernel built-in max
> >> (which is 1M, i.e. /proc/sys/fs/nr_open), and needed to pick
> >> something. Do you have any particular reason to prefer 1M over 256K? I
> >> am completely open to suggestions there...
> >
> > The upstream esync branch requests setting the hard limit to 1M.
> >
> > https://github.com/zfigura/wine/blob/esync/README.esync
> >
> > I haven't torn apart the project to see if 1M is really necessary so a
> > different limit may be up for discussion.
>
> esync uses eventfd to reduce IPC to wineserver when emulating Windows
> kernel objects, the exact number of eventfds needed depends entirely on
> the behavior of the Windows application you are running.
So, any idea why they picked 1M? Are there typical apps that require
really that many?
I mean, it could be two things:
1) yes, they ran into real-life apps that require 500K fds and hence
set the limit to 1M since they can't set it any higher anyway, and
it's far away from (i.e. double of) 500K.
2) no, they didn't run into real-life apps like this, but didn't want
to figure out what a good limit is, hence they set it to the
kernel's built-in maximum of 1M.
If it's #1 then I figure we should bump the systemd upstream to 1M
too. If it's #2, then I figure we can start with 256K as my PR
currently does, for now.
Lennart
--
Lennart Poettering, Red Hat
5 years, 6 months