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)
Samstag, 13. Dezember 2008
Dienstag, 2. Dezember 2008
New toy
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:
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.
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)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.
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
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.
Montag, 1. Dezember 2008
Read the same paragraphs every half year?
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:
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 :-/
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.
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 :-/
Sonntag, 30. November 2008
Number 3: Ginger
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".
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".
Dienstag, 25. November 2008
Enable RPM Fusion during Fedora install
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:
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
Montag, 10. November 2008
RPM Fusion for EL in the early testing stage
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:
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.
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.
Samstag, 25. Oktober 2008
Second step of the transition from Livna to RPM Fusion: Moving F8 and F9 testing users over
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:
It's even easier if you have livna enabled already:
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.
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.
Sonntag, 12. Oktober 2008
First steps of the transition from Livna to RPM Fusion begins soon
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:
And if you installed a Fedora Beta or Rawhide then from now on use the following command to enable RPM Fusion for rawhide:
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.
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.
Samstag, 11. Oktober 2008
Popular things are often not the right thing to do
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:
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.
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.
Donnerstag, 25. September 2008
Livna buildsys still down :-(
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 :-((
(¹) -- 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 :-((
Dienstag, 16. September 2008
Life is a bitch: Livna Buildsys down, thus no new kmod packages in Livna right now :-/
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.
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
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.
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.
Samstag, 21. Juni 2008
Bringing M&Ms back to Germany
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.
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.
Freitag, 20. Juni 2008
thl left Red Hat Summit 2008, knurd now at FUDCon ;-)
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.
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.
Dienstag, 3. Juni 2008
Knurd's chocolate im- and export ;-)
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):
The verbose story:
- 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
A lot of you will have noticed: Apart from
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 ;-)
- a (hopefully helpful) mail here and there
- a bit of work on the packages I maintain
- the testing -> stable moves for EPEL4 and EPEL5
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 ;-)
Montag, 26. Mai 2008
LinuxTAG 2008
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!
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!
Montag, 3. März 2008
SnowBit
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...
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...
Mittwoch, 13. Februar 2008
Smooge new EPEL Steering Committee chairmen
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.
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.
Freitag, 25. Januar 2008
Lots of changes
$ 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.
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.
Dienstag, 22. Januar 2008
A milestone: More than 1000 packages in EPEL5!
I'm proud to present some statistics from the "Extra Packages for Enterprise Linux (EPEL)" SIG:
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 --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
Abonnieren
Posts (Atom)