desktop June 2014

desktop@lists.fedoraproject.org

38 participants
17 discussions

List of Qt/Qt5 packages for Fedora WS
by Lukáš Tinkl 29 Aug '14

29 Aug '14

Hi, based on request of cschaller, I'm sending the proposed list of Qt/Qt5 packages to be included in Fedora Workstation: qt qt-x11 qt-settings qt5-qtbase qt5-qtimageformats qt5-qtsvg qt5-qtx11extras qt5-qtxmlpatterns qt5-qtdeclarative qt5-qtquickcontrols qt5-qtdoc qt5-qtconnectivity qt5-qtmultimedia qt5-qtgraphicaleffects (you can see the dep chain of qt5 packages here: https://fedoraproject.org/wiki/KDE_updates) -- Lukáš Tinkl <ltinkl(a)redhat.com> Senior Software Engineer - KDE desktop team, Brno KDE developer <lukas(a)kde.org> Red Hat Inc. http://cz.redhat.com

35 104

Gnome 3.14 copr on F20
by Ankur Sinha 22 Aug '14

22 Aug '14

Hi, I just read Matthais' post on the planet and couldn't wait to try out the new *shiny* gnome packages from the 3.14 copr. Unfortunately, there seem to be some breakages: dnf --refresh --best update gives me: Error: nothing provides gnome-shell >= 3.13.2 needed by gnome-shell-extension-common-3.13.2-2.fc20.noarch. nothing provides gnome-shell >= 3.13.2 needed by gnome-shell-extension-common-3.13.2-2.fc20.noarch. package NetworkManager-l2tp-0.9.8.6-1.fc20.x86_64 requires ppp = 2.4.5, but none of the providers can be installed. package evolution-data-server-3.12.3-1.fc20.x86_64 requires libgdata.so.13()(64bit), but none of the providers can be installed. package gnome-shell-3.12.2-1.fc20.x86_64 requires libmutter-wayland.so.0()(64bit), but none of the providers can be installed. package gnome-shell-3.12.2-1.fc20.x86_64 requires libmutter-wayland.so.0()(64bit), but none of the providers can be installed. package NetworkManager-l2tp-0.9.8.6-1.fc20.x86_64 requires ppp = 2.4.5, but none of the providers can be installed Omitting the --best flag doesn't work either. It wants to reinstall evolution-data-server and errors out saying: Error: Transaction check error: package evolution-data-server-3.12.3-1.fc20.x86_64 is already installed I was on the 3.12 copr already. Thanks for putting up the new copr! -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

6 18

Multibooting UX, how well it ought to work
by Chris Murphy 16 Aug '14

16 Aug '14

This is largely directed to the WG, as a request to clarify a part of the workstation product tech spec. It relates to a thread on the anaconda list regarding os-prober, and a thread on this list regarding release criteria, both of which are referenced below. I am cross posting to the server@ list as well, while they don't have a dual-boot requirement in their spec it stands to reason the ability to dual-boot Fedora Server/CentOS/RHEL version n and n+1 could come in handy when doing migrations while still having a fall back position. Perhaps replies should drop the other cross posting since the requirements for the two products are different? But I leave up to the person replying to decide. The WorkstationTechnical Spec says: "One aspect of storage configuration that will be needed is support for dual-boot setups (preserving preexisting Windows or OS X installations), since e.g. students may be required to run software on those platforms for their coursework." 1a. Does preserve preexisting include providing a working menu entry in the boot manager (e.g. in the GRUB menu)? 1b. Or is it sufficient to just preserve the installation data — meaning it's permissible for its bootability to be either non-obvious or broken? 2. If the answer to 1a. is yes, and 1b. is no, does this dual-boot requirement apply to both BIOS and UEFI? 3. If resources cannot meet the dual-boot requirement by ship time, should the installer inform the user that their previous installation will be preserved but may not be bootable? 4. Why is the preservation of an existing Linux OS, including a previous Fedora, not explicit in the spec? Should it be? The answers to the above will help determine the scope of QA testing in this area, and avoid lengthy debate during blocker meetings. Maybe it'll provide some kick in the pants for old bugs with unimplemented solutions. Or maybe it will make it clear that the UX in this area doesn't need improvement and therefore effort testing and developing can be better spent elsewhere. So in any case, clarification will be helpful. References: "grub2, 30_os-prober, os-prober: A Proposal" https://www.redhat.com/archives/anaconda-devel-list/2014-June/msg00020.html Initial very rough Workstation release criteria draft https://lists.fedoraproject.org/pipermail/desktop/2014-June/009931.html https://bugzilla.redhat.com/show_bug.cgi?id=825236 https://bugzilla.redhat.com/show_bug.cgi?id=964828 https://bugzilla.redhat.com/show_bug.cgi?id=1048999 https://bugzilla.redhat.com/show_bug.cgi?id=1010704 Thanks, Chris Murphy

