I have a qemu-armhf chroot environment on an amd64 machine (it's mainly for compiling Raspberry Pi code). As such it can run both armhf and amd64 binaries but it's faster doing the latter. There are certain packages (such as make) where I've installed the amd64 version inside the chroot in order to get better speed. That works well up until I need to apt-get some other armhf package and it happens to have make listed as a dependency, whereupon I get this: The following packages have unmet dependencies: build-essential : Depends: make but it is not going to be installed dpkg-dev : Depends: make but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). If I try the suggested command, then it says it wants to install make:armhf and uninstall make:amd64. I don't want it to do that. How do I tell APT that make:armhf is already installed (because I want it to use make:amd64 to satisfy dependencies) without actually installing it? I've tried using apt-mark manual make but it says that it is not installed. ---- I know this probably isn't the right way to do it, but I've been looking at the /var/lib/dpkg/status file to try to work out how it thinks the package definitions work and to try to trick it into agreeing that make:amd64 satisfies make:armhf as well. In particular I noticed that "libbz2-1.0" is a package that's listed as installed twice; once as: Architecture: armhf Multi-Arch: same Pre-Depends: multiarch-support and once as: Architecture: amd64 Multi-Arch: foreign Pre-Depends: multiarch-support So I tried duplicating the entries for "make" similarly, setting all of those values above. But now APT's just saying that "make" and "make:amd64" are conflicted. Why is it a conflict when make does it but not when libbz2-1.0 does it? (I hope it's not special-casing libraries; that seems like it should be a bug.) ---- Per [this answer](https://unix.stackexchange.com/a/149799/78162) , I tried building a dummy package with equivs and installing that (after removing my manual fiddling above), but installing it produces these errors: # dpkg -i /var/cache/apt/archives/make_3.81-8.2_amd64.deb (real amd64 make) # dpkg -i make_3.81-8.2_armhf.deb (fake armhf depends on the above) Preparing to replace make 3.81-8.2 (using make_3.81-8.2_armhf.deb) ... Unpacking replacement make ... dpkg: dependency problems prevent configuration of make: make depends on make:amd64 (= 3.81-8.2). So again the problem looks like it thinks make:armhf is a *replacement* for make:amd64, and I don't know how to tell it that I want these two packages to coexist. (It doesn't seem to have a problem with the idea of two libbz2 packages coexisting, for example.)

I am trying to fetch some .debs that I can install in an airgapped machine (which is also a different architecture). My idea is to pass some configuration options to apt so that it will only look at the specified mirrors (and avoid messing up the system I'm running this on).

LLVM_GPG_PATH=/tmp/llvm.gpg
curl -fsSL "https://apt.llvm.org/llvm-snapshot.gpg.key " | gpg --dearmor -o ${LLVM_GPG_PATH}

DEBIAN_GPG_PATH=/tmp/debian.gpg
curl -fsSL "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x80d15823b7fd1561f9f7bcdddc30d7c23cbbabee " | gpg --dearmor -o ${DEBIAN_GPG_PATH}

cat > /tmp/sources.list << EOF
deb [signed-by=${DEBIAN_GPG_PATH}] http://deb.debian.org/debian  buster main
deb [signed-by=${LLVM_GPG_PATH}] http://apt.llvm.org/buster/  llvm-toolchain-buster-18 main
EOF

apt update --option "Dir::State=/tmp/apt/"\
           --option "Dir::Etc::sourcelist=${STAGING_DIRECTORY}/apt/sources.list"\
           --option "APT::Architecture=arm64"\
           --option "APT::Architectures=arm64"

# Eventually do something like this:
# apt install --option "Dir::Etc::sourcelist=/tmp/sources.list"\
#             --option "Dir::Cache=/tmp/cache/"
#             --option "Dir::Cache::archives=/tmp/archives/"
#             --download-only
#             libc++-18-dev:arm64

When I run something like this, the apt update step prints out updates from the repos I added but also many others.

Hit:1 http://deb.debian.org/debian  buster InRelease
Hit:2 https://apt.llvm.org/buster  llvm-toolchain-buster-18 InRelease                                                             
Get:3 http://security.ubuntu.com/ubuntu  noble-security InRelease [126 kB]                                  
Get:4 http://archive.ubuntu.com/ubuntu  noble InRelease [256 kB]
Ign:5 http://security.ubuntu.com/ubuntu  noble-security/main arm64 Packages
Ign:6 http://security.ubuntu.com/ubuntu  noble-security/multiverse arm64 Packages
Ign:7 http://security.ubuntu.com/ubuntu  noble-security/universe arm64 Packages
...

How can I stop that? (Side question, is there an easier way to do this?)

I'm trying to install [Stata 16](https://www.stata.com/) on Debian 12 "bookworm". Stata requires libpng12, and unfortunately, the libpng in the repositories (version 16) doesn't fulfill the dependency. I've downloaded the libpng12 deb package, but when I try to install it, I get this error message about multiarch support

dpkg: regarding libpng12-0_1.2.50-2+deb8u3_amd64.deb containing libpng12-0:amd64, pre-dependency problem:
 libpng12-0 pre-depends on multiarch-support
  multiarch-support is not installed.

dpkg: error processing archive libpng12-0_1.2.50-2+deb8u3_amd64.deb (--install):
 pre-dependency problem - not installing libpng12-0:amd64
Errors were encountered while processing:
 libpng12-0_1.2.50-2+deb8u3_amd64.deb

Both my OS and the package are 64-bit, so I'm not sure why multiarch-support is needed here. I ran dpkg --print-architecture and it says amd64. I thought the current version of dpkg [already had multiarch support](https://wiki.debian.org/Multiarch/HOWTO) . How do I get this package installed?

using docker command buildx build --platform=linux/arm64,linux/amd64 after latest updates may cause error: ERROR: multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. "docker buildx create --use")

I compiled a 32-bit executable for a Linux machine. It runs on most Linux distros without trouble. However, on Ubuntu 16.04 LTS, I get the No such file or directory error when trying to execute it. The executable is present in the directory and has all the relevant permissions set. There are a few answers detailing a solution to this (like here ). So, I did: 1. dpkg --print-architecture prints amd64. 2. dpkg --print-foreign-architectures prints i386. Even with multi-arch enabled by default, I am unable to get the executable to work. What else do I need to install/do in order to get this executable to work? P.S: The system does not have ia32-libs installed.

Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye I'd like to install libc6:i386 to support an old proprietary printer driver. I've performed the following: dpkg --add-architecture i386 apt update When I attempt to install libc6:i386 via apt install libc6:i386 I am presented with a message indicating that most of the existing packages, including essential packages will be removed. Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: [ seemingly all of the automatically installed packages on my system] Use 'apt autoremove' to remove them. The following additional packages will be installed: gcc-10-base:i386 libcrypt1:i386 libgcc-s1:i386 libidn2-0:i386 libunistring2:i386 Suggested packages: glibc-doc:i386 debconf:i386 | debconf-2.0:i386 locales:i386 Recommended packages: libnss-nis:i386 libnss-nisplus:i386 The following packages will be REMOVED: [ seemingly all of remaining packages, including X, etc ] The following NEW packages will be installed: gcc-10-base:i386 libc6:i386 libcrypt1:i386 libgcc-s1:i386 libidn2-0:i386 libunistring2:i386 WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! apt adduser (due to apt) gpgv (due to apt) libapt-pkg6.0 (due to apt) libc6 (due to apt) libgcc-s1 (due to apt) libgnutls30 (due to apt) libseccomp2 (due to apt) libstdc++6 (due to apt) libsystemd0 (due to apt) base-files base-passwd libdebconfclient0 (due to base-passwd) bash libtinfo6 (due to bash) debianutils (due to bash) bsdutils coreutils libacl1 (due to coreutils) libattr1 (due to coreutils) libgmp10 (due to coreutils) libselinux1 (due to coreutils) dash dpkg (due to dash) debconf (due to dash) diffutils libbz2-1.0 (due to dpkg) liblzma5 (due to dpkg) zlib1g (due to dpkg) tar (due to dpkg) e2fsprogs libblkid1 (due to e2fsprogs) libcom-err2 (due to e2fsprogs) libext2fs2 (due to e2fsprogs) libss2 (due to e2fsprogs) libuuid1 (due to e2fsprogs) logsave (due to e2fsprogs) findutils grep libpcre3 (due to grep) install-info (due to grep) gzip hostname init systemd-sysv (due to init) init-system-helpers (due to init) perl-base (due to init-system-helpers) libc-bin libcrypt1 login libaudit1 (due to login) libpam0g (due to login) libpam-runtime (due to login) libpam-modules (due to login) ncurses-bin sed sysvinit-utils util-linux libcap-ng0 (due to util-linux) libmount1 (due to util-linux) libsmartcols1 (due to util-linux) libudev1 (due to util-linux) 0 upgraded, 6 newly installed, 2746 to remove and 1 not upgraded. Need to get 3,579 kB of archives. After this operation, 13.7 GB disk space will be freed. You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' Here are my source repositories: deb http://deb.debian.org/debian/ bullseye main non-free contrib deb http://security.debian.org/debian-security bullseye-security main non-free contrib deb http://deb.debian.org/debian/ bullseye-updates main non-free contrib deb [arch=amd64] http://http.debian.net/debian bullseye-backports main non-free contrib deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main deb [arch=amd64] https://xpra.org/ bullseye main Any idea on what might be causing this? **EDIT 1:** The system is up-to-date prior to adding the architecture, e.g. # apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Directly after adding the new architecture and running apt update, an apt upgrade returns this: # apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages have been kept back: gnupg gnupg-l10n 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. which seems to indicate there's already an issue prior to attempting to install libc

What is the difference between the kernel architecture and the OS architecture? Which of these is relevant when trying to figure out which architecture to compile binaries for? From what I have read, it is possible to install a 64 bit kernel despite using a 32 bit OS in some distributions. What does uname -i print, the kernel architecture or the OS architecture? What about dpkg --print-architecture and arch?

I have a ARM virtual machine on AWS with Ubuntu18.04 installed. dpkg & uname commands show this, $ dpkg --print-architecture arm64 $ uname -m aarch64 I've got a third-party precompiled static library (.a) built for 32-bit. I understand that I cannot link 32-bit library to a 64-bit application, so I've created a new application which will link the library and get compiled for 32-bit. This application will communicate with rest of the applications (64-bit) using some IPC mechanism. To compile this application I've added following flag in my cmake file, set (CMAKE_CXX_FLAGS "-m32") but the compiler throw this error, c++: error: unrecognized command line option ‘-m32’ c++ version on my machine is, $ c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/7/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu Thread model: posix gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) It shows that it is prepared with configuration option ***--enable-multiarch*** which I suppose should allow me to compile for different architecture (32-bit ARM). On one of the other thread on stackoverflow says that some ARM64 machine's hardware may not support compilation of 32-bit applications. My question is how to check if my ARM64 machine is capable of building 32-bit application? And if it is capable of building then what is the alternative to ***-m32*** flag?

I'm trying to cross-build a Debian/Ubuntu package on a running amd64 system to mips arch. I've tried several methods, from pubilder to sbuild, but I keep failing. About the latter, on a freshly installed Debian 9 I do:

apt-get -y install sbuild
sbuild-createchroot --arch=mips --make-sbuild-tarball=/srv/chroots/wheezy-sbuild.tgz wheezy /srv/chroots/wheezy http://archive.debian.org/debian/ 

But in the end I get:

W: Failure trying to run: chroot /srv/chroots/wheezy dpkg-deb -f /var/cache/apt/archives/dpkg_1.16.18_mips.deb Version
W: See /srv/chroots/wheezy/debootstrap/debootstrap.log for details
W: Failure trying to run: chroot /srv/chroots/wheezy mount -t proc proc /proc
W: See /srv/chroots/wheezy/debootstrap/debootstrap.log for details
E: Error running debootstrap at /usr/sbin/sbuild-createchroot line 268.

and the log contains:

chroot: failed to run command 'dpkg-deb': Exec format error
chroot: failed to run command 'mount': Exec format error

All the methods I tried end up with that *Exec format error* while trying different commands.

With Raspbian and a 64-bit kernel, I am fetching packages from the following sources: deb [arch=armhf] http://raspbian.raspberrypi.org/raspbian/ stretch main contrib non-free rpi deb http://deb.debian.org/debian stretch main contrib non-free deb http://deb.debian.org/debian stretch-updates main contrib non-free Attempting to install the minimal dependencies to run something like gzip:arm64 reports conflicts such as: libgcc1 : Breaks: libgcc1:arm64 (!= 1:6.3.0-18+rpi1+deb9u1) but 1:6.3.0-18+deb9u1 is to be installed gcc-6-base:arm64 : Breaks: gcc-6-base (!= 6.3.0-18+deb9u1) but 6.3.0-18+rpi1+deb9u1 is to be installed It looks like the "+rpi1" *armhf* packages are conflicting with the non-rpi1 *arm64* packages. But that would mean that it's comparing package **versions** across two different architectures! Error messages with apt-get can be misleading anyhow, so to bring my system into a state similar to bamarni's Debian Pi64 (where multiarch works), I can try downloading some non-rpi1 armhf packages from links such as https://packages.debian.org/stretch/armhf/libgcc1/download Once I replace libgcc1:armhf, gcc-6-base:armhf, libc6:armhf, libatomic1:armhf and others, basic conflicts go away and I can install libgcc1:arm64 gcc-6-base:arm64 libc6:arm64 via apt. However, this isn't a great solution because in the process I have likely lost ARMv6 compatibility and other Raspbian-specific modifications. And the above could still mean there's something else fishy hiding in the Raspbian packages. My next test is to use the Raspbian *.deb files, except with a script I repackage them to remove the +rpi1 part of the version text in each control file. Once I do this and reinstall those packages, the conflicts with arm64 packages go away. This again indicates that APT is comparing package versions across two different architectures. When I run apt-cache show on any of these they all say Multi-Arch: same with their correct corresponding Architecture: lines. As I understand things, it would only care about versions across different architectures in the cases of Multi-Arch: foreign or Multi-Arch: allowed. What's going on here? It seems like APT is comparing package versions across different architectures when it shouldn't, which leads to bogus conflicts. I wonder if the fact that multiarch works okay on bamarni's Pi64 or Ubuntu MATE--or most i386+x86_64 systems--is in part luck that these systems have generally consistent package versions across 32-bit and 64-bit.

On Linux and Windows, I'm used to the situation that I require a 64-bit kernel to have a system with multiarch/WoW where I can run 32-bit and 64-bit software side-by-side. And then, years ago it blew my mind when someone showed me that MacOS 10.6 Snow Leopard could run 64-bit applications with the kernel in 32-bit mode. This may be largely forgotten now because it was a one-time technology transition. With the hardware ahead of the curve in the mobile space, as far as I know this was never needed in the move to 64-bit for iOS and Android. My question: What would it take to get the same capability in a 32-bit Linux kernel (i386 or armhf)? I understand that this probably isn't trivial. If it was, Microsoft could have put the feature into Windows XP 32-bit. What are the general requirements though? Has there ever been a proposed patch or proof-of-concept? In the embedded world I think this would be especially helpful, as 64-bit support can lag behind for a long time in device drivers.

I'm trying to set up a build environment for a software package in Debian Jessie. I need to produce amd64, i386 and eventually armel and armhf binaries of the software. It would be cool if I could cross-compile it to ALL of the architectures supported by Debian, which are a lot more than that, but those 4 are the ones I particularly care about. I started with amd64 Debian Jessie and added i386 multiarch. It all worked well until I had to install libpulse-dev, which is a dependency of the software. When installing it, I got >The following packages have unmet dependencies: libpulse-dev : Depends: libglib2.0-dev but it is not going to be installed with apt-get and >The following packages have unmet dependencies: libglib2.0-dev : Conflicts: libglib2.0-dev:i386 but 2.42.1-1 is installed. with aptitude. It looks like libglib2:amd64 and libglib2:i386 conflict — they can't be installed at the same time. Someone on #debian at Freenode told me that it's a well-known limitation of multiarch. I have to have that package installed in order to make i386 builds. I'm thinking of removing i386 multiarch, since it doesn't work, and setting up i386 chroot and building the i386 version of the software inside that chroot. That chroot solution should work for i386, but it doesn't work for when I will be producing binaries for armel, armhf, arm64, mips and all others architectures — I won't be able to make those builds in armel, armhf, arm64, mips, etc. chroots since I can't run arm and mips executables on my processor. How can I produce builds of the software that target amd64, i386, armel, armhf, arm64 and mips architectures on the same Debian Jessie system in a consistent manner (i.e. all builds are done the same way, not "builds for one architecture use chroot, but builds for other architectures use multiarch") without getting libglib2 conflicts like I do when using multiarch?

**Multilib and Multiarch:** Are these two term just synonym ? If no, how they differ ? If I want to run 32-bit and 64-bit application in same system then shall I call it *Multiarch or Multilib ?*

So it would be a single installation, sharing user data, config files, programs, etc., but I could take the boot drive and plug it into an x86 machine and it would boot and then later continue my work on an ARM machine and it would boot. This could be implemented, for example, by having multiple copies of every binary, each compiled for different architectures, connected by symlinks. Is this possible? Do any distros do this?

I have [multiarch](https://wiki.debian.org/Multiarch/HOWTO) enabled, and when I run [debtags search](https://wiki.debian.org/Debtags) , I get a lot of duplicate results. $ debtags search 'works-with-format::man' | head docbook-to-man - converter from DocBook SGML into roff man macros docbook-to-man:i386 - converter from DocBook SGML into roff man macros docbook-utils - Convert DocBook files to other formats (HTML, RTF, PS, man, PDF) docbook2x - Converts DocBook/XML documents into man pages and TeXinfo docbook2x:i386 - Converts DocBook/XML documents into man pages and TeXinfo doclifter - Convert troff to DocBook dwww - Read all on-line documentation with a WWW browser dwww:i386 - Read all on-line documentation with a WWW browser ebook-speaker - eBook reader that reads aloud in a synthetic voice ebook-speaker:i386 - eBook reader that reads aloud in a synthetic voice There's a workaround using grep: $ debtags search 'works-with-format::man' | grep -v ':i386 - ' | head docbook-to-man - converter from DocBook SGML into roff man macros docbook-utils - Convert DocBook files to other formats (HTML, RTF, PS, man, PDF) docbook2x - Converts DocBook/XML documents into man pages and TeXinfo doclifter - Convert troff to DocBook dwww - Read all on-line documentation with a WWW browser ebook-speaker - eBook reader that reads aloud in a synthetic voice git-man - fast, scalable, distributed revision control system (manual pages) gman - small man(1) front-end for X gmanedit - GTK+ man pages editor gnulib - GNU Portability Library This assumes the string :i386 - does not appear in any package description, which is a bit of a hack. Is there a better way?

I'm trying to compile multiarch project the right (means reproducible) way, so I decided to install all libraries through apt-get. But ever since the system noticed what I'm doing, it became hostile. While many people claim that you can install 32bit OpenSSL through this command: apt-get install libssl-dev:i386 I ended up with this result: E: Unable to locate package libssl-dev I did apt-get update and my OS version is Debian GNU/Linux 8 (*Jessie*). Am I doing something wrong? I tried to check what i386 libraries are actually available: XXXXX@debianvirtualbox:~$ aptitude search i386 p debian-installer-8-netboot-i386 - Debian-installer network boot images for i386 v debian-installer-netboot-i386 - p installation-guide-i386 - Debian installation guide for i386 p installation-guide-kfreebsd-i386 - Debian installation guide for kFreeBSD i386 i libc6-dev-i386 - GNU C Library: 32-bit development libraries for AMD64 i A libc6-i386 - GNU C Library: 32-bit shared libraries for AMD64 v qemu-system-i386 -

Edited output: # apt-get install librados2:amd64 librados2:i386 The following packages have unmet dependencies: librados2:amd64 : Conflicts: librados2 but 0.80.7-2+deb8u1 is to be installed librados2 : Conflicts: librados2:amd64 but 0.80.7-2+deb8u1 is to be installed E: Unable to correct problems, you have held broken packages. # apt-cache show librados2:amd64=0.80.7-2+deb8u1 librados2:i386=0.80.7-2+deb8u1 Package: librados2 Version: 0.80.7-2+deb8u1 Architecture: amd64 Replaces: libcrush, libcrush1, librados, librados1 Depends: libboost-system1.55.0, libboost-thread1.55.0, libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libnspr4 (>= 2:4.9-2~) | libnspr4-0d (>= 1.8.0.10), libnss3 (>= 2:3.13.4-2~) | libnss3-1d (>= 3.12.0~1.9b1), libstdc++6 (>= 4.9), libuuid1 (>= 2.16) Pre-Depends: multiarch-support Conflicts: libcrush, libcrush1, librados, librados1 Tag: role::shared-lib Section: libs Package: librados2 Version: 0.80.7-2+deb8u1 Architecture: i386 Replaces: libcrush, libcrush1, librados, librados1 Depends: libboost-system1.55.0, libboost-thread1.55.0, libc6 (>= 2.9), libgcc1 (>= 1:4.1.1), libnspr4 (>= 2:4.9-2~) | libnspr4-0d (>= 1.8.0.10), libnss3 (>= 2:3.13.4-2~) | libnss3-1d (>= 3.12.0~1.9b1), libstdc++6 (>= 4.9), libuuid1 (>= 2.16) Pre-Depends: multiarch-support Conflicts: libcrush, libcrush1, librados, librados1 Tag: role::shared-lib Section: libs Why Conflicts:? I don't see this library in conflict list displayed by apt-cache info (there is librados**1**, not librados**2**)... What prevents having librados2:i386 in /usr/lib/i386-linux-gnu/librados.so.2.0.0 and librados2:amd64 in /usr/lib/x86_64-linux-gnu/librados.so.2.0.0?

I have this kind of system: :~$ dpkg --print-architecture amd64 :~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty When I try to sudo dpkg --add-architecture armhf sudo apt-get update I get the error messages W: Fehlschlag beim Holen von http://security.ubuntu.com/ubuntu/dists/trusty-security/main/binary-armhf/Packages 404 Not Found [IP: 2001:67c:1560:8001::14 80] W: Fehlschlag beim Holen von http://security.ubuntu.com/ubuntu/dists/trusty-security/restricted/binary-armhf/Packages 404 Not Found [IP: 2001:67c:1560:8001::14 80] W: Fehlschlag beim Holen von http://security.ubuntu.com/ubuntu/dists/trusty-security/universe/binary-armhf/Packages 404 Not Found [IP: 2001:67c:1560:8001::14 80] W: Fehlschlag beim Holen von http://security.ubuntu.com/ubuntu/dists/trusty-security/multiverse/binary-armhf/Packages 404 Not Found [IP: 2001:67c:1560:8001::14 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-updates/restricted/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-updates/universe/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-updates/multiverse/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://extras.ubuntu.com/ubuntu/dists/trusty/main/binary-armhf/Packages 404 Not Found [IP: 2001:67c:1360:8c01::23 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-backports/main/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-backports/restricted/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-backports/universe/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-backports/multiverse/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty/main/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty/restricted/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty/universe/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/trusty/multiverse/binary-armhf/Packages 404 Not Found [IP: 141.76.1.204 80] What can I do to add the armhf stuff?

I'm using apt-rdepends on an _amd64_ system with _i386_ as a foreign architecture. But it seems that apt-rdepends loses the architecture information of packages: $ apt-rdepends libgcc1:i386 Reading package lists... Done Building dependency tree Reading state information... Done libgcc1:i386 Depends: gcc-4.9-base (= 4.9-20140406-0ubuntu1) Depends: libc6 (>= 2.2.4) PreDepends: multiarch-support gcc-4.9-base libc6 Depends: libgcc1 libgcc1 Depends: gcc-4.9-base (= 4.9-20140406-0ubuntu1) Depends: libc6 (>= 2.14) PreDepends: multiarch-support multiarch-support Depends: libc6 (>= 2.3.6-2) While apt-cache shows the correct architecture but can't recurse: $ apt-cache depends libgcc1:i386 libgcc1:i386 Depends: gcc-4.9-base:i386 Depends: libc6:i386 PreDepends: multiarch-support:i386 multiarch-support Breaks: Breaks: Breaks: gcc-4.4 Breaks: gcc-4.4:i386 Breaks: Breaks: Replaces: libgcc1 Breaks: libgcc1 Any suggestions on how to recursively retrieve dependencies without losing architecture information?

Can the apt-get command be configured to ignore some of the packages it wants to remove. I run both 32 bit and 64 bit development packages as well as the programs created on them, meaning I need both the xxx:i386 and their 64 bit counterparts on the system.In this system for example I need to install a 64bit development package on all the related 32bit development packages are marked for removal. root@ac02:/usr/src/packages/lazarus# apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages were automatically installed and are no longer required: gir1.2-freedesktop:i386 gir1.2-glib-2.0:i386 gir1.2-pango-1.0:i386 libcairo-gobject2:i386 libcairo-script-interpreter2:i386 libexpat1-dev:i386 libgirepository-1.0-1:i386 libharfbuzz-gobject0:i386 libharfbuzz-icu0:i386 libice-dev:i386 liblzo2-2:i386 libpcre3-dev:i386 libpcrecpp0:i386 libpng12-dev:i386 libpthread-stubs0-dev:i386 libsm-dev:i386 libx11-dev:i386 libxau-dev:i386 libxcb-render0-dev:i386 libxcb-shm0-dev:i386 libxcb1-dev:i386 libxcursor-dev:i386 libxdamage-dev:i386 libxdmcp-dev:i386 libxext-dev:i386 libxfixes-dev:i386 libxinerama-dev:i386 libxrandr-dev:i386 libxrender-dev:i386 zlib1g-dev:i386 Use 'apt-get autoremove' to remove them. The following extra packages will be installed: gir1.2-atk-1.0 gir1.2-gdkpixbuf-2.0 gir1.2-gtk-2.0 libatk1.0-dev libcairo-script-interpreter2 libcairo2-dev libexpat1-dev libfontconfig1-dev libfreetype6-dev libgdk-pixbuf2.0-dev libglib2.0-dev libgtk2.0-dev libharfbuzz-dev libharfbuzz-gobject0 libice-dev libpango1.0-dev libpcre3-dev libpcrecpp0 libpixman-1-dev libpng12-dev libpthread-stubs0-dev libsm-dev libx11-dev libxau-dev libxcb-render0-dev libxcb-shm0-dev libxcb1-dev libxcomposite-dev libxcursor-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxft-dev libxi-dev libxinerama-dev libxrandr-dev libxrender-dev Suggested packages: libcairo2-doc libglib2.0-doc libgtk2.0-doc libice-doc libpango1.0-doc libsm-doc libxcb-doc libxext-doc The following packages will be REMOVED: gir1.2-atk-1.0:i386 gir1.2-gdkpixbuf-2.0:i386 gir1.2-gtk-2.0:i386 libatk1.0-dev:i386 libcairo2-dev:i386 libfontconfig1-dev:i386 libfreetype6-dev:i386 libgdk-pixbuf2.0-dev:i386 libglib2.0-dev:i386 libgtk2.0-dev:i386 libharfbuzz-dev:i386 libpango1.0-dev:i386 libpixman-1-dev:i386 libxcomposite-dev:i386 libxft-dev:i386 libxi-dev:i386 The following NEW packages will be installed: gir1.2-atk-1.0 gir1.2-gdkpixbuf-2.0 gir1.2-gtk-2.0 libatk1.0-dev libcairo-script-interpreter2 libcairo2-dev libexpat1-dev libfontconfig1-dev libfreetype6-dev libgdk-pixbuf2.0-dev libglib2.0-dev libgtk2.0-dev libharfbuzz-dev libharfbuzz-gobject0 libice-dev libpango1.0-dev libpcre3-dev libpcrecpp0 libpixman-1-dev libpng12-dev libpthread-stubs0-dev libsm-dev libx11-dev libxau-dev libxcb-render0-dev libxcb-shm0-dev libxcb1-dev libxcomposite-dev libxcursor-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxft-dev libxi-dev libxinerama-dev libxrandr-dev libxrender-dev 0 upgraded, 38 newly installed, 16 to remove and 33 not upgraded. 1 not fully installed or removed. Need to get 14.0 MB of archives. After this operation, 13.4 MB of additional disk space will be used. Do you want to continue? [Y/n] When a package is marked for removal, does that mean that apt-get thinks it conflicts with other packages? This I find rather unexpected as most development systems search for 32bit development packages separately form 64 bit packages.