October 2018 - desktop - Fedora Mailing-Lists

[Fedocal] Reminder meeting : Silverblue APAC

by sinnykumari＠fedoraproject.org

Dear all, You are kindly invited to the meeting: Silverblue APAC on 2018-10-30 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/

4 years, 11 months

1
0
0 / 0

[Fedocal] Reminder meeting : Silverblue

by sanja＠redhat.com

Dear all, You are kindly invited to the meeting: Silverblue on 2018-10-29 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/

4 years, 11 months

1
0
0 / 0

Workstation WG meeting recap 2018-10-22

by Paul W. Frields

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2018-10-22/workstation... Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2018-10-22/workstation... Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2018-10-22/workstation... * * * ================================= #fedora-meeting-2: Workstation WG ================================= Meeting started by stickster at 13:03:37 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2018-10-22/workstation... . Meeting summary --------------- * roll call (stickster, 13:03:46) * ryanlerch is on PTO and sends regrets (stickster, 13:05:05) * Workstation related F29 blockers (stickster, 13:09:12) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1637418 (stickster, 13:09:41) * Should we recommend https://bugzilla.redhat.com/show_bug.cgi?id=1637418 as a special blocker? (mcatanzaro, 13:09:47) * if we do this, Fedora 29 will surely be delayed another week (mcatanzaro, 13:10:03) * AGREED: bug 1637418 is a blocker in WG opinion (+1: 5, 0: 1, -1: 0) (stickster, 13:34:21) * https://qa.fedoraproject.org/blockerbugs/milestone/29/final/buglist has the list of all the blockers (kalev, 13:34:36) * we have two gnome-maps blockers, which at least one I believe is fixed upstream (kalev, 13:34:54) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1633133 (kalev, 13:35:20) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1637751 (kalev, 13:35:24) * IDEA: Drop Maps from default Workstation (stickster, 13:39:01) * ACTION: stickster come up with a template for the Workstation WG issue tracker for default app adds -- in which one also has to confirm it's actively maintained (stickster, 13:39:59) * ACTION: stickster be at blocker meeting and argue to remove 1637751 from blocker list (stickster, 13:53:56) * ACTION: kalev get fix for 1633133 into package (stickster, 13:54:22) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1640701 is a gnome-software blocker that needs quite a bit of code changes, I'm working on it and about half way done (kalev, 13:58:31) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1632981 is a input bug, something between gtk+ and mutter. garnacho is tracking it down (kalev, 13:59:02) * IDEA: stickster to comment in bug: "The Workstation WG discussed this bug and was against holding the release up for this bug. However, kalev and others are looking at it so we can winnow down the cases where it does reproduce. Some users report this working fine under intel + Wayland, so it doesn't seem to be universal. It should be possible to fix in an update. (stickster, 13:59:27) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1632981 (stickster, 14:00:04) * IDEA: stickster to comment in bug: "The Workstation WG discussed this bug and was against holding the release up for this bug. However, upstream are looking at it so we can winnow down the cases where it does reproduce. Some users report this working fine under intel + Wayland, so it doesn't seem to be universal. It should be possible to fix in an update." (stickster, 14:04:08) * ACTION: kalev add note to bug 1632981 to summarize where we are with the gtk3 bug (stickster, 14:10:26) Meeting ended at 14:12:44 UTC. Action Items ------------ * stickster come up with a template for the Workstation WG issue tracker for default app adds -- in which one also has to confirm it's actively maintained * stickster be at blocker meeting and argue to remove 1637751 from blocker list * kalev get fix for 1633133 into package * kalev add note to bug 1632981 to summarize where we are with the gtk3 bug Action Items, by person ----------------------- * kalev * kalev get fix for 1633133 into package * kalev add note to bug 1632981 to summarize where we are with the gtk3 bug * stickster * stickster come up with a template for the Workstation WG issue tracker for default app adds -- in which one also has to confirm it's actively maintained * stickster be at blocker meeting and argue to remove 1637751 from blocker list * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * stickster (85) * juhp (54) * mcatanzaro (39) * kalev (38) * kparal (34) * otaylor (23) * zodbot (18) * mclasen (12) * cschalle (6) * frantisekz (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com

4 years, 11 months

3
2
0 / 0

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

by Zbigniew Jędrzejewski-Szmek

