On Fri, 2008-09-05 at 10:58 -0400, Dean Ustaszewski wrote:
Neil,
I've attached two dumps of emdebuild output for 1.4.6 and 1.4.3.
You mean emdebcheck?
I
also attached the temp file for each with the cache outputs. I'm
still trying to determine if the new emdebcheck (or possibly edos-
debcheck) is artificially failing, or the previous version is
artificially passing, or even if I'm doing something wrong.
The tools appear to be working correctly - your problem is that only
Architecture: all packages are available from the Emdebian target
package repository (emdebian.org/emdebian).
Right now I have a bunch of packages emsource'd and built. As an
example, I went into the gcc-4.3 directory and tried emdebcheck on the
protoize_4.3.1-9em1_armel.deb package and it failed on gcc-4.3 {NOT
AVAILABLE}. One odd thing is that I've also seen it fail on libgcc1
{NOT AVAILABLE}.
It would be correct for it to fail.
One thing I'm not really clear on is how things get into the apt-cache
when you build them from source. Is that something that emdebuild does?
No, when I upload to the official Emdebian target repository, I use
emrecent. It requires a fair bit of configuration for things like dput
and scp/rsync as well as authourized access to the Emdebian server
itself. Allowing those uploads needs to be done with some care because
it would complicate the migration of packages into Emdebian testing and
into Emdebian 1.0 stable (which might or might not include armel when
released alongside Debian 5.0 "Lenny").
Therefore, although support has recently been added to work with
multiple architectures in the report scripts etc., adding a new
architecture to Emdebian is similar to adding a new port to Debian.
There are certain criteria that need to be met - one of which is that
the new autobuilder is at least as reliable as the existing ones so that
when an ARM package needs to migrate to testing, the same version has
also been built for armel. Once armel is accepted, any delays would
complicate the migration of ARM and therefore complicate the release.
So to get to the point where we can add armel, you need to create your
own local repository using reprepro, use reprepro commands to include
the packages. reprepro needs a conf/ directory containing a
'distributions' file with content something like:
$ cat conf/distributions
Origin: Debian
Label: Emdebian-unstable
Suite: unstable
Codename: unstable
Version: 0.1
Architectures: i386 uclibc-i386 arm uclibc-arm armel uclibc-armel
powerpc uclibc-powerpc source
Components: main
UDebComponents: main
Description: Emdebian unstable package repository
The only strings that really matter are Suite, Codename and
Architectures.
reprepro commands need to be either executed in the directory containing
conf/ (so that ./conf/distributions exists) or be given that directory
path using the -b option.
reprepro export
Creates your initial database and directory structure based on the data
on conf/distributions.
reprepro include unstable /path/to/foo.changes
includes all the packages into the repository.
Note that when armel is uploaded to the Emdebian repository, there will
need to be some way of ensuring that your autobuilds use the -B option
to dpkg-buildpackage so that you only upload _armel.deb and not _all.deb
or .diff.gz, .dsc etc. (which already exist from ARM).
Once you are familiar with how these tools work and what can go wrong,
we can look at adding armel. I'm not sure, at present, whether
emdebcheck and emrecent are going to have explicit support for local
repositories. Patches welcome. :-)
I apologize if I'm making a rookie mistake. I'm pretty new to debian
and debian packaging so I get a little confused sometimes with all the
caches and dependencies and whatnot.
Emdebian will require a lot of learning about Debian packaging - there
is no real way to skip that.
Please add things like this to the Wiki so that others can benefit.