desktop January 2015

desktop@lists.fedoraproject.org

46 participants
27 discussions

ABRT changes for Fedora Workstation (22 and further)
by Bastien Nocera 17 Feb '15

17 Feb '15

Hey, Before the end of year holidays, Allan and I went to Brno to meet up with the ABRT team, in order to see what could be done to integrate ABRT and gnome-abrt better into Fedora Workstation, and into GNOME. We now have a number of TODO items, which can be worked on incrementally, which I will list below. - ABRT: - https://github.com/abrt/abrt/milestones/Fedora%2022 - https://github.com/abrt/abrt/issues/891 - https://github.com/abrt/abrt/issues/887 - gnome-abrt: - https://github.com/abrt/gnome-abrt/issues - GNOME: - https://bugzilla.gnome.org/show_bug.cgi?id=742375 - Retrace server: - Make it possible to filter by Fedora product (Workstation, Server, Cloud) - Longer-term: - Using gnome-abrt for better SELinux notifications - "Merge" local and remote retracing into one: - https://github.com/abrt/abrt/issues/832 - Look into privacy policies (what happens when Fedora contributors start leaking information about a user's choice of documents in a bug report?) Allan will be working on finalising the gnome-abrt mockups so that Jakub Filak can work on the gnome-abrt issues. He will also be documenting common workflows between server and desktop to share with the ABRT and Cockpit teams. I'll be working on the GNOME Settings part of the equation in a couple of days, and will likely shift to ABRT or gnome-abrt issues further down the line. Cheers

4 10

Meeting on 2015-Feb-04?
by Paul W. Frields 05 Feb '15

05 Feb '15

A bunch of us will be in Brno on Wednesday 2015-Feb-04 for some Red Hat company meetings. Do we still want to hold the Workstation WG meeting per usual at 1600 UTC (11:00 EST, 17:00 Brno time) that day? -- 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

2 3

criterion update: add "switch user" to Shutdown, reboot, logout
by Kamil Paral 31 Jan '15

31 Jan '15

Hello, we're discussing a release criterion which is tightly related to GNOME and KDE environments. Could your teams please provide some feedback on the proposed criterion update, see below? Is user switching something you believe should be working (and in which milestone?), or should we rather de-emphasize/remove that function? Please respond to the test@ list, if possible, to avoid fragmenting the discussion. Thanks! ----- Original Message ----- > Hello, > > yesterday we have discussed whether user switching should be included in our > criteria. We agreed that Beta is a good target for it, and accepted this bug > as a blocker: > > https://bugzilla.redhat.com/show_bug.cgi?id=1184933 > https://bugzilla.gnome.org/show_bug.cgi?id=719418 > > Now we need to adjust this criterion: > https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Shutdown.2C_… > Shutting down, logging out and rebooting must work using standard console > commands and the mechanisms offered (if any) by all release-blocking > desktops. > Work? [hide] > Similar to the Alpha criterion for shutting down, shutdown and reboot > mechanisms must take storage volumes down cleanly and correctly request a > shutdown or reboot from the system firmware. Logging out must return the > user to the environment from which they logged in, working as expected. > > I propose this change: > title: Shutdown, reboot, logout, switch > Shutting down, rebooting, logging out and user switching must work using > standard console commands and the mechanisms offered (if any) by all > release-blocking desktops. > Work? [hide] > Similar to the Alpha criterion for shutting down, shutdown and reboot > mechanisms must take storage volumes down cleanly and correctly request a > shutdown or reboot from the system firmware. Logging out must return the > user to the environment from which they logged in, working as expected. User > switching must allow multiple users to perform live switching between their > sessions, working as expected. > > > What do you think?

6 10

Agenda for Workstation panel @ DevConf.cz
by Paul W. Frields 29 Jan '15

29 Jan '15

https://fedoraproject.org/wiki/User:Pfrields/Workstation_panel_at_DevConf.c… I drafted up notes for the Fedora Workstation WG panel talk that's happening on Sunday morning at the DevConf.cz event. The talk is not meant to be exhaustive regarding past or future Workstation features. It's meant to summarize and highlight. A substantial portion of the time should be given to open audience questions/answers of the WG members. The agenda is open to review, edit, or comment on the agenda, especially by WG members attending the conference[*]. = = = [*] I'd ask WG members to be at the panel talk. I believe Christian, Matthias, Kalev, Owen are attending; did I err or miss anyone? -- 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 5

Webapps for developers
by Matthias Clasen 29 Jan '15

29 Jan '15

Hey, we currently are shipping information for a relatively small set of webapps so that they show up in gnome-software. Since we are aiming to make the Workstation developer-focused, maybe we should add some must-have developer sites to that list ? I'm really just asking for suggestions here, I'm probably too old-fashioned in my development habits to know the places that really should be on this list... devdocs.io ? stackexchange.com ? github.com ?

13 31

root password required for basic troubleshooting
by Chris Murphy 27 Jan '15

27 Jan '15