On Wed, Oct 24, 2018 at 08:45:32AM +0200, Igor Gnatenko wrote: > How can I enable cgroups2 on my laptop? Put systemd.unified-cgroup-hierarchy on the kernel command line. Zbyszek > On Fri, Oct 19, 2018, 17:27 Lennart Poettering <mzerqung(a)0pointer.de> wrote: > > > On Fr, 19.10.18 09:12, Florian Weimer (fweimer(a)redhat.com) wrote: > > > > > >> (cross-posting to devel and desktop lists, ideally reply to both) > > > > > > > > Coincidentally, at All Systems Go! in Berlin last week I had some > > > > discussions with kernel people about RLIMIT_NOFILE defaults. They > > > > basically suggested that the memory and performance cost of large > > > > numbers of fds on current kernels is cheap, and that we should bump > > > > the hard limit in systemd for all userspace processes. > > > > > > Which kernel version is that? Is that a new patch? Or some older > > > kernel? > > > > > > It's definitely not true for kernel 4.18, see the script I posted. > > > > I inquired Tejun Heo about this all, this is what he replied: > > > > <snip> > > In cgroup1, socket buffers are handled by a separate memory > > sub-controller. It's cumbersome to use, somewhat broken and doesn't > > allow for comprehensive memory control. cgroup2, however, by default > > accounts socket buffer as part of a given cgroup's memory consumption > > correctly interacting with socket window management. > > > > OOM killer too fails to take socket buffer into account and high > > number of sockets can lead it to make ineffective decisions; however, > > this failure mode isn't confined to high number of sockets at all - > > fewer number of fat pipes, tmpfs, mount points or any other kernel > > objects which can be pinned by processes can trigger this. > > > > cgroup2 can track or control most of these usages and at least for us > > switching to oomd for workload health management solves most of the > > problems that we've encountered. In the longer term, the kernel OOM > > killer can be improved to make better decisions too. > > </snip> > > > > ("us" in the above is facebook btw.) > > > > So, yeah, if we'd use cgroupv2 on Fedora, then everything would be > > great (unfortunately the container messiness blocks that for now). But > > as long as we don't, lifting the fd limit is not really making things > > worse, given that there are tons of other easily exploitable ways to > > acquire untracked memory... > > > > Lennart > > > > -- > > Lennart Poettering, Red Hat > > _______________________________________________ > > 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://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > _______________________________________________ > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

4 years, 11 months

1
0
0 / 0

TopIcons extension in F29

by Kamil Paral

Hello, some time ago when systray support was removed from gnome and the widely-recommended solution was the TopIcons extension, I got the impression that the extension will be somewhat semi-officially maintained. I might have understood it wrong. Either way, the current status is that TopIcons doesn't even load [1] and TopIcons Plus does load but doesn't seem to do anything (no icons shown). So I just want to highlight this. Is this on Workstation WG's radar? Is there going to be any GNOME dev participation in getting this fixed, or is this solely dependent on the community? (IOW: Is there any hope for those of us using systray?) Thanks for info. [1] Error: Expected type object for Argument 'theme_widget' but got type 'undefined'

4 years, 11 months

5
6
0 / 0

raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

by Kamil Paral

