Hello Wouter, the build of icedove 31.4.0-2 is broken again on powerpc-unicamp-01 (as expected). Could you please reschedule the build on another powerpc buildd again? Christoph has fixed a RC bug [6] with this version of icedove and by this it is important for us to get this version of icedove into testing.
Thanks! (I don't have cut up the old mail because I added the RC bug about FTBFS on powerpc [7] to the CC list of this mail.) Am 22.01.2015 um 21:20 schrieb Carsten Schoenert: > Hello Wouter, > > Am 20.01.2015 um 00:58 schrieb Wouter Verhelst: >>> Could this problem depends on the autobuilder powerpc-unicamp-01? >> >> Possibly, but I don't think it's a configuration issue on the buildd or >> some such. All buildd hosts these days use throwaway chroots; that means >> that if the issue occurs, it *should* also occur in a clean chroot. >> >> Looking at the buildd log, we see: >> >> <jemalloc>Compile-time page size does not divide the runtime one. >> >> which to me smells like an incorrect assumption either in jemalloc or in >> the code that uses jemalloc. But I'm not sure; I don't know what the >> message means. > > In the past from time to time we had build issues related to jemalloc > [1], but Mozilla has worked on the code, probably initiated by Mike > Hommey [3-5]. > This message is produced by a simple check if the pagesize is different > to internal result check. On powerpc (and other platforms as well) the > source is setting a definition of MALLOC_STATIC_SIZES to 1 because the > code should be compiled as compile-time constants for performance > reasons. This means later that some things are hardcoded and hasn't to > detect by the CPU and the system, but the jemalloc compiler is proofing > later the environment [2] before it will translate the code. But exactly > here on this on the buildd this check was failing. > > But how the jemalloc thing is exactly working ... I also don't know. :) > >>> And finally could you schedule a rebuild of icedove on another >>> autobuilder? >> >> We could randomly disable icedove on some buildd hosts and not on others >> if it really FTBFS due to hardware, but I'd prefer to see the root cause >> found and (hopefully) fixed. >> >> We don't currently know what the problem is, though. > > I don't know if you have done some buildd's disabled for the icedove > packages, but last night a build on host 'parry' was successful! > That's because Christoph was meaning that there could be something > different to the porter box. It would be interesting to found out what > the differences are to the other buildd. > > [1] > https://sources.debian.net/src/icedove/31.4.0-1/mozilla/memory/mozjemalloc/jemalloc.c/ > [2] > https://sources.debian.net/src/icedove/31.4.0-1/mozilla/memory/mozjemalloc/jemalloc.c/#L1085 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708331 > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=825165 > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=840242 [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770008 [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775788 -- Regards Carsten Schoenert
signature.asc
Description: OpenPGP digital signature
