Bug#325292: Is this bug still alive?

[Michael Schmitz]

It very much is - removing qt3-dev-tools and qt3-qtconfig fixed it for me
while upgrading a testing installation.

Michael



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#270389: kdelibs: t-p-u upload FTBFS on m68k

[Michael Schmitz]

> > Beefier than which one?
>
> According to
> ,
> this was kullervo.

Build needed 18:22:55, 129668k disk space

tells me it wasn't the disk space.

Regarding VM: kullervo has 128 MB RAM (maxed out here) and 768 MB swap.
Are you suggesting this isn't sufficient*

Michael

Bug#270389: kdelibs: t-p-u upload FTBFS on m68k

[Michael Schmitz]

> > Usually meinproc errors we have seen so far have been building machine
> > running out of ram/disk space. Since all the other builds came out fine,
> > this seems probable this time too.
>
> Ok.  m68k porters, is it possible for this kdelibs t-p-u upload
> to be requeued on a beefier machine?

Beefier than which one?

Michael

Re: strange kdepim failure on m68k build

[Michael Schmitz]

> > /dev/sdc2  16G  3.9G   11G  26% /org
> >
> > which is what the buildd chroot lives on. I'm not sure what the problem
> > actually is, though.
>
> Maybe when kullervo rebooted it corrupted something, since the first
> time it tried to build it worked fine until it was shutdown in the
> middle of the build. As soon as it tried to build it the second time, on
> the same box, without rebuilding the chroot, it failed to build properly.
> According to the build log it looked like it just tried to resume the
> build more or less, so something must have gotten corrupted, at least
> afaict.

Not likely - the build isn't just resumed but restarted from the
beginning (without unpacking the source again, though). If the package
fails to build on the second try, something might be wrong with the clean
target.

Michael