Fedora People

Try the Dash to Dock extension for Fedora Workstation

Posted by Fedora Magazine on December 10, 2018 08:00 AM

The default desktop of Fedora Workstation — GNOME Shell — is known and loved by many users for its minimal, clutter-free user interface. However, one thing that many users want is an always-visible view of open applications. One simple and effective way to get this is with the awesome Dash to Dock GNOME Shell extension.

Dash to Dock takes the dock that is visible in the GNOME Shell Overview, and places it on the main desktop. This provides a view of open applications at a glance, and provides a quick way to switch windows using the mouse. Additionally, Dash to Dock adds a plethora of additional features and options over the built-in Overview dock, including autohide, panel mode, and window previews.


Dash to Dock adds a bunch of additional features over the dock that usually shows in the GNOME Shell overview.

The extension has an intelligent autohide feature, that hides the dock when it obscures windows. To bring the dock back up, simply move the mouse to the bottom of the screen.

<video class="wp-video-shortcode" controls="controls" height="385" id="video-23285-1" preload="metadata" width="616"><source src="https://fedoramagazine.org/wp-content/uploads/2018/11/dashtodock-autohide.webm?_=1" type="video/webm">https://fedoramagazine.org/wp-content/uploads/2018/11/dashtodock-autohide.webm</video>

Additionally, panel mode stretches the dock to take up the entire width of the screen. This is a good option for users that want to always have the dock showing, without autohiding it.

Dash to Dock also cleanly handles multiple windows of the same application. It shows small dots under each application icon to show how many windows are open. Additionally, it can be configured to show previews of each window when clicking the icon, allowing the user to choose the window they want.

Installing Dash to Dock

The quickest and easiest way to install the extension is with the Software Application. Check out the previous post here on the Magazine for more details:

How to install extensions via the Software application

<iframe class="wp-embedded-content" data-secret="EUxscBaMeP" frameborder="0" height="338" marginheight="0" marginwidth="0" sandbox="allow-scripts" scrolling="no" security="restricted" src="https://fedoramagazine.org/install-extensions-via-software-application/embed/#?secret=EUxscBaMeP" title="“How to install extensions via the Software application” — Fedora Magazine" width="600"></iframe>

Note, however, that Dash to Dock is available in both the Fedora repositories, and via the GNOME Shell extensions repository. Consequently, it will show up twice when browsing for extensions in the Software application:

Typically, the version from GNOME Shell Extensions is kept up-to-date more frequently by the developer, so that version may be the safer bet.

Configuring Dash to Dock

The Dash to Dock extension has a wide range of optional features and tweaks that users can enable and change. Some of the tweakable items include: icon size, where to position the dock (including on multiple monitors), opacity of the dock, and themes.

Accessing the settings dialog for the extension is easy. Simply right-click on the applications icon in the dock, and choose Dash to Dock settings.

Note, however, that the extension allows you to remove the applications icon from the dock. In this case, access the settings dialog via the Software Application:



Episode 126 - The not so dire future of supply chain security

Posted by Open Source Security Podcast on December 10, 2018 01:15 AM
Josh and Kurt continue the discussion from episode 125. We look at the possible future of software supply chains. It's far less dire than previously expected. It's likely there will be some change in the near future.

<iframe allowfullscreen="" height="90" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" scrolling="no" src="https://html5-player.libsyn.com/embed/episode/id/7856546/height/90/theme/custom/thumbnail/yes/preload/no/direction/backward/render-playlist/no/custom-color/6e6a6a/" style="border: none;" webkitallowfullscreen="" width="100%"></iframe>

Show Notes

OpenShift in Fedora Infrastructure

Posted by Kevin Fenzi on December 10, 2018 12:50 AM

I thought I would write up a quick post to fill folks in on what our OpenShift setup is in Fedora Infrastructure, what we are doing with it now, and what we hope to do with it in coming years.

For those that are not aware, OpenShift is the Red Hat version of OKD, which is a open source, container application platform. That is, it’s a way to deploy and manage application containers. Each of your applications can use a known framework to define how they are built, managed and run. It’s pretty awesome. If you need to move your applicaiton somewhere else, you can just export and import it into another OpenShift/OKD and away you go. Recent versions also include monitoring and logging frameworks too. There is also a very rich permissions model, so you can basically give as much control to a particular application as you like. This means the developer(s) of the applications can also deploy/debug/manage their application without needing any ops folks around for that.

Right now in Fedora Infrastructure we are running two separate OpenShift instances:One in our staging env and one in production. You may note that OpenShift changes the idea of needing a staging env, since you can run a separate staging instance or just test one container of a new version before using it for all of production, however, our main use for the staging OpenShift is not staging applications so much as having another OpenShift cluster to upgrade and test changes in.

In our production instance we have a number of applications already: bodhi (the web part of it, there is still a seperate backend for updates pushes), fpdc, greenwave, release-monitoring, the silverblue web site, and waiverdb. There’s more in staging that are working on getting ready for production.

One of the goals we had from the sysadmin side of things was the ability to be easily able to completely re-install the cluster and all applications, so we have made some different setup choices that others might. First, in order to deploy the cluster we have in our ansible playbooks one that creates and provisions a ‘control’ host. On this control host we pull a exact version of the openshift-ansible git repository and run ansible from the control host with a inventory we generate and the specific openshift-ansible repo. This allows us to provision a cluster exactly the same everytime. One the cluster is setup, we have setup our ansible repo to have the needed definitions for every application and it can provision them all with a few playbook runs. Of course this means no containers with persistent storage in them (or very few using NFS), but so far thats fine. Most of our applications store their state in a database and we just run that outside of the cluster.

Short term moving forward we plan to move as many applications as we can/make sense to OpenShift, as it’s a much easier way to manage and deploy things. We also intend to set things up so our prod cluster can run staging containers (and talk to all the right things, etc). Also we hope to run a development instance in our new private cloud. This instance we hope to open more widely to contributors for their developing applications or proof of concepts. We would like to get some persistent storage setup for our clusters, but it’s unclear right now what that would be.

Longer term we hope to run other clusters in other locations so we can move applications around as makes sense and also for disaster recovery.

I’d have to say that dealing with OpenShift has been very nice, there have been issues, but they are all logical and easy to track down, and the way things are setup just makes sense. Looking forward to 4.0!

[Short Tip] Provide dictionaries as default in Ansible variables

Posted by Roland Wolters on December 10, 2018 12:46 AM
<figure class="alignright is-resized">Ansible Logo</figure>

Ansible uses the Jinja2 template engine to handle variables. This includes the default filter, which sets a default value if a referenced variable is not explicitly defined somewhere else.

With Ansible it might happen that instead of a skalar variable a key-value is needed, a dictionary. If you just paste the plain text in there, you might run into trouble:

fatal: [test.example.com]: FAILED! => {"changed": false, "msg": "argument env is of type and we were unable to convert to dict: dictionary requested, could not parse JSON or key=value"}

The key-value pair needs to be properly formatted:

"{{ my_variable|default({'key':'value'}) }}"

Thanks to @bcoca for his post about this.

Fedora 29 : Python 3 and Jupyter notebook.

Posted by mythcat on December 09, 2018 07:23 PM
Today I tested the Jupyter Notebook with Fedora 29.
About the Jupyter Notebook the official website comes with this intro:
The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text. Uses include: data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and much more.
First I check with DNF tool the update and the upgrade of the Fedora 29 distro.
The next step was to install this:
# dnf install python3-pip
# dnf install python3-devel.x86_64
# pip3 install --upgrade pip
With my account shell I used this commands to create and run the Jupiter Notebook:
$ pip3 install --user virtualenv
$ mkdir my_project
$ cd my_project/
$ virtualenv my_project_env
$ source my_project_env/bin/activate
$ pip3 install jupiter
$ jupiter notebook
The last command will start your default browser and will see this:
You can see I created a new notebook with Python 3.
The result is shown into another tab webpage browser where I used few commands to install new module scipy and I check if this working well:
!pip3 install scipy
The result of this notebook looks like this image:

NeuroFedora update: week 49

Posted by Ankur Sinha "FranciscoD" on December 09, 2018 03:05 PM

In week 49:

There is a lot of software available in NeuroFedora already. You can see the complete list here on Fedora SCM. Software that is currently being worked on is listed on our Pagure project instance. If you use software that is not on our list, please suggest it to us using the suggestion form.

Feedback is always welcome. You can get in touch with us here.

Polkit CVE-2018-19788 vs. SELinux

Posted by Lukas Vrabec on December 09, 2018 02:52 PM

Hi All,

Last month, I wrote about Xorg X server vulnerability and we have new interesting vulnerability, now in PolicyKit.

Exploit use vulnerability when you create a user account on affected Linux systems with any UID greater than INT_MAX value, the PolicyKit component will allow you to execute any systemctl command successfully. For more info visit thehackersnews.com article.

How SELinux handle this exploit? 🙂 Let’s see.

SELinux brings very powerful feature called confined users. You are able to also confine user entities on the system. See official Fedora documentation or Blog from Dan Walsh. This feature is not enabled out of box and need to be configure on SELinux enabled system.

Let’s try PoC of the exploit in Permissive mode when SELinux security policy is not enforced:

[tester@localhost ~]$ getenforce
[tester@localhost ~]$ id
uid=4000000000(tester) gid=1012(tester) groups=1012(tester) context=user_u:user_r:user_t:s0
[tester@localhost ~]$ systemd-run -t /bin/bash

(pkttyagent:7036): GLib-GObject-WARNING **: 15:39:20.472: value "-294967296" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
ERROR:pkttyagent.c:156:main: assertion failed: (polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
Running as unit: run-u3748.service
Press ^] three times within 1s to disconnect TTY.
[root@localhost /]# id
uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:initrc_t:s0

As you can see, using PoC I can get root access with one command. Let’s repeat it with SELinux in enforcing:

[tester@lvrabec-workstation ~]$ getenforce
[tester@lvrabec-workstation ~]$ id
uid=4000000000(tester) gid=1012(tester) groups=1012(tester) context=user_u:user_r:user_t:s0
[tester@lvrabec-workstation ~]$ systemd-run -t /bin/bash

