Monthly Archives: February 2008

Israeli government stops l10n funds

Quoting an announcement by Jonathan Ben Avraham from Tk Open Systems Ltd to the Israeli malling list:

The Hebrew OpenOffice project at will close for an indefinite recess at the end of February 2008.

As of this date I do not have any further information regarding the possible resumption of the project. A senior figure in the MoF has recently indicated an interest in continuing MoF support but that approval for funding, if at all, might take several months.

During the last year there was an effort to push many bug fixes to upstream. Fixes not accepted upstream appeared in the a releases made by Tk Open Systems Ltd at

I was very sorry to read Jonathan’s announcement as I enjoy the results of the l10n project on a daily basis. I hope to see the government decide to continue the support to make sure an alternative to proprietary software exists, and hopefully making it a de facto standard in Israel in the future.


Filed under

FOSDEM 2008 and the art of Juggling

People have different methods to handle the overwhelming amount of lecture and events. Some just stick to one or two rooms and hear all the related issues, some goes by topic (which might be presented in different places) and I prefer to try and juggle between the lectures and try to have it all.

I’ve planned the lectures I’d like to go to, always keeping an alternative in case the first one isn’t interesting enough for me. I left some lectures early to get to other lectures (usually leaving during the Q&A parts). And some lectures even required me to arrive a bit earlier just to get a seat (especially important if you intend to stay for a few lectures in a row).

While rushing back and forth between rooms, I’ve tried to find I have questions for and people I’m interested to talk with. Moving enough at the campus usually means you’ll eventually find them.

The only problem with the whole process is that it’s consuming a lot of effort and energy during these two days, and I’m feeling exhusted by the end of FOSDEM. But the productivity of talking so many people face to face and getting new information from the lectures makes it all worthwhile.

So my advise is to try and use FOSDEM to expend your horizons instead of going to these familiar talks about stuff you probably already know enough,

    1 Comment

    Filed under FOSDEM

    The 2nd Debian bug triage

    In 24 hours 21% of the triage is already done due to an amazing responsiveness from Debian’s users.

    From the total of 285 bugs targeted by the triage, 35 were closed and 27 were reproduced. Another 20 bugs are in my processing queue.

    With today’s result the total bug count for in Debian crossed the 300 outstanding bugs mark. I hope to lower it to the area of 200 by the end of this triage.

    I must say most users were very happy to see their bugs’ get some attention, and some were really happy to see their bug was already fixed. I got a few mails with very warm words about the triage, in debian and the project in general.

    Getting this feedback from users is one of the things that motivates me to keep and contribute to Debian in general, and to do bug triages in particular.

    One issue I noticed is that some of our users don’t know how to close bug reports. While it’s more important they’ll know how to report bugs than how to close them, it’s a good idea to refer them to “Closing bug reports” on Developers’ information regarding the bug processing system.


    Filed under Debian GNU/Linux,, QA stuff bug triage

    Lior: “My name is Lior, and it has been 6 months since my last bug triage.”

    Support group: “we love you Lior…”

    While I was thinking of doing another bug triage for version 2.2.1, version 2.3.1 had already entered testing. Meaning the versions in testing/unstable are very similar. This also means users can easily test a fairly recent version of without running unstable…

    So, I’m glad to announce the beginning of (my) 2nd bug triage. This triage targets 285 bugs out of 330 open bugs. The selected bug are ones which were reported against versions lower the 2.3.1 or have no version information at all.

    The goal of the triage isn’t to close as much bugs as possible, but to get all the bugs updated with recent version. Hoping “not relevant any more” will be the answer for most pings. Last time about 1/3 of the bugs were reported as already fixed / not relevant any more.

    For those of you who will get one of my pings, please don’t forget to send you current version info.

    I know some of you don’t necessary agree with this method for closing bugs, as it allegedly puts the burden of testing and updating bug information on the users/reporter than upstream.

    While I partially agree, I don’t see how can teams with so much bugs can handle all the bugs themselves without having someone doing a full time job on this issue (any volunteers ?).

    People wish to review the progress of the triage (or even help…) can check the triage bugs list.


    Seems I was too slow with this triage, version 2.4.0~rc1 is already in unstable…

    p.s. 2

    It’s been only 4 moths since my last triage…


    Filed under Debian GNU/Linux,, QA stuff

    The benefits of working with GPL drivers

    For the last few day I’m having problem with the tg3 driver for Broadcom’s NetXtreme Ethernet NIC on an IBM System x3850 machine with RHEL4 update 4.

    The problem was that the tg3 driver recognizes only one NIC and ignores the other, although lspci / lshw can show there are two on board NICs. The weird thing is that I couldn’t find reference to such a problem on google.

    IBM’s technical people suggested that I should use an updated driver, a change I’m usually reluctant to do, as some hardware requires proprietary drivers which come as a “black box”. But this time, the driver is licensed under the GPL and is also available in latest kernel releases.

    IBM provides a set of pre-built RPMs for RHEL4, but it only covers old updates for RHEL (which also represent minor changes to the kernel installed). With this set IBM also provides a source RPM to build the module yourself. That was easy enough to do, just install rpmbuild, the right kernel development package (usually kernel-`uname -`-devel), install the source RPM and build the custom RPM for your kernel.

    I fail to understand why IBM also provides a few more scripts and tools to build the rpm and install the pre-built ones. Every system administrator should be comfortable with using RPMs directly instead of using scripts to run a lot of other stuff before the actual RPM commands.

    The updated driver did solve the problem, and I finally can use both NICs.

    Having IBM’s stuff is nice, but I wanted to know what options do people have, without using their wrapping over the original driver. So I went to see what Broadcom have to offer.

    On their FAQ, Broadcom declare:

    To better support users, Broadcom has been actively supporting, maintaining, and testing the in-kernel Linux drivers for the NetXtreme, NetXtreme II, NetLink and 4401 product lines.

    I found that Broadcom offer an updated version for the tg3 driver (comparing to RHEL4 update 4) on their NetXtreme Server Drivers page. Clicking the download page showed this message:

    The Broadcom Linux Ethernet drivers are licensed under the GNU GPL. The full text of the license is available in the driver archive.

    That’s must be a good start (:

    Broadcom doesn’t give you pre-built RPMs, but they do provide a source RPM to ease your job. I actually preferred their simple spec file over IBM’s complex spec file.

    To conclude, having GPL drivers enable system administrator to build the drivers specifically for their system (operating system, distribution and kernel version), and lower the pressure (or necessity) for vendors to offer pre-built packages for each possible combination.

    1 Comment

    Filed under Proud to use free software, Red Hat Enterprise Linux

    Commercial companies and (the lack of) changelogs

    As a Debian maintainer, I got a habit of reading the changelog of packages I install or want/need to upgrade. My problems begin with these packages come from some commercial compay, as most of them don’t log their changes.

    Oracle’s OCFS2 RPMs have this “useful” changelog:

    * Fri Jun 23 2006 Sunil Mushran
    – Add largesmp

    * Sun Jan 25 2004 Manish Singh
    – Initial rpm spec file


    * Fri Jan 28 2005 Manish Singh
    – Add ocfs2console

    * Sat Jan 22 2005 Manish Singh
    – Initial rpm spec

    That’s a start, but not very informative one. The packages were last updated on November 2007, the changelog doesn’t mention the various changes done on the packages.

    Skype’s Etch deb file has this changeog entry:

    skype ( extra; urgency=low

    * Added Changelog for compliance with debian rules.

    — Skype Technologies <> Wed, 10 Aug 2005 17:50:14 +0300

    When I read that my reaction was “gee, thanks for the changlog”. I’m glad companies recognize the debian policy and comply to it, but let’s not forget the files is there to have some substance. Having a empty (or a place holder) changelog isn’t the real essence of the debian policy rule.

    These are just two examples I encountered, but these are also the companies who actually wrote a changlog. I see a lot of packages which have an empty changelog.

    I know companies work differently from community projects, what I fail to understand why don’t provide more information about their products. They all have “a support matrix”, tons of documentation and such, but when I want to know if I can install the new package easily – I don’t have this info, and usually the documentation doesn’t mention these technical changes.

    So, my message for the commercial companies: you have a lot to learn from community projects, especially for those companies what want to be a part of the free software world. We (the community) usually have a high standards and we expect you to keep them.

    I’m sure you’ll also benifit from these standards, if you’re not already enjoying it.


    Filed under Proprietary software