9 22

Introduction, Documenting Workstation
by Pete Travis 17 Jul '14

17 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm acquainted with many of you already, but an introduction seems fitting anyway. I've been involved with the project for a few years now, primarily on the Docs team but also some light packaging and lately light infrastructure things. I live in Montana, US, where the population density is almost as low as the temperature. I work for a small government agency doing user and systems support. Why should you care? Well, the Docs team reached a decision this last weekend to proactively work with the Product WGs to assess documentation needs. I volunteered to liaison with the Workstation team. As we approach the release cycle, I'd like everyone to keep documentation in mind and the discussion open about not only implementation, but how to represent that implementation to the users. An undocumented feature isn't featured :) I'm looking forward to working with everyone, perhaps saying hello at the next meeting - there are meetings, right? - and developing a presentation of the Workstation Product that shows off the capabilities and character of your work. - -- - -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize(a)fedoraproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTNW1PAAoJEL1wZM0+jj2Zos4H/37WaPQMRumzi766cXv6x3mb ADJuFmZ+mZwosTynurCAKG5p8PczOHKhRrZNslf9nFNx4dczc94QJFlO7hPOq3Mr WOzkSn6pUXppukAd6UxX7qAjtrNomYCM8kDlmyK+ArZmVbo78O2IppeSwZk4R/tJ ILnktcYl4sXJjlOrA28X5uiZ0dvreuZPBT+UsiDZHVvFBQfaYqjUKIioW/R4wQYp FoFvLbXe2XCn609LuHl0TcEP9DIwd2ShKROqw2fhXXSPe4jWWwkm0+FktwEKAt46 DqKBpIZeeIIZfiKXRPS6CCGNOULboepDKj+7RfqmtrjUIqdPQZ4ZP+Hdr1vSC3M= =G3EO -----END PGP SIGNATURE-----

2 2

Workstation status and TODOs
by Josh Boyer 07 Jul '14

07 Jul '14

