Monday, April 28, 2008
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.
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 :)
Labels: opensuse
» 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.
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:
If you want to remove a key from the RPM keyring, take the first field from the list above (represented by HASH below) and (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.
rpm -qa --nodigest --nosignature \
--qf '%{VERSION}-%{RELEASE} %{SUMMARY}\n' \
gpg-pubkey\* \
| sed 's/ gpg(/ /;s/)$//'
rpm -e gpg-pubkey-HASH
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: EU, opensource, petition
Sunday, April 13, 2008
» Countdown to 11.0
- normal version (256x256 px):
<a href="http://en.opensuse.org/OpenSUSE_11.0"><img src="http://counter.opensuse.org/11.0/medium"/></a>
- small version (130x130 px):
<a href="http://en.opensuse.org/OpenSUSE_11.0"><img src="http://counter.opensuse.org/11.0/small"/></a>
- large version (400x400 px):
<a href="http://en.opensuse.org/OpenSUSE_11.0"><img src="http://counter.opensuse.org/11.0/large"/></a>
- 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
Labels: opensuse
Saturday, April 12, 2008
» Amarok 1.4.9.1
![](http://opensuse-community.org/images/e/ea/Amarok_128x128.png)
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: amarok-1.4.9.1-100.pm.1.x86_64 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 [http://packman.links2linux.de]taglib-1.5-0.pm.1.x86_64
Solution 2: do not install amarok-1.4.9.1-100.pm.1.x86_64
Choose the number, (s)kip, (r)etry or (c)ancel>
taglib
1.4 with Packman's taglib
1.5
The reason is that Amarok 1.4.9.1 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.
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 opensuse.org 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 countdown.opensuse.org
(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.Labels: opensuse
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 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 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):Note that normally, I'd say that upgrading
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 \
http://download.opensuse.org/.../11.0/.../\
<ARCH>/rpm-4.4.2-<RELEASE>.<ARCH>.rpm
:)
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
zypper install rpm
zypper dist-upgrade
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...Labels: opensuse
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:
2) Start and stop the PostgreSQL server to populate its
3) Enable the 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
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 4.2) open the PostgreSQL server listen port 4.3)Apply the above mentioned firewall modifications:
5) Restart the PostgreSQL server to apply all settings we've made above (as root):
zypper install postgresql-server
data
directory, still as root:rcpostgresql start && rcpostgresql stop
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 127.0.0.1/32 md5
host all all ::1/128 md5
EOF
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 0.0.0.0/0 md5" >> ~postgres/data/pg_hba.conf
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):POSTGRES_OPTIONS="-i"
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"
rcSuSEfirewall2 reload
rcpostgresql restart
Labels: opensuse, postgresql