Looking back at the last Fedora year (2)

Yesterdays post got some comments, so here is my reply.

Max wrote:

• The Board not being active enough This is 100% my fault, and it is one part of Fedora that I will look back on as the place where I feel like I have personally failed. The Board has tried hard to allow FESCO decision making power, but it hasn't really picked up the ball for being a sponsor for other activities that Fedora so desperately needs.

I don't think it 100% your fault. It just happened that way. When we discussed the government of the merged world we wanted to keep FESCo in control of Fedora (the Linux Distribution, not the Project), because FESCo was well known and accepted among the packaging contributers.

Looking back at that decision now it was correct and wrong at the same time -- yes, having a committee that is completely elected and formed out of those that take care of the bits is good. But FESCo IMHO lost most of the reputation it had in the Extras days. That's happened more by accident and not on purpose -- with the merge FESCo got much more things to take care of, so there simply isn't much time for many of the tasks FESCo handled back in the Extras days. That afaics resulted in a lot of small things here and there that were (or are) not that well, which resulted in a bit of dissatisfaction among the contributers.

• New leaders -- I think we are developing new leaders [...]Compared to the rate at which leaders emerge from other organizations, I think Fedora does fairly well.

Ohh, well, agreed, there are new leaders emerging in Fedora-land -- but afaics all of those you mentioned in your blog or your "lesser known Fedora contributors" series come from other areas of the project, not from the packaging area (which has more the 500 contributers).

IOW: in this most impotent area of out project (where many if not most of our current leaders come from) we're are not doing "fairly well". I'd even say we are doing bad here, as we afaics lost some very active members like jpo over the past year or seem to losing them (mschwendt) -- both of them were members of FESCo and did a lot of good work for Fedora but seem unhappy these days.

JonRob wrote

• [...] you should definitely consider running for one of the boards or try and be a bit more vocal about it and get a real discussion started!

No, with my current job I can not join the Board or FESCo :-/ And I suppose the time for my post wasn't the best, as it will be forgotten after christmas and new year, so I don't think there will be much of a "real discussion".

Andrea Musuruane

• "review queue much to long; I think we need a more wiki-style approach and a easier (more automated) review process". I've been thinking about how to solve or alleviate this for some time. It seems that most packagers are more interested in submitting packages than reviewing. Therefore I came up with two ideas:
  • Have a package review day each 4(?) months. This could be a way to shorten the queue.
  • Force the packager submitter to swap reviews with another packager for each submitted packages.

Well, we tried a "package review day" in the past. It worked, but wasn't a big success iirc. Enforcing swap reviews is something that I've thought about as well. But I think before we enforce them we should strongly encourage them more and help people with swapping; I suppose that might be enough already.

Looking back at the last Fedora year

Looking back at the last Fedora year

Year's end is close and I'm currently a few days off from work (had to take the reaming untaken vacation days), so it might be a good time to look back at the past Fedora year and see what happened and what's good ( +1 - +3) or bad (-1 - -3):

• +3 -- Fedora has a predicable release schedule (finally)
  
• +2 -- Core and Extras repositories merged. Overall it was a good thing for Fedora and its users. But there were many things that sort of came together with the merge that I'm not so happy with (see below).
  
• +2 -- EPEL started. We have about 900 packages (counting SRPMs for EPEL5 here, that build about 1650 RPMs in total) in it now -- that's good, but I hope we get a lot of more in the next few months. Fedora has about 5000 packages right now, RHEL5 about 1100, thus there is still a delta of round about 3000 Fedora packages that could be added to EPEL ;-) But EPEL just like the Fedora merge has some downsides (again: see below)
  
• +2 -- RPM Fusion will hopefully become a proper semi-official 3rd party repo; but it's still not started, as setting everything up in a Fedora-like-way (FAS, CVS, buildsystem, ...) just takes time; I had hoped some people from Fedora infrastructure that are familiar with the all those bits would help us at least for the start, but only Kevin jumped in (thx Kevin) which delayed and still delays things /me will take a look at FAs later this week again)
  
• +2 -- Livna is in a better shape then a year before; we even got new contributers again (mainly thx to the RPM Fusion effort, where the Livna packages and contributers will be moved to once it's started)
  
• +1 -- Fedora 7 -- late (due to the merge) and to early (due to the merge -- bodhi and some other things were finished "just in time" and created a lot of frustration)
  
• +1 -- Fedora 8 -- thx to the Feature-tracking in the wiki we now advertise our features better and don't leave the credit to others that pick our code up
  
• +1 -- the number of fedora maintainers grew
  
• +1 -- Kmods were dropped from Fedora; at the same time we got a few more in Livna; I also enhanced the kmod stuff a lot (more to come) and often the livna kmods are in the repo just a few minutes after the new Fedora kernel hits the repo (e.g. before the kernel hits most mirros)
  
• +1 -- for Fedora-unity (respins, revisor) -- but why can't we do that directly in Fedora? Especially the respins is IMHO something Fedora should do, as we had bad bugs in the install-media in most of the the past releases
  
• -1 -- there is not a lot of contributer interested in EPEL steering issues or EPEL improvements -- seem people like EPEL a lot, but are not much willing to invest their time to improve it besides maintaining their packages in EPEL
  
• -1 -- the tone on the Fedora mailing lists became unfriendlier
  
• -1 -- the mailing list are still a mess; even long-term contributers seem sometimes confused where a post is on-topic
  
• -1 -- the Fedora-wiki is a bit messy -- if you search for a term you often find told IRC logs, which most of the time is not what you looked for; many real pages are not really up2date
  
• -1 -- my Fedora-Dream-DVD (x86-32, x86-64-Install media with a Live-CD that features both GNOME and KDE all on one Double-Layer-DVD) is still not there, even if such a beast would be ideal for computer magazines to ship
  
• -1 -- still no proper package webinterface for users with a static URL where upstream can point users to
  
• -1 -- Codeina (was: CodecBuddy) -- I think Fedora should have stayed away from it.
  
• -2 -- Fedora has to much bureaucracy
  
• -2 -- Fedora has to much committees; we needs most of them, but should reduce their influence so new contrinuters that want to improve something can do so without running against hurdles
  
• -2 -- review queue much to long; I think we need a more wiki-style approach and a easier (more automated) review process
  
• -2 -- still not easily possible for long-term contributers to fix packages which are owned by other contributers (ACLs and the general but unwitten "don't touch packages you don't own" attitude are the two main reasons for it)
  
• -2 -- The way the Fedora Board works IMHO got worse and lost contact to the contributer base -- the Board only meets in private, the meeting schedule is often not announced beforehand, not much traffic on fedora-advisory-board (there were way more discussions early this year), the meeting summaries sometimes get posted a week or two after the meeting (nobody comments on them anyway) are some of the reasons for my opinion. It sometimes seems to me the Board work in a different universe -- and even I who follows lots of mailing lists and blogs sometimes wonder what the Board does for Fedora; I know they do a lot of good work for Fedora, but the only main visible thing from the past weeks afaics is the FUDCon (and the election of one seat of the Board, but self-organization IMHO does not count for real)
  
• -3 -- EPEL and it's contributers seems to be the bad guys in some peoples eyes. "EPEL doesn't do repotags" is one reason for it -- but it at least for me was not a political decision, it was a technical one, because some long-term Fedora contributers I trust showed examples where repotags can do harm. "EPEL doesn't cooperate" is mentioned often as well, but that untrue -- we got some packages (yum and its deps, yum-cron) into EPEL in a way to not disturb CentOS-Base and are willing to cooperate other specific issues as well (we don'st need a formal cooperation document for that; we can just do it; if someone thinks we need one: write one please!). EPEL also failed to get CentOS onboard (even before the repotags issue came up), which afaics happened due a lot of stupid misscommunications and misunderstandings on both sides (totlly apart from repotags) :-/
  