Hi, In Fedora 20 and 21, the installer doesn't require setting the root password. Yet systemd in both requires a root password to do anything, including basic boot time troubleshooting, in both rescue.target and emergency.target. If the user is dropped to an emergency shell at boot, and are referred to rdsosreport.txt, they can't do anything if they haven't set a root password. And if they need to do a password reset, they're stuck also. Questions Is this the intended and desired UX for Workstation? If not, what policy change is most practical? Requiring the user set a root password, or somehow enabling systemd emergency.target to accept a non-root user in group wheel? Points of comparison Windows has a burdensome password reset method, but it does offer startup repair environments that don't require a password. OS X has a safe boot option, as well as a separate recovery environment, also without requiring a password, and a password reset can be done within this environment. -- Chris Murphy

2 3

Evince browser plugin
by Michael Catanzaro 27 Jan '15

27 Jan '15

Hi, I noticed the Evince browser plugin is not installed by default. It was split into a subpackage to accommodate organizations that are concerned about the security implications of displaying PDFs in the web browser, and nothing installs the subpackage. This plugin is very good, and I want it to be installed by default for all Epiphany users who have Evince installed, as intended by upstream. (For Firefox users, it doesn't matter because Firefox will use its own built-in PDF viewer in preference to the plugin, Firefox makes it click-to-run which sucks, and Firefox hangs when it dlopens a GTK+ 3 plugin anyway.) The correct solution in most distros would be for the evince package to have a Recommends for the evince-browser-plugin package, so that users get it by default but sysadmins can decide not to install it if need be. But we can't use Recommends yet. :S So there are a few options I can think of: * Add a Requires from evince to evince-browser-plugin, to be changed into a Recommends once we're allowed to use those. This will sadden those who do not want the browser plugin, but it's the most "correct" approach. * Add a Requires from epiphany-runtime to evince-browser-plugin. That would make Epiphany depend on Evince, and we don't want apps to depend on other apps, so this is my least favorite option. But it is preferable to users having to discover and install the plugin themselves. (It's a good plugin. :) * Add evince-browser-plugin to the Fedora Workstation group in comps. This is yucky since it only benefits Epiphany users, and Epiphany is not installed by default. But I think it's preferable to a Requires from Epiphany to Evince. Any preferences or other suggestions? (If anyone can think of an option that's actually good, that would be dandy.) Michael

4 5

rescue environment with live media
by Chris Murphy 27 Jan '15

27 Jan '15

Two problems with live media: 1. Installer team dislikes it because the environment gets increasingly non-deterministic the longer the user uses the system before installing the OS, and this can cause unpredictable installer failures that are also quite difficult to test for. (This is an old concern.) 2. The installer rescue mode isn't available with live media. Both Ubuntu and openSUSE offer separate boot menu options for installing the OS, vs booting the live environment. It seems both problems above could be obviated if Fedora lives also distinguished between installing vs booting live. I know this has come up before, but not since products arrived. It's understandable this is probably a Fedora 23 food for thought. It is somewhat mitigated by the Fedora 22 plan to have separate product netinstalls, with which the rescue mode will be available. -- Chris Murphy

1 0

Fedora 21 Alpha validation test work
by Adam Williamson 24 Jan '15

24 Jan '15

Hi, folks. So, we're scheduled for Alpha TC1 tomorrow. We had a nice happy co-operative plan where QA and the WGs would collaborate on revising the release validation test process for Fedora.next... ...which, well, didn't really happen. As of this morning we were nowhere near having a viable validation process. So I went for plan B: I spent today more or less pulling the entire thing out of my ass. It's a bit rough around the edges, but I think we more or less have something workable now. I have skipped the draft stage for a lot of documents just in the interest of having something vaguely workable in time for TC1; of course, the pages can be revised as much as necessary as we work with them. It's a bit hard to remember everything I've done, but we now have a draft Alpha Release Criteria page which should cover all release-blocking media, which for now I'm assuming includes the Workstation live media, Server minimal and offline install media, Cloud and ARM disk images, and possibly some kind of generic network install image. That draft is at https://fedoraproject.org/wiki/User:Adamwill/Draft_F21_Alpha_criteria and is based on the stuff from https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria , https://fedoraproject.org/wiki/User:Adamwill/Draft_workstation_release_crit… and https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Release… , plus some adjustments to the templates that handle the preamble. We have a new validation matrix, for Server product-specific tests: https://fedoraproject.org/wiki/QA:Server_validation_results_template The Desktop matrix has been adjusted to cover - not quite elegantly, but at least cover - both the Workstation product and the KDE spin: https://fedoraproject.org/wiki/QA:Desktop_validation_results_template The Base matrix has been extended to add a couple of new test cases that came out of the Product criteria drafting process, but actually aren't really product specific, and has had its columns adjusted to be product-y: https://fedoraproject.org/wiki/QA:Base_validation_results_template The installation matrix has similarly had a couple of new criteria wedged in, but much more importantly, I ripped the netinst, DVD and live image 'sanity test' sections and replaced them with an ARM-style table where a single 'generic' test case is run against several images on several platforms - that's the "Default boot and install" section, so please cast an eye over it: https://fedoraproject.org/wiki/QA:Fedora_21_Install_Results_Template and I made a small change to the release validation test event SOP to list the server matrix as one to create: https://fedoraproject.org/wiki/QA/SOP_Release_Validation_Test_Event Here are links to all (I think) of the new test cases I had to write as I went along: https://fedoraproject.org/wiki/QA:Testcase_Boot_default_install https://fedoraproject.org/wiki/QA:Testcase_kickstart_user_creation https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation https://fedoraproject.org/wiki/QA:Testcase_base_selinux https://fedoraproject.org/wiki/QA:Testcase_Server_firewall_default https://fedoraproject.org/wiki/QA:Testcase_kickstart_firewall https://fedoraproject.org/wiki/QA:Testcase_Server_cockpit_default The following test cases already existed, but are newly included in the release validation process (they were written for test days): https://fedoraproject.org/wiki/QA:Testcase_FreeIPA_realmd_join https://fedoraproject.org/wiki/QA:Testcase_realmd_join_kickstart https://fedoraproject.org/wiki/QA:Testcase_realmd_join_server There are still quite a few i's to dot and t's to cross. There are some release criteria and test cases that explicitly reference 'the DVD' image that will need to be adjusted. We need to apply the 'associated release criterion' template to all the new test cases, and probably clean up some categorizations. Various other process documentation pages may need to be updated, we'll have to check through all of them. But I think now we at least have the broad strokes of what's needed for .next validation testing. All feedback on the above changes is of course welcome! Please do cast your eye over and point out anything I missed, anything that looks silly, any possible improvements and so on. Remember, though, this is really *test process* design: we're not actually doing product design here, if you think there are issues with the Fedora.next changes themselves, that goes to the WGs or FESCo. As far as this work is concerned, we're just trying to test the new Products as they're designed (all of the above is based off of the Product PRDs and tech specs). I'll take time tomorrow to do some polishing, and of course look at any and all feedback on the stuff I did today. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 3

