Plan to organize the Wayland-by-default effort
by Kevin E Martin
We are working toward enabling the GNOME desktop on Wayland as the
default for the Fedora Workstation project. The question is: What
features do we have to complete in order to make this switch? Everyone
seems to have their own ideas of what is required, and a systematic
approach is needed to organize the effort.
Over the years, many features have been developed for the traditional
X11-based GNOME desktop, and we are bringing these features over to the
Wayland-based version. Quite a few of these features have already been
implemented for the Wayland-based desktop and we already have highly
functional desktop experience that everyone can use, but it is not yet
complete. In order for us to enable it by default we need to both
implement the missing features and fix the bugs in features that are
already complete.
For the bugs, we simply need to fix them. However, the situation with
features is more complex. We each have our own list of features that we
believe need to be implemented, but we lack a complete list of all the
missing features and a clear way to determine when we have implemented
enough of them to enable the Wayland-based GNOME desktop by default.
Toward that goal, we are consolidating all of the various feature lists
in the following Fedora wiki page:
https://fedoraproject.org/wiki/Wayland_features
We are putting this on the Fedora wiki (instead of a GNOME, Wayland,
kernel, Freedesktop or other wiki) since this is a Fedora decision on
when we feel the Wayland-based GNOME desktop is ready to be the default
for our Fedora Workstation project.
The initial step is to list all features for the Wayland-based GNOME
desktop. Olivier Fourdan, who has been heavily involved in the upstream
Wayland development and also involved in GNOME development activities,
has agreed to maintain this page. If you have ideas for what features
should be included, please add them to the wiki page and discuss them on
this list.
What we need for each missing or incomplete feature is a descriptive
name and what stage of development it is in. Links to other pages where
more detailed description of the feature status and implementation
details are also welcomed. For the development stages, there are
kernel, supporting libraries, Wayland protocol, XWayland, mutter, gtk+
and application levels. For example, tablet support is currently
implemented in the kernel and supporting libraries. The protocol has
been proposed and is under discussion. Once the protocol has been
accepted, there will be additional development needed at higher levels.
This feature will remain on the list until it is complete at all levels.
The next step is determining which of these features must be implemented
before we can enable Wayland by default in Fedora Workstation. The plan
is to form a small group of people deeply involved in the Wayland, GNOME
and/or Fedora development to prioritize the list of features and then
draw a line in this prioritized list above which all features must be
complete before we will enable the GNOME desktop on Wayland by default
in our Fedora Workstation project. We can then evaluate this list
during the Fedora 24 development cycle to determine if we are ready to
enable Wayland by default in the alpha, beta and final releases.
7 years, 9 months
Missing dnf-langpacks package in Workstation Live iso
by Parag Nemade
Hi,
Since we moved from yum-langpacks to dnf-langpacks package and yum
to dnf package in Fedora 22+ comps files, we have lost langpacks
plugin in Workstation Live iso. Till Fedora 21 we were having
yum-langpacks package available in Workstation Live iso.
I am not sure what has changed when we moved from yum to dnf but
we need this dnf-langpacks package to be added in the Workstation Live
iso. I have requested this addition against spin-kickstarts package.
See https://bugzilla.redhat.com/show_bug.cgi?id=1286527
Can Workstation WG discuss on this and add dnf-langpacks to
fedora-workstation-packages.ks file?
Regards,
Parag.
7 years, 11 months
Let's write metadata about add-ons
by Jiri Eischmann
Hi,
due to previous efforts we have a pretty good appdata coverage of apps themselves, but add-ons (plugins, extensions,...) lag far behind. There are dozens of useful GUI app add-ons in Fedora repositories which don't have metadata files and are not exposed to users in GNOME Software. Let's focus on them.
The goal of this iniciative is to have a metadata file for every useful add-on (for a GUI app) that is in Fedora repositories, so that those add-ons appear in app profiles in Software and are easily discoverable and installable for users.
For more information visit https://fedoraproject.org/wiki/Workstation/AddonAppdata
Jiri
7 years, 11 months
gnome-software --gapplication-service
by Michael Schwendt
In F23, I just had to kill the process in subject, since it had gone mad.
All I had done before was to type "soft" in GNOME Shell, then enter
the names of a few programs to check how they are displayed.
Upon checking Audacious, I noticed the uninstalled plugins. As I want one
of the plugins to be installed always, I clicked the checkbox next to it,
had to enter root password, and gnome-software started working on the
installation. So far so good. However, just a few seconds later a tiny
window opened up asking me for confirmation whether I wanted to remove the
plugin package. That made no sense to me as I had just asked the program
to install that plugin. I ran "rpm -qa --last|head" to verify that it's
installed. Then I clicked "Cancel", refusing uninstallation of the plugin
package. That made me curious. Perhaps the single click on the checkbox
was received as two clicks? I went back to check, but the box was still
marked.
Next I tried to reproduce the problem. I clicked the marked checkbox
once more to start uninstalling the plugin package. It seemed to work.
I verified via "rpm" again. Afterwards, I clicked the checkbox once more
to install the plugin again. Then I closed gnome-software.
Just a short time later, when I ran "dnf -y update" in a terminal,
another tiny window received focus, asking me again whether I wanted that
plugin package to be removed. What a surprise. I no longer was using
gnome-software at that time. I refused by clicking "Cancel". It said
that something didn't work out. Then I noticed on the Shell's activity
overview five of those tiny small windows, all asking me the same thing.
No way to close them or cancel them. Either they didn't react, or they
claimed something didn't work out. Hence I killed the process to make
them go away.
7 years, 11 months
FYI: Legal/FESCo discussion around RPMFusion
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Recommended reading: https://fedorahosted.org/fesco/ticket/1517
The original request to FESCo was for a decision on whether a package
built in COPR could `Requires: rpmfusion-foo` from RPMFusion. However,
with the new availability of weak dependencies, I've expanded the
discussion to include whether it would be acceptable in COPR or Fedora
proper to use `Recommends: rpmfusion-foo` or `Suggests: rpmfusion-foo`.
If we decide that the weak dependencies are acceptable, this would
make it much easier for users to install codecs, etc. from RPMFusion
(always assuming of course that they are legally permitted to do so
wherever they are). In effect, it would become possible to do this
easily at install-time because just adding the RPMFusion repos
manually in the installer could then result in pulling in Recommended
codecs.
I figure this is of particular interest to the Workstation SIG, so I'm
raising it here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlZ0BtYACgkQeiVVYja6o6OqMwCeKMLk/+AtuOlGrFgr32DxsnrF
frUAn0Kt7m+mA1xJltshROxdCsTuiZV5
=tzS2
-----END PGP SIGNATURE-----
7 years, 11 months
Re: Fedora Rawhide 20151216 compose check report
by Adam Williamson
On Wed, 2015-12-16 at 15:44 +0000, Fedora compose checker wrote:
> Missing expected images:
>
> Cloud_atomic disk raw x86_64
> Workstation live x86_64
> Workstation live i386
> Kde disk raw armhfp
> Kde live i386
> Kde live x86_64
>
> No images in this compose but not Rawhide 20151215
>
> Images in Rawhide 20151215 but not this:
>
> Lxde live i386
>
> Failed openQA tests: 6 of 54
>
> ID: 1073 Test: i386 universal package_set_kde
> URL: https://openqa.fedoraproject.org/tests/1073
> ID: 1072 Test: i386 universal upgrade_2_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/1072
> ID: 1071 Test: i386 universal upgrade_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/1071
> ID: 1058 Test: x86_64 universal upgrade_2_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/1058
> ID: 1056 Test: x86_64 universal upgrade_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/1056
> ID: 1043 Test: x86_64 universal package_set_kde
> URL: https://openqa.fedoraproject.org/tests/1043
So here we still have the KDE package set failures, plus we have all
the Workstation upgrade tests failing. I'm pretty sure this is why
they're failing:
<mclasen> might be a good idea to keep that gsettings-desktop-schemas
build out of rawhide until we get a shell release
<mclasen> since the old shell won't start with the new schemas
only it was too late - by the time he posted that, the new gsettings-
desktop-schemas was already in the repos. So all the Workstation
upgrade tests fail; the upgrade process itself works fine, but GDM does
not start properly in the upgraded system. i.e., we could do with a
fixed gnome-shell build ASAP :)
If we were actually getting Workstation lives, I expect they'd fail in
about the same way.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years, 11 months
Cut'n'paste with the GNOME Files app
by Michael Schwendt
Forwarding a head-scratcher problem that has come up here:
1.) Set the "Files" app to display details instead of icons.
2.) Mark a file (e.g. in 2nd "Files" window) with either "Cut" or "Copy".
3.) Open a directory that contains many files.
4.) Try to to paste the cut/copied file into that crowded directory.
=> There is no free space in the directory view where to get "Paste" in
the context menu. Everywhere one clicks it opens the context menu of
either an existant file or a directory. Even making the window larger
doesn't help.
Where to find a "Paste" method then to activate with the mouse?
As I still use Midnight Commander, I found that problem puzzling.
On the contrary, if switching back to display directory contents as icons
(no matter whether large or small icons), there is enough free space
between the icons, and at the right border of the window too, where to get
the context menu for "Paste" into current dir.
7 years, 11 months
