desktop February 2020

desktop@lists.stg.fedoraproject.org

12 participants
20 discussions

Re: URGENT: users prompted to upgrade to F32
by Adam Williamson 17 Feb '20

17 Feb '20

On Sun, 2020-02-16 at 22:17 +0100, drago01 wrote: > On Saturday, February 15, 2020, Kevin Fenzi <kevin(a)scrye.com> wrote: > > > On Fri, Feb 14, 2020 at 05:14:57PM -0800, Adam Williamson wrote: > > > On Fri, 2020-02-14 at 18:37 -0600, Michael Catanzaro wrote: > > > > Hi, > > > > > > > > Users are being prompted to upgrade to F32. Anyone who knows how to > > fix > > > > this, please help with > > > > https://pagure.io/fedora-infrastructure/issue/8652 ASAP. > > > > > > We fixed it several hours ago, but people are likely hitting copies of > > > the bad data cached somewhere along the line :/ > > > > > > https://pagure.io/fedora-infrastructure/issue/8652#comment-626587 > > > > Yeah, it was live for about 45min this morning, but we fixed it as soon > > as it was noted. ;( > > > > Not sure that there is too much more we can do at this point... > > > > > What can we do to ensure it does not happen again? Well, ideally, finally come up with an actually sane system / set of processes for handling release events and storing/providing information about them. Unfortunately, as Kevin puts it, we could do a great job of that if someone would give us four people who could work on it for six months. As long as that doesn't happen, releng will keep putting duct tape on duct tape, and when resource constraints force people to do that, this kind of accident will happen. In practice, though, there might be something concrete we can do in the short term. The problem here is that GNOME Software (and fedfind, as it happens) are using this thing as a Source of Truth about Fedora releases: https://admin.fedoraproject.org/pkgdb/api/collections/ when pkgdb existed, that was one of its API endpoints. It could be relied upon to be a reliable source of information about Fedora releases that existed and their status (stable, development, EOL) because it *had* to be updated accurately at each 'lifecycle event' (Branching, EOL, stable release) or else various other things wouldn't work right. But pkgdb was retired in 2017. Since then this URL has not been a reliable API endpoint, but a weird orphan: it's literally a JSON format text file which a web server is configured to serve out at that URL. At each 'lifecycle event', someone has to update the text file by hand, and do it right. What happened in this case is someone made a mistake while doing that - I'm not going to say who, because of course it could happen to anyone as long as this fundamentally silly process is in place. We keep this silly process in place because there hasn't really been a viable alternative to it. PDC was *supposed* to be the replacement for pkgdb so far as 'Official Source of Truth for release information' went, but for a variety of reasons - significantly https://github.com/product-definition-center/product-definition-center/issu… - it never really has been. Now RH has lost interest in PDC, Fedora is in an awkward spot where we're sort of still using it, but don't have the resources to really complete all the plans for its adoption. However! It seems that there *may* be an alternative candidate for the role. Bodhi has a 'releases' API endpoint, here: https://bodhi.fedoraproject.org/releases/ (it renders as HTML in a browser, but you get JSON when accessing it in API-y ways). I think it actually provides the information that at least GNOME Software and fedfind need - 'these are the releases that exist, and their lifecycle status is X'. One key question is exactly when Fedora 32 becomes 'current' for Bodhi's purposes - it needs to be at the time we actually decide Fedora 32 is stable, not at the Bodhi activation point or the point when we cut the final fedora-release package or anything like that. Another possible issue is distinguishing Branched from Rawhide. But if the 'stable release' event happens at the right time, and we can distinguish Branched and Rawhide somehow, I think we may have a good candidate. Since this is an API endpoint of a real system which needs to be updated correctly when the release events actually happen, it should have the benefits pkgdb used to be (the information should be reliable and timely), and it shouldn't be as vulnerable to PEBKAC events as...a hand-edited JSON text file. So if we update GNOME Software and fedfind, and anything else using collections as a source of truth, to use this Bodhi API instead, potentially that could help. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 1

[Fedocal] Reminder meeting : Workstation WG
by catanzaro＠fedoraproject.org 17 Feb '20

17 Feb '20

Dear all, You are kindly invited to the meeting: Workstation WG on 2020-02-18 from 09:30:00 to 10:30:00 US/Eastern At https://bluejeans.com/395383051/ The meeting will be about: Regular meeting for the Workstation Working Group Current Topics: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting More information available at: https://fedoraproject.org/wiki/Workstation Source: https://apps.fedoraproject.org/calendar/meeting/9652/

1 0

18 Feb, MEETING AGENDA
by Chris Murphy 14 Feb '20

14 Feb '20

9:30 am ET 14:30 UTC Location: https://bluejeans.com/395383051/ https://www.bluejeans.com/numbers Announcements: * FESCo approved governance * Draft letter to Council, "Ship fedora-workstation-repositories on install media" https://pagure.io/fedora-workstation/issue/105#comment-626259 Issues: ** "Support for hibernation?" ** https://pagure.io/fedora-workstation/issue/121 Starting point: everyone takes a turn to state their perspective (facts, position, concern, questions), capping the time to 1 minute. It's OK if you want to take a pass, or defer your time to another person, or read from notes. I'm curious what 2 or 3 things each person decides is most relevant. ** Reconsider updates policy ** https://pagure.io/fedora-workstation/issue/107 Discussion to unstick this, and hopefully get to a proposal: Does GNOME Software need a method to be told what is an urgent security fix? Should there be a distro wide definition of urgent security fix? Who should assess it? Urgent: critical impact and it should be fixed with an update within 24-48 hours? Everything else, once per week? Related, but still doesn't put the finger on this issue: Red Hat security classifications list. Critical doesn't tell us when to apply the update. https://access.redhat.com/security/updates/classification Final release criterion refers to the above, "important" or higher security flaws need to be fixed for release, if they can't be fixed with an update. https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Security_bu… RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers (~31 email thread) https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… -- Chris Murphy

1 0

Workstation WG meeting minutes, 11 Feb
by Allan Day 12 Feb '20

12 Feb '20

The Fedora Workstation Working Group had a meeting yesterday, 11 February 2020. See meetbot for the summary or full minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2020-02-12/workstation.2… Thanks, Allan

1 0

Support for hibernation 1/2: background and summary
by Chris Murphy 10 Feb '20

10 Feb '20

Hi, Fedora Workstation WG is tracking the following issue: Support for hibernation? https://pagure.io/fedora-workstation/issue/121 ACPI power states decoder ring [1] S0 normal powered on state, S0 low power idle, freeze, s2idle, connected/modern standby, power nap S1 standby, power-on suspend, shallow S2 not used on linux S3 suspend, suspend to RAM, S2RAM, sleep, deep S4 soft off, used for hibernate/suspend to disk and implies firmware coordination S5 power off, used for hibernate/suspend to disk Summary of the issues: - Hibernation image and swap (paging) share the swap device. There's no kernel support to separate them. With a shared swap partition, there's no guarantee there will be enough contiguous free space (this is a requirement) to write out the hibernation image. - A swap device sized at 1:1 with RAM, and any appreciable use of swap, will thwart the creation of a hibernation image. This is discovered at hibernation image creation time. - A swap device sized at 2:1 with RAM might be quite a lot more reliable, but it's still not a guarantee. And already the swap partition is considered too big.[2] And we're considering dropping it by default in Fedora 33 in favor of swap-on-ZRAM. [3] - Hibernation is getting very little attention by hardware vendors and Microsoft. - For 5+ years the emphasis has been on S0 low power idle (a.k.a. freeze, standby, s2idle, S2I, modern standby, and power nap), and faster boots. Hibernation is intended as a last resort fallback when the battery charge becomes low. - Microsoft's hardware certification mandates UEFI Secure Boot by default since Windows 8 (2012). It's reasonable to estimate this is the vast majority of present and future hardware. - Linux kernel enforces hibernation lockdown (among other things), on UEFI systems with Secure Boot enabled. - S3 (a.k.a. suspend, suspend-to-RAM, S2RAM, STR, sleep, deep) is widely available hardware and linux support wise; but the gotcha has always been wake from suspend and device reactivation, including graphics. There are lots of firmware, ACPI, and kernel bugs, and regressions, and it's make/model/version specific. - Lately, since ~2018 [4], linux is catching up, with more effort being put into S0 low power idle (called s2idle on linux and either connected standby or modern standby on Windows, and power nap on macOS). It's all done in software, and ostensibly has no firmware or ACPI dependencies, so it can be done on any platform.[4] - uswsusp: I can't find any recent upstream information on it. [6] It's not packaged in Fedora. I see no evidence of image signing capability. If it could work around kernel Secure Boot lockdown, I think most any reasonable person would consider that a security vulnerability. - Fedora kernel team has said resource constraints means hibernation is not a priority, i.e. it's best effort, and can't practically be release blocking. There's prior, Fedora specific, kernel, systemd, and GNOME discussion in these threads. [7] I'll start a separate thread for questions and discussion. [1] https://www.kernel.org/doc/Documentation/power/states.txt https://www.kernel.org/doc/html/v4.19/admin-guide/pm/sleep-states.html [2] https://pagure.io/fedora-workstation/issue/120 [3] https://pagure.io/fedora-workstation/issue/127 [4] https://lwn.net/Articles/762132/ [5] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences… [6] http://suspend.sourceforge.net/ https://wiki.archlinux.org/index.php/Uswsusp [7] https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.or… https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.or… https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.or… -- Chris Murphy

