TDE R14 and above does not require HAL; marking SRUONLY

AFAIK the last official version of HAL was 0.5.14.
I guess this 0.5.15 version means that the patch is so big, that it deserves a version update.

Where do these patches come from ? I found equivalent things in Arch Linux ...

(In reply to comment #2)
> Where do these patches come from ? I found equivalent things in Arch Linux ...
The patches from here: http://git.altlinux.org/people/rom_as/packages/hal.git

Created attachment 1496 [details]
Concrete my path for allow events watch direct from UDEV.

Tim, Francois, Slavek,
since v14.0.0 does not require hal anymore, what should we do with this bug? AFAIK, we have no plan for a 3.5.13.3 release. 
I suggest we close it as a WONTFIX

(In reply to Michele Calgaro from comment #5)
> AFAIK, we have no plan for a 3.5.13.3 release. 
Too bad!

Then I will continue for fix SRU, LTS branch but TDE valuable for me by first and mostly single SRU/LTS DE.

For new bugs, problems and instability I will go to new KDE4 and Plasma5.

> Then I will continue for fix SRU, LTS branch but TDE valuable for me by first
> and mostly single SRU/LTS DE.
> For new bugs, problems and instability I will go to new KDE4 and Plasma5.

Hi Roman, why wouldn't you consider to upgrade to v14.0.0 when it is ready? As far as I have heard from users who have used both 3.5.13.x and the nightly builds of v14.0.0, v14.0.0 is more stable and moreover there are several improvements over 3.5.13.2. I myself have been using the development version for over a year and haven't had major problems with that.

Anyhow, as said in comment 5, the question for Tim, Francois and Slavek remains.
Since v14.0.0 does not require hal anymore, what should we do with this bug?

(In reply to Michele Calgaro from comment #7)
> Hi Roman, why wouldn't you consider to upgrade to v14.0.0 when it is ready?
At first v14.0.0 is official unreleased yet, so unstable and is not LTS apparently.
Second I need full building change include renaming  kde* to tde* packages for maintaining by me ALTLinux distributive.
Thirds, to present problems into SRU I get new from v14.0.0 as from core and into more KDE3 independent applications.

> Anyhow, as said in comment 5, the question for Tim, Francois and Slavek
> remains.
> Since v14.0.0 does not require hal anymore, what should we do with this bug?
But HAL uses also into kpowersave, for example, which build without will perform some features leaks.
Besides what the problem with optional using HAL or not?

Hi Roman, 
I am not questioning your reasons, just trying to give my opinion as a TDE developer.

> Besides what the problem with optional using HAL or not?
The problem with HAL is that it is being progressively phased out. For example Debian does not provide hal package anymore in testing for linux distros. It provides hal only on *bsd versions. As consequence, kpowersave doesn't build any more in such distro. Basically kpowersave is meant to be used on *bsd distros, while on linux one tdepowersave should be used (obviously I am talking about v14.0.0, not 3.5.13.2). ALTLinux for what I see on the internet, has a linux kernel, so you should have no problem with tdepowersave

> At first v14.0.0 is official unreleased yet, so unstable 
> and is not LTS apparently
1) not yet release: correct, we are working on it and should be out later this year
2) ... so unstable: depends on the meaning you give to stable :-) If stable = "changing" I agree since there are still things changing (even though not much any more). If stable = "buggy/locking up" I disagree.
3) is not LTS apparently: not sure where you read about LTS for 3.5.13.2 or 14.0.0. Anyhow R14 is the way forward for TDE and will have much more support and enhanchment than 3.5.13.2 (which is basically the final 3.5.13.x release).

Ok, I had a look at the patches. As for bug 2054, for what I can see, those patches are meant for the hal package, which is something provided externally of TDE. Those patches should be reported to the hal package maintainers, not here, since TDE source code does not contain hal package sources.

So I propose we close this bug (as well as bug 2054) as either INVALID or NOTOURPROBLEM.

Ok, I see what I was missing. My previous comment was partially incorrect.
Anyhow v14.0.0 is meant to be hal-free in Linux, so these patches no longer apply.
After discussing with Slavek, we have decided to mark the bug as SRUONLY. At the moment there are no plans for a 3.5.13.3, but if one day it will, then the patch would come useful.

By the way, while the patch works well with kernel 3.14, with kernel 3.16 is again a problem.

(In reply to Slávek Banko from comment #12)
> By the way, while the patch works well with kernel 3.14, with kernel 3.16 is
> again a problem.
With kernel 3.17.2 the patch work fine and genericly I have not any broken for the path Linux configuration.

HAL is no longer used/supported. I reckon we can close this bug because the patches are no longer relevant?
Slavek, what do you think?

On modern systems with udev-systemd, udev has set that it collides with hal. So it could not be installed on such systems. There are no plans to maintain our fork of hal.