knurd

Why I'm not posting much on Google+ – or – My big problem with Google+

2011-07-16T20:16:00.010+01:00

The "tldr"-version: Google+ has lots of nice things, but in its current state it does not look like a solution that could replace twitter (and identi.ca) for me at all. In fact I'd need something like tags or topic-streams (that people could select when adding me to their circles) for my messages before I'd feel more comfortable to write public posts on G+ more that occasional.

The detailed version: It seems the people that added me to their circles mainly know me from one of four aspects of my life:

my work for heise.de and c't
English translations of that work published on "The H"
my contributions to Fedora
this strange thing called real-life (good 3D effects!)

Sending out just one public information stream to those people afaics would only make very few of them happy; I'd feel like spamming them with crap they are clearly not interested in.

Among the reasons for that view are simple language problems: I was born and live in Germany and speak German most of the time – but I know lots of people from the US, the UK and other countries and most of them do not know more that five German words. Many of them added me to their circles nevertheless; I'm also in a lot of circles where I don't know the people at all; hence I don't know their interest in me or their language preferences. I could avoid annoying them with German posts by writing in English all the time when doing public posts – but that's a crappy workaround (one I suppose might annoy some of my German friends over time) and not a real solution for the underlying problem.

Yes, you are of course right, that is a problem on Twitter as well. But I solved that easily by using multiple accounts right from the start, which is not easy with G+. Using three accounts also mostly circumvents the problem I indicated in the beginning: Different people are interested in different things and only they can decide what they are interested in.

Here is how I do it with twitter:

My main account is @thleemhuis. Just like everybody else I use it to tweet things from my real life (including work). Most of the tweets are German, some are English; almost all of the followers are from Germany or understand German afaics
I use @kernellogauthor to tweet about things in the Linux kernel area I stumble upon; it is a kind of bonus and an additional communication channel for readers of my Kernel-Log (DE, EN). Almost all tweets are English (I assume most Germans that read the Kernel Log know English well enough) and kernel related. It has 266 subscribers (some more on identi.ca) and only a handful of them follow @thleemhuis as well
Many English speaking people also know me from all the contributions I did to Fedora in the past few years (I'm mostly inactive in that area right now); I follow them via @knurd666 and provide them with a English tweet there now and then; only a handful of them follow @thleemhuis or @kernellogauthor

IOW: I have three kinds of followers (something like 500 on twitter in total and 200 more on identi.ca) that seems to be interested in stuff I do, but there are only very few people (I assume less than 5) that follow all three accounts; and yes, I occasionally mention the different accounts on each other, so it's not a secret I use multiple accounts...

I'd really like to feed them with information from my life or work via Google+, too, but I can not see how to do that efficiently, because right now I have to know that people are interested in; on twitter those that follow me can decide on their own. That's why G+ seems so alien and wrong to me. Something like predefined tags, streams or "outgoing circles" people could select when they add me could help. But maybe that's to complicated; and maybe my situation is special and shows a problem other do not encounter.

P.S.: Yes, maybe I'm thinking to much as someone that wants to maximize the group of people he can reach -- maybe that has something to do with my day ob ;-)

New Intel graphics drivers released

2010-09-30T19:42:00.002+01:00

The Fedora developers among you will be aware: there is a Fedora Test Day with a focus on the Intel graphics card driver today (Thursday the 30th). The X.org driver that is being tested afaics is xorg-x11-drv-intel (also known as xf86-video-intel) version 2.12.0, release 6.fc14 -- the latest F14 build as of today.

Oh, and something else happened today: After three months of development Carl Worth released a xf86-video-intel version 2.13.0. Quoting the release announcement: "[...] With the many bug fixes in this release, we encourage everyone using 2.12 to upgrade to 2.13. [...]"

So people that participate in the testing today might run into bugs that that are fixed in 2.13 or in its pre-release already. But what is even worse from my point of view: With the new and recently ratified Fedora updates policy it seems unlikely to me that Fedora 14 will update to 2.13 ever (note: unlikely still means it's possible!).

My head simply fails to understand why that is the right thing to do in this and similar cases. Even worse: lot's of other distributions have similar policies, so it's take months or years till the fixes the Intel developers worked out in the past three months make their way to regular end users.

Visiting LinuxTag and Red Hat Summit 2010

2010-06-05T14:08:00.003+01:00

Blog entry for my fellow readers that visit LinuxTag (next week) or Red Hat Summit/JBoss World 2010 (starting in two and a half weeks from now):

I'm in Berlin for LinuxTag next Saturday (on my own efforts).
I'm in Boston for the whole Summit to report about it for my employer.

So if you want to meet me in real life simply look out for me or sent a mail to arrange a meeting.

BTW, looks like I might stay in Boston till Sunday afternoon, so I will have some free time once the Summit is over and all work done. Please let me know if you have any good suggestion how to best spent that time it in Boston! tia!

What questions would you like to ask the Candidates for the Fedora Board, FESCo, and FAMSCO?

2009-11-11T22:28:00.001+01:00

As you may have heard already, several seats of the Fedora Board, FESCo, and FAMSCO are up for election soon(¹). Right now we are in the nomination period, which will be followed by a "Candidate Questionnaire." That means we'll give candidates a list of questions to answer by private mail within one week after the nomination period closed; the results will be publish soon after that to make sure they are available to the public before the Town Hall meetings on IRC happen.

Candidates may choose to answer (or not) those questions as they see fit. Voters can use the answers to get an impression of what the candidate think or plan to do while serving for the committees they are nominated for. That should help to get a interesting discussion running during the IRC Town Hall meetings; furthermore, those people that can't or don't want to participate in the IRC meetings can use the answers to make a more informed vote.

Hence we need to prepare a few good questions that we can send to the candidates once the nomination period ends. And that's where I need *your help* now:

If you have one or more questions you'd like to send to the candidates simply go and add them to:

https://fedoraproject.org/wiki/Elections/F13_Questionnaire

It just takes a minute or two, so best to do it right now -- otherwise you might get distracted and forget about it. ;-)

I'll take care of the remaining work to review, sort, and clean up the questions(²); after that I'll send them to the candidates soon after the nomination period ended. Hence, I need your question suggestions by around the 15th November 17:00 UTC latest to get a chance to prepare everything in time.

So please go to the wiki now and add at least one hard question! The answers will help Fedora contributors to chose whom to vote for! Thanks in advance for your help .

CU
knurd

(¹) If you haven't read about it yet see
https://fedoraproject.org/wiki/Elections for details.

(²) If you want to get involved or review the questions before I send them please drop me a line and I'll try to get that arranged; maybe we can arrange a quick, informal IRC meeting on Sunday evening if there is interest

P.S.: This blog post is mainly meant to get spread via planet.fedoraproject.org ;-)

New RPM Fusion packages: nvidia drivers for F12, staging drivers for F11 and F12

2009-11-01T18:10:00.005+01:00

Just FYI:

the nvidia graphics drivers finally showed up again in the RPM Fusion repository for rawhide (the current public rawhide to be precise, e.g. what becomes Fedora 12 soon)
Most drivers from the linux-staging tree are disabled in the kernels that Fedora ships (among them a few wifi drivers like rtl8187se) . That's a good thing, as they are often of highly questionable quality (¹, ²). But some people nevertheless what them, as they own hardware that needs them(³). Those people from now on can get them easily for Fedora 11 and Rawhide/Fedora 12 by installing kmod-staging from RPM Fusion.
Please note that:
- the drivers for Fedora 11 are in rpmfusion-free-updates-testing currently and build for the kernel that is in Fedora's updates-testing repo; thus to use them you need to run something like "yum --enablerepo='*testing' install kmod-staging" and reboot into the kernel that is installed to use them
- you need to install kmod-staging-PAE if you use a PAE kernel on your x86-32 machine
- there are no akmod-staging package at this time
- the package doesn't contain all the drivers from the staging tree; in case you miss one just file a bug in bugzilla.rpmfusion.org and tell the packager to enable it

Also note that it might take some hours till the mirror yum chooses for you offers the packages, as they were uploaded to the master repo just a few minutes before this blog posting got published.

We thank you for your attention and we wish you a pleasant flight.

(¹) that's the long story short

(²) don't expect the drivers to work well; NetworkManager for example will in have problems with some of the WiFi drivers in staging-kmod. In most cases that will be the fault of the driver and not NetworkManager, thus filing NetworkManager bugs that occur with staging drivers is likely a waste of your time.

