[Live-demo] Ideas for Collaboration

[Alex Mandel]

Hamish wrote:
> Alex  wrote:
>> I've been thinking about is some and I have a plan or at
>> least an idea for a plan.
>>
>> I think we need:
>> 1. packages built and available through standard repos or
>> launchpad
>> 1a. when you custom compile, instead of a make install use
>> checkinstall which creates a deb file at least good for that
>> system, should be fairly universal on a live-dvd, it will also
>> show up in the package management.
>> 1a2. Upload the deb files to a launchpad repo for install
>> on other live-dvds. Note: these are not official deb packages
>> and may not work on anything other than the live-dvd.
>> 2. A script which loads and actives including gpg keys for
>> repos that contain Geo Foss software, ie QGIS launchpad
>> 3. A script with dpkg -l list of packages, basically run
>> this and it will install all the geo based packages
>> 4. A configure script, which will setup things like system
>> user,postgis user, and maybe things like splash screen,
>> desktop etc.\
>> 4a. A script to add add-ons like qgis python plugins, etc.
>> 5. A list of optional things that can be changed and how to
>> change them
>> 5a. Language
>> 5b. Desktop Background
>> 5c. Screensaver of FOSS screenshots
>>
>> Everything from 2+ can be stored in a version control.
>>
>> So the workflow would look like:
>> 1. Download the U(X)(K)buntu variant you want to use.
>> 1a. Install to partition or virtual machine
>> 2. Checkout the scripts from svn
>> 3. Run the scripts
>> 4. Customize datasets and configuration
>> 5. Remastersys
>> 6. Upload/Burn
>>
>> A good server to upload the variants to would be nice at
>> some point, since there are bound to be variants.
>>
>> What do people think?
> 
> 
> I think most of the tools we need to accomplish what is
> described above are already in place by way of the live-helper
> package in Debian+Ubuntu.
> 
> "live-helper suite to autobuild images non-interactively"
> 
> see
>  http://debian-live.alioth.debian.org/
>  http://wiki.debian.org/DebianLive/
>  http://live.debian.net/manual/
>  http://packages.ubuntu.com/search?keywords=live-helper
> 
> 
> I have been playing with it recently and it is rather nice once
> you break through a bit of the learning curve. (typically it is
> reusable knowledge thankfully)
> 
> 
> the general idea is that you 
> 
> 0. install the live-helper package,
> 1. mkdir live-iso; cd live-iso/
> 2. run "lh_config -p gnome" (or kde or minimal wm...)
> 3. now you have a directory tree that looks like:
> 
> ../config:
> binary
> binary_debian-installer/
> binary_debian-installer-includes/
> binary_grub/
> binary_local-debs/
> binary_local-hooks/
> binary_local-includes/
> binary_local-packageslists/
> binary_local-udebs/
> binary_rootfs/
> binary_syslinux/
> bootstrap
> chroot
> chroot_apt/
> chroot_local-hooks/
> chroot_local-includes/
> chroot_local-packages/
> chroot_local-packageslists/
> chroot_local-patches/
> chroot_local-preseed/
> chroot_sources/
> common
> includes/
> source
> templates/
> 
> 4. the files we are interested in are in the config/ dir
>    these are just text files and scripts, easily stored in svn.
>    I expect a max of a few hundred kb for our needs (+graphics)
> 5. tweak config/binary, bootstrap, chroot, common, source
>    and /etc/default/live-helper_autobuild rc files to suit
> 6. put a list of official packages to include (1 per line) in a
>    file in chroot_local-packages-list/
> 7. entire custom .debs can be added to chroot_local-packages/
> 8. alternate download sites (e.g. qgis.deb) can be included
> 9. any files to end up in the user home dir go in (e.g.)
>    chroot_local-includes/home/user/geodata/
>    I'm pretty sure you can add symlinks there to local files.
> 10. any files to overwrite go in the same place, e.g.
>    chroot_local-includes/etc/rc.local
> 11. put any patches to system files in chroot_local-patches/
>    they'll be applied during the build.
> 12. put any scripts to run during the build (e.g. wget data)
>    into chroot_local-hooks/
> 13. etc.
> 
> 14. when done run "lh_build" and some minutes later you have a
>   file called binary.iso. test with qemu.
> 
> 15. if you change something run "lh_clean" then "lh_build again"
> 
> 
> So my suggestion would be to put set everything up to auto-
> install/build/download/collect into the config/ dir, and keep
> that config dir in SVN.
> 
> to build an ISO you would just need to 'svn checkout' the
> appropriate variant and run "lh_build". a cron job could do
> that to build a full ISO for distribution from the website once
> a week or so.
> 
> We have a svn repo for DebianGIS which could be used for this,
> write-access can be gained upon request. I might set that up
> anyway for a DFSG-compliant geodata variant run by DebianGIS.
> 
> or if folks prefer we could ask to set one up at OSGeo's servers.
> An advantage of hosting it as OSGeo is that we could use the
> nicely integrated "trac" system to deal with bugs, wishlists,
> wiki how-tos, task lists, etc. see gdal, qgis, or grass's for
> an example:  http://trac.osgeo.org/qgis/
> DebianGIS has a bug-tracker on Alioth, but it is not as nicely
> integrated or project-specific.
> 
> SVN branches could be used for variants and updates cross-
> pollinated between branches.
> 
> a start is to throw the DebianGIS package list (or debian-edu
> geography list) into chroot_local-packagelists/
> see  http://wiki.debian.org/DebianGis/PackageList
> 
> 
> Surely keeping several mostly-parallel 4gig .iso up for download
> and outside of revision control does not scale very well at all!,
> and does not allow for trivial upgrades to new OS releases or
> a trivial switch to build a USB-drive version instead of an ISO.
> Not to mention being pretty hard on those of us with limited
> bandwidth (currently I can't even test what's done let alone
> help with it..).
> 
> 
> Personally, I'm pretty sold on the live-helper approach.
> 
> 
> Hamish
> 

It had appeared to me that the current OSGeo related disc were being
done using remastersys, I'll have to look more at live helper. The other
issue though is that much of what people might add is not in .debs at
all and bash scripts with wget and cp commands plus dropping in
configure files might make those easier (I'm talking mostly Java apps
here), plus how do you configure the user home directory on these
things, and permissions, I seem to recall that was a problem previously.

But my real concern is that I don't want to waste time building the iso
before I know that everything is working correctly. Every one of the
discs I've tried so far has had various issues that you didn't really
figure out until you tried opening every Geo application installed to
see what it does.

My thought about the multiple .iso files is that people want local
versions, in local languages with local datasets. Yes overall we can
have 1 generic one we keep on osgeo downloads, but if gfoss.it wants an
italian version in italian with italian language it should be easy to
just change the script to pick a different language, and wget a
different dataset.

Since the primary use seems to be people who are going to teach demos,
or exhibit and not just end users directly downloading I don't think the
speed of iso download will be a giant issue, especially if it's a local
project where you can post or hand copies to others, or order batch
copies made. But we should investigate setting up a bittorrent tracker
or download mirrors.

Thanks,
Alex