[Server-devel] XS-0.7 CentOS6.2 rebase - other pending items

Daniel Drake dsd at laptop.org
Thu Feb 9 17:48:51 EST 2012


I now have an XS fully up and running and passing all my basic tests.
Here are the remaining items that need addressing before we have a
test release:

ejabberd - see the other thread. Need to decide on forking the package
as 'ejabberd' or 'ejabberd-xs' to move forward. Once that is done, I
will update xs-config (if needed) and then push and release all the
other components you have already reviewed.

moodle - pu branch ready for review. If you're going to pull in moodle
updates as well, now is the time :)
I have tested this quite well, including the interaction with mod_admin_extra.

xs-release - how do we go forward with this? I think we should drop
the old approach (of *replacing* the system release package) and take
the epel-release approach of just (additionally) installing our repo
files. But I'm not sure how you want this in git - existing branch of
existing repo, new repo? Or maybe I could create a new
packages/xs-release repo, with all the files contained in the spec
file repo (i.e. doesn't pull in a tarball, just ships the trivial repo
files directly).

xs-logos - Haven't really looked what this has. Given that we don't
face copyright/trademark restrictions of the logo package in CentOS,
can we just drop this?

usbmount - I had to update to the latest version. It no longer uses
any patches (they are all obsolete/upstream). How do I take care of
this w.r.t. your existing usbmount git repository, where you actually
forked the source? Perhaps we could just drop/obsolete that git repo,
and create a new packages/usbmount repo with the simple .spec file?

olpc-xs-builder - pu branch ready for review. Might need tweaking
based on the outcome of the above. I dropped the idea of running
xs-setup during the install, since the user might choose a hostname
that doesn't start with "schoolserver.". The installation instructions
will require the user to run xs-setup after the install completes.

repos - I have reorganised slightly http://dev.laptop.org/xs/
"repos" is now a subdirectory there, which will be our main URL from now on.
But the other URLs still work: http://dev.laptop.org/xsrepos/
Also, I have created aliases at http://dev.laptop.org/xs/stable and
http://dev.laptop.org/xs/testing for the repos. This means that if we
update the DNS of fedora.laptop.org, we will fix "yum update" / "yum
install" for the existing XS's in the field, which use such addresses.
What do you think?

I had to bring some packages in from Fedora, these are:

bitfrost-1.0.15-3.el6.i686.rpm - not in RHEL/EPEL. Recompiled for EL6
from rawhide.
mtd-utils-1.3.1-3.fc14.i686.rpm - dep of bios-crypto, imported from F14

kernel- - as previously agreed, imported from F15
(kernel-* subpackages too)
grubby-7.0.16-5.fc15.i686.rpm - dep of kernel, imported from F15
linux-firmware-20110601-1.fc15.noarch.rpm - dep of kernel, imported from F15
module-init-tools-3.16-2.fc15.i686.rpm - dep of kernel, imported from F15
acpid-2.0.9-1.fc14.i686.rpm - imported from F14. Needed for compat
with new kernel.

rssh-2.3.3-2.el6.i686.rpm - imported from EPEL-6 updates
syck-python-0.61-12.el6.i686.rpm - dep of ds-backup, not in RHEL/EPEL.
F14 version recompiled for EL6.
syck-0.61-12.el6.i686.rpm - dep of syck-python

Is it OK to stick these in the core xs-0.7 RPM repo, or would you
prefer a separate "fedora-ports" repo to be created? (I vote just the
one :))


More information about the Server-devel mailing list