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 <[email protected]> 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:[email protected] Wanna-Build Admin > `- finger pkern/[email protected] -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
