Fedora People

Updating a group of packages on Gentoo

Posted by Tomas Tomecek on March 31, 2019 03:18 PM

I wanted to update my gentoo box once again. I did last update probably ~6 months ago. This usually means for me that I get a ton of conflicts:

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ~] dev-qt/qtcore-5.12.2 [5.11.1-r1]

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:


  (dev-qt/qtcore-5.12.2:5/5.12::gentoo, ebuild scheduled for merge) pulled in by
    dev-qt/qtcore (Argument)

  (dev-qt/qtcore-5.11.1-r1:5/5.11::gentoo, installed) pulled in by
    ~dev-qt/qtcore-5.11.1 required by (dev-qt/qtdbus-5.11.1:5/5.11::gentoo, installed)
    ^              ^^^^^^
    (and 9 more with the same problem)

I was really hoping that portage would be so smart that would it update whole qt stack in one transaction. Sadly, it did not and I realized that I had to tell it. But how?

The easiest solution I came up with was using equery: get installed packages from dev-qt category:

$ equery l dev-qt/* -F '$category/$name'

And now we just feed this output to emerge:

$ emerge --ask -1 --verbose-conflicts $(equery l dev-qt/* -F '$category/$name')                                                                                                                   1 ↵

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-qt/qtchooser-0_p20170803
[ebuild     U  ] dev-qt/qtcore-5.11.3-r2 [5.11.1-r1]
[ebuild     U  ] dev-qt/qtxml-5.11.3 [5.11.1]
[ebuild     U  ] dev-qt/qtconcurrent-5.11.3 [5.11.1]
[ebuild     U  ] dev-qt/qtdbus-5.11.3 [5.11.1]
[ebuild     U  ] dev-qt/qtnetwork-5.11.3 [5.11.1]
[ebuild     U  ] dev-qt/qtsql-5.11.3 [5.11.1-r1]
[ebuild     U  ] dev-qt/linguist-tools-5.11.3 [5.11.1]
[ebuild     U  ] dev-qt/qtgui-5.11.3 [5.11.1]
[ebuild     U  ] dev-qt/qtwidgets-5.11.3 [5.11.1]
[ebuild     U  ] dev-qt/qtx11extras-5.11.3 [5.11.1]
[ebuild     U  ] dev-qt/qtsvg-5.11.3 [5.11.1]

Would you like to merge these packages? [Yes/No] Y

I wish emerge was smarter in this use case, but on the other hand, the solution is also not that hard.


Posted by Sayan Chowdhury on March 26, 2019 09:06 AM

I was back to FOSSASIA this year after a gap of an year and nothing had changed other than the venue. The event had the same level of enthusiasm as before, though the crowd seemed to be less compared to the previous years.

This FOSSASIA was more special for the participants, organizers and the volunteers because this was the 10th year of the event. Kudos, to the organizing team for doing it successfully for last 10 years!

Day zero, the speakers informally gathered at the Lau Pa Sat street, where we shared some nice discussions along with sea food.

Sadly, the first day started out bad for me, with me waking up to bloodshot red eyes and burning sensation. I went back to have more some rest and later in the day headed to the conference after waking up.

The first day was a single-track event with the talks lined up one after another. Martin, from Debian, shared the varied differences and similarities within the open source communities. The panel on "What Opportunities Does "Open" Bring to Society?" was an interesting panel to sit through and listen to bunnie, Hong, Shanker, Dr. Graham, and Carsten share their opinions. Being there is the industry for long and embracing open source they shared their thoughts on how their employers embrace open source over time.

Recently, I've been looking IPFS (InterPlanetory File System) after we had a talk on the same during the Golang Bangalore Meetup. Jollen Chen in his talk shares how they are building distributed ledger/blochain from scratch for the IoT space. They use virtual blocks that provide a new blockchain design to ensure the real-time data transactions. This virtual blocks also add up with IPFS.

I lost track of time and could not attend the "Serverless with Knative".

The second day, I did not attend a lot of talks rather went around the booths, and made connections in the hallway tracks. Elastic, Upcloud, UI-licious, Indeed, Microsoft, IBM, and others. There were a couple of communities too who had put up their booth. CentOS also had a booth of it's own. We had our Fedora CoreOS stickers and Silverblue stickers up for display at the booth.

In talks, Rishav talked on the best practices to be followed while building Docker images. Manuel puts why/what problems is GraphQL  trying to solve in comparison to REST. The under/over fetching principle in GraphQL/REST seems to be interesting to me and I shall put some reading around it and try to get something implemented around it. Rohan took us through the magical land of babel and codemod. He explained how he refactored and migrated to a different library by writing custom codemod, and explaining JavaScript AST, babel parser on the way.

On the third day of the event, I went to talk by Harsha who was talking on building intelligent intrusion detection system, the first half of the talk mostly talks about the basics about IDS, and the second half on how he uses machine learning, and the fields to build this intelligent IDS. As expected, Jason Zaman gives an amazing talk on how to leverage SELinux to debug issues, for conditional policies, for policy types etc. He also demoed the various SELinux commands to use to tool effectively as an system administrator. Abhishek, from Swiggy, how Redis sits in-front of MySQL as a caching layer. He also demonstrated the plugin that he built and shared a demo on the performance of the tool.

The last day, I gave a talk on how I leverage the container-workflow tool on my primary workstation using Silverblue. I also shared why we built Silverblue in the first place, and what happens behind the scenes. The good thing was just after my talk Sinny's talk was scheduled which was on the upcoming  Fedora CoreOS.

I was actually happy that our talks had a good amount of audience, and there was good amount of enthusiasm from the crowd. Few people where interested in knowing the release cycle of the Silverblue/Fedora CoreOS and if it would be different from the one Container Linux followed which was maintaining channels. Also, an interesting question was if there was  limit to the number of package layering I can go while working with Silverblue.

Apart from the talk, I was reached out by a lot of people to know if Silverblue or the container-based workflow actually helps. I've to agree it's not an easy task to pitch a unconventional way to manage your system and something which is totally new. Still, at the end of the day, I hope I had good discussion around the topic with a lot of people.

I also happened to visit the Singapore Hackerspace which is one of the places I love to visit. On second visit we met a enthusiastic group of hackers and makers who are out on travelling South East Asia.

To end, I really had a good time at Singapore and FOSSASIA. I met a lot of people whom I did not meet for years, built connections to meet them in the future, and learnt quite a lot of things. And, I also happened to learn some really nice soldering technique at the very end.

À bientôt

Cover image by Michael Cannon (CC BY-SA 2.0)

Outreachy 2019 with Fedora Happiness Packets: application period

Posted by Fedora Community Blog on March 26, 2019 08:15 AM
Outreachy 2019 with Fedora Happiness Packets: application period

Outreachy provides remote internship under Free and Open Source Software (FOSS) Communities to the under represented groups in technology. It runs twice an year, mid-year and end of year. I decided to participate in its summer run.

Why Outreachy?

Before I get into anything, as a rule of thumb, I ask myself why? Why is it that I wanted to participate in Outreachy?

It was in the month of September 2018 when I felt like now I can start giving back to the FOSS communities. I tried to explore a bunch of different organisations but it proved hard for me to find my footing in any of them. While exploring I came to know about Outreachy and thought this might be my gateway into FOSS communities.

Apart from the above, I knew that participating in Outreachy would require me to learn and render results not only in the areas I was working on but also the ones that would be new to me. The challenge to go through a steep learning curve was one I was looking forward to!

When in the month of February, Outreachy announced their summer run, I was a happy lass! I ardently filled up my initial application and waited to hear back to find out if I was eligible to participate. Little did I know, next morning would be the beginning to a new journey!

<figure class="wp-block-image"><figcaption>Confirmation email: Initial Application Approved!</figcaption></figure>

Note: Outreachy has strict restrictions when it comes to eligibility criteria and anyone looking to participate should take the Initial Application very seriously.

Choosing the project: Fedora Happiness Packets

As I was browsing the list of projects, I was hoping to find a project with which I could have a two way relationship. Not only did I want to bring value to the project but I also wanted to work in a project that could bring value to my journey as a developer.

Keeping the above in mind, I came across Fedora’s Happiness Packets. The project required an understanding for Django and UI/UX. Since both of them were the areas I had in my mind that I wanted to improve upon, I decided to look further into it.

Fedora Happiness Packets aims to promote recognition of the good work developers dish out by providing a means to send Happiness Packets i.e emails full of appreciation, anonymously or not. The project’s purpose resonated on a high note with me. Appreciation is sparse to content creators world wide and if I can contribute in any small way to bridge that gap, count me in!

Contributing: A roller coaster ride 

After joining the IRC and saying hi, I went on a hunt to find my first issue. Looking at the list of issues, my heart dropped when I realised all the good-first-issues were taken up. After a moment of panic, I found an open issue and started my journey with Fedora with my first comment ever!

<figure class="wp-block-image"><figcaption>Beginning of a new journey with Fedora. Yay!</figcaption></figure>

After having that issue assigned to me, contributing to the project has been a roller coaster ride. Since it wasn’t a beginner issue it was taking me longer than everyone else to solve it. While others were moving onto their third or fourth issue, I was still struggling with my first one, Integrating Fedora Messaging in Fedora Happiness Packets (blog coming soon!).

From there I have come as far as getting four major feature addition PRs merged and several other improvements till the time of writing this. It has been an extremely enriching experience and the one where I got to learn so much! Can’t wait to keep this ball rolling as I continue to contribute to this project.


As these 6 weeks for the Application period are coming to an end, here is a list of things this golden period has taught me.

Passion: Required in abundance 

I’m not going to glorify this period as something that has gone by in a breeze. I have spent many sleepless nights, just trying to figure out why a particular piece of code won’t work. I have struggled to strike a balance between my university schedule, exams and health whilst consistently contributing. But despite all this, it is my passion that has been my fuel throughout this period. Doing what you love really makes the process easy. Don’t let money be the purpose but rather see it as an added benefit!

Keep going on. No matter what!

“If you can’t fly then run, if you can’t run then walk, if you can’t walk then crawl, but whatever you do you have to keep moving forward.”

― Martin Luther King Jr.

During those moments of extreme Nay! when my code just didn’t seem to work, this is what I kept reminding myself. 

Collaboration, not a competition: The ultimate mantra

During the entire duration of the application period I made it my personal goal to help out other applicants as much as possible. Obviously I’m not naive enough to not realise that we are all in this for the same position. But don’t let that hold you back from helping others out in their tasks if you can. After all, isn’t that what FOSS is all about?

Communication is key

It’s daunting to communicate on a public platform. When I sent out my first question in the IRC, I was a bundle of nerves till I got a response. The key to effective communication in a FOSS community is to do research before coming up with a question, practice being utmost patient and follow the basic etiquette of communicating in a FOSS community. It doesn’t hurt to keep in mind that the person on the other side helping us out are volunteering as mentors. They are taking time out of their busy schedules to help us out and are not compelled to do so. The least we can do is make the questions worth their while. Make Googling and Stack OverFlow your new bffs, if they aren’t already.

Step out of your comfort zone: Learn shiny new things!

Contributing to Fedora Happiness Packets required me to explore past my comfort zones. I worked with technologies I hadn’t even heard of before, Docker, Celery, RabbitMQ and Fedora Messaging to name a few. Had I restricted myself to tasks that only fell under my umbrella of knowledge, I would have missed out big time! Yes obviously, it won’t be easy, but the end result would be so worth it. Don’t shy away from getting your hands dirty!

Documentation: Address the elephant in the room

When going through the documentation while implementing a new feature, if I found any part of it wasn’t explanatory enough and needed more clarification, I made sure to add to it. This saves time for anyone else who refers to it again and makes the on boarding experience better. Contribute to documentation, don’t be lazy about it!

No battle is fought alone

Needless to say, I couldn’t have powered through these six weeks without any help. I was introduced to the beauty of FOSS communities in this time. People are so unbelievably helpful and kind, its astonishing!

Fedora’s community is the most helpful one I’ve come across. Shout out to Justin for taking out time from his schedule to help me out with my never ending series of doubts! Thank you so much Justin for being so patient with me. I’m extremely grateful to Jona, Alberto, Jeremy, Aurélien and Angelo for supporting me, giving me valuable advice and extremely helpful pointers throughout the application period. 

Apart from the awesome Fedora community, I’d also like to mention this extremely helpful blog post, What not to do in Outreachy/GSoC by Shivani Bharadwaj, that helped me prepare for the application period. I highly recommend all the aspirants to give this a read!

I find myself immensely lucky to have chosen Fedora as the project I chose to contribute to. The experience has been one that really made me learn so much about my own self and grow as a developer. I can’t wait to keep contributing to Fedora as I wait for the results to come out!

Came for Outreachy, stayed for the community!

Hope you find something of value in this blog post and most importantly, the motivation to approach any summer of code with the best mindset to reap its full benefits!

The post Outreachy 2019 with Fedora Happiness Packets: application period appeared first on Fedora Community Blog.

Fedora at SCaLE 17x (2019) Event Report – Pasadena, California

Posted by Fedora Community Blog on March 26, 2019 08:15 AM

At a Glance: What is SCaLE?

The Fedora Ambassadors gathered statistical feedback from attendees and distributed swag items during SCaLE’s four-day expo.

  • Frequency of the release cycle past Fedora Release 29 trended with guests.
  • Peak visitor days were Friday and Saturday.
  • We collected detailed information for our various Fedora teams. Roll-up found below.

Our Ambassadors/Volunteers in the Field

This report is for the following Ambassadors who were on-site at SCaLE 17x:

  1. Perry Rivera (FAS: lajuggler)
  2. Alex Acosta (FAS: aacosta)
  3. Scott Williams (FAS: vwbusguy)
  4. Brian Monroe (FAS: ParadoxGuitarist)

Supplemental assistance provided by:

  1. Jennifer Madriaga
  2. Iván Chavero (FAS: ichavero)
  3. Brian Exelbierd (FAS: bex)

What is SCaLE?

SCaLE is a rip-roaring, immersive four-day convention covering a variety of free and open source topic presentations, training, and entertainment. This year marks the seventeenth annual event in the general Los Angeles (LA) area, specifically Pasadena.

The SCaLE conference exhibits groundbreaking general technology and Linux ideas from around the globe. The Conference Chair, Ilan Rabinovitch, and Bala (Hriday Balachandran) led our team throughout the registration process and coordinated an enlightening, orchestrated, and all-around fun  event.

Conference Recap

Day 1: 7 March (Thursday)

Initial Booth Setup

Brian arrived in Pasadena on Thursday morning to deliver supplies for the Expo portion of the conference.

He located our exhibit booth, number 312, and dropped off and set up: a banner and the event box.

Perry meanwhile went to FedEx to print out Fedora logo sign-in sheets for people to provide comments/feedback.

The Ambassadors met throughout the day to discuss plans for exhibiting. Brian provided Perry a Thinkpad to perform a Workstation install of Fedora 29.

We also checked into our various hotels. The Sheraton Hotel is adjacent to the convention center and expo hall, and parking appeared convenient and plentiful for Thursday morning but filled rapidly by the afternoon.

The Sheraton furnished a clean and comfortable hotel room.

Iván Chavero arrived later that evening as he had been flying throughout the day. Perry joined him for dinner to bring him up to speed on Fedora team news.

Perry later imported a What’s New in Fedora 29 presentation on the laptop and installed updates.

Day 2: 8 March (Friday)

After lunch, Perry delivered a portable whiteboard, markers, and office supplies. We re-positioned tables in the booth to maximize conversation space and set up chairs for guests to sit and hang out if they needed a place to sit and relax. We also arranged swag and our Fedora laptop setup.

Our Ambassadors observed how SCaLE situated our booth in one of the main middle rows which definitely brought in high traffic.

We set up an initial whiteboard to gather people’s impressions of how they use Fedora.

After the exhibit hall opened, Brian, Perry, and Scott fielded questions by our booth guests. General questions we asked visitors were open-ended (not direct “yes” or “no” answers); this established connections with our guests, encouraged their repeat visits later in the conference, and gave people avenues into further discussion.

Such questions included:

  1. How do you use Fedora?
  2. So tell me what brings you here today?
  3. If not using Fedora, what do you use and why?
  4. Do you have any suggestions or comments for us to pass back upstream to Fedora?

Version 2 of Booth Setup

Since we had a finite amount of swag, we placed a few items here and there to mitigate “swag” vacuuming, and handed premium swag out to 1) really great questions and detailed feedback and 2) people who illustrated they have FAS accounts.

Jennifer Madriaga from Red Hat also stopped in to provide additional swag and to say hello.

Having a fair amount of Ambassadors, we rotated shifts as needed for meal breaks or attending the occasional workshop.

Day 3: 9 March (Saturday)

Alex arrived very early in the morning.

Before the exhibit hall opened, Perry re-set up our display and swag in our Exhibit Hall booth.

Perry then traveled to the other convention building to assist Clint Savage (FAS: herlo), John Bonesio and guests with an all-day Linux InstallFest. While the first half of the day involved providing Fedora install help to attendee’s laptops and virtual machines, the second half of the day comprised guiding students on how to initially configure their new setup.

Meanwhile, Fedora Ambassadors Brian, Scott, Iván, and Alex greeted guests at the expo floor to run the booth. The second day of exhibiting (on day 3 of the conference) brought many guests to our booth.

A snapshot of the final dry board. Topic: How do you Fedora?

Clockwise from the left, Perry, Alex, and Jennifer

Iván later gave a talk on Linux Engineering. Following that, a Game Night took place. Quite a fun and well-attended event! This year’s highlights include two Escape Room options, a video game room, and penguin hors d’oeuvres made from olives and carrots.

The Tux Spectacular

Day 4: 10 March (Sunday)

The final day of exhibiting (on day 4 of the conference) delivered attendees to our booth. To keep things interesting, Perry and Alex passed out different and interesting regular swag and premium swag to encourage new visits by attendees.

Brian meanwhile worked the Sunday Installfest.

By this day, however, guests attended workshops or began returning to home.

A snapshot of the final dry board.

Lessons Learned

  1. We counted at least 44 respondents that asked specifically for DVD distribution media.
  2. We counted at least 10 people who did not know what Fedora is. It was definitely good we were there to provide information!
  3. Brian discovered that we would definitely need more lead time for T-shirt swag and Fedora badges, as neither of those assets arrived on schedule for the event.
  4. More USB thumb drives. Based on the number of visitors we had, I think about 250  USB thumb drives as premium giveaways would be advantageous to distribute.

Future event box suggestions

  1. T-shirts: These were a hit and all disappeared by conference end. Could definitely use more and mixed designs and all sizes, especially larger sizes (L, XL, XXL, XXXL).
  2. T-shirts: Preferably with the new logo
  3. DVD Distribution media. Suprisingly people still ask for these. (see last section)
  4. More USB thumb drives
  5. Candy: Minimal funds for reimbursement for donated candy
  6. Ribbons for badges: Ribbons are gathering popularity and advertising interest at expos and conventions. It might be advantageous to make various sets of these for fun and pass them out.
  7. Stickers: More! Everyone loved them and want to use them for their boxes. Perhaps additional Fedora designs and shapes might garner increasing popularity.
  8. More Meta Key Stickers: These were a hit.
  9. Lanyards for the Ambassadors branded with the Fedora logo: It’s interesting to advocate Fedora while wearing the stock lanyard for a completely different organization because that’s what was received in the registration goodie bag. Having Fedora-branded lanyards for the ambassadors to use at events would add value to our guests of the Fedora way.

Community feedback:
All days

At our booth, we provided a sign-in sheet for visitors to leave feedback, suggestions, and comments about Fedora. The following highlights this feedback.

There were 12 respondents. At least 6 respondents were using the latest release of Fedora (as of this writing, Release 29), 1 respondent was still using one release behind (as of this writing, Release 28), and two are using the developmental release (as of this writing, Release 30/Rawhide). This is better than last year, which had people expressing they were running extremely dated versions of Fedora.

  1. All: 2 respondents had positive feedback Nothing but good things“and “You’re the reason I got my job!“.
  2. Marketing: 2 respondents requested/liked ink pens.
  3. PowerPC: 1 respondent said Keep ppc64le great again!!
  4. Raspberry Pi 3: 1 respondent said Raspberry Pi 3 video driver is upstreamed.
  5. SCaLE: 2 respondents wanted a Birds of a Feather (meetup during the SCaLE conference) [editor note: We tried to add a Fedora Day, but that was not accepted this year in the event program].
  6. ARM64: 1 respondent said ARM64!!! You are all the best! Fractional scaling in GNOME please!
  7. Fedora 28 (down-rev): The respondent’s comment was slightly illegible. From context, it might potentially say “Will update at fedoraproject.org
  8. SoaS Team: 1 respondent was looking for information on SoaS download statistics. [Perry completed an action item and followed up with Brian to relay this information to the respondent].

Final thoughts

Attendees thanked us for Fedora’s conference presence and look forward to our return for SCaLE 18x.

We had a room availability issue that prevented an official Fedora Day from taking place. We also could use more support for swag/badge time-to-event concerns. Hopefully these will be rectified for 2020 (SCaLE 18x).

Ambassador feedback

Based on our post-rollup from Ambassadors, we discovered the following:

  • Concerns from the community on the road-ahead following the recent acquisition.
  • Excitement that Fedora is very much alive, well, and active.
  • We had no T-shirts this year, which resulted in a severe drop in visitors compared to last year.
  • We did have plenty of stickers, which were well-received.

All staff members and guests appeared to enjoy being there. Feedback on talks and training indicated high interest in a Fedora Day track.

That’s all the news from the Fedora Ambassador team and SCaLE 17x. Hope to see you next year!

Perry and Brian look forward to seeing you next year!

The post Fedora at SCaLE 17x (2019) Event Report – Pasadena, California appeared first on Fedora Community Blog.

[F30] Participez à la journée de test consacrée à la modularité

Posted by Charles-Antoine Couret on March 26, 2019 07:00 AM

Aujourd'hui, ce mardi 26 mars est une journée dédiée à un test précis : sur la modularité. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

La modularité est le résultat de la réflexion de Fedora.next, amorcé en 2014. L'objectif est de découpler le cycle de vie des applications avec celui de Fedora afin qu'un utilisateur de Fedora bénéficie de plus de flexibilité. Il serait par exemple possible de choisir une version native de Python plus récente ou plus ancienne que celle disponible par défaut. Auparavant cela n'était possible qu'en choisissant une autre version de Fedora ce qui pouvait être contraignant.

Les modules se comportent comme des dépôts supplémentaires proposant un ensemble de paquets destinés à remplacer ceux des dépôts officiels. Mais bien entendu, tout cela est géré par le projet Fedora avec la même qualité et les mêmes mainteneurs.

Pour le moment Fedora propose quelques modules comme Docker, Django, NodeJS et le langage Go.

Les tests du jour couvrent :

  • Lister les modules disponibles et installés ;
  • Installer un nouveau module ;
  • Activer un nouveau module ;
  • Mettre à jour un module.

Comme vous pouvez le constater, ces tests sont assez simples et ne devraient prendre que quelques minutes seulement. Il vous faudra bien évidemment installer le dépôt modular avant (paquet fedora-repos-modular).

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Contribute at the Fedora Test Day for Fedora Modularity

Posted by Fedora Magazine on March 25, 2019 12:05 PM

Modularity lets you keep the right version of an application, language runtime, or other software on your Fedora system even as the operating system is updated. You can read more about Modularity in general on the Fedora documentation site.

The Modularity folks have been working on Modules for everyone. As a result, the Fedora Modularity and QA teams have organized a test day for Tuesday, March 26, 2019. Refer to the wiki page for links to the test images you’ll need to participate. Read on for more information on the test day.

How do test days work?

A test day is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to do the following things:

  • Download test materials, which include some large files
  • Read and follow directions step by step

The wiki page for the modularity test day has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day web application. If you’re available on or around the day of the event, please do some testing and report your results.

Happy testing, and we hope to see you on test day.

Even more fun with SuperIO

Posted by Richard Hughes on March 25, 2019 11:35 AM

My fun with SuperIO continues, and may be at the logical end. I’ve now added the required code to the superio plugin to flash IT89xx embedded controllers. Most of the work was working out how to talk to the hardware on ports 0x62 and 0x66, although the flash “commands” are helpfully JEDEC compliant. The actual flashing process is the typical:

  • Enter into a bootloader mode (which disables your keyboard, fans and battery reporting)
  • Mark the internal EEPROM as writable
  • Erase blocks of data
  • Write blocks of data to the device
  • Read back the blocks of data to verify the write
  • Mark the internal EEPROM as read-only
  • Return to runtime mode

There were a few slight hickups, in that when you read the data back from the device just one byte is predictably wrong, but nothing that can’t be worked around in software. Working around the wrong byte means we can verify the attestation checksum correctly.

Now, don’t try flashing your EC with random binaries. The binaries look unsigned, don’t appear to have any kind of checksum, and flashing the wrong binary to the wrong hardware has the failure mode of “no I/O devices appear at boot” so unless you have a hardware programmer handy it’s probably best to wait for an update from your OEM.

We also do the EC update from a special offline-update mode where nothing else than fwupd is running, much like we do the system updates in Fedora. All this work was supported by the people at Star Labs, and now basically everything in the LapTop Mk3 is updatable in Linux. EC updates for Star Labs hardware should appear on the LVFS soon.

NeuroFedora update: 2019 week 13

Posted by The NeuroFedora Blog on March 25, 2019 11:18 AM

More software has been submitted for review and included in NeuroFedora. We keep making steady progress on that front. Please keep an eye on our documentation to see what new tools are now available for use in NeuroFedora

We have also submitted an abstract for CNS*2019 to present at poster at the conference introducing NeuroFedora to the computational neuroscience research community. So, we do hope to see you there (Ankur will be at CNS*2019 anyway).

We are always looking for more people to join the team. At the moment, we are looking for people to fill these two roles:

  • Spin/Lab master: to have a ready-to-use downloadable ISO, we'd like to work on a Fedora based NeuroFedora "lab". We are looking for a spin/lab master to lead this goal. (What is a Fedora spin/lab?). The skills needed for this task are:
    • knowledge of Git and Git based workflows: Pagure/Gitlab/Github/Bitbucket.
    • knowledge of how DNF works.
    • knowledge of the Fedora Spin process and associated tools (kickstart files, for example).
  • Documentation master: given how important end-user documentation is, we are looking for a documentation master to ensure ours is up to the mark. For this role, the required skills are:

If any of these roles interest you, please get in touch with the NeuroFedora team. You needn't have these skills already---you can learn these from the NeuroFedora team as you go along.

The next Open NeuroFedora meeting is on the 26th of March at 2200GMT/UTC. We will discuss our progress, and what we need to do next. It is time we started preparing for CNS*2019 too, so we will discuss what software we would like to showcase there.

The meeting will be held on our IRC/Telegram channel. It is open for all to attend. Please pop by!

NeuroFedora is volunteer driven initiative and contributions in any form always welcome. You can get in touch with us here. We are happy to help you learn the skills needed to contribute to the project. In fact, that is one of the major goals of the initiative---to spread technical knowledge that is necessary to develop software for Neuroscience.

Backup on Fedora Silverblue with Borg

Posted by Fedora Magazine on March 25, 2019 08:00 AM

When it comes to backing up a Fedora Silverblue system, some of the traditional tools may not function as expected. BorgBackup (Borg) is an alternative available that can provide backup capability for your Silverblue based systems. This how-to explains the steps for using BorgBackup 1.1.8 as a layered package to back up Fedora Silverblue 29 system.

On a normal Fedora Workstation system, dnf is used to install a package. However, on Fedora Silverblue, rpm-ostree install is used to install new software. This is termed layering on the Silverblue system, since the core ostree is an immutable image and the rpm package is layered onto the core system during the install process resulting in a new local image with the layered package.

“BorgBackup (short: Borg) is a deduplicating backup program. Optionally, it supports compression and authenticated encryption.”

From the Borg website

Additionally, the main way to interact with Borg is via the command line. Reading the Quick Start guide it becomes apparent that Borg is well suited to scripting. In fact, it is pretty much necessary to use some form of shell script when performing repeated thorough backup’s of a system. A basic script is provided in the Borg Quick Start guide , as a point to get started.

Installing Borg

In a terminal, type the following command to install BorgBackup as a layered package:

$rpm-ostree install borgbackup

This installs BorgBackup to the Fedora Silverblue system. To use it, reboot into the new ostree with:

$systemctl reboot

Now Borg is installed, and ready to use.

Some notes about Silverblue and it’s file system, layered packages and flatpaks

The file system

Silverblue is an immutable operating system based on ostree, with support for layering rpm’s through the use of rpm-ostree. At the user level, this means the path that appears as /home in a flatpak, will actually be /var/home to the system. For programs like Borg, and other backup tools this is important to remember since they often require the actual path, so in this example that would be /var/home instead of just /home.

Before starting a backup it’s a good idea to understand where potential data could be stored, and then if that data should be backed up. Silverblue’s file system layout is very specific with respect to what is writable and what is not. On Silverblue /etc and /var are the only places that are not immutable, therefore writable. On a single user system, typically the user home directory would be a likely choice for data backup. Normally excluding Downloads, but including Documents and more. Also, /etc is a logical choice for some configuration options you don’t want to go through again. Take notes of what to exclude from your home directory and from /etc. Some files and subdirectories of /etc you need root or sudo privileges to access.


Flatpak applications store data in your home directory under $HOME/.var/app/flatpakapp, regardless of whether they were installed as user or system. If installed at a user level, there is also data found in $HOME/.local/share/flatpak/app/, or if installed at a system level it will be found in /var/lib/flatpak/app For the purposes of this article, it was enough to list the flatpak’s installed and redirect the output to a file for backing up. Reasoning that if there is a need to reinstall them (flatpaks) the list file could be used to do it from. For a more robust approach, examining the flatpak file system layouts can be done here.

Layering and rpm-ostree

There is no easy way for a user to retrieve the layered package information aside from the

$rpm-ostree status
command. Which shows the current and previous ostree commit’s layered packages, and if any commits are pinned they would be listed too. Below is the output on my system, note the LayeredPackages label at the end of each commit listing.

<figure class="wp-block-image">Terminal output of rpm-ostree status command.</figure>

The command

$ostree log
is useful to retrieve a history of commits for the system. Type it in your terminal to see the output.

Preparing the backup repo

In order to use Borg to back up a system, you need to first initialize a Borg repo. Before initializing, the decision must be made to use encryption (or not) and if so, what mode.

With Borg the data can be protected using 256-bit AES encryption. The integrity and authenticity of the data, which is encrypted on the clientside, is verified using HMAC-SHA256. The encryption modes are listed below.

Encryption modes

Hash/MACNot encrypted no authNot encrypted, but authenticatedEncrypted (AEAD w/ AES) and authenticated
SHA-256noneauthenticatedrepokey keyfile
BLAKE2bn/aauthenticated-blake2repokey-blake2 keyfile-blake2

The encryption mode decided on was keyfile-blake2, which requires a passphrase to be entered as well as the keyfile being needed.

Borg can use the following compression types which you can specify at backup creation time.

  • lz4 (super fast, low compression)
  • zstd (wide range from high speed and low compression to high compression and lower speed)
  • zlib (medium speed and compression)
  • lzma (low speed, high compression)

For compression lzma was chosen at setting 6, the highest sensible compression level. The initial backup took 4 minutes 59.98 seconds to complete, while subsequent ones have taken less than 20 seconds as a rule.

Borg init

To be able to perform backups with Borg, first, create a directory for your Borg repo:

$mkdir borg_testdir

and then change to it.

$cd borg_testdir

Next, initialize the Borg repo with the borg init command:

$borg init -e=keyfile-blake2 .

Borg will prompt for your passphrase, which is case sensitive, and at creation must be entered twice. A suitable passphrase of alpha-numeric characters and symbols, and of a reasonable length should be created. It can be changed later on if needed without affecting the keyfile, or your encrypted data. The keyfile can be exported and should be for backup purposes, along with the passphrase, and stored somewhere secure.

Creating a backup

Next, create a test backup of the Documents directory, remember on Silverblue the actual path to the user Documents directory is /var/home/username/Documents. In practice on Silverblue, it is suitable to use ~/ or $HOME to indicate your home directory. The distinction between the actual path and environment variables being the real path does not change whereas the environment variable can be changed. From within the Borg repo, type the following command

$borg create .::borgtest /var/home/username/Documents

and that will create a backup of the Documents directory named borgtest. To break down the command a bit; create requires a repo location, in this case . since we are in the top level of the repo. That makes the path .::borgtest for the backup name. Finally /var/home/username/Documents is the location of the data we are backing up.

The following command

$borg list

returns a listing of your backups, after a few days it look similar to this:

<figure class="wp-block-image"><figcaption>Output of borg list command in my backup repo.</figcaption></figure>

To delete the test backup, type the following in the terminal

$borg delete .::borgtest

at this time Borg will prompt for the encryption passphrase in order to delete the backup.

Pulling it together into a shell script

As mentioned Borg is an eminently script friendly tool. The Borg documentation links provided are great places to find out more about BorgBackup, and there is more. The example script provided by Borg was modified to suit this article. Below is a version with the basic parts that others could use as a starting point if desired. It tries to capture the three information pieces of the system and apps mentioned earlier. The output of flatpak list, rpm-ostree status, and ostree log as human readable files given the same names each time so overwritten each time. The repo setup had to be changed since the original example is for a remote server login with ssh, and this was intended to be used locally. The other changes mostly involved correcting directory paths, tailoring the excluded content to suit this systems home directory, and choosing the compression.


# This gets the ostree commit data, this file is overwritten each time
sudo ostree log fedora-workstation:fedora/29/x86_64/silverblue > ostree.log

rpm-ostree status > rpm-ostree-status.lst

# Flatpaks get listed too
flatpak list > flatpak.lst

# Setting this, so the repo does not need to be given on the commandline:
export BORG_REPO=/var/home/usernamehere/borg_testdir

# Setting this, so you won't be asked for your repository passphrase:(Caution advised!)
export BORG_PASSPHRASE='usercomplexpassphrasehere'

# some helpers and error handling:
info() { printf "\n%s %s\n\n" "$( date )" "$*" >&2; }
trap 'echo $( date ) Backup interrupted >&2; exit 2' INT TERM

info "Starting backup"

# Backup the most important directories into an archive named after
# the machine this script is currently running on:
borg create                         \
    --verbose                       \
    --filter AME                    \
    --list                          \
    --stats                         \
    --show-rc                       \
    --compression auto,lzma,6       \
    --exclude-caches                \
    --exclude '/var/home/*/borg_testdir'\
    --exclude '/var/home/*/Downloads/'\
    --exclude '/var/home/*/.var/'   \
    --exclude '/var/home/*/Desktop/'\
    --exclude '/var/home/*/bin/'    \
    ::'{hostname}-{now}'            \
    /etc                            \
    /var/home/ssnow                 \


    info "Pruning repository"

    # Use the `prune` subcommand to maintain 7 daily, 4 weekly and 6 monthly
    # archives of THIS machine. The '{hostname}-' prefix is very important to
    # limit prune's operation to this machine's archives and not apply to
    # other machines' archives also:

    borg prune                          \
        --list                          \
        --prefix '{hostname}-'          \
        --show-rc                       \
        --keep-daily    7               \
        --keep-weekly   4               \
        --keep-monthly  6               \


    # use highest exit code as global exit code
    global_exit=$(( backup_exit > prune_exit ? backup_exit : prune_exit ))

    if [ ${global_exit} -eq 0 ]; then
        info "Backup and Prune finished successfully"
    elif [ ${global_exit} -eq 1 ]; then
        info "Backup and/or Prune finished with warnings"
        info "Backup and/or Prune finished with errors"

    exit ${global_exit}

