Just a note to folks out there who help out in, or are helped out by the freenode #fedora channel:
Due to a flood of unregistered spambots on the freenode network, we have had to make the #fedora channel require registration.
If you aren’t registered you will be redirected to #fedora-unregistered where links and notes can help you get registered and rejoin the main #fedora channel for support. Hopefully this will be a temporary measure until freenode migrates to their new shiny ircd in a few weeks. Sorry for the trouble, but it’s pretty easy to register. See you in #fedora!
PS: See http://freenode.net/faq.shtml#userregistration for how to register with freenode.
PPS: Also, if you see a flood of spam links in any freenode channels, please refrain from clicking on them. Currently they will turn your browser into an additional flooder and you will be removed from the network.
PPPS: There is no PPPS.
It looks like I might have been able to convince enough of the right people and soon the rawhide repository file ( /etc/yum.repos.d/fedora-rawhide.repo ) will be moving to a subpackage of the fedora-release package.
Why? Far too many times in #fedora have we had folks that come in who have just enabled every installed repository, thinking this will give them more software choices. Unfortunately, once these people have installed packages from rawhide it’s very difficult or impossible for them to go back to packages from a stable Fedora release, and invariably they are forced to re-install. This makes them sad and upset, and makes those helping them sad too. 
So, what does this mean? If you want to be using rawhide moving forward you will need to ‘yum install fedora-release-rawhide’ and enable it in the /etc/yum.repos.d/fedora-rawhide.repo file. If you install from a release once we have branched off rawhide for the next release, this package should not be installed by default, so you will have to install it to jump on the rawhide train.
Overall I think this is a good thing for our users and hopefully won’t inconvenience our rawhide folks too much.
As soon as the change lands I will be updating the fedora Rawhide wiki page. If folks know of any other docs that should be changed, please let me know.
As Christoph mentioned we are trying to open things up more and get more people involved in the Xfce SIG.
Toward that end we have created a new mailing list: here
as well as trying to figure out a good irc meeting time
Please join us if you use or have interest in Xfce in Fedora!
Sadly the source check script I ran last week was going against old data and thus not very helpful. ;(
What happened was that I had a devel.tgz checkout in my sourcecheck directory, and did a wget to get the latest one, and wget helpfully made a devel.tgz.1 file, which I didn’t notice and unpacked the devel.tgz from 2008. ;(
In any event, I checked out the right thing and re-ran the script.
See the devel list posting at: http://lists.fedoraproject.org/pipermail/devel/2010-January/129027.html (hurray for shiny new list after the migration yesterday!).
So, if you are a Fedora package maintainer and see your name in the output, please take a few minutes to fix your packages in devel and commit (but no need to build now) to CVS.
As I mentioned I have taken to reading ebooks (usually in epub format) recently on my phone.
The most recent one is First Light Chronicles: Omnibus.
This is a hard sci-fi space book, that’s really 3 “books” in one (thus the “Omnibus” name). The characters and setting and universe are pretty compelling here. The author is a bit dry I think in the way they write, but that works well with the hard sci-fi setting. I fear many of the feats the crew manages are also a bit on the unbelievable side especially given the time constraints they have, but there’s good suspension of disbelief at least.
Overall an entertaining read, and I am looking forward to the other books set in this same universe.
spoonfeeding:
noun
1. feeding someone (as a baby) from a spoon
2. teaching in an overly simplified way that discourages independent thought
I’ve been accused of this in the #fedora channel, so I thought I would throw out there my thoughts on this.
Overall I think it comes down to where you draw the line between ‘overly simplified’ and ‘helpfull’. Would you consider pointing someone to a specific link that addresses their problem spoonfeeding? How about if they run into problems following the steps from a link and want more help? Like many things it’s not a black and white line, it’s shades of grey or a spectrum from on one end to the other: “figure it out yourself and don’t bother me”, “http://lmgtfy.com/”, “Here’s a link that should help”, “You are stuck on step 5? ok, pastebin your exact output and let me try and break it down more for you’”, “Here’s a screencast showing the exact button to press”, “Let me explain how to plugin in and turn on the computer”, “Let me just login to your machine and do it for you”.
I personally think that Fedora support channels should at least go to the level of “Here’s a link that should help you” and likely to the “You are stuck on step 5? Let me try and break it down more for you” and don’t consider that spoonfeeding. My personal line is there before the ‘Here’s a screencast’ step, of course each person has their own line.
Of course if you find yourself in a Fedora support channel holding a spoon when you didn’t mean to be, it’s fine to tell the person you are helping that the spoon has to go back to the dishwasher and get someone else to continue to help them. 
I’ve just finished another run of my sourcecheck script against all the Fedora devel packages.
What is that you might ask? It’s a pretty basic shell script that does:
- Operates over a full Fedora CVS checkout (which you can get from: http://cvs.fedoraproject.org/webfiles/)
- For each package it runs ’spectool -g *.spec’ to fetch any Source files that have a URI.
- It checks any downloaded sources against the ’sources’ file in CVS (which has a md5 checksum of the package sources from the lookaside cache
- It generates a basic log line for that package about what happened
So, why would I do this? Because it notices problems that we should fix. If a source is no longer available at the URI in our package it should be updated. If source has changed upstream without a new version, upstream maintainers should be notified and the issue corrected. If some maintainer checked in sources that don’t match the upstream project we should find out why. Imagine an end user looking at your spec file and trying to download sources for a package that they would like to contribute to, only to find that the URI is wrong.
This is the kind of thing that the AutoQA project should hopefully be able to take over at some point, but I’m happy to run my script until then. With AutoQA hopefully we can check this at spec/sources checkin time and stop the package update/import until the issue gets fixed. Until then we shall just have to clean things up as best we can.
So, if you maintain packages in Fedora, do take a minute to look for your name in http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20100105.txt and fix up the Source URI’s in any packages listed. It’s the right thing to do.
EDITED TO ADD: Sigh. Looks like my devel checkout was from an old checkout, so some/many of the results here will not be current. I am re-running it again against the current devel packages and should have an updated list in a few days. ;( Sorry for the trouble.
I recently got a Motorola Droid phone. I am loving it so far. Here’s a pic from the phone camera on today’s dog walk of Nash, posted from the phone. Hopefully this will make it easy to take and share photos for me.