Re: Front-end preview

*sinister laughter*

I got a list of about 20 updates that i'm gonna go and try all at once
this week... should be interesting.

also found an update for the ppc related boot loader (i think), i can
fire that off to the list if anyone needs it.

And also a question:  Is there an 'easier way' to monitor when an
update to a package that we use comes out?  (other than the down list
alphabetical thing i am doing now)  Cause its definitely not a small #
of packages, and subscribing to all those devel lists (some of which
don't have an 'announce' list, or a 'list' at all) would just be a
damn nightmare.  And how do we determine when a project is 'dead' or
'finished' and to not monitor it for updates any more. (like zip or
tar or something that can be 'completed')

yea, the question got long and complicated... but I felt it needed to be as=
ked.

--ME


On 2/11/06, Paul Gray <[email protected]> wrote:
> -----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 (a=
lso a
> huge security risk).  There are a few other ways to speed up simple build=
s 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 (wi=
thin
> 45 minutes).
>
> I should also mention that there's been considerable help from the PPC ke=
rnel
> maintainer (Tobias McNulty) and the team at Earlham college to get the PP=
C
> 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 th=
e 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-calculat=
ion 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 packag=
es
> 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 th=
e 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 wo=
uld
> 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 plac=
e
> under chroots, too.  That's one great thing about GAR -- it can go from s=
tart
> 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 migr=
ating
> around Spring break anyway, due to moves of the server within our DNS nam=
ing
> (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 tha=
t
> host/domain.  I sent out an e-mail to Duncan earlier today to ask about t=
hat.
>
> >
> > I still have some patches for some multimedia-related software here, bu=
t
> > 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 d=
o :)
>
> (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=3D
> =3DC0bj
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Lnx-bbc-devel mailing list
> [email protected]
> http://zork.net/mailman/listinfo/lnx-bbc-devel
>
>


--
irc.virrox.com  #cedarlug

http://www.urbandictionary.com/define.php?term=3Dirc

random quote(s) for the week
http://bash.org/?75154

truth is rarely appreciated:
http://www.laddertheory.com/