Re: m68k: being ignored for testing propagation
On Sun, Oct 09, 2005 at 11:37:05AM -0400, Jay Berkenbilt wrote:
> Steve Langasek <vorlon@debian.org> wrote:
>
> > . . .
> > From
> > <http://buildd.debian.org/~jeroen/status/architecture.php?a=m68k>, there are
> > 125 packages in state Failed, 138 in state Dep-Wait, and 45 that are
> > Maybe-Failed; as well as 27 packages in state Not-For-Us.
> > . . .
> >
> > The release team will continue to monitor the progress of the m68k
> > port. If you have any questions about where to go from here, please
> > ask us.
>
> (cc-ing debian-release so that others can assume that the answer I get
> here may apply to their packages as well...)
>
> ICU failed to build on m68k because of an internal compiler error.
> Last I heard, people were aware of several internal compiler errors
> and were working on the problem.
Correct. It has been fixed, in the mean time.
> I'm not in a position to help hunt for internal compiler errors on
> m68k, so I've just left icu alone in hopes that it will be requeued at
> some point once some of the compiler issues get resolved.
>
> I had attempted a manual build of icu on crest at one point a couple
> of months ago (when icu was behind packages that depend upon it in the
> buildd queue), but I got the same problem. I just now logged into
> crest and tried compiling the stand-alone source file that used to
> create the internal error, and it no longer does. Would I be helping
> or hurting things to do a manual build on crest?
There's no easy answer to that one.
In general, it's not a good idea to just go ahead and start building
packages on crest, because eventually crest would then no longer be able
to keep up anymore. Note that crest does run a buildd itself as well, so
every additional build that runs on crest will slow down the buildd
build that's already running.
In the case of the recent ICE problems, I recently went through the list
of packages that failed to build by producing an ICE and requeued those
that would most likely succeed now; so if a package is not built yet,
you may want to check what the wanna-build state is.
In this particular case, I did not requeue the package because I didn't
think it would've been fixed; however, if you can confirm it has, then
that's great and it should be built.
As to the question of whether you should interrupt the build, I think
it's most important to see how much CPU time you'd be throwing away. If
crest is heavily loaded, and you're not far into the build yet, it's
probably a good idea to stop it. If, however, the build is more than
(say) two-thirds into completion, I'd rather you just let it continue;
it'd be a waste to throw them away, then.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
Reply to: