By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1624 - [stdout/stderr] hal-find-by-property: command not found message on hal-less system
Summary: [stdout/stderr] hal-find-by-property: command not found message on hal-less s...
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: R14.0.0 [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Michele Calgaro
URL:
Depends on:
Blocks: 2014
  Show dependency treegraph
 
Reported: 2013-08-12 20:25 CDT by Darrell
Modified: 2014-05-27 04:11 CDT (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:


Attachments
hal 'device.c' file (161.36 KB, text/x-csrc)
2013-11-10 05:42 CST, Francois Andriot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2013-08-12 20:25:04 CDT
While troubleshooting and collecting information for bug reports 1615 and 1623, I noticed the following message in my xsession-errors log:

hal-find-by-property: command not found

I traced that message to tdebase/kdesktop/lock/lockprocess.cc:2405.

I am running Slackware 14.0, which does not have hal installed.
Comment 1 Francois Andriot 2013-11-10 05:42:07 CST
Created attachment 1622 [details]
hal 'device.c' file

It is likely that we should write the same detection mechanism in TDE HW library than there was in HAL.

Look at "pnp_add" function, line 2219. The "tabletpc" property is set at line 2251.
Comment 2 Michele Calgaro 2014-05-17 00:32:51 CDT
Darrell,
the message appears because tdebase was compiled with option WITH_HAL. Excerpt from lockprocess.cc:

#ifdef WITH_HAL
        int status = system( "hal-find-by-property --key system.formfactor.subtype --string tabletpc" );
//        status = 0; // enable for testing
        run_vkbd = ( WIFEXITED( status ) && WEXITSTATUS( status ) == 0
            && !TDEStandardDirs::findExe( "xvkbd" ).isEmpty()) ? 1 : 0;
#else // WITH_HAL
        run_vkbd = (!TDEStandardDirs::findExe( "xvkbd" ).isEmpty());
#endif // WITH_HAL

On Slackware 14.0 you don't have hal installed, so you should compile with the following options:
-DWITH_HAL="OFF" -DWITH_TDEHWLIB="ON" 

If you do, the error message should not appear anymore.

Before I close the bug, can you test and let me know?
Thanks
Comment 3 Darrell 2014-05-17 09:44:03 CDT
>Before I close the bug, can you test and let me know?

With Slackware 14.0 I have always compiled with the following:

-DWITH_HAL=OFF \
-DWITH_TDEHWLIB=ON \

I do not remember the circumstances under which I saw the message and filed the bug report. I have a small watchdog script that monitors specific stdout/stderr messages. I will watch for this specific message.
Comment 4 Michele Calgaro 2014-05-18 00:01:11 CDT
> I will watch for this specific message.

Thanks Darrell. I would say that if you don't see the message for a few days we could safely close this bug.
Perhaps at the time of the report, tdebase was mistakenly compiled with hal support (if I remember correctly, several months ago you were trying to compile 3.5.13.2 as well, so perhaps the build options got mistakenly mixed up... just a guess)
Comment 5 Michele Calgaro 2014-05-26 21:57:29 CDT
Darrell,
have you seen the 'hal-find-by-property' message recently?
If not, would it be ok to close this bug? As I explained, it should have been the result of a mistaken configuration used when building tdebase.
You can always reopen the bug if you see the message again.
Comment 6 Darrell 2014-05-26 22:48:16 CDT
I haven't seen the message since I started monitoring.
Comment 7 Michele Calgaro 2014-05-26 23:30:01 CDT
Ok, thanks Darrell.
Since I think the message was the result of a mistaken (mixed up?) configuration used when building tdebase, I am closing this bug as invalid.
Feel free to reopen it any time if you see the message again.
Comment 8 Slávek Banko 2014-05-27 01:42:51 CDT
(In reply to Michele Calgaro from comment #7)
> Ok, thanks Darrell.
> Since I think the message was the result of a mistaken (mixed up?)
> configuration used when building tdebase, I am closing this bug as invalid.
> Feel free to reopen it any time if you see the message again.

Note that bug report from Darrell was in August, while the part from commit b876907e whose you mention in the comment 2, is in December. The message was not accidental, nor disappeared "self", but was solved by commit b876907e.

The question is whether to add the code to testing device type using tdehw-lib. Alternatively, add also code for use kvkbd.
Comment 9 Michele Calgaro 2014-05-27 04:11:01 CDT
> Note that bug report from Darrell was in August, while the part from commit
> b876907e whose you mention in the comment 2, is in December. The message was
> not accidental, nor disappeared "self", but was solved by commit b876907e.
Ah, ah! That explains why Darrell originally saw the bug and now he doesn't. Good thing to keep in mind for the future to look at if and when the code was changed from the time the bug was filed :-)
Thanks for the additional info.