Wednesday, September 28, 2005
phew, 12 RPM updates yesterday, mostly new networking-related stuff I currently need at work. I think that 12 packages on one day is my personal record. If you want to see some advanced SUSE Linux integration work in RPMs, check out the plugdaemon, http-replicator and plb (pure loadbalancer) source packages. SUSE Linux offers a nice convention and way of editing sysconfig files (e.g. /etc/sysconfig/network/plugdaemon) to set various options and parameters, mostly for init scripts (e.g. /etc/init.d/plugdaemon). In the 2 first packages mentioned above (plugdaemon and http-replicator), the init scripts have to pass all the configuration options using command-line arguments (those 2 daemons have no configuration file on their own). Fortunately, with SUSE Linux, one can create such a sysconfig file, put various variables in there (with description, default value, type filtering) that one can edit (either via YaST2 or your favourite text editor) and the init scripts read those variables to define what parameters and switches to pass to the daemon binaries at startup. There's some trickery involved in doing that but fortunately (e.g. using fillup), it's well documented by Novell. I also decided to package libevent 1.1a (the package being named "libevent-1.1_0.1") as it features some minor reliability fixes by the author (Niels Provos). The issue here was that SUSE Linux 10.0 RC1 already ships libevent-1.1 and that the author chose to name the shared libraries libevent-1.1a.so.*. Obviously it's a great idea because this way, you're able to install several versions of the shared libraries side-by-side on your system, but unfortunately that doesn't work on SUSE Linux because the SUSE packagers chose to include the devel stuff in the libevent package instead of splitting it up in libevent and libevent-devel (I do have my gripes about that, but it's getting better), which means that you cannot have several versions of the library installed at the same time on your system because of file conflicts on the other files, e.g. /usr/include/event.h and /usr/lib/libevent.so. Packaging libevent 1.1a would mean breaking packages and applications that use the libevent-1.1.so.* files from the libevent-1.1 package, so I added symbolic links libevent-1.1.so.* that point to libevent-1.1a.so.*. Little trick here: you also have to explicitely mention the symbolically linked shared libraries in the spec file as Provides:, as rpmbuild isn't picking those up automatically. Request to other packagers out there: always (and I really mean always) split up packages into foo and foo-devel, even if it's just for a few bytes.
Tuesday, September 27, 2005
Now, how is that one qualifying ? :) "Suse is a commercial version of Slackware; and has also many Slakware backward compatibility liabilities" "Mandriva is Mandrake with apt-get addition" "In the old days, you start with Linux official release then add KDE and Gnome plus Mozilla for desktop. Its sound pretty safe." "Each linux kernel versions have bugs; unless you confine to Eclipse. So, full blown Linux such as AIX 5L(IBM) use Eclipse." Well, two options here, either he's the type of guy who has no clue whatsoever (and in this case, I really mean none) but has to give his pseudo-enlightened opinion about everything (we all know some of those), or he's the type of guy who smokes 2g of sativa before turning on his computer. Must be one of the two. Really. Or maybe it's the next generation of Eliza chatter bots. Not bad for a bot. Braindead for a human. :-)
Saturday, September 10, 2005
» openSUSE contributed package aggregator
One of the major issues with contributed packages for SUSE Linux seems to have been that they are difficult to find, and that only part of the SUSE users are actually aware of Packman, my repository and the others. The other, in my opinion, is that we packagers don't communicate much and we sometimes end up with having the same package in several repositories, sometimes even conflicting and incompatible (e.g. because of the naming). I have some of those myself ;) To address the first problem, there are a couple of solutions that could work: » centralize all the contributed packages inside a same infrastructure, e.g. the openSUSE site » augment YaST2's package management module to have it fetch a list of contributor package repositories from a central location (opensuse.org would be my first guess) on the internet and propose to easily add some (or all) of them to the list of installation sources used by YaST2 » keep decentralized package repositories but aggregate them in some way on the openSUSE.org website A centralized site for all the packages is not feasible, as already shortly explained on the openSUSE mailing-list by Christoph Thiel, Robert Schiele and Christoph again. The 2nd and 3rd points share the same idea of keeping decentralized package repositories (more or less like now, although we need a lot more collaboration and communication to avoid incompatibilities, projects packaged several times, etc...) but aggregating them in some way, be it on openSUSE.org. More ideas on that later, but maybe having a kde-apps.org-like web interface (maybe even inside YaST2 ?), as Marco Maske has proposed, is an option as far as user-friendlyness is concerned. Nevertheless, as package managers and advanced users, we also need tools to see whether a piece of software is already packaged, where, in what version, in what state, see what packages are unmaintained, provide them on all supported architectures, etc...
» More thoughts on a "Debian-like" package classification for openSUSE
A few people (including me) have started to discuss on the openSUSE mailing-list what we could do to embrace packages that are made by contributors (like Packman, James Ogley, a lot of smaller "suser-*" repositories on gwdg.de, myself and others) into the openSUSE initiative. There's no consensus yet, we're still far from having discussed enough about it, mostly because we need to have quite a few people from SUSE involved into the thread and they're really busy doing a great job releasing SUSE Linux 10.0. One of the options I have proposed is to have a model where [YaST2/apt/yum] repositories are categorized into 3 levels of "quality" or "stability", namely stable, unstable and testing. Does that remind you of something ? Indeed, that's pretty much known as "the Debian release system" and there has been quite some critics against it. James Ogley has been making the same proposition (more or less) and added "I don't think we should allow ourselves to have a Debian-like interval between releases just because we may adopt a similar model of distro development, the current frequency is about right" I couldn't agree more. What James and I are talking about is not adopting the Debian release concept, we're only talking about that one idea. Note that (AFAICR) it was originally used by BSD. Now, what's wrong with Debian and why are a few people being allergic to that idea ? I think it's mostly related to the fact that although Debian is a brilliant distribution within its scope and goals, it has been having quite a few issues with their release cycles during the last 2-3 years, with major distribution releases for the "stable" branch taking far too much time to be decided and roadmapped, leaving Debian users for very long with a completely outdated "stable" release. Note that this has at least had the advantage of pushing a new distribution out of the ground, namely Ubuntu (and it's derivates, like Kubuntu), that are specifically adressing two of Debian's major "shortcomings" (they only are in a certain context, which is end-users in this case): faster release cycles (as you can read on the Ubuntu website, they make major releases every 6 months) and stress user-friendlyness for the installation. That being said, what James and I have been proposing has nothing to do with that, and it's definately not a consequence of adopting a stable/unstable/testing categorization of contributed packages. First of all, that model doesn't apply in the same way as with Debian, not by any means: the SUSE Linux distribution as produced by the SUSE staff is to be considered a "core distribution" that's absolutely not subject to that categorization. From the openSUSE community's point-of-view, it gives us a strong, stable foundation with 2 or 3 releases every year we can build our specialized distributions or contributed package repositories upon. That categorization idea actually applies to two different criterias: » quality of the packages: making good RPMs is not an easy task and requires a lot of experience, both with RPM itself as with the distribution one is making the packages for (SUSE Linux, in this case) » stability of the package itself: I've found myself quite often into a position where I chose not to package a piece of software because it was still in alpha/beta stage or even worse, it was a CVS snapshot, and I don't want to push a package as an update to hundreds of users who, full of confidence in the level of quality I think I've been able to achieve up to now, pull that newer package and end up with a non-working application - and I suppose you can see how a stable/unstable/testing categorization would apply here All of this just being a summarization of what has already been said on the openSUSE mailing-list, I got to think about it again. While I still believe that this categorization system (not necessarely exactly the above, but similar) could prove to be effective, it certainly is not good enough for end-users. They don't necessarely care about stable/unstable, what levels of quality and trust can be expected from a packager, and only partly take interest in whether that piece of software is to be considered to be stable and tested or just another CVS snapshot that might break. I don't have an answer to that, yet, but we should probably "think beyond the Debian model", as Sonja wrote.
Friday, September 09, 2005
On the openSUSE mailing-list, houghi asked for openSUSE banners and web buttons. Since there's nothing there just yet (although it has been forwarded to the SUSE/Novell marketing dept), I have quickly hacked some web buttons: The GIMP .xcf source is available from my site as well (gzipped), enable and disable layers to recreate the various web buttons. At the same time, I made a little FOSDEM web button:
I really had a good laugh reading Eric Raymond's reply, couldn't have said it better. Damn, how am I going to clean the coffee off my keyboard ? Hmm.. what could their other "objectives" be on that list ? Linus, Alan Cox, Richard Stallman ? Nah, I don't think that's some strategy of theirs, it's hopeless. Guess it was rather a pretty good joke that HR guy was put into.
Thursday, September 08, 2005
James says: "The major gtk2 upgrade was very important between betas 2 and 3, and would have had API/ABI backwards compatibility". I have absolutely no problem with the 1st part, I mean.. hey, it's a beta ;) Great to include the latest available version. But what was actually breaking packages built on beta2 was the major cairo upgrade, then shipping libcairo.so.2 instead of libcairo.so.1. Personally I'm really not convinced about GNOMEs backwards compatibility. I've seen too many users send me too many mails because of major issues they had after upgrading some GTK or GNOME package. Take it or leave it, but KDE proves to be much more stable regarding that, at least from my humble experience. My major gripe with GTK and GNOME is the naming of the libraries. Why on earth is the shared library in gtk2-2.6.x called libgtk-x11-2.0.so.. and the shared library in gtk2-2.4.x called... you bet.. libgtk-x11-2.0.so as well ? 1) either it's supposed to version the ABI, and then it would only make sense if GTK 2.8.0 was ABI-compatible with GTK 2.0.0 (are you kidding me ? ;)) 2) or.. well.. a wrong decision that doesn't make any sense ? Because of that, it's not possible to install e.g. GTK 2.4.0 and GTK 2.8.0 side-by-side. Almost every file that's part of GTK and GNOME libraries is versioned (pkgconfig, shared libs, include directories, ...), but they're all versioned with -2.0. I mean, everything is there, technically, to have several GTK and GNOME versions at the same time on one host, it just fails because the GTK/GNOME developers keep calling it "2.0" (instead of 2.0, 2.2, 2.4, ...). Why would someone want to have 2 GTK versions installed at the same time ? Well, I maintain packages for SUSE Linux 10.0, 9.3, 9.2, 9.1 and 9.0. Very often, projects that use GTK and GNOME rely on features only available in the very latest version (often even unstable development versions), and there's just no way I can provide e.g. GIMP 2.3.0 on SUSE Linux 9.2, 9.1 or 9.0. Can anyone enlighten me on the reason for that file/library naming scheme ?
Damian Smith (who's running the suseroot.com website) has started a series of interviews of "visible members of the SUSE community", and he started with me. While I was very pleased to be his first choice, I think this is definately a great idea. Keep up the good work Damian ;)
Wednesday, September 07, 2005
Today, on the openSUSE mailing-list, Otmar Stahl came up with a pretty cool one-liner to import all the GPG signatures of the 3rd party SUSE packagers with APT:
apt-get -o gpg::check=false install rpmkey*That's a very interesting one, as it is a common problem not to have imported the required rpmkey- package before installing RPMs from one's APT repository. Note that it does not affect YaST2 nor y2pmsh as it's currently not verifying RPM signatures.
What is it with the WLAN NIC manufacturers ? Why are they changing their chipsets every few weeks, even shipping exactly the same product but with very different chipsets ? That's especially annoying as less and less chipsets are working on Linux. Prism and Prism2 were working well, but those tend to become quite rare. In the end, I was fed up with ndiswrapper and bought myself 2 wireless NICs that really work on Linux, from Conceptronics (huh? no, never heard of them before either) and they include the ralink chipset. There are native Linux drivers included with every (very) recent distribution: rt2500. And the driver is even GPL. And they are working really well. What do we want more ? ;) Note that the rt2500 driver is included in SUSE Linux 9.3 and 10.0, but not in 9.2. I'd also like to warmly recommend this very nice hardware shop: tuxhardware.de. If you're living in Germany, consider buying your hardware over there, as they are exclusively supporting Linux and only sell stuff that actually works on our favourite operating system. Yay! I've been looking for a shop like that for quite some time ;)
Tuesday, September 06, 2005
Stumbled on KeyJNote today after seeing it on freshmeat.net. It's a presentation tool written in Python and that uses OpenGL, GhostScript and SDL, with very nice and useful effects. Actually you just need to export your presentation to PDF and off you go. It's really impressive, wow :) (and, of course, it works on Linux and is licensed under the GPL)