FESCo Election: Interview with Till Maas (till)

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

Interview with Till Maas (till)

  • Fedora Account: till
  • IRC: tyll (found in #fedora-releng #fedora #fedora-devel #fedora-admin #fedora-apps #fedora-social #fedora-de #epel)
  • Fedora User Wiki Page

Continue reading “FESCo Election: Interview with Till Maas (till)”

Council Election: Interview with Till Maas (till)

This is a part of the Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, May 31st and closes promptly at 23:59:59 UTC on Wednesday, June 6th, 2018.

Interview with Till Maas (till)

  • Fedora Account: till
  • IRC: tyll (found in #fedora-releng #fedora #fedora-devel #fedora-admin #fedora-apps #fedora-social #fedora-de #epel)
  • Fedora User Wiki Page

Continue reading “Council Election: Interview with Till Maas (till)”

Fedora Classic or is it Traditional?

automobile-automotive-beetle-163809

In FESCo ticket 1878, Matthew, our project leader, suggested to find a different name for the Everything directory that used to contain all pieces used to build all the other parts of the Fedora artifacts because there are now other artifacts that do things differently such as Fedora Modularity or Fedora Atomic. Also there are other artifacts such as Fedora Copr. Therefore it is nowadays only almost Everything. Regardless of the name we will choose for this directory, this also made me realize, that there is no name for Fedora artifacts that used to be Everything or the packages formerly known as Fedora. How would you call it? Is it Fedora Classic? Fedora Traditional? Does this have a negative connotation to you? Does it maybe mean, that there will be no Fedora Classic in five years? I am looking forward to your comments.

Put Everything on Fire and Make Friends with the Robots

fire-burn-hell-warm-57461

From 29 August to 1 September 2017 Fedora contributors from all over the world flocked to Hyannis, Massachusetts to meet and work on improving Fedora. I was lucky to be part of it.

Our leader Matthew Miller opened the conference with his State of Fedora presentation that included a perfect quote for Fedora:

Let’s put things on fire in a good way and make friends with robots!

For me this is a great motto that also fits the conference. To stay in the innovators/early-adopters space, Fedora needs to constantly change. Unavoidable, this results in fires. But we need to make sure these are good fires that create space for good, new things. We changed a lot of things to allow modularity and now we can build great things with it. The other part is about increasing automation. This is what hopefully will result from the fire when adopting pagure for dist-git. Now we have the infrastructure ready for automating more tasks for packaging. This matches one of the last sessions by Stef Walter about Continuous Integration and Delivery. There he shared his experience with integrating robots into the creation of Cockpit and described best practices in making robots an integral part of a team.

 

 

There were many other interesting sessions and luckily there will be recordings of most of them. For the Atomic Host 101 workshop Dusty Mabe prepared an interesting lab session that he published in his blog so you can do it at home, too. It gave nice introduction into the special properties of Atomic Host. Being there in person I had the advantage that I could ask questions to find out more about the details which Dusty and Colin Walters happily answered. This is in my opinion the great extra value of live workshops on which Flock focussed: Getting introduced into new topics and giving/receiving immediate feedback. It is great to see, that there are already further use cases for the technology behind Atomic Host besides using them as a container host. Patrick Uiterwijk and Owen Taylor shared their experience running Atomic workstation. It seems to be doable but be prepared for a lot of extra work. In his visionary session about Fedora IoT Peter Robinson suggested to make use of the atomic upgrades for IoT devices to reduce the risk of bricking devices and allowing to easier recover to a previously known-good state. The ideas for Fedora IoT sound very promising but they still need a lot of work to be implemented.

In an evening session there was an the Fedorator building workshop. After reading about it on the Ambassador mailing list it was very interesting to learn to how to build one and understand it’s design. I volunteered to take one back to Germany, so hopefully we can present them at one of the next conferences. Anyone going to OpenRheinRuhr? The workshops fits great into another topic our project leader promoted – improving the Fedora Ambassador work. He focused on improving what Ambassadors do. For example targeting more events matching the Fedora objectives would be an idea. To me it would be great for Ambassadors to decide more consciously which events to visit and to properly show off Fedora’s unique selling points. However, at least for me personally the critical criterion is usually the proximity to my home town and whether I have time to be there at all. Therefore it might take a while to get enough people and presentations/workshops together. to actively pursue this. I like the vision nonetheless. Speaking of improving the Ambassador work, I see also potential in improving how to represent Fedora at events. But this could be a full blog post on its own and I want to get this one finished.

In the Bodhi hacking session Randy Barlow and Jeremy Cline helped me setting up a Bodhi 2 development instance. I lost track of Bodhi development after the switch from Bodhi 1. The new setup with vagrant is very nice and allows to test new code very easily. We tried to improve the speed for Fedora Easy Karma to get it’s update information. Initially we hoped adding indexes to the database would help but it seems there is also a lot of serialization going on that might make Bodhi send a whole database dump in the end instead of just the necessary data.

The other sessions, the hallway track and social events were awesome, too. Everyone was very friendly and it was great to meet more people in person that I only knew online. The organizers did a great job as well. The main possibility for improvement would be to make the scheduling more collision-free. There were some sessions that did not get many attendees because sessions for the same target audience were at the same time. My sessions suffered from this as well. Maybe there could be a poll in advance to figure out which sessions people want to go at the same time and then plan the schedule with this feedback. The Chaos Communication Congress uses halfnarp for this. Maybe this is an option for Flock, too.

All in all I am happy to have been part of Flock 2017 and hope to be there in 2018 when it is back in Europe.

Fedora Council Summer 2017 Election Results

fireworks-574739.jpg

The results for the Fedora Council Summer 2017 Election are published. Congratulations to Justin W. Flory for winning! He is very committed and I am looking forward to his efforts to improve communication in Fedora.

Also, I would like to thank everyone who voted for me. Thank you very much for the trust you put into me! Since the FESCo election was restarted you have to vote again in case you voted last week. On a related note, my candidate interview is now available at the Community Blog. Please let me know if you have any questions or remarks.

Collecting Local RPM File Changes

danbo-1865359.jpgDo you know this? There is an old system you set-up ages ago without using a configuration management tool like ansible and you did not setup etc-keeper right away. And now it is time to migrate the configuration from one Fedora or CentOS version to a newer one. It is a mess to figure out what did you change on the system compared to the distribution packages and it is not much fun to migrate these changes to a new system. Wouldn’t it be nice to be able to get a diff of your local system compared to a clean installation?

I would like to have this and I was thinking about what is needed to implement it. RPM  is so great to track the state of all local file it manages. It stores several attributes such as the modification date, size and one or more checksums (usually MD5 and SHA-256 for Fedora packages). This allows to easily find files that are changed locally, for example rpm -qVa will query the RPM database and show all files where one of the attributes changed:
$ rpm -qVa
S.5....T. c /etc/koji-gc/koji-gc.conf
S.5....T. c /etc/kojira/kojira.conf
S.5....T. /usr/sbin/koji-gc

I am not 100% certain what the attributes mean. I believe the T means the timestamp is different and the 5 relates to a different MD5 checksum and S might be size. The c probably identifies config files. Querying the RPM database is the first step to identify which packages need to be diffed but do not yet allow to create the diff. However this information could be used to at least collect all the files that contain changes needed to be migrated. After playing around with the RPM python API I am planning to write a small utility that allows to gather all local files that are changed and to put them into a tarball. Before investing too much time into this, do you maybe know if something like this already exists?

The next step would be to try to get the unmodified files from the original RPMs and then produce a proper diff. This would also mean to interact with the actual RPM repositories and download the actual file using yum or dnf I guess. What do you think about this idea? Would it be useful for you, as well? Is there something that implements this already?