Pavol Rusnak #cypherpunk #hacker #openhw #privacy #bitcoin #newmediaart

RPM Summit at the openSUSE Conference 2009

osc09

I’m sure you all heard about the openSUSE Conference 2009 that took place in September in Nuremberg. Not so many know about the RPM Summit that was a part of the conference during its first two days. Idea to create something like this started at LinuxTag 2009 when Zonker invited Florian to Nuremberg. One thing lead to another and in the end we managed to get several important people into one room (or to join us via conf call) and we kept them there until all problems with RPM and package management in general were solved. Well, not really, there was a lot to discuss and there still is, but you got the point. :-)

And who were our victims^Wexperts? Here’s the list:

We were also joined by others interested in RPM development: Ludwig Nussel, Olaf Dabrunz and Jan Engelhardt. Most of the time we were working through a quite long list of issues we prepared in advance in the wiki and it turned out that there is not much difference in the view on the different topics. I tried to summarize the summit in the following 10 points:

  1. Virtual triggers Triggers on virtual symbols (provides) do not work at the moment. This is considered a bug (or missing feature) and will be fixed.
  2. File triggers Panu is working on file triggers feature. This will help packagers to get rid of a large number of scriptlets (e.g. %post/%postun -p /sbin/ldconfig) in spec files, but he wants to be sure that it doesn’t break anything else. File triggers are already used by Mandriva, but Panu wants to implement them in a different fashion. (See Mandriva wiki for the details about their implementation).
  3. Soft dependencies Soft dependencies keywords that are already used by SUSE (Recommends, Suggests, Supplements, Enhances) will be recognized in the future versions of RPM. RPM will not do anything with them except of storing in the database and reporting to higher levels of package management stack. There is an ongoing discussion whether and how to implement soft dependencies in YUM (they are already implemented in the zypp stack).
  4. Update scriptlets We agreed to introduce two new scriptlets called %preup and %postup. These will be called when updating the package (%preun, %postun, %pre and %post will not be run in this case). This is a way how to fix the broken uninstall scriptlets and one doesn’t have to do the weird if [ "$1" = "0" ]; stuff in the scriptlets anymore to detect whether the operation is upgrade or uninstall.
  5. Scriptlets arguments Package scriptlets will get more information (e.g. NEVRA of the packages) about currently run transaction in environment variables. This will make it easier for scriptlets to handle special situations or to detect more precisely what is happening. (One could for example convert some config files when upgrading from package of version 1.x to 2.x and to leave them intact otherwise).
  6. DeltaRPM DeltaRPM sources will stay in gitorious at the moment. They might appear in RPM upstream git repository later in the future but there is no reasoning for this right now. Jindrich Novy is working on a new diff algorithm, we’ll see if it will be merged into DeltaRPM or replace it completely.
  7. New payload format Currently used format is CPIO but it has a filesize limit of 8 GiB. This is not enough when one tries to distribute very large files, for example appliance images, packaged as RPMs. Developers will need to find a way how to enhance CPIO or try another format soon. TAR is really not an option …
  8. Tilde in version The special character tilde (~) will be available for use in version representing a negative version token. This will simplify complicated rules which abuse the version and the release tags. (For example, using foo-2.5.99.2 instead of the foo-2.6~beta2). There already exists a patch but it needs more test coverage.
  9. Logging and recovery There is a plan to include a transaction log to RPM which will allow recovery after a broken transaction. RPM log could also replace similar features in YUM/zypper and will be more reliable as it would also work from rpm cli.
  10. Easy way to add or remove autogenerated dependencies This feature is wanted but is not implemented yet. Currently this is workarounded by redefining the __find_provides/__find_requires/… in spec file. Example from the open-vm-tools package:
# exclude AMD PCnet32 LANCE pci.id from Supplements list [bnc#397554]
%define __find_supplements sh -c '/usr/lib/rpm/find-supplements %{name} | grep -v pci:v00001022d00002000'

That’s it! I had a great time during the conference and was really happy to see the synergy between the developers, even though they are working for two competing companies. In case you have any questions feel free to join us on Freenode IRC channel #rpm.org or use the appropriate mailing list.

SVG-edit 2.3 is out!

During the last weekend we released version 2.3 of our in-browser SVG editor called SVG-edit. If I was a DnB producer I would call this a “massive” release, because it includes lots of new features. :-) To name some of them:

  • Rotate tool
  • Polygon/Polyline Editing
  • Linear Gradient Picking
  • View and Edit Source
  • Clone tool
  • Align tool
  • Firefox extension
  • Opera widget

