Re: [buildd] Stuff
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
Reply to: