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
1 year, 1 month
Release criteria proposal: networking requirements
by Adam Williamson
Hi folks!
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
networking criteria.
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1 year, 9 months
Fedora website - revamp
by Pawel Zelawski
Dear team,
we decided it's time to rethink our needs and redesign Fedora main website from scratch.
I would like to encourage your team to take a part in this initiative and work on this together as we need to make sure that we have everybody on board and all needs are taken into consideration.
Based on initial input I gather from Fedora forum and meeting with Matthew I prepared one page with summary of what we are going to do and it's available here https://fedoraproject.org/wiki/Websites/Fedora_Website_Revamp
It's possible I'll move it to other place in the future but for now it will be our workspace.
As a short term strategy I would like you to choose one representative from your team for upcoming kick-off meeting with other stakeholders and send me directly details like name, Feroda ID and e-mail address. It will be much easier for me to contact chosen person having this. Please try to do this by 30th June. I'm aware holiday period started and probably not everyone will be available but let's try to do our best and push forward this exciting initiative :)
When I have all participants gathered I'll try to find common slot to organize session for us. Agenda will be included in invitation.
Main goal of this kick-off will be to discuss known facts, go through goals, assumptions and requirements and also plan next steps for next couple of weeks.
I'll propose long term strategy, approach and wider plan after meeting with all of you.
Please read in advance https://fedoraproject.org/wiki/Websites/Fedora_Website_Revamp and if you already have some requests, suggestion please send it to your representative and then each person can send it to me before kick-off. Taking into consideration we will have huge amount of stakeholders I don't see other way to work on this than having one person from each team, I hope you understand.
Looking forward to work with all of you.
Stay safe!
--
Pawel Zelawski
2 years, 5 months
Fedora Workstation WG minutes, 2021-06-29
by Matthias Clasen
#startmeeting Workstation WG (2021-06-29)
#meetingname workstation
#chair Neal
#topic Rollcall
#info present: Matthias (secr.), Neal, Chris, Tomas, Jens, Michael
#info regrets: Allan
#info present guests: Luna Jernberg(bittin), Omar Sandoval, Michel
#topic Approval of June 23 minutes
https://meetbot.fedoraproject.org/teams/workstation/workstation.2021-06-2...
#agreed no objections
#topic Fesco deadline is today, Owen wants agreement from wg for
proposals for installing
repos by default, and flathub with a filter
Michael says that these proposals have been discussed and agreed to by
the WG in the past,
so this should be uncontroversial.
Owen will wait a few hours for feedback on the proposals.
#agreed interested parties should comment on the proposals after the meeting
#topic Discussion with Omar Sandoval
Chris introduces Omar and the topic of encryption of user/systemdata with btrfs.
This is follow-up to discussion from 2 weeks ago.
Hot question: When is the code expected to land in the upstream kernel?
Omar expects this to land in complete form, not piecemeal. Timeline
expectation: end-of-the-year
btrfs-specific parts will be different from how fscrypt does things,
so that will need a bit of
extra attention.
Chris is asking about enabling encryption at runtime. Omar says that
he thinks about using
the defrag code paths for this. Use case at facebook: container images
with well-known,
unencrypted base images and encrypted modifications.
Chris is asking about providing user keys after the fact. Omar says
that this sounds like
a userspace problem.
Neal asks about having multiple keys for decrypting. Omar says that
the kernel only supports
one encryption key, which would have to be protected in a key
management system if
multiple keys are desired.
Omar says that upstreaming of all this work is still pending. He will
reach out when things
are in a state where testing would be useful.
Neal was asking questions around backup and encryption.
Followup questions can be sent to Omar Sandoval <osandov(a)osandov.com>
#topic Open Floor
Matthias mentions negotiations with Lennart about having him come back for homed
discussion. Current
Next weeks meeting is cancelled due to July 4, next meeting: July 13.
#endmeeting
2 years, 5 months
Re: GNOME on Wayland does not work on latest Rawhide
by Florian Weimer
* Mohan Boddu:
> On Mon, Jun 28, 2021 at 3:20 PM Florian Weimer <fweimer(a)redhat.com> wrote:
>>
>> * Mohan Boddu:
>>
>> > Not sure if its related, but bolt is also having an issue:
>>
>> What's your glibc version? glibc-2.33.9000-25.fc35 is the first build
>> with the (then downstream-only) fix.
>
> I should have mentioned this earlier, but I updated to
> glibc-2.33.9000-25.fc35
Then this must be a different bug. glibc or not glibc, I don't know. A
backtrace with debuginfo might help. Maybe the received udev message
has an unexpected format.
Thanks,
Florian
2 years, 5 months
Re: GNOME on Wayland does not work on latest Rawhide
by Florian Weimer
* Mohan Boddu:
> Not sure if its related, but bolt is also having an issue:
What's your glibc version? glibc-2.33.9000-25.fc35 is the first build
with the (then downstream-only) fix.
boltd issues have been reported as well, but I'm not sure if we have
verified that they went away with the fix for the larger issue.
Thanks,
Florian
2 years, 5 months
Re: GNOME on Wayland does not work on latest Rawhide
by Florian Weimer
We could use some basic GNOME SHell debugging help here. Ideally, we'd
like to run GNOME Shell in such a way that it does not perform X
fallback and does not re-exec itself, and uses a specified VT (so that
we can launch it over an SSH session).
(This is about bug 1974970.)
Thanks,
Florian
2 years, 5 months