(³) friends don't let friends buy hardware which need's staging (or even worse: proprietary) drivers on Linux

Presentations from LinuxTag / Fudcon Berlin 2009 available; Tomorrow: Hackfests

2009-06-27T16:15:00.006+01:00

My presentations on LinuxTag and Fudcon Berlin 2009 went mostly well. Biggest problem when looking back now: Seems it was more then enough stuff to talk for 90 or 100 minutes, but I only had a hour in total :-/.

Want to look at the slides? Follow these links:

German, LinuxTag: "Überblick über aktuelle Entwicklungen des Linux-Kernels"
English, FUDCon: "What is RPM Fusion and why it is really important for Fedora (and how you can help to make it better!)"

Another problem: There are so many people here at FUDCon and I more and more get the impression that the list with people I "want to meet, shake hands with and talk to for a while, to get a better connection between faces, email addresses, nicks, and (those sometimes overrated) real names" isn't getting shorter as fast as it should to meet everyone in the remaining time. Seems I need to speed up somehow...

It's the same for you? If yes and if you ever wanted to talk to the crazy troublemaker that did or does a lot of work for Fedora, EPEL and Livna/RPM Fusion then just grab me and start to talk to me when you see me walking by or sitting somewhere. The photo on the right shows how I look like, just imagine some mostly inconspicuous glasses on the nose. Ohh, and the hair is a bit shorter right now (I guess nature will do it's best to fix that over time).

BTW, again some informations for the FUDConners: I plan a small "RPM Fusion" hackfest for tomorrow *if* people are interested in one. There is no real plan what to do exactly besides the general idea: Do some work to improve RPM Fusion, and work out the details on the fly. Want to join? Then just watch the wiki and the usual places at FUDCon for details!

thl and knurd @ LinuxTag 2009 and Fudcon Berlin 2009

2009-06-25T09:28:00.003+01:00

I just arrived in Berlin at the fairgrounds where LinuxTag 2009 and Fudcon 2009 are held. I'm staying till Sunday evening, but like so often I have to split my attention and time as I'm partly here for my employer and partly for fun/Fedora (just like last year at Red Hat Summit Boston).

As usual that's creating some interesting problems where I ideally wound like to be at two places at the same time :-/

Friday will get most complicated. I for example can't visit the Fudcon-Keynote from Jan Wildeboer, as I'm giving a "Kernel-Log" talk as part of the "Kernel Track" of LinuxTag at just the same time. That wasn't planed like that, but seems Jonathan Corbet canceled his trip and thus can't give his well know and always interesting "The Kernel report"; I three or four weeks ago was asked to fill the position and accepted (presentation is basically finished; luckily Linus closed the merge window a few hours ago). Note that I'm giving that talk in German, not in English, as Jonathan would have done.

I also have time and space problems for the barcamp pitching session at 5 pm local time: Together with Nils Magnus from LinuxTag e.V. / Linux New Media I'm moderating the Kernel Kwestioning at that time, where the audience can ask some kernel developers on stage a few questions.

And that are only the hard scheduled events which I really can't miss. I also want (have?) to hear at least two of the other talks (Union Mounts and Ksplice) from the Kernel track on LinuxTag, so I likely walk back and forth between Kernel track and Fudcon a lot on Friday. But I hope to join the Fudcon crowd early for Fudpub in the evening -- I mean, I likely *have to*, as the Fudpub otherwise might run out of pizza and drinks before I arrive (you know how Fedorians are...).

Remains to be seen how long I can stay at Fudpub, as I still have to prepare my presentation on RPM Fusion which I'm giving at 2 pm on Saturday on Fudcon. I'll give that talk in English -- I'm not completely sure yet if that works out, but I guess I have to give it a try sooner or later. So remember to bring eggs and tomatoes to throw them on the stage if my English is way to worse ;-)

So, see you on LinuxTag and Fudcon! This is how I look like. But note, I had to buy a add-on a few months ago: now with glasses (often, not always) ;-)

P.S.: Headline-Explanation: those that contribute to Fedora for a long while will remember that I used to be known as "thl" in the Fedora -world initially. But I already was and still am "thl" at work and a few years ago decided it might be better to use a different nick in the Fedora world -- after a bit of thinking I chose "knurd". That way it's at least a bit harder (especially on IRC!) to get the connection "Ohh, the thl that writes the kernel-log for c't/heise.de/the-h is also the one that contributes to Fedora", which I think is a good thing. But it's not really a secret anyway, as rare blog entry like this make it obvious. But trying to keep it a real secret would not work anyway, as the name "Thorsten Leemhuis" quite rare, so it's not that hard to find out anyway.

rpmfusion-{,non}free-remix-kickstarts -- or -- knurdix

2009-06-17T21:12:00.002+01:00

There was always the idea to build a linux distribution with RPM Fusion packages within the RPM Fusion project -- e.g. live media and installer spins ^w remixes that are basically a distribution like Fedora under a different name and with some packages from RPM Fusion. There is/was Omega 10, which until now never became the official spin for one reason or another. Recently some other work was done to get one step closer to create a official "Fedora Remix" from RPM Fusion sooner or later:

RPM Fusion since a few weeks contains the packages rpmfusion-free-remix-kickstarts and rpmfusion-nonfree-remix-kickstarts in the repositories for Fedora 11 and Rawhide. They just like the Fedora package spin-kickstarts contain kickstart files that can be used to create your own linux distribution live-image using the Fedora Package Collection and Fedora's livecd-tools. A installer image is still on the todo list and might need some fixes in anaconda and the rpmfusion-{,non}free-release packages afaics.

The kickstart files in the two RPM Fusion packages are pretty basic: They simply include the kickstart files from Fedora, remove the Fedora branding, add the generic branding and add the repo definitions for RPM Fusion. That's basically it, because the comps groups from RPM Fusion extend the groups that Fedora defines and thus you automatically get all the packages you want depending on what's defined in the RPM Fusion comps files -- that is for example gstreamer-plugins-ugly and gstreamer-ffmpeg in the case of the Gnome groups and xine-lib-extras-freeworld for the KDE remix.

As a proffce of concept I created four remixes (Desktop and KDE for i586 and x86_64) for testing purposes and uploaded them to to the web for public testing. But warning: They are basically untested and just meant to show what's possible. Ohh, and due to the lack of a better name I just called them "knurdix" ;-) We'll need to find a different name for the official RPM Fusion images (which might be simply "RPM Fusion" or something else that sounds better).

Hopefully those packages and the kickstart files in it can help to get some people interested in the idea of a RPM Fusion remix -- maybe enough people to build and maintain official "Fedora remixes" with packages from RPM Fusion" in the long term. If you are interested to help just join the rpmfusion-developers list and share your ideas. Or get in contact with me directly, but the mailing list is the preferred way.

Make things easy

2009-06-12T14:35:00.004+01:00

Alan Cox recently on LKML:

[...] If nobody else is interested then you can do the reviewing/acking
because clearly nobody else cares if you make a mistake. And if they do
then they'll be motivated to add resources to assist you ;) [...]

Sometimes I wonder if we should apply a similar concept in Fedora/RPM Fusion land more often.

Leave kmods in RPM Fusion, but make sure they work well

2009-06-01T13:23:00.004+01:00

In short: Fedora IMHO should not ship separate packages with kernel modules (so called "kmod packages") as part of the package collection. But Fedora afaics needs to make sure things like kmods work well, even if they are not used in the Fedora package collection.

Verbose variant: Recently there was another(¹) discussion on fedora-devel about allowing packages with kernel-modules in the Fedora package collection. I'm one of the drivers of the original "kmod" packaging standard for kernel-modules in Fedora and take care of it in RPM Fusion these days (which uses a modified version). So obviously I have a strong interest in the area.

Nevertheless I stayed away from the discussion and I guess many would have been surprised if I'd shared my option: It doesn't make much (if any) sense to package kernel modules as separate packages in Fedora. The main reason for this option: Everything lands in one package repository anyway(²), so it's much easier for everyone to get the bits into Fedora's proper kernel package directly. And I agree with the suggested approach way to make that happen as well: get the modules upstream, e.g. in linus' "vanilla" kernel (and not the staging area), then Fedora will get them automatically.

But: Some widely used kernel-modules will never make it upstream. For others (like some of those in linux-staging) it's a long way that takes a lot of time, because the code of those modules often is in a bad shape; until that's fixed and an improved variant merged a lot of people are nevertheless willing to use the ugly code we have today, because for them it's often better than throwing hardware away.

Fedora ignores those cases -- afaics because they are "not the right thing to do" or maybe "politically incorrect". One can argue if that is right or wrong for Fedora, but that's a topic for a different blog entry. The real point I'm up to: users still want to get the modules they need. Thus they will either work around it locally, use/contribute to repositories like RPM Fusion, or switch to a distribution that offers them what they want.

The latter is something that is neither in the interest of Fedora or Red Hat. Hence I'd say it would be good if Fedora would make sure that things like kmods work well, *even if they are not used within Fedora* -- just like Red Hat makes sure that Oracle DBs work fine on RHEL (which uses kmods in RHEL5, so RHEL would benefit from proper kmod support and testing in Fedora as well). But that's not the case right now(³), which makes Fedora sometimes annoying or hard to use.

(¹) There have been a lot similar discussion around kmods over the past years.

(²) My option might be different if we had something like a "extras"/"unsupported" add-on repositories within Fedora, as that would make it obvious "hey, these modules are not part of the upstream kernel/might not work so well/might suddenly go away again".

(³) Note that the main problem afaics is on the Fedora side, so it's not really fixable for RPM Fusion. I outlined the details in a posting to fedora-devel last August, but nothing happened. There are ways to work around the problem using a yum-plugin. But that is not a real fix, because the problem is not specific to kmods -- it happens with a lot of other packages as well in cases where a RPM Fusion package depends on a specific version of a package that is part of Fedora (xine-lib and xine-lib-extras-freeworld for example). And yes, sorry, I don't have the skills to fix the problem myself. But I don't think I have to -- Fedora afaics is meant to be a community where people with different skills work on different areas of the project to make the whole thing better.

yum install thunderbird-enigmail

2009-05-23T13:25:00.000+01:00

The RPM Fusion Free package repositories now(¹) contain the popular thunderbird extension enigmail for F9, F10, F11/rawhide and EL-5. To install it just configure RPM Fusion and run:

# yum install thunderbird-enigmail

Big "thanks!" goes to Remi Collet for packaging it up and submitting it for Review in RPM Fusion.

The package is especially helpful for users of rawhide/Fedora 11, as the enigmail homepage doesn't offer prebuild extensions for the thunderbird beta that Fedora 11 contains. It's also nice for users of Fedora for x86-64, as the add-ons on the enigmail homepage sometimes were outdated.

Additional note: Normally RPM Fusion doesn't take any packages that are suitable for Fedora to avoid getting in Fedora's way. But earlier attempts to get thunderbird-enigmail into Fedora have failed, so we took it; hopefully the package can be moved to Fedora sooner rather than later!

(¹) might take up to something like 32 hours till your yum sees it due to mirror lag and metadata caching

Fedora 11, kernel-PAE, and what it means for your x86-32 system

2009-05-23T12:39:00.004+01:00

There is one small change in Fedora 11 that I guess will confuse Fedora and RPM Fusion users with x86-32 (aka i386/ix86) systems quite a lot, but afaics did not get enough attention yet:

By default, the PAE kernel will be used on 32-bit hardware, where appropriate(¹).

"Appropriate" is not really explained -- maybe because it's a bit hard to sum up without going into the boring details. But basically it boils down to: The kernel with PAE support will be installed by Fedora 11 for x86-32 on the majority of x86-compatible systems that have been manufactured in the past three or four years(¹). So likely on your system as well if you are running a x86-32 distro on a modern system.

The important part: the package containing the kernel with PAE support is not called "kernel" -- it's called "kernel-PAE" instead. And that's not the only package where "-PAE" is used as suffix. That has major certain consequences on systems where Fedora 11 installs kernel-PAE:

when you build kernel modules with akmods, dkms, or manually, then you from now on need to install kernel-PAE-devel instead of kernel-devel
similar for kernel-modules: instead of "yum install kmod-nvidia" your now need to type "yum install kmod-nvidia-PAE". Yum otherwise will try to install the matching kernel without PAE support for you, which (in short without the boring details) is something you most of the time don't want(²).

In other words: the change in Fedora 11 makes lots of howtos, FAQs, articles on the net and in computer magazines confusing, wrong, misleading or harmful (depending on view and specific howto/FAQ/article), because most of those docs don't consider the above fact (yet).

And that's not Fedora's fault -- PAE kernels are around for a long time in Fedora already. But they were used only on a minority of systems. Most (not all!) of those that have written today's howtos, FAQs or articles were likely either not aware of it or chose to ignored it to keep things simple.

That's backfiring now. So go and spread the news on mailing lists, forums and other places where it might be of interest. Feel free to copy-n-paste this whole text or simply point to this blog entry. Thanks in advance!

(¹) E.g. since processors with NX bit became mainstream; NX stands for NoeXecute and is also called Enhanced Virus Protection by AMD and xD-Bit by Intel

(²) not sure, but maybe the yum-plugin "yum-fedorakmod" could have made yum to the right thing and install the proper kmod for the PAE kernel. I never tried and it doesn't matter much as the plugin is not available in the Fedora or RPM Fusion repositories for F11. If someone wants take care of yum-fedorakmod and wants to get it into RPM Fusion then please drop me a line.

What questions would you like to ask the Fedora Board or FESCo Candidates?

2009-05-19T16:07:00.002+01:00

Several seats of the Fedora Board and FESCo are up for election soon(¹). Right now we are in the nomination period, which will be followed by a "Candidate Questionnaire." That means we give candidates a list of questions to answer by mail before the Town Hall meetings on IRC happen.

Candidates may choose to answer (or not) those questions as they see fit. Voters can use the answers to get an impression of what the candidate think or plan to do while serving for the Board or FESCo. That should help to get a interesting discussion running during the IRC Town Hall meetings. Furthermore, those people that can't or don't want to participate in the IRC meetings can use the answers to make a more informed vote.

Hence we need to prepare a few good questions that we can send to the candidates once the nomination period ends. And that's where I need *your help*: If you have one or more questions you'd like to send to the candidates simply go and add them to:

https://fedoraproject.org/wiki/Elections/Questionnaire

It just takes a minute or two, so best to do it right now -- otherwise you might get distracted and forget about it. ;-)

I'll take care of the remaining work to review, sort, and clean up the questions(²), and send them to the candidates after the nomination period ends. Hence, I need them by around the 27th of May. I'll later collect the answers from the candidates and put them up for pubic consumption to give people enough time to read them before the town hall meetings start.

So go to the wiki and add at least one hard question! The answer will help Fedora contributors to chose whom to vote for!

Thanks for your help in advance.

(¹) If you haven't read about it yet see https://fedoraproject.org/wiki/Elections for details.

(²) If you want to get involved or review the questions before I send them please drop me a line and I'll try to get that arranged

Unprofessional

2009-05-19T15:46:00.003+01:00

Dear GNOME project,

thanks for running the "GNOME 3.0 General Sociological Research" survey and putting the results online.

A small note: If you ask people if they use foo, bar, baz or foobar and most people select foo, that that's it. Nothing more. And definitely don't conclude "Nearly ³/₄ of the people use foo for it's stability, compatibility and ease of use", because the latter part is a personal option if there wasn't a question "why do you use foo" with checkboxes "stability", "compatibility" and "ease of use" next to it.

Personal opinions like that render the whole conclusion unbelievable and make things look highly unprofessional.

rpmusrtools?

2009-02-28T16:04:00.002+01:00

The rpmdevtools are in Fedora for quite a while now and really helpful in a lot of situations. So are the tools in the yum-utils. But the tools in those two packages don't completely satisfy all my needs, hence I (ages ago) wrote a few small scripts that do some additional magic:

run "rpm -V" on all the packages and look out for packages where files are (a) missing or (b) corrupted; the script as a bonus (c) can even print out config files that have been modified (which likely should be part of a separate script, as that might be handy for backup purposes); if likely (d) should offer to reinstall packages that have missing or corrupted files
run something like "find /bin/ /boot/ /etc/ /lib/ /opt/ /sbin/ /usr/ /var/" with "-type f" and/or "-type d" and let rpm check if the list of files and/or directories that find outputs are owned by a package -- complain if not; that's quite a lot of work for the system and takes a while to complete, but often turns up a whole lot of old and obsolete cruft that is lying in some hidden corner of the hard disk just waiting to get erased (just checked a random machine; 3241 files sum up to 380 MByte...)
run something like "find /boot/ /etc/ /opt/ /usr/ /var/" with "-name '*.rpmnew'" "-name '*.rpmsave'"; go through the list of files find outputs, show a "diff -u" and offer the user to either
- run tools like meld or kdiff3 to merge the files(¹) and remove the .rpm{new,save}-file afterwards
- replace the file with its .rpm{new,save}-pendant (or do it semi-automatically if sha1sums are identical)
- delete the .rpm{new,save}-file
- do nothing
a script that calls all the above tests as well as "package-cleanup" sequentially with the options "--problems", "--orphans", and "--dupes" to generate a report of "unusual" things

All my scripts are quite rough and not really ready for general consumption. But I wonder if it would be worth to collect scripts like these (a lot of users likely have similar scripts), pick the best ones, clean them up in a fedorahosted project and ship them in a package "rpmusrtools" within the fedora repositories.

Dear reader: Would you find such a package useful? Or are there already such scripts/tools somewhere in the big Fedora package collection and I'm just not aware of them?

(¹) that works quite well for a lot of config files, but breaks horrible for those that have lots of comments in them that try to explain each and every option and/or variable :-(( it get even worse if those comments change every few months.

So this goes to the authors of dovecot, postfix, squid, and other software that has lots of comments in their default config files: "Config files are for configuration and should not contain lots of comments that get adjusted every few months, as those make it really hard to merge older (modified) config files with new one; in the future please consider to explain all option in a proper document like a man-page instead please and remove the comments from the config files! Thanks in advance! Yours truly, Thorsten Leemhuis"

I really wish we could get rid of ".fcXY" as disttag in rawhide

2009-02-16T06:28:00.003+01:00

I really wish we would get rid of using ".fcXY" as disttag in rawhide because it confuses way to many people when they find packages with tags like "fc7" on their fresh rawhide install... Simply using ".1" as disttag imho would be the best solution.

$ rpmdev-vercmp 1.2-3.1 1.2-3-fc10
0:1.2-3.1 is newer

Then packages that (for good reasons) don't get rebuild during one or two devel cycles don't have disttags from older fedora releases in their package names. But people didn't like it back when I proposed it some years ago. :-/ Hopefully someone sooner or later comes up with a better idea. ".fcn" for "Fedora Collections newest" maybe?

$ rpmdev-vercmp 1.2-3.fcn 1.2-3-fc10
0:1.2-3.fcn is newer

rpm.livna.org is not dead

2009-02-13T07:47:00.008+01:00

rpm.livna.org is unreachable -- but that are just temporary DNS problems, so the rumors of livna's death are greatly exaggerated. rpm.livna.org will stay as a add-on to the repositories from RPM Fusion for the foreseeable future.

The rpm.livna.org mirrors still work and yum will automatically use one of them. You can find the release-rpm on mirrors like the one on http://ftp-stud.fht-esslingen.de/pub/Mirrors/ in case you need it for a fresh Fedora install.

Update: The DNS for livna.org will likely be unavailable for at least a few days, likely a week or more. So spread the news to make sure everyone is aware of the fact that rpm.linva.org is still alive and remains usable thanks to the mirrors.

Update2: Use this command to enable livna on a fresh install:

su -c 'rpm -Uvh http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/livna-release.rpm'

After that adjust the repo file to let it retrieve the mirrorlist from one of the mirrors:

su -c "sed -i 's|http://rpm.livna.org/mirrorlist|http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/mirrorlist|' /etc/yum.repos.d/livna.repo"

The latter command should be used as workaround on exiting Fedora install as well if yum is unable to retrieve the mirrorlist!

Some notes on RHEL 5.3

2009-01-22T19:28:00.003+01:00

Congrats to the RHEL team for getting RHEL 5.3 out. Some random thoughts that sprung to my mind when looking closer at it:

The release announcement (short), the Red Hat Enterprise Linux 5.3 Technical Overview (medium sized) and the release notes (all the details) are really great resources to see what's new in the latest RHEL release. I wish we had similar documents for each new Fedora release (yes, we have the release notes, but they contain a lot of boring details regular Fedora users already know).
The kernel and dmraid in RHEL 5.3 now support dmraid 4/5/10. Alasdair, Heinz, others in RH: can you *please* speed up now to get that code (which is developed for quite some time now) upstream for Linux 2.6.30 to make sure it gets into Fedora 11 and from there into RHEL 6? I guess many users would be glad about that, as a lot of newer amd, intel and nvidia chipsets for desktop mainboards support RAID 5.
Many thanks in advance to the CentOS folks that already started to work on CentOS 5.3
I guess it will be an interesting comparison if somebody would compare the number of improvements (and their impact) that RHEL did between 5.2 and 5.3 with those that Ubuntu LTS 8.04.2 brings ;-) [Update 20090123]: Bad timing, 8.04.2 came out just a few hours after I wrote this; list of changes is available [/Update]

Communication is important

2009-01-18T20:25:00.002+01:00

Short version: More and more decisions in Fedora are done on IRC and in other places you have to be aware of; that itself would be no problem if the mailing lists would stay in the loop to make sure people cat raise their option before something is decided. But that's often not the case. The Fedora Project needs to improve here, as proper communication between contributors and those that make the decisions is a key factor for a community project.

Long version: Cut'n'pasted below is a part from a post that some time ago was send to some random fedora mailing list by someone that's quite important in Fedora:

I get the fact that you resent being in a timezone and location that
makes it difficult for you to participate in higher bandwidth forms of
communication (irc, phone, face to face).  I can't help that.  However
I'm not about to force the entire Fedora project slow to a crawl just so
that every thought, comment, discussion, fart, whatever happens via a
public email.  That's just ridiculous.  People will continue to talk on
IRC, will continue to chat via IM, will continue to talk on phones, and
will even *shock* talk in person!  Ideas, proposals, and even a decision
or two, depending on the group, will be made in these ways.  Deal with
it.

Statements like this are one of the reasons why I'm not as active in Fedora anymore as I was two or three years ago.

Sure, the one that wrote above para made a lot of good points. Face-to-face or IRC meetings are important and often help a lot to drive things forward. And we all afaics don't want a totally bureaucracy Fedora with hundreds of rules that express how decisions or other things have to be done; I actually tend to say we actually have way to many rules in some places already and need to get rid of a few (but that's a different topic).

But in the end above para sounded to me: be on FUDCon, IRC, or right hallway at a specific time on a specific place on earth or you have no chance to influence things. It might not have been meant that way, but that's what my mind made out of when reading it. Partly that's because I got the impression that more and more things in Fedora actually work in a "be there at the right time and place if you want to get heard"-way. Obviously that's bad for a lot of contributors due to time zone differences, job, vacation, or other real life issues getting in the way; which, obviously again, is bad for a community project that has contributors from places spread all over the world, as it excludes some contributors from getting involved or from influencing decisions.

That's why mailing lists (or a similar form of time-zone-independent communication) IMHO are very important for community projects with lots of contributors. But Fedora seems to move more and more things away from the public lists to other places -- especially IRC is used more and more desperate that we know there are people that don't want or can't join IRC.

Moving things to IRC wouldn't be such a big problem if important things that come up for decision in IRC or other places get announced properly 2 or 3 days beforehand on the lists. But that's often not the case, hence people that can't make the meetings get no real chance to see what coming up -- hence they can't share their options before something is up for vote. But that's IMHO a very very important factor for a community project, as contributors want to feel "heard" and have a chance to influence stuff, as that makes them feel as part of the project (and not like a citizen of a state where you can elect the decision makers every few months or year) -- even if the outcome in the end is not what the contributor wanted initially, as everyone knows (or at least should) that you can't get everything you want every time (a pony anyone?).

What makes things even worse: Now and then there are insufficient summaries from Fedora IRC meetings; the board is the big exception here while rel-eng often is not writing a summary at all. Sure, writing those summaries is a boring task -- I know that, as I had to write a lot of them for FESCo and the EPEL Steering Committee in the old days. But it's worth it, as a quick summary (even if it misses some details) is way easier to read then a log from a IRC meeting; that helps people to know what's up which again gives them the important feeling that they are part of the project. Not even trying to write summaries IMHO is a bit like top-posting and not removing unnecessary parts when replying to a mails on a mailing list: it might be easier and quicker for you, but a lot harder and time consuming for all those out there that want to know what's up. It shows disrespect for the community.