Hi All, We have just less than 3 months before the F21 Alpha change deadline comes. That means that now is the time to get going in earnest on making sure we have all the things we want lined up for the initial release of Workstation done. Matthias and Christian have done a great job of getting us started, and have gotten some major Changes approved. The GNOME 3.12 rebase was accepted, and the enabling of SCLs should go over fairly well once the questions are addressed. So what is left? Off the top of my head I can think of: 1) Getting the kickstart for Workstation cleaned up with the appropriate package lists (I'd be willing to get this rolling) 2) Integrating KDE into the above in whatever form we work out with the KDE team 3) KDE variant of Adwaita theme 4) Firewall/firewalld integration issues 5) Installation and compose methods work with rel-eng (live image default, but install tree necessary for compose. PXE/netboot iso? etc) I'm sure I'm missing a few things here. Please chime in with what I'm forgetting. In short, there's more than enough work to go around. Lastly, we've been rather quiet as a WG as of late. The Cloud WG is going through a confirmation process with their members to make sure people are still interested and willing to do work. That's not a bad idea for ourselves. WG members, please take the time to reply with whether or not you wish to remain a WG member. As an aside, much of the "heavy lifting" in terms of process is done for this release. The PRD and Tech Specs have been approved, and the initial round of Changes are submitted. Not being overly familiar with the underlying code in much of the DE stacks, my participation has been limited mostly to those kinds of process things. I think we still have some discussions to have on process and interactions with other groups, but I thought I would double check that the WG feels I'm doing a decent job representing them in this capacity. I'm happy to continue to pitch in where I can, but if the WG feels they'd be better served by someone else as the FESCo liaison, please speak up. josh

6 9

Curating the metadata in the Software application
by Ryan Lerch 30 Jun '14

30 Jun '14

IMHO, Software is a very important application in the Workstation concept, however much of the appdata needs refinement and curation to make it even more useful to Fedora Workstation users. What it be a good idea to start up a team of some sort to start up this process? A little unsure of the best way to approach improving this part of the Workstation for our users. cheers, ryanlerch

5 9

Re: Multibooting UX, how well it ought to work
by Stephen Gallagher 27 Jun '14

27 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/27/2014 11:30 AM, Simo Sorce wrote: > On Thu, 2014-06-26 at 18:51 -0600, Chris Murphy wrote: >> This is largely directed to the WG, as a request to clarify a >> part of the workstation product tech spec. It relates to a thread >> on the anaconda list regarding os-prober, and a thread on this >> list regarding release criteria, both of which are referenced >> below. >> >> I am cross posting to the server@ list as well, while they don't >> have a dual-boot requirement in their spec it stands to reason >> the ability to dual-boot Fedora Server/CentOS/RHEL version n and >> n+1 could come in handy when doing migrations while still having >> a fall back position. Perhaps replies should drop the other cross >> posting since the requirements for the two products are >> different? But I leave up to the person replying to decide. > > To be honest I do not see any need whatsoever for multibooting in > the Server case. > > So whatever abilities the Workstation WG want will be sufficient > IMO. I will second this. Dual-booting is not particularly valuable in our case. People doing migrations are generally doing staged upgrades in a testing environment first. Now, there's certainly an argument to be made for a robust rollback mechanism, but that's a different topic (and one we will probably explore with Project Atomic in Fedora 22). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOtkWkACgkQeiVVYja6o6MX7ACfU4ulkBM5dRueulEKKsUA2SRs cOcAnjzpu5ctpX4RfXxoQjwb+sXgNSHJ =2QSK -----END PGP SIGNATURE-----

1 0

Initial very rough Workstation release criteria draft
by Adam Williamson 26 Jun '14

26 Jun '14

Hi, folks! Continuing to work on release criteria revision for Fedora.next / Fedora 21 (and getting a bit behind :<), I have a very rough working draft for Workstation: https://fedoraproject.org/wiki/User:Adamwill/Draft_workstation_release_crit… for now, Alpha, Beta and Final are together. So far I have not added any new criteria, but I've taken a rough shot at splitting out the existing criteria that seem either only applicable to the Workstation product, or that would clearly benefit from a Workstation-specific variant, and simplifying them appropriately. Mainly that means we don't have to fudge around as much with generic wording when we're talking about the Workstation product and not about "release blocking desktops" in particular. Next step would be to add new criteria where appropriate to reflect the tech spec; I'll try and take a look at that tomorrow. Probably useful to know for reference and comparison that the current working Server draft is at https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria , and the Cloud draft (by Mike Ruckman) at https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Release… , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Release_… , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Release… . I am still thinking about how we go about presenting the entire collection of criteria for Fedora 21 as a whole - we need to somehow present criteria that apply pretty cleanly to all the supported deliverables, ones that apply to more than one but not all, ones that apply to just one, ones that *sort of* apply to multiple deliverables but clearly need to be tweaked slightly for each deliverable they apply to, and criteria for non-Product supported deliverables (at least KDE, which we've explicitly decided is not a Product but *is* release blocking for F21). It's a bit of a puzzle, and I'm trying to think it through as I work on the Product drafts. So I'm hoping I'll be able to present a Grand Plan draft of the combined presentation some time shortly after we finish deciding at least on the broad shape of the criteria we want to apply to each deliverable. If anyone has helpful thoughts beyond the prior discussion on this, please do send 'em in! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Tasklist for the Fedora Workstation
by Christian Schaller 25 Jun '14

25 Jun '14

Hi everyone, As we are ramping up the development effort around the workstation we wanted to help increase transparency and enable more community participation in the Fedora Workstation effort by providing a more detailed view of the various tasks underway as derived from the more high level PRD and Technical Specification documents. You can find the current version of the tasklist here - http://fedoraproject.org/wiki/Workstation - but we hope to expand on it in the coming days and weeks to be even more comprehensive and also include more explanations around the motivation for each task. The list enumerates the various efforts that is being undertaken around the Fedora Workstation effort and also puts a name next to many of the items. If you are interested in helping out with any of these efforts please get in touch by reaching out either to the Working group board members or to the people listed next to the tasks in question. For those of you not familiar with the working group we have contact information and board membership information available on this page: http://fedoraproject.org/wiki/Workstation If you are getting this email you probably already know about the mailing list, but the working group can also be reached on IRC on #fedora-workstation on freenode. Looking forward to discussing our plans with both new and old contributors to the workstation product effort. Feel free to ask questions about the various tasks as I realize that the list is quite low on detail atm., and not all items might be self explanatory and as mentioned we do hope to add more detailed information to each item in the next few days. Sincerely, Christian Schaller

2 1

A bit more about default apps for Workstation
by Diogo Campos (cadastros) 16 Jun '14

16 Jun '14

Hi, First I would suggest that we make sure that Workstation comes with a preinstalled backup app (I say this because Fedora 20 does not). If there is not one already, I vote for "Deja-Dup". Another thing: now that we have California (calendar app), GNOME Contacts (contacts app), Bijiben (notes app) and GTG (tasks app), is time to preinstall Geary instead of Evolution. Right?

11 18

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop June 2014