Archive for the ‘Fedora’ Category

The Linux/FOSS desk at Assembly Summer 2008 – with Fedora

Friday, August 1st, 2008

I’m currently blogging from the Assembly demoparty in Helsinki, Finland. The Finnish Linux User Group and the user communities of different distributions have organized a Linux/FOSS support desk here. We have three demo computers here, one is running Fedora with KDE4, the other is running Ubuntu with Gnome and the third is running Frets on Fire on Ubuntu. We are also handing out CDs here, we have a lot of Fedora 9 CDs and some Ubuntu ones too.

The support site (in Finnish) is at – you can add a support request there and people will come and help you if you have a Linux related problem. In case you don’t know Finnish, just come meet us at the desk 🙂

If you’re a Fedora user, developer, translator or interested in becoming one, come and meet me, I should be here for Saturday and Sunday. Our desk is near the doors A112 and A113.

I’ll attach some images as well:

The Fedora and Ubuntu CDs

The computers

The banners

Fedora 9 being updated and Frets on Fire

Fedora 9: Fonts in KDE 4

Monday, May 19th, 2008

I just spotted this thread in fedora-list about KDE and fonts. Apparently the default font in Fedora 9’s KDE 4 is Nimbus Sans L. I switched the font in my KDE to DejaVu Sans earlier – just like Kevin Kofler recommends – but forgot to write about it in my previous posts. This font looks quite nice in KDE, I recommend making the switch if you use KDE and haven’t switched yet.

Here’s what Kevin wrote in case you can’t be bothered to read the mailing list thread 😉 :

In System Settings, pick Appearance, Fonts, Adjust all fonts…, check Font and set it to DejaVu Sans, check Font style and set it to Regular.

I have no idea why this isn’t being picked up as the default font, it’s supposed to. For some reason, it’s defaulting to “Sans Serif” and interpreting that as “Nimbus Sans L”, whereas it would be expected to default to “Sans” which is a FontConfig alias for “DejaVu Sans”.

By the way, I’ve been getting a couple of comments from my Fedora 9 related posts and so I decided to install the WordPress OpenID plugin to hopefully make commenting a bit easier for some people. I’ll still approve all comments – even those posted with OpenID – myself, since I really don’t want any spam.

My adventures with Fedora 9, part 2

Saturday, May 17th, 2008

I’ve updated my Smolt profile for the laptop, it’s here.

Since this laptop has an Intel 915GM/GMS/910GML Express Graphics Controller (I have no idea which one it actually is 😉 ), I tried kernel modesetting by adding i915.modeset=1 to the kernel boot line in /etc/grub.conf. At first it seemed to work just right and it seems to be a really nice feature. But after some usage I started to see weird font issues every now and then, all of the characters weren’t drawn completely, some parts were missing. Now that I’ve disabled kernel modesetting again, I have not seen any of these issues, but the boot looks much uglier now 😀 . I’m looking forward to this stuff becoming more widely used in the future. I have to mention that drawing stuff on to the screen in X seems to have slowed down quite a bit with the upgrade. I can’t say anything very specific, but for example doing a cat /var/log/messages is much slower and uses more CPU than it used to. Someone else has noticed it as well. I think this might be the reason why the laptop is running a bit hotter than it used to.

The IPW2200 error messages I mentioned in my previous post are gone now. Maybe it was the kernel update that fixed it…

I also updated to KDE 4.0.4 from updates-testing. It seems to work quite nicely now, especially after I switched the new menu to the more traditional one. I still have the new menu on the desktop, though, just because you can’t add new icons to the desktop or the panel via the old style menu with the right mouse button. The most visible problem I see now is the clock. If I add the date to the clock, I can’t actually see the date at all, because it goes so low it’s already out of the display 😀 . The tray icons are also sometimes acting weirdly, as I wrote in my previous entry, but I’ll keep an eye on that. Oh, and I keep using compositing with KWin. I’ve had problems with GNOME’s compositing, but in KDE it works great and looks nice 🙂 .

Now that I mentioned updates-testing, there’s also one issue related to it. When I first did yum --enablerepo updates-testing check-update, it only showed me some Fedora 8 updates. Even doing yum clean all didn’t help. There was recently some talk about his in the #fedora-devel channel, so it might be a common issue. I did an rm -r /var/cache/yum/*, but apparently yum --enablerepo updates-testing clean all could also help.

