Henrique de Moraes Holschuh h...@debian.org writes:
On Sun, 26 Apr 2009, Matthew Garrett wrote:
Hal checks the drive capabilities and shouldn't be polling drives that
support async notifications. Is that code not working for you?
It is working fine, thanks for the head's up about it
On Mon, 27 Apr 2009, Bjørn Mork wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
On Sun, 26 Apr 2009, Matthew Garrett wrote:
Hal checks the drive capabilities and shouldn't be polling drives that
support async notifications. Is that code not working for you?
It is working
Henrique de Moraes Holschuh h...@debian.org wrote:
On Tue, 21 Apr 2009, Michael Biebl wrote:
powertop encourages to disable polling, so it is a big point.
I agree with you in general, but I doubt polling every 2 or 16 seconds will
make
any significant difference power consumption wise.
It
On Sun, 26 Apr 2009, Matthew Garrett wrote:
Henrique de Moraes Holschuh h...@debian.org wrote:
On Tue, 21 Apr 2009, Michael Biebl wrote:
powertop encourages to disable polling, so it is a big point.
I agree with you in general, but I doubt polling every 2 or 16 seconds
will make
any
On Tue, 21 Apr 2009, Michael Biebl wrote:
powertop encourages to disable polling, so it is a big point.
I agree with you in general, but I doubt polling every 2 or 16 seconds will
make
any significant difference power consumption wise.
It does. It won't be much, but still... in any
Matthew Garrett mgarr...@chiark.greenend.org.uk writes:
powertop makes various recommendations that are only useful in very
specific circumstances. Disabling polling in hal saves you a small (and
probably not useful in the real world) amount of power, but is required
to get to the number of
Michael Biebl bi...@debian.org writes:
See the hal-disable-polling man page. In short: hardware support for MMC media
change notification is broken.
Err. You are using the broken firmware argument both ways.
You should follow your own advice regarding the drives spinning up:
Implement a
Emilio Pozuelo Monfort wrote:
Giacomo A. Catenazzi wrote:
Emilio Pozuelo Monfort wrote:
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Giacomo Catenazzi wrote:
For these two reason (power and security), I think Debian should offer
a debconf question, (medium priority), about disabling
Didier Raboud wrote:
Giacomo A. Catenazzi wrote:
Emilio Pozuelo Monfort wrote:
No, users should file bugs if their HW is broken so that those can be
blacklisted too.
Are you joking?
For one year that user could not use debian stable?
BTW for one reported bug, there are 10 unreported bugs.
Gunnar Wolf wrote:
Roger Leigh dijo [Wed, Apr 22, 2009 at 03:49:54PM +0100]:
How shall I answer that?
I know that I myself use auto-mounting extensively and also don't expect my
father to type someting like mount /dev/hdc /mnt/cdrom
Absolutely, but this is a separate issue. You can still,
Bjørn Mork wrote:
Michael Biebl bi...@debian.org writes:
See the hal-disable-polling man page. In short: hardware support for MMC
media
change notification is broken.
Err. You are using the broken firmware argument both ways.
You should follow your own advice regarding the drives
bj...@mork.no wrote:
You'll save between 0.5 and 1.5 W by enabling SATA Aggressive Link Power
Management according to http://www.lesswatts.org/tips/disks.php As this
definitely is measurable, I assume that your measurements have been done
without enabling ALPM? Or maybe the power saving
bj...@mork.no wrote:
Michael Biebl bi...@debian.org writes:
See the hal-disable-polling man page. In short: hardware support for MMC
media
change notification is broken.
Err. You are using the broken firmware argument both ways.
You should follow your own advice regarding the drives
Giacomo Catenazzi wrote:
Emilio Pozuelo Monfort wrote:
Giacomo A. Catenazzi wrote:
Emilio Pozuelo Monfort wrote:
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Giacomo Catenazzi wrote:
For these two reason (power and security), I think Debian should offer
a debconf question, (medium
Michael Biebl wrote:
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
hal does not poll removable disks, it does though poll
Giacomo Catenazzi c...@debian.org wrote:
Recently it was discovered that a blinking cursor consumes a lot of power
(blink is normally between 1 and 2 second interval).
I think it should be the same, in this case.
Take into account that both uses hardware, thus not allowing some chips
to rests.
Steve Langasek vor...@debian.org wrote:
On Tue, Apr 21, 2009 at 06:13:47PM +0200, Michael Biebl wrote:
powertop encourages to disable polling, so it is a big point.
I agree with you in general, but I doubt polling every 2 or 16 seconds will
make
any significant difference power consumption
Giacomo Catenazzi wrote:
Michael Biebl wrote:
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
hal does not poll removable
Giacomo Catenazzi wrote:
For these two reason (power and security), I think Debian should offer
a debconf question, (medium priority), about disabling pooling.
Sorry, but this is certainly not going to happen.
The blacklist for faulty drives on the other hand, installed by default, might
On Tue, Apr 21, 2009 at 06:13:47PM +0200, Michael Biebl wrote:
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
powertop encourages to disable polling, so it is a big point.
I agree with you in general, but I doubt polling every 2 or 16 seconds will
make
any significant difference power
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Giacomo Catenazzi wrote:
For these two reason (power and security), I think Debian should offer
a debconf question, (medium priority), about disabling pooling.
Sorry, but this is certainly not going to happen.
Why not? Is it so bad to
Michael Biebl wrote:
Giacomo Catenazzi wrote:
Michael Biebl wrote:
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
hal
Emilio Pozuelo Monfort wrote:
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Giacomo Catenazzi wrote:
For these two reason (power and security), I think Debian should offer
a debconf question, (medium priority), about disabling pooling.
Sorry, but this is certainly not going to happen.
Michael Biebl wrote:
Giacomo Catenazzi wrote:
For these two reason (power and security), I think Debian should offer
a debconf question, (medium priority), about disabling pooling.
Sorry, but this is certainly not going to happen.
Why not? Is it so bad to give user a choice?
The
Giacomo A. Catenazzi wrote:
Emilio Pozuelo Monfort wrote:
No, users should file bugs if their HW is broken so that those can be
blacklisted too.
Are you joking?
For one year that user could not use debian stable?
BTW for one reported bug, there are 10 unreported bugs.
I try hard to
Roger Leigh dijo [Wed, Apr 22, 2009 at 03:49:54PM +0100]:
How shall I answer that?
I know that I myself use auto-mounting extensively and also don't expect my
father to type someting like mount /dev/hdc /mnt/cdrom
Absolutely, but this is a separate issue. You can still, in any desktop
Giacomo A. Catenazzi wrote:
Emilio Pozuelo Monfort wrote:
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Giacomo Catenazzi wrote:
For these two reason (power and security), I think Debian should offer
a debconf question, (medium priority), about disabling pooling.
Sorry, but this is
Giacomo A. Catenazzi wrote:
Emilio Pozuelo Monfort wrote:
No, users should file bugs if their HW is broken so that those can be
blacklisted too.
Are you joking?
For one year that user could not use debian stable?
This says far more about the disadvantages to our stable release policy
Giacomo A. Catenazzi c...@debian.org wrote:
Michael Biebl wrote:
It makes no measurable difference here on my laptop (nx7000) running Debian
Lenny.
ok, this confirm also Matthew Garrett analysis, and it is good.
But so why powertop reccomend to disable pooling?
powertop makes various
Le mercredi 22 avril 2009 à 14:50 -0400, David Nusinow a écrit :
This says far more about the disadvantages to our stable release policy
than it does about hal or any other specific piece of software in the
release.
And actually this is simply untrue. I’ve seen similar fixes accepted in
Josselin Mouette j...@debian.org writes:
If it’s just your decision, why are you bitching on this list?
That's a good question. It was fun for a while. But I think the
spectators are getting a bit bored. I'll stop now. Thanks for your
answers. Believe it or not, but I've learned a lot
Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
hal does not poll removable disks, it does though poll cd-rom drives for new
media and afaik there is no
Giacomo A. Catenazzi wrote:
Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
hal does not poll removable disks, it does though poll cd-rom drives for
new
On Tue, Apr 21, 2009 at 06:13:47PM +0200, Michael Biebl wrote:
powertop encourages to disable polling, so it is a big point.
I agree with you in general, but I doubt polling every 2 or 16 seconds will
make
any significant difference power consumption wise.
If it requires the drive to be
Josselin Mouette j...@debian.org writes:
Le jeudi 16 avril 2009 à 15:06 +0200, Bjørn Mork a écrit :
a) laptop keys remapped or disappearing (might be caused by the driver -
I don't know)
Yes, they are remapped to the standard XF86* names, so that applications
configuring shortcuts
Bjørn Mork wrote:
[lot of fud deleted]
The hal default polling removable disks is annoying, useless, and an
example of bad hal design. You may of course continue to ignore this by
claiming that I don't know what I'm talking about. Unfortunately, it
Seems you are confusing a lot of
Julien Cristau wrote:
hal breaks existing working configurations without warnings. The simple
test case is using a non-US keyboard properly configured as such in
xorg.conf. Introduce evdev/hal and watch users get frustrated. The
problem of course: keyboard layout cannot be
On Mon, Apr 20, 2009 at 16:24:59 +0200, Rene Engelhard wrote:
Julien Cristau wrote:
hal breaks existing working configurations without warnings. The simple
test case is using a non-US keyboard properly configured as such in
xorg.conf. Introduce evdev/hal and watch users get
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
Bjørn Mork wrote:
[lot of fud deleted]
The hal default polling removable disks is annoying, useless, and an
example of bad hal design. You may of course continue to ignore this by
claiming that I don't know what I'm
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
hal does not poll removable disks, it does though poll cd-rom drives for new
media and afaik there is no way around that if you want automount for cdrom
drives to work
Spinning up the CD drive every 30
On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
hal does not poll removable disks, it does though poll cd-rom drives for
new
media and afaik there is no way around that if you want
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote:
Roger Leigh wrote:
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
hal does not poll removable disks, it does though poll cd-rom drives for
new
media and afaik there is no way around that if
Le lundi 20 avril 2009 à 18:26 +0200, Michael Biebl a écrit :
Second, you can very easily disable this behaviour: man hal-disable-polling
Great, but it's still not the default behaviour. Does every
user need to find out how to disable it after they become sufficiently
annoyed by the
Twas brillig at 19:36:30 20.04.2009 UTC+02 when j...@debian.org did gyre and
gimble:
Why should *every* user need to find out? Seems to me as if you are
exaggerating in order to make a point. For the majority of users it
just works, that's why it is the default.
JM Why not introduce a
Le lundi 20 avril 2009 à 10:26 +0200, Bjørn Mork a écrit :
I prefer non-broken defaults. hal defaults are broken. No, the keys are
not always mapped to standard XF86* names. They are sometimes mapped
into the blue.
See e.g. bug #504643, which explains my disappearing keys. Finding it
Josselin Mouette wrote:
Le lundi 20 avril 2009 à 18:26 +0200, Michael Biebl a écrit :
Second, you can very easily disable this behaviour: man hal-disable-polling
Great, but it's still not the default behaviour. Does every
user need to find out how to disable it after they become sufficiently
Le lundi 20 avril 2009 à 19:43 +0200, Michael Biebl a écrit :
Josselin Mouette wrote:
Why not introduce a FDI that disables polling for drives that are known
to be broken?
You mean like
/usr/share/doc/hal/examples/no-cd-media-check.fdi
and the note in README.Debian?
Something like this,
Le mardi 21 avril 2009 à 00:38 +0700, Mikhail Gusarov a écrit :
Twas brillig at 19:36:30 20.04.2009 UTC+02 when j...@debian.org did gyre and
gimble:
JM Why not introduce a FDI that disables polling for drives that are
JM known to be broken?
Most of ATAPI CDROMs are, so it makes HAL media
Josselin Mouette j...@debian.org writes:
Le lundi 20 avril 2009 à 10:26 +0200, Bjørn Mork a écrit :
I prefer non-broken defaults. hal defaults are broken. No, the keys are
not always mapped to standard XF86* names. They are sometimes mapped
into the blue.
See e.g. bug #504643, which
Le lundi 20 avril 2009 à 22:13 +0200, Bjørn Mork a écrit :
So, the HAL defaults are broken *for one keyboard model*.
Make that for every keyboard I'm using. Why would the number of
working keyboards matter? If you care about such statistics you should
probably use Windows. It works for
On Mon, Apr 20 2009, Josselin Mouette wrote:
Le lundi 20 avril 2009 à 10:26 +0200, Bjørn Mork a écrit :
I prefer non-broken defaults. hal defaults are broken. No, the keys are
not always mapped to standard XF86* names. They are sometimes mapped
into the blue.
See e.g. bug #504643,
On Wed, Apr 15, 2009 at 10:25:36AM +0200, Bjørn Mork wrote:
I still haven't got a clue how to really fix this, but have resorted to
this for now:
?xml version=1.0 encoding=UTF-8?
deviceinfo version=0.2
device
match key=info.capabilities contains=input.keyboard
merge
Le jeudi 16 avril 2009 à 00:34 +0200, Bjørn Mork a écrit :
My list of hal related regressions are
a) laptop keys remapped or disappearing (might be caused by the driver -
I don't know)
Yes, they are remapped to the standard XF86* names, so that applications
configuring shortcuts can have
Josselin Mouette j...@debian.org writes:
Le jeudi 16 avril 2009 à 00:34 +0200, Bjørn Mork a écrit :
My list of hal related regressions are
a) laptop keys remapped or disappearing (might be caused by the driver -
I don't know)
Yes, they are remapped to the standard XF86* names, so that
Le jeudi 16 avril 2009 à 15:06 +0200, Bjørn Mork a écrit :
a) laptop keys remapped or disappearing (might be caused by the driver -
I don't know)
Yes, they are remapped to the standard XF86* names, so that applications
configuring shortcuts can have sensible defaults.
So you
On Thu, 2009-04-16 at 10:18 +0200, Gabor Gombas wrote:
...except with latest hal/X.org/whatever it also stopped working. Latest
X.org pulled in console-setup, and now the settings under
/etc/hal/fdi/policy get ignored. What a mess.
that's called a bug. ranting on mailing lists doesn't do
Julien Cristau jcris...@debian.org writes:
On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote:
On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote:
As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards
standardizing on one power management stack in Debian
On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote:
Well, you can always argue that the rest can be fixed. Provide patches
etc. But the point is that hal implies a regression for many (most?)
users.
please stop the FUD.
hal breaks existing working configurations without warnings. The
Le mercredi 15 avril 2009 à 10:25 +0200, Bjørn Mork a écrit :
False. All users want all things to work. The just is nice to have,
but not important. It's infinitely better to have to configure things
than not being able to.
Bullshit. This is just true for nerds who want to spend their whole
2009/4/12 Raphael Hertzog hert...@debian.org:
Expect grumpy people every time that you add something new that they have
to learn. I also had troubles with hal and X when I tried the X servers in
experimental. But I have not read any serious criticism based on technical
facts in the bug report
On Wed, Apr 15, 2009 at 05:58:49PM +0200, Luca Niccoli lultimou...@gmail.com
wrote:
2009/4/12 Raphael Hertzog hert...@debian.org:
Expect grumpy people every time that you add something new that they have
to learn. I also had troubles with hal and X when I tried the X servers in
[not CC-ing the RFA, I did it by mistake before and I don't think this
is so relevant to that specific matter]
2009/4/15 Mike Hommey m...@glandium.org:
Bug count is not a good metric. Take a look at the bug count for linux-2.6,
glibc, iceweasel...
Fair enough.
Is there a convenient way to
Julien Cristau jcris...@debian.org writes:
On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote:
Well, you can always argue that the rest can be fixed. Provide patches
etc. But the point is that hal implies a regression for many (most?)
users.
please stop the FUD.
Sorry. You're right.
On Sun, 12 Apr 2009 15:15:56 +0200
Raphael Hertzog hert...@debian.org wrote:
That said, it looks like that having things just work on the desktop
require hal anyway and I fail to see why we would have to reinvent
other solutions (like continuing to maintain/create many hacks in
acpi-support)
On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote:
As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards
standardizing on one power management stack in Debian (and not install 3 by
default [1]), i.e. I'd support in phasing out acpi-support and would gladly
On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote:
On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote:
As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards
standardizing on one power management stack in Debian (and not install 3 by
default [1]), i.e.
On Sun, Apr 12, 2009 at 01:11:26PM +0100, Julien Cristau wrote:
515214 isn't most users. most users just want things to work.
But then 515214 appears to be at least a significant amount of users. Anyway,
having things just work and being able to run a system without hal do not
contradict each
On Sun, 2009-04-12 at 15:01 +0200, Michael Meskes wrote:
On Sun, Apr 12, 2009 at 01:11:26PM +0100, Julien Cristau wrote:
515214 isn't most users. most users just want things to work.
But then 515214 appears to be at least a significant amount of users. Anyway,
no, it doesn't.
having
On Sun, 12 Apr 2009, Michael Meskes wrote:
But then 515214 appears to be at least a significant amount of users. Anyway,
having things just work and being able to run a system without hal do not
contradict each other.
Expect grumpy people every time that you add something new that they have
to
On Sun, 12 Apr 2009 13:11:26 +0100, Julien Cristau
jcris...@debian.org wrote:
515214 isn't most users. most users just want things to work.
While were at it, I find it unacceptable to set a bug wontfix without
explanation.
Greetings
Marc
--
-- !! No
[Michael Biebl]
As (co-)maintainer of pm-utils and hal, I'd prefer if we could work
towards standardizing on one power management stack in Debian (and
not install 3 by default [1]), i.e. I'd support in phasing out
acpi-support and would gladly accept patches for hal and pm-utils
which add (if
On Tue, Apr 07, 2009 at 01:26:18PM +0200, Petter Reinholdtsen wrote:
[Michael Biebl]
As (co-)maintainer of pm-utils and hal, I'd prefer if we could work
towards standardizing on one power management stack in Debian (and
not install 3 by default [1]), i.e. I'd support in phasing out
On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
I'm putting the acpi-support package up for adoption. The RFA bug is here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683
Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes,
the acpi team will
Hi Steve,
On Mon, April 6, 2009 05:44, Steve Langasek wrote:
On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
1. The upstream for this package is Ubuntu. Ubuntu has never been very
cooperative at accepting changes, until recently: our contact Steve
Langasek has indicated that he
Michael Meskes wrote:
On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
I'm putting the acpi-support package up for adoption. The RFA bug is here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683
Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes,
On Mon, 06 Apr 2009, Bart Samwel wrote:
black hole. /rant Things suddenly got much easier when I got into direct
contact with you. But I shouldn't be blaming Ubuntu, my expectations just
didn't match the way Ubuntu works.
To be fair, I proposed co-maintenance to Matthew Garrett when I
Steve Langasek wrote:
On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
1. The upstream for this package is Ubuntu. Ubuntu has never been very
cooperative at accepting changes, until recently: our contact Steve
Langasek has indicated that he is interested in merging most or all of
Dear all,
I'm putting the acpi-support package up for adoption. The RFA bug is here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683
I have copied the text of the bug report below (since my mail client did
not allow me to set X-Debbugs-CC). If anyone is interested to adopt this
package,
On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
1. The upstream for this package is Ubuntu. Ubuntu has never been very
cooperative at accepting changes, until recently: our contact Steve
Langasek has indicated that he is interested in merging most or all of
our changes, provided
79 matches
Mail list logo
