git.tremily.us Git - catalyst-swc.git/log

fsscript.sh: Make a ~swc/.fluxbox/ directory for fluxbox-generate_menu

And make sure everything under ~swc/ is owned by swc.users.

This fixes:

  Running fsscript.sh in chroot /.../livecd-stage2-i686-2013.1/
  touch: cannot touch '/home/swc/.fluxbox/menuconfig':
    No such file or directory
  Warning: I couldn't create /home/swc/.fluxbox/menuconfig
  Fatal error: can't create or write to /home/swc/.fluxbox/menu

spec: Update snapshot from 20130320 to 20130328

This gets us app-text/poppler-0.22.2-r2, which closes some CVE issues
(with 0.22.1) and works with evince (with 0.22.2-r2). For details,
see #459866 [1].

[1]: https://bugs.gentoo.org/show_bug.cgi?id=459866

portage-conf/default: Don't bring in wxpython 2.9.4.1

Limit the number of testing (~x86) packages.

I'm not quite sure why wxpython 2.9 is being drawn in, but disabling
these use flags seems to fix it.

spec: Update snapshot from 20130308 to 20130320

default-livecd-stage1-i686-2013.1.spec: Remove x11-misc/slim

I have the following patches in my build version of catalyst:

* livecdfs-update.sh: Use `bash --login` to spawn startx
* livecd-bashrc: Avoid a startx race by restricting to tty1

which allow me to boot directly into startx without needing a login
manager.

fsscript.sh: Call fluxbox-generate_menu to pickup Firefox, etc.

Nothing installed after Fluxbox shows up in the Fluxbox menu unless
you regenerate the menu. There's not much on this livecd, but having
a menu entry for Firefox is important, and before this commit it was
missing (as reported by Jon Pipitone).

portage-conf: Move package.keywords to package.accept_keywords

This brings me up to date with Portage's 39020a6 (Add support for
/etc/portage/package.accept_keywords, 2010-08-15) [1].

Thanks to Chí-Thanh Christopher Nguyễn (chithead) and Ben Kohler
(iamben) for pointing this out to me on #gentoo.

[1]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=39020a6a418c0910b372e04a8f4959ce258d1989

spec: Convert /mnt/d/... to /var/tmp/catalyst

It's easier to reuse these spec files if I stick to a standard
location and:

# mount --bind /mnt/d/... /var/tmp/catalyst

to attach my extra space to the standard location.

package.keywords: Add additional ~x86 keywords

As directed by emerge in order to emerge our target packages.

spec: Update snapshot from 20130208 to 20130308

default-stage1-i686-2013.1.spec: Add 'update_seed=yes'

The 2012-12-13 stage3 uses libmpc.so.2, but the 2013-03-08 Portage
snapshot installes libmpc.so.3.

overlays/default: Add README and equery-licenses

The packages distributed in the release ISOs are distributed under a
range of licenses, but in the ISO we distribute them without their
source. Since many licenses (e.g. the GPLv2, section 3) require you
to also distribute or provide access to the corresponding source code,
it's good to be clear about the licensing of the bundled binaries.

The large list of installed packages and licenses can also serve as a
teaching tool for explaining how open source development works, and
emphasizing why using a standard license is a good idea ;).

default-livecd-stage1-i686-2013.1.spec: Add bindist to livecd/use

Firefox doesn't allow branded binary distribution by third parties,
and there may be other packages with binary distribution restrictions.
Enabling this USE flag ensures that we don't run afoul of these
restrictions.

package.keywords/ipython: Fix '~amd64' -> '~x86' typos

Oops, sloppy me.

portage-conf/default/package.use/x: Re-break pambase <-> consolekit loop

I's disabled consolekit for pambase in package.use/circular, but this
was re-enabling it (and package.use/x is parsed after
package.use/circular). This dependency cycle broke the stage3 build,
but was, apparently, needed for some later stage. If this fix doesn't
work, we can transition to using different portage-conf subdirectories
for different stages.

default-livecd-stage1-i686-2013.1.spec: Add Firefox package

The previous ISO weighed in at 665 MB, so there should be room for
Firefox to still fit on a 737 MB CD. We need *something* with fairly
modern CSS and JavaScript support for IPython.

default-livecd-stage1-i686-2013.1.spec: Add python to livecd/use

This is required in VTK 5.10.1 by MayaVi 4.2.0, but SWC likes Python,
so we enable this globally.

default-livecd-stage1-i686-2013.1.spec: Add livecd/use with gtk & ipython

These are used by SymPy, but we want to enable them globally in case
other packages use them too.

package.keywords: Add ~x86 where necessary for new packages

default-livecd-stage1-i686-2013.1.spec: Add Mercurial and other packages

With these packages we'll be closer to passing the full
swc-installation-test-2.py suite.

Initial SWC (Gentoo) Linux 2013.1 x86 configuration

This is the catalyst stuff for building a Gentoo live CD ISO for
Software Carpentry students [1].  It's pretty bare-bones at the
moment, since I tried to keep any non-specfile stuff to a minimum.  It
also requires a few patches on top of the current catalyst master
(37540ff):

  livecdfs-update.sh: Assign users to per-user groups
  livecd-bashrc: Avoid a startx race by restricting to tty1
  livecdfs-update.sh: Use `bash --login` to spawn startx
  livecdfs-update.sh: Escape ampersands in STARTX sed expression
  fixup: env-update
  livecdfs-update.sh: Set XSESSION in /etc/env.d/90xsession
  chmod +x all sh scripts so they can run from the git checkout

This is not the most elegant patch series, and some of these patches
will probably be squashed/tweaked before inclusion in upstream
catalyst.  I'm not even sure if the per-user group patch is a good
idea (but it shouldn't hurt).

My catalyst.conf file looked like:

  digests="md5 sha1 sha512 whirlpool"
  contents="auto"
  distdir="/usr/portage/distfiles"
  envscript="/etc/catalyst/catalystrc"
  hash_function="crc32"
  options="autoresume kerncache pkgcache seedcache snapcache"
  portdir="/usr/portage"
  sharedir="/home/wking/src/catalyst"
  snapshot_cache="/tmp/catalyst/snapshot_cache"
  storedir="/tmp/catalyst"

This repository was checked out into $storedir.

The spec files should be fairly stable (modulo snapshot/version
bumps), but you may need to update the Portage configuration as stable
packages evolve and assorted bugs and incompatibilities are fixed
upstream.

[1]: http://lists.software-carpentry.org/pipermail/discuss-software-carpentry.org/2013-March/000210.html