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

[Martin Langhoff]

On Thu, Feb 9, 2012 at 5:48 PM, Daniel Drake <dsd at laptop.org> wrote:
> 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:

Great news.

> ejabberd - see the other thread. Need to decide on forking the package
> as 'ejabberd' or 'ejabberd-xs' to move forward.

I prefer "ejabberd" + a custom revision prefix. I see you intend to
blacklist ejabberd from the main epel repo.

For users that install CentOS and *then* install our stuff, we may
need to add a warning if we don't see our custom revision prefix. It's
gotta be a soft warning 'cause we don't really know if it's wrong or
not.

Alternatively,  we could make our ejabberd package provide
"ejabberd-xs" or something like that, and xs-config depend on it.

If a later ejabberd release has a means to enable the behaviour we
want, we can teach xs-config about depending on that one instead.

> moodle - pu branch ready for review. If you're going to pull in moodle
> updates as well, now is the time :)

Great. I'll review a bit later.

> I have tested this quite well, including the interaction with mod_admin_extra.

Excellent.

> 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

Absolutely. It's a bit more tricky with the blacklisting of ejabberd
you're proposing but yeah.

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

Your packages/xs-release plan sounds ok. That was _never_ actually
used, unless Jerry based something on it, so I'd say it's ok to wipe
it.

Otherwise just wipe master and reshape it in any way you want...

> 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?

I think it's ok to skip it for now, but we'll bring it back .

> usbmount - I had to update to the latest version. It no longer uses
> any patches (they are all obsolete/upstream)

that's good news!

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

Yep, a fedpkg style repo (thjat's what I prep'd the "packages" directory for.

For those cases, we'll work on getting them into Fedora/EPEL infra,
but _after_ this release cycle.

> olpc-xs-builder - pu branch ready for review.

Looks good,
 - where do you maintain the groups file?
 - does the resulting .iso file convert and now run nicely from USB
media? this used to be flakey...

> xs-setup during the install, since the user might choose a hostname
> that doesn't start with "schoolserver."

True, we hadn't considered that.

>. The installation instructions
> will require the user to run xs-setup after the install completes.

That's perfectly acceptable. Worse things have happened at sea.

> 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/
> http://dev.laptop.org/~martin/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?

Oh thanks! Yes please!

> 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-2.6.42.2-1.fc15.i686.rpm - 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

I'm surprised the list is so short!

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

Just one. Going foward, we'll push to get those packages in
Fedora/EPEL (where possible) so we migrate towards the fedpkg/koji
infra.

AIUI, groups can only refer to packages in the same repo -- how do you
bring in things like puppet?

thanks!



m
-- 
 martin at laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff