Change in WG meeting time
by Paul W. Frields
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
7 years, 7 months
Third party repos and command line access
by Rahul Sundaram
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
7 years, 7 months
Procedure for dealing with 3rd party applications
by Christian Schaller
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-softw...)
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
7 years, 7 months
Btrfs in fedora 25-26
by Hugo Alejandro
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*
7 years, 7 months
Booting Your Computer in Rescue Mode
by Chris Murphy
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
7 years, 7 months
wifi firmware on netinstall?
by Matthew Miller
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
7 years, 7 months
Installing .flatpak files in Software in F25
by Jiri Eischmann
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
7 years, 7 months
Fedora 25
by Benson Muite
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
7 years, 7 months
Wayland by default on F25? Blockers?
by Christian Stadelmann
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...
* "Wayland blockers for F24 default" in februar, https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
⁴ 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
7 years, 7 months
Another Ars review
by Michael Catanzaro
Hi,
We should all read today's featured Ars article:
http://arstechnica.com/information-technology/2016/08/fedora-24-review-th...
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
7 years, 7 months
