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
# F29 Blocker Review meeting
# Date: 2018-10-15
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 7 proposed Final blockers and 2 proposed Final freeze
exceptions to review, so let's have a review meeting on Monday. We have
GNOME and dnf bugs, and one iSCSI bug on the list.
** NOTE ** I may not be able to run the meeting, as I'm going on
vacation that same Monday. If I'm not available, we really need someone
else to step up and run the meeting, as this is the last review meeting
before the go/no-go meeting which is on Thursday. Running the meeting
is easy, there is an SOP (linked below) and you can also refer to the
logs from previous meetings for tips.
If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting - the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F29 can be found on the
For more information about the Blocker and Freeze exception process,
check out these links:
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
Have a good weekend and see you on Monday!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
You are kindly invited to the meeting:
Silverblue on 2018-10-15 from 09:00:00 to 10:00:00 US/Eastern
The meeting will be about:
Fedora Silverblue IRC meeting in #fedora-meeting-2 on Freenode. Fedora Silverblue is an rpm-ostree-based Fedora desktop edition.
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
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
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
Hi, this came up in the WS WG meeting today, and noone present felt able to
Anyone want to author the F29 Workstation article for the Fedora Magazine?
("What's new in F29 Workstation article for Fedora Magazine")
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:
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,
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?
On Mon, Oct 8, 2018 at 11:09 AM Michal Konečný <mkonecny(a)redhat.com> wrote:
> Maybe it will be also good to look at the SteamOS distribution and what
> limits they are using.
According to the proton document , SteamOS also has an increased fileno
hard limit. I haven't verified the actual value, but they probably just
inherit it from Debian. And on SteamOS they really wouldn't need to go
lower than on Debian, it's a gaming-only OS.
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
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 Poettering, Red Hat