Monday, April 28, 2008

» Packman: deprecating 10.0

As openSUSE 10.0 has reached end of life in November last year, we will be removing all 10.0 packages from the Packman repository end of this week. If you want to keep them aside, make sure to download a copy before.

Labels: ,

Saturday, April 26, 2008

» qtcurve-gtk2 was broken in KDE:Backports

The repository KDE:Backports was containing a package qtcurve-gtk2-0.59.0-3.1 that caused every single GTK2 application to crash on a buffer overflow (detected by glibc), including all of GNOME, firefox, thunderbird, etc... Thanks to a few bugreports on #suse, Dirk Müller quickly came up with a patch, fixed and rebuilt the package in the above mentioned repository (as well as in Factory). Of course, the patch was also sent to upstream. So just in case you run into that problem, just upgrade qtcurve-gtk2 to its latest version in KDE:Backports. And thanks to Dirk :)


» Packman: starting to build for 11.0

We've started building against openSUSE 11.0 beta 1 a few days ago. There are still some larger bits missing, such as libxine1, but we already have quite a lot of packages on 11.0 already.

Labels: ,

Friday, April 25, 2008

» List RPM keys you trust

Here's how to get a list of the GPG keys you have (and hence trust) in RPM's keyring:
rpm -qa --nodigest --nosignature \ --qf '%{VERSION}-%{RELEASE} %{SUMMARY}\n' \ gpg-pubkey\* \ | sed 's/ gpg(/ /;s/)$//'
If you want to remove a key from the RPM keyring, take the first field from the list above (represented by HASH below) and
rpm -e gpg-pubkey-HASH
(the above has obviously to be performed as root) As blogged by Duncan, Ladislav added a window in openSUSE 11.0's YaST2 to manage those keys in a much more user-friendly way.

Labels: ,

Saturday, April 19, 2008

» Petition against software lock-in in the EU

A petition worth signing. It points out to two major issues where the EU Parliament using Microsoft software conflicts with the Treaty of the European Union: forcing people into using Microsoft software (e.g. Windows Media Player) to access content that is supposedly accessible to the widest audience, and not enabling open competition. Concise and to the point. If not open source software, the EU must at the very least mandate and enforce the use of open standards. Check out the complete text of the petition.

Labels: , ,

Sunday, April 13, 2008

» Countdown to 11.0

So here it is, finally, the localized server-side rendered countdown to 11.0 release. It automatically localizes depending on the preferred language as configured in the user's browser, with support for the following languages: english, german, czech, french, danish, russian, polish, dutch, finnish, spanish, italian, greek, swedish, croatian, norwegian, portuguese, hungarian, romanian (thanks a lot to everyone who contributed those translations). And as it is rendered on the server, it always points to the right number of remaining days before 11.0 release (diffed against 12:00 CET). And thanks again to jimmac for the great artwork. Font is DejaVu Sans.
Here is how to use it on your website/blog/whatever:
  • normal version (256x256 px):
    <a href=""><img src=""/></a>
  • small version (130x130 px):
    <a href=""><img src=""/></a>
  • large version (400x400 px):
    <a href=""><img src=""/></a>
Oh and we still have to work on a few things:
  • singular forms (e.g. czech) and translations for various languages once the remaining day countdown comes to 1
  • come up with a message to render on day 0
  • come up with a message to render once 11.0 has been released
Last but not least, many thanks to darix for helping and doing the hosting work.


Saturday, April 12, 2008

» Amarok

Amarok is going to be released today, and is already available in the Packman repository (including for ppc thanks to Peter Czanik). Most notably, it fixes the Amazon cover downloading which was broken since a few weeks because Amazon changed their online API. It requires taglib 1.5 (openSUSE up to 10.3 ships with 1.4), which should be API and ABI compatible (which means that upgrading to it is safe), but if you run into problems with other applications than Amarok that use taglib, let me know. UPDATE: if you use zypper or yast and see the following message:
Problem: requires taglib >= 1.5, but none of the providers can be installed Solution 1: vendor change of [SUSE LINUX Products GmbH, Nuernberg, Germany]taglib-1.4-114.x86_64 to [] Solution 2: do not install Choose the number, (s)kip, (r)etry or (c)ancel>
then go for "Solution 1" and upgrade openSUSE's taglib 1.4 with Packman's taglib 1.5 The reason is that Amarok now requires having taglib >= 1.5, and openSUSE only ships 1.4 (as 1.5 has been released after openSUSE 10.3). zypper/yast2 don't do it automatically because a "vendor" change (origin of the package) is considered to be something the end-user must do explicitly, not something that may happen automagically. Note that I heavily disagree with that behaviour but well.