• -3 -- still no sudo or similar technology in Fedora by default (pup for example still asks me for the root password on F8 each time)
  
• -3 -- I tried to do realize some things in Fedora-land without being a member of the Board and FESCo. But most of the time it was hard or painful and sometimes a very frustrating experience. That why I stopped working in this area and only speak up these days if there is something that seems really wrong to me.
  
• -3 -- seems I'm not the only one frustrated (got that impression from looking at the lists and from talking to other contributers) -- most contributers seems to not much care what the Board, FESCo, Rel-Eng or FPC do; the contributers just accept what got decided. That's makes decision finding a lot easier for those committees, but I much prefer a proper discussion (even if it results in a mini-flamewar) where contributers share their opinion. We had that one year ago in Extras-land, but lost it during the merge. IOW: FESCo seems to take care of the Distribution these days (Features mostly), but lost the community contact FESCo had in the Extras days (which was still far from perfect, but a whole lot better).
  
• -3 -- some people say new leaders emerged, but I disagree; nearly everyone from the Board, FESCo, FPC, Rel-Eng is around in Red-hat- or Fedora-land for a long long time; we also got nearly no new sponsors, just more packagers;
  
• -3 -- I can neither join the Board or FESCo (the latter became a Problem due to the merge, that's why I had to leave) to make things better due to conflicts of interest with my day job (maybe I should send in my resume for Max's job, but that position is based in the US :-/ ) I'm unsure if I even wanted to join the Board or FESCo these days if I could -- I lost the energy and the interest over the merge because there were so many things that seemed handled in a wrong way to me.

VMWare util and driver packages

Dear Fedoraweb,

Is anyone around who's interested in maintaining open-vm-tools packages (kernel modules and userland utils for VMWare products) in Livna (and RPM Fusion, once I or ixs get around of setting up FAS and the look-aside cache for CVS)? The package are prepared already and mostly reviewed (see 1664 and 1665), but the packager switched all his systems from Fedora to Gentoo (good luck with that Brandon!) and abandoned the packages after a final update (thx for hat Brandon!). He mentioned in bugzilla that the packages work for him; and it seems they work fine for duke as well, as they have a slightly enhanced version of those packages in their repo. I'll of course help with the final review steps and the Livna import.

Quicktext for GNOME panel?

Before I switched to Linux (years ago) I used text-templates a lot -- that made for example answering e-mails a lot easier and quicker. I still do it using Quicktext in Thunderbird sometimes these days. But Quicktext is bound to Thunderbird and sometimes it'd like to have its functionality available other apps (Editor, OpenOffice, ...) as well.

Dear Lazyweb, do you know a Gnome application (integrated into the panel ideally) that makes a similar functionality available desktop-wide (in cooperation with the clipboard if needed)? I asked Google -- all I found that half-way matched my use cases was blah, which seems to be one of those ten thousands of inactive sourceforge apps that were abandoned by their developers.

Parallel universes ^w discussions

Mailing lists are funny sometimes -- like today on fedora-devel. There is one discussion where some people support the idea to get rid of mosts ACLs in CVS (often found in old Core packages) so all (new and old contributers) can commit (nearly) everywhere.

At the same time there is a debate about restricting CVS more due to security concerns (disclaimer: I'm the one that brought the old topic up again), as a malicious attacker can modify random packages in CVS once he got sponsored for cvsextras (with is neither easy nor very hard). The latter discussion resulted in a IMHO nice post from John Dennis. To quote just a part:

Linux has been mostly immune to malware. For anyone writing malware one of the challenges
is propagating the infected code.

So lets not give bad folks the perfect vehicle for distributing their malware through an
official update channel which automatically gets pushed to tens of thousands of machines
with the implication of being clean software. Such an event would be devastating to the entire
open source community.

The funny thing about it: both the views I mentioned above are IMHO right somehow. We IMHO need to get hurdles (like to restricting ACLs, but also those in our heads that say "that package is owned by someone else, I won't touch it") out of the way to have a more wiki-like working style for maintaining packages in Fedora. But at the same time we need fences to prevent that new contributers immediately get access in areas where they don't need access, to prevent malicious people to do bad things easily.

Problems updating kernels and kmods (2)

Remember my Post about problems when updating kernels on systems with kmods? A updated yum package which should fix the problem is on the way to updates-testing -- thx to skvidal for fixing the problem. Hopefully the new yum makes it to the stable repo before the next kernel update.

Flexibility

Cnet cites Max: Red Hat wants Fedora to be a foundation for those who want to build their own Linux products on a Fedora foundation.

dwmw2 wrote: I'd love to see more functionality -- more _possibilities_ -- merged under the 'Fedora' umbrella.

There are more such statements from other people; the general idea is floating around for some time now in Fedora-land. I'm wondering if we should issue something like Max statement above as official goal for the next few Fedora-years, to have a target we can work towards.

But can Fedora really be a proper foundation for other distributions? What if somebody wants to create a complete OpenVZ or Linux-VServer distribution (just as example) with Fedora as a base *within* the Fedora-project to ensure updates and patches for all non-OpenVZ and non-Linux-Vserver stuff floating back and forth easily between this special spin (wich patches Fedora would not take) and the official Fedora? E.g. something similar to what OLPC in parts did?

Something like that afaics would be needed if we really want to be a proper foundation for other distros, as the "once Fedora-size fits all" is a good goal we should aim for with Fedora, but on the way to that sometimes special treatment and a semi-fork might be needed. Not to mention the old Who will ship the sources to fulfil the GPL-requirements problem that's still unsolved.

IOW: if we really want to be a proper foundation for other distributions there is much work to do afaics.

[Update 20071129-2110UTC]I just reused the word "foundation" (meant as in "base for a product/distribution" here) from the Cnet source. Do not confuse it with the "Fedora Foundation", a idea which was abandoned long ago.[/Update]

Problems updating kernels and kmods

I announced in on fedora-list@redhat.com and freeworld@livna.org already, but seems a lot of people ran into the problem and missed my post, so I put a slightly enhanced version of my post here as well:

F8 users with kmods will run into problems when updating to the
latest kernel from Fedora due to a problem in yum from F8 (at least
it looks like a bug in yum to me atm). See
https://bugzilla.redhat.com/show_bug.cgi?id=330711
for details. The problem looks like this:

# yum update
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package kernel.i686 0:2.6.23.1-49.fc8 set to be updated
---> Package kmod-nvidia-96xx.i686 0:96.43.01-17.lvn8 set to be updated
--> Processing Dependency: kmod-nvidia-96xx-2.6.23.1-49.fc8 for package: kmod-nvidia-96xx
--> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package: kmod-nvidia-96xx-2.6.23.1-42.fc8
--> Running transaction check
---> Package kmod-nvidia-96xx-2.6.23.1-49.fc8.i686 0:96.43.01-17.lvn8 set to be updated
--> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package: kmod-nvidia-96xx-2.6.23.1-42.fc8
--> Finished Dependency Resolution

If you run into this problem you can uninstall the kernel-modules for
the current kernel with this command :

rpm -e --nodeps $(rpm -qa 'kmod-*2.6.23*')

as workaround and then run yum update; you should get the new kernel and
the new kmods for it when running "yum update" afterwards.

Sorry for the trouble. Note that we have seem other problem in F7 due to this problem in the past already as well. According to a comment in above bug report it looks like other kernel module packaging standards might be affected as well.

While at it: looks like there is another bug in yum that affects kmods. In some situations the i586 kmod gets chosen to install, which tracks in the i586 kernel, which then leads to an error, as that has file conflicts with the i686 kernel. This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=346371
You can work around the problem by specifying which arch to install by running "yum install kmod-foo.i686".

Testing new features in rawhide

Much talk about pulseaudio everywhere, so I wondered what it's all about and wanted to take a closer look (I likely should have done it weeks ago, but I was busy with other stuff...).

It wasn't really easy to find all the bits I need (I know, there were posts on fedora-devel-list or fedora-test-list weeks ago that explained what's needed, but well, that was months ago and they are not easy to find as well). Especially locating the volume control app made some trouble -- you see screenshots of it everywhere but that doesn't help much if you don't know the binary's name or the name of the package which contains it. Especially if you are so stupid as I was and just look in the packges with pulseaudio-prefix (hint for those that run into the same trap: the binary is called pavucontrol and it's package is called the same).

Those that install F8 freshly (once it's released) have more luck -- they will get the important bits by default. But rawhide testers (I updated this machine from F7 to rawhide months ago) didn't get it -- with IMHO kind of sucks, as a feature that will become by default isn't tested by default by regular rawhide users...

BTW: those that update from F7 to F8 with yum later won't get pulseaudio by default either...

All it takes is code, and time...

Hans, Kevin, thanks for taking up the idea from my mail and discussing it further. I don't have the energy anymore for driving such discussions much further, as I got the impression that it's not worth the trouble in Fedora-land these days. In the end there is often a lot of discussion and wasted time. The hurdles to fix it yourself are often way to high as well. Thus the problems stay and don't get fixed (and surely there is a problem here that needs fixing).

See the "Firefox update breaks repo" problem, which we have for years now. Instead of letting someone do for released updates what Jeremy did for rawhide some days ago the problem comes up every few weeks or months again. But no, FESCo discussed it ages ago and then forgot about it during the merge; like so many things. Lot's of good ideas from different people afaics don't get realized because we have committees and bureaucracy everywhere and people yelling "show me code" instead of being helpful and say "yeah, that problem needs fixing; not sure if your idea is the best, but we put it on the Board/FESCo/FPC schedule and will try to fix it over the next months; we'd appreciate your help with that and bring you in contact with the right people".

It's imho really frustrating. In Extras contributers helped each other out and FESCo tried to work towards a better Fedora Extras for users and contributers. We lost that "help each other for the common goal" during the merge afaics.

While writing some of my frustration on the state of Fedora down: Max, where do you see new leaders emerging in packaging land (e.g. old Fedora Extras)? Most if not all of those that are in FESCo, FPC, the Board or active on the lists these days are the same people that were as much active in Fedora Core or Extras one or two years ago already. So I'd say there is a stagnation here. In fact we even lost some people afaics, so it's going down -- the low number of volunteers during the last FESCo election is a indicator for that.

Another indicator for stagnation: we didn't get much (any?) new sponsors during the past months during and after the merge afaics (¹). In the past we each meeting asked for nominations and approved about one or two new sponsors per month -- it was even on the schedule each time so people that might want to self-nominate got a reminder where to self-nominate.

(¹) -- I have no hard numbers, but I got the impression there were just very few new sponsors over the past months. Does anyone have real numbers?

Fedora planet and english speaking feeds

The current discussion on "fedora planet and english speaking feeds" IMHO is a good example for what I call the "Fedora knows better then you what's good for you and thus Fedora only gives you what Fedora thinks is best"-attitude which IMHO becomes more and more a problem in different areas of the project.

IOW: There is no black and white here. Some people want a multi-lingual feed, others a english-only one (and likely others a German or a French one as well) -- there are good arguments for both sides. Thus we need to give people the choice here and have a sane default -- otherwise people stop reading Fedora Planet (like for example Pete did), which is not what we want. So thanks Airlied for setting such a feed up.

I hope we can have the feed alongside the current one on planet.fedoraproject.org/ in the future -- e.g let planet.fedoraproject.org/ be the default and multi-lingual while en.planet.fedoraproject.org/ (or planet.fedoraproject.org/en/ ?) serves those who want English only. Problem solved, everybody happy.

BTW: I don't care much about the non-english content -- the amount for me was up to now still acceptable. Okay, sometimes it was starting to become annoying and nearly reached the this-is-really-annoying trigger level -- but only nearly for me. But I suppose sooner or later with more feeds being tracked it would have been triggered, as it did now for Lennart afaics.

Further: A non-english post on an english-only planet now and then IMHO is likely no problem and I assume acceptable for everyone. It's normal that some post are off-topic in the blog/planet world afaics -- just like the post from Lennart was not really on topic for other planets like planet.gnome.org.

The difference between IRC and mailing lists

On IRC if you enter #fedora-devel and ask a question that is off-topic and more suitable for #fedora you get pointed there.

The question itself is not answered normally (even if it's a real easy one). Seems there is a silent agreement between those in the channel to not answer, as the questioner (or someone else) might come up with even more off-topic questions or comments sooner or later in the channel.

On fedora-devel-list@redhat.com that's handled differently.

fedoradev-pkgowners -- get package owners from pgkdb

Could not really sleep last night :-(( -- the cold I had one or two weeks ago came back on Friday and was likely the reason for it.

So I went down into the living room again a 1:00 in the morning and looked to work on something easy. I had a rough "look the owner of a package up by its name using the bugzilla data in the pgkdb" script lying around at which I took a closer look again -- I started to write it some weeks ago, because I got more and more annoyed when people posted mails like "the following 42 packages needs to be rebuild because some good reason" on fedora-devel and then just putting the list of packages names below it. It's better then not sending such mails, but for people with more then n packages (n likely something between 10 and 25 packages) it's not really helpful, as they can easily miss one of their packages in such a list.

Thus I improved and polished that script (nearly 250 lines in total now, including license and comments :-/) and upload it to the wiki today, as it's likely useful for other Fedorians as well. You can find it on the UsefulScripts page (which, btw, needs a cleanup afaics) now.

Here is a example how it can be used:

$ ./fedoradev-pkgowners ntfs-3g enigma gnome-desktop \
 kdebase | sort | column -t
rstrode  gnome-desktop
spot     ntfs-3g
than     kdebase
thl      enigma
$ #
$ echo "ntfs-3g enigma gnome-desktop kdebase" | ./fedoradev-pkgowners \
  --fasfile fasdata --email --pkgdbfile tmp/bugzilla | sort | column -t
rstrode  gnome-desktop  rstrode_[AT]_redhat.com
spot     ntfs-3g        tcallawa_[AT]_redhat.com
than     kdebase        than_[AT]_redhat.com
thl      enigma         fedora_[AT]_leemhuis.info

It likely has still some bugs in it as I wrote big parts of it in the middle of the night (which is really unusual for me -- I'm not one of those that works in the night normally), but it's a start and hopefully useful for others as well.

Thinking about it: wouldn't it make sense to put this and some of the other scripts into a fedoradevtools package? That would make it easier for people to get this and similar scripts and keeping them up2date. The idea is similar to the concept from rpmdevtools (which IMHO is a rea success), but putting fedora-specific things into that package seems wrong to me.

How to use the wiki properly

Keeping docs like the Proposed Fedora Features or Schedule pages in the Wiki up2date seems to be boring task for a lot of people (including me) -- often it's done rarely. For the Proposed Features John Poelstra does a good job of poking people when needed and takes care of the pages himself as well (thx for that John).

Matthias Clasen at the moment demonstrates how good the wiki can work if people update the status and proceedings of a task in the wiki properly: he keeps the Clock Applet page update nearly daily (with screenshots!) -- thus it's easy to follow the progress by subscribing to the page, even without being involved directly with the task. Matthias even reacted to a comment I put on the page.

Really nice -- that's how it's supposed to work, but often doesn't. Thx Matthias and keep up with your good work!

"Rapid innovation" (2)

Ajax commented on my "Rapid innovation" post. As stuff in comments easily gets lost in the noise I'd like to quote it here:

Because the one part of 1.4 that's most broken is input, and we didn't think we had enough time to land that and also fix all the bugs in it before F8. That's why the X server contains tons of backports for everything outside of input.

Maybe rebasing earlier would have solved this. But, maybe not. I've seen basically zero patches from the Fedora community for X issues, and at least speaking for Red Hat's X team, reworking input isn't really high on our list of priorities, so fixing that would have taken away time from everything else we're already doing. So I don't have any reason to think rebasing earlier would have helped.

Many thanks for clarifying the issue Ajax. I expected there might be "good reasons" to not update to 1.4, but well, this post sounded much like "feature freeze" and left me (and likely other Fedora contributors as well as our users) totally in the dark why exactly we were not using xorg-server 1.4.

I ignored that for some time, but then came the WhyUpstream stuff and some minutes later I stumbled over that pile of patches that got applied to the xorg-xserver package and got a bit confused...

So thx again for all your work on X ajax, krh, airlied and the other X-heros Fedora and Red Hat have.

Videos auf SPON

I normally write my blog only in English, but today is a exception, as the information is relevant to German-speaking people only in any case...

----

Ich gehöre wie viele andere deutschsprachige Internet-Surfer zu den Lesern von Spiegel Online (SPON). Kann sein, dass Stern, Tagesschau.de oder was auch immer qualitativ besser sind, ich bin recht zufrieden mit SPON.

Seit einiger Zeit hat SPON verstärkt Videos. Ich nutze dies Angebot nicht besonders häufig, weil das Verhältnis von Informationsgehalt pro investierter Zeiteinheit meines Erachtens schlechter als bei Text ist. Aber ja, klar, ich hab auch schon das ein oder andere Video auf SPON gesehen und sie würden mich ja normalerweise auch nicht groß stören.

Neuerdings haben die Videos einen prominenten Platz weit oben in der rechten Spalte -- man bekommt so bei praktisch jeder Meldung, die man liest, auch ein Standbild aus dem Video als Lockangebot gezeigt. Soweit auch nichts wirklich besonderes oder störendes -- manchmal findet man ja auch unter den Textangeboten in der rechten Spalte was interessantes .

Das eine sicherlich nicht zufällig ausgewählte Standbild aus dem Video steht aber für sich -- worum es geht, ist nicht weiter ersichtlich, da erklärende Worte fehlen. Das alleine wäre für mich auch nur "schlecht gemacht" -- aber in der letzten Woche viel mir mehr und mehr auf, dass ein nicht unerheblicher Anteil der gezeigten Standbilder gerade einen Moment aus dem Video aufgreift, wo eine attraktive oder zufällig vielleicht sogar leicht bekleidete Frau im Bild ist. Okay, es passiert verstärkt in der Rubrik "Panorama". Aber trotzdem: Muss das sein? Ich weiß, das Menschen so leicht zu ködern sind, aber bloß weil es geht, muss man es ja auch nicht machen, oder?

Also liebes Spiegel-Online-Team: Ein paar erklärende Worte zu jedem Video-Standbild bitte, sonst wirkt das mit den leicht bekleideten Damen wie billiger Kundenfang -- den hat die Bild-Zeitung sicher nötig, aber Ihr nicht.

Mit ein paar Worten dazu habe ich auch nichts dagegen, wenn attraktive Frauen abgebildet werden -- dann weiß ich aber wenigstens, ob Ihr Kundenfang betreibt, oder ob das nur zufällig hübsche Reporterinnen sind, die mir war wirklich wichtiges erzählen würden, wenn ich das Video ansehe.

Rapid innovation

From the Fedora-Wiki-Frontpage: The goal of Fedora? The rapid progress of free and open source software and content. [...] Rapid innovation. [...]

That what I like about Fedora -- you get new kernel versions, new releases from hplip, sane, gutenprint an lots of other stuff during lifetime of a distribution.

But I sometimes get the impression other parts of the distribution follow a different update strategy than for example the software I mentioned above -- the X-Server for example. The Xorg server 1.4 from X.org 7.3 (released about two month(¹) before the currently estimated Fedora 8 release) for example will afaics not make it into Fedora 8. Instead we are backporting lots of stuff to the current Xorg server 1.3.

I completely fail to understand why. At least I'm not aware of any good reasons why we didn't update rawhide some weeks ahead of the official X.org release -- that how we do it for Kernel, GNOME and lots of other stuff in rawhide as well.

But well, it happens more and more often these days that I think the Fedora project is getting worse and not better, as everybody had hoped during the merge. Way to many Committees (often the same people in them(²)) for example make even easy stuff hard to realize -- that slows progress and frustrates contributors. What is missing IMHO is a strong leadership (³) which is more involved with the distribution we create and shows the direction forward.

BTW, Rahul, the current WhyUpstream draft starts with: Fedora Project has a strong focus on not deviating from upstream as much as possible in all the different software it includes in the repository. I agree that that's how it should be, but for the X-Server (which is a major part of our Distribution) it's definitely not the case afaics.

(¹) -- two month are one third of one development cycle!

(²) -- we fail to build new leaders -- most of the active community contributors, package sponsers and FESCo members were in the same or similar positions one or two years ago as well. That IMHO tells us that we fail to build a community and have a to high entry burden

(³) -- Max sorry, I know that you are doing a lot of stuff and really good work that needed to be done. Don't take that as critique on your work

Overlay repos and dong releases from it?

Disclaimer: I'm a Gnome user and don't care much about KDE

Another disclaimer: KDE is just a example; the scheme I outline below could likely used lot for other stuff as well (other Desktops like Gnome and XFCE; new stuff like AIGLX was in the FC5 days; crucial apps like Firefox, Thunderbird or OpenOffice; there are likely more examples).

People seem to really want KDE4 out in official linux distribution/included in a released Fedora as soon as it hits the street. I can understand that. But well, seems the KDE4 and the Fedora 8 schedule don't match perfectly (anymore; and it remains to be seen if KDE4 won't slip again, as lots of Open-Source-Projects [including Fedora] do).

Which brought me to the idea: Why are we so inflexible? Why can't we ship Fedora 8 with the old KDE, and prepare a KDE4 in a kind of overlay rawhide repo (as well as in rawhide after F8 is ready) within the Fedora project? When KDE4 ships let some people continue to maintain this overlay repo (and a update repo for it) and create a Fedora 8 KDE4 spin composed from the basic Fedora 8 Repo and the overlay repo -- that should make everyone happy and it not that much work afaics, as it's mainly rebuilding the rawhide KDE4 packages for Fedora 8, putting them in a repo somewhere and make sure packages get updated now and then until EOL of F8...

liquidat on OpenSuse Build Service

liquidat writes:

[...]
The look into the crystal ball

The OBS could become a central place for distributing software in
the FLOSS world:  every software project could create the necessary
binaries there for all bigger distributions. [...]

Well, as someone that maintains rpm packages in different repositories for some years now I tend to doubt that -- the interdependencies of FLOSS software are way to complex: lot of stuff further is moving in parallel forward quickly all the time and makes it ever more complicated.

Sure, for a pure apps that does not provide libs to be used by other software I suppose it will work in a acceptable way (well, as long as the distribution they were build against don't do major updates to library packages without providing compat packages. Which is the case in Fedora; see recent libupnp update -- soname was bumped in new version but no compat package in sight afaics).

It should even work to get one or two apps with libs from the OBS add-on repo for Fedora to have them always in their latest and greatest version.But I tend to think the more uncoordinated repos you mix the more problems users will run into.

Heck, even within Fedora we run into broken dependency's in our own repos often. Then there are the inter-repo problems into which users run now and then when they try to mix the three big 3rd party repos for Fedora. Now just imagine what happens if five uncoordinated mini-repos from the OBS with libfoo, libbar, foobar, baz and barbaz come into the mix... Sounds like major trouble to me.

Well, time will tell -- maybe I'm painting it way to black here. Or tools (RPM, yum, ...) will get better.

The imho real solution for the Fedora project would be to have special experimental repos for special things that are not yet ready for rawhide or stable. KDE4 would be a good candidate for such a repo atm; kernel-vanilla as well. Maybe it would even be the right place for kernel module packages.

Got a new Laptop - Dell Latitude D630

After thinking about buying a new laptop I actually went ahead and bought one – a Dell Latitude D630. It arrived last Friday and is my main working machine now; it replaces my older laptop (I have a normal desktop system, but that's only used by my girlfriend these days).

The hardware details, for those interested:

• Core 2 Duo 7300 – should be a bit quicker then the 7100 due to the 4 MByte Cache and did not cost that much more
  
• 2 × 1 GByte RAM – 1 GByte would have been enough for now, but it's a long-term investment (by last Laptop mainly was slow these days because it has only 512 MByte ;-)
  
• 1440 × 900 WXGA+ Display 14,1" – I need space on my desktop (but didn't want to buy a 15,4 Laptop)!
  
• 80 GB Harddrive – yes, I don't need so much hard disc space
  
• 9 Cell battery with 78 WHr – with it I should e able to suffice some time without searching for the power cord
  
• Santa Rosa platform (965GM)
  
• IPW3945 – should be quick enough for me, so I skipped the extra costs for the 4965
  
• Windows Vista – there was no way around Windows here in europe :-(
  

My first impressions after nearly one week of use from the hardware point of view:

• chassis seems to be stable (much more stable then the old one)
  
• keyboard is fine; I'm slowly getting used to the new layout; some keys like Pos1, End, Page Up/Down where placed better (near the cursor keys) on my old laptop – I miss them in that area a bit
  
• I had a 15,1 SVGA+-Display with 1400×1050 pixels in my old laptop – I really miss those 150 pixels in height :-/ And due to 15,1 vs. 14,1 everything is also a bit smaller
  
• I adjust the display angle quite often – a bit to often, but well, it's not really bad. The display is quite bright – that should make it possible to work with it outside in the garden/on the terrace; but it gets a bit darker in the edges, which one easily notices
  
• much quicker then my old machine; that's likely mainly the memory and the quicker harddisk as well as the dual core cpu
  
• fan stays off most of the time and is is mostly silent when it runs
  
• The bigger battery is also bigger in its dimensions; I knew that, but seems I forget about it as I was a bit astonished when I actually saw the notebook and it's battery (which makes the laptop a bit bigger) for the first time.

My first impressions from the Linux (Fedora 7, x86_64) point of view:

• I had expected problems when buying a brand new notebook-model with a brand new chipset; I got what I expected ;-)
  
• Fedora 7 (as well as the stock kernel 2.6.21 and 2.6.22-rc7) don't support the PATA-DVD-Controller of the ICH8M yet. I had to install via LAN. A patch is getting discussed on lkml and linux-ide; Chuck (thanks!) added it to the F7 tree already (another user requested it earlier already), so this problem soon should vanish
  
• no DRI – supported by the devel kernel/2.6.22, but the system crashes when I enable compiz. So no compiz for now, but I don't miss it much. Need to investigate further.
  
• Hibernate and Suspend-to-RAM seem to work ATM – but that needs to be reinvestigated after enabling DRI – one never knows ;-)
  
• System tracks about 1 Watt more with Linux then within Vista; Tickless, AHCI-Power Saving stuff and some other improvements that are being worked on should hopefully improve that "problem" soon.
  
• Did I mention Sound isn't working? Ohh, sorry, I keep the biggest hassle for the end of this list. Well, in fact, I made sound work roughly in between; first I found reports that sounds works fine for Feisty users. Thus I went ahead and installed the Feisty Kernel (2.6.20 based) – sounds works. Then I install the latest FC-6 kernel (2.6.20 based) and the Ubuntu-devel kernel (2.6.22) as well as the rawhide kernel (2.6.22 based) – none of those where able to get audio output. Found two helpful mailing list threads on LKML and alsa-devel. Recompiled the latest F7-kernel (2.6.21) from Fedora-CVS with alsa and snd-hda-intel compiled *into* the kernel – sound works. But it does not work again after hibernate and produces a warning (hda_intel: azx_get_response timeout, switching to polling mode...;hda_intel: azx_get_response timeout, switching to single_cmd mode... ) during load that it only works in a kind of debug-mode.
  

Last words for now: There is still much fun ahead, but I can live with the problems for now (by ignoring them manly) and use the new Laptop as main machine now.

Evolution (or) The growth of Fedora

I started to contribute to Fedora(.us) years ago; Fedora has grown a lot since then -- especially now with the merge we are lot more people that have to interact with each other.

What really disappoints me about that: the tone on the mailing lists afaics got and constantly gets worse and unfriendlier (¹). Sure, there were flamewars in the past (and I were part of them as well), but people showed more respect to each other.

I'm not sure if I would start contributing to Fedora today if I would be searching for a project to contribute to.

(¹) -- no, there is not special mail or flamewar that got me to write this blog entry. Just a general impression.

I need a new Laptop

I need a new Laptop. I was thinking about that for months already, but the wish to actually buy one gets bigger and bigger...

Why you ask? Well, the machine itself was fast enough for me when I bought it three years ago. It likely would still be fast enough if I would run CentOS 4 or something similar on it, but with recent Fedora releases the machines feels to slow. It has just 512 MByte of RAM and afaics these days that's not enough to run Gnome, Gnome-terminal, Thunderbird, Firefox and Pidgin in parallel without swapping. In fact there is enough free RAM when I start the machine and those apps freshly, but after some days of use (software suspending it in between) with running OpenOffice.org in between the RAM is filled; so the machine starts swapping and a "yum update" makes everything nearly unusable slow.

Does anybody remember the good old days when Linux needed less hardware resources? Seems that was long long ago...

Why many comments in config files are bad

Just yum-updated my local home-server from FC6 to F7 (my main machines at home and work used rawhide for weeks already). After such upgrades I always look over the .rpmnew files that got created and merge the changes back from them into the proper config files with meld and delete the rpmnewfiles.

That's no big deal; with a script of of mine I normally would be able to do it in one or two minutes for that machine. I would, if there wasn't dovecot.conf and squid.conf. They have lots of comments in them that explain nearly each of the settings. That just sucks because I now have to look over all of them :-((

Especially dovecot.conf is bad:

[thl@truhe etc]$ diff -u dovecot.conf dovecot.conf.rpmnew   | grep '^+' | wc -l
127
[thl@truhe etc]$ diff -u dovecot.conf dovecot.conf.rpmnew   | grep '^+' | grep '#' | wc -l
119
[thl@truhe etc]$

Most of those eight non-comment lines are probably settings I actually did.

***thl is now known as knurd

I never was really happy with my TLA as nickname -- but well, thl (from Thorsten Heiner Leemhuis oder Thorsten Leemhuis) was the thing that sprung to my mind when I needed a nickname for IRC. I actually tried to think about something else quite a bit of time back then, but I didn't find something better that was free, so I just started using thl.

But recently I thought again to look out for something else -- IRC once again was the trigger, as thl was owned by someone else on OFTC already (and there was actually somebody else on freenode that tried to use thl these days). So I searched for something else.

I considered "steinlaus" (Petrophaga lorioti), but that joke is hard to understand for people outside of Germany (I'm actually wondering how many Germans will understand it these days), so I took something more international.

Evil?

'Our informal corporate motto is "Don't be evil."' -- that's written on the top of Google's Code of Conduct. Well, they managed that in the beginning imho when they were still a search engine and not much more. But they are becoming evil more and more in my eyes -- they were imho more then big enough already to be trusted and had much to much control over the Web already. Now they are buying DoubleClick. That really makes me anxious; where will that end? I'm starting to fear a Google controlled Internet where I can't visit a website without having "Big Brother Google" watching me. Just imagine what might happen if Google buys Microsoft (or vice versa); just a cooperation would be bad enough probably. <Prediction of the day>But I suppose Google will buy Canonical first</prediction of the day> ;-)

Google until now was one of the rare sides that were allowed to set cookies on my machine for more than one session as I had some settings saved that influenced what search results I get and how they are formated. That will change now. I'll probably look out for another blog hosting, too, and will try to get rid of gmail (which I'm using for jabber only anyway).

exclude=*-devel.i386 [Update]

I'm normally trying to use the default software and settings my linux distribution provides as much as possible, as everything that one changes in my experience fires back sooner or later and requires manual adjustments (read: time) to make it work again; that makes slightly advantages often obsolete if looked back at the situation in retrospective later.

But well, today I made a big exception again. I added "exclude=*-devel.i386" to my /etc/yum.conf; getting all those *-devel.i386 packages by default really annoyed me, as I always forgot to add the ".x86_64" when running "yum install foo-devel". The download of those i386 packages consumes bandwidth and takes time; installing and updating the packages later takes even more time. And even worse: you end with lots of unwanted and unneeded userspace apps and libs for i386 as well, as the devel packages normally depend on them; those packages are not cached by rpmdev-rmdevelrpms either, so I end up with lots of cruft on my hardisk.

All this IMHO for a small benefit: to be able to develop i386 packages on a x86_64 host. How big is the number of users doing that? And does it really work in practice? A lot of configure scripts and apps (including rpm) in my experience seem to get confused if you try to compile something for i386 on a x86_64 host (even when remembering to use setarch). So it's really the best and the safest to use a chroot (e.g. mock) for this purposes as far as I can see.

So in other words: is installing *-devel.i386 packages on x86_64 really a sane default for Fedora? I really doubt it. It creates more trouble for the growing number of x86_64 users and makes it a slightly bit easier for only a small group of users. I'm really wondering if it would be better to have those *-devel.i386 packages in a separate Fedora-add-on repository that people just can enable if they really want them.

[Update] Seems I need to clarify something, as I got two comments on this blog now, and it seems both users got tracked into the wrong direction. Rahul for example wrote:

>> All this IMHO for a small benefit: to be able to
>> develop i386 packages on a x86_64 host
> This is not the primary benefit. The primary reason
> is that there is a number of third party software that
> are still 32 bit and multi lib by default helps them
> work better without fiddling.

You got me wrong here. I'm all for having .i386 libs and maybe even some i386 apps (like firefox) in the repo, because (as your write) they are needed for third party software (for example). I was taking about the *-devel.i386 packages only.

I can still write spec files

My Fedora involvement in these days seems to me more in housekeeping/organization areas than packaging. But it seems I haven't lost all of my packaging skills in the past months and got two new Packages into Fedora over the weekend: rss2email and python-html2text -- the latter is needed by the former. Patrice Dumas, thanks for the quick review.

BTW, that's all your fault Max -- you shamelessly placed the idea of running an rssfeed-to-email daemon or cron job in my head with your blog post months ago. But rss2email suited my needs better than newspipe, which seems to be your preferred choice.

You're wondering what rss2email actually does? Well, it reads a rss or atom feed and sends all new (or, if you like, updated) entries to you by mail (html or plain text -- whatever you prefer). You can even use different e-mail addresses per feed and point the output directly to the proper IMAP folder that way.

Why all that? Easy: with rss2email I don't have to synchronize a rss-reader's settings-directory between different computers, I don't have to run and learn and additional application and I don't have to tell any web-service which feeds I like.

My usual way of browsing the web changed dramatically due to rss2email already -- I spend even more time in Thunderbird now (is that possible? I'm there already a lot to read all those mailing lists...) and less in Firefox.

BTW, is anyone still interested in having websec in Fedora? I'm using it on one of my servers for ages, but it seems I accidentally never packaged it up for Fedora :-(

Leaving FESCo

Just FYI, I'm not in FESCo any longer. Now with the Core and Extras merge it became to conflicting with my day job (we all need to earn money somehow for living), so I left (after being in FESCo for about 1 2/3 years) before the problems became to pressing. Yes, stepping down as chair some weeks ago was a preparation for this step; but no, I probably would have stepped down as chair then, too, even if I wouldn't have to leave FESCo now.

And be warned: I'll stay active in Fedora land. I'll in the long term hopefully do what I'd really like to see more in Fedora land: "Simply work on stuff, solve problems, write proposals, write policies or help with getting shit ^w stuff done that is needed or improves Fedora, even if you are not in FESCo or a similar committee". IMHO way to many people yell about (organizational) problems in Fedora land, without actually really helping to make those problems go away.

I wish FESCo all the best with its work and I'm sure it'll do a good job -- but guys, please make sure the community at least gets as much involved as in the past and make sure you try to get them even more involved. I think that's hardly needed, especially now with the merge when Extras-maintainers from the Fedora Community get in touch with Red Hat employees more often -- that's afaics sometimes like people from two different worlds meeting for the first time without actually understanding how the other world works and is organized. That can result in a lot of trouble...

My plans for the short term: finish some stuff like co-maintainership (I prepared a updated proposal, just need to look over it again) and the mailing list reorganization (that's still blocked; I'm waiting for decisions how we want to realize it technically -- e.g. a new server, a alias hostname that points to the current server, or just continue with the current setup...). I plan to get a lot more involved in EPEL (again) -- I had to put that down on my agenda a bit for the past months, as other FESCo jobs were more important.

For Fedora 8 I hope to revisit and rework the kernel module packaging standard -- we sat down and talked about it with some people on FUDCon. I hope we actually can have a enhanced standard for kernel modules in the future that is a mix of the current one and a dkms like solution in addition for those that want it (that might use dkms -- still unsure how to actually do that, but well, we'll see). That should fit most people: "normal" users then can get pre-compiled packages via yum while other that really want to (for whatever reasons) can use a dkms(-like) automatic build solution. Ohh, and I have two other Fedora-related, not-yet-publicly-announced pet projects that I plan to work on, too.

Ohh, and yes, besides that I hope to actually find time again to read a book or two :-)

Parallel installable Firefox 2.0 RPMS for Fedora Core 6

As some of you know I really disliked that Fedora Core 6 shipped (and sticks) to Firefox 1.5. But I understand the reasons why Fedora does that, and why the firefox2 package didn't make it into Extras. But the SRPM from Gawain Lynch was quite nice and he put a lot of effort into it. So I thought: why not get into the repo business for a while and set up a small repo with it? And that's what I did. Use

rpm -ivh http://www.leemhuis.info/files/repo/fc6-thl-ff2/6/i386/thl-ff2-for-fc6-release-1-1.fc6.thl.ff2.noarch.rpm

or something similar to install the repo file and the key which was used to sign the packages. Then run

yum install firefox2

to get Firefox 2.0 installed. The package installs in parallel to the Firefox 1.5 package from Fedora Core, so all those apps from Core and Extras that were build against 1.5 should still work. Note that some of your plugins might not work with Firefox 2.0 and that it will use the same profile directory as Firefox 1.5 (that's different from Gawain's packages -- he started Firefox 2.0 with the profile manager b default, *if* you start it from the menu).

To start Firefox 2.0 simply use the launcher from the menu or start it with "firefox2" from the command line. The package sets a alias "firefox -> firefox2" via a profile.d file, so after the next log in you should be able to just start if by using "firefox".

Special feature: I put a special package into the repo that should obsolete and thus delete the firefox2 package when you update to the development tree or to Fedora 7 later when it comes out -- just make sure the repo stays enabled.

There is one bug ^w feature I don't know how to workaround -- Firefox 1.5 starts up if you click on a URL in a Gnome app in case Firefox 2.0 is not yet running and Firefox 1.5 is still configured as your default browser. That happen to me multiple times, but it did not do any harm to my profile that I got aware of -- but it could, so you have been warned!

Home from FUDCon Boston 2007

Made it home from FUDCon fine. This time the flight worked well so I was at home on Monday morning local time. Haven't had that much luck earlier on my way to Boston -- we had a four hours delay in Paris CDG because they had to fix one of the engines :-( . We were in the plane all the time, so including the flight I got stuck in it for about 12 hours...

FUDCon was great, so it was worth the flight over the ocean -- especially meeting all those people from IRC real life was great, but even three days were not enough time to talk to each and everyone I wold have like to talk to. For the next conference I'll try to prepare a shirt or a cap that has my nick printed on it in big letters -- that should hopefully help that people find me on the first day :-) .

The Barcamp format was nice and worked quite well. The time was to short to visit all the session I was interested in -- I for example could not attend to the key signing party or the Live-CDs stuff. Got quite a bit of work done and stuff discussed during FUDCon and the Hackfest on Saturday/Sunday. Between discussion EPEL, mailing lists, kernel modules, a FESCo meeting and other stuff (side note: we forget to talk where we want to put the Extras wiki-pages after the merge) I reviewed some packages. I chose to work on xorg-x11 stuff -- don't know if that was a wise. I stopped reviewing xorg-x11-drv-* packages soon, as I found some issues in the first two packages that will likely be in others as well -- so it's probably wise to sort them out first before continuing.

Name for a FESCo Successor

FESCo in its yesterday out-of-order meeting agreed to follow the proposal I posted on fedora-advisory-board to merge the Core Cabal and FESCo into a new committee that handles the day to day work around the stuff that was formally known as Fedora Core and Fedora Extras. In other words: we integrate Jesse (aka f13) and Bill (aka notting) into FESCo (Jeremy is already part of FESCo), merge the responsibilities of both groups (and thus give it lot more to do). The Fedora Board will probably discuss the proposal in todays meeting, too.

But one issue is still totally undecided and needs to be solved soon: What do we call that FESCo and Core Cabal successor? The "E" in FESCo until now stood for Extras, but soon Extras will vanish due to the merge. So hat do we want to call it? Suggestions that came up:

• FTC -- Fedora Technical Committee


• FTT -- Fedora Technical Team


• FET -- Fedora Engineering Team


• FEDCo -- Fedora Distribution Committee


• FESCo -- Fedora Steering Committee


• 42

None of the above name suggestions did receive a "yes, that's a really great idea, I like it, all the people I asked love it, thus go for it" from the people involved in the discussions. Thus we'd like to ask the community for suggestions and its option: "Which of the above names do you like most or do you have something better in mind that sounds good, is not to easily confused with other stuff from this world and roughly describes what the committee does?"

Please participate in the discussion on fedora-devel. Thanks!

Ohh, some backgrounds for the proposed names:

• FTC -- name clash with Federal Trade Commission. A bit bad, but seems some people don't care much about that.
  39 meanings in total on acronym finder


• FTT -- "Failure to thrive (FTT) refers to a baby or child that is not
  developing as well as desired." 12 meanings in total on acronym finder


• FTT -- Field-Effect Transistor 24 meanings in total on acronym finder


• FEDSCo "Federal Employees Distributing Company (Co-Op)" 2 meanings on acronym finder


• FESCO-- Fedora Steering Committee is to easily confused with the Board, thus probably a no-go


• 42 -- The Answer to Life, the Universe, and Everything

P.S.: For those that missed it, I'm not FESCo's chairmen any more (but still a FESCo member) since last Thursday -- After doing the job for one year I felt that it's time for me to hand it over to someone else with fresh blood and new ideas. Brian Pepple is FESCo's interims chair now and I'm sure he'll do a great job. Please help him as good as you can -- and always keep in mind: You don't have to be in FESCo or any other committee to to help improving Fedora!

thl's irssi notification script [UPDATED]

A while ago Luke Macken wrote an irssi notification script and blogged about it. I really liked the idea having pop-ups (using libnotify) on all of my desktops when somebody mentions my name in on of the channels. But well, the script had one big problem for me: It requires irssi to run on the local machine.

But I run irssi within screen on another machine in another network – I just ssh into that machine normally and resume the irssi-session with "screen -R". Thus I could not use lmacken's script :-(

I looked a bit more into that some time ago and came up with another solution: fnotify. Download it and put it as fnotify.pl in .irssi/scripts/ and load it in irssi with

/load perl
/script load fnotify

Is somebody chats to you directly (query) or mentions your nick somewhere in one of the channels it will put something like

#fedora-devel foo> ping thl

into ~/.irssi/fnotify . I can read that file from the client via ssh now and fire up notify-send locally. I use this startup script do realize that:

# yes, we need a way to flush the file on disconnect; i don't know one
# yes, that's flush is not atomic (but good enough for me)
ssh remote.system.somewhere "tail -n 10 .irssi/fnotify ; : > .irssi/fnotify ; tail -f .irssi/fnotify " | sed -u 's/[<@&]//g' | while read heading message  do  notify-send -i gtk-dialog-info -t 300000 -- "${heading}" "${message}"; done # the sed -u 's/[<@&]//g' is needed as those characters might confuse  notify-send (FIXME: is that a bug or a feature?)

This results is nice pop-ups in the bottom right corner of my desktop:

Site note: Yes, there are probably 1000 other ways to realize something like that. The above stuff is far from perfect, but it suits my needs.

Mailing list reorganization, FESCo Chair

I looked at the mailing list mess that evolved in the Fedora Project over the past years and -- after the Board asked me to drive deeper into the issue -- worked out a proposal for a mailing list reorganization. I posted it to fedora-devel for public discussion. Comments -- on the list please -- appreciated.

Ohh, and while blogging for the second time in my life it's probably a good time to announce something else: I'll step down as FESCo chair tomorrow. I did that job for one year now and I think it's time for a new chairmen with fresh blood and new ideas. I'll stay in FESCo for now.

I have a blog

mether talked me into it. Let's hope it it's not yet another close-to-never-updated blog -- I'm quite busy with all the Fedora stuff, real life and my work already.

It was just a quick click-through-and-yes-I-accept-all-your-term-and-guidelines setup and I probably have to look closer now how to actually use and fill it :-)