Re: Front-end preview

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Feb 11, 2006 at 10:20:37PM +0100, Tobias Gruetzmacher wrote:
> Hi,
> 
> On Sat, Feb 11, 2006 at 02:11:44PM -0600, Paul Gray wrote:
> > Just in case anyone's curious about the front-end build customization that I
> > mentioned:
> > 
> >   http://fireant.cs-ceee.uni.edu/selectModules.php
> 
> This looks pretty cool. When you are doing this you probably should try
> to speed up the build process with ccache and a huge cache setting :)
> 

Thanks for taking a look.

ccache is good, distcc hasn't been as beneficial as it has been a PITA (also a
huge security risk).  There are a few other ways to speed up simple builds that
just integrate new packages too.  Namely, doing a full build, then 
    make -C lnx-bbc/meta/lnx-bbc clean && \
    make -C lnx-bbc/meta/bbc-contents clean && \
    make -C lnx-bbc/meta/i386-livecd clean && \ 
    make -C lnx-bbc/meta/singularity clean 

...Then a simple augmentation to bbc-contents can be built very quick (within
45 minutes).

I should also mention that there's been considerable help from the PPC kernel
maintainer (Tobias McNulty) and the team at Earlham college to get the PPC
kernel in a more viable and supported LNX-BBC option.

Working on USB-booting and more robust PXE booting, too  :)

> > Clicking on the package will (eventually) show the package blurb and list 
> > the package's full dependencies (so that you can see how it bloats the final 
> > image).
> 
> Would a simple life calculation of the estimated target size with some
> client-side JavaScript be possible? That would make the web form even
> more awesome :)

That's part of the plan.  Right now, the approach is to do a pre-calculation of
a 'make showdeps' and try to parcel out the incremental build sizes.  It's not
that straight forward though, as I've seen situations where adding packages 
DECREASE the ISO size due to more efficient cloop compression of blocks!

> 
> > I'd also like it to have the capability to upload/replace files in the package
> > with the user's own customized versions (like customized init levels that pull
> > down Condor using list-packages and build their own distributed 
> > computing flock...just one example).
> 
> How are you dealing with security issues in this? You would have to
> lock down a build with customized files pretty tight...

Only select things would be "open" to customizing -- nothing that make would
ever source, we'd start with kernel configs (such as adding SMP support), but
probably not additions to kernel drivers.  Builds will all be taking place
under chroots, too.  That's one great thing about GAR -- it can go from start
to finish at the user level.  In addition, the front end *will* "Sanitize 
all input."

> Apart from this: Great to see some life back in this project. Is there
> a plan to use Arch or are we stuck with CVS again? I really would like
> to see a version control system where it is easy to track the official
> sources while maintaining some personal patches. The most promising in
> this area are probably darcs, git, Mercurial and bzr (aka. bazaar-ng).
>

I'm open to moving to other paradigms.  The current CVS tree will be migrating
around Spring break anyway, due to moves of the server within our DNS naming
(i.e., the server WAS in our CEEE building, but now it's in our Physics
building, and will be moving to the ITTC building in a couple of months -- no
money here for faculty salaries, but ample for remodeling.).  The server now has
a cs-ceee.uni.edu suffix.  I put the tree in cvs to just get the tree
back "out there."

It'd be nice to make it available on lnx-bbc.org, but I don't control that
host/domain.  I sent out an e-mail to Duncan earlier today to ask about that.

> 
> I still have some patches for some multimedia-related software here, but
> I think I have to review them before submitting them, because the
> suffer from serious bitrot ;)

Keep us posted.  I have some students that are looking for something to do :)

(Sokar -- you didn't read that.)

- -- 
Paul Gray                                         -o)
323 Wright Hall                                   /\\
University of Northern Iowa                      _\_V
Message void if penguin violated ...  Don't mess with the penguin
No one says, "Hey, I can't read that ASCII attachment ya sent me."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD7m4OOH45TZW7mh4RAvcMAKCY1+WIIv7uVg5Oy8gNwjw+Ww//PACfVHIe
YE41Vp9jIdDgtgn14dnqArY=
=C0bj
-----END PGP SIGNATURE-----