Danny's Blog

My new openSUSE buildservice home project

2012-11-15T17:42:00.001+01:00

Only a short information for you: I have a new home project on the openSUSE buildservice. Therefore I've took the chance and deleted my old home project and a lot of old packages I've build for no longer supported (open)SUSE releases with it.

That also means: some of the links to packages in this blog are may broken and I don't plan to fix them. You can find the new project here. Since the most of my former packages already moved into the distribution or other devel projects feel free to search here for them if you can't find them in my new home.

PandaBoard: persistant MAC address via initrd

2012-02-07T14:41:00.000+01:00

I worked out a solution to replace the random MAC address set by the smsc95xx kernel module with the MAC address generated by u-boot on the PandaBoard(ES). It should also work on the BeagleBoard.

As first you need this kernel patch to fix isses with exporting the assign type (PERM, RANDOM, STOLEN) to /sys/class/net/*/addr_assign_type correctly if the smsc95xx driver generate a random MAC address. Build your kernel, if you use openSUSE:Factory:ARM you can get RPMs here, until it's integrated into the official openSUSE kernel.

Now you need a mkinitrd with this patch or a you install these RPMs for openSUSE. This adds a initrd boot script to set the MAC address from kernel cmdline parameters. These are the available parameters and some example values:

setmac.set_mac_addr=01:23:45:67:89:ab

setmac.set_iface=eth0

setmac.set_module=smsc95xx

The setmac.set_mac_addr= is mandatory to change the MAC and you have to choose one of the other two parameters. Either you specify the network interface or the kernel driver/module. In case you use setmac.set_module the first network device provided by this module which has a random MAC gets the new address assigned. Please note: this script change the MAC of a interface only if addr_assign_type=1 , otherwise nothing will change.

If you have installed the new kernel and mkinitrd you may need to follow these steps:

# mount the boot partition which contains the uImage (and may also the MLO file)
mount /dev/mmcblk0p1 /mnt
# make sure this partition contains the new uImage
# build a new initrd
mkinitrd -B
# create a uInitrd
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d /boot/initrd /mnt/uInitrd

Now you need to tell u-boot to boot from the uInitrd and to set the needed cmdline parameters. I prefer to use a uEnv.txt file instead of a boot.scr since you simply can change it without call mkimage. You can download my currently used uEnv.txt here. The content depends on your setup you may need to adapt yours:

bootargs=root=/dev/mmcblk0p2 rw rootwait rootfstype=ext3 console=ttyO2,115200n8 vram=16M omapfb.vram=0:16M

bootcmd=mmc rescan ; setenv bootargs ${bootargs} setmac.set_mac_addr="${usbethaddr}" setmac.set_iface=eth0; fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80000000 0x81600000

uenvcmd=boot

Now umount /mnt and reboot your system. If you already worked around the random MAC address problem: don't forget to remove/disable these hacks.

Personal note: Moved to blog.bisect.de

2012-02-06T16:36:00.001+01:00

As you may already seen, I moved my blog from dkukawka.blogspot.com to a new address. You reach the blog now on blog.bisect.de . The old address should still work but you may want to adopt your bookmarks or RSS/Atom feeds.

I also merged my blog with my Google+ profile. By this you should see new posts also at my Google+ stream.

Update: PandaBoard persistent MAC from smsc95xx kernel module

2012-02-04T19:10:00.000+01:00

Some days ago I decided to send an updated and reworked version of my kernel patch for the smsc95xx kernel module - to get a persistent MAC address via the kernel cmdline from u-boot - to the linux kernel mailing list. I should have known better and save me the time: the patch wasn't accepted. You can follow the discussion here.

If you follow the argumentation, we should drop the support for changing the MAC address of a network device via kernel module parameter also from e.g. the following modules: sunhme, fec or ksz884x. And we should then also remove all the 'generate a random MAC for real devices' since it all could be somehow get managed in the user-space, although it's pita to handle this task in user-space since it's currently even hard to find out if a device got a random MAC assigned from the kernel.

I still plan to add the patch to the openSUSE kernel until I've worked out another solution. Feel free to use the patch anyway on your system.

PandaBoard: get persistent MAC address by default

2012-01-20T17:22:00.004+01:00

The PandaBoard/PandaBoard ES, as the BeagleBoard too, don't have a EEPROM on the (USB-) network card to store the MAC address. That's why you get a new MAC and subsequently a new IP address with each boot. You can set the MAC manually via e.g. 'ifconfig eth0 hw ether 01:23:45:67:78:01' or also automatically via the network scripts.

The other solution would be to generate a MAC on OMAP (version > 2) machines by reusing another unique hardware identifier. There is already an old patch written by Mark Crichton for the BeagleBoard. And there was also an patch on the kernel mailing list from Andy Green and some related discussion, but none of them got into the kernel. The problem was that if there are more than one card in the system without EEPROM they all would get the same MAC address. That sounds reasonable to me while I'm not sure that something like this will happen with a high chance out in the field. And since there are objections against exporting the OMAP die ID to the sysfs there is no simple way to handle the MAC generation in userspace (e.g. via udev).

While investigating how u-boot handle the no-EEPROM problem, I've found out that the u-boot code already contain functions to generate a persistent MAC for such devices. The MAC gets also exported to the u-boot environment as usbethaddr. That's why I wrote a patch for the smsc95xx kernel driver (based on a patch from Sebastien Jan) to take a module parameter to set the MAC address via the kernel command line. With this patch the driver takes the following parameter: macaddr=01:23:45:67:89:ab;[tgt-netdevname] and assign the given MAC address to the first device in the system without a MAC on the EEPROM. If there is more than one device without EEPROM you can add the netdevice name to the parameter - separated by a ';' - to assign it to a special device (e.g. for eth0: macaddr=01:23:45:67:89:ab;eth0). If there is no MAC given, the device still gets a random MAC as before.

After patching and installing your kernel, you need to change the u-boot config to pass the $usbethaddr from the environment along to the kernel cmdline. I used a uEnv.txt file (on my boot partition) instead of the legacy/obsolete boot.scr, since you simply can change the file without call mkimage after each change. That's the content of the uEnv.txt file I currently use to set the MAC of my PandaBoard ES:

bootargs=root=/dev/mmcblk0p2 rw rootwait rootfstype=ext3 console=ttyO2,115200n8 vram=16M omapfb.vram=0:16M

bootcmd=mmc rescan ; setenv bootargs ${bootargs} smsc95xx.macaddr="${usbethaddr}" ; fatload mmc 0 0x82000000 uImage; bootm 0x82000000

uenvcmd=boot

You can find the patch here, I plan to include it into the openSUSE OMAP2+ kernel and to send it upstream as soon as I have some reports back that it also works for others. You can find an kernel RPM for openSUSE Factory here.

How to send patches via git-send-email

2012-01-13T15:25:00.000+01:00

In the past I either directly commited to git or send - if needed - my patches to e.g. mailing list by exporting the patches from my local git repo via 'git format-patch -s origin' and then importing them into my mailer. Yesterday I finally found some time to get git-send-email running to do this for me directly on command line.

First you have to choose if you always use the same email account to send your patches. In this case you need to configure 'git-send-email' this way:

git config --global sendemail.from "YOUR NAME <user@example.org>"
git config --global sendemail.smtpserver imap.example.org
git config --global sendemail.smtpuser USER
# depending on your config you may also set:
git config --global sendemail.smtpencryption tls

If you don't want to enter password for your SMTP server all the time:

git config --global sendemail.smtppass = PASS

If you use different settings/email accounts for different project, you can setup different identities for them. Here one example for btrfs project:

git config --global sendemail.btrfs.to "linux-btrfs@vger.kernel.org"
git config --global sendemail.btrfs.from "YOUR NAME <user@example.org>"
git config --global sendemail.btrfs.smtpserver imap.example.org
git config --global sendemail.btrfs.smtpuser USER
git config --global sendemail.btrfs.smtppass = PASS
git config --global sendemail.btrfs.smtpencryption tls

There are some other options you may should use as e.g.:

git config --global sendemail.chainreplyto false

to set the threading format to shallow/flat instead of the deep threading, which is much more readable on a mailing list if you send multiple patches at once.

Now you can send you patches with (you may have to replace origin with the revision you need):

git send-email --annotate origin

If you use an identity e.g.:

git send-email --identity=btrfs --annotate origin

If you didn't commit your changes into your local git branch with the -s option (to get the 'Signed-off-by:' line) you need to add the --signoff option, as I realized after sending my latest patches to the btrfs mailing list. If you send a patch series you may also want to use a cover email to explain something or to write more info. In this case you can use --cover-letter to get git to create and let you edit such an email before sending.

Here the full example command I would use to send my patches:

git send-email --identity=btrfs --annotate --cover-letter --signoff origin

For more info check e.g. the Git Community Book or use your favorite internet search engine.

Some fixes for btrfs-progs ...

2012-01-13T14:04:00.000+01:00

Yesterday I found some time to send some patches for btrfs-progs upstream. Unfortunately the information on the btrfs wiki pages about the source code repositories are completely outdated, either the repo didn't exist or the branch wasn't there as in case of the 'for-chris' branch of the 'Integration repository'. Finally I send them against the repo of Chris Mason listed at git.kernel.org.

The patches fix some possible segfaults and some compiler warnings, you can find them at the mailing list.

CHERRY STRAIT Exclusive Testa Motari Edition

2012-01-03T14:42:00.001+01:00

I got a 'CHERRY STRAIT Exclusive Testa Motari Edition' keyboard at Christmas from my girlfriend. It's a really exclusive keyboard. The top of the board is made out of wood veneer. Since each wood is unique as a fingerprint, no keyboard looks like the other. My keyboard was made with satin walnut, but you can get them also with vavona burl or macassar ebony. The veneer used is certified for sustainable forestry and no tropical wood was used.

The keyboard was derived from the 'CHERRY STRAIT Corded'. The wood was glued to a aluminium plate. Thanks to that detail the 'Testa Motari Edition' is much more torsion-resistant and not that wibbly-wobbly as the original keyboard was reported in some tests (e.g. here).

It's a really cool keyboard with a nice to touch surface. As you can see in the following pictures, the device is very flat. From the ergonomical point of view I miss a way to change the inclination, but it's comfortable to use anyway. I guess you have always to wash your hands before using it, since the wood isn't sealed or varnished.

The key layout needs getting used to: four of the five multimedia keys are on the top of the numeric pad but the 'Play'-key is located between the Print/SysRq key and F12. Also the block between the main keys and the numeric pad is modified and the 'fn' keys are not grouped compared to a standard keyboard.

Résumé: It's an expensive but really nice keyboard! Thanks for the present!

Here some pictures (see more here):

Pandaboard ES: How to get 1 GByte RAM

2011-12-16T14:07:00.000+01:00

Some colleagues told me they have only ~750 MByte RAM available on their PandaBoards. So I checked my PandaBoard ES and it was the same there. As first I tried to set mem=1024M in boot.scr, but this didn't help. After some research I found that our kernel from the openSUSE:Factory:ARM repository wasn't build with HIGHMEM support. But the kernel need HIGHMEM-support to access the memory above 768MB on ARM/OMAP.

I changed the kernel config for the omap2plus package and build a new kernel RPM locally.

As soon as I installed the new kernel and rebooted, I got this:

root@pandboardES:/ # free
total used free shared buffers cached
Mem: 1010680 54604 956076 0 3516 29384
-/+ buffers/cache: 21704 988976
Swap: 0 0 0

I'll submit a new kernel package, but for now you can get the RPMs here.

PandaBoard ES ... got it up and running openSUSE

2011-12-13T20:21:00.000+01:00

I finally found some time the last days to play with my new PandaBoard ES. As first Dirk Müller helped me by providing an image for my SD-card with an image that worked with the normal PandaBord. Thanks! Unfortunately we couldn't get the machine running with this image.

Later I tried a Linaro Android build and the machine booted. As I copied some of the files from the boot partition to the SD-card with the openSUSE installation it booted into openSUSE. After a hint from Alexander Graf (to change the console in u-boot to ttyO2) I could also access the serial console.

I could now play around and build on the board to find a fix for the openSUSE image Dirk provided to me: Since it didn't boot with the latest u-boot/x-loader git code from mainline, I tired the u-boot git from Linaro. This step finally solved the issue. I created a new u-boot package for openSUSE: u-boot-linaro-omap4panda. While the upstream u-boot package deletes the MLO file at the end of make, the Linaro u-boot doesn't. Therefore the new RPM should obsolete x-loader-omap4panda at openSUSE.

You can get the Factory RPM (temporary) here. I already made a submit request for Base:System ... we will see if and when it gets in.

New PandaBoard ES arrived

2011-12-12T12:05:00.001+01:00

Today finally my new PandaBoard ES arrived from Digi-Key. Here the new features compared to the former PandaBoard:

Dual-core 1.2 GHz ARM® Cortex™-A9 MPCore™ (OMAP4460) with SMP from Texas Instruments

provides 25% increase in graphics performance over OMAP4430 (but use a Imagination Technologies’ POWERVR™ SGX540 graphics core as the PandaBoard)

DSI Support

Bluetooth Low Energy Capable

Sysboot switch available on board

The rest of the board should be the same as on the OMAP4430 based PandaBoard. Here some pictures:

Let's start to get an openSUSE running on the machine ... I'll post updates as soon as I found the time to play around with this tiny thing.

Git trouble shooting: none-bare repository

2011-10-31T16:16:00.002+01:00

I had some trouble with my git repositories at freedesktop.org in the past, as you may remember [1,2]. Last week I run in some trouble again. As it looks, they updated the git server to a new version, since the update I got the following error message on push:

[...]
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error:
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error:
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ssh://dkukawka@people.freedesktop.org/~dkukawka/hal.git
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'ssh://dkukawka@people.freedesktop.org/~dkukawka/hal.git'

Unfortunately the instructions from the error didn't help me to make push work again. I tried 'git reset --hard'and also to clone the repo again from the server, apply the new patches etc. but it didn't work. Here is what I had to do to get it work again:

go to the repository directory

call 'git config --bool core.bare true'

I don't know how it happened in the first place to be non-bare, but this should set the remote repository again to a bare repo and you are able to push again.

How to get your full disc space back on ext filesystems

2011-08-19T17:09:00.000+02:00

You may have already wondered why you can't use the full disc space on an ext2/3/4 partition? You already seen something like this, where the used and available blocks don't fit the number of blocks on the device/partition:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdc1 15391664 38184 14571608 1% /mnt

The reason is: if you create an ext filesystem (no matter if with mkfs or YaST), 5 % of the filesystem get reserved for the super-user to allow e.g. root daemons to continue to write to the partition after unprivileged processes stopped because the partition is full.

While this perfectly make sense on system partitions as '/', it makes no sense on data partitions or external media (in the most cases). By this you get e.g. on an external 2TB/1.8TiB drive 100GByte/~92GiB, which you can't use as normal user. But you can get this space back. Either you set the number of reserved blocks to zero when you create the file system:

mkfs -t ext4 -m 0 /dev/sdc1

or you do it later:

# make sure partition is unmounted
umount /mnt
tune2fs -m 0 /dev/sdc1

On a LUKS encrypted you have to do this:

# on a LUKS device
umount /media/disk
tune2fs -m 0 /dev/mapper/udisks-luks-uuid-X

You should see this output:

tune2fs 1.41.14 (22-Dec-2010)
Setting reserved blocks percentage to 0% (0 blocks)

And if you mount the device again, you can see with df that you have the full space available:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdc1 15391664 38184 15353480 1% /mnt

Update for extundelete

2011-08-17T18:50:00.000+02:00

Today I've submitted a new extundelete package to my repo with following fixes:

added man(8) page to the package
fixed --help output to print also info about --restore-directory
added --dump-names option to search for - and print the full name of - deleted and (potentially fully) recoverable files on a given partition

Feel free to test and report problems back. The package is now also part of the filesystems project.

How to undelete files from ext3/ext4

2011-08-09T13:28:00.000+02:00

Sometimes, especially on the command line, it happens that you delete a file or directory you didn't really plan to delete. A second after hit enter you realize what you have done, maybe you are fast enough to stop the deletion process and save some files, but in the most cases it's already to late, at least for some files. If you have no or a too old backup you're screwed.

If you use ext3/ext4 you may be able to recover the file with ext3grep or extundelete with information from the file system journal if the content of the file wasn't already overwritten by new data.

The first step should be to stop all writing processes on the related partition and unmount that partition as soon as possible. Now you have the choice: if your partition uses ext4 you have to use extundelete, if it's ext3 you can use also ext3grep. Personally, I prefer extundelete, since it supports both file systems and seems on one hand much faster to me than ext3grep and it's also easier to use on the other hand. Due to that, the following examples are for extundelete (you can find a ext3grep How-To here).

If you know the path and the name of the file (let's assume it's /home/tux/cv.tex and /dev/sda4 is mounted to /home) you deleted, switch to root and go to a partition with enough free space to store the deleted files. Then:

# extundelete need the relative file path
me:/tmp # extundelete --restore-file tux/cv.tex /dev/sda4

As soon as extundelete finished, you'll find the recovered file in /tmp/RECOVERED_FILES/tux/ .

If you deleted more than one file in a directory or a directory itself, you can use --restore-directory :

# extundelete need the relative dir path
me:/tmp # extundelete --restore-directory tux/Documents/tex/ /dev/sda4

There are some more useful options as --restore-all , --restore-files, --after 'dtime' or --before 'dtime', but in the most cases the two examples above should be enough. You can find both tools in my buildservice repository.

Updated xinput_calibrator packages

2011-08-09T12:20:00.001+02:00

Today I found some time to update the xinput_calibrator packages in my buildservice repository. The new version is 0.7.5. And since someone asked in my last post for 11.4 rpms, I've activated the build also for openSUSE 11.4.

Feel free to test and report back if you have any trouble with the updated version.

How to calibrate your TabletPC

2010-08-30T17:20:00.003+02:00

Since a while e.g. the X11 driver for Wacom tablets should work out of the box, no calibration needed. I didn't test other tablet/touchscreen drivers in the last time, but I assume also some other should work out of the box. But sometimes you still need to calibrate your device.

But how do you calibrate e.g. your wacom tablet on a openSUSE 11.3 or Factory, since there is no wacomcpl anymore in the package, which was used in the past? And how about a evdev based device? Simply use xinput_calibrator. You can get the package for openSUSE from my openSUSE buildservice repo.

After installation follow these steps on shell:

# check if xinput_calibrator found any device
user@tablet:~> xinput_calibrator --list
Device "Wacom ISDv4 90 Pen" id=10

# start calib.: for multiple devices use --device option
user@tablet:~> xinput_calibrator

You get this screen, follow the instructions:

You get some output with some instructions as soon as you finished the procedure. The preferred way to setup the tablet/touchscreen with the calibration data is coping a snippet from the output into '/etc/X11/xorg.conf.d/99-calibration.conf' (as root). Here an example for such a snippet:

Section "InputClass"
        Identifier      "calibration"
        MatchProduct    "Wacom ISDv4 90 Pen"
        Option "MinX" "0"
        Option "MaxX" "28606"
        Option "MinY" "0"
        Option "MaxY" "17876"
EndSection

You may need to restart your X-server after setting up the file. If it doesn't work checkout the instructions in the output for other ways to setup the changes.

Tech Tags: TabletPC

Hacking osc (4)

2010-08-19T15:15:00.000+02:00

Here's what some of the major stuff I did on osc in the last weeks:

changed 'osc request revoke' (and also reopen, accept, decline, wipe, revoke) to check the actual state and ask the user to prevent set the same state twice [1]
added new command 'osc requestmaintainership' as shortcut for 'osc creq -a add_role USER maintainer PROJECT PACKAGE' since this command is hard to find for (new) users [2]
changed 'osc request show' to show add_role request info more verbose including requested person/group and the requested role [3]
fix output of 'osc buildinfo' if parameters are missing, show only the available repos (and not the arch) if called from a checked out package [4]
updated osc.complete, added all existing commands to list [5]
added new command 'osc distributions' to get info about active distributions [6]
some changes to respect 'osc -A' and to reuse apiurl instead of reading it again and again from config [7][8]
changed 'osc repos' to filter out disabled repos of a package [9]

Tech Tags: Patches SUSE

[Update] openSUSE: new wiki, and now ...

2010-07-21T17:23:00.000+02:00

Some updates about the new openSUSE wiki issues:

The User:* pages are now finally protected (see bnc#409520 for history).
Looks as if the Special:Import is now finally working also for normal users.

That are good news, but there are some other issues with the wikki:

As already pointed out by some other (e.g. in the 5th comment on this post): older external links to wikipages don't work anymore and there is no hint on the 'empty' page that there is a new wiki with a new structure and where you can find the old wiki. That's really annoying! But there is a info one some pages in the old wiki where to find the new pages (as e.g. here), we need something like that in the new wiki with info where the page was moved. At least as long as this page is empty.
Also the 'google index' is destroyed. If you e.g. search at google.com for 'opensuse nvidia' you find this result on the second place, but the page doesn't exist. Sorry, but it was really a stupid idea to do this change and breaking the google index (and external links) with it.
I know the intention was to cleanup the old wiki and give it a new structure, but the way it was done makes it really hard for the users. If a user look for the replacement of the old Nvidia page in the new wiki, there is no result with the default search, since it was moved to SDB:NVIDIA. You have to enable the search for the SDB namespace manually. IMO this should be activated by default.
Not sure about the plans for the new structure of the wiki atm, have to search for some information about it. But there are some pages missing which are used in the URL-field of old and new (openSUSE 11.3/Factory) rpms. One example is the patterns page (e.g. from the patterns-openSUSE* rpms) and I assume there are others.

Tech Tags: SUSE

openSUSE: new wiki, and now ...

2010-07-13T16:11:00.000+02:00

... a lot of work and some trouble. Since yesterday is the new openSUSE wiki online, as I discovered today as I checked my last week updated user page. The page was gone ... I had to create a new version of the page. Thanks!

I really appreciate the time the openSUSE wiki-team spend on the update, but unfortunately the new wiki don't always work as exprected:

You can export any page via Special:Export (from the old wiki, which you can reach via http://old-en.opensuse.org) and you should be able to import the page via Special:Import. But the import page don't work, you get "Permission error: The action you have requested is limited to users in the group: Administrators.". No way to migrate a page from the old to the new wiki for now!
If you 'Log out', you end in a old-style wiki page, which is oddly enough part of the new wiki:

The User:* pages are still not protected. Any user can change the content of your userpage. That's inacceptable! If you don't monitor your page very closely other ppl. may write there whatever they want. Btw. I opened a bug ages ago (2008-07-16) for this problem, but it's still not fixed even though there is already a proposal how to fix it included (bnc#409520).
Due to this post you should recreate to User:* page with a template. Unfortunately I couldn't find a way to load/import the template if you already created and saved the content of your page. That's why my page will stay in the old style.

So far so good about the technical part. There is another issue I don't like on the new wiki: the corporate design (CD). Except for the little lizard at the top left corner, there is not that much that differs the openSUSE wiki from other MediaWikis. I miss the distinguishing characteristics to other wikis and the associations to e.g. the design of the current openSUSE installer as you can see if you compare both side-by-side:

Even the sponsor logo is much bigger than the openSUSE lizard. There is no big recognition effect. While it's may not such an issue if you use a prosaic design for a developer service like build.opensuse.org, it's IMO important to have a design with a higher recognition effect for direct user services.

Tech Tags: SUSE

Hacking osc (3)

2010-07-01T15:35:00.005+02:00

Here my latest changes/commits on osc:

extended 'osc wipebinaries' to read package/project from checked out directories [1]
fixed 'osc diff' function which left tempfiles in /tmp after finished [2]
changed 'osc getbinaries' to work also in project dirs. If 'osc getbinaries' get called in a checked out directory all packages of the project get downloaded [3]

Tech Tags: Patches SUSE

ModemManager vs. modems

2010-06-30T11:52:00.003+02:00

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)

2010-06-24T15:49:00.005+02:00

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

2010-06-12T11:09:00.003+02:00

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

2010-02-27T11:03:00.011+01:00

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