hal ignores fdi files containing uint64 merges

[Thorsten]

Binary package hint: hal

Since the update to 0.5.9 in feisty-backports hal does no longer accept fdi files which contain a merge with type="uint64". Such files are simply ignored. Usually this is not a problem since hal (i.e. hal-info in 0.5.9) doesn't come with any such fdi files but it potentially makes the use of certain user provided fdi files impossible (as in my case). Downgrading to 0.5.8.1 solved the problem for me.

[Sense Egbert Hofstede (sense)]

Thorsten Schoel reported this a while ago at Launchpad:
"Since the update to 0.5.9 in feisty-backports hal does no longer accept fdi files which contain a merge with type="uint64". Such files are simply ignored. Usually this is not a problem since hal (i.e. hal-info in 0.5.9) doesn't come with any such fdi files but it potentially makes the use of certain user provided fdi files impossible (as in my case). Downgrading to 0.5.8.1 solved the problem for me."

After I asked him whether the bug was still present in the latest version he told me that he could still reproduce it.
He provided this example file:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
        <device>
                <match <email address hidden>:storage.cdrom.cdr" bool="true">
                <match key="block.is_volume" bool="true">
                        <merge key="foo" type="string">foo</merge>
                        <merge key="bar" type="uint64">12345</merge>
                </match>
                </match>
        </device>
</deviceinfo>

Removing the uint64 merge makes HAL detect the fdi file again.

The Launchpad bug report: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/116264

The latest version of HAL in Ubuntu is 0.5.11~rc2-1ubuntu8.1

[Sense Egbert Hofstede (sense)]

Thank you for reporting this bug. However, it has been a while since you've reported it and meanwhile Hardy Heron has already been released. Do you still experience this issue with the latest version of HAL?

[Thorsten (ungesaeuertesbrot)]

I had already forgotten about this bug since the problem it caused me was fixed elsewhere. But yes, it still exists in the current version of hal in hardy. The following fdi file shows the problem. Needs to be put into /etc/hal/fdi/information:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
        <device>
                <match <email address hidden>:storage.cdrom.cdr" bool="true">
                <match key="block.is_volume" bool="true">
                        <merge key="foo" type="string">foo</merge>
                        <merge key="bar" type="uint64">12345</merge>
                </match>
                </match>
        </device>
</deviceinfo>

In this form the file is completely ignored. Once you remove (or comment out) the line <merge key="bar" type="uint64">12345</merge> the property foo appears in the volume properties when you insert a cdrom. This is independent of the name or value of the key. I remember that other types such as int continued working. Also in the current hal documentation the type is still present with the exact same name and some properties like volume.size of block devices still use it.

[Sense Egbert Hofstede (sense)]

This bug can be confirmed. I'm going to forward it upstream. Thank you for your fast response.

[Danny Kukawka (danny-kukawka)]

Created an attachment (id=17474)
fix for the bug

Without any deeper test.

[Danny Kukawka (danny-kukawka)]

I really don't understand why the Ubuntu guys (always) report such trivial bugs upstream without fixing them while you are able to confirm the bug. Sorry, but this behavior leaves bad karma!

[Sense Egbert Hofstede (sense)]

(In reply to comment #2)
> I really don't understand why the Ubuntu guys (always) report such trivial bugs
> upstream without fixing them while you are able to confirm the bug. Sorry, but
> this behavior leaves bad karma!
>

I think that was my fault. I triaged the bug and reported it upstream after it was confirmed. I'm not a developer by myself, so I didn't (have the time to) look if I could find the cause. I'm just a Bug Triager. ;)

Anyway, thank you for the fast response. I'll ask if someone can test this patch.

[Sense Egbert Hofstede (sense)]

I got a really fast response from Danny Kukawka who wrote this (untested) patch: http://bugs.freedesktop.org/attachment.cgi?id=17474
Could you try if this patch works, please?

[Thorsten (ungesaeuertesbrot)]

Well, I never tested a patch yet and wouldn't want to screw up my working system by messing around with hal. If there are some instructions on how to test a patch for ubuntu I'll gladly do that though.

[Thorsten (ungesaeuertesbrot)]

OK, I found the information on the ubuntu wiki and tested the patch. And yes, it works.

[Sense Egbert Hofstede (sense)]

The path has been tested and it works. It's not a very complex patch, so it isn't a surprise, but I thought it would be good to let you know.

[Danny Kukawka (danny-kukawka)]

Commited patch to git master.

[Martin Pitt (pitti)]

We have the latest upstream in Jaunty which includes this fix.