3 3

[Fedocal] Reminder meeting : Workstation WG
by catanzaro＠fedoraproject.org 10 Feb '20

10 Feb '20

Dear all, You are kindly invited to the meeting: Workstation WG on 2020-02-11 from 09:30:00 to 10:30:00 US/Eastern At https://bluejeans.com/395383051/ The meeting will be about: Regular meeting for the Workstation Working Group Current Topics: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting More information available at: https://fedoraproject.org/wiki/Workstation Source: https://apps.fedoraproject.org/calendar/meeting/9652/

1 0

Workstation WG minutes for 28 Jan and 4 Feb
by Allan Day 07 Feb '20

07 Feb '20

The minutes for the last two workstation working group meetings can be seen here: - 28 Jan: https://meetbot.fedoraproject.org/teams/workstation/workstation.2020-02-07-… - 4 Feb: https://meetbot.fedoraproject.org/teams/workstation/workstation.2020-02-07-… Unfortunately, due to a technical glitch, much of the content from the 28 Jan meeting was lost. Allan

3 4

11 Feb, MEETING AGENDA
by Chris Murphy 07 Feb '20

07 Feb '20

9:30 am ET 14:30 UTC Location https://bluejeans.com/395383051/ 1. Poor support for multiple VPNs (should we enable systemd-resolved?) https://pagure.io/fedora-workstation/issue/123 2. Automatically install the OpenH264 codecs https://pagure.io/fedora-workstation/issue/84 We did previously reach agreement to change fedora-cisco-openh264.repo to enabled=1, but not on automatically installing what's needed. 3. Ship fedora-workstation-repositories on install media https://pagure.io/fedora-workstation/issue/105 4. Support for hibernation? https://pagure.io/fedora-workstation/issue/121 https://teams.fedoraproject.org/project/workstation-wg-1/task/15 -- Chris Murphy

1 0

4 Feb, MEETING AGENDA
by Chris Murphy 04 Feb '20

04 Feb '20

9:30 am ET 14:30 UTC Location https://bluejeans.com/395383051/ 1. Guest, domain expert on resource control, Dan Schatzberg from Facebook Background video. https://www.youtube.com/watch?v=30i7SamZxRU 2. Ship fedora-workstation-repositories on install media https://pagure.io/fedora-workstation/issue/105 3. Support for hibernation? https://pagure.io/fedora-workstation/issue/121 https://teams.fedoraproject.org/project/workstation-wg-1/task/15 -- Chris Murphy

3 2

[Fedocal] Reminder meeting : Workstation WG
by catanzaro＠fedoraproject.org 03 Feb '20

03 Feb '20

Dear all, You are kindly invited to the meeting: Workstation WG on 2020-02-04 from 09:30:00 to 10:30:00 US/Eastern At https://bluejeans.com/395383051/ The meeting will be about: Regular meeting for the Workstation Working Group Current Topics: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting More information available at: https://fedoraproject.org/wiki/Workstation Source: https://apps.fedoraproject.org/calendar/meeting/9652/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop February 2020