1 |
Am Freitag, 6. April 2007 20:54:28 schrieb Doug Goldstein: |
2 |
> Michael Cummings wrote: |
3 |
> steev got hal 0.5.9 into the tree (it's masked) and we've both been |
4 |
> solidly kicking it to behave how we need it. Anyone interested in |
5 |
> testing it out would be very helpful. |
6 |
> |
7 |
> I can promise it won't come to your house and beat up your dog. But I |
8 |
> can't promise you might have some little glitches here and there that I |
9 |
> end up asking you to help debug. Overall it's a much more enjoyable |
10 |
> version to work with then 0.5.7 and 0.5.8 ever were. We're currently |
11 |
> sitting at 4 patches and that number will probably move to 5 over the |
12 |
> next few days. They're fairly straight forward and not to difficult to |
13 |
> manage. |
14 |
|
15 |
It works really fine here (finally, selecting CPU scaling schemes works again |
16 |
in KPowersave). |
17 |
|
18 |
The only thing, that bugged me was after installing it, a lot of daemons* |
19 |
crashed because hald did an autoreload because of it's inotify feature to |
20 |
reload rules as soon as there are changes to it's rules files. |
21 |
|
22 |
*daemons/applications that crashed: |
23 |
dbus |
24 |
powersaved -> KPowersave |
25 |
Networkmanager -> KNetworkmanager |
26 |
|
27 |
Also, the new hald didn't want to start, because dbus had crashed because of |
28 |
the auto-hald-reload. |
29 |
|
30 |
So we need to prevent this before it goes stable: |
31 |
|
32 |
a) print out a big fat warning before doing the update / make the update |
33 |
interactive, so we make sure, the user knows about the dangers |
34 |
|
35 |
b) find a way, to postpone the reload until the next reboot / disable |
36 |
auto-reloading for the currently running session |
37 |
|
38 |
This were the only problems I could find so far. |
39 |
What I really liked about the update: didn't have to re-emerge |
40 |
(revdep-rebuild) a single package.. ;-) |
41 |
|
42 |
Regards, |
43 |
|
44 |
Elias P. |