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 Workstation WG minutes, 2021-01-26
by Chris Murphy
==============================================
#fedora-meeting-2: Workstation WG (2021-01-26)
==============================================
Meeting started by cmurf at 08:18:43 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-28/workstation...
.
Meeting summary
---------------
* Rollcall (cmurf, 08:19:14)
* present: mcatanzaro, otaylor, Neil, cmurf, aday, kalev, tpopela
(cmurf, 08:19:16)
* regrets: langdon, mclasen (cmurf, 08:19:18)
* present guests: zbigniew (cmurf, 08:19:20)
* Approval of 19 Jan minutes: (cmurf, 08:19:22)
* LINK:
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-21/workstation...
(cmurf, 08:19:24)
* AGREED: no objections (cmurf, 08:19:26)
* Announcements, follow-ups, status reports (cmurf, 08:19:28)
* ACTION: Michael to follow-up with the proposal to create a
nm-connection-editor-core package (cmurf, 08:19:38)
* Updated activities overview design for GNOME 40 / F34 (cmurf,
08:19:40)
* LINK: https://pagure.io/fedora-workstation/issue/210 (cmurf,
08:19:42)
* The bulk of the changes are being rebased this week, ahead of merge
into master (cmurf, 08:19:48)
* 3 weeks until UI freeze upstream - that gives us 2 weeks to polish.
Help would be appreciated with this. (cmurf, 08:19:50)
* Review some older open issues (cmurf, 08:19:52)
* Replace Rhythmbox with GNOME Music in default install (cmurf,
08:19:54)
* LINK: https://pagure.io/fedora-workstation/issue/33 (cmurf,
08:19:56)
* ACTION: Allan to write call for help blog post (cmurf, 08:20:02)
* Redesign Anaconda installation progress page (cmurf, 08:20:04)
* LINK: https://pagure.io/fedora-workstation/issue/48 (cmurf,
08:20:06)
* Fix placement of Welcome to Fedora application in live boot (cmurf,
08:20:10)
* LINK: https://pagure.io/fedora-workstation/issue/79 (cmurf,
08:20:12)
* ACTION: Michael to investigate how gnome-tour centers its window
(cmurf, 08:20:18)
* ACTION: Allan to create a ticket for installer session proposal for
further discussion (cmurf, 08:20:20)
* 2m shutdown timer is too long (cmurf, 08:20:22)
* LINK: https://pagure.io/fedora-workstation/issue/163 (cmurf,
08:20:24)
* The user manager should propagate info to the system manager so it
can be shown in the shutdown menu. (cmurf, 08:20:34)
* AGREED: We need action on systemd on getting the ID of user
services. (cmurf, 08:20:52)
* AGREED: Action to debug PackageKit is needed. (cmurf, 08:20:54)
* ACTION: Zbigniew to reduce the timeout for F34. (cmurf, 08:20:56)
* Open Floor (cmurf, 08:20:58)
Meeting ended at 08:21:03 UTC.
Action Items
------------
* Michael to follow-up with the proposal to create a
nm-connection-editor-core package
* Allan to write call for help blog post
* Michael to investigate how gnome-tour centers its window
* Allan to create a ticket for installer session proposal for further
discussion
* Zbigniew to reduce the timeout for F34.
Action Items, by person
-----------------------
* **UNASSIGNED**
* Michael to follow-up with the proposal to create a
nm-connection-editor-core package
* Allan to write call for help blog post
* Michael to investigate how gnome-tour centers its window
* Allan to create a ticket for installer session proposal for further
discussion
* Zbigniew to reduce the timeout for F34.
People Present (lines said)
---------------------------
* cmurf (57)
* zodbot (7)
* mcatanzaro (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
2 years, 10 months
Thoughts on shell redesign
by Matthew Miller
Overall, like it and think this is a good direction. It didn't really take
me long to adjust to. I do think we need to communicate this a _lot_,
because change is hard and there exist a lot of negativity around GNOME
changes in general (even when such negativity is really ironic). Let's make
sure to get positive messaging out there.
Personally, I think we should take this a step further and make an always-on
dock a configurable preference. But one thing at a time. :)
Anyway, here's my feedback after running with this for a week:
* The latest mutter update in the copr broke my ability to log in my
existing account (getting the sad face "can't do anything"). Haven't had
time to really diagnose yet. That makes me a little worried that others
might experience something similar. For non-techie users this basically
says "your machine is dead and now you have to reinstall".
* Super-L does not lock the screen. Actually that shortcut just plain
doesn't work no matter what I set it to.
* I really find overview-zoom and unzoom animations to be too slow. Turning
them off is, however, too jarring. Hopefully Impatience will be available
as an extension again, but I think we should consider making the default a
little faster and perhaps proving options in Tweaks. (I know this isn't
new, just missing it from not having that extension.)
* That said, when using the scroll wheel, the switch workspace animation
feels too _fast_. It's easy to get lost if I have more than two
workspaces. I know, it's all subjective, but that's my impression.
* Speaking of extensions, obviously the redesign is going to impact a lot of
them. Is the popularity sort on https://extensions.gnome.org/ meaningful?
We should consider explicitly testing the top 20 or so and commenting on
compatibility.
* I don't have a strong opinion about horizontal vs. vertical workspace
alignment, even after using it for a week. Either is fine with me. However
I had previously used always-zoom-workspaces, and there's not really a
logical place for that in the new design. The net result of this is that I
forget what's on my other workspaces and open up more new windows and
workspaces in general throughout the day.
From reading other feedback, I think many people have a strong opinion
about this even though I don't. One factor might be multi-monitor; if I
have two monitors side by side, the side-scrolling workspaces are
confusing and vertical makes more sense. Also, on a 16:9 panel vertical
space is precious, and especially so on 13" or 14" notebooks -- making a
side dock more logical.
I know we don't like having a lot of options, but I wonder if having a 90°
rotation mode for this might be a worthwhile option, where the dash (and
"top" bar) are on the sides and workspaces go up and down.
* Okay, this is long-standing rather than new, but it seems like this
redesign is an opportunity to address. I find the word "Activies"
puzzling. It's always on screen in a very prominent place, and isn't very
descriptive. I know it comes from the idea of activity-centered design,
but that actually makes things worse because that's not what the UX really
ended up being. And, it's been a while, but in the past I've encountered
people who thought the whole desktop environment or even OS was called
"Activities".
The menu on the top right doesn't have any words; maybe this could also
bceome an icon? I get the rationale for not making it a brand icon, so I'm
not asking for that specifically, just... _an_ icon. (Sadly, the most
logical thing for it would actually be what's printed on the Overview key.
But that's not really a possibility!)
* Launching something from the dash using the mouse requires a LOT of mouse
travel: up to the top left corner, then down to the middle. Then, it seems
that new windows prefer to appear back up in the top left, so it's back up
to there again. Maybe:
1. the botton edge of the screen could also be "hot" and bring up the
overview, and
2. new windows could bias more towards appearing in the center of the
screen even if that makes more overlap.
* Actually point #2 might be important enough that it's worth calling out
directly. The top left of the screen is rarely where I want a
non-maximized window to appear.
* The borders around the window positions in the overview make for even less
real-estate in that view, which is unfortunate. I don't have a great
suggestion, except maybe thinner margins.
- Bonus thought though: although it's not apparent onscreen in normal use
like the Endless logo is, (which is something I'd still like), maybe we
could make those margins Fedora Blue instead of gray, to give a little
bit of distro-specific theming?
I love that GNOME's main UI uses neutral colors, but since this won't
distract the eye while you're actually working in an application, maybe
it's something we could do.
(Actually, what I'd love for my own personal configuration is a black
background screen and the stars and gas clouds from the F33 wallpaper in
the overview margins... or, for a default, I can see a design with a
pattern which complements the default wallpaper, rather than just a
plain color. Maybe too busy, though. Just thinking out loud!)
* If I click the "show applications" icon, and then start to search, the
transition from the app panel with workspaces at the top to the search is
kind of jarring. I think this would be better if the workspaces were
_below_ the application icons rather than above.
* A dash-to-dock feature I miss: I want the terminal icon to launch a new
window rather than focusing an existing one. I know that's not new in this
design but it'd be nice to not have to use this extension. I might be able
to train myself to middle-click, but I'd rather swap the behavior.
* The first time I dragged a window to a new workspace, I was confused as to
where it went. I think it's probably the right behavior, just a surprise.
Maybe an animation can help here?
* If I have a single window on the second workspace and drag it to the
third, that second workspace (naturally) becomes empty. If I then
immediately launch a new application or new window without leaving the
overview, that new app lands on that workspace and everything is fine.
If, however, I don't launch a new app and return from the overview, the
empty workspace is collapsed, which in pratice means that the window I
dragged to the right is now back on the workspace in front of me, and
there are still just two workspaces.
There's not even an animation making this smooth, but even if it were, it
really feels like strange behavior. Consider not collapsing single empty
workspaces between occupied ones.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2 years, 10 months
Anyone know offhand why rdma-core is on the Workstation live image?
by Matthew Miller
This only happened to come up because of a multilib glitch, but I'm
wondering why rdma-core is on the default Workstation image. It seems
unlikely that any of our users have Infiniband on their desktops.
----- Forwarded message from Jonathan Billings <billings(a)negate.org> -----
> Date: Tue, 26 Jan 2021 14:58:14 -0500
> From: Jonathan Billings <billings(a)negate.org>
> To: users(a)lists.fedoraproject.org
> Subject: Re: rdma-core-32.0-1.fc33.i686 has inferior architecture
> Archived-At: <https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.o...>
>
> On Tue, Jan 26, 2021 at 10:33:20AM -0500, Matthew Miller wrote:
> >
> > On Mon, Jan 25, 2021 at 06:40:10PM -0800, ToddAndMargo via users wrote:
> > > Hi Matthew,
> > >
> > > I just did a
> > > # dnf remove rdma-core-32.0-1.fc33.x86_64
> > > and now `dnf upgrade` is happy.
> >
> >
> > FWIW the root cause is here: https://bugzilla.redhat.com/show_bug.cgi?id=1919864
> > ... the package was accidentally built x86_64 only, which is why DNF
> > couldn't find the matching i686 package. But this is only needed for
> > special-purpose cluster networking hardware, and I'm pretty sure 0% of
> > desktop users even need this package. I'm not sure what has pulled it in for
> > so many people.
>
> Looking at the /var/log/anaconda files, it appears that rdma-core was
> included in the LiveCD image I used to load the fedora workstation
> that has it installed. I used the default Fedora Workstation
> (Fedora-Workstation-Live-x86_64-33-1.2.iso). If I mount the rootfs
> inside the squashfs on the ISO, I can run:
>
> # mkdir /mnt/livecd /mnt/squashfs /mnt/rootfs
> # mount /slow/images/Fedora-Workstation-Live-x86_64-33-1.2.iso /mnt/livecd
> # mount /mnt/livecd/LiveOS/squashfs.img /mnt/squashfs
> # mount /mnt/squashfs/LiveOS/rootfs.img /mnt/rootfs
> # chroot /mnt/rootfs/ rpm -q rdma-core
> rdma-core-31.0-1.fc33.x86_64
>
> Might want to remove that from the build if it shouldn't be
> installed.
>
> --
> Jonathan Billings <billings(a)negate.org>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
----- End forwarded message -----
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Fedora Project Leader mattdm(a)fedoraproject.org <http://fedoraproject.org/>
2 years, 10 months
Self-Introduction
by Suhaas Joshi
Hello everyone! I am Suhaas, a first-year undergrad from India, eyeing this
year's GSOC. I am good at C++ and data structures and find C manageable. I
can contribute up to 7 hours per week until the end of February, after
which I can spend 17-18 hours working here per week. I was told to email
the subprojects I am interested in. I like the workstation since it seems
incredibly elegant and would love to be a part of it.
I don't have any experience contributing to open source or creating an
elaborate project before, and my programming journey started just a few
months ago. Therefore before the application period commences, I would love
to be able to finish contributing or helping around a bit to increase my
familiarity with the codebase. It would be much appreciated if a potential
mentor or anyone else could guide me through the initial stage or give me
pointers of where to begin! :)
Thanks
Suhaas
2 years, 10 months
Fedora Workstation WG minutes, 2021-01-19
by Chris Murphy
==============================================
#fedora-meeting-2: Workstation WG (2021-01-19)
==============================================
Meeting started by cmurf at 03:16:13 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-21/workstation...
.
Meeting summary
---------------
* Roll Call (cmurf, 03:17:10)
* present: cmurf, aday, mclasen, mcatanzaro, otaylor, tpopela,
petersen, kalev, ngompa (cmurf, 03:17:12)
* regrets: langdon (cmurf, 03:17:14)
* present guests: miroslav suchy, salimma, msrb (Michal Srb) (cmurf,
03:17:16)
* Approval of 12 Jan minutes (cmurf, 03:17:18)
* LINK:
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-14/workstation...
(cmurf, 03:17:20)
* AGREED: Approved - no objections (cmurf, 03:17:22)
* Announcements, follow-ups, status reports (cmurf, 03:17:24)
* none (cmurf, 03:17:26)
* Updated activities overview design for GNOME 40 / F34 (cmurf,
03:17:28)
* LINK: https://pagure.io/fedora-workstation/issue/210 (cmurf,
03:17:30)
* LINK: https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/80
(cmurf, 03:17:40)
* ACTION: mclasen to write a change proposal (cmurf, 03:17:52)
* Give ABRT some (cmurf, 03:17:54)
* LINK: https://pagure.io/fedora-workstation/issue/130 (cmurf,
03:17:56)
* LINK: https://pagure.io/fedora-workstation/issue/130#comment-705518
(cmurf, 03:18:02)
* LINK: https://github.com/abrt/abrt/issues/1399 (cmurf, 03:18:20)
* LINK: https://github.com/abrt/abrt/issues/1402 (cmurf, 03:18:24)
* Open Floor (cmurf, 03:18:30)
* meeting adjourned (cmurf, 03:18:32)
Meeting ended at 03:18:40 UTC.
Action Items
------------
* mclasen to write a change proposal
Action Items, by person
-----------------------
* **UNASSIGNED**
* mclasen to write a change proposal
People Present (lines said)
---------------------------
* cmurf (46)
* zodbot (7)
* mcatanzaro (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
2 years, 10 months