Jeff Schiller also prepared two screencasts. The older one is an introduction to SVG-edit, where he uses 2.2 version. And the newer one, which presents some of the new features included in 2.3 release.

Head here if you’d like to try SVG-edit yourself!

New RPM in openSUSE Factory

rpmlogo

Michael Schroeder has finally updated the RPM package in openSUSE to the latest upstream version 4.7.1. \o/ There were LOTS of bugfixes, enhancements and internal API changes which are probably not very interesting for mere mortals, but what do they mean for packagers? Here’s a list of important changes for them:

  • Macro %patch does not behave like %patch0 anymore. Stop mixing Patch: with %patch0 and vice versa and use them consistently - i.e. either use the numbers in preamble and in %prep phase or don’t.
  • Fuzz tolerance for patches was changed from 2 to zero. All patches must apply cleanly now.
  • Sub-packages can be declared as “noarch” now. Such .spec file is incompatible with older RPM but the resulting binary packages are compatible.
  • Section %files now supports multiple file lists. No need to join the files into one in %install section.
  • The new macros %{patches} and %{sources} are available. You can use them in for loops to iterate over all patches and sources respectively.
  • %ghost files do not have to be present in the build root anymore. In this case you have to specify their attributes like this: %attr(0644,root,root) %ghost ghostfile.

Few months ago we began discussion with Fedora guys about how to bring our packaging habits more closer. We identified some points by comparing their Packaging Guidelines with our routines and I created a list of differences at RPM wiki. The main idea is to find a solution which is acceptable by both parties and to create a mechanism (usually macros) for it in RPM upstream, so both distributions can benefit from it. Some of the problems are already sorted out, but there is still a long way to go. If you are aware of such differences or even would like to propose the solution, please contact me. I’ll add the items to the list and we’ll discuss them at the openSUSE Conference - RPM Summit, where people from RPM upstream will be present as well. By looking at the “Solved” part (at the bottom) of the mentioned wiki page you can see the following changes to be more compatible:

  • Our %makeinstall macro is called %make_install in RPM upstream. Change it to the new form when you touch your package (also replace make DESTDIR=${buildroot} install with this macro).
  • Build root is created in a safe way, you don’t need to specify the location with BuildRoot:. Also it is automatically cleaned after the build if the %clean phase is omitted from .spec file (i.e. not mentioned at all, if it is there but is empty no removal is done).
  • Use %{python_sitelib} macro for noarch Python packages and %{python_sitearch} for the architecture dependent ones, instead of the old %{py_sitedir} one. (Yes you can now create noarch Python packages!) Stop using %{py_requires} as well, because dependencies are added automatically now.

Important! Nearly all of these changes are effective from 11.2 and will not work with earlier releases in openSUSE. If you plan to use the same .spec file for backporting inside BuildService, you’ll need to keep the old and the new stuff in corresponding %if 0?%{?suse_version} ... %endif blocks for a while (well, until 11.1 is EOL).

PS: I will try to keep this post updated until 11.2 is released so you might want to check it from time to time.

Chameleón má už svoje meno

Počas minulého týždňa sa viac ako 130 z vás zapojilo do súťaže o výber mena pre nášho chameleóna v pražskej ZOO. Obdržali sme viac ako 150 skvelých nápadov a naša skalná komunita, ktorá sa zdržuje na IRC kanáli #susecz mala čo robiť, aby z nich vybrala najlepší. Medzi návrhmi sa objavili rôzne pôvabné mená ako Bugísek, Susík či Zmizík, ale nakoniec zvíťazil Jastík. Z pekných cien odfotených na obrázku nižšie sa môžu radovať Petr Dvořák zo Studenej a Jan Hora z Prahy.

sutaz-ceny

Chameleón obrovský v ZOO

English version below …

Pred pár dňami sa pražská pobočka SUSE Linux, s.r.o. stala adoptívnym rodičom Chameleóna obrovského (Furcifer oustaleti) v ZOO Praha. Ako každý vzorný rodič musíme nášmu potomkovi vybrať meno (a anglické Geeko sa mu predsa nehodí). Keďže je openSUSE komunitný projekt, nenechávame si túto radosť iba pre seba a chceme Vás poprosiť o pomoc pri výbere. Vaše nápady nám píšte do konca tohto týždňa (23.8.2009 23:59). Najlepší z nich odmeníme zaujímavou cenou!

Na záver ešte prikladám certifikát a dve fotografie nášho krásavca:

zoo_certifikat

zoo_chameleon_1

zoo_chameleon_2

A few days ago the Prague SUSE office became the adoptive parent of the giant chameleon (Furcifer oustaleti) in the Prague ZOO. You can see the adoption certificate and two photographs of our beauty above.