14 Feb
2012
14 Feb
'12
12:58 a.m.
Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is
still relevant, but HAL and udev stopped the boot process on my Arch box today.
Calvin had the issue that I believe he solved by removing an offending udev
rule[1]. That raised the question to me whether there is some standardization
that HAL will require across distros in order to support TDE or if there is some
part of udev that is needed to support HAL?
Arch no longer provides HAL as a standard package. I believe what triggered
the boot fail today was the loss of the 'udev-compat' package (unconfirmed).
I'm
still digging into this, but if HAL will be required for TDE, then should we
look into either insuring that a generic HAL version that is compatible with
upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on
either, but I thought I would raise the issues to those smarter than I am in
case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just
a matter of the individual distro TDE builders to sort out? What worries me is
Arch no longer packages HAL and the version we have in the user supported
repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch*
file. If this is where all the distros are ultimately going, we may be better
served by deciding how to handle it now rather than waiting until we run into
build problems later...
Footnote [1]: (which we are still trying to determine exactly what he removed :)
--
David C. Rankin, J.D.,P.E.
14 Feb
14 Feb
9:49 a.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On Tue, Feb 14, 2012 at 1:58 AM, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is
still relevant, but HAL and udev stopped the boot process on my Arch box today.
Calvin had the issue that I believe he solved by removing an offending udev
rule[1]. That raised the question to me whether there is some standardization
that HAL will require across distros in order to support TDE or if there is some
part of udev that is needed to support HAL?
Calvin got it to work?
Arch no longer provides HAL as a standard package. I
believe what triggered
the boot fail today was the loss of the 'udev-compat' package (unconfirmed).
I'm
still digging into this, but if HAL will be required for TDE, then should we
look into either insuring that a generic HAL version that is compatible with
upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on
either, but I thought I would raise the issues to those smarter than I am in
case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just
a matter of the individual distro TDE builders to sort out? What worries me is
Arch no longer packages HAL and the version we have in the user supported
repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch*
file. If this is where all the distros are ultimately going, we may be better
served by deciding how to handle it now rather than waiting until we run into
build problems later...
This may be an arch-only problem for a while. From what I understood
arch uses last bleeding-edge version of udev, where other distros are
using older version.
Trinity team doesn't maintain hal, so it is something for the hal
package maintainers to fix.
Anyway I'm looking into it. Since I haven't updated my arch box yet, I
recovered error that I was getting for some time, but never actually
figured that it could cause problems in the future:
everything.log.2:Feb 1 05:15:16 localhost udevd[141]:
RUN+="socket:..." support will be removed from a future udev release.
Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use
libudev to subscribe to events.
Footnote [1]: (which we are still trying to determine
exactly what he removed :)
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
12:32 p.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On Tue, Feb 14, 2012 at 10:49 AM, Pawel Soltys <sh4dou(a)gmail.com> wrote:
On Tue, Feb 14, 2012 at 1:58 AM, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
Strangely enough... for me everything works well and starts well after
upgrade. I still get the previously stated errors, but I don't have
hangups of any sort.
Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is
still relevant, but HAL and udev stopped the boot process on my Arch box today.
Calvin had the issue that I believe he solved by removing an offending udev
rule[1]. That raised the question to me whether there is some standardization
that HAL will require across distros in order to support TDE or if there is some
part of udev that is needed to support HAL?
Calvin got it to work?
Arch no longer provides HAL as a standard
package. I believe what triggered
the boot fail today was the loss of the 'udev-compat' package (unconfirmed).
I'm
still digging into this, but if HAL will be required for TDE, then should we
look into either insuring that a generic HAL version that is compatible with
upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on
either, but I thought I would raise the issues to those smarter than I am in
case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just
a matter of the individual distro TDE builders to sort out? What worries me is
Arch no longer packages HAL and the version we have in the user supported
repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch*
file. If this is where all the distros are ultimately going, we may be better
served by deciding how to handle it now rather than waiting until we run into
build problems later...
This may be an arch-only problem for a while. From what I understood
arch uses last bleeding-edge version of udev, where other distros are
using older version.
Trinity team doesn't maintain hal, so it is something for the hal
package maintainers to fix.
Anyway I'm looking into it. Since I haven't updated my arch box yet, I
recovered error that I was getting for some time, but never actually
figured that it could cause problems in the future:
everything.log.2:Feb 1 05:15:16 localhost udevd[141]:
RUN+="socket:..." support will be removed from a future udev release.
Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use
libudev to subscribe to events.
> Footnote [1]: (which we are still trying to determine exactly what he removed :)
>
> --
> David C. Rankin, J.D.,P.E.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
> For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
> Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/
> Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
> 
5:04 p.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On 14 February 2012 07:32, Pawel Soltys <sh4dou(a)gmail.com> wrote:
On Tue, Feb 14, 2012 at 10:49 AM, Pawel Soltys
<sh4dou(a)gmail.com> wrote:
Even if HAL is still working - it will break in upcomping udev
versions unless we get rid of that rule, and add a patch to hal to
subscribe to the changes via libudev instead.
Calvin
On Tue, Feb 14, 2012 at 1:58 AM, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
Strangely enough... for me everything works well and starts well after
upgrade. I still get the previously stated errors, but I don't have
hangups of any sort.
Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is
still relevant, but HAL and udev stopped the boot process on my Arch box today.
Calvin had the issue that I believe he solved by removing an offending udev
rule[1]. That raised the question to me whether there is some standardization
that HAL will require across distros in order to support TDE or if there is some
part of udev that is needed to support HAL?
Calvin got it to work?
Arch no longer provides HAL as a standard
package. I believe what triggered
the boot fail today was the loss of the 'udev-compat' package (unconfirmed).
I'm
still digging into this, but if HAL will be required for TDE, then should we
look into either insuring that a generic HAL version that is compatible with
upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on
either, but I thought I would raise the issues to those smarter than I am in
case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just
a matter of the individual distro TDE builders to sort out? What worries me is
Arch no longer packages HAL and the version we have in the user supported
repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch*
file. If this is where all the distros are ultimately going, we may be better
served by deciding how to handle it now rather than waiting until we run into
build problems later...
This may be an arch-only problem for a while. From what I understood
arch uses last bleeding-edge version of udev, where other distros are
using older version.
Trinity team doesn't maintain hal, so it is something for the hal
package maintainers to fix.
Anyway I'm looking into it. Since I haven't updated my arch box yet, I
recovered error that I was getting for some time, but never actually
figured that it could cause problems in the future:
everything.log.2:Feb 1 05:15:16 localhost udevd[141]:
RUN+="socket:..." support will be removed from a future udev release.
Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use
libudev to subscribe to events.
> Footnote [1]: (which we are still trying to determine exactly what he removed :)
>
> --
> David C. Rankin, J.D.,P.E.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
> For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
> Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/
> Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
>
11:54 p.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On 02/14/2012 11:04 AM, Calvin Morrison wrote:
Pawel,
You must be living right! After full updates yesterday, my box locked when it
reached hal in the DAEMONS list. Normal kernel and LTS both locked (linux
3.2.5-1, and linux-lts 3.0.20-1) It was bad enough I had to boot to single user
mode just to get to boot. On 'init 3' it hung on hal again, but switching to
tty2, I was surprised that hal was actually running:
[17:47 providence:/etc/udev/rules.d] # ps ax | grep hal
22701 ? Ssl 0:00 /usr/sbin/hald
22702 ? S 0:00 hald-runner
22732 ? S 0:01 /usr/lib/hal/hald-addon-acpi
init 5 from tty3 brought up kdm from 3.5.12.
I have absolutely nothing in rules.d:
[17:47 providence:/etc/udev/rules.d] # l /etc/udev/rules.d/
total 8
drwxr-xr-x 2 root root 4096 Feb 8 07:54 .
drwxr-xr-x 3 root root 4096 Feb 13 13:40 ..
I built and updated hal from AUR to 0.5.14-7, and I still have no
/etc/udev/rules.d/90-hal.rules:2. Should I? I have remotely downgraded udev to
180-1 to see if that helps. I'll know tomorrow when I get to the office.
--
David C. Rankin, J.D.,P.E.
Strangely
enough... for me everything works well and starts well after
> upgrade. I still get the previously stated errors, but I don't have
> hangups of any sort.
>
Even if HAL is still working - it will break in upcomping udev
versions unless we get rid of that rule, and add a patch to hal to
subscribe to the changes via libudev instead.
Calvin
15 Feb
15 Feb
12:07 a.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On Wed, Feb 15, 2012 at 12:54 AM, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
On 02/14/2012 11:04 AM, Calvin Morrison wrote:
Pawel,
You must be living right! After full updates yesterday, my box locked when it
reached hal in the DAEMONS list. Normal kernel and LTS both locked (linux
3.2.5-1, and linux-lts 3.0.20-1) It was bad enough I had to boot to single user
mode just to get to boot. On 'init 3' it hung on hal again, but switching to
tty2, I was surprised that hal was actually running:
[17:47 providence:/etc/udev/rules.d] # ps ax | grep hal
22701 ? Ssl 0:00 /usr/sbin/hald
22702 ? S 0:00 hald-runner
22732 ? S 0:01 /usr/lib/hal/hald-addon-acpi
init 5 from tty3 brought up kdm from 3.5.12.
I have absolutely nothing in rules.d:
[17:47 providence:/etc/udev/rules.d] # l /etc/udev/rules.d/
total 8
drwxr-xr-x 2 root root 4096 Feb 8 07:54 .
drwxr-xr-x 3 root root 4096 Feb 13 13:40 ..
I built and updated hal from AUR to 0.5.14-7, and I still have no
/etc/udev/rules.d/90-hal.rules:2. Should I? I have remotely downgraded udev to
180-1 to see if that helps. I'll know tomorrow when I get to the office.
--
David C. Rankin, J.D.,P.E.
Strange. This.Is.Really.Strange.
On my pc I still have the /etc/udev/rules.d/90-ral.rules file, nothing
freezes and everything is ok. Am I the only one unaffected?
Though reports from different people have reached my about this kind
of breakage in hal. Calvin was looking on how to enable the hal to
cummunicate with udev using directly libudev and not dbus like it was
done before (I assume, since I don't know anything about hal
structure). Anyway try reading this:
https://bbs.archlinux.org/viewtopic.php?id=135672
People stated that addink two symlinks in their system fixed the problem.
ln -s /usr/bin/udevadm /sbin/udevadm
ln -s /usr/bin/udevd /sbin/udevd
The problem may be:
-due to final deprecation of configuration of udev through rules.d and
now the apps should use libudev
-or due to movement of the binaries from /sbin to /usr/bin
I'll try to reproduce your problem on one of my arch
virtualmachines... and see what happens.
Strangely
enough... for me everything works well and starts well after
> upgrade. I still get the previously stated errors, but I don't have
> hangups of any sort.
>
Even if HAL is still working - it will break in upcomping udev
versions unless we get rid of that rule, and add a patch to hal to
subscribe to the changes via libudev instead.
Calvin
1:19 a.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On Wed, Feb 15, 2012 at 1:07 AM, Pawel Soltys <sh4dou(a)gmail.com> wrote:
On Wed, Feb 15, 2012 at 12:54 AM, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
For everyone interested: I was able to fix
the problem. For
explanations read my latest comment in aur:
https://aur.archlinux.org/packages.php?ID=51454
On 02/14/2012 11:04 AM, Calvin Morrison wrote:
Pawel,
You must be living right! After full updates yesterday, my box locked when it
reached hal in the DAEMONS list. Normal kernel and LTS both locked (linux
3.2.5-1, and linux-lts 3.0.20-1) It was bad enough I had to boot to single user
mode just to get to boot. On 'init 3' it hung on hal again, but switching to
tty2, I was surprised that hal was actually running:
[17:47 providence:/etc/udev/rules.d] # ps ax | grep hal
22701 ? Ssl 0:00 /usr/sbin/hald
22702 ? S 0:00 hald-runner
22732 ? S 0:01 /usr/lib/hal/hald-addon-acpi
init 5 from tty3 brought up kdm from 3.5.12.
I have absolutely nothing in rules.d:
[17:47 providence:/etc/udev/rules.d] # l /etc/udev/rules.d/
total 8
drwxr-xr-x 2 root root 4096 Feb 8 07:54 .
drwxr-xr-x 3 root root 4096 Feb 13 13:40 ..
I built and updated hal from AUR to 0.5.14-7, and I still have no
/etc/udev/rules.d/90-hal.rules:2. Should I? I have remotely downgraded udev to
180-1 to see if that helps. I'll know tomorrow when I get to the office.
--
David C. Rankin, J.D.,P.E.
Strange. This.Is.Really.Strange.
On my pc I still have the /etc/udev/rules.d/90-ral.rules file, nothing
freezes and everything is ok. Am I the only one unaffected?
Though reports from different people have reached my about this kind
of breakage in hal. Calvin was looking on how to enable the hal to
cummunicate with udev using directly libudev and not dbus like it was
done before (I assume, since I don't know anything about hal
structure). Anyway try reading this:
https://bbs.archlinux.org/viewtopic.php?id=135672
People stated that addink two symlinks in their system fixed the problem.
ln -s /usr/bin/udevadm /sbin/udevadm
ln -s /usr/bin/udevd /sbin/udevd
The problem may be:
-due to final deprecation of configuration of udev through rules.d and
now the apps should use libudev
-or due to movement of the binaries from /sbin to /usr/bin
I'll try to reproduce your problem on one of my arch
virtualmachines... and see what happens. Strangely
enough... for me everything works well and starts well after
> upgrade. I still get the previously stated errors, but I don't have
> hangups of any sort.
>
Even if HAL is still working - it will break in upcomping udev
versions unless we get rid of that rule, and add a patch to hal to
subscribe to the changes via libudev instead.
Calvin
4:20 p.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On 02/14/2012 07:19 PM, Pawel Soltys wrote:
For everyone interested: I was able to fix the
problem. For
explanations read my latest comment in aur:
https://aur.archlinux.org/packages.php?ID=51454
Your good! Thanks Pawel!
--
David C. Rankin, J.D.,P.E.
4:23 p.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On 15 February 2012 11:20, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
On 02/14/2012 07:19 PM, Pawel Soltys wrote:
Is this a longterm fix?
For everyone interested: I was able to fix the
problem. For
explanations read my latest comment in aur:
https://aur.archlinux.org/packages.php?ID=51454
Your good! Thanks Pawel!
10:30 p.m.
New subject: [trinity-devel] HAL & udev 181-2: rule issues? long term plans for HAL & impact on TDE?
On Wed, Feb 15, 2012 at 5:23 PM, Calvin Morrison <mutantturkey(a)gmail.com> wrote:
On 15 February 2012 11:20, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
Yes.
On 02/14/2012 07:19 PM, Pawel Soltys wrote:
Is this a longterm fix?
For everyone interested: I was able to fix the
problem. For
explanations read my latest comment in aur:
https://aur.archlinux.org/packages.php?ID=51454
Your good! Thanks Pawel!
4461
days inactive
4462
days old
9 comments
3 participants
participants (3)
-
Calvin Morrison -
David C. Rankin -
Pawel Soltys