desktop September 2016

desktop@lists.fedoraproject.org

36 participants
30 discussions

Change in WG meeting time
by Paul W. Frields 12 Sep '16

12 Sep '16

I wanted to check on Workstation Working Group members' availability for our meeting time. Our current time, 10:00am Eastern on biweekly Wednesdays, has worked fairly well. However, Michael can't make it for the foreseeable future. In some groups it might be odd to look at times for just one person, but he's a very active contributor to the WG so it makes sense to do here. :-) I posted this WhenIsGood for WG members to answer: http://whenisgood.net/workstation-wg-2016 Please visit this by the end of the week. I'll take a look and post results next Tuesday. -- 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

1 1

Third party repos and command line access
by Rahul Sundaram 12 Sep '16

12 Sep '16

Hi Just curious - Has there been any thought given to how third party repositories are going to be exposed on the command line? If someone wants to use dnf, it seems like there isn't an easy to do this with the current proposal. A command interface that can abstract away the package content format differences - rpm, flatpak would be useful Rahul

6 8

Procedure for dealing with 3rd party applications
by Christian Schaller 09 Sep '16

09 Sep '16

Hi Workstation Working Group, So now that that Council finalized on the 3rd party software proposal in a positive way (https://fedorahosted.org/fesco/ticket/1617) we need to figure out the details on how we want to approach this as a working group. As mentioned in previous discussions and in the concrete proposal there will need to be some kind of procurement process here to ensure we don't drag Fedora and Red Hat into legal troubles. So let me start by listing what think should be our guiding principles for dealing with 3rd party software. a) We want the process of inclusion technical bit to be well documented and clear b) We want the process for inclusion in Fedora Workstation to be as transparent as possible. So for a) I have already asked Richard Hughes to draft up a document including all technical requirements for a 3rd party application to show up in GNOME Software. He made a start of that in this blog entry (https://blogs.gnome.org/hughsie/2016/09/02/fedora-25-and-additional-softwar…) My idea is that we build and that and ensure we get an article up on the Fedora Developer Portal with this information and more. Basically I want it to cover every step from source tarball to finished RPM/Flatpak and hosting. I figure that this will in some sense be the easy step as all items here are already known we just need to pull things together and document them. for b) things are a bit more of a blank sheet currently my thoughts on this are as follows: So the process of procuring a new application has a few natural steps. 1) application developer reaching out to us or we reaching out to application developer 2) we discuss the technical requirements of a) with said developer 3) we discuss any legal issues with said developer (sounds scary, but it could just be pointing said developer to a terms of service agreement 4) if developer have already done or is willing to do 2) we decide if we want to include said application in GNOME Software. 5) we include the URL to their repository in our 3rd party repositories package So one thing I been thinking quite a bit about here is that for many developers whose application could potentially be included might want to be able to have a non-public discussion with us on it first. There could be many reasons for this including not wanting to create a public expectation of something before they finally decided upon doing it to needing to figure out some technical or legal details before committing etc. So my suggestion is that we as workstation working group members empower ourselves to be able to speak with this companies and people in confidence, but that we make it clear that the final decision to include will be a public one, done as part of the working group meetings. This should hopefully let us balance the need for privacy in initial discussions to having a clear public paper trail to how and when something was agreed to go inn. We should also develop some kind of inclusion policy document, drawn from the basic guidelines of the Council proposal, to ensure that the inclusion decision is highly predictable. I will also have another chat with the Red Hat lawyers to figure out the details of what kind of legal vetting etc., we need to do here. Any other ideas or suggestions for how we proceed here? I assume that no matter what we decide upon we will need to adjust it as we get going and we deal with the real issues that might or might not pop up. Sincerely, Christian

5 9

Btrfs in fedora 25-26
by Hugo Alejandro 08 Sep '16

08 Sep '16

For a while there was much talk about a replacement for ext4 to btrfs, for fedora 23 (desktop)... I have not read related news to future releases of fedora workstation and btrfs wiki it seems outdated <https://fedoraproject.org/wiki/Btrfs>. I have some doubts regarding support for Btrfs in fedora and recommended partitioning through Anaconda. I understand that /boot can be part of a btrs partition (GRUB2 claims to have support) but it is not possible to set it on a clean installation. Are there blockers in fedora workstation to set btrfs by default? Cheers -- *Hugo*

2 2

Booting Your Computer in Rescue Mode
by Chris Murphy 07 Sep '16

07 Sep '16

This came up on the user@ list recently so I filed a docs bug. The gist is that because it boots graphically, and Anaconda inst.rescue is text based, there's no rescue. Further, rescue.target and emergency.target aren't functional either because systemd requires root login password for those, but the lives don't have a root password set. So what I've suggested in the bug for docs is the user can use init=/bin/bash if they need access to a shell, but... I'm not really sure if there's a better way to handle this? Suggest the user download a netinstall image for rescue? https://bugzilla.redhat.com/show_bug.cgi?id=1374064 -- Chris Murphy

2 1

wifi firmware on netinstall?
by Matthew Miller 06 Sep '16

06 Sep '16

Because I was just doing a one-off install of Workstation on my new laptop and probably won't use the USB stick again (without updating to a newer version), I chose the Workstation Netinstall. And... the wifi didn't work, because iwl7260-firmware wasn't installed. After a brief moment of puzzlement, I shrugged and went to the full CD. I understand that these probably aren't needed on the server netinstall, in the interest of keeping it small, but what about Workstation? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

2 1

Installing .flatpak files in Software in F25
by Jiri Eischmann 05 Sep '16

05 Sep '16

Hi, I was under the impression that GNOME Software 3.22 will be able to install .flatpak bundles. You download a 3rd-party .flatpak bundle, double-click the file and Software does the magic for you (installs necessary runtime, install the app, sets up app's repo,...), but I tried it on my upgraded system to F25 and Software doesn't seem to handle .flatpak files at all. I still need to do the inconvenient procedure of several commands to install a flatpak. Was it never a plan to install flatpaks in Software this way and I got it wrong or it didn't make it to the release for some reason? If we need to improve something it's user experience of installing flatpaks which is currently pretty terrible and people point it out all the time. Jiri

2 2

Fedora 25
by Benson Muite 05 Sep '16

05 Sep '16

Hi, If any of you use Fedora Atomic as a desktop, could you add a brief overview of why and how (workflow) you do so here: https://fedoraproject.org/wiki/Fedora_25_talking_points For the typical Fedora workstation user, what is needed to migrate to Fedora Atomic as a desktop? Does this make it easier to use remote cloud resources? Thanks, Benson

1 0

Wayland by default on F25? Blockers?
by Christian Stadelmann 03 Sep '16

03 Sep '16

I'd like to know whether there are plans to make wayland default in F25. I'm asking because there was no change proposed for this¹, although Fedora Magazine is stating it will become default in F25². I know that there have been some considerations on this before³ and some places where issues are collected⁴. Still, the wiki page is missing some important stuff: How do we handle the fact that even XWayland applications cannot be started as root? I'm ok with dropping the "feature" of starting GUI applications as root, but this might need some discussion and will need some communication. Please note that this would drop any support for at least a dozen applications such as GParted or grub-customizer. And, as Kamil Paral stated on the december thread: > I think we're going to get much worse publicity with this than primary selection. Inexperienced Linux users are used to run "sudo gedit", because terminal editors are unfriendly. Even I, with my years of experience, use "sudo meld" to merge configuration files, because I don't want to learn vimdiff, and graphical apps can simply offer a much superior experience. There was a discussion on devel list about this and everybody talked why running root gui apps is unsafe on X11, but nobody explained why it is unsafe on Wayland. Polkit and fine-grained permissions were proposed, which is a good idea, but it's not going to solve all use cases and it's not the current state of things in many apps. So unless there's a very good reason for deviating from current common practices, I'd put this onto "needs to be fixed" list. The more things we break without a really good reason, the more pushback we're going to get. Maybe this can be improved gradually over time? This point should at least be noted on the wiki list. Can someone please add it? Accessibility is pretty much unusable on wayland right now. The wiki page lets me assume that nobody really worked on this besides some minor bug fixings. Can we disable wayland for people relying on a11y? If not, shipping wayland by default probably is a bad idea. Virtual machine and remote desktop software: Currently, it is impossible for remote desktop and virtual machine GUIs (both under XWayland and Wayland) to grab keys. This is a major regression for all users of these pieces of software.⁵ This point is completely missing on the wiki page. Can someone please add it? Stability: There are more crashers in gnome-shell with wayland than with X11. That's probably ok, but still worth considering. Drivers: Lastly, I don't know anything about support with non-Intel GPUs, because their drivers (especially proprietary ones) used to mess up pretty much last time I used them. ¹ https://fedoraproject.org/wiki/Releases/25/ChangeSet ² https://fedoramagazine.org/whats-new-fedora-24-workstation/ ³ See e.g: * "Plan to organize the Wayland-by-default effort" in late 2015, https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o… * "Wayland blockers for F24 default" in februar, https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o… ⁴ See https://bugzilla.redhat.com/show_bug.cgi?id=WaylandRelated https://bugzilla.gnome.org/show_bug.cgi?id=WaylandRelated and https://bugzilla.gnome.org/show_bug.cgi?id=wayland https://fedoraproject.org/wiki/Wayland_features ⁵ https://bugs.freedesktop.org/show_bug.cgi?id=97333 and https://bugzilla.redhat.com/show_bug.cgi?id=1285770

15 39

Another Ars review
by Michael Catanzaro 03 Sep '16

03 Sep '16

Hi, We should all read today's featured Ars article: http://arstechnica.com/information-technology/2016/08/fedora-24-review-the-… There's a few inaccuracies, but no more than normal for distro reviews. It's good feedback at any rate. Highlights: * Author plainly states that he thinks Fedora is better than Ubuntu and Mint * Author thinks we released too soon, should have waited for a kernel upgrade. (I don't think it makes sense to consider the kernel in the schedule....) * Author mentions the Skylake fiasco in recommending that users wait a couple months before updating to the new release; familiar suggestions that our distro is unstable. In a sense it's Intel's fault for the bad update, but other distros did not ship this broken update. This could probably have been avoided if our update system was more conservative. It's nuts that we have important packages going from testing to stable in less than a day and we should fix this. * Author praised GNOME Photos and GNOME Calendar... even though they're not installed by default. (Let's change that!) He also praised Maps. * Author says Flatpak support in Software is still unstable. That's being worked on. * Author is disappointed that Flatpaks don't use the system fontconfig settings, says it makes Flatpak apps look inconsistent. * Author heaped praise on the new font settings. He didn't notice the changes that went into Freetype, though, so GNOME got perhaps more praise than deserved, but I can live with that. ;) * Author is also pleased with QGnomePlatform Some inaccuracies I found: * Author dinged us for not having Chromium, but we do have Chromium in our repos. It's because it (presumably) has no appdata file, so it doesn't appear in Software. Who wants to fix it? * Author dinged us for not having VLC, but this is really unfair; he's probably not aware of the legal issues. * Author doesn't realize that our graphical upgrades are already working for F23 -> F24, suggests users must wait until F25 to see how well the upgrade works. * Author thinks the PackageKit command-not-found helper we've had for years is new and related to dnf. * Author thinks spins are variants of WorkStation... and somehow decided to camel-case our name * Author thinks we're on an eight-month release cycle (sad!) Michael

8 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop September 2016