(pkttyagent:7243): GLib-GObject-WARNING **: 15:42:05.436: value "-294967296" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
ERROR:pkttyagent.c:156:main: assertion failed: (polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
Failed to start transient service unit: Access denied

[tester@lvrabec-workstation ~]$ id
uid=4000000000(tester) gid=1012(tester) groups=1012(tester) context=user_u:user_r:user_t:s0

What does it mean? SELinux technology can block this exploit! Because confined user domain (user_t) cannot start systemd services!

time->Sun Dec 9 15:43:17 2018
type=USER_AVC msg=audit(1544366597.713:2394): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { start } for auid=4000000000 uid=4000000000 gid=1012 cmdline="systemd-run -t setenforce 0" scontext=user_u:user_r:user_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system permissive=0 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?

It looks like it’s right time to confine users on your systems! 😉

Thanks @paragonsec for one-liner PoC.

The post Polkit CVE-2018-19788 vs. SELinux appeared first on Lukas Vrabec.

Održan OpenClass povodom dvadeset godina otvorenog koda

Posted by HULK Rijeka on December 08, 2018 10:14 PM

Ovaj smo tjedan održali prvi ovosezonski OpenClass povodom dvadeset godina otvorenog koda. Osobito nas veseli da su prisutni bili i studenti Sveučilišta i zainteresirani iz šire javnosti te da su i jedni i drugi nakon predavanja imali brojna pitanja.

U odjeljku OpenClass moguće je pronaći poster i prezentaciju. Audio i video snimke ovaj put nije bilo, ali nam je u planu da ubuduće bude barem onoliko kvalitetno koliko je bilo za Dan slobode dokumenata 2015.

Idući OpenClass slijedi za 14 dana, kada nas čeka proslava Dana slobode računalne grafike i računanja na grafičkim procesorima (engl. Graphics and Compute Freedom Day) 2018. Uskoro očekujte najavu.

F29-20181207 Testing Needed

Posted by Ben Williams on December 08, 2018 03:43 PM

The Fedora Respins Sig Needs help testing our F29-20181207 isos. To help join us in #fedora-respins on irc.freenode.net.  We also have a Fedora Badge to award for those whom help Test

Ben Williams

Fedora Respins Lead

Work around docker exec bug

Posted by William Brown on December 08, 2018 02:00 PM

Work around docker exec bug

There is currently a docker exec bug in Centos/RHEL 7 that causes errors such as:

# docker exec -i -t instance /bin/sh
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""

As a work around you can use nsenter instead:

PID=docker inspect --format {{.State.Pid}} <name of container>
nsenter --target $PID --mount --uts --ipc --net --pid /bin/sh

For more information, you can see the bugreport here.

FPgM report: 2018-49

Posted by Fedora Community Blog on December 07, 2018 07:34 PM
Fedora Program Manager weekly report on Fedora Project development and progress

Here’s your report of what has happened in Fedora Program Management this week. Fedora 29 elections voting is underway.

I’ve set up weekly office hours in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections or anything else.


  • bugzilla.redhat.com will be offline for an upgrade to Bugzilla 5 from 0000-1200 UTC on 9 December. See the changes page or release notes for more information. Note that this is a change from the originally-announced date.

Help wanted

Upcoming meetings

Fedora 29 Status

Fedora 30 Status

Fedora 30 includes a Change that will cause ambiguous python shebangs to error.  A list of failing builds is available on Taskotron.

Fedora 30 includes a Change that will remove glibc langpacks from the buildroot. See the devel mailing list for more information and impacted packages.



Submitted to FESCo

Approved by FESCo

The post FPgM report: 2018-49 appeared first on Fedora Community Blog.

How to automate via Travis CI publishing of new pelican pages to GitHub pages

Posted by Pablo Iranzo Gómez on December 07, 2018 03:00 PM

Table of contents


Elegant theme for pelican has been undergoing a big change from individual-driven effort to community, as part of this, one of the tasks to accomplish, has been the decoupling from author blog to project site for documentation.

As we wanted this process to be both automated and allowed us to demonstrate via dogfooding that the theme works and how it looks, the idea was to automate the rendering of pelican website with new documents.

Under the hood

Setting an automated build required several steps to be done:

  • Get a GitHub token that could be used by Travis for pushing to a repo (and configure it in Travis environment variables for the repo in a variable named GITHUB_TOKEN)
  • run unit tests for validating new PR before merging
  • configure Travis so that it downloads required dependencies in order to run pelican and then publish the generated web to the repo
  • a GitHub pages enabled repo so that resulting files can be viewed as a webpage.

One of the key pieces is a properly configured .travis.yaml like the one we started using:

language: python
dist: trusty
sudo: required

- '3.5'

- pip install -U pip
- pip install -U setuptools
- pip install -r requirements.txt
- pip install -r test-requirements.txt
- pip install peru
- peru sync
- pip install tox

- tox
- make html

- rm -rf .git/
- git init
- git config user.name "Travis CI"
- git config user.email "travis@domain.com"
- git config --global push.default simple
- git remote add origin https://${GITHUB_TOKEN}@github.com/Pelican-Elegant/pelican-elegant.github.io.git
- make github

Image setup

So, from above file we do:

language: python
dist: trusty
sudo: required

- '3.5'
  • Configure language as python
  • Select distribution
  • Confirm we require 'sudo' access
  • Configure python version as 3.5

All of this depends on Travis Image being used and their documentation

Preparation of environment

Now, we'll prepare the environment for our tests:

- pip install -U pip
- pip install -U setuptools
- pip install -r requirements.txt
- pip install -r test-requirements.txt
- pip install peru
- peru sync
- pip install tox

We do install pip, setuptools, repository and test requirements, peru and tox.

Peru is used to grab additional dependencies for elegant (plugins, latest theme, etc)

Actual tests

This is really easy in our case:

- tox
- make html

We run 'tox' that allows to automate Python virtualenv and tests and then, use the Makefile from Pelican to build the site and tests plugins, etc

If everything succeeds, we're ready for the next step (publishing)

After tests passed

All the environment setup and tests have succeed now, we do need to push the site 'live'

- rm -rf .git/
- git init
- git config user.name "Travis CI"
- git config user.email "travis@domain.com"
- git config --global push.default simple
- git remote add origin https://${GITHUB_TOKEN}@github.com/Pelican-Elegant/pelican-elegant.github.io.git
- make github

This piece does the final step, first removes info about the repo containing the actual documentation and allows us to initialize a new one, that we make it point towards the repo we're pushing (so that we keep separate actual website content from 'rendered' website).

In the final step, 'make github' uses the makefile provided with pelican to push the changes to the 'master' branch of the target repository, that then, is ready to be served via github pages as a regular web server would do.

Wrap up

So, right now we've accomplished several things:

  • We do use pelican in the same way that we'll do for our own website
    • We do also have as a consequence, a 'live' demo of latest master branch showcasing features
  • We did automate publishing of webpage as soon as contributors send new articles and are approved for merge
  • All requires no extra change to regular workflow as <travis-ci.org> is the glue here puting together all the pieces.

Hope you enjoy it!


Fedora rawhide – fixed bugs 2018/11

Posted by Filipe Rosset on December 07, 2018 01:24 PM

Bug 1579090 – cdrdao-1.2.4 is available

Update ansifilter to 2.12

Bug 1604900 – muParser: FTBFS in Fedora rawhide

Bug 1316595 – muParser-v2.2.5 is available

Bug 1448721 – [muParser] Upgrade to version 2.2.5 on epel7

Update muParser to 2.2.6

Bug 1652127 – (CVE-2018-19387) CVE-2018-19387 tmux: NULL Pointer Dereference in format_cb_pane_tabs in format.c

Bug 1652128 – CVE-2018-19387 tmux: NULL Pointer Dereference in format_cb_pane_tabs in format.c [fedora-all]

Bug 1650955 – foremost crashes due to bad fedora patch

update feh to 2.28.1

update feh to 3.1

AMI joins the LVFS

Posted by Richard Hughes on December 07, 2018 11:49 AM

American Megatrends Inc. may not be a company you’ve heard of, unless perhaps you like reading early-boot BIOS messages. AMI is the world’s largest BIOS firmware vendor, supplying firmware and tools to customers such as Asus, Clevo, Intel, AMD and many others. If you’ve heard of a vendor using Aptio for firmware updates, that means it’s from them. AMI has been testing the LVFS, UpdateCapsule and fwupd for a few months and is now fully compatible. They are updating their whitepapers for customers explaining the process of generating a capsule, using the ESRT, and generating deliverables for the LVFS.

This means “LVFS Support” becomes a first class citizen alongside Windows Update for the motherboard manufacturers. This should trickle down to the resellers, so vendors using Clevo motherboards like Tuxedo get LVFS support almost for free. This will take a bit of time to trickle down to the smaller OEMs.

Also, expect another large vendor announcement soon. It’s the one quite a few people have been waiting for.

PHPUnit 7.5

Posted by Remi Collet on December 07, 2018 10:02 AM

RPM of PHPUnit version 7.5 are available in remi repository for Fedora ≥ 26 and for Enterprise Linux (CentOS, RHEL...).

Documentation :

emblem-notice-24.pngThis new major version requires PHP ≥ 7.1 and is not backward compatible with previous versions, so the package is designed to be installed beside version 5 and 6.

Installation, Fedora:

dnf --enablerepo=remi install phpunit7

Installation, Enterprise Linux:

yum --enablerepo=remi install phpunit7

Notice: this tool is an essential component of PHP QA in Fedora. This version will quickly be available in Fedora 29.

PHP version 5.6.39, 7.0.33, 7.1.24 and 7.2.12

Posted by Remi Collet on December 07, 2018 07:08 AM

RPM of PHP version 7.2.13 are available in remi repository for Fedora 28-29 and in remi-php72 repository for Fedora 26-27 and Enterprise Linux  6 (RHEL, CentOS).

RPM of PHP version 7.1.25 are available in remi repository for Fedora 26-27 and in remi-php71 repository for Enterprise Linux (RHEL, CentOS).

RPM of PHP version 7.0.33 are available in remi-php70 repository for Enterprise Linux (RHEL, CentOS).

RPM of PHP version 5.6.39 are available in remi-php56 repository for Enterprise Linux.

emblem-important-2-24.pngPHP version 5.5 have reached its end of life and is no longer maintained by the PHP project. These versions are the last for PHP 5.6 and 7.0. PHP 7.1 enters security only support.

These versions are also available as Software Collections in the remi-safe repository.

security-medium-2-24.pngThese versions fix a few security bugs, so update is strongly recommended.

Version announcements:

emblem-notice-24.pngInstallation : use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 7.2 installation (simplest):

yum-config-manager --enable remi-php72
yum update php\*

Parallel installation of version 7.2 as Software Collection (x86_64 only):

yum install php72

Replacement of default PHP by version 7.1 installation (simplest):

yum-config-manager --enable remi-php71
yum update

Parallel installation of version 7.1 as Software Collection (x86_64 only):

yum install php71

And soon in the official updates:

emblem-important-2-24.pngTo be noticed :

emblem-notice-24.pngInformation, read:

Base packages (php)

Software Collections (php56 / php70 / php71 / php72)

How Fedora’s Wallpaper Are Made

Posted by Sirko Kemter on December 07, 2018 05:47 AM

I am now member of the Design Team more then 10 years and had my hands in, in many off the fedora wallpaper. Over the years the Design Team developed a way to be creative and come up with a unique design for each release. This way was build around the release names, yes it became harder, how funnier the release names became. For Fedora 20 aka Heisenbug, there was no idea how this name could be represented. So this wallpaper was build with the number of the release 20 and his latin representation XX. Then the council disabled the code names, what put the Design Team into a little crisis, we tried to work furthermore with the numbers but except for Fedora 24 (which represents 24 hours of a day) not work. So a solution was needed.
Since Fedora 25 I running a small voting among the Design Team, giving a few names of inventors/discoverer. This is not the same as code names, as we use it only as an creative starting point. Nevertheless there are always people outside the team taking the vote (and they vote mostly just because they find the name cool and have no eye what can be done with)



Archimedes, Al-Battani and Armstrong been the choices for this version, and Archimedes won very clear. And so the wallpaper bases on a design of an archimedian spiral, maybe you can see it now.


Alexander Graham Bell

For Fedora 26 Charles Babagge, George Beauchamp and Alexander Graham Bell as inventor of the telephone been the choices and Bell won the voting. But how do you come from telephone to a line of trees? Take a closer look, the line of trees is nothing else as a waveform of a spoken word, here Fedora. Isnt that genius?


Jaques Cousteau

Jaques Cousteau came out as the favorite for Fedora 27, the other choices been Nicolas-Joseph Cugnot and Vladimir Nikolayevich Chelomey. And so the beautiful jellyfish design was created.


Emily C. Duncan

For Fedora 28, Mo requested the change one of the person shall be a woman (thats a bit problematic as there are lesser woman inventors outside. Since then we have 4 options to choose from. Giovanni de Dondi, Arvid Gerhard Damm, Georges Darrieus and Emily C. Duncan. Emily C. Duncan did win, the concept of the artwork bases of “information travelling down/up wires”.


Gertrude B. Elion

As I was not available for wrangling the Fedora 29 inspiration, Mo suggusted relative late to go with Gertrude B. Elion and so the wallpaper was made on a concept of hexagons representing cells.


Augustin-Jean Fresnel

For the upcoming Fedora version 30, we held the voting and there been Federico Faggin, Rosalind Franklin, Sandford Fleming and Augustin-Jean Fresnel the options. The team decided to go with Fresnel, so you can be curious with what we come up.

Some closing words, as I said before there are always people who read the mail on the list and vote, even they are not member of the team. That would be fine, but there is one thing, they always vote because they find the invention cool or the name but this doesnt help the Design Team. This is a two-sided thing I have spoken about this a while ago with Mo, the people have interest to “contribute” into such a voting but as said, its not helpful in this way for the team itself. I have an idea how to solve this problem, maybe there is room to hack the needed thing together during next GSoC.

Fedora rawhide – fixed bugs 2018/10

Posted by Filipe Rosset on December 07, 2018 01:12 AM

Bug 1554395 – tmux tab display on fedora it is related to /etc/bashrc

Bug 1615933 – tmux crash with coredump possibly because of window resize grid_get_cell1 grid.c

Bug 1631015 – In text mode, strange behaviour of help pages

Bug 1381509 – RFE: dash for EPEL

bindfs – update to new version 1.13.10

Bug 1559823 – [abrt] ranger: exit(): img_display.py:86:clear:BrokenPipeError: [Errno 32] Broken pipe (edit)

Bug 1495481 – Search not working in ranger (edit)

Bug 1592733 – Need ranger updated to newest version (edit)

Bug 1408563 – ranger-1.9.1 is available (edit) [NEEDINFO]

Bug 1543425 – update chocolate-doom to 3.0.0

Bug 1555763 – ghasher: FTBFS in F28

Bug 1604078 – ghasher: FTBFS in Fedora rawhide

Update pogo to 1.0

Update ansifilter to 2.11

Bug 1563149 – highlight: Partial Fedora build flags injection

Bug 1611359 – Man page scan results for highlight

Bug 1630845 – Coverity/cppcheck scan reports issues

Bug 1438979 – feh-2.27.1 is available

Bug 1444077 – CVE-2017-7875 feh: Integer overflow in wallpaper.c while receiving an IPC message [fedora-all]

Bug 1602421 – feh no longer depends on giblib

Update converseen to version

Update linsmith to new upstream version 0.99.31 + spec cleanup and modernization

Bug 1583880 – linsmith-0.99.31 is available

Bug 1589549 – [abrt] linsmith: sprintf(): linsmith killed by SIGABRT

Update pdf2djvu to version 0.9.11

Bug 1283552 – Segmentation fault / not working

Bug 1540683 – [abrt] disper: XQueryExtension(): python2.7 killed by SIGSEGV

Bug 1577523 – [abrt] disper: XQueryExtension(): python2.7 killed by SIGSEGV

Bug 1603791 – disper: FTBFS in Fedora rawhide

Update homebank to 5.2.2

bbkeys – spec cleanup and modernization

64tass – spec cleanup and modernization

glog – spec cleanup and modernization

update python-empy to 3.3.3 (epel7)

Fedora rawhide – fixed bugs 2018/09

Posted by Filipe Rosset on December 06, 2018 09:01 PM

Bug 1574484 – aime-8.20180501 is available

Bug 1605788 – python-myhdl: FTBFS in Fedora rawhide

Bug 1592156 dgit-6.11 is available

Bug 1611876 – vcftools-v0.1.16 is available

Bug 1574279 – sakura-3.6.0 is available

Bug 1603487 – bindfs: FTBFS in Fedora rawhide

Bug 1615175 – byobu-5.127 is available

Bug 1554395 – tmux tab display on fedora it is related to /etc/bashrc

Bug 1609442 – pdf2djvu-0.9.10 is available

Bug 1578595 – aime-8.20180811 is available

Bug 1613080 – converseen-0.9.7 is available

Bug 1606901 – pyexiv2: FTBFS in Fedora rawhide

Bug 1579346 – worker-3.15.1 is available

Bug 1606703 – worker: FTBFS in Fedora rawhide

Bug 1603994 – fotowall: FTBFS in Fedora rawhide

Bug 1604068 – genbackupdata: FTBFS in Fedora rawhide

Bug 1603385 – aoetools: FTBFS in Fedora rawhide

Bug 1405782 – vile-9.8s is available

Bug 1604508 – klatexformula: FTBFS in Fedora rawhide

Bug 1603433 – atop: FTBFS in Fedora rawhide

Bug 1606840 – unclutter: FTBFS in Fedora rawhide

Bug 1606321 – scummvm: FTBFS in Fedora rawhide

Bug 1606762 – xwax: FTBFS in Fedora rawhide

Bug 1370846 – xwax-1.7 is available

Bug 1604612 – libmimedir: FTBFS in Fedora rawhide

Bug 1556052 – libmimedir: FTBFS in F28

Bug 1552361 – tiled-1.1.6 is available

Bug 1634209 – dgit-6.12 is available

Closed bugs:
Bug 1542808 – snapraid-v11.2 is available

Élections pour le Conseil, FESCo et Mindshare cette semaine

Posted by Charles-Antoine Couret on December 06, 2018 08:50 PM

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au vendredi 21 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.


Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.


Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège. Ici 5 places sont à remplacer.


Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

  • La communication entre les équipes, notamment entre la technique et le marketing ;
  • Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
  • Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
  • Gestion de l'équipe marketing.

Il y a 9 membres pour gérer ce nouveau comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.

PHP version 7.3.0 is released!

Posted by Remi Collet on December 06, 2018 04:15 PM

RC6 was GOLD, so version 7.3.0 GA is just released, at planed date.

A great thanks to all developers who have contributed to this new major and long awaiting version of PHP and thanks to all testers of the RC versions who have allowed us to deliver a good quality version.

RPM are available in the remi-php73 repository for Fedora  27 and Enterprise Linux  6 (RHEL, CentOS) and as Software Collection in the remi-safe repository.

RPM are also available in the php:remi-7.3 module for Fedora 29 and Enterprise Linux 8 Beta.

Read the PHP 7.3.0 Release Announcement.

emblem-notice-24.pngInstallation : read the Repository configuration and choose installation mode, or follow the Configuration Wizard instructions.

Replacement of default PHP by version 7.3 installation (simplest):

Fedora 29 or Enterprise Linux 8 Beta :

dnf module install php:remi-7.3

Other distribution versions:

yum-config-manager --enable remi-php73
yum update php\*

Parallel installation of version 7.3 as Software Collection (x86_64 only, recommended for tests):

yum install php73

emblem-important-2-24.pngTo be noticed :

  • EL7 rpm are build using RHEL-7.5
  • EL6 rpm are build using RHEL-6.10
  • this version will be the default version in Fedora 30, see PHP 7.3
  • all extensions are already available, see the PECL extension RPM status page

emblem-notice-24.pngInformation, read:

Base packages (php)

Software Collections (php73)

Fedora 29 : Shotcut video editor.

Posted by mythcat on December 06, 2018 11:15 AM
Today I tested the new software video editor for Fedora 29.
This video editor is named Shotcut and come with a new released 18.11.18 available here.
This Linux tool come for many operating systems and is a good video editor
I download and unarchive this software from the official website.
The first error comes from libnsl packages but finally, all worked well.
[mythcat@desk Shotcut]$ cd Shotcut.app/
[mythcat@desk Shotcut.app]$ ll
total 80
drwxr-xr-x. 2 mythcat mythcat 89 Nov 19 01:08 bin
-rwxr-xr-x. 1 mythcat mythcat 35147 Nov 18 23:53 COPYING
-rwxr-xr-x. 1 mythcat mythcat 779 Nov 19 01:10 ffmpeg
-rwxr-xr-x. 1 mythcat mythcat 779 Nov 19 01:10 ffplay
-rwxr-xr-x. 1 mythcat mythcat 782 Nov 19 01:10 ffprobe
drwxr-xr-x. 8 mythcat mythcat 8192 Nov 19 01:10 lib
-rwxr-xr-x. 1 mythcat mythcat 773 Nov 19 01:10 melt
-rwxr-xr-x. 1 mythcat mythcat 776 Nov 19 01:10 qmelt
drwxr-xr-x. 13 mythcat mythcat 163 Nov 19 01:10 share
-rwxr-xr-x. 1 mythcat mythcat 759 Nov 19 01:10 shotcut
-rwxr-xr-x. 1 mythcat mythcat 899 Nov 19 01:10 source-me
-rw-r--r--. 1 mythcat mythcat 802 Nov 19 01:10 versions
[mythcat@desk Shotcut.app]$ ./shotcut
bin/shotcut: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory
[root@desk Shotcut.app]# dnf install libnsl
Last metadata expiration check: 0:23:04 ago on Thu 06 Dec 2018 12:31:08 PM EET.

The result can be see into the next screenshot:

Play with NFC HAT I

Posted by Zamir SUN on December 06, 2018 10:29 AM

The other day I got an NFC HAT for SBC to play with. And I started to play with it on my Raspberry Pi last week.

Things did not go smoothly, which is expected. But some part of it still goes beyond my expection.

So what’s it? It’s a NFC development board based on NXP PN7150. You can buy it from taobao. It’s header is compatible with Raspberry Pi, and minimal modification to use with Salted Fish Pi. As I already have Raspberry Pi 1/2/3, I simply plug it onto Raspberry Pi 2 running with Fedora.

As I have little knowledge with hardware, I started directly with reading the documentation and assume simply follow it will work, which is proven to be wrong.

So, I compiled linux_libnfc-nci, on my RPI2, and it simply do not work. Then I found the i2c-dev module is not loaded during boot time. Then I load the module and tried again, still do not work. And I just realized I don’t have /sys/class/gpio on my system.

I checked the kernel config, no wonder, CONFIG_GPIO_SYSFS is not set. I searched and realized the GPIO sysfs is marked as deprecated in mainline kernel, so Fedora decide to disable it. Instead, the GPIO char device are suggested. However, the linux_libnfc-nci project do not support GPIO char device yet.

The first thing that came into my mind is to compile the support as a out-of-tree module. I did not realize it is not possible untile I tried 3 times, and then I start to check the dependency by manually make oldconfig. Hmm, it told me ‘m’ is not supported for this config.

As a result, I have to compile my own kernel temporary with the config enabled. And I have compiled a 4.19.7-300 one here.

Now I can start play with it, and possible think of how to get char device supported.

Mindshare Election: Interview with Jared Smith (jsmith)

Posted by Fedora Community Blog on December 06, 2018 12:15 AM

This is a part of the Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Jared Smith (jsmith)

  • Fedora Account: jsmith
  • IRC: jsmith (found in #fedora-devel, #fedora-arm, #fedora-iot, #fedora-docs, #fedora-mindshare)
  • Fedora User Wiki Page


Is there a specific task or issue you think that Mindshare should address this term?

My number one goal for this term in Mindshare is to finish documenting and socializing the new plans for low-friction release parties, low-friction swag requests, and Emeritus ambassadors. While the last term was important in terms of planning changes, I think the focus of this next term should be communicating those changes to the community at large.

Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare.

I’ve spent a lot of time in the Fedora community, and the number one complaint I hear at Fedora Events is the ambassadors program. Even though it’s been a great program, it also causes an undue amount of stress and friction. I’d like to do my part to help reduce that, and help work some of the “wrinkles” out of the system.

What are your thoughts on the impact (as an individual and then as a Mindshare group) that the group will have?

Let me speak to the group as a whole, first. As a group, the Mindshare team will be successful if they can communicate clearly with the community, and show the results of their work. Individually, I hope to be able to dedicate more of my personal time to pushing those efforts, especially with regards to communications with the broader Fedora community.

The post Mindshare Election: Interview with Jared Smith (jsmith) appeared first on Fedora Community Blog.

Mindshare Election: Interview with Luis Bazan (lbazan)

Posted by Fedora Community Blog on December 06, 2018 12:15 AM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Luis Bazan (lbazan)

  • Fedora Account: lbazan
  • IRC: LoKoMurdoK (found in #fedora-fedora-latam #fedora #fedora-pa)
  • Fedora User Wiki Page


Is there a specific task or issue you think that Mindshare should address this term?

Keep working hard in the regions maintaining a constant communication with the active ambassadors, in order to receive comments from each region.

Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare.

  • My motivation is all the team, the community, work as a team!
  • I have worked closely with the ambassadors and I like to listen to their ideas.
  • I’m very excited about this opportunity because I feel that my skills and knowledge are very well lit to be candidate for Mindshare.

We could motivate and help more people in and out of the Fedora community to contribute as a team.

What are your thoughts on the impact (as an individual and then as a Mindshare group) that the group will have?

As individual, I think that I can share my ideas, experience and knowledge to contribute that the council makes good decisions in the different aspects of the community.

As Mindshare group, we must encourage more the community members to share their ideas with the Mindshare group and/or their ambassadors.

The post Mindshare Election: Interview with Luis Bazan (lbazan) appeared first on Fedora Community Blog.

Mindshare Election: Interview with Ricardo Martinelli de Oliveira (rimolive)

Posted by Fedora Community Blog on December 06, 2018 12:15 AM

This is a part of the Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Ricardo Martinelli de Oliveira (rimolive)


Is there a specific task or issue you think that Mindshare should address this term?

Nothing so far.

Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare.

I’d like to do more for the Fedora project and I want to see more participation of Latin American contributors for the project.

What are your thoughts on the impact (as an individual and then as a Mindshare group) that the group will have?

Nothing comes to my mind at this moment, but if elected you will see a very motivated person with a lot to contribute.

The post Mindshare Election: Interview with Ricardo Martinelli de Oliveira (rimolive) appeared first on Fedora Community Blog.

FESCo Election: Interview with Owen Taylor (otaylor)

Posted by Fedora Community Blog on December 06, 2018 12:10 AM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Owen Taylor (otaylor)

  • Fedora Account: otaylor
  • IRC: otaylor (owen on GIMPNet) (found in #fedora-workstation #fedora-admin #fedora-devel #flatpak)
  • Fedora User Wiki Page


Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

The Fedora project has been moving decisively in the direction of increased flexibility and diversity – with Modularity, with new distribution mechanisms and formats like ostree and containers. One of our big challenges is to able to take advantage of all this flexibility and still provide a stable, easy to understand experience to our users. I’ve been involved in desktop Linux from the days of editing your window manager and XFree86 configuration manually to the current point where have slick desktop environments that just work. I’m familiar not just with the technology, but also the design processes we’ve developed, and the tricky balancing act between keeping things streamlined and accommodating the needs of advanced users.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

There is a lot of work currently going on in Fedora to separate out the operating system layer from the application layer – Fedora CoreOS, Fedora Silverblue, and our container and Flatpaks efforts all represent aspecs of this. FESCo should be continually keeping these ways of consuming Fedora in mind.

A personal interest of mine is how developers work in these new models – how do Fedora users develop their applications, and how do Fedora developers develop Fedora. Our traditional model, where the operating system and applications emerge from a great big sea of packages gives a ton of flexibility, and once you move away from it, it feels a bit like putting handcuffs on, but I think there’s a lot of value to be found for developers as well – to be able to have different development setups for different applications, and to be able to try out operating system changes in ways that are well contained and easily reverted.

At times, it seems like FESCo can get a bit bogged down in the nuts-and-bolts of fixing the operating system – and while that’s essential work, I’d hope that some of that work can be delegated and FESCo can concentrate a bit more on high-level issues and what Fedora needs to do as a project to enable a better operating-system / application split.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

I think it’s generally agreed that the weakest part of our process is the “compose” step – taking the bits we create and making an operating system image out of them, reliably and quickly. Not only does this hamper our ability to fix bugs, it is a huge limitation in our ability to do integration testing – any packager who wants to update a system image or component should be able to get tests run on the entire operating system with their component included. In fact they should be required to get such tests run. I think there are some good efforts out their to improve things – FESCO can help out by directing focus towards those efforts and by continually pushing back when a “broken operating system” problem comes up – not just helping out with an immediate fix but figuring out why it wasn’t caught by automated testing.

The post FESCo Election: Interview with Owen Taylor (otaylor) appeared first on Fedora Community Blog.

FESCo Election: Interview with Kevin Fenzi (kevin)

Posted by Fedora Community Blog on December 06, 2018 12:10 AM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Kevin Fenzi (kevin)

  • Fedora Account: kevin
  • IRC: nirik (found in #fedora, #fedora-admin #fedora-apps #fedora-noc #fedora-devel #fedora-releng)
  • Fedora User Wiki Page


Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

Moving faster, adding CI and testing, LTS support will all be big issues in Fedora in the upcoming year or two (at least). We really need to automate as much as we can so we can support new ideas while not overworking all our maintainers and community. I have a lot of the historical background on why things were the way they were, but I am also pretty open to change and moving forward when it makes sense to do so.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

Automation and CI. The only way we will keep up with all the software our there is if we automate things and get robots to do testing all the time. Otherwise we just won’t scale.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

We definitely need to still work on maintainer workflows. Many of these were disrupted to bring in arbitrary branches and modularity, and I think we can smooth things out a good deal. We need to make it easier to maintain things.

The post FESCo Election: Interview with Kevin Fenzi (kevin) appeared first on Fedora Community Blog.

FESCo Election: Interview with Aleksandra Fedorova (bookwar)

Posted by Fedora Community Blog on December 06, 2018 12:10 AM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Aleksandra Fedorova (bookwar)


Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

We are moving towards more flexible and varied ways of delivering the software. And this flexibility is going to become an issue on its own.

On a technical side, extended list of deliverables requires extended testing effort which is hard to achieve via semi-manual workflows. As a CI Engineer and member of Fedora CI Working Group I want to make sure that CI effort is aligned with current engineering goals. And while we work on improving the CI infrastructure and user experience we also find the ways to incorporate CI in the development process.

Now from the process and policy point of view, as a former DevOps Engineer, I have worked on the “other” side – in cloudy environments flexible to the point of becoming chaotic. And while I believe that there are things Fedora needs to catch up with in terms of modern development practices, there are a lot of things “modern practices” need to catch up with in terms of processes and workflows, which are widely known and established in the Linux distributions world.

I hope that bringing this perspective to FESCo would help us find the right balance between providing the flexible tooling and keeping the solid foundation for it to be usable

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

It may sound odd, but I would say that one of the big goals of FESCo and Fedora community in general is to prevent Fedora from becoming stable. In this case by stable I mean “freezed” not “free of bugs”.

We need it to be easy to change things, even most core features. We need certain loose ends hanging for everyone to come and take care of.

One of the objectives to achieve that big goal is to provide people with the toolchain and services to make their own unique flavors of Fedora or on top of Fedora. Custom repositories, modules, images, flatpaks… you name it. And we need it to be a self-service available for any contributor to use. We should provide pieces for community to play, build and create.

The other complementary thing is actually CI. While many believe that Continuous Integration is there to prevent people from changing things (it does prevent you from merging changes sometimes), the actual reason why we need CI is to allow more changes coming in. CI (and test automation) gives you the freedom to take in changes which otherwise look unusual, or risky. It allows you to focus on whether or not the change is reasonable and brings any value, rather than worry if it might break something.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

Additionally to the topics above one of the troubling issues in Fedora is the lack of open collaboration on the package maintenance side. Traditionally, changes in package specs happen locally in a private environment, and community can only interact with the outcome of the change via karma or bug reports. It is very hard for people to contribute and actively help the maintainer especially when they don’t have the packager status themselves.

We have already done a lot to improve this situation. The open pull-requests workflow, which is available on Pagure already, being one of those big steps. But there is more to it. CI, again, could help here as via early integration we encourage maintainers of dependent packages to work closely and discuss the changes happening in interacting packages early in the development phase, and to actually contribute into each other’s test suites.

The post FESCo Election: Interview with Aleksandra Fedorova (bookwar) appeared first on Fedora Community Blog.

FESCo Election: Interview with Fabio Valentini (decathorpe)

Posted by Fedora Community Blog on December 06, 2018 12:10 AM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Fabio Valentini (decathorpe)


Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

There’s been a lot of discussion about the compose (and release) process recently. While I don’t necessarily always agree with the motivation, I think improving the compose process would be crucial for the future. Speed is one measure, but it’s not the most important one in my opinion. I’d rather focus on making the process more reliable (and possibly even reproducible) to avoid issues like deliverables (possibly randomly) missing from composes (even the GOLD one, like what happened for fedora 29). I’d push for making the processes more reliable first, and optimize later (“premature optimization is the root of all evil”).

Another focus should be placed on how the Modularity effort is moving forward. While I see big benefits in some areas, especially server environments (I’ve read about efforts to make the different NodeJS versions supported by upstream concurrently available as modules), I don’t think it is suited for solving problems in the “desktop” use case, since there are a lot more (indepentently) moving parts involved.

With respect to the “release cadence” discussion that has erupted recently, I’d rather support a tick-tock cycle with annual “major” releases (e.g. fedora 2019.0) and a “minor” release (e.g. fedora 2019.1), where effort for “major” changes isn’t constrained to 5 months, but rather 11. Another possibility would be to just treat GNOME like other packages and do updates during releases (like KDE), which would make the “tock” minor releases unnecessary (many packagers already do updates like this, GNOME is rather an exception here).

By extension, a modified release cadence like this would result in a almost double the support period for major fedora releases (if we keep 2 major supported releases around, just like now), or reduce the number of supported fedora releases by one (if we keep the support period the same) – which other, recent discussions about the fedora release cadence have mentioned.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

Since I don’t think that we can (or should!) “grow” fedora by fundamentally changing what it means to be the linux distribution “fedora”, I’d rather focus on improving upon the strengths fedora already has:

  • Continue to be a great platform to develop software on: Since “developers and makers of any kind” are the core audience of fedora Workstation, focusing on this area could make fedora not only a good, but a better, or even an excellent choice for software developers.
  • Continue delivering updated software stacks in a stable manner: GCC, python, ruby, golang, etc. all make up a compelling development environment. This probably means that a “development base” containing the latest stable versions of these components would have to be released at least anually – which is why I think the idea of a true “fedora LTS” is a contradiction in terms. Fedora is supposed to be first, after all. However, an argument for moving “major” (development) platform updates to an annual cycle could be the possibly longer support window for major releases, since “minor” updates wouldn’t obsolete the “core development platform”. This would also benefit server deliverables due to the possibly longer support window for the stable “core”.
  • Continue making upgrades to new fedora releases as painless as they are now: Maybe “upgrades” can even be treated as “big updates” one day, bringing even more people up-to-date, and delivering more features first faster.

We all know that the development and release model of fedora has its drawbacks, too. Improving upon the “pain points” would be my preferred way forward, instead of throwing everything that alread works out the window. After all, the current model has served us well for many ears.

  • Reduce likelihood of compose and release issues: (Automated) update gating for rawhide; improved enforcement (and/or automation) of rules around SONAME bumps/API and ABI breaks/mass rebuilds.
  • Possibly adapt the release schedule: Development and release engineering resources could be allocated more efficiently to the areas that really need attention, instead of just putting out the latest fire (again).

This could possibly mean moving to ONE annual release (I’d only agree with this if more components would be updated mid-release, for example GNOME), or moving to a tick-tock “major”-“minor” release cycle with one annual “major” release – to pick up updated language toolchains and make infrastructure changes – and one (or more?) “minor” release(s) to update things atop this stable “core”. I don’t think we need modularity for this, since only one set of packages would be supported to run on a “major release” at a time.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

I think an area that could really be improved is the way some changes (be it “Changes” or major package updates being pushed) are introduced to fedora. For example, I find it hilarous that every release there’s a need for a GNOME mega-update and a corresponding freeze exception, just because the release schedules don’t match up. Moving the target date for a fedora release to avoid situations like this could even reduce release date postponements (which has improved over the years, but it’s still kind of a meme that fedora never releases on time).

I’d also suggest being more conservative with accepting changes – I’d like to see more testing before something big lands in rawhide (e.g. dbus-broker transition, redhat-rpm-macros changes for build flags, macros, etc.). Update gating can help with that, doing test rebuilds in koji side tags (and maybe even test composes for the biggest changes) could help too. Related to this, I’d also promote the usage of koschei, and just add all existing packages to be tracked automatically. I’ve already caught multiple issues by relying on koschei for my packages, and I’m always surprised by how small the number of tracked “core” packages is.

I also increasingly see some packages (mostly podman/buildah/runc/etc.) basically using fedora rawhide as their CI system with bot-created snapshot builds being submitted to koji. While I didn’t find a policy that explicitly disallows this, I think it’s against the spirit of the Updates Policy, even for rawhide – since there’s no way that automatically submitted builds can be verified to conform the Updates Policy criteria. For example, “don’t push clearly broken builds”, or “announce API/ABI changes a week in advance” just isn’t satisfiable with bot-submitted snapshot builds. To reduce the likelihood of broken packages in fedora, I’d amend the Updates Policy to explicitly state that – basically – “rawhide isn’t a CI system”. (This point doesn’t apply to GCC, glibc, and kernel snapshots though – they are already explicitly allowed, and they are submitted by a human who knows very well what they are doing.)

The post FESCo Election: Interview with Fabio Valentini (decathorpe) appeared first on Fedora Community Blog.

FESCo Election: Interview with František Zatloukal (frantisekz)

Posted by Fedora Community Blog on December 06, 2018 12:10 AM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with František Zatloukal (frantisekz)

  • Fedora Account: frantisekz
  • IRC: frantisekz (found in #fedora-qa , #fedora-devel, #fedora-noc, #fedora-releng )
  • Fedora User Wiki Page


Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

I believe Fedora is going to have to face issues in areas like Silverblue, Modularity, wider Flatpak adoption and so on. All this is it’s kind of “reinventing” some core concepts of traditional Linux Distribution. However, I see this as an amazing opportunity for Fedora … to distinguish itself more from others.

The Idea behind Silverblue is a true revolutionary concept in Linux Desktop area and Fedora is leading the way while leaving other Distributions far behind. Light core systems, applications contained in flatpaks, “de-facto” instant upgrades and updates, being able to boot an older tree if something goes south… I am really excited for this.

Not to speak just about Silverblue, one more area that we should pay attention is proposed Fedora LTS. This, if done correctly, could bring Fedora to many more people as pre-installed OS. I see this as a huge challenge, not to overwhelm package maintainers and not to slow Fedora’s leading edge pace.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

I see some areas which FESCO should focus on in following months. Recently opened up discussions around delaying Fedora 31 in order to refine and improve the way we release Fedora is definitely one of them. The vision of fast composing, decoupled spins so anything new can be tested right away instead of waiting 8 hours or more sounds great to my Fedora QE ears 🙂 .

Apart from Silverblue, I believe Modularity is also a way forward. Something that, if spread across more packages, could make Fedora an obvious choice for Server deployment.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

I’ve mentioned one of these in previous answer. How could FESCO help here? One of the ways is to improve and accelerate the communication between teams. From top of my head, i see some opportunities in tighter collaboration between QE and Marketing/Websites. I believe there are many more areas which Fedora could do better and it might make sense to invest some time and investigate it more.

The post FESCo Election: Interview with František Zatloukal (frantisekz) appeared first on Fedora Community Blog.

FESCo Election: Interview with Zbigniew Jędrzejewski-Szmek (zbyszek)

Posted by Fedora Community Blog on December 06, 2018 12:10 AM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Zbigniew Jędrzejewski-Szmek (zbyszek)

  • Fedora Account: zbyszek
  • IRC: zbyszek (found in #fedora-devel, #systemd, #fedora-python)
  • Fedora User Wiki Page


Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

The biggest problem I see currently is the introduction of Modularity and the related changes causing a slowdown of development in other areas. There are three important aspects: first, it is a complicated topic that brings a whole set of new concepts, tools, techniques, and bugs, and packagers and users both have to get acquainted with modules, which takes time and effort. Second, the roll-out of modularity, e.g. integration in dnf and other package managers, is still far from great. Third, many smart people at the core of the distribution are diverting from other activities to work on this. I hope that with F30 most of those issues will be figured out and we can reap the benefits.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

The way we do packaging is evolving all the time. We have Modularity, and we are right now facing questions how to make it generally usable, without abandoning external users and redistributors of our packages. There are various proposals how to evolve packaging to cater to go and rust and modern python packaging, to allow maintainers to manage packages semi-automatically, more in line with native package management in those languages. I hope FESCo can coordinate these efforts to allow things to “happen”, but in a way that the needs of all stakeholders are taken into account.

I’m not convinced by the recent proposals to delay F31 to work out the releng and pipeline and tooling challenges. I do see many things that need to be improved, but most of them are independent of the release cycle, and can be worked at any time. It seems that currently too much depends on the core releng team, and I hope we some of those responsibilities can be devolved, and others automatized. In this and other areas, I would love to see more freedom for “fly-by” contributions, like proven packagers do for spec file maintenance and anyone can get involved in the freeze testing and bug zapping process.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

Communication between different teams is, as always, an issue. I think all our teams are doing an excellent job, but there’s always more need for transparency and exchange of information. I hope FESCo can improve it’s procedures to invite stakeholders earlier and more consistently.

There’s a number of processes that don’t seem to be happening or are only happening through manual efforts, without automatization. Cleanup of FTBFS, orphaned, and insecure packages, package ownership reassignments, notifications about missing dependencies. We are still recovering from pkgdb removal. We need to automatize those things again to make everything run a little smoother, and to avoid burnout from releng members.

The post FESCo Election: Interview with Zbigniew Jędrzejewski-Szmek (zbyszek) appeared first on Fedora Community Blog.

FESCo Election: Interview with Justin Forbes (jforbes)

Posted by Fedora Community Blog on December 06, 2018 12:10 AM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.

Interview with Justin Forbes (jforbes)

  • Fedora Account: jforbes
  • IRC: jforbes (found in #fedora-kernel #fedora-devel #fedora-qa #fedora-arm)
  • Fedora User Wiki Page


Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

Fedora is a constantly evolving distribution. Fedora 29 is not just Fedora Core 1, or even Fedora 20 with newer package versions. Big changes happen, and they are typically for the better, but how they are introduced has to be mindful of existing contributors, users, and use cases. Modularity continues to be a major initiative, with a lot of benefits, but also plenty of pitfalls to avoid. We also have the ideas around release cycle, and how Fedora can improve the release process to keep managing things going forward without constant duct tape and string holding it all together. It is often heroic efforts that make a release come together, but that can be improved upon.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

There is really a long list of details, but it can be all be summarized with “ensure our processes for introducing new technologies are managed in such a way as to not alienate existing contributors, users, and use cases, while publishing stable releases with useful new features”

This includes things like:
Improving our QA processes
Taking the time improve our release process
Ensuring new changes are ready before wedging them into a release
Making sure changes are not too disruptive to existing workflows.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

I am afraid Rel-eng is going to crack at some point. The load they have taken on is massive. It has come in the form of little things here and there that have mounded up to a difficult workload to manage. FESCo needs to both come up with a way to help make it more manageable (the idea has been floated of extending a release cycle), and ensuring we don’t get back into the situation. QA is hitting similar issues, we keep adding releases. This one is a bit more difficult to “fix”

Modularity continues to be a trouble spot. It is a great feature in theory, adding capabilities to the distro as shipped, but even more so to people who are using or deploying the distro in their own environments. In practice, it has not been managed as well as it could be. There was always some backlash from the community members who just don’t care about modularity, or understand what it brings, but now there is also justified backlash in how things are being currently deployed. FESCo can help to ensure that further features around modularity are planned and executed, though there are a few fires to be put out first.

The post FESCo Election: Interview with Justin Forbes (jforbes) appeared first on Fedora Community Blog.

Bodhi 3.11.3 released

Posted by Bodhi on December 05, 2018 03:17 PM

This is a bugfix release.

Server upgrade instructions

No special actions are needed when applying this update.

Bug fixes

  • Correctly handle multiple builds with the search form in the new update JavaScript web UI code


The following developers contributed to Bodhi 3.11.3:

  • Mattia Verga

How to rearrange the GNOME Adwaita default theme

Posted by Luca Ciavatta on December 05, 2018 08:10 AM

Have you ever used the GNOME desktop? This is by far one of the best graphics environments to work with, and its developers have a nice taste for elegance and minimalism; in short, the GNOME DE is really so beautiful.   GNOME, by default, has incredible elegant themes I’m a big fan of both Xfce and i3wm, but on all[...]

The post How to rearrange the GNOME Adwaita default theme appeared first on CIALU.NET.

Fedora Classroom: Containers 101 with Podman

Posted by Fedora Magazine on December 05, 2018 08:00 AM

Fedora Classroom sessions continue next week with a session on containers with Podman. The general schedule for sessions appears on the wiki. You can also find resources and recordings from previous sessions there. Here are details about this week’s session on Thursday, December 13 at 1600 UTC. That link allows you to convert the time to your timezone.

Topic: Containers 101 with Podman

Containers are becoming the de facto standard for building and distributing applications. Fedora as a modern operating system already supports container use by default. As with every new technology, there are different applications and services available for adopting it. This classroom will explain the basics of containers technology and its implementation in Fedora 29 using new open source tools like podman and buildah.

Here’s the agenda for the Classroom session:

Containers 101 with Podman

  1. What are Linux containers?
  2. Deep dive into container architecture
  3. Container runtimes
  4. Build and run containers
  5. Introduction to container networks, logs, security and persistent storage


Alessandro Arrichiello is a Solution Architect for Red Hat. He has a passion for GNU/Linux systems, which began at age 14 and continues today. He works with tools for automating Enterprise IT, configuration management, and continuous integration through virtual platforms.

He’s now working on distributed cloud environments via PaaS (OpenShift), IaaS (OpenStack) and process management (CloudForms), container building, instance creation, HA services management, and workflow building.

Joining the session

This session takes place on BlueJeans. The following information will help you join the session:

We hope you attend, learn from, and enjoy this session. If you have any feedback about the sessions, have ideas for a new one, or want to host a session, feel free to comment on this post or edit the Classroom wiki page.

Fedora Design Team Meeting, 4 Nollaig 2018

Posted by Máirín Duffy on December 04, 2018 08:37 PM

Fedora Design Team Logo

Today we had a Fedora Design Team meeting. Here’s what went down (meetbot link).

Freenode<>Matrix.org Issues

Tango Internet Group Chat, CC0 from openclipart.ogr

About half of the team members who participated today used matrix.org (e.g. the riot.im client). Unfortunately, we noticed an issue with bridging between these two networks today – both sides could see IRC comments, but matrix.org comments weren’t getting sent to IRC. ctmartin recognized the issue from another Fedora channel and figured out that if we added +v to the channel members using matrix, that would fix the issue. I am not sure if this is All Fixed Now or is going to be an ongoing Thing. But that is why our meeting started late today.

If anybody has ideas on how to resolve this in a permanent way, I would very much appreciate your advice!

Fedora 30 Artwork

CC BY-SA 3.0, wikimedia commons "A Fresnel lens exhibited in the Musée national de la Marine"

For 5 Fedora releases now, the design team has been using a famous scientist / mathematician / technologist as the inspiration for the release artwork. We do this based on an alphabetical system; Fedora 30 is slated to be a person whose names begins with an “F.” Gnokii manages this process, and already set up and tallied the results for the design team-specific vote on which we chose from the following:

  • Federico Faggin (microprocessor)
  • Rosalin Franklin (DNA helix)
  • Sandford Fleming (Universal Standard Time)
  • Augustin-Jean Fresnel (fresnel lens)

As gnokii announced on our team mailing list, the inspiration for the Fedora 30 artwork will be Augustin-Jean Fresnel. He also gathered the following set of inspirational images, which all revolve around the design of the Fresnel lens, which we talked about in the meeting would be a good central focus / concept for the artwork, whether it’s a depiction of a lens itself or some form of study of the diffraction pattern (and “thin-film” rainbow effect”) that inspired its invention:

The action item we got out of this discussion is that we need to meet separately, a remote hackfest if you will, to work on the F30 artwork (as we typically do each release.) This will take place in #fedora-design on IRC (or Fedora Design on matrix.org.) If you are interested in participating, here is the whenisgood.net to organize a time for this event:


Exploring a Fedora logo refresh

For the past few weeks we have been working with mattdm on exploring what a refresh of the Fedora logo might look like. This work has been ongoing in design ticket #620. There’s a few issues such a thing would aim to address – if you’ve ever worked with the current Fedora logo yourself, these should be pretty familiar (copy-pasta-ed from the ticket):

  • It doesn’t work well at small sizes
  • It doesn’t work at all in a single color
  • It’s hard to work with on a dark background
  • The “voice” bubble means it’s hard to center visually in designs
  • The Fedora wordmark is based on a non-open-source font
  • The “a” in the wordmark is easily mistaken for an o
  • The horizontal wordmark + logo with the “floated” trailing logo is challenging to work with
  • It gets confused with the Facebook logo

The general approach here is a light touch, and not an overhaul. Below are some of the leading concepts / experiments thus far:

The next step here that we discussed is for each concept, to create something like “style tiles” for each so we can better understand how each would play in context – how would it look like with our fonts, color palette, and what design elements would go with it. That process may surface some issues in the design of each which we’ll need to address.

After that, we’ll open up to broad community input – maybe a formal survey and/or maybe some mini IRC or video chat focus group sessions and see how folks feel about it, gather feedback, see which concept the broader community prefers and see if there are tweaks / adjustments we can make to iterate it based on the feedback we receive.

This is something we’ll continue to work on for the next few months. If you have feedback on the assets so far, please feel free to leave it in the comments here, but be nice please 🙂 and note this is still early stages.

Are you new to Fedora Design? Would you like to join?

This little ticket popped up in our triage during the meeting today, and is a good one for you to grab. It has a LibreOffice template you can use, or simply draw from for inspiration. Note the base font should be Overpass (free font, downloadable at overpassfont.org):

If that’s not your speed, we have a couple of other newbie tickets in our queue, check them out and feel free to grab one that piques your interest!

Fedora Podcast Website Design

terezahl, the Fedora Design team intern, has been working on a website design for the Fedora Podcast that x3mboy has created. She showed us a snapshot of her work-in-progress, and we gave her some feedback. Overall, it looks great, and we’re excited to see where it goes 🙂

That’s it folks!

If you are interested in participating in the Fedora 30 Artwork IRC Hackfest, please vote for a timeslot here, ASAP 🙂


Fedora on Raspberry Pi: camera module

Posted by alciregi on December 04, 2018 07:56 PM

How to use the camera module on a Raspberry Pi 3 running Fedora 29?

Flatpaks in Fedora – now live

Posted by Owen Taylor on December 04, 2018 07:42 PM


I’m pleased to announce that we now have full initial support for Flatpak creation in Fedora infrastructure: Flatpaks can be built as containers, pushed to testing and stable via Bodhi, and installed by users from registry.fedoraproject.org through the command line, GNOME Software, or KDE Discover.

The goal of this work has been to enable creating Flatpaks from Fedora packages on Fedora infrastructure – this will expand the set of Flatpaks that are available to all Flatpak users, provide a runtime that gets updates as bugs and security fixes appear in Fedora, and provide Fedora users, especially on Fedora Silverblue, with an out-of-the-box set of Flatpak applications enabled by default.

At a technical level, a very brief summary of the approach we’ve taken is to take Fedora RPMs, rebuild them with prefix=/app using the Fedora modularity framework, then using the same container build service we use for server-side containers, create Flatpaks as OCI images . Flatpak has been extended to know how to browse, download, and install Flatpaks packaged as OCI images from a container registry. See my my talk at DevConf.CZ last year  for a slightly longer introduction to what we are doing.

Right now, there are only a few applications in the registry, but we will work to build up the set of applications over the next few months, and hopefully by the time that Fedora 30 comes out in the spring, will have something that will be genuinely useful for Fedora users and that can be enabled by default in Fedora Workstation.

Special thanks to Clement Verna, Randy Barlow, Kevin Fenzi, and the rest of the Fedora infrastructure team for a lot of help in making the Fedora deployment happen, as well as to the OSBS team and Alex Larsson!

Using it

From the command line, either add the stable remote:

flatpak remote-add fedora oci+https://registry.fedoraproject.org

Or add the testing remote:

flatpak remote-add fedora-testing oci+https://registry.fedoraproject.org#testing

There is no point in adding both, since all Flatpaks in the stable remote are also in the testing remote. (The plan is to eventually that most users will simply use the stable remote, and there will be links in Bodhi to make it easy to install a single application from testing.)

Note that some fixes were needed to make OCI remotes work properly system-wide. These were backported to the Fedora Flatpak-1.0.6 packages, but are only in master upstream, so if you aren’t using Fedora, you should add the remote per-user instead.

Creating Flatpaks

If you are a Fedora packager and want to create a Flatpak of a graphical application you maintain, or want to help out creating Flatpaks in general, see the packager documentation. There is also a list of applications that are easy to package as Flatpaks.

Future work

One thing that should make things easier for packagers is the flatpak common module – by depending on this module, different Flatpaks can share the same binary builds of common libraries. This is particularly important for libraries that take a long time to build, or when an application needs to bundle a large set of libraries (think KDE or TeX). The current flatpak-common is a prototype, and there needs to be some thought given to the policies and tools for updating it.

Automatic rebuilds of Flatpaks are essential: when a fix is added to a library that an application bundles, the module and Flatpak should automatically be rebuilt without the maintainer of the Flatpak having to know that there was something to do – and then the maintainer should be notified, either with a link to a build failure, or, more hopefully, with a link to a Bodhi update that was automatically filed. Adding Flatpak support to Freshmaker and deploying it for Fedora is probably the right course here – though not a small task.

Another thing that I hope to address in the near term is signatures. Right now the authenticity is checked by downloading a master index from https://registry.fedoraproject.org that contains hashes for the latest versions of applications. But having signatures on the images would add further protection against tampering, and depending on how they were implemented, could allow things like third party signatures added by an organization’s IT department. There’s quite a bit of complexity here, because there are multiple competing signature frameworks to coordinate: not just Flatpaks native signatures, but multiple different ways of signing container images.

A more long-term goal is to create a way to download updates to Flatpak container images as deltas, so that every update is not a full download. Reusing OCI images for Fedora Flatpaks has strong advantages for creating a common ecosystem between server applications and desktop applications, but on the server side, reducing bandwidth usage for server updates was usually not an important consideration, so the distribution strategy is simply to download everything from scratch. Hopefully work here could be shared between Flatpaks and the server usage of OCI images.

Kconfig symbol visibility

Posted by Laura Abbott on December 04, 2018 07:00 PM

I managed to get bit by the same issue twice in about 24 hours so I guess it's time for a blog post. If you've ever compiled a kernel, you have dealt with kconfig symbols (CONFIG_FOO) which are used to enable various options in the kernel. You can't select every symbol out that exists in the kernel since that would be a nightmare. Configuration options may be limited by adding depends e.g.

config FOO
    depends on BAR
    depends on BAZ if HAS_BAZ

Something like depends on BAR is statically defined and isn't going to vary across systems. It turns out, you can do some interesting tricks and have your Kconfig symbol depend on the output of a script. The first time I got bit by this was with CONFIG_GCC_PLUGINS:

menuconfig GCC_PLUGINS
    bool "GCC plugins"
    depends on HAVE_GCC_PLUGINS
    depends on PLUGIN_HOSTCC != ""

    default "$(shell,$(srctree)/scripts/gcc-plugin.sh "$(preferred-plugin-hostcc)" "$(HOSTCXX)" "$(CC)")" if CC_IS_GCC

Because of the way gcc plugins work, you need to have an external package installed to do anything useful so it makes sense to only show the symbol if the package is properly installed.

As a distro maintainer, I'm responsible for looking at new symbols as they are added to the kernel. The easiest way to do this is to take the existing config file and run make listnewconfig. A side effect of the dynamic nature of CONFIG_GCC_PLUGINS is that if you take a .config generated on a system that doesn't have the plugin devel package installed and then use it to run listnewconfig on a system that does have the package installed it will show up as a new symbol:

$ make defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
# configuration written to .config
$ make listnewconfig
scripts/kconfig/conf  --listnewconfig Kconfig
$ sudo dnf install gcc-plugin-devel

..various installation messages..

$ make listnewconfig
scripts/kconfig/conf  --listnewconfig Kconfig

We have some scripts that expect a clean listnewconfig (i.e. we've set values for all configuraiton options) so this led to some confusion about why things were not working on my system which had gcc-plugin-devel installed ("But this worked when we built it last week!")

The other case of dynamic configuration options happened with powerpc. Distros support multiple architectures but almost all development is done on our x86 workstations (until the year arm64 on the desktop happens of course). We can generate configuration files by setting the ARCH=blah option on the command line. Today I discovered that there's a dynamic config option in powerpc:

    depends on PPC64 && CPU_LITTLE_ENDIAN
    def_bool $(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) -I$(srctree)/include -D__KERNEL__)

This results in CONFIG_MPROFILE_KERNEL not being visible unless you have the appropriate compiler installed which means, again, different behavior for listnewconfig.

Obviously the system environment makes a difference when building the kernel but it's a bit surprising where this shows up. The moral I have learned is to think a little bit more closely about how exactly kernel configuration files are generated.

Using hexchat on Flatpak on Qubes OS AppVM

Posted by Kushal Das on December 04, 2018 03:59 PM

Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. It uses BubbleWrap in the low level to do the actual sandboxing. In simple terms, you can think Flatpak as a as a very simple and easy way to use desktop applications in containers (sandboxing). Yes, containers, and, yes, it is for desktop applications in Linux. I was looking forward to use hexchat-otr in Fedora, but, it is not packaged in Fedora. That is what made me setup an AppVM for the same using flatpak.

I have installed the flatpak package in my Fedora 29 TemplateVM. I am going to use that to install Hexchat in an AppVM named irc.

Setting up the Flatpak and Hexchat

The first task is to add flathub as a remote for flatpak. This is a store where upstream developers package their application and publish.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

And then, I installed the Hexchat from the store. I also installed the version of the OTR plugin required.

$ flatpak install flathub io.github.Hexchat
<output snipped>

$ flatpak install flathub io.github.Hexchat.Plugin.OTR//18.08
Installing in system:
io.github.Hexchat.Plugin.OTR/x86_64/18.08 flathub 6aa12f19cc05
Is this ok [y/n]: y
Installing: io.github.Hexchat.Plugin.OTR/x86_64/18.08 from flathub
[####################] 10 metadata, 7 content objects fetched; 268 KiB transferr
Now at 6aa12f19cc05.

Making sure that the data is retained after reboot

All of the related files are now available under /var/lib/flatpak. But, as this is an AppVM, this will get destroyed when I will reboot. So, I had to make sure that I can keep those between reboots. We can use the Qubes bind-dirs for this in the TemplateVMs, but, as this is particular for this VM, I just chose to use simple shell commands in the /rw/config/rc.local file (make sure that the file is executable).

But, first, I moved the flatpak directory under /home.

sudo mv /var/lib/flatpak /home/

Then, I added the following 3 lines in the /rw/config/rc.local file.

# For flatpak
rm -rf /var/lib/flatpak
ln -s /rw/home/flatpak /var/lib/flatpak

This will make sure that the flatpak command will find the right files even after reboot.

Running the application is now as easy as the following command.

flatpak run io.github.Hexchat

Feel free to try out other applications published in Flathub, for example, Slack or the Mark Text

Kiwi TCMS 6.3

Posted by Kiwi TCMS on December 04, 2018 07:15 AM

We're happy to announce Kiwi TCMS version 6.3! This is a medium severity security update that includes new versions of Django and Patternfly, new database migrations, lots of improvements, bug fixes and internal refactoring. This version also introduces integration with GitLab issue tracker! You can explore everything at https://demo.kiwitcms.org!

Supported upgrade paths:

5.3   (or older) -> 5.3.1
5.3.1 (or newer) -> 6.0.1
6.0.1            -> 6.1
6.1              -> 6.1.1
6.1.1            -> 6.2 (or newer)

Docker images:

kiwitcms/kiwi       latest  8135624fdca2    960.3 MB
kiwitcms/kiwi       6.2     7870085ad415    957.6 MB
kiwitcms/kiwi       6.1.1   49fa42ddfe4d    955.7 MB
kiwitcms/kiwi       6.1     b559123d25b0    970.2 MB
kiwitcms/kiwi       6.0.1   87b24d94197d    970.1 MB
kiwitcms/kiwi       5.3.1   a420465852be    976.8 MB

Changes since Kiwi TCMS 6.2.1


  • Resolve medium severity XSS vulnerability which can be exploited when previewing malicious text in Simple MDE editor. See CVE-2018-19057, SNYK-JS-SIMPLEMDE-72570
  • Use mozilla/bleach before rendering Markdown to the user as a second layer of protection against the previously mentioned XSS vulnerability


  • Update to Django 2.1.4
  • Update to Patternfly 3.58.0
  • Make docker container restartable (Maik Opitz, Adam Hall)
  • Add GitLab issue tracker integration. Fixes Issue #176 (Filipe Arruda, Federal Institute of Pernambuco)
  • Convert Create new TestPlan page to Patternfly (Anton Sankov)
  • Upon successful registration show the list of super-users in case new accounts must be activated manually. This can be the same or expanded version of the addresses in the ADMIN setting. Include super-users in email notifications sent via tcms.signals.notify_admins().
  • Don't include admin/js/*.js files in templates when not necessary. Results in faster page load. Fixes Issue #209
  • Enable nl2br Markdown extension which allows newline characters to be rendered as <br> tags in HTML. Visually the rendered text will look closer to what you seen in the text editor. Fixes Issue #623
  • Use auto-complete for adding components to TestCase

Removed functionality

  • Bulk-update of Category for selected TestCase(s) inside of TestPlan
  • Bulk-update of Components for selected TestCase(s) inside of TestPlan
  • Bulk-update of automated status for selected TestCase(s) inside of TestPlan
  • Bulk-remove for TestCase Component tab

These actions have always been a bit broken and didn't check the correct permission labels. You can still update items individually!

  • Selection of Components when creating new TestCase. Closes Issue #565. Everywhere else Kiwi TCMS doesn't allow selection of many-to-many relationships when creating or editing objects. Tags, Bugs, Components, TestPlans can be added via dedicated tabs once the object has been saved.

Bug fixes

  • Hide KiwiUserAdmin.password field from super-user. Fixes Issue #610
  • Don't show inactive Priority. Fixes Issue #637
  • Don't traceback when adding new users via Admin. Fixes Issue #642
  • Teach TestRun.update() API method to process the stop_date field. Fixes Issue #554 (Anton Sankov)
  • Previously when reporting issues to Bugzilla, directly from a TestRun, Kiwi TCMS displayed the error Enable reporting to this Issue Tracker by configuring its base_url although that has already been configured. This is now fixed. See Stack Overflow #53434949


  • Remove TestPlan.owner field, duplicates TestPlan.author



  • Remove fmt_queries(). Fixes Issue #330 (Anton Sankov)
  • Remove unused parameter from plan_from_request_or_none(). Refers to Issue #303 (Anton Sankov)
  • Remove ComponentActions() class. Fixes Issue #20
  • Convert lots of AJAX calls to JSON-RPC
  • Remove lots of unused Python, JavaScript and templates. Both after migration to JSON RPC and other leftovers
  • Pylint fixes (Alexander Todorov, Anton Sankov)

How to upgrade

If you are using Kiwi TCMS as a Docker container then:

cd Kiwi/
git pull
docker-compose down
docker pull kiwitcms/kiwi
docker pull centos/mariadb
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate

Don't forget to backup before upgrade!

WARNING: kiwitcms/kiwi:latest and docker-compose.yml will always point to the latest available version! If you have to upgrade in steps, e.g. between several intermediate releases, you have to modify the above workflow:

# starting from an older Kiwi TCMS version
docker-compose down
docker pull kiwitcms/kiwi:<next_upgrade_version>
edit docker-compose.yml to use kiwitcms/kiwi:<next_upgrade_version>
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate
# repeat until you have reached latest

Happy testing!

A PolicyKit refresher

Posted by Matthias Clasen on December 04, 2018 05:08 AM

PolicyKit has been around for a long time, and it is a mature system that basically does its job. I recently spent some time to improve the PolicyKit integration in Flatpak and thought it might be useful to write up some of the details.

Details, details

It is irritating when a dialog  pops up unexpectedly and asks questions without providing sufficient details to really know where it is coming from and what the context is. Like

Authentication is required to install software

It would be much better to say what software is being installed, and where it is coming from:

PolicyKit lets you do this by using variables in your message and providing the replacement for them via a PolkitDetails object:

Authentication is required to install $(ref) from $(origin)
polkit_details_insert (details, "origin", origin);
polkit_details_insert (details, "ref", ref);

No display – no problem

Its nice to get a  PolicyKit dialog when you are using a desktop app that needs to carry out a privileged operation. But PolicyKit is also used by commandline tools, such as flatpak. If you are running a command in a terminal, a dialog might still be ok. But what if you are using the flatpak on the console? A dialog is not available here, so privileged operations will fail.

PolicyKit provides the necessary plumbing to solve this situation, by letting apps register their own ‘agent’, which can handle authorization requests if no other agent is available. (In a graphical session, GNOME Shell provides an agent.)

Glancing over some details,  the code to do this looks roughly like this:

listener = polkit_agent_text_listener_new (NULL,
polkit_agent_listener_register (listener,
            flags, subject, NULL, NULL, &error);

And it yields a result like this:If PolicyKits built-in text agent does not fit your needs, you can implement a PolkitAgentListener yourself. That is what I ended up doing for Flatpak.

Psst, don’t interrupt

As I said earlier, unexpected dialogs are annoying. Ideally, PolicyKit dialogs should only ever appear in response to a direct user action. For example, a dialog is ok if I am clicking the “Install” button in GNOME Software, but not if GNOME Software decides on it own that it is time to install some updates.

PolicyKit has a means to achieve this, by not passing the


flag when checking for authorization. But this check happens in the system service (or mechanism, in PolicyKit lingo), not in your client. In order to take advantage of this flag, the client needs to pass information about  user interaction along whenever it calls a privileged method of the mechanism.

In the Flatpak case, I added a ‘no-interaction’ flag to all the flatpak-system-helper methods, and library API that GNOME Software can use to set this flag for background operations.

So there should be less unexpected PolicyKit dialogs in the future.

Update: A useful PolicyKit feature that I forgot to mention is implications. If the the permissions (or actions, in PolicyKit lingo) are ordered in some way (e.g. if you are allowed to install applications, you should also be allowed to update them), you can express these relations with “imply” annotations. This can further reduce the need for duplicate dialogs.`

Bodhi 3.11.2 released

Posted by Bodhi on December 03, 2018 06:49 PM

This is a bugfix release, addressing an issue that was solved incorrectly with 3.11.1.

Server upgrade instructions

No special actions are needed when applying this update.

Bug fixes

  • Correctly catch http.client.IncompleteRead while Composing and retry (#2758).


The following developers contributed to Bodhi 3.11.2:

  • Randy Barlow

[Short Tip] Identify supported platforms of Ansible Galaxy

Posted by Roland Wolters on December 03, 2018 04:40 PM
<figure class="alignright is-resized">Ansible Logo</figure>

Ansible Galaxy recently got a fresh update and now has much more features worth a look. Among those are automatic quality scorings.

In a recent role upload my scoring was only 4.5. One of the problems was a “invalid platform”. I wondered which platforms are supported, and how the strings for those are, but the documentation is sparse in this regard.

However, Ansible Galaxy does feature an API to query those things. And in fact galaxy.ansible.com/api/v1/platforms/ shows the appropriate Fedora versions:

        "id": 143,
        "url": "/api/v1/platforms/143/",
        "related": {},
        "summary_fields": {},
        "created": "2018-01-15T11:54:54.212531Z",
        "modified": "2018-01-15T11:54:54.212560Z",
        "name": "Fedora",
        "release": "27",
        "active": true
        "id": 162,
        "url": "/api/v1/platforms/162/",
        "related": {},
        "summary_fields": {},
        "created": "2018-04-30T16:35:24.066120Z",
        "modified": "2018-04-30T16:35:24.066153Z",
        "name": "Fedora",
        "release": "28",
        "active": true
        "id": 61,
        "url": "/api/v1/platforms/61/",
        "related": {},
        "summary_fields": {},
        "created": "2016-02-04T06:29:41.226911Z",
        "modified": "2016-02-04T06:29:41.226980Z",
        "name": "FreeBSD",
        "release": "10.0",
        "active": true

So Fedora 29 is not supported right now, but there is even a bug report already.

The saga of build Librelancer over Mono, NuGET and Cake.

Posted by mythcat on December 03, 2018 12:38 PM
I wrote this article because it is a good way to understand beyond the errors encountered for Mono, NuGet and Cake.
I started the day with Fedora 29 installing the old Librelancer game:
Librelancer is a cross-platform, open source game engine re-implementing the 2003 space trading and combat game Freelancer. The engine comes with an editor for several of the game's file formats called LancerEdit.
See the official webpage.
Some errors are temporarily fixed, see:
This error refers an issue open on Feb 13,2018,12:52 PM GMT+2, see here.
However, this is a great way to go through Fedora installations to avoid searching for GitHub issues and issues.
The default install of Cake with the version 0.30.0 will not solve the last error:
[root@desk Librelancer]# nuget  install Cake -Version 0.30.0 
Installing 'Cake 0.30.0'.
Successfully installed 'Cake 0.30.0'.
Let's hope that problems will solve with time.
Below are the correct steps for going through the installation until the last error.
[mythcat@desk ~]$ git clone --depth=50 --branch=master https://github.com/Librelancer/Librelancer.git 
Cloning into 'Librelancer'...
remote: Enumerating objects: 3085, done.
remote: Counting objects: 100% (3085/3085), done.
remote: Compressing objects: 100% (1414/1414), done.
remote: Total 3085 (delta 2131), reused 2295 (delta 1639), pack-reused 0
Receiving objects: 100% (3085/3085), 7.97 MiB | 2.79 MiB/s, done.
Resolving deltas: 100% (2131/2131), done.
Checking out files: 100% (863/863), done.
[mythcat@desk ~]$ cd Librelancer/
[mythcat@desk Librelancer]$ ll
total 48
-rw-rw-r--. 1 mythcat mythcat 4912 Dec 3 11:23 build.cake
-rw-rw-r--. 1 mythcat mythcat 7439 Dec 3 11:23 build.ps1
-rwxrwxr-x. 1 mythcat mythcat 3210 Dec 3 11:23 build.sh
-rw-rw-r--. 1 mythcat mythcat 33 Dec 3 11:23 cake.config
-rw-rw-r--. 1 mythcat mythcat 1029 Dec 3 11:23 CMakeLists.txt
-rw-rw-r--. 1 mythcat mythcat 2768 Dec 3 11:23 Credits.txt
drwxrwxr-x. 4 mythcat mythcat 87 Dec 3 11:23 deps
drwxrwxr-x. 4 mythcat mythcat 4096 Dec 3 11:23 editoricons
drwxrwxr-x. 12 mythcat mythcat 208 Dec 3 11:23 extern
-rw-rw-r--. 1 mythcat mythcat 1166 Dec 3 11:23 LICENSE
-rw-rw-r--. 1 mythcat mythcat 1877 Dec 3 11:23 README.md
drwxrwxr-x. 2 mythcat mythcat 75 Dec 3 11:23 scripts
drwxrwxr-x. 15 mythcat mythcat 4096 Dec 3 11:23 src
drwxrwxr-x. 2 mythcat mythcat 29 Dec 3 11:23 tools

[mythcat@desk Librelancer]$ git submodule update --init --recursive
Submodule 'extern/BulletSharpPInvoke' (https://github.com/AndresTraks/BulletSharpPInvoke) registered for path
Submodule 'extern/Collada141' (https://github.com/Librelancer/Collada141) registered for path
Submodule 'extern/FontConfigSharp' (https://github.com/CallumDev/FontConfigSharp.git) registered for path
Submodule 'extern/ImGui.NET' (https://github.com/mellinoe/ImGui.NET) registered for path 'extern/ImGui.NET'
Submodule 'extern/SharpFont' (https://github.com/Robmaister/SharpFont.git) registered for path 'extern/SharpFont'
Submodule 'extern/StbSharp' (https://github.com/rds1983/StbSharp) registered for path 'extern/StbSharp'
Submodule 'extern/bullet3' (https://github.com/bulletphysics/bullet3) registered for path 'extern/bullet3'
Submodule 'extern/cimgui' (https://github.com/Extrawurst/cimgui) registered for path 'extern/cimgui'
Submodule 'extern/lidgren-network-gen3' (https://github.com/lidgren/lidgren-network-gen3) registered for path
Submodule 'extern/nvidia-texture-tools' (https://github.com/castano/nvidia-texture-tools) registered for path
Cloning into '/home/mythcat/Librelancer/extern/BulletSharpPInvoke'...
Cloning into '/home/mythcat/Librelancer/extern/Collada141'...
Cloning into '/home/mythcat/Librelancer/extern/FontConfigSharp'...
Cloning into '/home/mythcat/Librelancer/extern/ImGui.NET'...
Cloning into '/home/mythcat/Librelancer/extern/SharpFont'...
[mythcat@desk Librelancer]$ export GITHUB_TOKEN=[secure]
Check your mono version
[mythcat@desk Librelancer]$ mono --version
Mono JIT compiler version 4.8.0 (Stable Wed Sep 20 21:27:10 UTC 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: normal
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen

[root@desk Librelancer]# rpm --import https://packages.microsoft.com/keys/microsoft.asc
[root@desk Librelancer]# wget -q https://packages.microsoft.com/config/fedora/27/prod.repo
[root@desk Librelancer]# ls
build.cake cake.config deps LICENSE scripts
build.ps1 CMakeLists.txt editoricons prod.repo src
build.sh Credits.txt extern README.md tools
[root@desk Librelancer]# vim prod.repo
[root@desk Librelancer]# mv prod.repo /etc/yum.repos.d/microsoft-prod.repo
[root@desk Librelancer]# chown root:root /etc/yum.repos.d/microsoft-prod.repo
[root@desk Librelancer]# dnf update
packages-microsoft-com-prod 48 kB/s | 156 kB 00:03
Last metadata expiration check: 0:00:01 ago on Mon 03 Dec 2018 11:52:11 AM EET.
Dependencies resolved.
Nothing to do.

[root@desk Librelancer]# dnf search dotnet-sdk
Last metadata expiration check: 0:01:05 ago on Mon 03 Dec 2018 11:52:11 AM EET.
=========================== Name Matched: dotnet-sdk ===========================
dotnet-sdk-2.1.x86_64 : Microsoft .NET Core SDK 2.1.500 2.1.500
dotnet-sdk-2.1.200.x86_64 : Microsoft .NET Core SDK - 2.1.200 2.1.200
dotnet-sdk-2.1.201.x86_64 : Microsoft .NET Core SDK - 2.1.201 2.1.201
dotnet-sdk-2.1.202.x86_64 : Microsoft .NET Core SDK - 2.1.202 2.1.202
dotnet-sdk-2.1.300-rc1-008673.x86_64 : Microsoft .NET Core SDK 2.1.300 - rc1
: 2.1.300-rc1-008673

[root@desk Librelancer]# dnf install dotnet-sdk-2.1.202.x86_64
Last metadata expiration check: 0:02:18 ago on Mon 03 Dec 2018 11:52:11 AM EET.
Dependencies resolved.
Package Arch Version Repository Size
dotnet-sdk-2.1.202 x86_64 2.1.202-1 packages-microsoft-com-prod 96 M
Installing dependencies:
aspnetcore-store-2.0.0 x86_64 2.0.0-1 packages-microsoft-com-prod 24 M
aspnetcore-store-2.0.3 x86_64 2.0.3-1 packages-microsoft-com-prod 7.9 M
aspnetcore-store-2.0.5 x86_64 2.0.5-1 packages-microsoft-com-prod 1.6 M
aspnetcore-store-2.0.6 x86_64 2.0.6-1 packages-microsoft-com-prod 9.3 M
aspnetcore-store-2.0.7 x86_64 2.0.7-1 packages-microsoft-com-prod 24 k
aspnetcore-store-2.0.8 x86_64 2.0.8-1 packages-microsoft-com-prod 8.5 M
aspnetcore-store-2.0.9 x86_64 2.0.9-1 packages-microsoft-com-prod 956 k
dotnet-host x86_64 2.1.6-1 packages-microsoft-com-prod 45 k
dotnet-hostfxr-2.0.9 x86_64 2.0.9-1 packages-microsoft-com-prod 182 k
dotnet-runtime-2.0.9 x86_64 2.0.9-1 packages-microsoft-com-prod 24 M

Transaction Summary
Install 11 Packages

Total download size: 173 M
Installed size: 173 M
Is this ok [y/N]: y

This will fix a bug :
Unhandled Exception:
System.TypeInitializationException: The type initializer for 'System.Console' threw an exception.
[mythcat@desk Librelancer]$ TERM=xterm

[mythcat@desk Librelancer]$ ./build.sh
Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.

[root@desk Librelancer]# dnf install nuget.x86_64

The dotnet come with this:

[root@desk Librelancer]# dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.1.500
Commit: b68b931422

Runtime Environment:
OS Name: fedora
OS Version: 29
OS Platform: Linux
RID: fedora.29-x64
Base Path: /usr/share/dotnet/sdk/2.1.500/

Host (useful for support):
Version: 2.1.6
Commit: 3f4f8eebd8

.NET Core SDKs installed:
2.1.202 [/usr/share/dotnet/sdk]
2.1.500 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.9 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.6 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:

Let's test again:
[mythcat@desk Librelancer]$ ./build.sh
Feeds used:

Restoring NuGet package Cake.0.30.0.
WARNING: Unable to find version '0.30.0' of package 'Cake'.
https://api.nuget.org/v3/index.json: Unable to load the service index for source https://api.nuget.org/v3/index.json.
An error occurred while sending the request
Error: TrustFailure (Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED)
Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Unable to find version '0.30.0' of package 'Cake'.
https://api.nuget.org/v3/index.json: Unable to load the service index for source https://api.nuget.org/v3/index.json.
An error occurred while sending the request
Error: TrustFailure (Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED)
Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Could not restore NuGet tools.

[root@desk Librelancer]# cat /etc/ssl/certs/* >ca-bundle.crt
[root@desk Librelancer]# TERM=xterm
[root@desk Librelancer]# cert-sync ca-bundle.crt
Mono Certificate Store Sync - version
Populate Mono certificate store from a concatenated list of certificates.
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.

Importing into legacy system store:
I already trust 0, your new list has 129
Certificate added: CN=ACCVRAIZ1, OU=PKIACCV, O=ACCV, C=ES
Certificate added: C=ES, O=FNMT-RCM, OU=AC RAIZ FNMT-RCM
Certificate added: C=IT, L=Milan, O=Actalis S.p.A./03358520967, CN=Actalis Authentication Root CA
Certificate added: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
129 new root certificates were added to your trust store.
Import process completed.
[root@desk Librelancer]# rm ca-bundle.crt
rm: remove regular file 'ca-bundle.crt'? y

[mythcat@desk Librelancer]$ ./build.sh
Feeds used:

Restoring NuGet package Cake.0.30.0.
GET https://api.nuget.org/v3-flatcontainer/cake/0.30.0/cake.0.30.0.nupkg
OK https://api.nuget.org/v3-flatcontainer/cake/0.30.0/cake.0.30.0.nupkg 53ms
Installing Cake 0.30.0.
Adding package 'Cake.0.30.0' to folder '/home/mythcat/Librelancer/tools'
Added package 'Cake.0.30.0' to folder '/home/mythcat/Librelancer/tools'
Install failed. Rolling back...
Error: One or more errors occurred.
Could not load type 'NuGet.Packaging.PackageArchiveReader' from assembly 'NuGet.Packaging,
Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

Secure Boot — Fedora, RHEL, and Shim Upstream Maintenance: Government Involvement or Lack Thereof

Posted by Peter Jones on December 03, 2018 09:46 AM

You probably remember when I said some things about Secure Boot in June of 2014. I said there’d be more along those lines, and there is.

So there’s another statement about that here.

I’m going to try to remember to post a message like this once per month or so. If I miss one, keep an eye out, but maybe don’t get terribly suspicious unless I miss several in a row.

Note that there are parts of this chain I’m not a part of, and obviously linux distributions I’m not involved in that support Secure Boot. I encourage other maintainers to offer similar statements for their respective involvement.

OpenClass: Dvadeset godina otvorenog koda – GNU/Linux, Mozilla i prijatelji jučer, danas i sutra

Posted by HULK Rijeka on December 03, 2018 09:09 AM

Riječka podružnica Hrvatske udruge Linux korisnika i Odjel za informatiku Sveučilišta u Rijeci pozivaju vas na OpenClass koji će se održati četvrtak, 6. prosinca 2018. u 17 sati, u zgradi Sveučilišnih odjela, prostorija O-028. OpenClass pod naslovom

GNU/Linux, Mozilla i prijatelji jučer, danas i sutra

održava se povodom obilježavanja dvadeset godina otvorenog koda od strane Open Source Initiative. Predavač je dr. sc. Vedran Miletić s Odjela za informatiku Sveučilišta u Rijeci.


Početkom 1998. godine tvrtka Netscape Communications obznanila je da će vlastiti preglednik Netscape Communicator dati svima na korištenje potpuno besplatno te da će izvorni kod preglednika biti slobodno dostupan za daljnji razvoj. Metoda razvoja softvera dotad poznata pod imenom slobodan softver dobiva novo ime, otvoreni kod, i iste godine nastaje projekt Mozilla. Kroz narednih 5 godina projekt je stvorio Firefox, prvi preglednik koji je ozbiljno zaprijetio monopolu Microsoftovog Internet Explorera.

Dvadeset godina kasnije je dobar trenutak da napravimo pogled unatrag: da sagledamo uvjete koji su omogućili Netscapeu da razmatra slobodni softver kao moguću metodu razvoja softvera, da istražimo proces kojim je otvoreni kod postao mainstream među desktop aplikacijama te da pronađemo koje su sve kompanije i koji sve njihovi projekti slijedili Netscapeov primjer i postali projekti otvorenog koda. Dvadeset godina kasnije je i dobar trenutak da usporedimo sadašnje stanje stvari u svijetu slobodnog softvera i vidimo gdje smo napravili dobar posao (možda u Top 500 superračunala gdje je tržišni udio Linuxa 100%?), a gdje smo mogli biti i bolji (možda u domeni PC gaminga gdje, prema statistikama s Steama, još uvijek s preko 90% dominiraju Windows 10 i Windows 7?).

Naposlijetku, bacit ćemo i pogled u budućnost. Što je s otvorenim kodom na mobilnim uređajima raznih veličina i namjena, od tableta do satova? Kakvo je stanje uređaja i aplikacija u domeni virtualne i proširene stvarnosti, što su u tom području napravili Valve, Unreal Engine i Godot Engine? Već danas implementacije standarda Trusted Platform Module i tehnologije Secure Boot nude razloge za zabrinutost oko mogućnosti otvaranja čitavog koda koji pokreće računalo na kojem radimo, ma koliko truda uložili u razvoj coreboota. Koji nas drugi izazovi čekaju u, kako Cory Doctorow iz Electronic Frontier Foundationa naziva zbivanja koja vidimo, ratu protiv računarstva opće namjene?

Nadamo se vašem dolasku!

Meet an opinionated quickstart for Sphinx docs authors

Posted by Justin W. Flory on December 03, 2018 09:00 AM
Meet an opinionated quickstart for Sphinx / ReStructuredText docs authors

Are you someone who writes documentation with the Sphinx tool chain? Do you want to encourage more people to write documentation in a distributed organization, but worry about maintaining compatible workflows? Introducing sphinx-docs-opinionated-quickstart, a template repository with an opinionated configuration of ReStructuredText documentation with Travis CI testing and readthedocs.org publishing.

I created this for the RIT Linux User’s Group (a.k.a. RITlug). RITlug welcomes student-led projects for members to work on together. RITlug executive board members want to better encourage students to share and join projects for collaboration with the community (in the spirit of FOSS). To do this, the executive board members will create and offer both a template website and template documentation tools to introduce students to project development process. Then, students are better able to sustain a more diverse community around their projects.

“Start writing ReStructuredText already!”

The philosophy with this small project is: “Start writing ReStructuredText already!” I use Sphinx with ReadTheDocs as a deployment option across different organizations. I want a common base to later customize for a specific project’s needs.

The whole point of this project is to save time kicking off a new project’s recently-established documentation effort.

Travis CI testing configuration included

Complex documentation tool chains need simple validation of successful builds. This avoids long periods where documentation may not build and the public docs are out of date. It also better engages core contributors to monitor and take care of their documentation.

A Travis CI configuration is included. Fork this repository and enable the repo on travis-ci.org to start running builds.

Add a star on GitHub

Does this sound helpful? Check it out and add a star at jwflory/sphinx-docs-opinionated-quickstart. The project is licensed under the BSD 3-Clause License; feel free to fork it and form your own opinions too.

Photo by Jānis Skribāns on Unsplash.

The post Meet an opinionated quickstart for Sphinx docs authors appeared first on Justin W. Flory's Blog.

Smart home: where to start?

Posted by Daniel Pocock on December 03, 2018 08:44 AM

My home automation plans have been progressing and I'd like to share some observations I've made about planning a project like this, especially for those with larger houses.

With so many products and technologies, it can be hard to know where to start. Some things have become straightforward, for example, Domoticz can soon be installed from a package on some distributions. Yet this simply leaves people contemplating what to do next.

The quickstart

For a small home, like an apartment, you can simply buy something like the Zigate, a single motion and temperature sensor, a couple of smart bulbs and expand from there.

For a large home, you can also get your feet wet with exactly the same approach in a single room. Once you are familiar with the products, use a more structured approach to plan a complete solution for every other space.

The Debian wiki has started gathering some notes on things that work easily on GNU/Linux systems like Debian as well as Fedora and others.


What is your first goal? For example, are you excited about having smart lights or are you more concerned with improving your heating system efficiency with zoned logic?

Trying to do everything at once may be overwhelming. Make each of these things into a separate sub-project or milestone.

Technology choices

There are many technology choices:

  • Zigbee, Z-Wave or another protocol? I'm starting out with a preference for Zigbee but may try some Z-Wave devices along the way.
  • E27 or B22 (Bayonet) light bulbs? People in the UK and former colonies may have B22 light sockets and lamps. For new deployments, you may want to standardize on E27. Amongst other things, E27 is used by all the Ikea lamp stands and if you want to be able to move your expensive new smart bulbs between different holders in your house at will, you may want to standardize on E27 for all of them and avoid buying any Bayonet / B22 products in future.
  • Wired or wireless? Whenever you take up floorboards, it is a good idea to add some new wiring. For example, CAT6 can carry both power and data for a diverse range of devices.
  • Battery or mains power? In an apartment with two rooms and less than five devices, batteries may be fine but in a house, you may end up with more than a hundred sensors, radiator valves, buttons, and switches and you may find yourself changing a battery in one of them every week. If you have lodgers or tenants and you are not there to change the batteries then this may cause further complications. Some of the sensors have a socket for an optional power supply, battery eliminators may also be an option.

Making an inventory

Creating a spreadsheet table is extremely useful.

This helps estimate the correct quantity of sensors, bulbs, radiator valves and switches and it also helps to budget. Simply print it out, leave it under the Christmas tree and hope Santa will do the rest for you.

Looking at my own house, these are the things I counted in a first pass:

Don't forget to include all those unusual spaces like walk-in pantries, a large cupboard under the stairs, cellar, en-suite or enclosed porch. Each deserves a row in the table.

Sensors help make good decisions

Whatever the aim of the project, sensors are likely to help obtain useful data about the space and this can help to choose and use other products more effectively.

Therefore, it is often a good idea to choose and deploy sensors through the home before choosing other products like radiator valves and smart bulbs.

The smartest place to put those smart sensors

When placing motion sensors, it is important to avoid putting them too close to doorways where they might detect motion in adjacent rooms or hallways. It is also a good idea to avoid putting the sensor too close to any light bulb: if the bulb attracts an insect, it will trigger the motion sensor repeatedly. Temperature sensors shouldn't be too close to heaters or potential draughts around doorways and windows.

There are a range of all-in-one sensors available, some have up to six features in one device smaller than an apple. In some rooms this is a convenient solution but in other rooms, it may be desirable to have separate motion and temperature sensors in different locations.

Consider the dining and sitting rooms in my own house, illustrated in the floorplan below. The sitting room is also a potential 6th bedroom or guest room with sofa bed, the downstairs shower room conveniently located across the hall. The dining room is joined to the sitting room by a sliding double door. When the sliding door is open, a 360 degree motion sensor in the ceiling of the sitting room may detect motion in the dining room and vice-versa. It appears that 180 degree motion sensors located at the points "1" and "2" in the floorplan may be a better solution.

These rooms have wall mounted radiators and fireplaces. To avoid any of these potential heat sources the temperature sensors should probably be in the middle of the room.

This photo shows the proposed location for the 180 degree motion sensor "2" on the wall above the double door:


To summarize, buy a Zigate and a small number of products to start experimenting with. Make an inventory of all the products potentially needed for your home. Try to mark sensor locations on a floorplan, thinking about the type of sensor (or multiple sensors) you need for each space.