hal ignores fdi files containing uint64 merges

Bug #116264 reported by Thorsten on 2007-05-22
6
Affects Status Importance Assigned to Milestone
HAL
Fix Released
Medium
hal (Ubuntu)
Low
Unassigned

Bug Description

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.

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) wrote :

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?

Changed in hal:
status: New → Incomplete
Thorsten (ungesaeuertesbrot) wrote :

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) wrote :

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

Changed in hal:
importance: Undecided → Low
status: Incomplete → Confirmed

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

Without any deeper test.

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!

(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) wrote :

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) wrote :

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) wrote :

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

Changed in hal:
status: Unknown → Confirmed

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.

Commited patch to git master.

Changed in hal:
status: Confirmed → Fix Released
Martin Pitt (pitti) wrote :

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

Changed in hal:
status: Confirmed → Fix Released
Changed in hal:
importance: Unknown → Medium
Changed in hal:
importance: Medium → Unknown
Changed in hal:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.