ModemManager vs. modems

The last days I worked on porting newer versions of ModemManager (MM) and NetworkManager (NM) to SLE11-SP1. Basically, the NM version from openSUSE 11.2 plus some patches and the latest MM release v0.4 are working now, but that's not the point of this posting.

It was the first time I touched the code of these tools. My expectation was that ModemManager should contain all modem related code and provide a DBus interface for NM to handle all the networking. The first issue I tested was using a mobile (GSM) via USB. It worked. Also UMTS/CDMA devices should work. But to my surprise ModemManager don't support plain modems (simple old and slow modems like a serial 56k modem) at all. Or did I miss something?

So why is this daemon called ModemManager if there is no modem support? It's all about WWAN devices and not modems. Not that this project is completely new, the first git commit is from July 2008.

If this should be a manager for modems, it should IMO support all kinds of modems like e.g. serial or PCMCIA modems, cable or (A)DSL modems and WWAN devices. Otherwise rename it to WwanManager (or should it be WWANManager?) for example!

Another point that's absurd to me: All the PPPoE handling (as e.g. used for DSL modems) is still part of NetworkManager. And AFAICS the modem dialup support is still covered by pppd and under GNOME by gnome-ppp. It would make much more sense to do all the PPP handling in one place. Until now I assumed NM to be the central place to handle network, but the last days disabused me. The current situation is far far away from being reasonable.

Tech Tags: ModemManager Network

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