desktop October 2018

desktop@lists.fedoraproject.org

33 participants
26 discussions

using extensions.gnome.org in epiphany
by Kamil Paral 16 Oct '18

16 Oct '18

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.

2 2

2018-10-15 @ 16:00 UTC - Fedora 29 Blocker Review Meeting
by Adam Williamson 15 Oct '18

15 Oct '18

# 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 wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process 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: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 2

[Fedocal] Reminder meeting : Silverblue APAC
by sinnykumari＠fedoraproject.org 15 Oct '18

15 Oct '18

Dear all, You are kindly invited to the meeting: Silverblue APAC on 2018-10-16 from 05:30:00 to 06:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Fedora Silverblue is an rpm-ostree-based Fedora desktop edition. This meeting has been kept in APAC friendly timezone for folks interested in working on making Silverblue better. Issue tracker - https://pagure.io/teamsilverblue/issues More information available at: [https://teamsilverblue.org/](https://teamsilverblue.org/) Source: https://apps.fedoraproject.org/calendar/meeting/9315/

1 0

[Fedocal] Reminder meeting : Silverblue
by sanja＠redhat.com 14 Oct '18

14 Oct '18

Dear all, You are kindly invited to the meeting: Silverblue on 2018-10-15 from 09:00:00 to 10:00:00 US/Eastern At fedora-meeting-2(a)irc.freenode.net 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. Source: https://apps.fedoraproject.org/calendar/meeting/9304/

1 0

F29: power notification on gnome lock screen, no journal messages
by Chris Murphy 11 Oct '18

11 Oct '18

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 8

F29 Workstation article needed for Fedora Magazine
by Jens-Ulrik Petersen 08 Oct '18

08 Oct '18

Hi, this came up in the WS WG meeting today, and noone present felt able to commit. Anyone want to author the F29 Workstation article for the Fedora Magazine? See https://pagure.io/fedora-workstation/issue/78 ("What's new in F29 Workstation article for Fedora Magazine")

1 0

Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option
by Hans de Goede 08 Oct '18

08 Oct '18

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

11 29

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
by Kamil Paral 08 Oct '18

08 Oct '18

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 [1], 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. [1] https://github.com/ValveSoftware/Proton/blob/proton_3.7/PREREQS.md#fd-limit…

1 0

Disable (or make configurable and default to off) suspend-then-hibernate behavior in GNOME-3.30
by Hans de Goede 08 Oct '18

08 Oct '18

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

18 78

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
by Lennart Poettering 08 Oct '18

08 Oct '18

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop October 2018