On Wed, 2008-02-20 at 07:56 +0100, Simon Richter wrote:
(CC'ing Simon directly because I posted to this list several times
yesterday with BTS content and the posts still have not shown up.)
> Hi,
>
> following yesterday's IRC discussion I've built a small script that
> prepares dpkg-cross'd packages and publishes them in a repo.
>
> I've built arm overnight, armel is still building; we need about 1 GB
> per arch.
>
> APT source line is
>
> deb http://www.emdebian.org/debian-cross sid main
There are problems using that source, before everyone tries using it:
$ sudo apt-get update
$ sudo apt-get dist-upgrade
The following packages will be REMOVED
apt-arm-cross apt-utils-arm-cross cpp-4.2-arm-linux-gnu g++-4.2-arm-linux-gnu gcc-4.2-arm-linux-gnu libapt-pkg-dev-arm-cross
libcppunit-1.12-0-arm-cross libcppunit-dev-arm-cross libcwidget-dev-arm-cross libcwidget1-arm-cross libfam-dev-arm-cross libfam0-arm-cross
libgl1-mesa-dev-arm-cross libglu1-mesa-arm-cross libglu1-mesa-dev-arm-cross libglu1-xorg-dev-arm-cross libgnutlsxx13-arm-cross
libpcre3-dev-arm-cross libpcrecpp0-arm-cross libsigc++-2.0-0c2a-arm-cross libsigc++-2.0-dev-arm-cross libslang2-dev-arm-cross
libstdc++6-4.2-dev-arm-cross libstdc++6-4.2-pic-arm-cross libstdc++6-arm-cross libtiff4-dev-arm-cross libtiffxx0c2-arm-cross
Yep, that's my toolchain being removed, along with a few other packages.
193 upgraded, 26 newly installed, 27 to remove and 2 not upgraded.
Need to get 28.9MB/140MB of archives.
After this operation, 53.5MB of additional disk space will be used.
Do you want to continue [Y/n]? n
edos-debcheck
< /var/lib/apt/lists/www.emdebian.org_debian-cross_dists_sid_main_binary-amd64_Packages
Shows lots and lots of failures - despite avoiding toolchain-like
packages, lots and lots of -cross packages depend on things like
libgcc1-arm-cross (>= 1:4.2.1) {NOT AVAILABLE}
edos-debcheck -explain -failures
< /var/lib/apt/lists/www.emdebian.org_debian-cross_dists_sid_main_binary-amd64_Packages | grep AVAILABLE | grep -c libgcc1-arm-cross
Parsing package file... 1.3 seconds 8097 packages
Generating constraints... 0.4 seconds
Checking packages... 2.8 seconds
2354
(libgcc1 is such a PITA)
I'm wondering if it is safe to persuade dpkg-cross to *not* generate any
dependencies on libgcc1, *ever*. Effectively ban dpkg-cross from
tinkering with -cross packages that are essential to toolchains.
(libstdc++6* would also need to be banned.) I am not sure whether that
would be workable - it seems like a gross hack.
Other edos errors include:
x11-common-arm-cross (>= 1:7.0.0) {NOT AVAILABLE} (198 instances)
sysvinit-arm-cross (= 2.86.ds1-53) depends on initscripts-arm-cross
{NOT AVAILABLE}
libstreams0-arm-cross (= 0.5.7-2) depends on libstdc++6-arm-cross (>=
4.2.1) {NOT AVAILABLE}
guile-gnome0-glib-arm-cross (= 2.15.95-2) depends on libffi4-arm-cross
(>= 4.2.1) {NOT AVAILABLE}
libg2c0-arm-cross (>= 1:3.4.4-5) {NOT AVAILABLE}
libstdc++6-arm-cross {NOT AVAILABLE}
libvncauth-dev-arm-cross (= 3.3.7-14) depends on dpkg-arm-cross (>=
1.6.8) {NOT AVAILABLE}
Most of these arise because, as I outlined on IRC, dpkg and therefore
dpkg-cross has no idea what kind of package x11-common *is* whilst it is
processing x11proto-core-dev-arm-cross or libx11-dev-arm-cross or
libxau-dev-arm-cross. That information only comes from the apt cache -
via apt-cross.
> The script isn't perfect yet, it's a first hack. Known problems:
The script desperately needs to interface with apt-cross and
edos-debcheck. The script needs to give information to dpkg-cross about
the kind of package described in Depends:. dpkg-cross knows all it needs
to know about the package described by Package:, it needs to know almost
as much about each package listed in Depends: - at the absolute minimum,
it needs to know the Architecture: and the Depends: and then be able to
get recursive information about each of those Depends and so on.
>
> - Does not handle virtual packages (rather, it tells dpkg-cross to
> remove the alternatives from the Depends line, which is suboptimal)
> - Does not handle removals and packages that have become
> "uninteresting" in the last upload
> - Does not handle "interesting" packages depending on "uninteresting"
> ones that depend on an "interesting" one.
> - Mistakenly identifies "caudium" as interesting, because it has
> symlinks whose names end in .h below /usr/lib.
>
> A copy of the script lives at
>
> http://www.emdebian.org/debian-cross/update-cross-repo.pl
>
> It might be obvious, but perl is not my native language. :-)
Maybe if I'd had a chance to have reviewed that script before the source
was described on the mailing list, we could have come up with a fix for
some of these problems. Unfortunately, in between speaking on IRC and
waking up, the -cross repo appeared.
> I wonder whether it would make sense to also have a blacklist for
> kdeinit libraries, as these are never linked against, but are placed in
> /usr/lib, or if it makes more sense to prod the KDE maintainers that
> they move their plugins out of /usr/lib into some subdirectory (where
> they'd be ignored).
>
> Simon
Right now, some method of protecting the toolchain from this -cross
source is more important. Please fix the arm -cross repo before
proceeding to other architectures.
Try
concatenating /var/lib/apt/lists/www.emdebian.org_debian_dists_unstable_main_binary-amd64_Packages onto /var/lib/apt/lists/www.emdebian.org_debian-cross_dists_sid_main_binary-amd64_Packages and running 'edos-debcheck -explain -failures < newfile' on it. That should indicate where the two repositories clash - in amongst the existing problems in the toolchain repository itself. (I did say on IRC that I didn't think this -cross repo would be easy to maintain.)
You may have to concatenate a normal Debian Packages list onto 'newfile'
too to at least try to resolve some of the toolchain dependencies.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part