Re: Your axiom uploads
Greetings, and thank you so much for your work with the Debian
buildds!
While I'm confident it is not apparent at your end, I can assure you
that I have spent hours on the axiom port, primarily on merulo, as the
failures stem from a linker issue which is common to the failing
platforms, one of which was ia64. Further evidence can be deduced
from the success of -5 on ia64 and hppa, unlike -4. I anticipate mips
will work too. Alpha and arm have exposed other issues.
While I appreciate your point, I think it might also be advisable to
keep in mind that the most precious commodity we have is human time,
all the more so when we reflect on the fact that we are powered by a
purely voluntary workforce. I think it unreasonable to request that
all 12 builds are done by hand before an upload. (In any case,
albeniz has a dysfunctional gdb, and agricola cannot reproduce the
buildd failure, and responses on the mailing lists are not
forthcoming.)
I'm hoping you are a sparc expert. There has been a longstanding, yet
stochastic memprotect failure that has arisen on sparc over the last
two years or so. GCL and its reverse dependencies make use of a
garbage collecting algorithm which marks pages read-only, traps
segfaults on attempted writes, remarks the pages as writable, and uses
the division of pages into read-only and writable sets to speed the
algorithm. This periodically fails on sparc only. I have a maxima
setup on smetana now where failure occurs randomly from run to run.
Turning off the algorithm eliminates all issues, but takes more time.
If you could help solve this, or point me to someone who can, that
would lighten the load on sparc buildd for gcl gclcvs maxima, hol88,
acl2, and axiom. More than two years ago, this worked on sparc
without issue.
Take care,
Philipp Kern <pkern@debian.org> writes:
> Camm,
>
> it seems to us that you upload with minimal testing and the buildds are
> busy for yonks just to wait for you putting another build into the
> pipeline, so they were effectively blocked for nothing as the archive
> won't accept the upload anyway. This is an abuse of the buildd network,
> as it impacts other packages' buildability.[1]
>
> Please properly test your builds (e.g. on porterboxes) first. Otherwise
> we need to permanently decrease the build priority for that package to
> ensure that our slower architectures have a fair chance of decreasing
> their backlog instead.
>
> Regards,
> Philipp Kern
>
> [1] The last build on sparc took 25h.
> --
> .''`. Philipp Kern Debian Developer
> : :' : http://philkern.de Stable Release Manager
> `. `' xmpp:phil@0x539.de Wanna-Build Admin
> `- finger pkern/key@db.debian.org
--
Camm Maguire camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: