Emdebian now has a working usercase for the crossbuilt usertag and this is used to tag existing Debian bug reports as relating to crossbuilding. It may be time to turn that usertag into a BTS tag. [0] [1]
"crossbuilt :
This bug either occurs when the package is built using a cross
compiler or prevents another package being crossbuilt successfully."
As such, it would be used for FTBFS bugs in cross building packages at a
virtual severity of minor initially and would include bugs where
--build and --host or DEB_BUILD_OPTIONS="nochecks" are not correctly
supported in debian/rules, where CC_FOR_BUILD may be needed in the
package itself to compile programs within the build for various
processing requirements as well as bugs in -dev packages where the
pkgconfig file is incomplete etc.
Currently, I have only filed bugs using the crossbuilt usertag when I
already have a fix and a patch. I need to start extending that soon to
include bugs where I have not been able to identify a fix yet, where
others can see the problem and possibly contribute solutions.
One or two of the existing bug reports with the crossbuilt usertag would
then be re-tagged with a new usertag (nodocs), relating to the need for
wider support for DEB_BUILD_OPTIONS="nodocs" which although vital to
Emdebian, isn't directly related to the cross building process.
I'm wondering about a pseudo-package for Emdebian itself:
1. When a package, foo, has been crossbuilt successfully but cannot be
uploaded because a dependency, bar, is failing to cross build, file a
bug against buildd.emdebian.org showing foo as Blocked by #number in
bar. The bug report against bar would be a normal BTS report against
that package, tagged "crossbuilt". (I need easily available data on
which packages are causing the most trouble.)
e.g.:
#465248 bar: mass bug filing for cross building support.
Tags: crossbuilt.
...
# 465mumble : buildd.emdebian.org [foo] {arm} : new version available.
Blocked by #465248
Emdebian has custom scripts to detect these situations (using
edos-debcheck) because the normal method of relying on a pbuilder /
chroot build cannot pick up these cross-building dependency issues. This
bug type would not normally occur in Debian - the package would simply
FTBFS due to a missing dependency but still be installable.
2. When a package has had a crossbuilding fix applied but still needs
nodocs support or nochecks support implemented via debhelper etc., file
a bug against the pseudo-package, again, blocked by the debhelper or
cdbs bug.
3. When a package has been crossbuilt and uploaded but the installed
package does not behave as the Debian package would behave - i.e. where
crossbuilding might have introduced a new bug by changing dependencies
or removing a file that should be included.
4. When a package has unwanted dependencies in Emdebian - typically
because the Emdebian package needs to be built with --disable-foo
instead of --enable-foo. (Note that {4} may cause {3} - in which case a
functional package split or a new generated package may be needed to
have both build options available as separate packages).
5. One pseudo-package for all Emdebian architectures, just use the
[package]-{$ARCH} prefix in bug titles - including
[package]-{i386-linux-uclibc} where appropriate. I'll be starting on
prebuilt packages for armel and i386 soon and experimental uClibc
support is already available in emdebian-tools (>= 1.0.0).
6. The majority of these bug reports against buildd.emdebian.org would
be automatically generated. The existing embug script in emdebian-tools
already uses SOAP to get information on existing bugs, it can migrate to
storing bug information in the BTS under this pseudo-package instead of
only being able to create a local log file.
7. Where a crossbuilt package now fails the lintian test for cross-built
packages (lintian -ioC em) e.g. when the lintian check script provided
by emdebian-tools is updated. (Packages are not uploaded if the build
fails the cross-building lintian test.) [3]
8. Not all bugs against the buildd.emdebian.org pseudo package would be
tagged crossbuilt - some architectures used by Emdebian (like
i386-linux-uclibc) would not be cross built, just built normally with
DEB_BUILD_OPTIONS and a uClibc toolchain.
9. All BTS mail for the buildd.emdebian.org pseudo-package would need to
go to [EMAIL PROTECTED]
This, I believe, would be a useful step towards achieving an "unofficial
port" status for Emdebian packages in the PTS, similar to hurd-*
sometime after Lenny, as well as providing the data I need to get
Emdebian into a fit state to "release" alongside Lenny (albeit only
releasing a root filesystem because most embedded devices need
specialised kernel and module configuration as well as custom
installation methods).
That, in turn, would help to show the benefits of the Emdebian package
by listing the package size reduction in the packages.debian.org pages.
Only a fraction of the packages in Debian would show up in Emdebian.
Currently, we have 211 source packages, building 642 binaries. [4] (I am
looking at d-i support for Emdebian but haven't had time to look at it
closely since talking to Frans Pop at FOSDEM.)
Comments?
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337733#10
[1] http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]
[2] http://www.emdebian.org/bugs.php (parses the same tags)
[3] http://wiki.debian.org/EmdebianPolicy
[4] http://www.emdebian.org/packages/search.php
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
