On Tue, 23 Jun 2009 18:56:07 +0100 Wookey <wookey@wookware.org> wrote: > emdebuild -a arm build-dep > (instead of) > emdebuild -a arm --build-dep > then it carefully emdebianises your sources (changelog and rules). > This is quite annoying, and could probably be considered a bug. Ah, I see what's happening. It is assuming that this is an option to pass on to dpkg-buildpackage. Use 'emdebuild -v ...' to see what command is actually being passed down to dpkg-buildpackage: $ emdebuild -v build-d ... DEB_BUILD_OPTIONS='nodocs nocheck' \ DEB_VENDOR='emdebian-crush' nice -n 7 dpkg-buildpackage -aarmel -sa \ -rfakeroot -d -us -uc build-d > It would be better if it complained of invalid syntax (I don't think > the first line is valid, is it?). Umm, it would be if dpkg-buildpackage understood that command. emdebuild parses whatever it recognises from @ARGV and then bundles the rest into an array to be passed onto dpkg-buildpackage. Unfortunately, before dpkg-buildpackage can receive (and sanity check) these arguments, emdebuild has to setup various parts of the cross-building environment and sort out the patch support directories. > That's an easy fix and I really > ought to offer a patch...but my perl-foo isn't quite up to it. It > looks like the code only checks for options it doesn't understand, but > doesn't check if there is a left-over non-option paramter at the end. This is intentional, but not quite working as expected: $ emdebuild -? "Options to dpkg-buildpackage can be specified after the -- option. Note that '-uc' and '-us' are set by default and '-a' will be ignored (because arch is controlled separately). Options are passed down to emdebuild unchanged." So: (note: deliberately misspelt) $ emdebuild --build-de Unrecognised option error from emdebuild $ emdebuild -- build-de dpkg-buildpackage complains of bad option/argument What goes wrong is with: $ emdebuild build-dep I'll investigate that one. Please file a bug so that I don't forget. (emdebuild should only pass on arguments after ' -- ') > 2) More significant issue. > > If I have a sources.list like this (i.e. stable stuff only): > deb http://ftp.uk.debian.org/debian lenny main > deb-src http://ftp.uk.debian.org/debian/ lenny main deb http://ftp.uk.debian.org/debian/ lenny main would probably work. Note the '/' after the final debian in the URL. > apt methods failed for libdirectfb-dev_1.0.1-11_arm.deb, falling back to direct cache path. > Trying: path=http://www.emdebian.org/debianpool/main/d/directfb/libdirectfb-dev_1.0.1-11_arm.deb Bah! This has happened before - you've not put a '/' at the end of the requested apt source so that this command gets 'debian/pool/', not 'debianpool/' - the tools are trying to show you where it has gone wrong, that path is clearly wrong. Not sure why it is looking for that package in emdebian.org though. I think that's wrong, it should be looking in normal Debian - as long as it looks in Lenny. > So I think all that is needed is a way to tell emdebuild which suite(s) > to use or better, for it or apt-cross to use the ones in the apt lists. No, it's a path-assembly problem. apt-cross is being a little too careful to avoid 'debian//pool' when it would actually be fairly painless to let it pass. > Attached is the patch that Neil did a which time ago for emdebuild to > have a -S Suite override. I guess this is already in newer versions of > emdebian-tools? It is in 2.0.0 and later. > still fails to find any packages, but > emdebuild -a arm -S lenny -v --build-dep > does now work - hooray! > hmm, but apt-cross -a arm -i libgtk2.0-dev > doesn't. Isn't that the same issue as #502433 ? # emdebuild -a arm -v --build-dep processing libcups2-dev conflicts libcups2-dev conflicts with libcupsys2-dev (<< 1.3.7-6) libcupsys2-dev (1.3.8-1lenny2) is newer (which is OK). processing libcups2-dev dependencies. libcups2-dev Depends : libcups2 (1.3.8-1lenny2) Adding libcups2 libcups2-dev Depends : libgnutls-dev (2.4.2-1) Adding libgnutls-dev libcups2-dev Depends : heimdal-dev (1.2.dfsg.1-2.1) Adding heimdal-dev libcups2-dev Conflicts : libcupsys2-dev (1.3.8-1lenny2) The problem there is heimdal-dev which has a circular conflict and must never be installed if you want to be able to build Gtk. (heimdal conflicts with some package I can't remember that is either a build-dependency or a dependency of another build-dependency of Gtk). The solution is to install libcups2-dev manually - whereupon the conflict is resolvable and because it exists, heimdal-dev doesn't get a look-in. Once again, the apt perl bindings are responsible. > why does emdebuild need to be told which repo to use? Is there a > reason why can't it work it out from the apt sources list? Yes, there is. Many, many, Debian boxes use a mix of suites and it is a relatively complex and very unpredictable mechanism to parse them all, work out the priorities and decide which one to get from where. It is certainly too complex for the apt perl bindings. I tried many methods of trying to guess this value but each one failed under different tests - most commonly when users has CDROM/DVD sources still in their lists. This will all go away once we can stop using those horrid apt perl bindings and get to use the real C++ apt via multiarch because the real apt *can* work out these issues (because certain imperatives within Debian absolutely require that it does and because these issues are only possible because it can) whereas the perl bindings cannot (because nothing critical within Debian breaks if they cannot). -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpD5UVcwEHoc.pgp
Description: PGP signature