Raspbian

From eLinux.org
Revision as of 16:20, 13 July 2012 by Plugwash (talk | contribs) (Modified packages)
Jump to: navigation, search


Raspbian is a project to create a hard float port of debian for the Raspberry Pi and similar devices which use ARMv6 processors with VFPv2. The official debian armhf packages are built with ARMv7, VFPv3_D16 and Thumb2. So they are not suitable for the Pi and similar devices. To get arround this we have to change the compiler defaults (easy) and recompile everything (harder than it sounds).

Infrastructure has been set-up for building packages. We aim to stay as close to debian wheezy as possible but we will pull in packages from sid and/or make our own modifications when we deem it necessary.

A chroot can be bootstrapped from a debian squeeze armel installation using the following commands (replace /chroots/wheezy-armhf-rpi with where you want your chroot).

debootstrap --arch=armhf wheezy /chroots/wheezy-armhf-rpi http://archive.raspbian.org/raspbian
cd /chroots/wheezy-armhf-rpi
wget http://archive.raspbian.org/raspbian.public.key
chroot /chroots/wheezy-armhf-rpi
mount -t proc proc /proc
apt-key add raspbian.public.key
apt-get update

If you just want to install the minimum number of packages add a --variant=minbase to the bootstrap command

Since this is running in a chroot you probably don't want it attempting to start and stop services when you update packages. To avoid this create a file /usr/sbin/policy-rc.d with the following commands

 cat << EOD >/usr/sbin/policy-rc.d
 #!/bin/sh
 echo "rc.d operations disabled for chroot"
 exit 101
 EOD
 chmod 0755 /usr/sbin/policy-rc.d

Modified packages

Note: this list is incomplete

Source package Changes Reason Status Notes
elfutils testsuite disabled testsuite failed on plugwash's build system and package was needed local hack, hopefully we can drop later.
openldap patched smbk5pwd.c compilation failed, added nmu known bug 664930 filed in debian.
gcc-4.6 change compiler defaults need to build binaries suitable for rpi permanent raspbian change, not suitable for pushing upstream
gcc-4.5 change compiler defaults need to build binaries suitable for rpi permanent raspbian change, not suitable for pushing upstream
treat wheezy the same as sid compiler built in wheezy was passing --as-needed to the linker which we don't want could potentially be pushed upstream to debian but given they intend to get rid of the package in the not too distant future i'm not sure there is much point
disable testsuite gcc testsuite takes ages and we don't have the resources to do anything about failures anyway, especially for a non-default compiler version local hack, may be dropped later (but probablly won't)
git testsuite disabled testsuite failed on plugwash's build system and package was needed local hack, hopefully we can drop later.
libatomic-ops fixed support for armv6 package failed to build with assembler errors undecided on whether to push upstream or keep as a local change
gcj-4.6 change compiler defaults need to build binaries suitable for rpi permanent raspbian change, not suitable for pushing upstream
disable testsuite gcc testsuite takes ages and we don't have the resources to do anything about failures anyway, especially for a non-default compiler version local hack, may be dropped later (but probablly won't)
graphviz disable python2.5 python2.5 is no longer a supported python version in debian already filed in debian as bug 669517
openjdk-6 Alter arm_port/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S for armv6 arm version directives in the aforementioned file were making libjvm.so in openjdk-6-jre-headless come out armv7 dirty Probablly not suitable for pushing upstream in present form, may be able to be made suitable with extra conditionalising
Disable icedtex6-jre-jamvm binary package libjvm-so in icedtex6-jre-jamvm was coming out with armv7 code in it Root cause has not been determined, if someone wants to put the effort into determining it that would be appreciated
qt4-x11 Disable neon armv6 doesn't have neon (and not all armv7 systems do either) Debian armhf isn't supposed to require NEON either. Working out whether this should be pushed upstream would require working out if there is any runtime checking for neon in QT which I (plugwash) don't have time for ATM. Building documentation on raspbian seems to hang, when updating package a source+all upload should be built on amd64 or similar. The buildds can then fill in the remaining binaries.
x264 Disable build of neon vairant neon variant sets of our v7 contamination checker which could possiblly obscure real problems. Not suitable for pushing upstream. May be dropped if our contamination checker gets smarter.
libvpx Disable build of neon vairant neon variant sets of our v7 contamination checker which could possiblly obscure real problems. Not suitable for pushing upstream. May be dropped if our contamination checker gets smarter.
python-apt disable testsuite testsuite seems to fail for us, most likely due to some characteristic of our repo (python-apt uses the apt data from the build system for it's testsuite) Local hack but it would be nice if we could convince upstream to ship test data rather than relying on data from the build system
strigi mark _ZNK15QBasicAtomicInteqEi@Base as optional the symbol did not appear in our builds Not sure if this is correct to push upstream.
guile-2.0 testsuite disabled testsuite failed on plugwash's build system and package was needed testsuite fails for debian as well, hopefully they will fix it at some point.
redhat-cluster apply patch to fix header locations build failed existing bug 669446 with patch present in in debian
glade-3 add missing libraries build failed patch submitted to existing bug 669485 in debian
gcc-mingw-w64 disable ada we don't currrently have gnat in raspbian local change which may or may not be dropped later
pyopenssl seperate build-arch and build-indep documentation build was silently failing (causing a file not found error later) on raspbian Bug 675414submitted to debian for build-arch/build-indep split. No idea on root cause of documentation build issue.
geos change build-depends and add build-conflicts to force build with ruby 1.8 package doesn't build with ruby 1.9 patch submitted to existing bug report 676094 in debian
perl change build-depends and debian/config.debian to build with gcc-4.7 gcc 4.6 failed to build package with ICE local change likely to be kept until debian makes 4.7 the default on armhf
plplot disable ada we don't currrently have gnat in raspbian local change which may or may not be dropped later
libmediainfo change build-depends and debian/config.debian to build with gcc-4.7 gcc 4.6 failed to build package with ICE local change likely to be kept until debian makes 4.7 the default on armhf
libpd-stats-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libdevice-cdio-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
rhash add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
frozen-bubble add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libasync-interrupt-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
gcc-4.7 change compiler defaults need to build binaries suitable for rpi permanent raspbian change, not suitable for pushing upstream
disable testsuite gcc testsuite takes ages and we don't have the resources to do anything about failures anyway, especially for a non-default compiler version local hack, may be dropped later (but probablly won't)
tcsh testsuite disabled testsuite failed and we needed to get update built to keep source and binary in sync local hack, hopefully we can drop later.
libfilter-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
nginx add build-depends on gcc-4.7 package was trying to build perl related code with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
exim4 add build-depends on gcc-4.7 package was trying to build perl related code with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libb-hooks-parser-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
pspp add build-depends on gcc-4.7 package was trying to build perl related code with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
disable testsuite testsuite failed and we don't have the resources to troubleshoot it local hack which hopefully can be dropped later
libvariable-magic-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libmath-tamuanova-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
pidgin add build-depends on gcc-4.7 package was trying to build perl related code with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
dietlibc tweak debian patches to support armv6 vfp package failed to build with assembler errors planning to file a bug report with patch but havent got arround to it yet
nkf add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
remctl add build-depends on gcc-4.7 package was trying to build perl related code with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libxml-xerces-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libtemplate-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libsys-cpu-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libsort-key-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libpadwalker-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf
libmoose-perl add build-depends on gcc-4.7 package was trying to build with 4.7 (likely because we built perl with it) local change likely to be kept until debian makes 4.7 the default on armhf