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 ;-)
Mittwoch, 11. November 2009
Sonntag, 1. November 2009
New RPM Fusion packages: nvidia drivers for F12, staging drivers for F11 and F12
Just FYI:
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
- 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
- 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
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
Samstag, 27. Juni 2009
Presentations from LinuxTag / Fudcon Berlin 2009 available; Tomorrow: Hackfests
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:
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!
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!)"
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!
Donnerstag, 25. Juni 2009
thl and knurd @ LinuxTag 2009 and Fudcon Berlin 2009
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.
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.
Mittwoch, 17. Juni 2009
rpmfusion-{,non}free-remix-kickstarts -- or -- knurdix
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.
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.
Freitag, 12. Juni 2009
Make things easy
Alan Cox recently on LKML:
[...] If nobody else is interested then you can do the reviewing/ackingSometimes I wonder if we should apply a similar concept in Fedora/RPM Fusion land more often.
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 ;) [...]
Montag, 1. Juni 2009
Leave kmods in RPM Fusion, but make sure they work well
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.
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.
Samstag, 23. Mai 2009
yum install thunderbird-enigmail
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
# 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
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:
"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:
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.
"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(²).
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.
Dienstag, 19. Mai 2009
What questions would you like to ask the Fedora Board or FESCo Candidates?
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
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
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 3/4 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.
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 3/4 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.
Samstag, 28. Februar 2009
rpmusrtools?
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:
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"
- 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
- run tools like meld or kdiff3 to merge the files(¹) and remove the .rpm{new,save}-file afterwards
- 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
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"
Montag, 16. Februar 2009
I really wish we could get rid of ".fcXY" as disttag in rawhide
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-fc10Then 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?
0:1.2-3.1 is newer
$ rpmdev-vercmp 1.2-3.fcn 1.2-3-fc10
0:1.2-3.fcn is newer
Freitag, 13. Februar 2009
rpm.livna.org is not dead
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:
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!
Donnerstag, 22. Januar 2009
Some notes on RHEL 5.3
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]
Sonntag, 18. Januar 2009
Communication is important
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:
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 ;-)
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 thatStatements like this are one of the reasons why I'm not as active in Fedora anymore as I was two or three years ago.
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.
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 ;-)
Abonnieren
Posts (Atom)