Plan of Record for Fedora 22 Network Install Media
by Stephen Gallagher 24 Jan '15

24 Jan '15

(Cross-posted to the WG mailing lists; please reply only to devel@) == Overview == Today in #anaconda, we had a discussion of the plans for network install media for Fedora 22. We acknowledged that the network install (and more generally, unattended installation) story in Fedora 21 was somewhat lacking. In particular, there was user confusion around how to deploy Fedora Workstation in an unattended manner. Some of the problems we faced in Fedora 21 were a result of not having necessary plumbing in Anaconda (largely because we didn't even realize this until well into Beta phase, at which point we just started breaking out the duct tape and chewing gum). In particular, we needed a way for individual Fedora editions to provide a mechanism for specifying different defaults (such as automatic partitioning rules or the default environment group that would be displayed in an attended install). Without these things, while we could produce media with separate graphical branding, we couldn't truly produce separate network installs for Cloud, Server and Workstation. So we settled on producing only the Server network install media. == Output == In Fedora 22, we will be producing four network install ISOs: * Fedora Server - Server branding - Default environment group: Fedora Server - Auto-partitioning defaults: LVM on XFS (except /boot) - Responsible WG: Server WG * Fedora Workstation - Workstation branding - Default environment group: Fedora Workstation - Auto-partitioning defaults: LVM on EXT4 - Responsible WG: Workstation WG * Fedora Cloud - Cloud branding - Default environment group: Fedora Cloud - Auto-partitioning defaults: TBD - Responsible WG: Cloud WG * Fedora "Generic" (name TBD) - Generic Fedora branding - Default environment group: minimal - Auto-partitioning defaults: TBD - Responsible WG: Base WG In addition, there is ongoing discussion around media for bare-metal Fedora Atomic installations. This has not been finalized, but will likely result in an additional output. While each of these network installs will be *capable* of also installing any of the other products (though possibly not with the expected auto-paritioning), we have agreed that QA testing will only be performed on the intended environment group target for the branded media. We will not advertise or make any special effort to support other targets. == Remaining work that needs to be done == Release engineering will need to modify their compose tools to produce each of these install trees, as well as handling the necessary mirroring functions. The working groups responsible for each of these install media will be responsible for performing the following tasks before the Alpha Freeze (ideally well before, so we can run test composes and fix issues without slipping): * Modify the appropriate fedora-productimg-$PRODUCT package to include an anaconda extension model that will extend the InstallClass and set the default environment group and optionally modify the auto-partitioning functionality. * Review the contents of comps-f22.xml.in and the related kickstart files in spin-kickstarts to ensure that the install media contains the appropriate content. For simplicity in understanding who to contact, it would be beneficial if each of the responsible working groups would nominate an individual to be the point of contact on these changes. I volunteer myself to represent the Server WG in this capacity. Given that we branch on February 10th enter Alpha Freeze on February 24th, I'd like to propose a soft deadline (a check-in) on February 9th with a hard deadline on February 16th in order to have time to run at least one test compose prior to Alpha Freeze. == Acknowledgements == The cast of characters involved in this discussion were: * Stephen Gallagher (Server WG) * Dennis Gilmore (Release Engineering) * Brian C. Lane (Anaconda) * Ian McLeod (Project Atomic) * David Shea (Anaconda) * Adam Williamson (QA)

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 January 2015