On Thu, 2008-04-17 at 13:14 +0200, Peter Eisentraut wrote: > Package: dpkg-dev > Version: 1.14.16.6 > Severity: wishlist > > There are some sporadic bug reports around like #315935 that basically say > that the package cannot be cross-compiled.
Actually, ntp can be cross-compiled: http://www.emdebian.org/packages/search.php?arch=arm&distro=unstable&package=ntp The current patch set is here: http://buildd.emdebian.org/svn/browser/current/target/trunk/n/ntp/trunk/ During the development of emdebian-tools I am slowly partitioning those patches into bug reports for debhelper, dpkg (now fixed), cdbs and the packages themselves such that the patches do not affect normal Debian builds. ntp is one of the ones that needs this process and is likely to receive a crossbuilt wishlist bug (with patch) soon. I haven't uploaded the most recent crossbuilt ntp to Emdebian because it has a dependency on libgcc1 and gcc-4.3 currently fails to crossbuild (reverse cross) and I haven't been able to work out why yet. > I think it would be useful to have > a control field that told dpkg-buildpackage that cross-compiling won't work NO! Please can we just fix the package so that it does cross-compile?? It certainly does not warrant adding yet another control field. Put a static message on the PTS if you want - or ask about a debtag "not-likely-to-crossbuild". I've been doing loads and loads of work on this and the situation is as follows: 1. If a bug claims that the package cannot be cross-compiled but that bug report is NOT tagged with 'crossbuilt' '[EMAIL PROTECTED]' i.e. it is not on this list: http://www.emdebian.org/bugs.php or http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=crossbuilt;[EMAIL PROTECTED] then there is every chance that the bug report is void and that the package WILL cross build with sufficient support, namely emdebian-tools. The majority of that support is now implemented in dpkg-dev 1.14.18 so things have changed SIGNIFICANTLY in only the last week or two. 2. If the package exists in Emdebian as a target package: http://www.emdebian.org/packages/search.php then it most certainly DOES cross build (or at least a relatively recent version did). It is certainly possible that the changes between then and now have broken the cross build but that is probably best checked by CC'ing me or [EMAIL PROTECTED] 3. If a bug exists in the above reports, merge the old report (lowering the severity if necessary) with the existing Emdebian crossbuilt bug report. 4. If a package really does not make sense crossbuilt (OOo or other enormous packages like games that make no sense on low resource units), then that can be left as a wontfix bug or closed and CC'd to me or debian-embedded or send a static message to the PTS for the package. > for the package in question. (dpkg-buildpackage uses the Architecture field > to see whether the package will build for a given architecture, so this would > be quite similar.) Or maybe another way to convey this information would be > better, but I think this ought to be recorded somewhere so that the > cross-building folk don't waste their resources. The number of packages in this situation is already quite small, advances in dpkg and emdebian-tools are making the number smaller still and I intend to ensure that Debian has whatever support is necessary to allow cross building of every Debian package within limits of what is considered sane for a low resource unit. > Policy isn't entirely clear. Section 4.9 mentions the DEB_*_ARCH variables, > but it is not clear whether their use is mandated. In bug #315935, it is > opined that cross-build support isn't mandatory, which is of course the > practical reality anyway. True, sadly. However, cross building has become a lot easier due to the recent fixes in dpkg and interest is growing. All crossbuilding bugs are currently wishlist. I will look at creating a patch from the existing Emdebian patch files and including them in this bug report but something along these lines is probably going to be included: --- ntp.old/debian/rules Sun Dec 9 00:00:16 2007 +++ /opt/emdebian/trunk/n/ntp/trunk/ntp-4.2.4p4+dfsg/debian/rules Sun Dec 9 00:00:17 2007 @@ -2,6 +2,14 @@ include /usr/share/quilt/quilt.make +DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +DEB_BUILD_GNU_TYPE=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) +CROSS= --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) --cache-file=$(DEB_HOST_GNU_TYPE).cache +else +CROSS= +endif + # hacks to avoid running these things during the build export ACLOCAL = : aclocal export AUTOCONF = : autoconf @@ -18,7 +26,7 @@ config: patch config.status config.status: $(QUILT_STAMPFN) dh_testdir - ./configure CFLAGS='$(CFLAGS)' \ + ./configure CFLAGS='$(CFLAGS)' $(CROSS) \ --prefix=/usr \ --enable-all-clocks --enable-parse-clocks --enable-SHM \ --disable-debugging --sysconfdir=/var/lib/ntp \ The remaining problem is how to cope with these cache-files for ./configure data that would normally be determined by running a binary compiled during the ./configure operation. Cache files are a bit of a hack really and risk going stale in some circumstances. I'm investigating any other methods if anyone has ideas.... -- 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
