Hacking osc (2)

The last days I fixed again some issues in osc. This time it was about the 'osc results' options:

• fixed 'osc results -a/-r' if you call it from a package directory [1]
• fixed and enabled 'osc results -a/-r' also for project directories to be able to filter the output for architecture(s) and/or repo(s) (especially since it can be a long list) [2]
  

Since I have now commit rights at the osc git repo: it should be in the next release.

Tech Tags: Patches SUSE

Hacking osc

Last month I found some time to take a look at osc to fix issues and add some stuff I was missing since I have to work with build.opensuse.org and the SUSE internal buildservice (e.g. for updates and maintenance of our enterprise products).

Yes, I know it's some weeks old and now integrated, but anyway. Here is what I've done:

• added new 'osc getbinaries REPOSITORY' to checkout the RPMs for all architectures, including the source RPMs, into subdirectories [here]
  
• fix 'osc my' to get the apiurl from checked out packages if possible [here]
  
• make sure that global option -A always works too in a directory with a checked out package [here]
  
• add run_pager() and make osc log/diff work like git log/diff (call less by default to display the result of diff) [here]
  
• fixed some close() statements and some other warnings [here]
  

Tech Tags: Patches SUSE

How to move local git repo with branches to a server

As my HAL/hal-info git repos were lost last year at people.freedesktop.org, I restored them from my last existing local checkouts. I simply copied the local checkout/repo to the server and created a new git repository as proposed in the git user manual:

git clone --bare ~/hal hal.git

touch hal.git/git-daemon-export-ok

But as I, some months later, tried to switch to my hal-0_5_12-SUSE_CODE11 branch, there was no such branch. To be exact: there was neither this branch nor any of the upstream branches. I couldn't find any information on the web how to solve this problem. Everything I tried didn't work. When I cloned the new repo from the upstream repo, all branches where available.

At the end I found my own solution once I compared the .git/refs/ directories of the cloned repo from the upstream and the local repo. Looks as if the clone command don't copy the branches under .git/refs/remotes/origin/ to .git/refs/heads/ if you use a local repo/checkout as source. Here is what I did to get my branches available again:

cd hal

find refs/remotes/origin/ -type f | grep -v -E 'HEAD|master' | xargs cp --target=../hal.git/refs/heads/

I don't know if there is an other, more standard, way to do this. I couldn't find anything else and at least it solved the problem for me.

Tech Tags: git Tutorial HAL

My freedesktop.org stuff is online again

It's a while since the last post on my blog, so here the latest news:

Two weeks ago, after some weeks of absence, I tried to commit some patches to my hal/hal-info git repo at freedesktop.org, but there was no git repo anymore. In fact my complete home at people.freedesktop.org was empty. 

After wonder around about the reason, I found out that the freedesktop admins lost the complete /home filesystem during a power outage (see the announcement). Unfortunately there was obviously no backup (whyever!) and also no email announcement to the affected users after all . That's why my repos weren't reachable for nearly a month. Thanks for the service at  people.freedesktop.org in general (really!), but this was a lousy incident handling.

Anyway! You can find now again:

• my HAL git repo: here
  
• my hal-info git repo: here
• several different versions of the HAL specification: here

Tech Tags: HAL

HAL: new keys to match kernel version

Since a while there is the problem that e.g. suspend quirks or key mappings differ between kernel versions. While machines with newer kernel versions may need no longer to map scancodes (as in case of ThinkPads) or need no special suspend handling anymore, systems with older kernels may need other handling.

With current HAL versions it's not possible to match the kernel versions (e.g. > 2.6.28), except for a special version, because system.kernel.version is a string. This is especially a problem with data from the hal-info package, since the package depends on no special kernel version.

I added a patch to HAL to provide now these new comparable (using e.g. compare_*) keys:

• system.kernel.version.major (int)
• system.kernel.version.minor (int)
• system.kernel.version.micro (int)

This change will be part of the upcomming 0.5.12 release. For openSUSE 11.1 you can get the latest HAL snapshot from my OSBS repo.

Tech Tags: HAL Patches

TabletPCs: fix eraser detection in xournal

Some weeks ago I got a bugreport for SUSE about problems with automatic eraser detection of Wacom tablets/TabletPCs in xournal. After taking a deeper look into the problem, I discovered that it's again a problem with the naming of the wacom input devices in the xorg.conf.

To find out if the eraser is used, xournal checks for GDK_SOURCE_ERASER. And as it looks GDK can only identify an input device as GDK_SOURCE_ERASER if the devicename starts with eraser. But this is not the case at SUSE products since we use SaX2 which use Mouse[*] as device name.

I wrote a patch for xournal to use xsetwacom to find out if the currently used input device is a eraser, so that the automatic detection is working again and you can use the eraser without selecting the eraser tool again and again. You can find updated xournal packages for openSUSE/SLED in my OSBS repo.

In my opinion the real problem is, that there is (AFAIK) currently no way do mark and identify input devices in X.org as e.g. stylus/eraser/touch. It would make it much easier for applications if there would be a device name independent solution in X in the future.

Tech Tags: TabletPC Patches

HAL: support for linux leds kernel subsystem

I've implemented HAL support for the linux kernel leds (light-emitting diode) subsystem some days ago. The new namespace provides these information for leds devices:

• leds.device_name: The name of the related led device.
  
• leds.colour: The colour of the LED. (e.g. green, orange)
  
• leds.function: The function of the LED. (e.g. radio, power, standby, batt)

The new leds devices offer via a singleton addon also a DBus interface to set the brightness of the LED. It works the same way as e.g. the org.freedesktop.Hal.Device.LaptopPanel interface by providing a GetBrightness() and a SetBrightness() method. The values for the brightness depends on the kernel driver and should be normally between 0 and 255 (0 normally deactivates the LED, any other value > 0 activates the LED again).

You can get the patches from my git repo [1] [2] [3].

Tech Tags: HAL Patches