Labels: ,

Sunday, April 06, 2008

» 11.0 countdown banner

Aside many other things, I'm currently hacking on a server-side "countdown to 11.0" banner rendering script. It all started with a post by Pavol Rusnak about Ubuntu providing a countdown picture on their website. It is indeed a good idea, and a few people decided to have a shot at it (for openSUSE, that is ;)). Not to discard what other people did (there are a few nice ones, actually), but our local design hero Jakub "jimmac" Steiner made one too and, as always with jimmac, it's brilliant. Now there were a few issues: it is heavily using Javascript to render the text (but sports a nifty fade-in animation thanks to jquery), breaks when people change the font size and isn't localized. The problem with the latter is really that you cannot access the user's preferred language that is sent in HTTP headers by the browser. So I started to hack a version that renders the Javascript code on the server and just "injects" the detected language into the Javascript code. Easy, and works. But then, in order to address the other issues mentioned above, I had a shot at a PHP script that renders the picture on the server. It is already functional, but not public yet as it has to be moved to first (should happen in a very few days). It's pretty well translated (en, de, fr, it, es, da, sv, no, fi, hr, hu, pl, cs, ru, el) and really fast. Also, it's plain PNG and doesn't require any Javascript at all. There's also a smaller version (original one is 256x256, small one is 130x130). Click on the picture on the left to see it rendered in different languages, as well as the large and small versions. If you can provide me with translations, then please send them to me by email: - "n days to go" (or "n days before release", or "only n days left", whatever works best in your language) - a singular version of the above, when n==1, as well as any other variant needed to cover your language (as an example, russian and czech have more than one variant) TODO: - think of what to display when it's day 0 ;) - think of what to display when the release date has passed - have it hosted on (as you might imagine, I'm open to suggestions on the 2 first items above)
So stay tuned, hope I'll have it done real soon.


Saturday, April 05, 2008

» rpm lzma payload and breaking hot upgrade to 11.0

The alpha 3 version of the upcoming openSUSE 11.0 introduced using lzma to compress the package payload (= the actual files in the package) instead of bzip2. This means that packages will be slightly smaller (seems like and will be decompressed faster. Great stuff. Coolo posted some interesting numbers about it, clearly a significant benefit. The only issue with it is that it breaks RPM built without lzma support, in the sense that you cannot install/decompress RPM packages that have their payload compressed with lzma with an RPM runtime (I mean the rpm command and everything that layers on top of it: zypper, yast2, smart, yum, ...) that has been built without lzma support. To clarify: you cannot install RPM packages from openSUSE 11.0 >= alpha 3 on openSUSE < 11.0 alpha 3. While it doesn't sound all that critical for the alpha snapshots, this also means that you cannot do a "hot upgrade" of 10.x to 11.0. With "hot upgrade" I mean an upgrade while the system is running (e.g. using yast2/zypper or smart), as opposed to a "cold upgrade" which is performed by booting from the 11.0 media (CD/DVD) and run the installer in upgrade mode from there. The latter will obviously work and is the only supported+tested method, but nevertheless... I believe there are quite a lot of people who do hot upgrades (e.g. hosted server you don't have physical access to). Now it might be very tricky to solve from a technical point of view. The solution itself isn't all that tough to implement (although not as trivial as it might sound): 10.3's package management solver would have to prioritise the rpm package, upgrading that one first when an upgrade is available, before performing any other upgrade. The problem is rather from an infrastructure point-of-view, as fixing the above mentioned problem (not being to hot-upgrade to 11.0) would mean patching the package solver of 10.3 (and possibly 10.2, as 10.1 is going EOL soon, although people might want to upgrade from the EOL'd 10.1 to 11.0). And patching means releasing new packages -- sounds trivial but it isn't, as it involves QA and a whole lot of a process. So if we can't have it done by code, it has to be done by information. The workaround isn't exactly that complex, one will just have to
rpm --upgrade -vh \\ <ARCH>/rpm-4.4.2-<RELEASE>.<ARCH>.rpm
before doing the hot upgrade. The problem, at least in my opinion, lies in communicating that piece of information properly to anyone who will perform a hot upgrade. At the very least, it should be mentioned in the 11.0 release announcements. And I hope that trying to make a little noise around it now will spread sufficiently for people to know about it when 11.0 hits the fans :) What's currently bugging me in the corresponding bug and thread on opensuse-packaging is that it doesn't seem to be important to address it, as "cold upgrade is the only supported method". As explained above, if it isn't reasonably feasible from a technical (or human resources) point-of-view, then fine, that of course should be acceptable to everyone. But resorting to saying it isn't supported isn't all that great... IMHO. I might be wrong though. Is anyone actually using hot upgrade or is the importance of it overweighted in my mind ? On a side note, hot upgrade is something Debian has always been exceptionally good at (arguably, their release cycle is also exceptionally... slow, but that's ok, it's on purpose) and I'm afraid we've always been rather bad at it. It cannot realistically be supported the same way as cold upgrades, but that doesn't mean it has to be made impossible (which isn't the case, see workaround above) or unnecessarily hard in the first place either. And if we want it to improve, we need people to test that scenario when alpha and beta releases are being published and file bugs when needed. Mind you, the last thing I'm saying is that Novell should or must support that upgrade method, but the community could do by specifically testing and filing bugs using hot upgrading. EDIT: Actually, instead of the rpm --upgrade command above, the following would obviously be sufficient (and easier), after changing the list of repositories to 11.0:
zypper in rpm
Which brings us to the following two lines that, in theory, should be sufficient to perform the dist upgrade (after changing the repository URLs to 11.0's):
zypper install rpm zypper dist-upgrade
Note that normally, I'd say that upgrading libzypp and zypper before performing dist-upgrade would be a good idea, but it isn't when coming from 10.3 or below, as 11.0's libzypp is API/ABI incompatible, which means that it's likely to remove quite a few YaST2 modules instead of upgrading those depending packages. And thanks to Jan Claeys to point me to the following python script (and GTK or KDE frontend) used by Ubuntu to perform dist upgrades: update-manager. An interesting approach, and at first sight, a well written piece of software that includes automated tests (in chroot and qemu). No surprise here, it makes sure to upgrade the package management toolchain first (dpkg and apt for Ubuntu -- would be rpm, libzypp, zypper and possibly a few YaST2 modules for openSUSE). But it does include other interesting information (and rules), such as packages to keep at all costs, blacklisted packages, etc...


Wednesday, April 02, 2008

» PostgreSQL on openSUSE

PostgreSQL comes with pretty secure and locked down settings when installed. Here's a quick HOWTO to install the PostgreSQL database server on openSUSE and enable TCP/IP connections with user authentication. 1) Install the package postgresql-server which is in the OSS repository and ships with openSUSE media, here from a shell as root:
zypper install postgresql-server
2) Start and stop the PostgreSQL server to populate its data directory, still as root:
rcpostgresql start && rcpostgresql stop
3) Enable the md5 authentication method using the following commands as root:
su - postgres cat<<EOF >>~postgres/data/pg_hba.conf local all all md5 host all all md5 host all all ::1/128 md5 EOF
3.1) OPTIONAL: Note that if you also want to allow connections from other hosts, proceed as follows, still being in the same shell as above, as the user postgres (this example is to allow connections from all hosts -- you might want to restrict that for security reasons, as explained in the PostgreSQL documentation):
echo "host all all md5" >> ~postgres/data/pg_hba.conf
4) OPTIONAL: If you want to allow connections from any host then you must also do the following steps, from a shell as root (if you're still in the shell from above as user postgres, just type the command exit to return to its parent root shell): 4.1) make the PostgreSQL server listen on all network interfaces (it only listens on the loopback/localhost interface by default), by setting the variable POSTGRES_OPTIONS to -i in /etc/sysconfig/postgresql, using your preferred text editor (still from a shell as root):
4.2) open the PostgreSQL server listen port 5432 in the firewall, by adding the service name postgresql in the variable FW_SERVICES_ACCEPT_EXT in /etc/sysconfig/SuSEfirewall2 using your preferred text editor as root, e.g. like this:
FW_SERVICES_EXT_TCP="http https ftp postgresql"
4.3)Apply the above mentioned firewall modifications:
rcSuSEfirewall2 reload
5) Restart the PostgreSQL server to apply all settings we've made above (as root):
rcpostgresql restart

Labels: ,