If you've been using GNOME 3.12 and updating packages with
gnome-software, you might have run into an issue with the update process
leaving behind a lot of duplicate packages:
This turned out to be an issue with PackageKit's Fedora packaging. It
had an rpm postun script for restarting the PackageKit daemon after an
update, but if PackageKit itself was driving the update as is the case
with updates done through gnome-software, it interrupted the whole
I've now built fixed packages for both the f20-gnome-3-12 copr and rawhide.
How To Make Everything Work Again
1) Run 'package-cleanup --dupes' -- if you are affected, it prints out a
number of packages. If the command is not installed, install yum-utils
2) Find a good time for the next step. In some cases, it can uninstall
half of your system, so don't run it 5 minutes before you have to give a
3) Run 'package-cleanup --cleandupes'
4) Update to PackageKit-0.9.2-3.fc20 with either yum or dnf:
yum update 'PackageKit*'
dnf update 'PackageKit*'
5) All done, can now resume to using gnome-software and PackageKit updates.
Hope this helps,
Just a quick heads up on the software installation front:
PackageKit in rawhide had regressed at some point and lost support for
installing multiple kernel versions in parallel. I've fixed it upstream
and built a fixed PackageKit-0.9.2-2.fc21 for rawhide, which should keep
last 3 kernel versions installed once again when using GNOME Software
for system updates.
I know several people had bricked their rawhide systems with bad kernel
updates, hopefully this can help avoid it for future updates.
According to Fedora Workstation Specifications , SELinux will be enabled
in enforcing mode, using the targeted policy.
Is this really needed for Fedora workstation? We all have faced issues
with SELinux that prevents applications to do, what are supposed to do.
Applications rarely fail with certain operations and users don't
know why their applications fail. More over not even applications
developers don't know what SELinux considers as a dangerous operation.
Some "advance(?)" users disable it anyway, less advance users don't know
why their apps fail while app developers ignore it.
In any case, I don't think SELinux has helped much our PC to be more secure.
Moreover the latest bug found on Fedora 20 with SELinux/Scriptlets made the
recovery totally impossible for many users,
and it proved (again) that SELinux isn't a really good software for desktop
and desktop users.
>From personal experience in Fedora 15 I was 2 days with an unbootable
computer cause of SELinux and NVidia, till I found out what was wrong.
In Fedora 17 (I think) Chrome wasn't working. In Fedora 19, Cassandra
I don't care if you keep it or not, since I've learned that I have to
However I would care, if I didn't know how to disable it, if I was new
Fedora user, if I wasn't interesting to read mailing lists and forums, why
things don't work.
I've recently updated gedit-code-assistance in Fedora to its latest
version, which is far more stable and powerful than the previous ones.
gedit-code-assistance is a helpful gedit plugin that will check the syntax
It will alert you if you make syntax errors, and warn you about other
coding errors - it saves you a lot of time, and makes it easier to spot
problematic areas in your code as it highlights them for you as you are
Since it's a really powerful tool for anyone who uses gedit as a code
editor, and considering the fact that the workstation PRD says the
Workstation is developer-oriented, I think it should be installed by
default in the Workstation.
I'm trying to grok how to get to try out the workstation images but I
only see them mentioned by name/reference in mail archives and on the
Is there a doc somewhere outlining how to try it out ?
Just a quick heads up that GNOME Shell's Wayland compositor should be
back in a working condition in rawhide. A few things had gotten broken
during the 3.13.1 update: mutter-launch had lost it's setuid bit and
mutter itself was crashing at startup under Wayland. There was also
nothing that would pull in required xorg-x11-server-Xwayland.
These should all be fixed, thanks to elad661's testing and drago01's
expert know-how and my monkey building of fixes they found.
If you want to test, wait for tomorrow's rawhide compose and install
Below are the initial kickstart files I have for the Workstation live
image. They started as copies of the existing Desktop files, and added
some of the packages we need like the QT and devassistant things. I've
composed a live image (1.2G) with them and it boots succesfully if you
disable SELinux (there's a bug filed for that).
How does this look as a start? The installed package list is also
fedora-live-workstation.ks | 65 +++++++++++++++++++++++++++++++++++++++
fedora-workstation-packages.ks | 70 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 135 insertions(+)
create mode 100644 fedora-live-workstation.ks
create mode 100644 fedora-workstation-packages.ks
diff --git a/fedora-live-workstation.ks b/fedora-live-workstation.ks
new file mode 100644
@@ -0,0 +1,65 @@
+# Maintained by the Fedora Workstation WG:
+part / --size 6144
+cat >> /etc/rc.d/init.d/livesys << EOF
+# disable updates plugin
+cat >> /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.updates.gschema.override << FOE
+# don't run gnome-initial-setup
+# make the installer show up
+if [ -f /usr/share/applications/liveinst.desktop ]; then
+ # Show harddisk install in shell dash
+ sed -i -e 's/NoDisplay=true/NoDisplay=false/' /usr/share/applications/liveinst.desktop ""
+ # need to move it to anaconda.desktop to make shell happy
+ mv /usr/share/applications/liveinst.desktop /usr/share/applications/anaconda.desktop
+ cat >> /usr/share/glib-2.0/schemas/org.gnome.shell.gschema.override << FOE
+favorite-apps=['firefox.desktop', 'evolution.desktop', 'empathy.desktop', 'rhythmbox.desktop', 'shotwell.desktop', 'libreoffice-writer.desktop', 'nautilus.desktop', 'gnome-documents.desktop', 'anaconda.desktop']
+ # Make the welcome screen show up
+ if [ -f /usr/share/anaconda/gnome/fedora-welcome.desktop ]; then
+ mkdir -p ~liveuser/.config/autostart
+ cp /usr/share/anaconda/gnome/fedora-welcome.desktop /usr/share/applications/
+ cp /usr/share/anaconda/gnome/fedora-welcome.desktop ~liveuser/.config/autostart/
+# rebuild schema cache with any overrides we installed
+# set up auto-login
+cat > /etc/gdm/custom.conf << FOE
+# Turn off PackageKit-command-not-found while uninstalled
+if [ -f /etc/PackageKit/CommandNotFound.conf ]; then
+ sed -i -e 's/^SoftwareSourceSearch=true/SoftwareSourceSearch=false/' /etc/PackageKit/CommandNotFound.conf
+# make sure to set the right permissions and selinux contexts
+chown -R liveuser:liveuser /home/liveuser/
+restorecon -R /home/liveuser/
diff --git a/fedora-workstation-packages.ks b/fedora-workstation-packages.ks
new file mode 100644
@@ -0,0 +1,70 @@
+# FIXME; apparently the glibc maintainers dislike this, but it got put into the
+# desktop image at some point. We won't touch this one for now.
+# This one needs to be kicked out of @standard
+# We use gnome-control-center's printer and input sources panels instead
The Workstation product is described as a "platform for development of
server side and client applications". However, the technical
specification does not include any development tools (except a Python
Based on a review of what the other working groups are doing, it seems
that we won't end up with any development tools at all in the inner
circle of Fedora.next.
I understand that all products will be delivered with the Everything
repositories enabled, so GCC, autoconf, cmake, Boost, OpenJDK, Eclipse,
and so on will all be available. But I had hoped for a curated subset
of packages which could receive additional attention (and eventually be
held to higher standards).
How can we avoid having a developer workstation that does not include
the full range of development tools?
Florian Weimer / Red Hat Product Security Team