| Summary: | [stdout/stderr] hal-find-by-property: command not found message on hal-less system | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdebase | Assignee: | Michele Calgaro <michele.calgaro> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugwatch, darrella, michele.calgaro, slavek.banko |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2014 | ||
| Attachments: | hal 'device.c' file | ||
|
Description
Darrell
2013-08-12 20:25:04 CDT
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.
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
>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.
> 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)
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. I haven't seen the message since I started monitoring. 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. (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. > 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.
|