6:57 a.m.
As I've said here before, this is my first RPM Fusion package, so I
could be doing something wrong. But I don't know what.
My package ProjectX was recently approved and created in CVS. Now I'm
trying to build. I started builds last Tuesday. When I checked them
yesterday evening, they were still marked as building, but when I
checked the builder status only the ppc builder was available. So I
assumed something went wrong on the builder side. But I didn't have
time to look more at it then.
This morning I had got mails that the builds had failed. Not strange
if the build host went down or something. So I tried another build.
This one finished in four minutes. But it also failed. And when I
try to look at the logs to see what went wrong
(http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/8016...)
I don't see any logs at all. There is a SRPM package there, but no
logs in neither the i686 nor the x86_64 subdirectories.
Shouldn't it be? Am I doing something wrong? If so what could that
be?
Or is this another error on the build host side? Something I should
file a bugzilla about?
My build command was simply "make build" in the devel branch of my
package.
8:29 a.m.
There's another oddity:
* several build jobs are hung up in the "add_to_repo" state:
http://buildsys.rpmfusion.org/build-status/success.psp
* at least one of them is marked as "successful" despite a build error
for both i686 and x86_64 (also notice the German in the setup):
http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_nonfree/7...
+ rm -rf /builddir/build/BUILDROOT/unrar-3.9.10-1.fc14.i386
+ install -Dpm 755 unrar
/builddir/build/BUILDROOT/unrar-3.9.10-1.fc14.i386/usr/bin/unrar-nonfree
+ install -Dpm 644 debian/unrar-nonfree.1
/builddir/build/BUILDROOT/unrar-3.9.10-1.fc14.i386/usr/share/man/man1/unrar-nonfree.1
install: cannot stat `debian/unrar-nonfree.1': No such file or directory
Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.2cWhcZ (%install)
Fehler beim Bauen des RPM:
Fehler-Status beim Beenden von /var/tmp/rpm-tmp.2cWhcZ (%install)
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
4:15 p.m.
2010/9/9 Göran Uddeborg <goeran(a)uddeborg.se>:
As I've said here before, this is my first RPM Fusion package, so
I
could be doing something wrong. But I don't know what.
My package ProjectX was recently approved and created in CVS. Now I'm
trying to build. I started builds last Tuesday. When I checked them
yesterday evening, they were still marked as building, but when I
checked the builder status only the ppc builder was available. So I
assumed something went wrong on the builder side. But I didn't have
time to look more at it then.
This morning I had got mails that the builds had failed. Not strange
if the build host went down or something. So I tried another build.
This one finished in four minutes. But it also failed. And when I
try to look at the logs to see what went wrong
(http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/8016...)
I don't see any logs at all. There is a SRPM package there, but no
logs in neither the i686 nor the x86_64 subdirectories.
Shouldn't it be? Am I doing something wrong? If so what could that
be?
Or is this another error on the build host side? Something I should
file a bugzilla about?
The ProjectX builds were kill build-host side, because they were
causing the build host to swap itself to death. There were four
simultaneous builds going, when there should have only been two, due
to a plague server issue, and it overwhelmed the builder. I've taken
brute force measures builder-side to make sure that doesn't happen
again, but because I lack admin powers in plague itself, I couldn't
cleanly cancel and requeue your jobs. So that definitely contributed
some to the confusing states your jobs went though. Please try
launching them anew and we'll see what happens...
--
Jarod Wilson
jarod(a)wilsonet.com
11:15 a.m.
Jarod Wilson:
The ProjectX builds were kill build-host side, because they were
causing the build host to swap itself to death.
I see. Thanks for the explanation. (I hope it wasn't my fault in any
way.)
Please try
launching them anew and we'll see what happens...
It worked, and the package is in updates-testing now. :-)
12:16 p.m.
2010/9/14 Göran Uddeborg <goeran(a)uddeborg.se>:
Jarod Wilson:
> The ProjectX builds were kill build-host side, because they were
> causing the build host to swap itself to death.
I see. Thanks for the explanation. (I hope it wasn't my fault in any
way.)
Nope, issue was the plague server overloading the host with more
simultaneous jobs than it should have.
> Please try
> launching them anew and we'll see what happens...
It worked, and the package is in updates-testing now. :-)
Excellent, sorry for the interim confusion.
--
Jarod Wilson
jarod(a)wilsonet.com
1:48 p.m.
On Tue, 14 Sep 2010 08:16:35 -0400, Jarod wrote:
2010/9/14 Göran Uddeborg:
> Jarod Wilson:
>> The ProjectX builds were kill build-host side, because they were
>> causing the build host to swap itself to death.
>
> I see. Thanks for the explanation. (I hope it wasn't my fault in any
> way.)
Nope, issue was the plague server overloading the host with more
simultaneous jobs than it should have.
Any idea how that has been possible? Plague Builders don't accept more
than the maximum number of build jobs they can handle. The server cannot
override that. Though, rpmfusion infrastructure probably still uses the
unofficial/forked Plague version which differs from Fedora Extras era and
beyond.
2:32 p.m.
On Tue, Sep 14, 2010 at 9:48 AM, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Tue, 14 Sep 2010 08:16:35 -0400, Jarod wrote:
> 2010/9/14 Göran Uddeborg:
> > Jarod Wilson:
> >> The ProjectX builds were kill build-host side, because they were
> >> causing the build host to swap itself to death.
> >
> > I see. Thanks for the explanation. (I hope it wasn't my fault in any
> > way.)
>
> Nope, issue was the plague server overloading the host with more
> simultaneous jobs than it should have.
Any idea how that has been possible?
Not exactly, no.
Plague Builders don't accept more
than the maximum number of build jobs they can handle.
How does the builder know what the maximum number of jobs it can handle is?
The server cannot override that.
Well, it is/was. I set max_jobs to either 1 or 2 to no effect, it was
always "number of cpus" that got set as the max jobs value. So a
dual-core box with hyperthreading was being set up for 4 jobs at a
time. And four -j4 builds at the same time, is, um, well, bad.
Especially when two of the four "cpus" aren't full cores. So I've shut
off hyperthreading and throttled builds to -j1, and everything seems
stable again, but this certainly doesn't feel like a solution, just a
hack-around.
Though, rpmfusion infrastructure probably still uses the
unofficial/forked Plague version which differs from Fedora Extras era and
beyond.
Dunno. The builder itself is now running plague 0.4.5.8-1 as found in
Fedora, rebuilt for el6.
--
Jarod Wilson
jarod(a)wilsonet.com
3:04 p.m.
On Tue, 14 Sep 2010 10:32:06 -0400, Jarod wrote:
> Plague Builders don't accept more
> than the maximum number of build jobs they can handle.
How does the builder know what the maximum number of jobs it can handle is?
See determine_max_jobs() in /usr/bin/plague-builder.
It runs '/usr/bin/getconf _NPROCESSORS_ONLN' and defaults to '1',
which explains your value of '4'.
> The server cannot override that.
Well, it is/was.
No, the builder maintains its own number of max. jobs and free slots.
It rejects further jobs if it's busy and if the server tries to start
more jobs anyway.
The server only keeps track of the current number of free slots of
the builders for scheduling.
I set max_jobs to either 1 or 2 to no effect, it was
always "number of cpus" that got set as the max jobs value.
Right. There is no configuration variable to change that. Seems
everything else is there already (the "cfg" parameter to implement
a configuration parameter to override the default max.jobs value).
So a
dual-core box with hyperthreading was being set up for 4 jobs at a
time. And four -j4 builds at the same time, is, um, well, bad.
Especially when two of the four "cpus" aren't full cores. So I've shut
off hyperthreading and throttled builds to -j1, and everything seems
stable again, but this certainly doesn't feel like a solution, just a
hack-around.
True.
5:01 p.m.
On Tue, Sep 14, 2010 at 11:04 AM, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Tue, 14 Sep 2010 10:32:06 -0400, Jarod wrote:
> > Plague Builders don't accept more
> > than the maximum number of build jobs they can handle.
>
> How does the builder know what the maximum number of jobs it can handle is?
See determine_max_jobs() in /usr/bin/plague-builder.
It runs '/usr/bin/getconf _NPROCESSORS_ONLN' and defaults to '1',
which explains your value of '4'.
Bleah. Not a default I like much. Gets worse and worse with more cpus
too. 4 cores plus hyperthreading -> 8 x -j8 jobs, so 64 threads on 4
cores. 16 on 2 is bad enough...
> > The server cannot override that.
>
> Well, it is/was.
No, the builder maintains its own number of max. jobs and free slots.
It rejects further jobs if it's busy and if the server tries to start
more jobs anyway.
The server only keeps track of the current number of free slots of
the builders for scheduling.
> I set max_jobs to either 1 or 2 to no effect, it was
> always "number of cpus" that got set as the max jobs value.
Right. There is no configuration variable to change that. Seems
everything else is there already (the "cfg" parameter to implement
a configuration parameter to override the default max.jobs value).
Okay, so the problem is that I was trying to use an invalid config
option. Was there when I started poking at the config when the box was
being brought to its knees by the defaults, so I'd assumed it was
valid.
--
Jarod Wilson
jarod(a)wilsonet.com
5209
days inactive
5214
days old
rpmfusion-developers@lists.rpmfusion.org
8 comments
3 participants
participants (3)
-
Göran Uddeborg -
Jarod Wilson -
Michael Schwendt