F32, Automatic suspend isn't working.
by Chris Murphy
cross-posting test@ and desktop@
Fedora Workstation 32 (upgraded from f31)
Laptop on battery power set aside, 12 hours later it's dead instead of
sleeping. On F31 it reliably would sleep after 20 minutes.
Sleep still happens when pressing the power button and closing the
lid. It seems to be a GNOME automatic suspend timer problem.
Using dconf editor, I changed the
/org/gnome/settings-daemon/plugins/power/sleep-inactive-battery-timeout
Custom value 30 and the problem doesn't happen. Is there a way to
increase debug messages somehow to find out whether this timeout is
being reached? And what process or policy is causing it to be reset?
With the available information I can't figure out what's preventing
sleep.
--
Chris Murphy
5 months
Fedora Workstation WG minutes, April 28
by Michael Catanzaro
Fedora Workstation WG meeting
Minutes should be digestible by Meetbot (
https://fedoraproject.org/wiki/Meeting:Guide#MeetBot_Commands )
Minutes
#startmeeting Workstation WG (2020-04-28)
#meetingname workstation
#chair cmurf
#topic Rollcall
#info present: cmurf, tpopela, aday, mclasen, otaylor, mcatanzaro,
jens, kalev, james, feborges, link
#info regrets: neal
#info missing: langdon
#topic Approve minutes of 14 & 21 April
#link
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-04-21/workstation...
#link
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-04-24/workstation...
#agreed Approved - no objections
#topic Announcements
F32 release day
Fedora on Lenovo laptops; potential implications for the working group:
#link https://fedoramagazine.org/coming-soon-fedora-on-lenovo-laptops/
- First boot (initial setup as the first thing the user sees, rather
than Anaconda) - need to ensure that either language selection is
displayed in initial setup or ensure that the correct keyboard layout
is predefined for the locale. Some digging required here. It might be
good to track that.
- ACTION: Michael to investigate.
- Disk encryption - how to enable/reprovision?
#topic Status reports
Chris is 60% through swap on zram proposal; is currently summarising
the hibernation issue
#topic F32 retrospective, and appoint chair for F33 cycle
#link https://pagure.io/fedora-workstation/issue/141
#info Review F32 cycle, WG organizational and meeting format changes.
Chair and co-chair nominations.
#topic Meeting format
Chris would appreciate feedback on the meeting format.
Michael: thinks that things are going well. Thinks that video has been
a success. 6 month chair seems good; thinks that Chris has been doing a
good job.
Allan: posted his feedback in the ticket (as did Chris and Tomas).
Kalev: not happy at all. Would prefer IRC meetings.
Chris: could we have an IRC meeting every month? Kalev: or a video
meeting every month, and IRC at other times?
Matthias: we have IRC all the time.
Non-weekly meetings are difficult, calendar-wise.
#agreed Continue the discussion on the ticket.
#topic Chair/co-chair duration
Kalev: 6 months is too long; would prefer 2/3 months, and the chair can
choose the meeting format
Chris: perhaps that suggestion could be combined with Allan's idea of
the chair delegating more duties
#topic Nominations
Chris would be happy to do it, and perhaps delegate more
Allan is happy to carry on as co-chair, would quite like not to do the
minutes any more
Allan: we have some long-running initiatives which Chris has been
leading, which it would be good to resolve for F33. Chris: isn't sure
he needs to be chair for that.
Michael is happy for Chris to carry on as chair. So is Allan.
Chris invites others to put themselves forward as nominees.
Kalev is interested, but only if we use IRC. Would change the direction
- would focus on getting Flathub preinstalled instead of disk
encryption. Also which apps are preinstalled.
Some discussion about enabling Flathub by default - see ticket #108
#topic Encryption of system and user data
#link https://pagure.io/fedora-workstation/issue/136
#link https://pagure.io/fedora-workstation/issue/82
Discuss short term encryption plan (full disk encryption as it exists
today in the installer, which encrypts both system and user data).
Last week Lennart and Ray joined us to talk about homed. Ray might
report back next week on systemd-homed. It's currently unclear whether
systemd-homed is a short-term prospect or a long-term prospect.
Question about setting up recovery keys -
https://pagure.io/fedora-workstation/issue/136#comment-643926
Michael & Matthias: how is a recovery password useful, if you can just
forget that one as well?
Owen: the fact that it's a recovery password indicates to people that
they need a good record of it.
Allan: would like to evaluate the full range of issues/requirements in
relation to full disk encryption, not just this issue alone. How does
this approach to password recovery compare to other approaches?
Michael: we should invite people from fedora-devel to participate in
the discussion.
#action: michael to do this.
Jens: what about root password? (as recovery key?)
#topic Blocking on user switching
#link https://pagure.io/fedora-workstation/issue/139
What are the parameters by which loss of function should or should not
be release blocking?
Is it right to block a release on this?
Kalev: yes. We have the engineers to fix it.
Matthias: depends on how relevant user switching is to us.
Allan: there are some multiuser cases where it would be nice if Fedora
was appropriate - small labs/offices. Kalev: shared computers at home
are relevant too.
Allan: other question is how bad the fail state is - does it just not
work, or does it bring down the session/system, etc?
#agreed User switching should be a release blocker; we're happy for QA
to decide on the exact wording.
#action Chris to communicate the decision to QA
#topic Workstation Live image is oversize
#link https://pagure.io/fedora-workstation/issue/140
Chris: what's the process we want to determine the image size?
Kalev: if we want to stick to 2GB, we will need to cut some packages.
We're very close to the limit - not much room for manoeuvre.
Owen: if we change the limit to 4GB, we wouldn't have any other process
to keep the size down. This could imply that we should only increase
the limit a small amount. The alternative would be to schedule a size
review each development cycle. Matthias: it could be a package review
rather than size review - to see what changes have been made.
Kalev: it would be good to do this around the same time as the test day.
Owen: that might not give us a lot of time to resolve engineering
issues. Kalev: yes, we should have the test day before the beta, to
give us enough time before the beta release.
Chris: would like to review which services are started, too.
#action Chris will ask release engineering and QA for their input, and
we'll work out the details next week
#topic Guidelines for preinstalled and non-removable apps
#link https://pagure.io/fedora-workstation/issue/125
#info Deferred
#endmeeting
2 years, 11 months
Blocking on user switching: redux
by Adam Williamson
Hi folks!
So, during Fedora 32 Final blocker review, a bug relating to "user
switching" came up for review:
https://bugzilla.redhat.com/show_bug.cgi?id=1817708
I dug into the question of whether we have tended to consider the "log
in / log out / shut down / reboot" criterion as covering user
switching, and found that this issue is actually kinda outstanding and
unresolved for a long time.
Back in January 2015, we kinda provisionally decided that we *did* want
to block on user switching bugs, by accepting this one as a blocker
during a review meeting:
https://bugzilla.redhat.com/show_bug.cgi?id=1184933
kparal was detailed to propose clearly adding it to the criteria, and
he duly drafted up a change and mailed it to the relevant lists -
test@, kde@ and desktop@:
https://lists.fedoraproject.org/pipermail/test/2015-January/124811.html
https://lists.fedoraproject.org/pipermail/kde/2015-January/014175.html
https://lists.fedoraproject.org/pipermail/desktop/2015-January/011558.html
However, here things foundered a bit because there was some opposition
to the idea. The discussion is spread across the three lists, but my
reading is broadly that there were distinct camps in favour of and
against blocking on user switching bugs. Prominent "pro-blocking" folks
were Michael Catanzaro and Kevin Kofler. Prominent "anti-blocking"
folks were Matthias Clasen, Rex Dieter and Josh Boyer. Obviously that's
a particularly awkward split because we have pro- and anti- folks on
both the desktop and KDE teams.
The discussion was pretty active, but in the end it sort of petered out
without any definite conclusion being reached. The draft changes Kamil
proposed were never made, and the criterion remained as it was before.
For the purposes of our specific F32 blocker proposal we decided to
adopt the principle that, since there was a discussion that clearly did
not reach a consensus that user switching *should* be release-blocking,
we could not really treat it as such, and thus we rejected the bug as a
blocker. But I figured it would probably be a good idea to bring the
topic up again and try to come to a definite conclusion this time.
So, once again: do we think it makes sense to consider desktop user
switching - that is, switching between multiple active desktop sessions
for different users, without logging out and in - as release-blocking?
Has anyone who was active in the previous discussion changed their mind
on this?
I suppose one question that could potentially arise is whether we could
treat it as release-blocking for GNOME but not for KDE, or vice versa.
In general I think it's a good goal to try and keep our standards
similar across our release-blocking desktops, but I do think we could
at least consider that, if the discussion seemed to be going in that
direction.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2 years, 11 months
