On Mon, Jun 18, 2007 at 11:35:39PM +0200, Bill Allombert wrote: > On Mon, Jun 18, 2007 at 03:26:41PM -0500, Stephen R Marenka wrote: > > On Mon, Jun 18, 2007 at 06:53:46PM +0000, Bill Allombert wrote: > > > > > I strongly suggest that the box buildding security update use > > > distcc+crosscc. This will speed things quite a bit with no > > > risk of breakage since we are using a stable cross-compiler > > > that is well tested. > > > > > > In my opinion, distcc+crosscc have more potential that aranym, > > > especially for security in term of speed gain and reliability. > > > > It seems to break on objective-c code. Does it work for fortran or any > > other languages? > > It does not work for fortran (unless you use f2c) but fortran is an > order of magnitude faster to compile than C++. > > > > I believe that if there had been a concerted attempt to use > > > distcc+crosscc on some buildd, we would have been able to get > > > released with Etch. Actually I still believe we can relase m68k > > > as part of etch 4.0r2 or 4.0r3 if we show a real involvement > > > even if merely symbolical. > > > > The toolchain was the root cause for our etch problems, not our buildd > > speed. Buildd speed was contributory in that it was easy to point to. > > Exactly: we were able to build every packages anyway. But we needed to > do more: showing we have potential for being faster, even if it did not > make a real difference at this point. That is why I said 'merely > symbolical'. > > > At the time we were punted from etch, we had not yet worked out our > > toolchain problems. > > > > Until we resolve our current toolchain problems and get TLS working, > > we won't be added to lenny. I don't believe we have any chance to be > > added to etch. > > In my opinion, we have even less change to be released with Lenny than > with Etch. Releasing Etch will certainly get us point toward releasing > Lenny, especially if we show we are able to build security.d.o without > slowing down the advisories. > > > At the moment we don't even have a list of how etch-m68k > > differs from etch and etch-security. > > This is my attempt with quinn-diff: > Between etch and etch-m68k: > <http://people.debian.org/~ballombe/m68k/diff-etch-m68k> > Between etch and security.d.o: 40 source packages. > > The list of package marked out-of-date: > > x11/libx11_2:1.0.3-7.dsc > devel/mozart_1.3.2.20060615+dfsg-2.dsc > devel/klic_3.003-gm1-2.1.dsc > devel/haskelldb_0.9.cvs.601-13.dsc > python/python2.4_2.4.4-3.dsc > utils/fcitx_1:3.4.3-1.dsc > graphics/blender_2.42a-7.dsc > libs/kdelibs_4:3.5.5a.dfsg.1-8.dsc > libs/db4.2_4.2.52+dfsg-2.dsc > devel/mozart-gtk_20060615-2.dsc > graphics/ctn_3.0.6-10.dsc > admin/brltty_3.7.2-7.1.dsc > devel/libsigsegv_2.4-1.dsc > net/ejabberd_1.1.2-6.dsc > interpreters/sigscheme_0.6.1-1.dsc > devel/systemtap_0.0.20061028-2.dsc > math/octave2.9-forge_2006.07.09+dfsg1-8.dsc > interpreters/erlang_1:11.b.2-4.dsc > interpreters/gnu-smalltalk_2.1.8-2.1.dsc > web/yaws_1.65-4.dsc > > By the way, if I build them, can I upload them ? How ?
regular dupload? You may need to target etch-m68k instead of etch, I guess. ISTR sbuild having an option for that (specifying the release to generate .changes files for). > Can we remove packages that should be 'not for us' ? If they're already uploaded, asking an FTP master should be doable, I guess. If they're not uploaded yet, that's what wanna-build is for :) -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