Now that Fedora 9 has OpenJDK, I removed Sun’s proprietary Java, which I had installed in /opt/, changed the java binary to the free one by running alternatives --config java, removed an sh script in /etc/profile.d/ which set the java paths to the proprietary JDK and removed the symbolic link to the proprietary java plugin I had in /usr/lib/mozilla/plugins/. I also installed the java-1.6.0-openjdk-devel and java-1.6.0-openjdk-plugin packages, so now I should have quite a complete open java stack. It’s not yet quite the same as the proprietary JDK, but it looks very promising. Here’s a Red Hat Magazine article about OpenJDK.

The tapping functionality in touchpads has been disabled in Fedora 9. Axel Thimm gave advice on how to get it working again in this bug and now I have tapping working again. I’m not going to get into the discussion of whether or not this was a good thing, but having worked with the Docs team for a while, this would have needed a release note. The developer responsible for this change just probably forgot, since I don’t think the Docs team even knew about the change. Well, such is life… I also put syndaemon -k into my /etc/rc.local file, so that the touchpad will now be disabled when I’m using the keyboard. Syndaemon could be configurable as a service, though.

I guess that’s it for now, I may report more about my Fedora 9 experiences later…

My Fedora 9 upgrade story

Thursday, May 15th, 2008

I upgraded my laptop – an Asus S5A, Intel based – from Fedora 8 to Fedora 9 today. I used the DVD and the upgrade itself went with no problems. But after I booted into Fedora 9, I’ve been having some problems with it.

I used to use KDE in Fedora 8 and so I started with KDE 4. It looks quite nice, but doesn’t work that nicely: Some icons are missing in the new menu. KWin has a habit of starting to use all CPU time so that I need to restart X, both with and without compositing. The system tray icons of GNOME programs like gnome-packagekit don’t show up fully, I can only see about three quarters of the icons. If I try to resize the bottom panel into “Small”, the tray icons will “leak” out of it. And then there’s the bug of GTK apps looking quite ugly, but that has been fixed in an upcoming update. I’ll try 4.0.4 once it hits updates-testing, but so far I’ve just used GNOME instead.

GNOME itself is quite alright, but when I tried to use the desktop effects, the whole screen would turn completely white during some logins when starting GNOME, so I had to go to KDE and disable the effects. As this is a laptop, I also disabled automatic checking of updates from gnome-packagekit – but still I recently got an update notification from it. This needs further investigation to see if it really is a bug or what actually happened.

I also have a couple of hardware related issues. This laptop uses the IPW2200 wireless and I keep getting this message in the logs constantly: ipw2200: Failed to send SYSTEM_CONFIG: Already sending a command. I don’t have any wireless networks around me that I could use right now, so I’ve just disabled the wireless with the kill switch. On top of that, the machine seems to run hotter than it did in Fedora 8. It has quite poor cooling already and under Fedora 8 it usually ran at about 47 degrees Celcius. Under Fedora 9 it’s usually at about 50 degrees Celcius. That’s not much, but it did catch my attention. I’ve kept an eye on top and powertop and I see nothing really special there. Xorg does maybe take a bit more CPU as seen in top than it used to, so maybe it’s that one…

I’m also a Fedora packager so anyone responsible for the packages in question here, this is definitely not aimed at you personally. I especially know that the relatively small KDE and PackageKit teams in Fedora have been doing a lot of work to get all this new stuff into Fedora 9. And the packages in F9 are quite leading edge. And yes, I should have done more testing in the alpha and beta stages myself.

None of these issues actually prevent me from doing real work with the laptop (except maybe the WLAN thing, but I can’t test it yet…), I can very well live without desktop effects, I can use GNOME and wait until KDE4 develops further and it’s probably not going to make a real difference even if the machine runs a bit hotter. I’ll wait for a few days for all the “almost 0-day updates” to sync to the mirrors and I’ll start filing bugs if I still see these problems.

I promise to blog about some of the new and cool stuff in Fedora 9 (like OpenJDK, kernel based modesetting, PackageKit – even though I may have hit a bug 😉 – etc.) later on, when I actually have a bit more experience on the new release. The sad truth just is that you tend to spot all the problems and annoying stuff before all the goodness…

FLSCo Nominations

Sunday, April 13th, 2008

Dimitris threatened to poke me with a stick if I didn’t nominate myself for the Fedora Localization Steering Committee, so now I have. The elections will take place between the 14th and the 20th of April 2008. Please remember to vote, even if not for me 😉 . Fedora in general and also the L10N project is about us, the community, so make your voice heard!

The Google Highly Open Participation Contest and MoinMoin

Wednesday, November 28th, 2007

I haven’t blogged in a long time, but this is something I think deserves to be mentioned.

Today Google announced The Google Highly Open Participation Contest, which is a program for pre-university students. They participate in some of the 10 open source projects and Google pays them a maximum of $500 for it.

MoinMoin, the wiki engine used by Fedora, is one of the open source projects in this program. So if you’re a highschool student who’d like to contribute to a really nice open source Python based wiki engine and earn a few bucks while doing that, go see MoinMoin’s GHOP 2007 page. Remember, there are also other tasks than coding, like translation, marketing, testing etc!

Weekly report: week 34

Tuesday, August 28th, 2007

Last week was a lot about fighting with Texinfo. As I’ve probably said earlier as well, makeinfo –docbook is supposed to make DocBook XML. But it doesn’t really work that well. In the best case, it produces something that is well-formed XML but not really DocBook if you validate it against the DTD. Which means Moin can’t show an HTML rendering of it. In the worst case, makeinfo just segfaults.

In hopes of getting better HTML output from the pseudo-DocBook XML Texinfo files, I tried to use Moin with the latest Docbook XSL stylesheets, 1.73.1. And that resulted in a 4Suite error. See the Moin bug report I made.

So I joined #docbook and #4suite to report about my problems. Michael Smith, one of the DocBook XSL maintainers, was interested and made a workaround that will be in the next release of the stylesheets. See the SVN commit here. Thanks! Uche Ogbuji, a 4Suite developer was also interested to see if I hit a 4Suite bug. He knows the details now, so if it really is a bug, it’ll hopefully get fixed when he has the time to take a look.

In discussions with Michael Smith he convinced me to drop docbook2X and use the DocBook XSL stylesheets for DocBook refentry -> man source transformation. So I modified the ManSource action to use those via xsltproc. I also implemented caching, so that xsltproc doesn’t have to be called every time, if the same man source already exists. ManSource should handle concurrent requests too, but I haven’t done that much testing on it.

Michael had an idea that some of the pseudo-DocBook that makeinfo –docbook makes could be fixed to be valid DocBook with a stylesheet. So I have collected some of these XML files, see, take a look if you’re interested. You can try validating those with e.g. xmllint --noout --valid xml-file.xml. If Michael has the time to come up with such a stylesheet, that would be great, since right now makeinfo –docbook produces only two valid DocBook XML files from the whole Fedora updates-released repository!

Yesterday I added support to collect these “well-formed XML but not DocBook” files to the manimport script, so anyone could do the same and take a look at what makeinfo –docbook outputs. I also added some logging to file via the python logging module, so that you can analyze what has append later on and don’t need to save the output that manimport gives to the console.

What I would desperately need is a better way to do Texinfo to DocBook conversions. So either makeinfo –docbook should be fixed or a new converter should be made. Maybe I could report some of these things to the GNU Texinfo people in hope of a better makeinfo. Ideas?

As this is the final full work week of Summercode, here’s a quick list of what will be and what won’t be done:

As the most important point, there won’t be wiki markup as the editing/storage format in the wiki, but DocBook. The main reason is that I won’t have the time to do it correctly, meaning without loss of information. This is mostly because of the problems I’ve had with external tools and conversions during my project. Having wiki markup is possible, though. Probably the best way would be to write a DocBook refentry -> wiki markup XSL stylesheet. Avoiding information loss could be handled by putting in Moin macros where the wiki markup isn’t enough, as suggested by Florian Festi. Those macros would then activate themselves when doing the wiki markup -> DocBook XML conversion. But if Moin macros would have to be used correctly by the users who edit the man pages in the wiki, would it actually be easier for them too to keep DocBook as the format?