This listing is missing some more excludes that were specific to the test system setup and backup intentions, and is very basic with room for customization and improvement. For this test to write an article it wasn’t a problem having the passphrase inside of a shell script file. Under normal use it is better to enter the passphrase each time when performing the backup.

10th year of FOSSASIA

Posted by Sinny Kumari on March 25, 2019 05:15 AM

This FOSSASIA was special as it marked its 10th year! It was quite impressive to witness a FOSS conference to continue growing this long with growing community. The four day conference schedule was packed with various interesting talks, workshops, hackathon and other engaging activities.

WhatsApp Image 2019-03-23 at 8.46.20 PM

First day of the conference was single track with some insightful talks. This included speakers who have been long term contributors to FOSSASIA such as Harish Pillay and Hong Phuc. Hong talked about various FOSSASIA initiatives such as Open Tech Summit, Science Hack Day India and events conducted along with HackerSpace SG.

Another interesting talk was from Mitch Altman about the TV-B-Gone project. He started it because he was annoyed by TVs playing loud in public spaces. Little did he know that he wasn’t alone and lot of people wanted the device. Mitch went on to create hardware learning kits and  teaches introductory electronics workshops. He motivated a lot of people to go and enjoy making new things.

Another interesting talk was from Huzaifa Sidhpurwala on attacking email encryption and security in general. It was quite interesting to know that the usage of enigmail spiked a lot roughly during 2014 (around the Snowden revelations). The talk also compared S/MIME and OpenPGP approaches to email encryption.

