2:52 p.m.
Hi,
First of all I want to mention that I'm very grateful for what the
people in Fedora Extras are doing.
I noticed that the number of packages in Fedora Extras (I'll use this
name to refer to the repository at fedora.us for the rest of this mail)
is growing rather slowly on average 2 package announcements a day for
november (which are both updates and new packages).
Also I noticed that the QA queue is really full. 295 packages are
waiting for QA. And Warren Togami seems to be the owner of about 80
percent of these. This guy must be making 40 hour days.
So I think he needs some help if we want to make fedora extras live up
to what's in the FAQ (Second bullet)
[Quote]
How does Fedora differ from FreshRPMS or other repositories?
* Fedora apt/yum enforces GPG signature checking for your protection.
* All other repositories are made by a single person. Fedora can
have a lot more packages, and of higher quality, because we have have
many package developers working together on a common goal.
[/Quote]
What I understand is that QA has to be approved by two developers and
one of a trusted fedora.us developer which check the spec files and stuff.
If there aren't too many developers this can take quite a while I guess.
I for one (as a non packager) wouldn't mind testing binary packages
which are in the testing or unstable queues and I'm interested in.
My proposal would be, to have packagers post a message that a RPM is in
the testing or unstable queue and needs testing. Normal users can then
just test if they work well and send a message back on the fedora-test
list if it works or doesn't. I saw that in Bugzilla that QA/packager
people are doing all this.
In my opinion this would save a lot of time for the real QA people,
because most of the bugs will be gone.
I think this is more or less how the testing of Fedora Core worked.
Any thoughts??
Jaap
4:01 p.m.
On Mon, 08 Dec 2003 21:52:35 +0100, Jaap A. Haitsma wrote:
First of all I want to mention that I'm very grateful for what
the
people in Fedora Extras are doing.
I noticed that the number of packages in Fedora Extras (I'll use this
name to refer to the repository at fedora.us for the rest of this mail)
is growing rather slowly on average 2 package announcements a day for
november (which are both updates and new packages).
Also I noticed that the QA queue is really full. 295 packages are
waiting for QA.
As mentioned earlier, a lot of those packages have a very special target
group and are in need of people who are familiar with the packaged
software. E.g. lots of programming languages.
And Warren Togami seems to be the owner of about 80
percent of these. This guy must be making 40 hour days.
He's just the default person who's assigned to new package requests. The
actual packager is listed in the "reporter" field. Package updates are
assigned to the actual package maintainer instead.
But otherwise it's correct that some of the packagers maintain many a high
number packages.
So I think he needs some help if we want to make fedora extras live
up
to what's in the FAQ (Second bullet)
[Quote]
How does Fedora differ from FreshRPMS or other repositories?
* Fedora apt/yum enforces GPG signature checking for your protection.
* All other repositories are made by a single person. Fedora can
have a lot more packages, and of higher quality, because we have have
many package developers working together on a common goal.
[/Quote]
What I understand is that QA has to be approved by two developers and
one of a trusted fedora.us developer which check the spec files and stuff.
If there aren't too many developers this can take quite a while I guess.
It's also an indication that there's no interest in some of the packages
in the queue.
I for one (as a non packager) wouldn't mind testing binary
packages
which are in the testing or unstable queues and I'm interested in.
If you're also interested in helping with package requests but are not
familiar with rebuilding src.rpms, simply add yourself to the "Cc" field
of such a bugzilla entry and ask whether the packager could provide a
prebuilt binary for testing. That however bears a security risk for you.
My proposal would be, to have packagers post a message that a RPM is
in
the testing or unstable queue and needs testing. Normal users can then
just test if they work well and send a message back on the fedora-test
list if it works or doesn't. I saw that in Bugzilla that QA/packager
people are doing all this.
Approved packages are pre-published in the "pending" repository tree
(which is similar to Fedora Core's "Test Updates") where interested people
can check out the prebuilt binary rpms and report success/failure in the
corresponding package request bug ticket.
--
4:46 p.m.
Michael,
Don't you think that a "bit of noise" on for instance the fedora-test
mailing list (if that's ok with RedHat) would help.
Many people read that list and the probability of somebody interested in
helping out therefore will increase.
Jaap
On Mon, 08 Dec 2003 21:52:35 +0100, Jaap A. Haitsma wrote:
>First of all I want to mention that I'm very grateful for what the
>people in Fedora Extras are doing.
>
>I noticed that the number of packages in Fedora Extras (I'll use this
>name to refer to the repository at fedora.us for the rest of this mail)
>is growing rather slowly on average 2 package announcements a day for
>november (which are both updates and new packages).
>
>Also I noticed that the QA queue is really full. 295 packages are
>waiting for QA.
As mentioned earlier, a lot of those packages have a very special target
group and are in need of people who are familiar with the packaged
software. E.g. lots of programming languages.
>And Warren Togami seems to be the owner of about 80
>percent of these. This guy must be making 40 hour days.
He's just the default person who's assigned to new package requests. The
actual packager is listed in the "reporter" field. Package updates are
assigned to the actual package maintainer instead.
But otherwise it's correct that some of the packagers maintain many a high
number packages.
>So I think he needs some help if we want to make fedora extras live up
>to what's in the FAQ (Second bullet)
>
>[Quote]
>How does Fedora differ from FreshRPMS or other repositories?
>
> * Fedora apt/yum enforces GPG signature checking for your protection.
> * All other repositories are made by a single person. Fedora can
>have a lot more packages, and of higher quality, because we have have
>many package developers working together on a common goal.
>[/Quote]
>
>What I understand is that QA has to be approved by two developers and
>one of a trusted fedora.us developer which check the spec files and stuff.
>
>If there aren't too many developers this can take quite a while I guess.
It's also an indication that there's no interest in some of the packages
in the queue.
>I for one (as a non packager) wouldn't mind testing binary packages
>which are in the testing or unstable queues and I'm interested in.
If you're also interested in helping with package requests but are not
familiar with rebuilding src.rpms, simply add yourself to the "Cc" field
of such a bugzilla entry and ask whether the packager could provide a
prebuilt binary for testing. That however bears a security risk for you.
>My proposal would be, to have packagers post a message that a RPM is in
>the testing or unstable queue and needs testing. Normal users can then
>just test if they work well and send a message back on the fedora-test
>list if it works or doesn't. I saw that in Bugzilla that QA/packager
>people are doing all this.
Approved packages are pre-published in the "pending" repository tree
(which is similar to Fedora Core's "Test Updates") where interested people
can check out the prebuilt binary rpms and report success/failure in the
corresponding package request bug ticket.
5:48 p.m.
Jaap A. Haitsma wrote:
Michael,
Don't you think that a "bit of noise" on for instance the fedora-test
mailing list (if that's ok with RedHat) would help.
Many people read that list and the probability of somebody interested in
helping out therefore will increase.
Jaap
Every once in a while I have been doing exactly as you suggest with
certain packages that I thought several people would be interested in,
but in most cases I get almost ZERO responses.
https://bugzilla.fedora.us/show_bug.cgi?id=520
For example on more than two occasions I have mentioned powernowd, which
I believe would be extremely beneficial to any laptop owner. When used
with the 2.6 kernel cpufreq_userspace interface, it allows dynamic CPU
speed adjustment based upon current load. It has been tested to work
well with Athlon and VIA processors, and should theoretically work fine
with Intel SpeedStep too if cpufreq works with your laptop.
Packages will sit forever in fedora.us QA if nobody bothers to even
comment on them. And it is not useful to only say "It builds and runs
fine for me." as this says nothing about spec file correctness and the
security of the included sources. People that want to seriously
contribute to package development and QA must show that they actively
follow each point of the http://www.fedora.us/wiki/QAChecklist and
consistently give good advice more than several times in order to build
trust.
I am working on some ideas for fedora.us QA policy changes that should
speed the publication of certain packages without lowering the bar of
security requirements.
One example of a loosening of requirements might be:
http://www.fedora.us/pipermail/fedora-devel/2003-December/002370.html
Warren
12:54 a.m.
On Mon, 08 Dec 2003 13:48:17 -1000, Warren Togami wrote:
Jaap A. Haitsma wrote:
> Michael,
>
> Don't you think that a "bit of noise" on for instance the fedora-test
> mailing list (if that's ok with RedHat) would help.
Well, fedora.redhat.com advertizes fedora-devel-list as one of the
places where to "participate". fedora.us is not official "Fedora
Extras",
but at least mentioned at http://fedora.redhat.com/participate/ and
should be considered as sort of a testbed for Fedora Extras.
> Many people read that list and the probability of somebody
interested in
> helping out therefore will increase.
"Somebody interested in helping out" would be helping out for some time
already. All the package requests which have the UPDATE keyword set,
should be significantly easier to review.
Package reviews can be turned into team work just fine, provided that
interested people add themselves to a package request bug ticket.
> Jaap
Every once in a while I have been doing exactly as you suggest with
certain packages that I thought several people would be interested in,
but in most cases I get almost ZERO responses.
There also don't seem to be any questions on how the QA process works or
how it could be modified. So either the process is clear or it is
ignored. ;)
https://bugzilla.fedora.us/show_bug.cgi?id=520
For example on more than two occasions I have mentioned powernowd,
It's such a small package, it's an ideal candidate for someone's
first package review and approval.
Packages will sit forever in fedora.us QA if nobody bothers to even
comment on them. And it is not useful to only say "It builds and runs
fine for me."
No? ... Highly useful IMO, since it means the packaged software works
for somebody.
Bug reports are equally useful. ;)
as this says nothing about spec file correctness and the
"spec file correctness" should be defined more closely. "spec file
correctness" means nothing, if a piece of software doesn't work. With
some software packages, it's quite easily possible to make the spec file
look correct, but cause the source tarball to install files into wrong
directories. Boom!
security of the included sources.
This last item raises the bar for many people, I think, because it is
quite vague about what kind of review you expect. If you see security
issues because powernowd is a daemon running as root, the software should
not have been packaged. If you expect someone to read the single 16 KiB C
source file line by line and verify whether it doesn't contain any
malicious code or whether it doesn't do anything bad in general, well,
that could be reason enough to scare off some people who fear they could
make a mistake with such a small package. If, however, you'd be happy when
somone compared the source tarball MD5 with the upstream release, that
might help. Afterall, in the source you're listed as contributor.
--
1:14 a.m.
Michael Schwendt wrote about powernowd:
make a mistake with such a small package. If, however, you'd be
happy when
somone compared the source tarball MD5 with the upstream release, that
might help. Afterall, in the source you're listed as contributor.
Yes, and that is why I suggested the "Source Audit Clause" which would
make it possible to publish this and other cases where nobody else cares
enough to look at it.
Warren
4:21 p.m.
Warren Togami wrote:
Michael Schwendt wrote about powernowd:
> make a mistake with such a small package. If, however, you'd be happy
> when
> somone compared the source tarball MD5 with the upstream release, that
> might help. Afterall, in the source you're listed as contributor.
>
Yes, and that is why I suggested the "Source Audit Clause" which would
make it possible to publish this and other cases where nobody else cares
enough to look at it.
This seems like a good proposal to me.
Just a remark from previous discussions.
I think if there aren't many people interested to do QA on a package it
isn't because there isn't any need or interest for the package in
general. Quite often I read something on the web about a program and
then try to find an rpm for it. Or I need some rpm to get something else
compiled. And by definition there are less packagers then users out there.
So to conclude I think that if there is no interest in doing QA does not
really mean that there is no interest in the package.
Jaap
7:58 a.m.
On Mon, 8 Dec 2003, Warren Togami wrote:
https://bugzilla.fedora.us/show_bug.cgi?id=520
For example on more than two occasions I have mentioned powernowd, which
I believe would be extremely beneficial to any laptop owner. When used
with the 2.6 kernel cpufreq_userspace interface, it allows dynamic CPU
speed adjustment based upon current load. It has been tested to work
well with Athlon and VIA processors, and should theoretically work fine
with Intel SpeedStep too if cpufreq works with your laptop.
Packages will sit forever in fedora.us QA if nobody bothers to even
comment on them. And it is not useful to only say "It builds and runs
fine for me." as this says nothing about spec file correctness and the
security of the included sources. People that want to seriously
contribute to package development and QA must show that they actively
follow each point of the http://www.fedora.us/wiki/QAChecklist and
consistently give good advice more than several times in order to build
trust.
*shrug* If no one comments, no one cares, and then presumably there's not
that much demand for that package.
I think it'd be better to put efforts towards making it easier to do QA (ie,
things like a CVS tree of specs and patches), rather than removing steps
from QA.
later,
chris
1:42 a.m.
New subject: powernowd and friends
Hi all,
Perhaps this is not the best place, but since Warren mentioned
powernowd, I'm finally writing it down. Better let people know.
Any one with a laptop perhaps has tried things to modulate CPU
speed, they are mostly based on SpeedStep technology from intel,
or PowerNow from AMD. Well, there's a P4-clockmod from intel
too.
The functionality is exported to user space through cpu-freq
interface. The old interface is around /proc/cpufreq, while the
new one is in /sys/devices/system/cpu/*/cpufreq...
In 2.6 kernel configuration, it is mentioned that:
Enable this cpufreq governor when you either want to set the
CPU frequency manually or when an userspace programm shall
be able to set the CPU dynamically, like on LART
<http://www.lart.tudelft.nl/>
And people have developed a handfull of packages to *do the right
thing*. To name a few, autospeedstep, cpudynd, cpufreqd, and
powernowd. What all of them do is to set the CPU frequency on
demand.
Now comes my confusion. All my experiments have been done on my
Sony Vaio laptop with a Pentium 4 Mobile 2.4GHz CPU.
The ACPI spec is at http://www.acpi.info/DOWNLOADS/ACPIspec-2-0c.pdf
My processor has two P states, P0 and P1. (page 23 of ACPI spec)
And it has eigth T state.
To describe them briefly, P states are power states. When in P0,
it's working full power, when in P1, it works at half speed
1.2GHz, and consumes more power, because of lower voltage. If I
boot on battery power, it goes in P1. I can put it in P1
through ACPU CPU performance interface. But when in P1, I cannot
go back in P0.
[behdad@mces behdad]$ cd /proc/acpi/processor/CPU0/
[behdad@mces CPU0]$ ls
info limit performance power throttling
[behdad@mces CPU0]$ cat performance
state count: 2
active state: P0
states:
*P0: 2400 MHz, 35000 mW, 250 uS
P1: 1200 MHz, 20200 mW, 250 uS
[behdad@mces CPU0]$
Now comes the T states. For those who don't know, they are
called throttling states, and their main usage is to prevent
overheating and burning CPU. As the name suggests, it's
throttling, means that, it does not reduce CPU frequency, just
asks processor to spend a percentage of it's time in idle.
[behdad@mces CPU0]$ cat throttling
state count: 8
active state: T0
states:
*T0: 00%
T1: 12%
T2: 25%
T3: 37%
T4: 50%
T5: 62%
T6: 75%
T7: 87%
[behdad@mces CPU0]$
Then, if I'm in P0, throttling gives me 8 different speeds,
ranging from 298MHz/sec to 2.4GHz/sec, and if I'm in P1, it gives
from 149MHz/sec to 1.2MHz/sec. Please not that when you are on
298MHz, it's true that you only get 298M cycles per second, but
your CPU is still beating on 2.4GHz/sec.
Now comes cpufreq. There are enough evidence for me that cpufreq
is nothing more than a wrapper around throttling states, at least
for my processor.
On my system, if I load speedstep-ich driver, it loads and shows
me through cpufreq interface a min of 1200000 and max of 2400000.
It suggests to be P states, but I cannot change the speed what
ever I do. That's because it's the wrong driver. Unload that
and load p4-clockmod and I see 8 different steps in cpu freq
interface (2.6 kernel prefered). These are exactly the same as
my ACPI T states.
Maybe some numbers help:
My laptop compiling a kernel with make -j4, on full CPU power,
consumes 40W, when idle consumes 30W. Turn it down to 1.2GHz
(50%), in the same load consumes 35W, again in idle consumes 30W.
Turn it down to 298MHz(12%), I can't put the load on, but in
idle, it again consumes 30W.
So here are two facts:
1. You CPU does it's best to consume less power when idle, that's
because of those acpi_idle or apm_idle routines in kernel.
2. Throttling states and then cpufreq speeds, do not touch CPU
frequency and so voltage, but add CPU idle time.
The logical conclusion is that, modulating CPU speed *on demand*
means nothing. No matter what speed you *think* your CPU is
working on, your CPU is smart enough to consume enough power to
complete the job.
My conclusion is that, CPU speed modulation on demand is as wrong
as turning lights off when in blackout, and turn on again when
you are back.
The only reason I can see people want to set CPU freq manually,
is to put a limit on their power consumption. For example, you
have a long going Mozilla compilation session, and you want to go
home. You put a limit on cpu freq, so that you don't need to
stop the compilation job, and you do not go out of battery before
you reach home.
Done.
Please lemme know if I'm wrong. Experimentation on speedstep and
powernow technologies would be appreciated. Dave Jones should
have an idea. And don't shoot me out. I'm going to raise it in
the right place myself.
behdad
3:05 a.m.
New subject: powernowd and friends
Behdad Esfahbod wrote:
The logical conclusion is that, modulating CPU speed *on demand*
means nothing. No matter what speed you *think* your CPU is
working on, your CPU is smart enough to consume enough power to
complete the job.
My conclusion is that, CPU speed modulation on demand is as wrong
as turning lights off when in blackout, and turn on again when
you are back.
I know absolutely nothing about Intel processors, but here are my
observations of my 1GHz Athlon4 processor in my Sony Vaio FXA-36.
Running older kernels without ACPI, temperatures are always extremely
hot, sometimes reaching 70C. Back in those days with APM kernels, I
used the crude but effective lvcool program which runs HLT in otherwise
idle cycles. It is a userspace process that is niced to be very low
priority. ACPI kernels seem to have this effect by default, with
seemingly less overhead and no longer appearing as using 100% CPU all
the time like the old lvcool method. Using either lvcool or ACPI would
bring temperatures within the 58-64C range.
The 10 ACPI throttle states seem to be effective in slowing down the
system, but some crude measurements have showed seemingly ZERO
DIFFERENCE in temperature or power usage. Thus I have ignored tweaking
that interface.
Only recently did cpufreq begin working with K7 processors. Running at
500MHz I have regular operating temperatures in the 46-52C range and
extended battery life. After playing with cpufreq for a day, it was too
much of a hassle for me to tweak manually so I pretty much ignored it
until I discovered powernowd. I like powernowd because I get the
benefits of low temperatures and extended battery life, but it
automatically jumps to full speed if I do processor intensive things
like compiling.
The vast majority of the time however I am only using my laptop to ssh
into other boxes, so I like that it automatically drops to minimum speed
where my regular desktop apps are mostly idle cycles, with the exception
of brief jumps when large applications are loading.
Anecdotally I do not "feel" the effects of the slower speed, probably
because with powernowd default settings it has a hair-trigger to jump to
maximum speed when the CPU when it is needed.
https://bugzilla.fedora.us/show_bug.cgi?id=520
fedora.us powernowd package
Warren
7:35 a.m.
New subject: powernowd and friends
On Wed, 2003-12-10 at 07:42, Behdad Esfahbod wrote:
The logical conclusion is that, modulating CPU speed *on demand*
means nothing. No matter what speed you *think* your CPU is
working on, your CPU is smart enough to consume enough power to
complete the job.
Because you're running the ACPI code, *and* the cpufreq code.
ACPI will do load based adjustments itself on most laptops.
cpufreq should be looked on as an alternative if ACPI doesn't work
on a particular system due to broken AML tables.
Dave
7463
days inactive
7465
days old
10 comments
6 participants
participants (6)
-
Behdad Esfahbod -
Chris Ricker -
Dave Jones -
Jaap A. Haitsma -
Michael Schwendt -
Warren Togami