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

Handling requests directly in the Build Service web client

We had a listing of pending requests in the Build Service for a while. Unfortunately, it was mashed together with “My Projects” view and one couldn’t do anything with them. Few days ago, Jan Loeser added support for handling these requests directly in the web client. I liked the idea, so I decided to spend some time on it, too. I moved the request listing to a separate page and added some nifty Tango icons for the actions, so they wouldn’t take too much of the precious space. Also, the design doesn’t use tables-in-table anymore. You can view the result on the following image or directly in the Build Service.

listreq

PS: The page still looks like it was designed by programmers, but as usual you are welcome to help us! :-)

Wrong usage of LD_LIBRARY_PATH

Lots of programs that bring their own libraries use the following snippet in their wrapper scripts:

export LD_LIBRARY_PATH="/my/special/librarypath:$LD_LIBRARY_PATH"

This allows linker to find the needed libraries, even if they are not located in the standard directories (which are defined by /etc/ld.so.conf). At first, this seems OK, but it creates one problem, though. When the $LD_LIBRARY_PATH was empty before the assignment, the new value ends with a colon. When we run the program wrapper, linker splits the variable into substrings and ends up with one empty path. This indicates to search for libraries in the CURRENT working directory, which can cause problems or even a security threat.

So, what’s the correct way of defining the library path? Of course, we could check if the variable is empty before the assignment like this:

if [ -n "$LD_LIBRARY_PATH" ]; then
    export LD_LIBRARY_PATH="/my/special/librarypath:$LD_LIBRARY_PATH"
else
    export LD_LIBRARY_PATH="/my/special/librarypath"
fi

but there is one neat shell trick we can use (should work on all POSIX shells). The description says:

${parameter:+word} Use Alternate Value. If parameter is null or unset, nothing is substituted, otherwise the expansion of word is substituted.”

In the end we have:

export LD_LIBRARY_PATH="/my/special/librarypath${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

which is not much longer than the line we started with, but does the assignment correctly. (The first colon belongs to shell syntax, the second one is a part of the value being appended).

Chromium package in Contrib

chromium

Thanks to unceasing endeavors of David Buck and Raymond Wooninck we now have Chromium built fully from the source code! It is available from our Contrib repository (package chromium). I recommend using this one instead of various other RPMs that repack Google Chrome/Chromium binaries or are kept in users home repositories. Big thanks also goes to Tom ‘spot’ Callaway for much of the original patchwork, Justin Haygood for helping with the icu patch and Malcolm Lewis.

openSUSE Junior Jobs

Our dear friends at KDE have a really nifty feature in their Bugzilla. They mark easy tasks or “low-hanging fruits” with the “JJ:” prefix (meaning Junior Job). We like the idea so much that we decided to adopt it in our Bugzilla too. I created a trimmed URL - http://tr.im/opensusejj - which lists all such issues. If the bugreport is not verbose enough or it is not clear what to do, feel free to ask developer assigned to the bug. I’m sure he or she will give you a helping hand. :-) Michal started a wikipage which provides more details.

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.