Update

[Paul Gray]

Just a quick update for those still interested:

The latest CVS tree builds from start to finish with a stock Debian stable
build host.

A web front end is being developed that will provide a click-and-configure
customization of the images (upload your own stuff, add/remove package of your
choosing, etc.) that will be built here at UNI on our systems (where they are
known to build completely) and posted online for download.

Most all of the "blurbs" have been updated/added for the packages.

A slew of new utilities (mainly wireless and security related) have been added
to the tree; many packages have been NUV'd and MASTER_SITES updated.

The development branch is pushing toward support of gtk+2, 2.6.x kernels, and
my ultimate personal goal would be to support firefox/minimo.

Many new packages for the booted images will be available via the
"list-packages" paradigm.

The CVS tree can (temporarilly) be fetched via:
touch ~/.cvspass
cvs -d:pserver:***@fireant.cs-ceee.uni.edu:/ login
# hit return for the password
cvs -d:pserver:***@fireant.cs-ceee.uni.edu:/ co lnx-bbc

Feel free to play along at home. While progress is going forward, there are a
lot of things that still require some attention. My attention has been mainly
devoted to resurrection of the build process instead of functionality and
improvements, so patience and feedback is appreciated.

GAR rules.

- --
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."

[Paul Gray]

Just in case anyone's curious about the front-end build customization that I
mentioned:

http://fireant.cs-ceee.uni.edu/selectModules.php

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).

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).

Clicking on "confirm" will (eventually) result in an e-mail sent to you to
verify that the build should procede, and to validate that when my systems
churn about 8 hours of CPU cycles, there's someone on the other end of the
Internet that can be contacted to fetch the results. When the user responds to
the e-mail, procmail comes into play and parses the request, does a cvs
checkout, and pushes the build off on an idle host. When finished, the iso
will be posted to a web site and an e-mail generated that tells the end user
that their build is complete.

... that is all

- --
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."

[Tobias Gruetzmacher]

Hi,

Post by Paul Gray
Just in case anyone's curious about the front-end build customization that I
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 :)

Post by Paul Gray
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 :)

Post by Paul Gray
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...

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 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 ;)

Greetings Tobi

[Paul Gray]

Post by Tobias Gruetzmacher
Hi,

Post by Paul Gray
Just in case anyone's curious about the front-end build customization that I
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 :)

Post by Tobias Gruetzmacher

Post by Paul Gray
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!

Post by Tobias Gruetzmacher

Post by Paul Gray
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."

Post by Tobias Gruetzmacher
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.

Post by Tobias Gruetzmacher
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."

[Sokar Someone]

*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 asked.

--ME

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

Post by Tobias Gruetzmacher
Hi,

Post by Paul Gray
Just in case anyone's curious about the front-end build customization that I
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 :)

Post by Tobias Gruetzmacher

Post by Paul Gray
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!

Post by Tobias Gruetzmacher

Post by Paul Gray
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."

Post by Tobias Gruetzmacher
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.

Post by Tobias Gruetzmacher
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-----
_______________________________________________
Lnx-bbc-devel mailing list
http://zork.net/mailman/listinfo/lnx-bbc-devel

--
irc.virrox.com #cedarlug

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

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

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

[Paul Gray]

Post by Sokar Someone
*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 asked.

There's a vcheck-based approach that pulls the MASTER_SITES and versions from
the Makefiles and checks availability/latest versions.

I'll see if I can resurrect the scripting foo that pulled that together.
- --
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."

[Paul Gray]

Post by Paul Gray
There's a vcheck-based approach that pulls the MASTER_SITES and versions from
the Makefiles and checks availability/latest versions.
I'll see if I can resurrect the scripting foo that pulled that together.

Attached is the gar2vcheck script that Bill Immerman put together to do version
checking. It was posted, along with usage descriptions, circal Nov 2003. It
parses the GAR tree and generates a file suitable for vcheck.