Time and place independent communication also is not only important for IRC but also for conferences. That why I'd like to say "Thanks" to Karsten Wade aka quaid for his recent blog post "Where are your FUDCon session notes?". And also thanks to all those that put videos from the recent FUDCon sessions online. Albeit those OTOH are a bit like IRC meetings without summaries -- watching them just like reading IRC meeting logs takes a lot of time and at least for me often has a bad "benefit per time ratio" :-/ . But as I said earlier: You can't always get what you want and this is a area where that's the case ;-)

Fedora and support for new hardware

2008-12-13T18:01:00.002+01:00

As some people will know: At work I have to deal with brand new hardware (especially CPUs, graphic cards, motherboards, printers, scanners) a lot. One of the two(¹) main reasons why I (and some of my colleagues) use Fedora when it comes to test new hardware for compatibility with linux: Stable Fedora releases regularly get new versions of kernel, sane, xorg-drv-*, and some other hardware-related software as regular update during their lifetime; that improves support for hardware (and especially new hardware) a whole lot over time, as those updates to new versions also bring lots of new and updated drivers. OpenSuse or Ubuntu don't do things like that -- you are either forced to run the devel tree to get new drivers or you have to wait six to eight months till the next release comes out.

But when I took a closer look at Fedora 10 I really was disappointed when I noticed that both gutenprint and hplip (likely the two most important packages with printer drivers) were far from up2date -- especially for gutenprint that sucked, as gutenprint 5.2.1 had brought support for a whole variety of new printers one month before Fedora 10 came out.

But that won't matter much anymore soon: Tim Waugh(²), prepared updates for Fedora 10 that bring gutenprint and hplip up to the latest upstream version. Many thanks for your work twaught!

Ohh, and while at it also many thx to davej, cebbert, kylem, ajax, nphilipp and all the other package maintainers that update packages like kernel, xorg-drv-*, sane, and others to the latest upstream versions now and then in stable releases. I (and I guess lot of people that buy new hardware now and then) really appreciate your work!

(¹) the other: Fedora most of the time doesn't contain drivers or patches that are not yet upstream or on the way upstream. So if it works in Fedora then it most of the time should work on other dists that have the same or a higher version of software like kernel, xorg-drv*, ...

(²) he seems to be a bit more cautiously than some of the Fedora packagers (not sure if that's good or bad) -- the maintainers of packages like kernel or openoffice.org for example had incorporated beta released of their software before the feature freeze and updated that to the final later. Hence that software was up2date when F10 came out; but that is likely a whole lot of work (which otoh helps both Fedora and upstream to get the software in better shape)

New toy

2008-12-02T18:25:00.004+01:00

We not only got a new cat -- we (or, to be precise: my girlfriend) also got a netbook. A Samsung NC10 in white:
The Fedora 10 installed just fine -- no problems at all. Dmesg, lspci:

00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GME Express Memory Controller Hub [8086:27ac] (rev 03)
 Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 02)
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 02)
 Kernel driver in use: pcieport-driver
00:1c.2 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 [8086:27d4] (rev 02)
 Kernel driver in use: pcieport-driver
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 02)
 Kernel driver in use: uhci_hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 02)
 Kernel driver in use: uhci_hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 02)
 Kernel driver in use: uhci_hcd
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 02)
 Kernel driver in use: uhci_hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 02)
 Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02)
 Kernel modules: iTCO_wdt, intel-rng
00:1f.2 IDE interface [0101]: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4] (rev 02)
 Kernel driver in use: ata_piix
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 02)
 Kernel driver in use: i801_smbus
 Kernel modules: i2c-i801
02:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)
 Kernel driver in use: ath5k_pci
 Kernel modules: ath5k
03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller [11ab:4354] (rev 13)
 Kernel driver in use: sky2
 Kernel modules: sky2

I didn't test everything yet, but suspend, hibernate and wifi worked out of the the box. Regulating the display brightness does not work using the function keys -- but it works using the gnome-applet.

Seems the wifi-LED does not work; and when I once disabled wifi using the hotkeys I could only get it to work again by restarting the system -- not sure, maybe it was just a hickup or something like that. I'll investigate further over the next few days.

Read the same paragraphs every half year?

2008-12-01T19:59:00.002+01:00

I really wanted to read the Fedora 10 Release Notes, but when I did I quickly got distracted. Later I asked myself why and gave it a second try with the goal: watch closely why you got distracted.

I first noticed that I had missed the brief overview at the bottom of the first page. I simply had hit "Next" on the top of the first page, as I expected it to be just the index, like it's iirc is in so many multiple-page howtos -- abs is just a random example here.

I further noticed that the text it a bit hard to read, as all the links are written in plain text within the text -- so you have to skip them with the eyes when you try to read continuously. To stress this a bit more compare yourself, which to you think is quicker and easier to read:

Features for Fedora 10 are tracked on the feature list page: http://www.fedoraproject.org/wiki/Releases/10/FeatureList

Features for Fedora 10 are tracked on the feature list page.

I then got to section 2.1 and read: "Anaconda is the name of the Fedora installer. This section outlines issues related to Anaconda and installing Fedora 10." I don't like the bold writing -- I find is distracting. But I know, some people like that. The real problem is something else and gets even more obvious in the whole section 2.1.1: Most if not all existing Fedora users know all of that already.

And that IMHO is the big problem of the whole release notes. Sure, these information are important for new Fedora users and hence they need to be written somewhere. But these information are just boring for all the existing Fedora users out there. The new information between all the old and well know stuff on the other hand is very important to existing Fedora users -- we want them to read it (which most do not afaics). Thus I'm really wondering if we should provide a second version of the release notes that only provides information that are really new -- then users that come from the previous release only have to read that document, which like is a lot shorter.

I'm not even sure how hard it would be to create that section release note set -- maybe running a diff over the old and new version, cut'n'past the relevant paragraphs where something important changed and put them into one document.

P.S.: Another thing that I dislike in the Fedora 10 Release Notes: Why isn't there a single-page version online that would make searching something a whole lot easier. Example: I knew there was a paragraph in the release notes regarding the flash-plugin. Hence i browsed to the Fedora 10 Release Notes Index, typed "/flash" in Firefox to find it, but failed. I tried some other keywords like "plugin" and failed as well. After a while I gave up and asked Google with the search term "flash-plugin site:http://docs.fedoraproject.org/release-notes/f10/en_US/" -- then I quickly found what I was looking for. Works, but only is you know how to use Google properly :-/

Number 3: Ginger

2008-11-30T12:29:00.006+01:00

Three and a half years ago Linus & Lucy moved in. Now they got someone to play with: Ginger

Welcome Ginger, hope you'll like it. Ohh, and Ginger, if you read this: Please stop playing on the edge of the floor above the stairs! You can fall down there easily (remember: you were close to falling down there a few times already!) and chances are big that you'll break your neck if you do.

P.S.: We considered to stick to names from Peanuts. Pig-Pen would have fit Gingers look, but well, she's (a) a girl and (b) that not really a good name for a cat. Hopefully Ginger sticks with us -- the original Ginger always tried to escape from "home".

Enable RPM Fusion during Fedora install

2008-11-25T17:46:00.004+01:00

To all those that install the brand new Fedora 10: If you enable the RPM Fusion online repositories during install you'll in F10 and later will automatically get some of the packages installed that RPM Fusion provides. Which packages? Well, that depends on what software you choose; if you for example stick to GNOME you'll get gnome-mplayer and some gstreamer plugins by default.

For details how to use RPM Fusion during install please take a look at the documentation in the RPM Fusion wiki. It also holds some information's how to enable RPM Fusion after installing Fedora.

See also:

RPM Fusion free and nonfree repositories for Fedora 10 (Cambridge) now available on fedora-announce-list

RPM Fusion for EL in the early testing stage

2008-11-10T19:57:00.002+01:00

A lot of people in the past asked for a „Livna for RHEL/CentOS“. There were rough plans to create one, but they got dropped immediately when the idea to merge Livna with other 3rd party repositories for Fedora came up. That lead to RPM Fusion being formed,which was announced one week ago.

Sharp eyes will have noticed that the announcement did not contain any information's regarding support for EL. That was on purpose – we focused on getting RPM Fusion running, hence the EL branch (which was planed right from the start) did not get as much love as the Fedora branch. But the EL branch is in the works and some of the most important RPM Fusion packages have been built for EL already. Xine and xine-lib-extras-freeworld for example are available in the testing repository already; the AMD and Nvidia drivers are still missing, just like mplayer and vlc. But all of them should hopefully get into the repositories over the next few weeks.

You can already help testing the RPM Fusion packages for EL repositories by enabling it with this command:

rpm -ivh http://download1.rpmfusion.org/free/el/updates/testing/5/x86_64/rpmfusion-free-release-5-0.1.noarch.rpm http://download1.rpmfusion.org/nonfree/el/updates/testing/5/x86_64/rpmfusion-nonfree-release-5-0.1.noarch.rpm

Some of the RPM Fusion packages for EL require bits from EPEL, hence it's necessary that you have EPEL configured and enabled as well – just like you had to enable Fedora Extras to use Livna in the Fedora Core days. Just remember that the RPM Fusion for EL repositories are still in the early stages. Also not that you for now need to enable epel-testing, as some of the RPM Fusion packages depend on packages that are currently in epel-testing. That requirement should hopefully vanish with the next testing -> stable move in EPEL. The RPM Fusion for EL repositories of course don't replace and packages from EL or EPEL.

Note that not all RPM Fusion contributors have interest in building their packages for EL (just like not all Fedora contributors participate in EPEL). Hence we could need some help and people with rpm packaging skills that help getting the RPM Fusion repositories for EL filled and maintained. If you are interested contact me in private or (preferred) join the mailing list and just start to help.

Second step of the transition from Livna to RPM Fusion: Moving F8 and F9 testing users over

2008-10-25T15:27:00.004+01:00

After enabling the RPM Fusion repositories for users of Livna devel a few weeks ago we now do the next step to move livna users over to RPM Fusion: Enable RPM Fusion for those F8 and F9 users that have livna's testing repos enabled.

The way to do that is round about the same as in the devel branch earlier: I added the rpmfusion-release packages for RPM Fusion's free and nonfree repos to the livna repo for F8 and F9; afterwards I built new livna-release for F8 and F9 that went into livna-testing; those two livna-release packages track the two rpmfusion-release packages in with a hard dep. That way all users that installed livna properly (e.g. by installing the livna-release package) and enabled the testing repos will now get RPM Fusion enabled automatically.

Note, nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna repos enabled for now if you want everything. Once all the packages have a new home we'll let the rpmfusion-nonfree-release package obsolete livna-release.

The plan is to move regular livna users of F8 and F9 over to RPM Fusion with the same trick sooner or later. But some things in RPM Fusion need to get brought in shape before we start considering that. But if you want you can already help by using and testing RPM Fusion for F8 and F9 by running this command:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

It's even easier if you have livna enabled already:

yum install rpmfusion-free-release rpmfusion-nonfree-release

Please spread the news, to make sure all the docs in the internet get updated! tia!

P.S.: Just a reminder while at it: Some of you might have noticed already, the livna mailing lists (like freeworld{,-graphics}@livna.org) are dead since a few weeks; the hard disk in Anvil's mailman host died afaik (I don't know more details; sorry). But Livna will be superseded by RPM Fusion soon anyway, so simply use the RPM Fusion mailing lists from now on. They should serve well for the remaining time, as all the livna contributors should be subscribed there as well. Sorry for the trouble.

First steps of the transition from Livna to RPM Fusion begins soon

2008-10-12T17:13:00.001+01:00

Over the next few days (likely on Tuesday evening CEST) we'll begin to slowly move users from Livna over to RPM Fusion by activating the RPM Fusion free and nonfree rawhide repos for livna-devel users.

The plan to realize that transition is quite simple: We'll add the rpmfusion-release packages for RPM Fusion's free and nonfree rawhide repos to the livna-devel repo; then we'll build a new livna-release package that tracks those two rpmfusion-release packages in with a hard dep. That way all users that installed livna properly (e.g. by installing the livna-release package) will get RPM Fusion enabled automatically. Yum/PK will download a big bunch of updates during the next update, as all the packages were build anew for RPM Fusion; but rawhide users are likely used to that, so this should hopefully not be a big problem ;-)

Note, nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna-devel enabled for now if you want everything. Once all the packages have a new home we'll let the rpmfusion-nonfree-release package obsolete livna-release. But please note that all the packages that have been imported to RPM Fusion will not be updated anymore in livna-devel from now on, to save work for repo and package maintainers!

The plan is to move livna users of F8 and F9 over to RPM Fusion with the same trick sooner or later. But some things in RPM Fusion need to get brought in shape before we start considering that. But if you want you can already help by using and testing RPM Fusion for F8 and F9 by running this command:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

And if you installed a Fedora Beta or Rawhide then from now on use the following command to enable RPM Fusion for rawhide:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm

Please spread the news, to make sure all the docs in the internet get updated! tia!

P.S.: Some of you might have noticed already, the livna mailing lists (like freeworld{,-graphics}@livna.org) are dead since a few weeks; the hard disk in Anvil's mailman host died afaik (I don't know more details; sorry). But Livna will be superseded by RPM Fusion soon anyway, so simply use the RPM Fusion mailing lists from now on. They should serve well for the remaining time, as all the livna contributors should be subscribed there as well. Sorry for the trouble.

Popular things are often not the right thing to do

2008-10-11T08:37:00.002+01:00

No, this has nothing to do with the presidential elections in the US; but yes, it's about politics. To quote from a mail send by dwmw2 to fedora-devel:

I propose that each FESCo member should try to work on at least one
package review per week. Each week at the FESCo meeting, we'll ask
members which reviews they've worked on in the past week.

Nice idea, but for me that sounds like a pre-election promise to lower taxes or like big and rich politicians handling out food in a soup kitchen or a: It will help a few people and gives good press because it's popular, but it doesn't solve the underlying problem at all. In fact it's even worse, because time gets wasted instead of solving the underlying or other problems (that might be bigger or smaller).

Verbose:

