Spring arrived and doing spring-cleaning I thought about all the cleanup tasks in Fedora. If you are interested in doing some Fedora spring-cleaning, I will show you some opportunities to get your hand’s dirty and Fedora cleaner.
The required cleanup tasks depend on the state a package is in. In my opinion there are about five different states:
Recently the Hacktoberfest started, your chance to get involved with free/libre and open-source software and get a cool free t-shirt. All you need to do is find one or more projects on Github and submit four pull requests in October. I recommend taking a look at the Fedora easyfix issues – they contain several issues in projects using Github.
At the end of last year Zacharias and Jacob joined me in representing Fedora at the 32nd Chaos Communication Congress in Hamburg, Germany. It was the first Fedora Event that I organized as Fedora Ambassador, therefore I was quite nervous. Until I arrived at the hotel it was unclear whether I will have any swag to decorate the assembly (there are no classic booths at the Congress), but I also packed some bluesweets, chocolate and Aachener Printen to lure visitors to our assembly. Luckily as you can see on the picture, additional swag also arrived in time.
In contrast to the booths at other events, we had kind of a round square table we we could meet with interested visitors and talk about Fedora and related topics – I wished that we could also show some more items, like a 3D printer, but I was not fortunate enough to win one at last years Flock. I tried to get a LED stripe running to show some Fedora controlled blinkenlights, but I did not get it ready in time. Despite the usual SWAG like stickers, DVDs and buttons, I printed some brochures designed for SXSW 2011 that I found in the wiki. They attracted several visitors, who took a copy. Thanks to the digitalcourage assembly I was able to print more copies for a small donation. Additionally I prepared some sheets that showed the GPG fingerprints of the current Fedora keys that were also popular at this event. It was a very interesting experience to organize an event an I am looking forward to this years Congress to implement some of the ideas I have to improve our assembly. I also liked the change of perspective, since the previous years I was mostly a visitor going to other assemblies to talk to people, this time the people found me. I am looking forward to representing Fedora at the 33rd Chaos Communication Congress this year.
Did you ever wonder whether the packages you have installed are still maintained or will be available when you update to the next release? I might have a solution to answer this question for you. Recently I wrote a little script that reports packages that are orphaned, retired or missing from your current Fedora/EPEL release or any newer release. It is still only in a proof-of-concept status, but I hope to get it into Fedora eventually together with a useful cron job (or systemd timer) to get regular status reports.
If you would like to know why there might be a difference between missing and retired packages, I have the answer for you. This is quite common for EPEL packages. Even if a package is available in for example EPEL 6, it still needs active action by a maintainer to branch it for EPEL 7. Therefore packages in EPEL 7 might currently be missing and still become available. I, for example, hope that ipython will get into EPEL 7, but I read on IRC that some RHEL 7 package is not recent enought for a recent ipython release. Therefore it might take a while. Also for Fedora packages it might happen that a package is retired before the next release is branched (which is currently Fedora 21), therefore a package might be reported missing for Fedora 21 and retired for Rawhide/Fedora 22.
Today I got to the script ready I previously used to report long time orphaned packages for Fedora to allow checking for other releases than Rawhide. I just sent reports for Fedora Branched and Rawhide and EPEL 5, 6 and 7 to the respective devel lists. Especially EPEL 5 needs a lot of care as there are about 700 packages in EPEL 5 that are currently orphaned or depend on an orphaned package. Eventually all orphaned EPEL packages will be retired (removed). For Fedora Branched and Rawhide is was already decided to retire packages that are orphaned for six weeks. However automation for regular reports and checking when the packages were orphaned is still on the TODO list.
To make sure that no packages are retired that you would like to use, please check the reports on the mailing lists for any packages you care about and claim them if necessary. Eventually I will create nice HTML reports that are updated more regularly to make everthing more visible.
This year I was happy to be able to attend Fedora Flock in Prague. It was a very nice conference and I mainly enjoyed to get to know a lot of other people I already knew from the Internet. I was especially happy to be able to meet Toshio, who now takes some time off from Fedora, so I am not sure if I ever will have the chance again.
The talks were nice, too. I learned about some new features in Python 3, which I would like to use very much. I am sure I will enjoy using keyword-only arguments, chained exceptions, advanced unpacking and the new OSError subclasses. It is too bad that too much of Fedora’s tool (yum, koji) are still Python 2 only, so I am not able to use Python 3 for the current projects (autosigner and autoblocker). Especially chained exeptions is something I was missing in fedpkg, last time I had to debeg something there. I am also looking forward to Bodhi 2 and hope I will be able to provide tests for Taskotron, which according to Tim’s talk about it, should be rather easy. I am also thankful to Nick, that he hosted a GPG keysigning party, which is something a planned to do if I had more time in advance. The late blog post indicates already that I am still short of time. Therefore I only got to mention some highlights from Flock, even though there was a lot more worth mentioning. Thank you to everyone who made it possible for me to attend Flock!
The updated package should now be available via yum update openssl\*. Please do not forget to restart your system after you installed them. The manual installation process described below should not be necessary anymore.
Please be a aware that the instructions to update openssl given for example in Fedora
Magazine are incomplete. I recommend the following steps (All yum commands
need to run as root, all commands need to be specified on one line):
# Ensure that koji is installed
yum -y install koji
# Download the required packages (these are more RPMs than
# you might need):
# Fedora 19:
koji download-build --key=fb4b18e6 --arch=x86_64 --arch=i686 openssl-1.0.1e-37.fc19.1
# Fedora 20:
koji download-build --key=246110c1 --arch=x86_64 --arch=i686 --arch=armv7hl openssl-1.0.1e-37.fc20.1
# Verify that the RPMs are good, this needs to return lines
# openssl-1.0.1e-37.fc19.1.i686.rpm: rsa sha1 (md5) pgp md5 OK
# If a line does not contain pgp md5 OK, try to download the
# files again
rpm --checksig *.rpm
# Now get a list of all currently installed openssl
yum list installed openssl\*
# This outputs lines starting like:
# openssl-libs.x86_64 1:1.0.1e-37.fc19 @updates
# For each line you need to install a new package, e.g. if
# the line starts with "openssl-libs.x86_64", you need to
# add the file
# to the following command:
yum install openssl-libs-1.0.1e-37.fc19.1.x86_64.rpm
# Install all necessary packages at once to avoid dependency
# After everything is installed, reboot your system
# (recommended) or restart the necessary programs
# Use needs-restarting to identify these programs:
yum install -y yum-utils
If you are wondering, which package might be available to build your EPEL packages on, check this wiki page. Initially created by Dennis Gilmore I extended it with information about which package are available to which architectures. Packages only present in one of the two architectures can be maintained in EPEL for the other architecture.
I recently added a patch to Fedora’s upstream release monitoring to allow specifying monitored packages with wildcards. This allows to easily monitor packages that come from a central upstream location, such as drupal or ghc packages. This reduces unnecessary manual work adding these kind of packages. Another type of packages this should reduce work are perl packages, but they are currently not all using only the default URL and regex aliases, but this should be addressable in the near future as well.