Also, there won’t be that much testing during Summercode. Of course I’m testing all the time locally, but large scale testing will hopefully happen after Summercode.

(I’ll talk about only man pages here, info pages are also be mostly supported, but if makeinfo output can’t be fixed, there won’t be much info pages to use…)
Importing man pages from Fedora’s repositories, with support for repository updates and different releases works. Diffing between the same man pages in the different releases works. Getting the man source of a man page in the wiki works. Comparing the changes in the wiki to the original man source is not done yet, but that’s on my agenda for this week. There also aren’t index pages yet, you’ll have to find the man page you want with Moin’s search, but I’d like to add some index page generation to manimport this week too.

There won’t be any kind of official release of the stuff I’ve done yet. I’d like to have it all working on my public test instance, so that some of the features could be shown, though. The reason for not really releasing anything is that my work is based on Moin 1.7, which is still a quite fast moving target. It’ll hopefully be released some time next year and my goal is to have all of my stuff merged into 1.7 main in time for the release. That would also mean making some of the import code more general, as it’s quite Fedora/RPM specific right now. Still, none of this prevents Fedora to run my man/info wiki stuff, the underlaying Moin just won’t be officially stable, so there might be some bugs etc.

Here’s my plan for this week:

  • Going through the logs of info importing I made yesterday and seeing if there’s something that could be done to improve info importing without touching makeinfo
  • The “diff to upstream source” implementation
  • Index pages
  • Setting everything up to my public test instance
  • Testing

Weekly report: week 33

Tuesday, August 21st, 2007

Last week introduced a lot of code cleanups, some of which will also hopefully save some memory. I also made a fix for one problem we had with my Fedora test environment, but I’m not sure if it’ll go to Moin main branch, as it seems Moin was meant to give up and crash at that point. Then I implemented a man/info page exclusion feature, which can be used to avoid processing files that are known to cause problems with doclifter. I also did some base work for this week’s new features.

Sadly last week was a bit unproductive for me, I did some code on Monday, then Tuesday was more about planning on what should be done with the storage/editing format. I decided to use DocBook for now and implement all of the other features around it and then see if there’s time to do the DocBook -> wiki markup -> DocBook conversions. This seems to be OK with my mentor too. On Wednesday I had a terrible headache for the whole day, probably caused by the hot weather we had, so I couldn’t work at all. Then on Thursday and Friday I was back on coding, but the weekend was busy with other things.

Gladly I took back some of the missed coding hours yesterday with a near 12-hour coding spree 😉 I implemented a ManSource action, which produces man source from the DocBook XML that’s in the wiki and gives the man file to the user. Info support will also happen soon.

This week I’m going to implement an action for getting a diff from the wiki compared to upstream man/info source. Then there’s an interesting thing missing: Moin can’t display lists in info pages converted to DocBook, so I guess I should try to add support for those to the XSLT stylesheets Moin uses for the display of HTML from DocBook XML.

After those are done, I should have all the features completed except the wiki markup stuff. I’m starting to think that I should maybe spend these two weeks I have left of Summercode for adding new features and not spending so much time on testing. After Summercode is over and I can also accept patches from the community, we could do some testing in the community and fix bugs together. The only thing I actually have doubts about is (still) the updates handling. Sometimes it seems like it doesn’t notice all non-updated packages and does useless work…

But I guess that’s it for this week, back to coding now 🙂

Weekly report: week 32

Tuesday, August 14th, 2007

Last week I implemented support for translated man pages, fixed yet more bugs and did some serious code cleanups and refactoring as suggested by Thomas Waldmann and pylint. I got a public test wiki setup from the Fedora Infrastructure project, we spent about a day setting it up with Paulo Santos, also with some help from Mike McGrath, thanks guys 🙂

It took such a long time because the Moin instance runs as the “apache” user and my import script runs as the user you happen to be on the console, so permissions have to be set up so that both apache and the script have enough rights for the wiki data directory. Right now there’s some problem with the wiki installation (again) so I won’t give a link yet, especially because Paulo is on a holiday, we’ll probably get it fixed once he comes back.

Then when testing my script there, I hit a serious doclifter problem. With one man page, libbind-getaddrinfo.3, my script seemed to go crazy and take up all the memory on the server. I then tested it locally, same thing here. At first I thought all of this was caused by my script or by Moin and I spent hours trying to debug them. When I eventually found nothing, I realized it is a doclifter problem / bug. So I had to implement filtering in my script, now you can pass it a filename where the file has the names of the files that doclifter can’t handle and my script will then skip those files. Also I noticed that some packages have even 5-6 meg man files, which took about 2 hours to handle, so I had to set up my script so that it skips any files that are bigger than 1MB.

Wiki storage format and editing

I have done some testing and research on the Moin 1.6 DocBook branch from last year’s GSoC. It seems that I can’t use it as I originally planned, since it has no support for the refentry parts of DocBook. Refentry is a DocBook element for saving unix man pages and that’s what doclifter makes. So I don’t have a direct way of converting the DocBook XML to Moin wiki pages. I could probably try to enhance the XSLT stylesheets that do DocBook to Moin conversions. That way we would have man/info pages in wiki markup. But it would probably be way more difficult to do Moin wiki page -> DocBook XML conversions so that there would be no information loss.

As mentioned, DocBook has elements especially meant for man pages, so man -> DocBook -> man can be done with little if any information loss. But wiki markup has no such elements, so man -> wiki -> man, even with DocBook as an intermediate format, can easily cause a lot of information loss.

With that in mind, here’s my suggestion: We have about three weeks of Summercode Finland left, so I think I should leave DocBook as the storage format and concentrate on exporting changes / patches from the wiki against upstream man/info files. That way we would hopefully have the ability to edit man/info pages in a wiki and send patches from those edits upstream. The edits would have to be made in DocBook XML, which is probably not as user friendly as the wiki markup, but the basic idea / framework would be there. Then if it seems possible and someone with more XSLT/XML/DocBook experience than me is interested to help, DocBook refentry -> wiki -> DocBook refentry conversions could be added later.

Readers, what do you think?

Weekly report: week 31, bugs, connection troubles, Assembly

Monday, August 6th, 2007

Last week didn’t go actually according to my plans, but I did get some major improvements done. I improved repository metadata handling a lot, the code is much cleaner and should also work better now. I did a great deal of testing on updates handling, it seems to be working now.

Then I hit two serious problems with MoinMoin: XML-RPC PutPage and path problems. For some reason the MM server process and the man/info importer process went into some kind of deadlock at random times when running the import. The server was waiting on accept() and the importer on recv(). I tried to do some debugging etc. but I never figured out exactly what was wrong. So I decided to port my importer to use the PageEditor class in Moin. That was a big change, but I’m happy with the result. This also solved the other problems I had with XML-RPC, mainly the mysterious idle times when the importing kind of stalled for 30 seconds per every page import. I suspect all these things have something to do with network/socket stuff, but I just don’t have the time to start debugging all this when I have more important things to implement here…

So I gained speed, but I also lost something when getting rid of XML-RPC. Mainly I lost the ability to run the importer and all the man -> DocBook XML etc. conversions on a different host than the actual wiki. But since a single man page import now takes about 0.7 seconds and it took about 30 seconds with XML-RPC, it’s all worth it.

When doing the porting to PageEditor, I kept having some really weird problems with python import clauses. Simply, many of them didn’t work. I spent about a day trying to find out what was wrong and I eventually even found the reason: A relative path was added to sys.path which caused all the problems, since I had a bit of a different setup than the default. So I fixed it with adding an absolute path instead, which took something like maybe 20 characters of python, after one day of work 😀

In Friday I travelled from my parent’s place to Helsinki, since our student organization visited Assembly. That was fun, but I had no Internet access at all from my student apartment at Helsinki during the whole weekend, so any coding I could do was for a couple of hours at Assembly. Thanks a lot Sonera! Even with flaky Internet connection, I could work for about 40 hours last week. Btw, iirc, the 4k intro at Assembly was won with Python 🙂

This week I’ll probably have to update my blog, then I’ll do some testing with real RPM repositories now that the importer is ported to PageEditor. After all that I’ll hopefully finally get to working with the DocBook branch. Looking forward to that.