Sure, putting pressure on FESCo members to do reviews will force them to face some of the problems in the review process. That might result in some small improvements to the review process that might make things easier in the long term (but for that to really become true we also would need to have the same "should try [...] at least one package review per week" suggestion for members of the Fedora Packaging Committee as well); and of course the review queue gets a tiny fraction shorter due to the reviews that get done. But the time imho would be *way* better spend if some FESCo members would directly work on improving the review process with people that are doing lots of reviews (hello tibbs), because only that will improve the situation in the end (if done properly) and solve the problem (as far as it's possible to solve).

Ideas for making things easier and better are there; they are afaics well known among contributors and the different committees that are responsible. Just nobody is working on them:

* improve rpmlint and other tools to automate more of the checks to less the burden on the reviewer

* make review exchanges easier; maybe even force/guide/direct people a little bit to do exchange reviews (e.g. a little bit like, but not as strict as "if you want to get your packages reviewed you have to review a package from somebody else first")

* look more actively for new sponsors and be less strict when choosing them (like it has been in the past); we all make errors -- it's the ability to learn from them and to fix the errors once they got made

* be less strict with sponsoring people like it was in the early Fedora Extras days in 2005. We can do that now that new packagers don't get access each and every package in CVS

* add one more level between new packagers and sponsors; soon-to be sponsors there could work together with new packagers and keep an closer eye on them; by that they could get work of the real sponsor and show their ability to become a real sponsor sooner or later

* let FESCo and the Fedora Packaging Committee work together to make review and packaging guidelines easier to understand. We have done that two times in the past iirc (once in the fedora.us days and the last time it iirc mainly was spot's work with some help from mschwendt, scop and some others in the early FESCo days before the FPC existed). I tend to say it's overdue to do it again. Guidelines for corner cases in that process should get moved to special add-on documents or sections that are hidden by default. That will make the main things easier to understand and remember. Otherwise we soon have guidelines that will look like a code of law/statute book that nobody really understands as knows, as they are long and quite hard to read. Maybe splitting the guidelines might make sense as well: a "this is how it works in general" could be the quick ans easy start; a "here is how it works in detail" could serve as reference doc wher you have to look for the details and special treatments when it comes to perl/python/mono/java/...

* there are likely more ideas floating around...

And note, package reviews are just a fraction of the the area that FESCo is responsible for. So in the end instead of wasting time in each FESCo meeting with questions like "which reviews did you work on over the past week" it would imho be way better to ask "what did you do over the past week to make Fedora (the distribution and the project) a better place for contributors and users". That would also help to answer the "whom to vote for in the next election" question a lot.

Livna buildsys still down :-(

2008-09-25T19:05:00.003+01:00

Just FYI, the Livna buildsys is still down(¹) -- thus the stuff written in a earlier post still holds true. Yes, I know, that really sucks :-/

(¹) -- that is actually not the whole truth, as that is even worse. The buildsys was actually up last sunday for a few hours. I build a bunch of new kmods for the latest F8 and F9 kernels. I signed them and started the push to the master server -- then the buildsys went off the net again :-((

Life is a bitch: Livna Buildsys down, thus no new kmod packages in Livna right now :-/

2008-09-16T16:17:00.005+01:00

Life is a bitch -- the buildsys for livna is down again, thus I'm unable to build new kmod packages for the 2.6.26 kernels Fedora recently published for Fedora 8 and 9. Thus please be patient for a while; we'll build and publish them as soon as possible (but there is no ETA yet when the buildsys comes back; hopefully soon).

If you really need a new kmod for the 2.6.26 kernels you can either use akmods (Fedora 9 only) or follow the steps to manually rebuild a kmod srpm.

Example how to use akmod-nvidia on Fedora 9:

yum install akmod-nvidia

Just restart after that; the kmod should get compiled and installed on next startup. You might need to restart a second time before the nvidia driver gets enabled again -- there was a bug which was fixed just recently.

But there is one more problem: at least the akmods/srpms in the repos for iscsitarget, madwifi and qc-usb are not compiling with 2.6.26 yet :-/ Some of the maintainers have patches for this, so this problems hopefully will also be fixed quickly once the buildsys is back. I was told akmod-madwifi from devel might work, but someone else said it compiles, but doesn't work :-/

For RPM Fusion things hopefully will get better, as the buildsys seems to be more reliable. And we have two x86-builders, so one of them can go down without causing trouble. Ohh, and we'll be able to build kmod packages quicker thanks to the second builder.

akmods - compile kmod packages when needed

2008-09-16T15:23:00.005+01:00

I never mentioned it in my blog and it seems many people are not aware of it yet: the livna repos for Fedora 9 and Fedora development not only contain pre-compiled kernel-modules in kmod packages (e.g. kmod-nvidia, kmod-madwifi, ...); they also contain akmod packages (akmod-nvidia, akmod-madwifi, ...), which contain the sources for the kmod as source rpm (srpm). That srpm will dynamically get compiled and installed by the akmod scripts on startup in case the kmod for the kernel you booted were not found. That not only works for kernel from Fedora; it should work with kernels you complied yourself as well, as long as the files needed to compile kernel modules are available.

Note that kmods and akmods work nicely together. E.g. you normally install both akmod-foo and kmod-foo; if the kmod-foo is not found during bootup for the kenrel you booted akmods will step in and compile a kmod-foo for you.

Bringing M&Ms back to Germany

2008-06-21T18:21:00.004+01:00

Okay, some weeks I asked for it, now on FUDCon F10 I got what I (or to be precise: my girlfriend) wanted:

Many many thanks to Southern_Gentlem (James "Ben" Williams ) and daMaestro (Jonathan Steffan) who bought them for me and brought them to FUDCon today. You rock guys; my girlfriend will be very very happy.

thl left Red Hat Summit 2008, knurd now at FUDCon ;-)

2008-06-20T19:10:00.004+01:00

FYI, if you are attending Red Hat Summit or FUDCon: I mostly finished my work as member of the press now and thus I have a bit more time to talk to all of you that are around. Sorry, my work kept me a bit busy over the past few days so I didn't find enough time to talk to all of you I meet :-/

While at it a small disclaimer (added later: and a bit of advertising): A few people asked what kind of stuff I'm actually writing about. That's easier to answer these days as some of the stuff I'm writing is translated into English for our UK online publication. You there for example find some of the things I wrote from the summit (like these two). There is more to come; due to timezone differences and a bit of time to translate things to English it sometimes takes a while to get published.

But reporting from event like the Summit is a special thing. I normally test hardware (mainly motherboards and their chipsets, sometimes CPUs). I'm also kind of the main "linux hardware guy" for our magazine (where I'm still known as thl like I used to be in Fedora until a year or two ago). To do the latter properly I'm following quite a lot of linux projects to know what's up in linux-hardware-land -- for example by reading LKML. I not only use those information's in my day work -- I also write about the most important things that happened in a column that's called "kernel-log" (which not only reports about the linux kernel; there are often information on X or other things that are important for linux hardware support). You can find kernel-log examples (1, 2) in the UK publication as well (but not all of them get translated). In addition I write quite long "what's new in Linux 2.6.x" articles when new kernels come out. Examples (warning, they are quite long thus you need a bit of time to read them): 2.6.24, 2.6.25.

Knurd's chocolate im- and export ;-)

2008-06-03T18:40:00.004+01:00

As I mentioned in in my previous blog post: I'm going to Boston for the Red Hat Summit 2008. That means (the long story short):

I can buy Peanut Butter M&Ms -- my girlfriend really likes them, but they are not available in Germany :-((
I can bring some European/German chocolate or other sweets to the US for folks that visit the Summit or FUDCon

The verbose story:

Import: My girlfriend likes sweets (well, I do as well ;-) ) and some years ago she got some Peanut Butter M&Ms from a friend of her, who hat ordered them via Ebay earlier. My girlfriend really enjoyed them, but getting them via Ebay in Germany is hard and costly (and in fact: we don't like Ebay much and thus never sold or bought anything via Ebay ourselves...). I tried to get them elsewhere, but could not find them anywhere in Germany -- even shops like AmericanCandy don't offer them (if anyone knows a shop that sells them please drop me a note).

So when I visited FUDCon Boston in February 2007 I brought some Peanut Butter M&Ms home -- many thanks again to Southern_Gentlem from #fedora-unity, who bought them and sent them to the hotel for me. Sebastian Dziallas (the guy who formed the Education SIG and works on a Fedora Education Spin) was in the US earlier this year and brought some to Germany for me and my girlfriend as well (thx Sebastian!). Not sure how it happened, but they somehow vanished within a day... He also brought some Dark Chocolate Peanut M&Ms; those were tasty as well, but not as good as the peanut butter ones, so they did not evaporate as quickly ;-)

Thus when I'm visiting the Summit I'll bring some new Peanut Butter M&Ms home to Germany. In fact I really have to, as my girlfriend will kill me otherwise. She also ordered some Mint Crips M&Ms to check their smell -- they just like those with Peanut Butter are not available in Germany. :-/ Ohh, and I think I want to give Dark Chocolate M&Ms a try. I'm not yet sure if I'll buy them myself during the days in Boston or if I ask someone to bring them to Boston for me. Are they hard to get?
Export:When I visited FUDCon Boston 2007 I brought some German chocolate to the US with me, as Bob Jensen (*Bob* in #fedora-unity) asked me for it -- he told me it was for his kids, but I suppose he tried a piece of chocolate himself as well ;-)

Of course I can put some German sweets into my luggage when I'm traveling to the US this time. If I know you and if you're attending the Summit or FUDCon drop me a mail if you want some sweets and I'll try to bring it over the ocean (I for example could recommend a nice Bitterschokolade from Rausch called Tembadoro -- it contains 80 percent cocoa and smells great!) Of course space and weight is limited (carrying lots of sweets might look odd at customs as well -- does anyone have experience if that really is a problem?) Ohh, and I can't promise how the stuff looks when it gets into your hands -- I'll do my best to bring them intact, but traveling with chocolate or other sweets is a bit complicated during summertime...

Going to Red Hat Summit 2008 / FUDConF10 Boston

2008-06-03T15:55:00.003+01:00

A lot of you will have noticed: Apart from

a (hopefully helpful) mail here and there
a bit of work on the packages I maintain
the testing -> stable moves for EPEL4 and EPEL5

I'm making myself quite rare in the Fedora Project, as I'm quite unhappy about a whole lot of things in Fedora the Project (or mainly its organization with all those committees and all the bureaucracy; not about the contributors to Fedora or Fedora the distribution -- the latter of course like every other Linux Distribution had and has some things I dislike, but in the end it's not that bad). That's likely nothing new to most of you, as I mentioned that now and then already here in my blog or via mail on the lists. It would be a whole lot better to try to work towards improving the things I'm unhappy with, but I don't have the energy at the moment to do that. I tried a bit over the past 14 months, but it feels like it were hard and time-consuming discussions that didn't change much in the end -- so I suppose Fedora isn't the right place anymore for me to invest a great deal of my spare time (like I did in the past four years); thus I reduced my involvement and stopped trying to fix the things I dislike.

But life is funny game sometimes and it seems I at least for a few days get closer to Fedora and it's contributors again. Why you ask? Well, I'll visit the Red Hat Summit 2008. My travel back to Germany is scheduled for Sunday afternoon after the Summit ended -- thus I'll have enough time to join the FUDConF10 Boston Hackfest sessions on Saturday after the Summit. Note that I'm not going "just for fun" to the Summit -- Wednesday to Friday is a business trip for me and I have to do some work there. I was just the lucky one at work that was chosen for the trip, as it didn't really fit into my colleagues schedule... Well, it was not only luck -- I suppose it helped a bit that I'm quite familiar with what's Red Hat doing anyway ;-)

And yeah, I'm quite happy to go to the Summit and FUDCon -- especially as this gives me the opportunity to see a lot of Fedora people in real life that I normally got in contact only with via IRC or mail in the past years. Maybe I should feel a bit worried, as I suppose I didn't make much friends over the past year in Fedora... I suppose I'm the "always complaining and bad-painting everything 'old men' that might have been a bit important in the old Fedora days but now just disturbs the work" for some people.

But well, should I use the opportunity and try to work towards changing some of the "things I really dislike in Fedora" at FUDCon? There are a whole lot of Fedora people there in one spot, so it might be a bit easier to get complicated things discussed and maybe even improved/realized. Maybe I should try, but I'm not sure if it's worth the trouble. I'm also unsure if it's only me that feels that a lot of things are far from good and really need improvements; I only know from some discussions in real life or via mail that there are at least some people that just like I think "from the spare time contributors standpoint a whole lot of things got worse in Fedora the project (not the distribution!) since the Core and Extras merge".

So what should I do? Just try to be a ordinary visitor at FUDCon? Or try to do a small survey among Fedora contributors in preparation for FUDCon to get a impression how people feel and where they think Fedora needs to improve? I suppose I could be the right one for such a small survey, as I disliked a whole lot of things ;-)

LinuxTAG 2008

2008-05-26T09:12:00.003+01:00

Lot's of LinuxTAG blog entries on Planet Fedora, so I'll add another one FYI:

It currently looks like I won't be able to attend this Fridays FUDCon on LinuxTAG 2008. :-/ Sorry guys, I just couldn't fit it into my schedule...

But I'll be at LinuxTAG on Thursday, as I'll be giving a talk at 10:00 AM (CEST). I'll of course stop by at the Fedora booth and hope to meet lot of familiar people from the Fedora community there. :-) So see you next Thursday!

SnowBit

2008-03-03T06:57:00.003+01:00

As some of you know: I live in Hannover. Yes, that Hannover where tomorrow CeBIT will start.

We don't have much snow in Hannover normally. Round about 2 to 7 days each year I'd say, most of the time in December or January. This winter we haven't had snow at all IIRC -- just one day there was a bit Industrieschnee. The first sights of spring showed already up in the garden over the past two weeks.

But it seems every year when CeBIT starts its getting cold again and starts to snow. So guess what the weather prediction predicts for Hannover in the next few days: Light snow.

Can't believe it. I think all the visitors will yet again get the wrong impression about the weather in Hannover... No wonder why some people call it SnowBIT...

Smooge new EPEL Steering Committee chairmen

2008-02-13T19:40:00.004+01:00

It was mentioned in the EPEL reports and on the epel-devel-list already, but it might be good to announce it here as well: after leading the EPEL effort/the EPEL Steering Committee for about one year I'm stepping down as chairmen and leave the EPEL Steering Committee to make room for new members and fresh ideas.

Some minutes ago Stephen J Smoogen (smooge) was elected as new chairmen for the EPEL Steering Committee. Congrats smmoge! I'm sure you'll do a good job and get some new ideas realized in EPEL.

I'll stay involved in EPEL, but I'd like to focus a bit on RPM Fusion over the next few months. In the past weeks keeping EPEL and Livna running consumed most of my free time which kind of sucked as RPM Fusion really needs more attention; hopefully we can make it lift of soon (the current situations kind of reminds me of the FC2/FC3 days when the real Fedora Extras also started quite slowly...).

P.S.: Since a few days EPEL5 & EPEL5 testing include about 2000 packages (counting RPMS here, not SRPMS). I'd say that quite a lot what we got into EPEL in the past months since EPEL started. Another reason to make room for some fresh ideas in the EPEL Steering Committee.

Lots of changes

2008-01-25T09:53:00.000+01:00

$ for i in 20 21 22 23; do echo -n "2.6.${i} -> 2.6.$((${i}+1)): "; git diff v2.6.${i}..v2.6.$((${i}+1)) | diffstat | grep ' files changed, '; done

2.6.20 -> 2.6.21: 6568 files changed, 319232 insertions(+), 175247 deletions(-)
2.6.21 -> 2.6.22: 7620 files changed, 519591 insertions(+), 266699 deletions(-)
2.6.22 -> 2.6.23: 7203 files changed, 406268 insertions(+), 339071 deletions(-)
2.6.23 -> 2.6.24: 10209 files changed, 776107 insertions(+), 483031 deletions(-)

I like the current kernel development scheme; it might look a bit scary (especially for 2.6.24), but afaics it's way better then what we had in the past when new stuff (sometimes including drivers for new hardware) lingered around in 2.3 or 2.5. way to long.

A milestone: More than 1000 packages in EPEL5!

2008-01-22T08:56:00.000+01:00

I'm proud to present some statistics from the "Extra Packages for Enterprise Linux (EPEL)" SIG:

$ repoquery -qa --archlist="src" --repoid=epel5-source --repoid=epel5-testing-source | wc -l
1006

In other words: we have now more then 1000 different software packages (counting SRPMs) in the EPEL5 repositories for RHEL5/CentOS5.

Thanks to all Fedora contributers that also participate in EPEL! You made this happen!

Next goal are 2000 Binary RPMs in EPEL5. Shouldn't take that long:

$ repoquery -qa  --repoid=epel5 --repoid=epel5-testing | wc -l
1861

Looking back at the last Fedora year (2)

2007-12-21T09:40:00.000+01:00

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

2007-12-20T12:47:00.000+01:00

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

2007-12-13T08:47:00.001+01:00

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?

2007-12-10T15:04:00.000+01:00

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

2007-12-05T15:55:00.000+01:00

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)

2007-12-04T08:58:00.000+01:00

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

2007-11-20T19:47:00.000+01:00

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

2007-11-11T11:56:00.000+01:00

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

2007-11-01T19:00:00.000+01:00

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...

2007-10-25T18:21:00.000+01:00

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

2007-10-13T10:05:00.000+01:00

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

2007-10-04T07:21:00.000+01:00

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

2007-09-30T09:40:00.000+01:00

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

2007-09-30T07:54:00.000+01:00

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)

2007-09-27T18:22:00.000+01:00

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

2007-09-26T16:47:00.002+01:00

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

2007-09-26T09:42:00.000+01:00

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?

2007-07-30T07:12:00.000+01:00

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

2007-07-07T12:17:00.000+01:00

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

2007-07-05T17:36:00.000+01:00

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

2007-07-05T08:10:00.000+01:00

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

2007-06-14T12:53:00.000+01:00

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

2007-06-03T12:50:00.000+01:00

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

2007-04-24T16:27:00.000+01:00

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?

2007-04-14T12:23:00.000+01:00

'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]

2007-04-05T21:31:00.000+01:00

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

2007-03-27T14:27:00.000+01:00

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

2007-02-09T18:10:00.000+01:00

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

2007-02-06T21:16:00.000+01:00

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

2007-02-06T20:21:00.000+01:00

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

2007-01-16T18:41:00.000+01:00

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

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]

2007-01-14T12:10:00.000+01:00

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

2007-01-10T20:24:00.000+01:00

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

2007-01-08T15:33:00.000+01:00

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 :-)