Hardware had a lot of presence at FOSSASIA. There were interesting talks ranging from ARM Development boards to preparing embedded products to be Production ready. From the benchmarks I saw, ARM based devices are getting quite close to their x86 counterparts. Along with ARM64 based servers, the future is bright even for consumer laptops (such as the Pinebook). Also, speaking of the future, we will soon be able to talk to our Coffee Machines! Meanwhile, we do have farmers doing innovative things with Raspberry Pi in Japan 🙂

On last day of conference, I and Sayan talked about Fedora CoreOS and Silverblue respectively. In general I felt that the attendees were quite excited about Fedora CoreOS and the benefits it brings. During Q&A we discussed how the release streams in Fedora CoreOS will be in comparison to Container Linux. Another frequently discussed topic was Podman and benefits of using it over Docker. There was also interest about how CI will operate for Fedora CoreOS. Slides from my talk is available here .


Other than talks, the conference had a lot of activity in the exhibition area as well. We had a CentOS booth (thanks to Rich Bowen!) as well which was very engaging and a place for attendees to ask questions about various Open Source projects from CentOS, Fedora, etc.  There was an awesome demo of Open Firmware projects (like Coreboot, U-Boot etc) and how easy it is to flash FOSS firmware in modern laptops using flashrom. To add to that, I even learnt soldering like a pro! Thanks, Mitch.

WhatsApp Image 2019-03-25 at 10.37.46 AM WhatsApp Image 2019-03-23 at 8.50.30 PM

WhatsApp Image 2019-03-23 at 8.51.13 PM      WhatsApp Image 2019-03-23 at 8.55.48 PM

I must say that  conference was filled with wide range of topic and has something interesting to learn for most of the people. Organizers and volunteers has put really hard work in keeping this year conference awesome and engaging, kudos to all!

Episode 138 - Information wants to be free

Posted by Open Source Security Podcast on March 25, 2019 12:05 AM
Josh and Kurt talk about a prank gone wrong, the reality of when your data ends up public. Once it's public you can't ever put it back. We also discuss Notepad++ no longer signing releases and what signing releases means for the world in general.

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