(cross-posting to devel and desktop lists, ideally reply to both) Hello, this is a request for feedback regarding adjusting process limits to make Steam/Wine work better on Fedora. *A quick background:* In August Valve announced [1] Proton [2], their own fork of Wine, to get included in their Steam Play functionality, and allowing Linux players to run Windows-only games transparently from Steam without any complex configuration, just with a press of a button. Not everything works of course, but the success rate is more than decent [3]. As far as I can tell, the reception by Linux gamers has been *very* enthusiastic. *The technical details:* In order to boost performance, Valve included DXVK [4] which converts DirectX calls to Vulkan (instead of OpenGL in vanilla Wine), and esync [5], an existing wine patchset that performs process synchronization in a more efficient manner than vanilla Wine, using file descriptors. You can read the linked readme for full explanation. The esync patchset is the main subject of this email. It uses a lot of file descriptors and the default kernel limits are not sufficient for many games. Valve notes that in their requirements document (under "FD LIMIT REQUIREMENTS") [6] and it is further described in the esync readme [5]. The documents also say that Debian and its derivatives like Ubuntu have already raised the limit on open file descriptors, so those distributions work out of the box with esync. Fedora is one of those that doesn't. I wonder if we can consider changing that. *Debian and Ubuntu:* I've installed both Debian (Sid) and Ubuntu (18.10) to verify this, and can confirm it. The default soft limit stays the same (1024), but the hard limit is increased from 4096 to 1048576 (2^20). However, this only applies to the systemd's system instance (systemd --system, PID 1), and not to systemd user instances (systemd --user). Most of the apps you start in your session are children of gnome-shell, which doesn't run under the systemd user instance, so the higher limits apply for them as well (including Steam). However some apps (probably started via dbus, I'm not really sure, but importantly this includes also gnome-terminal) are started as children of the systemd user instance and therefore have the original low limits applied. I don't know whether this is intentional or just an omission. I tried really hard to find the place where Debian/Ubuntu patches the upstream limits, so that I could read some justification/explanation of the change, but I wasn't able to find it (I searched the available patches for kernel, systemd and pam). *Configuring the limits:* You can display the soft+hard limits of your current terminal using ulimit: $ ulimit -Sn 1024 $ ulimit -Hn 4096 However, note that gnome-terminal runs under the systemd user session, so at least in Debian/Ubuntu this will not see higher limits (i.e. neither will Steam started from the terminal). You can also use prlimit to see the limits of any running process. You can use this to check limits of the systemd system instance, systemd user instance, running Steam, etc. $ sudo prlimit --nofile --pid 1 RESOURCE DESCRIPTION SOFT HARD UNITS NOFILE max number of open files 1048576 1048576 files You can modify the limits on the fly like this: $ sudo prlimit --nofile=1024:1048576 --pid PID You can increase the default limits by editing /etc/systemd/system.conf (and /etc/systemd/user.conf, if you want to edit systemd user session as well) and setting: DefaultLimitNOFILE=1024:1048576 Alternatively, you can drop a file like this: [Manager] DefaultLimitNOFILE=1024:1048576 into /etc/systemd/system.conf.d/ (and /etc/systemd/user.conf.d/). *Default limits in Fedora:* From a technical point of view I'm not able to judge whether raising the fileno limits by default is a trivial change or something with important security implications. That's why I'm writing this email to hopefully get replies from more knowledgeable people. The fact that Debian raised the limits gives me hope we could do the same in Fedora (perhaps just in Workstation, if the change in not welcome in the whole distribution). If somebody can find the justification of Debian devs, that would be great. I'd very much like to see Fedora (Workstation) being a good choice for Linux gamers (we already packaged gamemode), and this might be an important step to make sure Steam games don't work worse than on Ubuntu (but hopefully even better, due to our more recent drivers). Thanks for your feedback. [1] https://steamcommunity.com/games/221410/announcements/detail/169605585573... [2] https://github.com/ValveSoftware/Proton [3] https://spcr.netlify.com [4] https://github.com/doitsujin/dxvk [5] https://github.com/zfigura/wine/blob/esync/README.esync [6] https://github.com/ValveSoftware/Proton/blob/proton_3.7/PREREQS.md#fd-lim...

4 years, 11 months

5
8
0 / 0

[Fedocal] Reminder meeting : Workstation WG

by stickster＠gmail.com

Dear all, You are kindly invited to the meeting: Workstation WG on 2018-10-22 from 09:00:00 to 10:00:00 America/New_York At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Regular meeting for the Workstation Working Group. Agenda: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting Chair: * Monday Jun 18 - Michael Catanzaro * Monday Jul 02 - (deferred) * Monday Jul 16 - Matthias Clasen * Monday Jul 30 - Rex Dieter * Monday Aug 13 - (deferred, Flock) * Monday Aug 27 - Paul Frields * Monday Sep 10 - Kalev Lember * Monday Sep 24 - Ryan Lerch * Monday Oct 08 - Jens Petersen * Monday Oct 22 - Christian Schaller * Monday Nov 05 - Owen Taylor More information available at: https://fedoraproject.org/wiki/Workstation Source: https://apps.fedoraproject.org/calendar/meeting/6411/

4 years, 11 months

1
0
0 / 0

Unresolved bug (1637418) - Switching keyboard layouts is not working without relogin/reboot

by Lukas Ruzicka

Hello guys, I would like to point towards the bug mentioned in the $subj. The Fedora Blocker Bug review yesterday discussed the impact of this bug on the Fedora 29 Final release. Although we agreed upon not to make it a blocking bug, we still believe that the bug has a big impact on Fedora user experience. We would like to have it fixed until the final release if possible. Please, take a look and provide some estimation in https://bugzilla.redhat.com/show_bug.cgi?id=1637418. Thank you very much. -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzicka(a)redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

4 years, 11 months

6
10
0 / 0

[Test-Announce] 2018-10-22 @ 16:00 UTC - Fedora 29 Blocker Review Meeting

by Geoffrey Marr

# F29 Blocker Review meeting # Date: 2018-10-22 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hey everyone, We currently (as of 2018-10-18 at 22:00UTC) have 10 accepted blockers, 5 proposed freeze exceptions, and 11 accepted freeze exceptions. Let's take Monday to review the accepted and vote on whatever is left before we (hopefully) get a compose going on Monday or Tuesday. *It will be extremely helpful to get votes IN-BUG for this, as if we wait until the meeting to take care of all the blockers, we can almost bet on not having a compose in time for Go/No-Go next Thursday. Please vote in-bug before the meeting!* * 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/ <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 Geoff Marr IRC: coremodule

4 years, 11 months

1
0
0 / 0

Vagrant: can we make it show up in Software?

by Matthew Miller

In this article, https://www.zdnet.com/article/kali-linux-for-vagrant-hands-on/ the author notes: "I didn't find Vagrant on Fedora, but there are several articles in the Fedora Developer Portal which describe installing and using it." Actually, vagrant definitely *is* in Fedora; it's just not a GUI app so it doesn't show up in a search in Software. How can we either 1. Make vagrant available in software, or 2. Make it obvious to people searching in Software that this is an available command line tool? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

4 years, 11 months

4
6
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop October 2018