Do not forget to vote the new FESCo, only about 12 hours are remaining.
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.
Keep in mind hat in about seven weeks a lot of currently orphaned packages will be removed from the EPEL repositories, if nobody shows up to maintain them. My script will help you identify packages, you might be missing, therefore it is now a good idea to join the Fedora package maintainers and adopt orphaned packages that are important to you.
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
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.