Show Notes

    Roadmap for Teleirc v1.4

    Posted by Justin W. Flory on March 23, 2019 08:33 PM
    RITlug/teleirc development update

    The RITlug Teleirc developer team celebrated the v1.3 release on March 3rd, 2019. Looking ahead, the team is mapping out next steps for quality-of-life improvements in v1.4.

    What’s coming in Teleirc v1.4

    Teleirc v1.4 is the next feature release of Teleirc. The targeted release date for v1.4 is by the end of April 2019 (i.e. the end of the academic semester for students involved with the project). Following v1.4, the project will likely enter brief hibernation until Fall 2019 when the RIT academic semester begins again.

    At the developer meeting on March 23rd, we discussed the scope of this sprint and what we felt is realistic for project maintainers to work on:

    Primary goals

    • Include limited characters from Telegram replies in relayed IRC message (RITlug/teleirc#51)
    • Create doc page on development environment (RITlug/teleirc#77)
    • QoL Improvements: show file-type of documents in IRC, insert ZWP character in join/leave messages (RITlug/teleirc#130)
    • Allow user to configure more variables for IRC server connection (e.g. port, SSL certs, etc.) (RITlug/teleirc#113)

    Secondary goals

    Recap of Teleirc v1.3 sprint

    The Teleirc v1.3 release follows the v1.2.2 release on December 8th, 2018. This release is a significant change in how project development is done. For the first time, a special interest group inside of RITlug exists around the project. The team shifted to an agile-like development practice to fit inside of the RIT student academic schedule.

    A special shout-out is earned by Tim Zabel for his support and participation as a core contributor during the v1.3 sprint.

    Get involved with Teleirc!

    More opportunities are coming to participate with Teleirc! We would love to have more people get involved and participate in the project. There is no formal commitment to contributing, although we ask for participation through a single sprint cycle.

    Soon, we will have better new contributor on-boarding docs. Our weekly developer meetings are now happening over public audio/video call each Saturday at 15:00 US EDT, so anyone can join and participate.

    Come say hello in our developer chat rooms, either on IRC or in Telegram!

    The post Roadmap for Teleirc v1.4 appeared first on Justin W. Flory's Blog.

    Chemnitzer Linux Tage 2019

    Posted by Fabian Affolter on March 23, 2019 01:09 PM

    Once again, Robert and I went to Chemnitz. We don’t wanted to break with the tradition of having a Fedora Project booth at the Chemnitzer Linux Tage. Robert is representing the Fedora Project at CLT for over a decade now.

    To show the visitors a running Fedora installation Raphael decided to take a larger screen, mounted it on a stand and placed a Raspberry Pi behind it. Pretty straight-forward setup but there is always an issue with the VESA connection on the back of the screen.

    <figure class="wp-block-image"></figure>

    Lucky us, there are no more people who are asking for live media. I guess that now everybody knows how to use an USB stick/key to get an installation going. So, they went with a sticker or a pen.

    <figure class="wp-block-image"></figure>

    I’m not going to talk about the swag more here as I already did on Twitter and the Ambassadors mailing list. I just want to remember everybody: There was a reason that we made a FAD (Fedora Ambassadors Day/Fedora Activity Day) every year to discuss swag and event. This prevented us from failures like the “stack-a-ribbon” awards.

    During the event I needed to switch my hats again. CLT is also always a little bit about Home Assistant. We got our third Thomas-Krenn award. This was every unexpected and a really nice surprise, especially as it was the first place. Thanks to that people came by our booth and asked about it. And running Home Assistant on Fedora IoT is just awesome. Fedora IoT is far from perfect but it shows where we are heading and with greenboot it will get a feature that make our lives easier.

    Last year we shared the space with OpenSuSE, this year it was Debian. It was pretty cool to have them as our “neighbor”. Different approaches and ideas but the same target.

    It’s very interesting that an event like CLT is able to maintain a more or less a constant number of visitors. Sure, sometimes it felt that there were not that much people around but 20 minutes later the whole place was flooded with visitors. I assume that the trick it to keep the event to a reasonable size, trying not to grow every years and to have fun.

    A preliminary review of /e/

    Posted by Kevin Fenzi on March 23, 2019 01:10 AM

    I’ve been running LineageOS on my phone for a while now (and cyanogenmod before that) and been reasonably happy overall. Still even LineageOS is pretty intertwined with the google ecosystem and worries me, especially given that google is first and foremost an ad company.

    I happened to run accross mention of /e/ somewhere and since LineageOS did a jump from being based on ASOP15 to ASOP16 which required a new install anyhow, I decided to check it out.

    As you may have gathered from the above, /e/ is a phone OS and platform, forked off from LineageOS14.1. It’s located at https://e.foundation based in france (a non profit) headed by Gaël Duval, who Linux folks may know from his Mandrake/Mandriva days. The foundation has a lot of noble goals, starting with “/e/’s first mission is to provide everyone knowledge and good practices around personal data and privacy.” They also have a slogan “Your data is your data!”

    I downloaded and installed a 0.5 version here. Since I already had my phone unlocked and TWRP recovery setup, I just backed up my existing LineageOS install (to my laptop), wiped the phone and installed /e/. The install was painless and since (of course) there’s no google connections wanted, I didn’t even have to download a gapps bundle. The install worked just fine and I was off and exploring:

    The good:

    • Most everything worked fine. Basically if it worked in LineageOS 14.1, it works here (phone, wifi, bluetooth, etc)
    • Many of the apps I use with my phone seem fine: freeotp, signal, twidere, tiny tiny rss reader, revolution irc are all the same apps I am used to using and are install-able from f-droid just fine.
    • There is of course no google maps anymore, but this was a great chance to try out OsmAnd, which has come a very long way. It’s completely usable except for one thing: The voice navigation uses TTS voices and it sounds like a bad copy of Stephen Hawking is talking to you. Otherwise it’s great!
    • My normal ebook reader app is available: fbreader, but I decided to look around as it’s getting a bit long in the tooth. I settled so far on KOReader, which was orig a kobo app, but works pretty nicely on this OS as well.
    • For podcasts I had been using dogcatcher, but now I am trying out AntennaPod.
    • The security level of the image I got was March 2019, so they are keeping up with at least the “android” security updates now.

    The meh:

    • The fdroid app isn’t pre-installed, but it’s easy to install it. They plan to have their own store for apps that will just show additional information over the play store, etc.
    • There is ‘fennec’ in f-droid. You can’t seem to install firefox as all download links lead to the play store.
    • I had been using google photos to store backups/easy web access versions of pictures and movies I took, but of course now I just need to look into alternatives. Perhaps syncthing.

    The bad:

    • A few apps I was using are of course non free and not available in f-droid: tello, vizio smartcast, various horrible IOT smart things apps, my credit unions silly app, etc. tello works fine if you can find a apk not on the play store. vizio smartcast seems to fail asking for location services (which should work, but oh well).
    • Untappd doesn’t seem to have a .apk easily available, so I guess twitter will be spared my been drinking adventures. 🙂
    • Some infosec folks looked closely and there was still some traffic to google: https://infosec-handbook.eu/blog/e-foundation-first-look/#e-foundation but they had a very reasonable reply I thought (not trying to reject or ignore anything): https://hackernoon.com/leaving-apple-google-how-is-e-actually-google-free-1ba24e29efb9

    The install is all setup with MicroG. “A free-as-in-freedom re-implementation of Google’s proprietary Android user space apps and libraries.” It does a pretty good job pretending to be google for apps that need some google bits.

    In addition to the OS, /e/ folks have a server side setup as well. I didn’t play with it too much as I am waiting for their promised containerized versions of the server side so I can run them myself. These provide replacements for google drive, notes, address book, mail, etc.

    The name /e/ is a bit strange to try and pronounce, or search for. Turns out they had another name at first, but someone else was using it and took exception. There is some mention that they are going to rename things before the magic 1.0 comes.

    All in all I think I am going to keep using /e/ for now. Keeping up on security and the ability to make me look at open source alternatives to the various apps I use seems pretty nice to me. I do hope it catches on and more folks start to use it.

    Fedora 30 Modularity Test Day 2019-03-26

    Posted by Fedora Community Blog on March 22, 2019 07:52 PM
    F30 Modularity test day

    Tuesday, 2019-03-26  is the Fedora 30  Modularity Test Day!
    We need your help to test if everything runs smoothly

    Why Modularity Test Day?

    Featuring one of major change[1] of Fedora 29  we would test to make sure that all the functionalities are performing as they should.
    Modularity is testable today on any Workstation, Labs, Spins  and we will focus on testing the functionality.
    It’s also pretty easy to join in: all you’ll need is Fedora 30 (which you can grab from the wiki page).

    We need your help!

    All the instructions are on the wiki page, so please read through and come help us test! As always, the event will be in #fedora-test-day on Freenode IRC.

    Share this!

    Help promote the Test Day and share the article in your own circles! Use any of the buttons below to help spread the word.

    The post Fedora 30 Modularity Test Day 2019-03-26 appeared first on Fedora Community Blog.

    Participating at #Scale17x

    Posted by Alejandro Acosta on March 22, 2019 06:22 PM

    Everytime somebody asks me about Scale I can only think of the same: Scale is the most important community lead conference in North America and it only gets better by the years. This year it celebrated its seventeenth edition and it just struck me: with me being there this year, there have been more Scales I have attended than I have not. This is my nineth conference out of 17.

    The first time that I attended it was 2011,  it was the edition followed by FudCon Tempe 2010 which happened to be my first Fedora conference and it was also the first time I got to meet some contributors that I had previously collaborated with, many of which I still consider my brothers.

    As for this time, I almost didn’t make it as my visa renewal was resolved on Friday’s noon, one day after the conference started. I recovered it that same day and book a flight in the night. I couldn’t find anything to LAX -as I regularly fly- so I had to fly to Tijuana and from there I borrowed a cart to Pasadena. Long story short: I arrived around 1:30 AM on Saturday.

    That is water under the bridge, a few hours later I was prepared to start the activities for the day. I met my good Fedora friends Scott Williams, Brian Monroe, Perry Rivera and -making his first Scale conference- Ivan Chavero who is with Red Hat and has been very active promoting Fedora in my hometown, he’s not an ambassador but he has helped me a lot in all of the Fedora activities that we have in Chihuahua.

    That day started up with the keynote by Hashicorp’s Mitchell Hashimoto speaking on the transformation of the company starting from a Dorm Room OSS project.

    From there, it was all booth duty for the remain of the conference.

    Perry Rivera was assisting Clint Savage with the install fest happening in a separated building, so for most of  that day it was only Brian, Scott and me in booth duty. Saturday is always the most active day in the expo floor, and this year it was not an exception. We had visitors continually and many Fedora users and enthusiasts approaching to us just to talk about how their Fedora experiences or with specific questions we were glad to clarify.  At the booth we had a sign up list and a card board in which users could write How they do Fedora, it was fun and gratifying looking at those answers.

    I think this year we got an excellent location within the exposition floor that allowed a lot of traffic coming through our booth. (See below)

    It is always pleasant to say hello to our good friends and members of other communities. We could say hi to Jason Hibbets and Rikki Endsley from  OpenSource.com and Jennifer Madriaga, Brian Proffit and Karsten Wade from Red Hat among others.


    <script async="async" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

    When expo floor closed, we still had a chance to attend a few talks, like Ivan Chavero’s “A Linux Engineer in Shark Tank” and also the Kubernetes BoF and the UpScale talks, always very fresh and informative.  We closed that day with the traditional Game Night where we had the chance to have a good time and continue networking with the conference attendees.

    As for Sunday, March 10th, the Daylight savings started so the day “felt” a little weird. The exhibit hall opened at 10:00AM and we noticed a smaller attendance, this again is normal for the last day. The floor was open for only 4 hours on Sunday. This time it was Brian who helped on the Install Fest so for then it was only Perry and myself working on the booth. Still people approaching to us and it is always satisfactory when students show interest if Fedora. This year I could also notice an increase on the spanish speaking attendees, which is also formidable to help promote Fedora among them.

    I leave you with a few pictures that I manage to take, but -as usual- they cannot get to describe the experience.

    Would I make to Scale18th? Only God $DEITY knows

    Do I want to attend it? You can bet anything that I do 🙂




    Obilježavanje Dana slobode dokumenata 27. ožujka 2019. u Rijeci

    Posted by HULK Rijeka on March 22, 2019 05:56 PM

    Obilježavanje Dana slobode dokumenata u srijedu, 27. ožujka 2019. godine u Rijeci održat će se u zgradi Sveučilišnih Odjela Sveučilišta u Rijeci, Radmile Matejčić 2, u prostoriji O-028, s početkom u 16 sati.

    Program obilježavanja Dana slobode dokumenata u Rijeci je sljedeći:

    • 16:00 — 16:30 Zašto slavimo Dan slobode dokumenata: OpenOffice.org, LibreOffice i OpenDocument (Vedran Miletić)
    • 16:35 — 16:55 reStructuredText: običan tekst, samo strukturiran (Mia Doričić)
    • 17:00 — 17:15 Alat za upravljanje referencama na literaturu Zotero (Patrik Nikolić)

    Nakon programa imat ćemo vremena za diskusiju i prigodno čašćenje po uzoru na našu proslavu izlaska LibreOfficea 3.3.

    <figure class="wp-block-image">LibreOffice 3.3. cake<figcaption>Mi u HULK-u smo slavili izlaske LibreOfficea prije nego je to postalo kul.</figcaption></figure>

    Nadamo se vašem dolasku!

    Parental Controls and Metered Data Hackfest

    Posted by Allan Day on March 22, 2019 05:01 PM

    This week I participated in the Parental Controls and Metered Data Hackfest, which was held at Red Hat’s London office.

    Parental controls and metered data already exist in Endless and/or elementary OS in some shape or form. The goal of the hackfest was to plan how to upstream the features to GNOME. It’s great to see this kind of activity from downstreams so I was very happy to contribute in my capacity as an upstream UX designer.

    There have been a fair few blog posts about the event already, so I’m going to try and avoid repeating what’s already been written…

    Parental controls

    Parental controls sound like a niche feature, but they actually have wider applicability than limiting what the kids can do with your laptop. This is because the same features that are used by parental controls can be useful for other types of functionality, particularly around “digital well-being”. For example, a parent might want to limit how much time their child spends using the computer, but someone might want to self-impose this same limit on themselves, in order to try and lead a healthier lifestyle.

    Furthermore, outside of parental controls, the same functionality can be pitched in different ways. A feature like limiting the use of particular apps to certain times of the day could either be presented as a “digital well-being” feature, where the goal is to be happier and healthier, or as a “productivity” feature, where the goal is to help someone get more out of their time in front of the screen.

    There are some interesting user experience questions that need to be answered here, such as to what extent we should focus on particular use cases, as well as what those use cases should be.

    We discussed these questions a bit during the hackfest, but more thought is going to be necessary. The other next step will be to figure out what the initial MVP should be for these features, since they could potentially be quite extensive.

    Metered data

    Metered network connections are those that either have usage limits attached to them, or those which have financial costs for usage. In both cases this requires that we limit automatic/background network usage, as well as potentially showing warnings if the user is doing something that could result in high data usage.

    My main interest in this area is to ensure that GNOME behaves correctly when people use mobile broadband, either by tethering their phone or when using a dedicated mobile broadband connection. (There’s nothing more frustrating than your laptop silently chewing through your data plan.)

    The first target for this work is to make sure that automatic software updates behave well, but there’s some other interesting work that could come out of it, particularly around controls for whether unfocused or backgrounded apps are allowed to use the network.

    Philip Withnall has created a survey to find out about peoples’ experiences using metered data. Please fill it out if you haven’t already!


    The hackfest was a great event, and I’d like to thank the following people and organisations for making it possible:

    • Philip Withnall for organising the event
    • The GNOME Foundation for sponsoring me to attend
    • Red Hat for providing the venue

    Not posting here means not there is nothing done

    Posted by Sirko Kemter on March 22, 2019 04:51 PM

    I looking with fears to this strange ideas Mindshare has for the future of the Ambassadors. You can not write reports if you not have an event, so I telling here now how hard it is in this country to organize an event.

    Since October 2018 I search for a place which would host the next Translation Sprint. We have tons of co-working spaces or NGO’s which have space available. But is always the same I asked e.g. Open Institute, answer we can host you just on Saturday. And I had actually to write there several times and even make calls because I got no answer for the first contact. The same on The Desk, we can host you only on Saturday. This makes no sense in Cambodia, it is a regular working day, because they have 28 holidays. So most people have to work until 2pm. What sucked on this one, I was working on it since end of January. So first meeting was setup for 11th March, I went there but nobbody there to meet me. This is normal cambodian working style I dont tell I am busy and cant meet you and give you an alternative time. Well the promised mail with an alternative time never arrived, so I had to ask for it again. Second meeting was then this Monday, I spent an hour with them with the useless result of “just Saturday”. But there is light on the horizon OpenDevelopment might host us but here just on Sunday, which is for us better then just Saturday. So six months, hundreds of mails and several meetings and achieved nothing. How easy is it to setup a Fedora Womans Day in the Pune office, compared to this and then just travel around the world to visit other events and this is then called “active”


    Also for the “different Release Party” I have a lot of trouble, I contacted PNC back in October to repeat the event. The sad news for me after Benoit Pitet also John Munger left, leaves me with Cambodians to work so again explaining things the Europeans did realize without the need to tell them. I show you here the quote I got back in November:

    Dear Gnokii,
    It is very interesting, but Fedora is not the one which matches with our students studying.
    Therefore, I was wondering if you could offer our CentOS, it will be the best for us.

    Best regards,


    I never signed a mail as gnokii to them, that shows their level of education. I will try it again, actually I try to contact their “External Relations Manager” which I have amongst my friends on facebook but no luck so far. So I might write again and try to setup a meeting with Maud Lhuillier as head of PN in Asia. I have a bit of a wild idea, so let’s see if this works out. So let’s see….

    So as you can see, there is a lot going on even something doesnt happen, so how wants Mindshare measure if there is activity or not?

    FPgM report: 2019-12

    Posted by Fedora Community Blog on March 22, 2019 03:46 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 30 Beta is No-Go. Another Go/No-Go meeting will be held on Thursday. 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. The Fedora 30 Beta Go/No-Go and Release Readiness meetings are next week.


    Meetings and test days

    Fedora 30 Status

    Fedora 30 Beta was declared No-Go. The target release date moves to 2019-04-02.

    Blocker bugs

    Bug IDBlocker statusComponentBug Status


    An updated list of incomplete changes is available in Bugzilla.

    The Firefox Wayland By Default On Gnome change is postponed to Fedora 31.

    FESCo will vote on including the Mono 5 change in Fedora 30 as well as Fedora 31.

    Fedora 31 Status



    Submitted to FESCo

    Approved by FESCo

    The post FPgM report: 2019-12 appeared first on Fedora Community Blog.

    FAS username search in Fedora Happiness Packets

    Posted by Fedora Community Blog on March 22, 2019 08:15 AM
    Fedora Happiness Packets - project update
    <figure class="aligncenter"></figure>

    I have been recently working on incorporation of Fedora Accounts System’s username search functionality in the project “Fedora Happiness Packets”. After weeks of working, it’s so overwhelming to see its on the verge of completion and being incorporated in the project.

    About the project

    The search functionality is used to find the name and email address of Fedora Accounts System’s users from their username, making it a lot easier for any sender to send happiness packets to a particular user with the knowledge of just their username.

    Getting started with python-fedora API

    For incorporating the search, python-fedora API is used to retrieve the data. After authenticating as a genuine fas-user by passing credentials to AccountSystem, we can retrieve the data using the method person_by_username of a fas2 object.

    Problems encountered

    The solution to the problem statement was simple. What made the process challenging was lack of proper documentation of the Python-Fedora module. Since credentials like FAS username and FAS password were required for authenticating the user, the main goal was to use the data while the user logs into Fedora Happiness Packets.

    I was aiming to use OpenID Connect, the client id, client secret which is used while registering the application to the OpenID provider (Ipsilon in this case). But the fas-client we have in python-fedora does not support OpenID Connect Authentication. This was the major problem which created a major stuck in the proceeding.

    Another setback was Django’s crispy forms. Since we are using Crispy forms to create models and render the layout in the front end, it was difficult for me to access individual form elements since the whole concept was very new to me.

    Quick fix

    After getting solution recommendation from other admins of Fedora, I finally got a solution to pass through. Since the search functionality requires only an authenticated user, which necessarily may not be the user who logs in, we can use a testing Username and testing Password in the case of development environment. For testing, we can make a json file from where the original credentials and the values are read into the project.

    What I learnt?

    I worked in Django for the very first time and it was such an overwhelming experience. I got to learn most of the concepts of Django. How it works, how the data flows, how data gets rendered in the front end, etc. The concept of Django’s Crispy forms was something really new to me and I learnt how to deal with the it. Every time, I rely on documentation to get into details, but for the first time I was successfully able to get what is actually happening by going through the code manually.

    My experience

    I had really enjoyed working with such an welcoming community. Almost all of my doubts are cleared during this application process. What actually I learnt that I am gonna keep with myself forever is, “There is always an alternative solution to any problem! We just need to minimize the gap between its actual existence and our knowledge of its being”.

    Vote of Thanks!

    Thanks to Justin (@jflory7) for helping me with my piles of doubts and queries. Jona (@jonatoni) was very kind to find explicit time to frame my ideas, thanks to her. A special thanks to Clement (@cverna) for helping me proceed with a viable solution, during one of the major hurdle I faced.

    Thank you 🙂

    The post FAS username search in Fedora Happiness Packets appeared first on Fedora Community Blog.

    Fedora Security Lab

    Posted by Fabian Affolter on March 22, 2019 08:14 AM

    The Fedora Security Lab was released as part of the Fedora 30 Candidate Beta cycle.

    Grab it, test it and report back.

    This time we don’t want to miss the release because of some last minute changes.

    How to set up Fedora Silverblue as a gaming station

    Posted by Fedora Magazine on March 22, 2019 08:00 AM

    This article gives you a step by step guide to turn your Fedora Silverblue into an awesome gaming station with the help of Flatpak and Steam.

    Note: Do you need the NVIDIA proprietary driver on Fedora 29 Silverblue for a complete experience? Check out this blog post for pointers.

    Add the Flathub repository

    This process starts with a clean Fedora 29 Silverblue installation with a user already created for you.

    First, go to https://flathub.org/home and enable the Flathub repository on your system. To do this, click the Quick setup button on the main page.

    <figure class="wp-block-image"><figcaption>Quick setup button on flathub.org/home</figcaption></figure>

    This redirects you to https://flatpak.org/setup/ where you should click on the Fedora icon.

    <figure class="wp-block-image"><figcaption>Fedora icon on flatpak.org/setup</figcaption></figure>

    Now you just need to click on Flathub repository file. Open the downloaded file with the Software Install application.

    <figure class="wp-block-image"><figcaption>Flathub repository file button on flatpak.org/setup/Fedora</figcaption></figure>

    The GNOME Software application opens. Next, click on the Install button. This action needs sudo permissions, because it installs the Flathub repository for use by the whole system.

    <figure class="wp-block-image"><figcaption>Install button in GNOME Software</figcaption></figure>

    Install the Steam flatpak

    You can now search for the Steam flatpak in GNOME Software. If you can’t find it, try rebooting — or logout and login — in case GNOME Software didn’t read the metadata. That happens automatically when you next login.

    <figure class="wp-block-image"><figcaption>Searching for Steam</figcaption></figure>

    Click on the Steam row and the Steam page opens in GNOME Software. Next, click on Install.

    <figure class="wp-block-image"><figcaption>Steam page in GNOME Software</figcaption></figure>

    And now you have installed Steam flatpak on your system.

    Enable Steam Play in Steam

    Now that you have Steam installed, launch it and log in. To play Windows games too, you need to enable Steam Play in Steam. To enable it, choose Steam > Settings from the menu in the main window.

    <figure class="aligncenter"><figcaption>Settings button in Steam</figcaption></figure>

    Navigate to the Steam Play section. You should see the option Enable Steam Play for supported titles is already ticked, but it’s recommended you also tick the Enable Steam Play option for all other titles. There are plenty of games that are actually playable, but not whitelisted yet on Steam. To see which games are playable, visit ProtonDB and search for your favorite game. Or just look for the games with the most platinum reports.

    <figure class="wp-block-image"><figcaption>Steam Play settings menu on Steam</figcaption></figure>

    If you want to know more about Steam Play, you can read the article about it here on Fedora Magazine:

    <figure class="wp-block-embed is-type-rich is-provider-fedora-magazine">
    Play Windows games on Fedora with Steam Play and Proton
    <iframe class="wp-embedded-content" data-secret="Dy6P5e7S04" frameborder="0" height="338" marginheight="0" marginwidth="0" sandbox="allow-scripts" scrolling="no" security="restricted" src="https://fedoramagazine.org/play-windows-games-steam-play-proton/embed/#?secret=Dy6P5e7S04" title="“Play Windows games on Fedora with Steam Play and Proton” — Fedora Magazine" width="600"></iframe>


    You’re now ready to play plenty of games on Linux. Please remember to share your experience with others using the Contribute button on ProtonDB and report bugs you find on GitHub, because sharing is nice. 🙂

    Photo by Hardik Sharma on Unsplash.

    Cockpit 190

    Posted by Cockpit Project on March 22, 2019 12:00 AM

    Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 190.

    Logs: Filter log entries by service

    Filtering logs by service

    The Logs page now allows you to only view the logs for a specific service.

    Machines: Support for Pausing/Resuming VMs

    Pause and Resume operations for VMs

    You can now pause a running VM or resume a paused a VM.

    Thanks to Simon Kobyda for this feature!

    Machines: Make Autostart property of a Virtual Network configurable

    Autostart property for Virtual Networks

    Thanks to Simon Kobyda for this feature!

    Machines: Support for creating VM with option to boot from PXE

    You can now choose Network boot when creating a new VM. Supported sources are libvirt Virtual Networks and host network devices used with direct assignment.

    Create VM with Network boot

    Accessibility improvements

    Dropdowns in all pages are now properly accessible and allow keyboard navigation.

    Try it out

    Cockpit 190 is available now:

    Fedora 29 : Testing the dnf python module.

    Posted by mythcat on March 21, 2019 07:41 PM
    Today we tested with Fedora 29 a python module called DNF.
    All users have used this tool.
    This python module is not very documented on the internet.
    A more complex example can be found on DNF tool documentation.
    I tried to see what I can get from this module.
    Let's start installing it with the pip tool:
    $ pip install dnf --user
    Here are some tests that I managed to run in the python shell.
    [mythcat@desk ~]$ python
    Python 2.7.15 (default, Oct 15 2018, 15:26:09)
    [GCC 8.2.1 20180801 (Red Hat 8.2.1-2)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import sys
    >>> import dnf
    >>> dir(dnf)
    ['Base', 'Plugin', 'VERSION', '__builtins__', '__doc__', '__file__', '__name__', '__package__',
    '__path__', '__version__', 'base', 'callback', 'cli', 'comps', 'conf', 'const', 'crypto', 'db',
    'dnf', 'dnssec', 'drpm', 'exceptions', 'goal', 'history', 'i18n', 'lock', 'logging', 'match_counter',
    'module', 'package', 'persistor', 'plugin', 'pycomp', 'query', 'repo', 'repodict', 'rpm', 'sack',
    'selector', 'subject', 'transaction', 'unicode_literals', 'util', 'warnings', 'yum']
    >>> import dnf.conf
    >>> print(dnf.conf.Conf())
    assumeno: 0
    assumeyes: 0
    autocheck_running_kernel: 1
    bandwidth: 0
    best: 0
    >>> import dnf.module
    >>> import dnf.rpm
    >>> import dnf.cli
    >>> base = dnf.Base()
    >>> base.update_cache()
    This read all repositories:

    >>> base.read_all_repos()
    You need to read the sack for querying:

    >>> base.fill_sack()
    >>> base.sack_activation = True</dnf>
    Create a query to matches all packages in sack:

    >>> qr=base.sack.query()
    Get only available packages:

    >>> qa=qr.available()
    Get only installed packages:

    >>> qi=qr.installed()
    >>> q_a=qa.run()
    >>> for pkg in qi.run():
    ... if pkg not in q_a:
    ... print('%s.%s' % (pkg.name, pkg.arch))
    Get all packages installed on Linux:

    >>> q_i=qi.run()
    >>> for pkg in qi.run():
    ... print('%s.%s' % (pkg.name, pkg.arch))
    You can see more about the Python programming language on my blog.

    PHP version 7.2.17RC1 and 7.3.4RC1

    Posted by Remi Collet on March 21, 2019 04:11 PM

    Release Candidate versions are available in testing repository for Fedora and Enterprise Linux (RHEL / CentOS) to allow more people to test them. They are available as Software Collections, for a parallel installation, perfect solution for such tests (for x86_64 only), and also as base packages.

    RPM of PHP version 7.3.4RC1 are available as SCL in remi-test repository and as base packages in the remi-test repository for Fedora 30 or remi-php73-test repository for Fedora 27-29 and Enterprise Linux.

    RPM of PHP version 7.2.16RC1 are available as SCL in remi-test repository and as base packages in the remi-test repository for Fedora 28-29 or remi-php72-test repository for Fedora 27 and Enterprise Linux.


    emblem-notice-24.pngPHP version 7.1 is now in security mode only, so no more RC will be released.

    emblem-notice-24.pngInstallation : read the Repository configuration and choose your version.

    Parallel installation of version 7.3 as Software Collection:

    yum --enablerepo=remi-test install php73

    Parallel installation of version 7.2 as Software Collection:

    yum --enablerepo=remi-test install php72

    Update of system version 7.3:

    yum --enablerepo=remi-php73,remi-php73-test update php\*

    Update of system version 7.2:

    yum --enablerepo=remi-php72,remi-php72-test update php\*

    Notice: version 7.3.4RC1 in Fedora rawhide for QA.

    emblem-notice-24.pngEL-7 packages are built using RHEL-7.6.

    emblem-notice-24.pngRC version is usually the same as the final version (no change accepted after RC, exception for security fix).

    Software Collections (php72, php73)

    Base packages (php)

    Small history about QA

    Posted by Remi Collet on March 21, 2019 03:10 PM

    Despite I'm mainly a developer, I now use most of my time on doing QA on PHP projects.

    Here is, around release of versions7.2.17RC1 and 7.3.4RC1 a report which should help to understand this activity.


    1. Presentation

    Usually, tests are done by PHP developers, particularly thanks to travis and then by users who will install the RC version available 2 weeks before a GA version.

    The PHP project follow a release process (cf README.RELEASE_PROCESS) which gives 2 days between the preparation of a version, the Tuesday on git, and the Thursday its announcement in the mailing lists. These 2 days are especially designed to allow the build of binary packages (mostly by Microsoft and often by me for my repository) and to allow a last QA check which mays allow to discover some late issue.

    When the new versions were available (on Tuesday afternoon) I start building the packages for my repostiory, givinf more coverage than the current travis configuration:

    • Fedora 27 to 31
    • RHEL 6, 7 and 8-Beta
    • i386 and x86_64
    • NTS and ZTS
    • various compiler versions  (GCC 4 to 9) and system library versions

    I also run the build of the 7.3.4RC1 package in Fedora rawhide to trigger the re-build of all the PHP stack in Koschei, one of the CI tools of the Fedora project.

    Notice : time to build all the packages for all the targets is about 3h for each version !  (I really need a faster builder).


    2. Discoverd issues

    2.1. Failed tests with pcre2 version 10.33RC1

    Already available in rawhide, this version introduce a change in some error message, making 2 tests to fail.

    Minor issue, fixed in PHP 7.3+: commit c421d9a.

    2.2. Failed tests on 32-bit

    In fix of bug #76117 the output of var_export have changed, make 2 tests to fail on 32-bit.

    After confirmation by the autor of the change, tests have been fixed in PHP 7.2+ : commits a467a89 and 5c8d69b.

    2.3. Regression

    Koschei allow to discover very quickly a important regression in the run of the "make test" command. After digging, this regression was introduced in the fix of bug #77609, read the comments on the commit 3ead672.

    After discussion between the Release managers, it have been choosen to:

    • revert this change to get back to a sane situation
    • to re-run the release process (new tag onr git)

    The version which wil be announced shortly will not be affected byt this regression.


    3. Conclusion

    To ensure of the quality of PHP, of no regression is a complex, long and serious work. Thanks to all the actors, developers, QA team and users, this works pretty well.

    So, if you use PHP in a development environment, it is essential to install the RC versions to detect and report us quickly any problem, so we can react before the finale version.

    For users of my repository, the RC versions of PHP and various extensions are nearly always available in the testing repositories.


    Don't trust me. Trust the voters.

    Posted by Daniel Pocock on March 21, 2019 09:07 AM

    On 9 March, when I was the only member of the Debian community to submit a nomination and fully-fledged platform four minutes before the deadline, I did so on the full understanding that voters have the option to vote "None of the above".

    In other words, knowing that nobody can win by default, voters could reject and humiliate me.

    Or worse.

    My platform had been considered carefully over many weeks, despite a couple of typos. If Debian can't accept that, maybe I should write typos for the White House press office?

    One former leader of the project, Steve McIntyre, replied:

    I don't know what you think you're trying to achieve here

    Hadn't I explained what I was trying to achieve in my platform? Instead of pressing the "send put down" button, why not try reading it?

    Any reply in support of my nomination has been censored, so certain bullies create the impression that theirs is the last word.

    I've put myself up for election before yet I've never, ever been so disappointed. Just as Venezuela's crisis is now seen as a risk to all their neighbours, the credibility of elections and membership status is a risk to confidence throughout the world of free software. It has already happened in Linux Foundation and FSFE and now we see it happening in Debian.

    In student politics, I was on the committee that managed a multi-million dollar budget for services in the union building and worked my way up to become NUS ambassador to Critical Mass, paid to cycle home for a year and sharing an office with one of the grand masters of postal voting: Voters: 0, Cabals: 1.

    Ironically, the latter role is probably more relevant to the skills required to lead a distributed organization like Debian. Critical Mass rides have no leader at all.

    When I volunteered to be FSFE Fellowship representative, I faced six other candidates. On the first day of voting, I was rear-ended by a small van, pushed several meters along the road and thrown off a motorbike, half way across a roundabout. I narrowly missed being run over by a bus.

    It didn't stop me. An accident? Russians developing new tactics for election meddling? Premonition of all the backstabbings to come? Miraculously, the Fellowship still voted for me to represent them.

    Nonetheless, Matthias Kirschner, FSFE President, appointed one of the rival candidates to a superior class of membership just a few months later. He also gave full membership rights to all of his staff, ensuring they could vote in the meeting to remove elections from the constitution. Voters: 0, Cabals: 2.

    My platform and photo for the FSFE election also emphasizes my role in Debian and some Debian people have always resented that, hence their pathological obsession with trying to control me or discredit me.

    Yet in Debian's elections, I've hit a dead-end. The outgoing leader of the project derided me for being something less than a "serious" candidate, despite the fact I was the only one who submitted a nomination before the deadline. People notice things like that. It doesn't stick to me, it sticks to Debian.

    I thank Chris Lamb for interjecting, because it reveals a lot about today's problems. A series of snipes like that, usually made in private, have precipitated increasing hostility in recent times.

    When I saw Lamb's comment, I couldn't help erupting in a fit of laughter. The Government of Lamb's own country, the UK, was elected under the slogan Strong and stable leadership. There used to be a time when the sun never set on the British empire, today the sun never sets on laughter about their lack of a serious plan for Brexit. Serious leadership appears somewhat hard to find. Investigations found that the Pro-Brexit movement cheated with help from Cambridge Analytica and violations of campaign spending limits but the vote won't be re-run (yet). Voters: 0, Cabals: 3.

    It is disappointing when a leader seeks to vet his replacement in this way. In Venezuela, Hugo Chavez assured everybody that Nicolas Maduro was the only serious candidate who could succeed him. Venezuelans can see the consequences of such interventions by outgoing leaders clearly, but only during daylight, because the power has been out continuously for more than a week now. Many of their best engineers emigrated and Debian risks similar phenomena with these childish antics.

    The whole point of a free and fair election is that voters are the ultimate decision maker and we all put our trust in the voters alone to decide who is the most serious candidate. I remain disappointed that Lamb was not willing to talk face-to-face with those people he had differences with.

    In any other context, the re-opening of nominations and the repeated character attacks, facilitated by no less than another candidate who already holds office in the Debian account managers team would be considered as despicable as plagiarism and doping. So why is this acceptable in Debian? Voters: 0, Cabals: 4. If you ran a foot race this way, nobody would respect the outcome.

    Having finished multiple cross countries, steeplechases and the odd marathon, why can't I even start in Debian's annual election?

    In his interview with Mr Sam Varghese of IT Wire, rival candidate Joerg "Ganeff" Jaspert talks about "mutual trust". Well, he doesn't have to. I put my trust in the voters. That's democracy. Who is afraid of it? That's what a serious vote is all about.

    Jaspert's team have gone to further lengths to gain advantages, spreading rumours on the debian-private mailing list that they have "secret evidence" to justify their behaviour. It is amusing to see such ridiculous claims being made in Debian at the same time that Maduro in Venezuela is claiming to have secret evidence that his rival, Guaido, sabotaged the electricity grid. The golden rule of secret evidence: don't hold your breath waiting for it to materialize.

    While Maduro's claims of sabotage seem far-fetched, it is widely believed that Republican-friendly Enron played a significant role in Californian power shortages, swinging public mood against the Democrat incumbent and catapulting the world's first Governator into power (excuse the pun). Voters: 0, Cabals: 5.

    If the DAMs do have secret evidence against any Debian Developer, it is only fair to show the evidence to the Developer and give that person a right of reply. If such "evidence" is spread behind somebody's back, it is because it wouldn't stand up to any serious scrutiny.

    Over the last six months, Jaspert, Lamb and Co can't even decide whether they've demoted or expelled certain people. That's not leadership. It's a disgrace. If people are trusted to choose me as the Debian Project Leader, I guarantee that no other volunteer will be put through such intimidation and shaming ever again.

    After writing a blog about human rights in January, it is Jaspert who censored it from Planet Debian just hours later:

    Many people were mystified. Why would my blog post about human rights be censored by Debian? People have been scratching their heads trying to work out how it could even remotely violate the code of conduct. Is it because the opening quote came from Jaspert himself and he didn't want his cavalier attitude put under public scrutiny?

    This is not involving anything from the universal declaration of human rights. We are simply a project of volunteers which is free to chose its members as it wishes.

    which is a convenient way of eliminating competitors. After trampling on my blog and my nomination for the DPL election, it is simply a coincidence that Jaspert was the next to put his hand up and nominate.

    In Jonathan Carter's blog about his candidacy, he quotes Ian Murdock:

    You don’t want design by committee, but you want to tap in to the wisdom of the crowd.... the crowd is the most intelligent of all.

    If that is true, why is a committee of just three people, one of whom is a candidate, telling the crowd who they can and can't vote for?

    If that isn't a gerrymander, what is?

    Following through on the threat

    If you are going to use veiled threats to keep your developers in line, every now and then, you have to follow through, as Jaspert has done recently using his DAM position to make defamatory statements in the press.

    If Jaspert's organization really is willing to threaten and shame volunteers and denounce human rights, as he did in this quote, then I wouldn't want to be a part of it anyway, consider this my retirement and resignation and eliminate any further questions about my status. Nonetheless, I remain an independent Debian Developer just as committed to serving Debian users as ever before. Voters: 0, Cabals: 6.

    I remain ready and willing to face "None of the above" and any other candidate, serious or otherwise, on a level playing field, to serve those who would vote for me over and above those who seek to blackmail me and push me around with secret evidence and veiled threats.

    Packages of varnish-6.2.0 with matching vmods, for el6 and el7

    Posted by Ingvar Hagelund on March 21, 2019 08:29 AM

    The Varnish Cache project recently released a new upstream version 6.2 of Varnish Cache. I updated the fedora rawhide package yesterday. I have also built a copr repo with varnish packages for el6 and el7 based on the fedora package. A snapshot of matching varnish-modules (based on Nils Goroll’s branch) is also available.

    Packages are available at https://copr.fedorainfracloud.org/coprs/ingvar/varnish62/.

    vmods included in varnish-modules:

    AskFedora refresh: we’ve moved to Discourse!

    Posted by Fedora Community Blog on March 21, 2019 07:33 AM
    The Fedora Project community

    We have been working on moving AskFedora to a Discourse instance after seeing how well the community took to discussion.fedoraproject.org. After working on it for a few weeks now, we’re happy to report that the new AskFedora is now ready for use at https://askbeta.fedoraproject.org.

    The new AskFedora!

    The new AskFedora is a Discourse instance hosted for us by Discourse, similar to discussion.fedoraproject.org. However, where discussion.fedoraproject.org is meant for development discussion within the community, AskFedora is meant for end-user troubleshooting. While we did toy with the idea of simply using discussion.fedoraproject.org for both purposes, we felt it was a bit of a risk of the mix hampering both use cases. So, the decision was made to stick to the current organisation and use a separate Discourse instance for user queries.

    Getting started: logging in and language selection

    The new AskFedora is limited to FAS (Fedora Account System) logins only. This is unlike the Askbot instance where we also permitted social media and other logins. Limiting the logins to FAS permits us to have better control over the instance, and makes it much easier to gather data on usage and so on. Setting up a new FAS instance is quite trivial, so we do not expect this to be an issue to end-users either.

    Another way in which AskFedora on Discourse is different from AskFedora on Askbot, is that we chose not to host per-language subsites. Instead, we’ve leveraged Discourse categories and user-groups to support languages.

    When you login for the first time, you will only see the general categories:

    • Start here!
    • Community
    • Site Feedback

    These are common to all users. Based on interest from the community, and after verifying that we had community members willing to oversee these languages, the new AskFedora currently supports English, Spanish, Italian, and Persian. Here is how:

    Each language has an associated user-group. All users can join and leave these language user-groups at any time. Membership to each user-group gives access to “translated” categories, i.e., identical categories set up for users of the particular language group. Users can join as many language groups as they wish!

    Categories are loosely based on the lifecycle of a Fedora release. The top levels ask the question “what stage of the Fedora life-cycle are you at?”. The next level tries to be more specific to ask something on the lines of “what tool are you using?”. These categories are only meant to help organise the forum somewhat. They are not set in stone, and of course, lots of topics may fit into a multitude of categories. We leave it up to the users of the Forum to choose the appropriate category for their query.

    • Announcements (for each language group: can be used by regional teams, for example)
    • Installing Fedora
      • “General” for standard installations using Anaconda with near to default settings, and “Advanced” for more complex use cases such as kickstarts. 
      • A “Hardware” category dedicated for queries related to hardware support.
    • Customising a Fedora installation: for queries related to personalisation:
      • Either “General” for simpler tasks like changing defaults and so on mostly using tools provided by the community or “Advanced” for well, anything else really.
    • Using Fedora, with subcategories for the different platforms that Fedora runs on:
      • Desktops/Servers/Containers/Cloud/Others.
    • Upgrading a Fedora installation:
      • Either using the supported methods: DNF and DNF based methods; or any other ways that we tend to cook up each cycle.

    So, when you do login, please do go to the “Start here” category as the banner requests. We have a topic in each supported language documenting what we’ve written here—how to join the appropriate language group and get started.

    Feedback and next steps

    At this time, we are only announcing the new instance to the community. Hence, this post on the community blog first. The forum will be announced to the wider user-base on the Fedora magazine a week or two later. This gives us time to have a set of community members on the forum already to help end-users when they do get started. This also gives us time to collect feedback from the community and make tweaks to improve the user-experience before the “official launch”. Please use the “Site Feedback” category to drop us comments. Before the forum is announced to the wider audience, we will also update the URL to use https://ask.fedoraproject.org and a redirect from https://askbeta.fedoraproject.org will be put in place to ensure a smooth transition for current users.

    The usual reminders

    The forum (all forums, channels) are extensions of the Fedora community. They are tools that enable us to communicate with each other. Therefore, everything that occurs on these must follow our Code of Conduct. In short, please remember to “be excellent to each other“. There will always be disagreements, and us being us, tempers will flare. However, before you type out a reply, repeat to your self: “be excellent to each other” again and again, until your draft has lost its aggression/annoyance/negative connotations. This also applies to trolling—even when pointing it out, let’s stay excellent to each other. If you need any help, the forum staff are always there to step in—just drop us a message.

    As a closing word, we’re grateful to everyone that put the work in to make this refresh happen—especially the Askbot developers that have hosted AskFedora for us till now, and the Discourse team that will host it for us from now. It has taken quite a few hours of discussion, planning, and work to set things up the way we felt it would help users most. All of this happened on the Fedora Join SIG’s pagure project. We are always looking for more hands to help, and we are even happier if we can pass on some of what we have learned in our time in the Fedora community to other members. Please, do get in touch!

    The post AskFedora refresh: we’ve moved to Discourse! appeared first on Fedora Community Blog.

    Using hexdump to print binary protocols

    Posted by Peter Hutterer on March 21, 2019 12:30 AM

    I had to work on an image yesterday where I couldn't install anything and the amount of pre-installed tools was quite limited. And I needed to debug an input device, usually done with libinput record. So eventually I found that hexdump supports formatting of the input bytes but it took me a while to figure out the right combination. The various resources online only got me partway there. So here's an explanation which should get you to your results quickly.

    By default, hexdump prints identical input lines as a single line with an asterisk ('*'). To avoid this, use the -v flag as in the examples below.

    hexdump's format string is single-quote-enclosed string that contains the count, element size and double-quote-enclosed printf-like format string. So a simple example is this:

    $ hexdump -v -e '1/2 "%d\n"' <filename>
    This prints 1 element ('iteration') of 2 bytes as integer, followed by a linebreak. Or in other words: it takes two bytes, converts it to int and prints it. If you want to print the same input value in multiple formats, use multiple -e invocations.

    $ hexdump -v -e '1/2 "%d "' -e '1/2 "%x\n"' <filename>
    -11568 d2d0
    23698 5c92
    0 0
    0 0
    6355 18d3
    1 1
    0 0
    This prints the same 2-byte input value, once as decimal signed integer, once as lowercase hex. If we have multiple identical things to print, we can do this:

    $ hexdump -v -e '2/2 "%6d "' -e '" hex:"' -e '4/1 " %x"' -e '"\n"'
    -10922 23698 hex: 56 d5 92 5c
    0 0 hex: 0 0 0 0
    14879 1 hex: 1f 3a 1 0
    0 0 hex: 0 0 0 0
    0 0 hex: 0 0 0 0
    0 0 hex: 0 0 0 0
    Which prints two elements, each size 2 as integers, then the same elements as four 1-byte hex values, followed by a linebreak. %6d is a standard printf instruction and documented in the manual.

    Let's go and print our protocol. The struct representing the protocol is this one:

    struct input_event {
    #if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL__)
    struct timeval time;
    #define input_event_sec time.tv_sec
    #define input_event_usec time.tv_usec
    __kernel_ulong_t __sec;
    #if defined(__sparc__) && defined(__arch64__)
    unsigned int __usec;
    __kernel_ulong_t __usec;
    #define input_event_sec __sec
    #define input_event_usec __usec
    __u16 type;
    __u16 code;
    __s32 value;
    So we have two longs for sec and usec, two shorts for type and code and one signed 32-bit int. Let's print it:

    $ hexdump -v -e '"E: " 1/8 "%u." 1/8 "%06u" 2/2 " %04x" 1/4 "%5d\n"' /dev/input/event22
    E: 1553127085.097503 0002 0000 1
    E: 1553127085.097503 0002 0001 -1
    E: 1553127085.097503 0000 0000 0
    E: 1553127085.097542 0002 0001 -2
    E: 1553127085.097542 0000 0000 0
    E: 1553127085.108741 0002 0001 -4
    E: 1553127085.108741 0000 0000 0
    E: 1553127085.118211 0002 0000 2
    E: 1553127085.118211 0002 0001 -10
    E: 1553127085.118211 0000 0000 0
    E: 1553127085.128245 0002 0000 1
    And voila, we have our structs printed in the same format evemu-record prints out. So with nothing but hexdump, I can generate output I can then parse with my existing scripts on another box.

    F29-20190319 updated Live isos released

    Posted by Ben Williams on March 20, 2019 12:46 PM

    The Fedora Respins SIG is pleased to announce the latest release of Updated F29-20190319 Live ISOs, carrying the 4.20.16-200 kernel.

    This set of updated isos will save considerable amounts  of updates after install.  ((for new installs.)(New installs of Workstation have 1.2GB of updates)).

    This set also includes a updated iso of the Security Lab. 

    A huge thank you goes out to irc nicks dowdle, Southern-Gentlem for testing these iso.

    We would also like to thank Fedora- QA  for running the following Tests on our ISOs.:



    As always our isos can be found at  http://tinyurl.com/Live-respins .  

    4 cool terminal multiplexers

    Posted by Fedora Magazine on March 20, 2019 08:00 AM

    The Fedora OS is comfortable and easy for lots of users. It has a stunning desktop that makes it easy to get everyday tasks done. Under the hood is all the power of a Linux system, and the terminal is the easiest way for power users to harness it. By default terminals are simple and somewhat limited. However, a terminal multiplexer allows you to turn your terminal into an even more incredible powerhouse. This article shows off some popular terminal multiplexers and how to install them.

    Why would you want to use one? Well, for one thing, it lets you logout of your system while leaving your terminal session undisturbed. It’s incredibly useful to logout of your console, secure it, travel somewhere else, then remotely login with SSH and continue where you left off. Here are some utilities to check out.

    One of the oldest and most well-known terminal multiplexers is screen. However, because the code is no longer maintained, this article focuses on more recent apps. (“Recent” is relative — some of these have been around for years!)


    The tmux utility is one of the most widely used replacements for screen. It has a highly configurable interface. You can program tmux to start up specific kinds of sessions based on your needs. You’ll find a lot more about tmux in this article published earlier:

    <figure class="wp-block-embed is-type-rich is-provider-fedora-magazine">
    Use tmux for a more powerful terminal
    <iframe class="wp-embedded-content" data-secret="AOTxgovebe" frameborder="0" height="338" marginheight="0" marginwidth="0" sandbox="allow-scripts" scrolling="no" security="restricted" src="https://fedoramagazine.org/use-tmux-more-powerful-terminal/embed/#?secret=AOTxgovebe" title="“Use tmux for a more powerful terminal” — Fedora Magazine" width="600"></iframe>

    Already a tmux user? You might like this additional article on making your tmux sessions more effective.

    To install tmux, use the sudo command along with dnf, since you’re probably in a terminal already:

    $ sudo dnf install tmux

    To start learning, run the tmux command. A single pane window starts with your default shell. Tmux uses a modifier key to signal that a command is coming next. This key is Ctrl+B by default. If you enter Ctrl+B, C you’ll create a new window with a shell in it.

    Here’s a hint: Use Ctrl+B, ? to enter a help mode that lists all the keys you can use. To keep things simple, look for the lines starting with bind-key -T prefix at first. These are keys you can use right after the modifier key to configure your tmux session. You can hit Ctrl+C to exit the help mode back to tmux.

    To completely exit tmux, use the standard exit command or Ctrl+D keystroke to exit all the shells.


    You might have recently seen the Magazine article on dwm, a dynamic window manager. Like dwm, dvtm is for tiling window management — but in a terminal. It’s designed to adhere to the legacy UNIX philosophy of “do one thing well” — in this case managing windows in a terminal.

    Installing dvtm is easy as well. However, if you want the logout functionality mentioned earlier, you’ll also need the abduco package which handles session management for dvtm.

    $ sudo dnf install dvtm abduco

    The dvtm utility has many keystrokes already mapped to allow you to manage windows in the terminal. By default, it uses Ctrl+G as its modifier key. This keystroke tells dvtm that the following character is going to be a command it should process. For instance, Ctrl+G, C creates a new window and Ctrl+G, X removes it.

    For more information on using dvtm, check out the dvtm home page which includes numerous tips and get-started information.


    While byobu isn’t truly a multiplexer on its own — it wraps tmux or even the older screen to add functions — it’s worth covering here too. Byobu makes terminal multiplexers better for novices, by adding a help menu and window tabs that are slightly easier to navigate.

    Of course it’s available in the Fedora repos as well. To install, use this command:

    $ sudo dnf install byobu

    By default the byobu command runs screen underneath, so you might want to run byobu-tmux to wrap tmux instead. You can then use the F9 key to open up a help menu for more information to help you get started.


    The mtm utility is one of the smallest multiplexers you’ll find. In fact, it’s only about 1000 lines of code! You might find it helpful if you’re in a limited environment such as old hardware, a minimal container, and so forth. To get started, you’ll need a couple packages.

    $ sudo dnf install git ncurses-devel make gcc

    Then clone the repository where mtm lives:

    $ git clone https://github.com/deadpixi/mtm.git

    Change directory into the mtm folder and build the program:

    $ make

    You might receive a few warnings, but when you’re done, you’ll have the very small mtm utility. Run it with this command:

    $ ./mtm

    You can find all the documentation for the utility on its GitHub page.

    These are just some of the terminal multiplexers out there. Got one you’d like to recommend? Leave a comment below with your tips and enjoy building windows in your terminal!

    Photo by Michael on Unsplash.

    Kiwi TCMS 6.6

    Posted by Kiwi TCMS on March 19, 2019 08:40 PM

    We're happy to announce Kiwi TCMS version 6.6! This is a medium severity security update, improvement and bug-fix update. 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  c4734f98ca37    971.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.5.3


    • Explicitly require marked v0.6.1 to fix medium severity ReDoS vulnerability. See SNYK-JS-MARKED-73637


    • Update python-gitlab from 1.7.0 to 1.8.0
    • Update django-contrib-comments from 1.9.0 to 1.9.1
    • More strings marked as translatable (Christophe CHAUVET)
    • When creating new TestCase you can now change notification settings. Previously this was only possible during editing
    • Document import-export approaches. Closes Issue #795
    • Document available test automation plugins
    • Improve documentation around Docker customization and SSL termination
    • Add documentation example of reverse rroxy configuration for HAProxy (Nicolas Auvray)
    • TestPlan.add_case() will now set the sortkey to highest in plan + 10 (Rik)
    • Add LinkOnly issue tracker. Fixes Issue #289
    • Use the same HTML template for both TestCase new & edit
    • New API methods for adding, removing and listing attachments. Fixes Issue #446:
      • TestPlan.add_attachment()
      • TestCase.add_attachment()
      • TestPlan.list_attachments()
      • TestCase.list_attachments()
      • Attachments.remove_attachment()

    Database migrations

    • Populate missing TestCase.text history. In version 6.5 the TestCase model was updated to store the text into a single field called text instead of 4 separate fields. During that migration historical records were updated to have the new text field but values were not properly assigned.

      The "effect" of this is that in TestCaseRun records you were not able to see the actual text b/c it was None.

      This change ammends 0006_merge_text_field_into_testcase_model for installations which have not yet migrated to 6.5 or later. We also provide the data-only migration 0009_populate_missing_text_history which will inspect the current state of the DB and copy the text to the last historical record.

    Removed functionality

    • Remove legacy reports. Closes Issue #657

    • Remove "Save & Continue" functionality from TestCase edit page

    • Renamed API methods:

      • TestCaseRun.add_log() -> TestCaseRun.add_link()
      • TestCaseRun.remove_log() -> TestCaseRun.remove_link()
      • TestCaseRun.get_logs() -> TestCaseRun.get_links()

      These methods work with URL links, which can be added or removed to test case runs.

    Bug fixes

    • Remove hard-coded timestamp in TestCase page template, References Issue #765
    • Fix handling of ?from_plan URL parameter in TestCase page
    • Make TestCase.text occupy 100% width when rendered. Fixes Issue #798
    • Enable markdown.extensions.tables. Fixes Issue #816
    • Handle form erros and default values for TestPlan new/edit. Fixes Issue #864
    • Tests + fix for failing TestCase rendering in French
    • Show color-coded statuses on dashboard page when seen with non-English language
    • Refactor check for confirmed test cases when editting to work with translations
    • Fix form values when filtering test cases inside TestPlan. Fixes Issue #674 (@marion2016)
    • Show delete icon for attachments. Fixes Issue #847


    • Remove unused .current_user instance attribute
    • Remove EditCaseForm and use NewCaseForm instead, References Issue #708, Issue #812
    • Fix "Select All" checkbox. Fixes Issue #828 (Rady)


    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!

    The Product Security Blog has moved!

    Posted by Red Hat Security on March 19, 2019 07:38 PM

    Red Hat Product Security has joined forces with other security teams inside Red Hat to publish our content in a common venue using the Security channel of the Red Hat Blog. This move provides a wider variety of important Security topics, from experts all over Red Hat, in a more modern and functional interface. We hope everyone will enjoy the new experience!






    Epiphany Technology Preview Upgrade Requires Manual Intervention

    Posted by Michael Catanzaro on March 19, 2019 06:39 PM

    Jan-Michael has recently changed Epiphany Technology Preview to use a separate app ID. Instead of org.gnome.Epiphany, it will now be org.gnome.Epiphany.Devel, to avoid clashing with your system version of Epiphany. You can now have separate desktop icons for both system Epiphany and Epiphany Technology Preview at the same time.

    Because flatpak doesn’t provide any way to rename an app ID, this means it’s the end of the road for previous installations of Epiphany Technology Preview. Manual intervention is required to upgrade. Fortunately, this is a one-time hurdle, and it is not hard:

    $ flatpak uninstall org.gnome.Epiphany

    Uninstall the old Epiphany…

    $ flatpak install gnome-apps-nightly org.gnome.Epiphany.Devel org.gnome.Epiphany.Devel.Debug

    …install the new one, assuming that your remote is named gnome-apps-nightly (the name used locally may differ), and that you also want to install debuginfo to make it possible to debug it…

    $ mv ~/.var/app/org.gnome.Epiphany ~/.var/app/org.gnome.Epiphany.Devel

    …and move your personal data from the old app to the new one.

    Then don’t forget to make it your default web browser under System Settings -> Details -> Default Applications. Thanks for testing Epiphany Technology Preview!

    Of debugging Ansible Tower and underlying cloud images

    Posted by Roland Wolters on March 19, 2019 03:09 PM
    <figure class="alignright is-resized">Ansible Logo</figure>

    Recently I was experimenting with Tower’s isolated nodes feature – but somehow it did not work in my environment. Debugging told me a lot about Ansible Tower – and also why you should not trust arbitrary cloud images.

    Background – Isolated Nodes

    Ansible Tower has a nice feature called “isolated nodes”. Those are dedicated Tower instances which can manage nodes in separated environments – basically an Ansible Tower Proxy.

    An Isolated Node is an Ansible Tower node that contains a small piece of software for running playbooks locally to manage a set of infrastructure. It can be deployed behind a firewall/VPC or in a remote datacenter, with only SSH access available. When a job is run that targets things managed by the isolated node, the job and its environment will be pushed to the isolated node over SSH, where it will run as normal.

    Ansible Tower Feature Spotlight: Instance Groups and Isolated Nodes

    Isolated nodes are especially handy when you setup your automation in security sensitive environments. Think of DMZs here, of network separation and so on.

    I was fooling around with a clustered Tower installation on RHEL 7 VMs in a cloud environment when I run into trouble though.

    My problem – Isolated node unavailable

    Isolated nodes – like instance groups – have a status inside Tower: if things are problematic, they are marked as unavailable. And this is what happened with my instance isonode.remote.example.com running in my lab environment:

    <figure class="wp-block-image"><figcaption>Ansible Tower showing an instance node as unavailable</figcaption></figure>

    I tried to turn it “off” and “on” again with the button in the control interface. It made the node available, it was even able to executed jobs – but it became quickly unavailable soon after.


    So what happened? The Tower logs showed a Python error:

    # tail -f /var/log/tower/tower.log
    fatal: [isonode.remote.example.com]: FAILED! => {"changed": false,
    "module_stderr": "Shared connection to isonode.remote.example.com
    closed.\r\n", "module_stdout": "Traceback (most recent call last):\r\n
    File \"/var/lib/awx/.ansible/tmp/ansible-tmp-1552400585.04
    -60203645751230/AnsiballZ_awx_capacity.py\", line 113, in <module>\r\n
    _ansiballz_main()\r\n  File \"/var/lib/awx/.ansible/tmp/ansible-tmp
    -1552400585.04-60203645751230/AnsiballZ_awx_capacity.py\", line 105, in
    _ansiballz_main\r\n    invoke_module(zipped_mod, temp_path,
    ANSIBALLZ_PARAMS)\r\n  File \"/var/lib/awx/.ansible/tmp/ansible-tmp
    -1552400585.04-60203645751230/AnsiballZ_awx_capacity.py\", line 48, in
    invoke_module\r\n    imp.load_module('__main__', mod, module, MOD_DESC)\r\n
    File \"/tmp/ansible_awx_capacity_payload_6p5kHp/__main__.py\", line 74, in
    <module>\r\n  File \"/tmp/ansible_awx_capacity_payload_6p5kHp/__main__.py\",
    line 60, in main\r\n  File
    \"/tmp/ansible_awx_capacity_payload_6p5kHp/__main__.py\", line 27, in
    get_cpu_capacity\r\nAttributeError: 'module' object has no attribute
    'cpu_count'\r\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact
    error", "rc": 1}
    PLAY RECAP *********************************************************************
    isonode.remote.example.com : ok=0    changed=0    unreachable=0    failed=1  

    Apparently a Python function was missing. If we check the code we see that indeed in line 27 of file awx_capacity.py the function psutil.cpu_count() is called:

    def get_cpu_capacity():
        env_forkcpu = os.getenv('SYSTEM_TASK_FORKS_CPU', None)
        cpu = psutil.cpu_count()

    Support for this function was added in version 2.0 of psutil:

    424: [Windows] installer for Python 3.X 64 bit.
    427: number of logical and physical CPUs (psutil.cpu_count()).

    psutil history

    Note the date here: 2014-03-10 – pretty old! I check the version of the installed package, and indeed the version was pre-2.0:

    $ rpm -q --queryformat '%{VERSION}\n' python-psutil

    To be really sure and also to ensure that there was no weird function backporting, I checked the function call directly on the Tower machine:

    # python
    Python 2.7.5 (default, Sep 12 2018, 05:31:16) 
    [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import inspect
    >>> import psutil as module
    >>> functions = inspect.getmembers(module, inspect.isfunction)
    >>> functions
    [('_assert_pid_not_reused', <function _assert_pid_not_reused at
    0x7f9eb10a8d70>), ('_deprecated', <function deprecated at 0x7f9eb38ec320>),
    ('_wraps', <function wraps at 0x7f9eb414f848>), ('avail_phymem', <function
    avail_phymem at 0x7f9eb0c32ed8>), ('avail_virtmem', <function avail_virtmem at
    0x7f9eb0c36398>), ('cached_phymem', <function cached_phymem at
    0x7f9eb10a86e0>), ('cpu_percent', <function cpu_percent at 0x7f9eb0c32320>),
    ('cpu_times', <function cpu_times at 0x7f9eb0c322a8>), ('cpu_times_percent',
    <function cpu_times_percent at 0x7f9eb0c326e0>), ('disk_io_counters',
    <function disk_io_counters at 0x7f9eb0c32938>), ('disk_partitions', <function
    disk_partitions at 0x7f9eb0c328c0>), ('disk_usage', <function disk_usage at
    0x7f9eb0c32848>), ('get_boot_time', <function get_boot_time at
    0x7f9eb0c32a28>), ('get_pid_list', <function get_pid_list at 0x7f9eb0c4b410>),
    ('get_process_list', <function get_process_list at 0x7f9eb0c32c08>),
    ('get_users', <function get_users at 0x7f9eb0c32aa0>), ('namedtuple',
    <function namedtuple at 0x7f9ebc84df50>), ('net_io_counters', <function
    net_io_counters at 0x7f9eb0c329b0>), ('network_io_counters', <function
    network_io_counters at 0x7f9eb0c36500>), ('phymem_buffers', <function
    phymem_buffers at 0x7f9eb10a8848>), ('phymem_usage', <function phymem_usage at
    0x7f9eb0c32cf8>), ('pid_exists', <function pid_exists at 0x7f9eb0c32140>),
    ('process_iter', <function process_iter at 0x7f9eb0c321b8>), ('swap_memory',
    <function swap_memory at 0x7f9eb0c327d0>), ('test', <function test at
    0x7f9eb0c32b18>), ('total_virtmem', <function total_virtmem at
    0x7f9eb0c361b8>), ('used_phymem', <function used_phymem at 0x7f9eb0c36050>),
    ('used_virtmem', <function used_virtmem at 0x7f9eb0c362a8>), ('virtmem_usage',
    <function virtmem_usage at 0x7f9eb0c32de8>), ('virtual_memory', <function
    virtual_memory at 0x7f9eb0c32758>), ('wait_procs', <function wait_procs at

    Searching for a package origin

    So how to solve this issue? My first idea was to get this working by updating the entire code part to the multiprocessor lib:

    # python
    Python 2.7.5 (default, Sep 12 2018, 05:31:16) 
    [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import multiprocessing
    >>> cpu = multiprocessing.cpu_count()
    >>> cpu

    But while I was filling a bug report I wondered why RHEL shipped such an ancient library. After all, RHEL 7 was released in June 2014, and psutil had cpu_count available since early 2014! And indeed, a quick search for the package via the Red Hat package search showed a weird result: python-psutil was never part of base RHEL 7! It was only shipped as part of some very, very old OpenStack channels:

    <figure class="wp-block-image"><figcaption>access.redhat.com package search, results for python-psutil</figcaption></figure>

    Newer OpenStack channels in fact come along with newer versions of python-psutil.

    So how did this outdated package end up on this RHEL 7 image? Why was it never updated?

    The cloud image is to blame! The package was installed on it – most likely during the creation of the image: python-psutil is needed for OpenStack Heat, so I assume that these RHEL 7 images where once created via OpenStack and then used as the default image in this demo environment.

    And after the initial creation of the image the Heat packages were forgotten. In the meantime the image was updated to newer RHEL versions, snapshots were created as new defaults and so on. But since the package in question was never part of the main RHEL repos, it was never changed or removed. It just stayed there. Waiting, apparently, for me 😉


    This issue showed me how tricky cloud images can be. Think about your own cloud images: have you really checked all all of them and verified that no package, no start up script, no configuration was changed from the Linux distribution vendor’s base setup?

    With RPMs this is still manageable, you can track if packages are installed which are not present in the existing channels. But did someone install something with pip? Or any other way?

    Take my case: an outdated version of a library was called instead of a much, much more recent one. If there would have been a serious security issue with the library in the meantime, I would have been exposed although my update management did not report any library to be updated.

    I learned my lesson to be more critical with cloud images, checking them in more detail in the future to avoid having nasty surprises during production. And I can just recommend that you do that as well.

    <script type="text/javascript"> __ATA.cmd.push(function() { __ATA.initSlot('atatags-26942-5c9a18ff081df', { collapseEmpty: 'before', sectionId: '26942', width: 300, height: 250 }); }); </script>
    <script type="text/javascript"> __ATA.cmd.push(function() { __ATA.initSlot('atatags-114160-5c9a18ff081e3', { collapseEmpty: 'before', sectionId: '114160', width: 300, height: 250 }); }); </script>

    Introducing flat-manager

    Posted by Alexander Larsson on March 19, 2019 01:20 PM

    A long time ago I wrote a blog post about how to maintain a Flatpak repository.

    It is still a nice, mostly up to date, description of how Flatpak repositories work. However, it doesn’t really have a great answer to the issue called syncing updates in the post. In other words, it really is more about how to maintain a repository on one machine.

    In practice, at least on a larger scale (like e.g. Flathub) you don’t want to do all the work on a single machine like this. Instead you have an entire build-system where the repository is the last piece.

    Enter flat-manager

    To support this I’ve been working on a side project called flat-manager. It is a service written in rust that manages Flatpak repositories. Recently we migrated Flathub to use it, and its seems to work quite well.

    At its core, flat-manager serves and maintains a set of repos, and has an API that lets you push updates to it from your build-system. However, the way it is set up is a bit more complex, which allows some interesting features.

    Core concept: a build

    When updating an app, the first thing you do is create a new build, which just allocates an id that you use in later operations. Then you can upload one or more builds to this id.

    This separation of the build creation and the upload is very powerful, because it allows you to upload the app in multiple operations, potentially from multiple sources. For example, in the Flathub build-system each architecture is built on a separate machine. Before flat-manager we had to collect all the separate builds on one machine before uploading to the repo. In the new system each build machine uploads directly to the repo with no middle-man.

    Committing or purging

    An important idea here is that the new build is not finished until it has been committed. The central build-system waits until all the builders report success before committing the build. If any of the builds fail, we purge the build instead, making it as if the build never happened. This means we never expose partially successful builds to users.

    Once a build is committed, flat-manager creates a separate repository containing only the new build. This allows you to use Flatpak to test the build before making it available to users.

    This makes builds useful even for builds that never was supposed to be generally available. Flathub uses this for test builds, where if you make a pull request against an app it will automatically build it and add a comment in the pull request with the build results and a link to the repo where you can test it.


    Once you are satisfied with the new build you can trigger a publish operation, which will import the build into the main repository and do all the required operations, like:

    • Sign builds with GPG
    • Generate static deltas for efficient updates
    • Update the appstream data and screenshots for the repo
    • Generate flatpakref files for easy installation of apps
    • Update the summary file
    • Call out out scripts that let you do local customization

    The publish operation is actually split into two steps, first it imports the build result in the repo, and then it queues a separate job to do all the updates needed for the repo. This way if multiple builds are published at the same time the update can be shared. This saves time on the server, but it also means less updates to the metadata which means less churn for users.

    You can use whatever policy you want for how and when to publish builds. Flathub lets individual maintainers chose, but by default successful builds are published after 3 hours.

    Delta generation

    The traditional way to generate static deltas is to run flatpak build-update-repo --generate-static-deltas. However, this is a very computationally expensive operation that you might not want to do on your main repository server. Its also not very flexible in which deltas it generates.

    To minimize the server load flat-manager allows external workers that generate the deltas on different machines. You can run as many of these as you want and the deltas will be automatically distributed to them. This is optional, and if no workers connect the deltas will be generated locally.

    flat-manager also has configuration options for which deltas should be generated. This allows you to avoid generating unnecessary deltas and to add extra levels of deltas where needed. For example, Flathub no longer generates deltas for sources and debug refs, but we have instead added multiple levels of deltas for runtimes, allowing you to go efficiently to the current version from either one or two versions ago.

    Subsetting tokens

    flat-manager uses JSON Web Tokens to authenticate API clients. This means you can assign different permission to different clients. Flathub uses this to give minimal permissions to the build machines. The tokens they get only allow uploads to the specific build they are currently handling.

    This also allows you to hand out access to parts of the repository namespace. For instance, the Gnome project has a custom token that allows them to upload anything in the org.gnome.Platform namespace in Flathub. This way Gnome can control the build of their runtime and upload a new version whenever they want, but they can’t (accidentally or deliberately) modify any other apps.


    I need to mention Rust here too. This is my first real experience with using Rust, and I’m very impressed by it. In particular, the sense of trust I have in the code when I got it past the compiler. The compiler caught a lot of issues, and once things built I saw very few bugs at runtime.

    It can sometimes be a lot of work to express the code in a way that Rust accepts, which makes it not an ideal language for sketching out ideas. But for production code it really excels, and I can heartily recommend it!

    Future work

    Most of the initial list of features for flat-manager are now there, so I don’t expect it to see a lot of work in the near future.

    However, there is one more feature that I want to see; the ability to (automatically) create subset versions of the repository. In particular, we want to produce a version of Flathub containing only free software.

    I have the initial plans for how this will work, but it is currently blocking on some work inside OSTree itself. I hope this will happen soon though.

    [F30] Participez à la journée de test consacrée à l'internationalisation

    Posted by Charles-Antoine Couret on March 19, 2019 07:00 AM

    Aujourd'hui, ce mardi 19 mars, est une journée dédiée à un test précis : sur l'internationalisation de Fedora. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

    Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

    En quoi consiste ce test ?

    Comme chaque version de Fedora, la mise à jour de ses outils impliquent souvent l’apparition de nouvelles chaînes de caractères à traduire et de nouveaux outils liés à la prise en charge de langues (en particulier asiatiques).

    Pour favoriser l'usage de Fedora dans l'ensemble des pays du monde, il est préférable de s'assurer que tout ce qui touche à l'internationalisation de Fedora soit testée et fonctionne. Notamment parce qu'une partie doit être fonctionnelle dès le LiveCD d'installation (donc sans mise à jour).

    Les tests du jour couvrent :

    • Le bon fonctionnement d'ibus pour la gestion des entrées claviers ;
    • La personnalisation des polices de caractères ;
    • L'installation automatique des paquets de langues des logiciels installés suivant la langue du système ;
    • La traduction fonctionnelle par défaut des applications ;
    • Les nouvelles dépendances des paquets de langue pour installer les polices et les entrées de saisie nécessaires.

    Bien entendu, étant donné les critères, à moins de savoir une langue chinoise, l'ensemble des tests n'est pas forcément réalisable. Mais en tant que francophones, de nombreuses problématiques nous concernent et remonter les problèmes est important. En effet, ce ne sont pas les autres communautés linguistiques qui identifieront les problèmes d'intégration de la langue française.

    Comment y participer ?

    Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

    Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

    En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

    De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

    Contribution opportunity! Quick docs!

    Posted by Fedora Community Blog on March 19, 2019 06:30 AM
    Photo by Peter Lewicki on Unsplash

    Quick docs are meant to be short articles on the official Fedora documentation site that cover commonly used workflows/tools.

    Unlike wiki pages which are generally unreviewed, information on quick-docs follows the PR (peer-review + pull request) process. So the new information that is added there is more trustworthy and should be too, given that quick docs is listed on the official Fedora documentation website.

    Role 1: reviewer

    All new quick-docs are added using the pull-request model. They all, therefore, must be reviewed.

    So, a really easy way of contributing to quick-docs is to find a pull request that addresses a topic you know about and review it.

    Similar to the package maintainers system, “review swaps” are encouraged: you review my pull request, and in return I will review yours. Not only does this ensure quicker reviews, it also helps contributors get to know each other! Please, feel free to request documentation review swaps on the mailing lists!

    Role 2: writer

    This role is on the other side of the review: you write new documents about topics that interest you. It could be anything, anything at all, that you think is worth documenting. Quite a few of us document various tools and techniques on our blogs—why not put these up on quick-docs if the are general enough to be of interest to a wider audience?

    Documentation writers need reviewers, and reviewers need documentation writers. So, while I’ve listed these as separate roles, most people will do both!

    Skills you will need/learn as a quick-docs contributor

    As a contributor to quick-docs, you will need/learn the following skills:

    You will notice that a these skills are mostly transferable to other work. This makes contributing to quick-docs even more useful, especially for beginners.

    I mention this purely for the sake of completeness, for it should be obvious to anyone who sees the Fedora community go about its work: the docs team and the Fedora community in general, are always looking to spread whatever knowledge we have to others in the community or those looking to join the community!

    Current requirement: improving automatically exported wiki pages

    A large body of quick-docs consists of pages from the wiki that were auto-exported. These are not yet reviewed. So, we do need more community members looking at these pages, catching errors, and improving them. This is also one of the easiest ways of contributing to quick docs:

    • pick a quick-docs page.
    • verify whether the information is correct.
    • open a pull request with suggested improvements.
    • review other’s pull requests.

    Get in touch, get started!

    So, let’s get started? Here are the relevant links:

    Happy writing!

    The post Contribution opportunity! Quick docs! appeared first on Fedora Community Blog.

    Happy St Patrick's Day, IFSO AGM and meeting sock puppets

    Posted by Daniel Pocock on March 18, 2019 02:18 PM

    Happy St Patrick's day (17 March)

    In February, we had an annual general meeting (AGM) of the Irish Free Software Organization in Dublin.

    If you are in Ireland, please consider joining IFSO or making a donation.

    The sock puppet next door

    There is a very interesting story about how this meeting came about.

    When discussions took place in the FSFE community about the decision to abolish elections, approximately 15 people participated, with about 10 people against democracy and only about 5 people speaking up in favour.

    Looking at those numbers is deceptive: of the 10 people speaking against elections, all were in what other people perceive as the cabal, a group of 27 people who have full membership, over and above the fellows. Cabal people hadn't lost anything in the constitutional change. The 5 people speaking in favour of democracy where not members of the cabal, they were ordinary members of the 1500-strong fellowship. In such circumstances, is it fair to extrapolate the voice of those 5 people and consider it to be representative of the majority of 1500 fellows? Or do we accept the more simplistic 10 against 5? The more simplistic case, where it is not obvious to outsiders that the 10 people are cabal members, is one of those fake community situations.

    Imagine if every participant in that conversation had to state in their email signature whether they were cabal or fellow, or even better, if the emails could be colour-coded by membership class. Would it be easier to see the correlation between the vested interests and the opinions?

    In any case, the more outspoken members of the cabal tried to intimidate the fellows, trying to discredit them with personal attacks and calling some of them sock puppets. As fellowship representative, I simply emailed some of these people personally asking "can you please tell me if you are a sock-puppet or a fellow?"

    What I found was surprising: not only were they real people, one of them lives just around the corner from my home in Dublin. Stefan and I met for burgers late in 2018 and helped put things into motion to reboot the IFSO.

    One fellow told me he (or she?) was not using their real name because the FSFE cabal censors discussions about governance issues, blocking people from the mailing lists or moderating their posts. But they are still a real person making real contributions to the organization. Another fellow observed that one member of the cabal, Cryptie, doesn't use her real name and asked why should anybody else?

    Another thought that crossed my mind after meeting Stefan: why is it easier for me to meet a so-called sock-puppet in real life than it is to meet the leader of the Debian project when serious issues need to be discussed? The DPL's refusal to meet with people in person and then deciding he knows them well enough to give opinions about them to people in other communities feels like one of the major reasons there has been stress for many people in Debian recently.

    Now Debian has similar problems to FSFE: undemocratic behaviour by the leaders, censorship and then, for fear of retribution, it looks like some people stop using their real names when posting on the debian-project mailing list and other people may erroneously be accused of not using real names. With over five thousand people subscribed to the list, I don't feel that two people with similar names is a compelling example of sock-puppeteering and some of the accusations are uncomfortable for multiple people. Even fewer people dare to open their mouth next.

    This brings us to another of the benefits of setting up local associations like IFSO: people can meet face to face more often, maybe monthly and then nobody is wondering if they are corresponding with a sock puppet. FSFE's 27 members (what they call the "General Assembly", or other people regard as a cabal) only officially meets once per year. It has become too big to function like a board or have regular meetings but too small to have the credibility that would come from acknowledging all volunteers/fellows as equal members.

    According to the treasurer's report at the IFSO AGM, there is no money in the bank so there is nothing for sock puppets to fight over anyway. So come along and join the next meeting for some fun.

    New feature in fedora-upgrade

    Posted by Miroslav Suchý on March 18, 2019 02:05 PM

    I have just released a new version of fedora-upgrade (an unofficial tool to upgrade Fedora). It has two nice features:

    Previously you were able to upgrade just to next version. E.g., upgrade from Fedora 28 to Fedora 29. You were not able to upgrade from Fedora 28 to Fedora 30. This is now possible. You can run:

    fedora-upgrade --upgrade-to=30

    and it will try to upgrade to Fedora 30 - no matter what is your current version. Be warned - more releases you skip, more bugs will pop up.

    I have several machines in the cloud, which have root volume pretty small (4GB) and which I (for various reasons) prefer to upgrade (rather than terminating and building from scratch using Ansible playbook). Upgrading system where rootfs is 4GB big and the 2 GB are already used is painful. You need 2 GB for DNF cache to download the packages, and then DNF tells you that you are out of space. I usually workaround that by mounting /var/cache/dnf as tmpfs and after the upgrade I unmounted it. I finally find time to script that so you can use:

    fedora-upgrade --tmpfs=3G

    to mount /var/cache/dnf as 3GB big tmpfs.

    The new version just landend in Bodhi - tomorrow it will be in updates-testing.

    Let’s try dwm — dynamic window manager

    Posted by Fedora Magazine on March 18, 2019 08:01 AM

    If you like efficiency and minimalism, and are looking for a new window manager for your Linux desktop, you should try dwm — dynamic window manager. Written in under 2000 standard lines of code, dwm is extremely fast yet powerful and highly customizable window manager.

    You can dynamically choose between tiling, monocle and floating layouts, organize your windows into multiple workspaces using tags, and quickly navigate through using keyboard shortcuts. This article helps you get started using dwm.


    To install dwm on Fedora, run:

    $ sudo dnf install dwm dwm-user

    The dwm package installs the window manager itself, and the dwm-user package significantly simplifies configuration which will be explained later in this article.

    Additionally, to be able to lock the screen when needed, we’ll also install slock — a simple X display locker.

    $ sudo dnf install slock

    However, you can use a different one based on your personal preference.

    Quick start

    To start dwm, choose the dwm-user option on the login screen.

    <figure class="wp-block-image"></figure>

    After you log in, you’ll see a very simple desktop. In fact, the only thing there will be a bar at the top listing our nine tags that represent workspaces and a []= symbol that represents the layout of your windows.

    Launching applications

    Before looking into the layouts, first launch some applications so you can play with the layouts as you go. Apps can be started by pressing Alt+p and typing the name of the app followed by Enter. There’s also a shortcut Alt+Shift+Enter for opening a terminal.

    Now that some apps are running, have a look at the layouts.


    There are three layouts available by default: the tiling layout, the monocle layout, and the floating layout.

    The tiling layout, represented by []= on the bar, organizes windows into two main areas: master on the left, and stack on the right. You can activate the tiling layout by pressing Alt+t.

    <figure class="wp-block-image"></figure>

    The idea behind the tiling layout is that you have your primary window in the master area while still seeing the other ones in the stack. You can quickly switch between them as needed.

    To swap windows between the two areas, hover your mouse over one in the stack area and press Alt+Enter to swap it with the one in the master area.

    <figure class="wp-block-image"></figure>

    The monocle layout, represented by [N] on the top bar, makes your primary window take the whole screen. You can switch to it by pressing Alt+m.

    Finally, the floating layout lets you move and resize your windows freely. The shortcut for it is Alt+f and the symbol on the top bar is ><>.

    Workspaces and tags

    Each window is assigned to a tag (1-9) listed at the top bar. To view a specific tag, either click on its number using your mouse or press Alt+1..9. You can even view multiple tags at once by clicking on their number using the secondary mouse button.

    Windows can be moved between different tags by highlighting them using your mouse, and pressing Alt+Shift+1..9. 


    To make dwm as minimalistic as possible, it doesn’t use typical configuration files. Instead, you modify a C header file representing the configuration, and recompile it. But don’t worry, in Fedora it’s as simple as just editing one file in your home directory and everything else happens in the background thanks to the dwm-user package provided by the maintainer in Fedora.

    First, you need to copy the file into your home directory using a command similar to the following:

    $ mkdir ~/.dwm
    $ cp /usr/src/dwm-VERSION-RELEASE/config.def.h ~/.dwm/config.h

    You can get the exact path by running man dwm-start.

    Second, just edit the ~/.dwm/config.h file. As an example, let’s configure a new shortcut to lock the screen by pressing Alt+Shift+L.

    Considering we’ve installed the slock package mentioned earlier in this post, we need to add the following two lines into the file to make it work:

    Under the /* commands */ comment, add:

    static const char *slockcmd[] = { "slock", NULL };

    And the following line into static Key keys[]:

    { MODKEY|ShiftMask, XK_l, spawn, {.v = slockcmd } },

    In the end, it should look like as follows: (added lines are highlighted)

    /* commands */
    static char dmenumon[2] = "0"; /* component of dmenucmd, manipulated in spawn() */
    static const char *dmenucmd[] = { "dmenu_run", "-m", dmenumon, "-fn", dmenufont, "-nb", normbgcolor, "-nf", normfgcolor, "-sb", selbgcolor, "-sf", selfgcolor, NULL };
    static const char *termcmd[]  = { "st", NULL };
    static const char *slockcmd[] = { "slock", NULL };

    static Key keys[] = {
    /* modifier                     key        function        argument */
    { MODKEY|ShiftMask,             XK_l,      spawn,          {.v = slockcmd } },
    { MODKEY,                       XK_p,      spawn,          {.v = dmenucmd } },
    { MODKEY|ShiftMask,             XK_Return, spawn,          {.v = termcmd } },

    Save the file.

    Finally, just log out by pressing Alt+Shift+q and log in again. The scripts provided by the dwm-user package will recognize that you have changed the config.h file in your home directory and recompile dwm on login. And becuse dwm is so tiny, it’s fast enough you won’t even notice it.

    You can try locking your screen now by pressing Alt+Shift+L, and then logging back in again by typing your password and pressing enter.


    If you like minimalism and want a very fast yet powerful window manager, dwm might be just what you’ve been looking for. However, it probably isn’t for beginners. There might be a lot of additional configuration you’ll need to do in order to make it just as you like it.

    To learn more about dwm, see the project’s homepage at https://dwm.suckless.org/.

    Episode 137.5 - Holy cow Beto was in the cDc, this is awesome!

    Posted by Open Source Security Podcast on March 18, 2019 12:01 AM
    Josh and Kurt talk about Beto being in the Cult of the Dead Cow (cDc). This is a pretty big deal in a very good way. We hit on some history, why it's a great thing, what we can probably expect from opponents. There's even some advice at the end how we can all help. We need more politicians with backgrounds like this.

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

    Show Notes

      GNU Tools Cauldron 2019

      Posted by Mark J. Wielaard on March 15, 2019 11:11 PM

      Simon Marchi just announced that the next GNU Tools Cauldron will be in Montreal, Canada from Thursday September 12 till Sunday September 15.

      The purpose of this workshop is to gather all GNU tools developers, discuss current/future work, coordinate efforts, exchange reports on ongoing efforts, discuss development plans for the next 12 months, developer tutorials and any other related discussions. This year, the GNU Tools Cauldron crosses the Atlantic Ocean and lands in Montréal, Canada. We are inviting every developer working in the GNU toolchain: GCC, GDB, binutils, runtimes, etc.


      The conference is free to attend, registration in advance is required.

      FPgM report: 2019-11

      Posted by Fedora Community Blog on March 15, 2019 09:35 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.

      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. The Fedora 30 Beta Go/No-Go and Release Readiness meetings are next week.


      Meetings and test days

      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.

      Blocker bugs

      Bug IDBlocker statusComponentBug Status


      An updated list of incomplete changes is available in Bugzilla.

      Fedora 31 Status



      Submitted to FESCo

      Approved by FESCo

      The post FPgM report: 2019-11 appeared first on Fedora Community Blog.

      Two new policy proposals

      Posted by Fedora Community Blog on March 15, 2019 05:19 PM
      Fedora community elections

      This post shares two new proposals for changes to Fedora Council policy.

      Policy changes

      While addressing another issue recently, the Fedora Council realized we don’t have a good policy for making changes to Council policies. That seems like a mistake we should fix. So I have submitted a pull request to the Council Docs repo that lays out a policy:

      Proposed changes to Fedora Council policies must be publicly announced on the council-discuss mailing list and in a Fedora Community Blog post in order to get feedback from the community. After a minimum of two calendar weeks, the Council may vote on the proposed change using the full consensus voting model. After approval, the change is reflected on the Council policies page.

      The intention is to make policy changes transparent and allow for community feedback.

      Channel bans

      In addition, we realized that we don’t have an explicit policy about issuing bans in channels for persistent off-topic conversation. We want to give teams within Fedora autonomy to act on their own within the boundaries of our Four Foundations and community norms.

      The Council developed a policy proposal that allows channel operators to ban individuals for persistent off-topic posting but makes it clear that the ban should only apply to affected channels:

      Teams within Fedora have the freedom to decide what is on- and off-topic for their fora (IRC channel, mailing list, Telegram channel, et cetera). Moderators may ban participants for repeatedly engaging in off-topic discussion, however they must file a ticket with the Council’s Code of Conduct issue tracker to report the ban. Bans for being off-topic in one channel may not be extended to other channels unless the behavior is displayed in that channel as well. In this case, each ban should be treated as a separate issue with its own ticket. Community members who wish to appeal the ban may file a ticket with the Council.

      To be clear, this is not intended for conduct that violates our Code of Conduct.

      Feedback welcome

      The Fedora Council wants community input. Please provide questions or comments in the Pagure pull requests:

      These will be submitted for a Council vote on Monday, 1 April.

      The post Two new policy proposals appeared first on Fedora Community Blog.

      NetworkManager 1.16 released, adding WPA3-Personal and WireGuard support

      Posted by Lubomir Rintel on March 15, 2019 05:00 PM

      NetworkManager needs no introduction. In fifteen years since its initial release, it has reached the status of the standard Linux network configuration daemon of choice of all major Linux distributions. What, on the other hand, may need some introduction, are the features of its 28th major release.

      Ladies and gentlemen, please welcome: NetworkManager-1.16.

      Guarding the Wire

      Unless you’ve been living under a rock for the last year, there’s a good chance you’ve heard of WireGuard. It is a brand new secure protocol for creating IPv4 and IPv6 Virtual Private Networks. It aims to be much simpler than IPsec, a traditional protocol for the job, hoping to accelerate the adoption and maintainability of the code base.

      Unlike other VPN solutions NetworkManager supports, WireGuard tunnelling will be entirely handled by the Linux kernel. This has an advantages in terms of performance, and also removes the needs of a VPN plugin. We’ve started work on supporting WireGuard tunnels as first-class citizens and once the kernel bits settle, we’ll be ready.

      More detail in Thomas’ article.

      Wi-Fi goodies

      Good Wi-Fi support is probably why many users choose NetworkManager on their laptops, and as always there are improvements in this area too. When wpa_supplicant is new enough, we’re now able use SAE authentication, as specified by the recent WPA3-Personal standard. This results in better security for password-protected home networks.

      New NetworkManager adds support for pairing with Wi-Fi Direct (also known as Wi-Fi P2P) capable devices. Read more in an article by Benjamin Berg, author of GNOME Screencast, who also contributed he functionality to NetworkManager.

      As usual, there’s also improvements to the IWD backend, an alternative to the venerable wpa_supplicant. With NetworkManager 1.16, users of IWD will be able to create Wi-Fi hot spots or take part in Ad-Hoc networks.

      Network booting

      Since the new version, it will be possible to run NetworkManager early in boot, prior to mounting the root filesystem. A dracut module will be able to convert network configuration provided on the kernel command line into keyfiles ready to be used by NetworkManager. Once NetworkManager succeeds in bringing up the network, it will terminate, leaving a state file for the real NetworkManager instance to pick up once the system is booted up.

      This removes some redundancy and makes the network boot both more capable and robust.

      Connectivity checks

      Finally, new NetworkManager is able to be more precise in assessing connectivity status. Under the right conditions (that basically means systemd-resolved being available, not necessarily default), we’re now able to assess connectivity status on per-device basis and check IPv4 and IPv6 separately.

      This will make it possible to prioritize default routes on internet-connected interfaces.

      What’s next?

      NetworkManager 1.18 is likely to see support for new Wi-Fi features; perhaps DPP and meshing. We’re also removing libnm-glib, since we no longer love it and nobody uses it anymore. Such is life.

      What else? You decide! As always, even though patch submissions is what makes us the happiest, we also gladly take suggestions. Our issue tracker is open.


      NetworkManager wouldn’t be what it is without contributions of hundreds of developers and translators worldwide. Here are the brave ones who contributed to NetworkManager since the last stable release: Aleksander Morgado, Andrei Dziahel, Andrew Zaborowski, AsciiWolf, Beniamino Galvani, Benjamin Berg, Corentin Noël, Damien Cassou, Dennis Brakhane, Evgeny Vereshchagin, Francesco Giudici, Frederic Danis, Frédéric Danis, garywill, Iñigo Martínez, Jan Alexander Steffens, Jason A. Donenfeld, Jonathan Kang, Kristjan SCHMIDT, Kyle Walker, Lennart Poettering, Li Song, Lubomir Rintel, luz.paz, Marco Trevisan, Michael Biebl, Patrick Talbert, Piotr Drąg, Rafael Fontenelle, scootergrisen, Sebastien Fabre, Soapux, Sven Schwermer, Taegil Bae, Thomas Haller, Yuri Chornoivan and Yu Watanabe.

      Thank you!

      Test Days: Internationalization (i18n) features for Fedora 30

      Posted by Fedora Community Blog on March 15, 2019 12:58 PM
      Fedora 30 Kernel 5.0Test Day

      All this week, we will be testing for i18n features in Fedora 30. Those are as follows:

      How to participate

      Most of the information is available on the Test Day wiki page. In case of doubts, feel free to send an email to the testing team mailing list.

      Though it is a test day, we normally keep it on for the whole week. If you don’t have time tomorrow, feel free to complete it in the coming few days and upload your test results.

      Let’s test and make sure this works well for our users!

      The post Test Days: Internationalization (i18n) features for Fedora 30 appeared first on Fedora Community Blog.