Sometimes it's good to have someone basically forcing you to make time to improve a lingering situation. Subversion was a long time a bottleneck (literally in I/O, and figuratively in collaboration) in RPMforge. I also had been using our public Subversion infrastructure for some unrelated Open Source projects.
So thanks to Yury V. Zaytsev (!) we are finally undertaking the migration to Github infrastructure. This will also mark the beginning of the project's name translation from RPMforge to RepoForge.
I am being fed up with the state of our RPMforge infrastructure lately. The RPMrepo website is down, and the RPMforge wiki is hosted there. This is a theme recurring every XX months. I myself neglected the infrastructure (as long as the repositories work!), simply because I lack the time to maintain it.
But since it is becoming a liability and we have more people involved, I want to fix this once and for all, I am looking for a few donated managed servers that we can set up so a single glitch does not rip out some of our infrastructure.
As we speak I am pushing the new wxGTK updates to the repository. It was needed in order to have a truecrypt package, but also required a lot of rebuilds and updates of packages that depended on wxGTK.
The good news is that this may bring us a bit closer to compatibility with EPEL, the bad thing is that the audacity builds fail (old and new versions) so for the time being no audacity, or no wxGTK update...
I also tried building the new VLC media player (0.9.2) but it had issues of its own so I did a rebuild of VLC 0.8.6i until I can fix it.
It is a common problem with packagers. Developers release a package 0.4, then release a 0.5a (or 0.5pre1 or 0.5rc1) and then release the stable 0.5. Of course, when packaging you have to foresee such problems and maintain a proper upgrade path from 0.4 to 0.5pre1 to 0.5rc1 and to 0.5. Often that means finding the meaning of a release string.
This weekend, after a few weeks of perl updates and fixing our perl SPEC file generator, I broke the perl dependencies and probably upset a few people along the way.
The good news is that we have some new tools for better automating and updating our perl RPM packages and the coming week I hope to finish updating the existing one.
The bad news is that your yum is broken by design. I wish apt was an option, but that possibility looks dimmer and dimmer. (Even though I am still an avid apt user)
One of the reasons why I wanted to start a blog is because I often stumble upon new and exciting tools. and sometimes I want to share some information or an opinion on it. So a blog seems a good way to ventilate (and archive) that knowledge. Much like offsite storage...
This week 2 interesting tools caught my attention.