Multiarch, apt-get, amd64, all.

[HadrianKross]

This is a hack:

:apt-get source package
cd package-version
dpkg-buildpackage -us -uc -rfakeroot

This is prohibitive in terms of development...

So is a "force" option.

Are there any config solutions for say alien-arena:amd64 showing alien-arena-data (all) as incompatible??
(assuming it is compatible...)

Have had similar issues with other amd64 installs using generic dependencies, not to mention dependency issues with other non-tagged (amd64 compatible?) packages.

Anyone else have this or similar issues?

Any non-hackish solutions?

(also the i386 alien install simply returns "Killed" on an x86-64 system)

--

Hoping I'm way off and there's a simple config fix to make x86 and x86-64 play nice together--esp. for development (e.g. elf 32/elf 64, x_x)

--

Is it the tagging and apt-get being too strict (not that it would know to begin with, without being told--supercow powers and all) or are they simply incompatible and need to be recompiled? Not looking forward to recompiling 500mb of graphic/game data... Esp. if I don't need to. Is it a similar issue of debian unwilling to store the excess/identical tagged data when the generic package is equally compatible. What happened to dummy packages? Too much of a crutch? Could suffice for the interim...

[stevepusser]

Where is the -data package coming from? Are you running Jessie (stable) without adding outside repositories?

Don't you think that giving us the exact error messages that come back from the attempted install would possibly be helpful?

[HadrianKross]

It's a system configuration help question.

How do I get Debian to play nice in multiarch systems. Specifically the package manager apt-get.

Best configs, tweaks, tips, etc.

For example, alien-arena-data is a jessie package that I see no amd64 counterpart...

No error, just compatability issues.

Another example was elf during multiarch compilation--not the focus of the question, nor a package manager issue.

If a simple sources update is in order that would be great!

[stevepusser]

A -data package with the "all" architecture has the architecture-independent files in it, such as graphics, scripts, xml files, and so on, so it is compatible with every platform. No arch-specific packages are needed. You then only need install the binary packages for your architecture, alien-arena amd64 version. No multiarch is needed.

Are there any config solutions for say alien-arena:amd64 showing alien-arena-data (all) as incompatible??
(assuming it is compatible...)

This should not happen on an updated system. Again, the exact error message would provide the solution!

Code: Select all

apt-get update && apt-get install alien-arena

[HadrianKross]

From Synaptics:

alien-arena:amd64:
Depends: libcurl3-gnutls but it is not going to be installed
Depends: libogg0 but it is not going to be installed
Depends: libvorbis0a but it is not going to be installed
Depends: libvorbisfile3 but it is not going to be installed
Depends: libxxf86vm1 but it is not going to be installed
Depends: libopenal1 but it is not going to be installed
Depends: alien-arena-data but it is not installable

From apt-get:

# apt-get install alien-arena:amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
alien-arena:amd64 : Depends: libcurl3-gnutls:amd64 (>= 7.16.2) but it is not going to be installed
Depends: alien-arena-data:amd64 but it is not installable
E: Unable to correct problems, you have held broken packages.

??????
"but it is not going to be installed"

Am I missing an amd64/x86-64 repo??
If I attempt them individually they install but the amd64 dependencies never seem to auto-install.
Did I miss a config for amd64 dependencies??

Also,
apt-get install multiarch-support
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
multiarch-support:amd64
The following NEW packages will be installed:
multiarch-support
0 upgraded, 1 newly installed, 1 to remove and 2443 not upgraded.
Need to get 0 B/179 kB of archives.
After this operation, 24.6 kB disk space will be freed.
Do you want to continue? [Y/n]

apt-get install multiarch-support:amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
multiarch-support
The following NEW packages will be installed:
multiarch-support:amd64
0 upgraded, 1 newly installed, 1 to remove and 2443 not upgraded.
Need to get 0 B/179 kB of archives.
After this operation, 24.6 kB of additional disk space will be used.
Do you want to continue? [Y/n]

multiarch-support and multiarch-support:amd64 don't seem to like each other and all these packages are getting caught in the conflict:

libavahi-core7:i386 depends on multiarch-support.
libxcb-xkb1:i386 depends on multiarch-support.
python-ldb depends on multiarch-support.
libdbusmenu-qt2:i386 depends on multiarch-support.
python-talloc depends on multiarch-support.
libjpeg8:i386 depends on multiarch-support.
libvpx1:i386 depends on multiarch-support.
libwayland-server0:i386 depends on multiarch-support.
libpcap0.8:i386 depends on multiarch-support.
libmediastreamer1:i386 depends on multiarch-support.
libcheese7:i386 depends on multiarch-support.
libqtwebkit4:i386 depends on multiarch-support.
libegl1-mesa:i386 depends on multiarch-support.
libqt4-scripttools:i386 depends on multiarch-support.
libwxbase3.0-0:i386 depends on multiarch-support.
libsmartcols1:i386 depends on multiarch-support.
libcups2:amd64 depends on multiarch-support.
libcups2:i386 depends on multiarch-support.
libglew1.7:i386 depends on multiarch-support.
libdvdread4 depends on...
...
libavahi-core7:i386 depends on multiarch-support.
libxcb-xkb1:i386 depends on multiarch-support.
python-ldb depends on multiarch-support.
libdbusmenu-qt2:i386 depends on multiarch-support.
python-talloc depends on multiarch-support.
libjpeg8:i386 depends on multiarch-support.
libvpx1:i386 depends on multiarch-support.
libwayland-server0:i386 depends on multiarch-support.
libpcap0.8:i386 depends on multiarch-support.
libmediastreamer1:i386 depends on multiarch-support.
libcheese7:i386 depends on multiarch-support.
libqtwebkit4:i386 depends on multiarch-support.
libegl1-mesa:i386 depends on multiarch-support.
libqt4-scripttools:i386 depends on multiarch-support.
libwxbase3.0-0:i386 depends on multiarch-support.
libsmartcols1:i386 depends on multiarch-support.
libcups2:amd64 depends on multiarch-support.
libcups2:i386 depends on multiarch-support.
libglew1.7:i386 depends on multiarch-support.
libdvdread4 depends on...

Also:
alien-arena (32bit) simply ends in "Killed" on my system (multiarch booting a 64bit kernel)...

"Oh the humanity!"

Crosscompatability currently has too much carnage for me; I mean even the multiarch support files won't exist on the same system at the same time--maybe I should just pick one or the other??

[fireExit]

0 upgraded, 1 newly installed, 1 to remove and 2443 not upgraded.

what exactly are you trying to do? about 2500 packages not upgraded?!
can you post the output of

Code: Select all

cat /etc/apt/sources.list; ls /etc/apt/sources.list.d; lsb_release -a

[HadrianKross]

cat /etc/apt/sources.list; ls /etc/apt/sources.list.d
# Debian/Squeeze is the stable base for this installation
deb http://ftp.de.debian.org/debian stable main contrib non-free
deb http://security.debian.org stable/updates main contrib non-free

# testing/unstable/experimental contain newer versions, but
# packages from there are not being installed by default, unless
# they came from there in the first place.
deb http://ftp.de.debian.org/debian testing main contrib non-free
deb http://security.debian.org testing/updates main contrib non-free
deb http://ftp.de.debian.org/debian unstable main contrib non-free
deb http://ftp.de.debian.org/debian experimental main contrib non-free

# Debian/volatile contains quickly changing data like spam- and virusfilter databases
# Does not exist anymore
# deb http://volatile.debian.org/debian-volatile stable/volatile main contrib non-free
deb http://ftp.de.debian.org/debian stable-updates main contrib non-free

# Knoppix repository
deb http://debian-knoppix.alioth.debian.org ./

# x2go
# deb http://x2go.obviously-nice.de/deb/ lenny main
#deb http://packages.x2go.org/debian squeeze main
#deb http://packages.x2go.org/debian wheezy main
#deb http://packages.x2go.org/debian sid main

# Debian Multimedia, contains non-free software like acrobat reader
# deb http://www.deb-multimedia.org squeeze main non-free

# eviacam
# deb http://ppa.launchpad.net/cesar-crea-si/eviacam/ubuntu trusty main
# deb-src http://ppa.launchpad.net/cesar-crea-si/eviacam/ubuntu trusty main

upgrading as needed so far from a Knoppix hd build. if it's multi why upgrade everything??

edit: a case for oldversions and refusing to upgrade indiscriminately: geo.wifi.uri
(not to mention keeping the version you like when updating/upgrading gives minimal improvement; when did debian turn into windo$e?? oh wait--that would be when they let google begin to do the work for them; or is that vice-versa?)

Technically wheezy:
Distributor ID: Debian
Description: Debian GNU/Linux 7.6 (wheezy)
Release: 7.6
Codename: wheezy

most of the packages are jessie though

[fireExit]

just one link for you viewtopic.php?f=20&t=114130 and i'm out of here.
good luck! (you gonna need it)

[HadrianKross]

Not even close.
That post is more to make fun of people than to provide real solutions, hence no offer of a solution at all...or even any real tips.

My system is fully functional.

When I started updating it was from wheezy to jessie, nothing else but non dependency single package applications, that might be off stable...
Easy enough to identify.

I'm simply in the middle of an upgrade from wheezy to jessie.

My main question/concern is multiarch related non-64 --> 64.

Please keep the comments to the topic.

--

Preferably those package experts with the wherewithall to answer them fully--or at least provide some constructive input. I.e. Knoppix, etc.

[stevepusser]

The first stage: Denial

Listen, we are not making fun of you, but there are literally thousands of threads with your type of situation here, and they follow a predictable sequence. Experts can handle a mixed system with careful apt-pinning; could you show us what pinning you did?

[HadrianKross]

So, again, the original multiarch question?

Should I define it more clearly?

I haven't made any changes to the sources...yet.

This isn't some obscure package causing problems, it's about x86 and x86-64 cross-compaibility within a given stable release...

[stevepusser]

Sorry, that's not the issue. I'm out of here, too, in that case.

[HadrianKross]

So viewers should refer to their given derivative distros for questions outside the arch??

--

Perhaps I should rephrase, as I do have other machines, distros, builds, and perhaps even custom images in mind.

On a brand new, stable debian hd install--wheezy to keep it simple--how should one enable multiarch support (lets keep it to just x86 and x86-64 for now)?

Also, how should the package manager, especially apt-get, behave concerning one or the other.

Preferably those that develop on said systems; furthermore, tips for help with arm/arm64 on the same system.

Should I move this to a development thread considering??

--

I suppose I'll leave you rather interesting debian folks with this question:

Would Deb and Ian ever have had so many children if the originators of those distros been so hesitant to venture out of a single release, or tweak a package for that matter? Don't stifle your own innovation for the sake of stasis...or a supposed "ease of use".

--

edit:
Alien Arena on deb based x86-64 system:

http://forumubuntusoftware.info/viewtop ... =68&t=5045

will compare to i386 package install soon...

[HadrianKross]

.

[thanatos_incarnate]

For someone spouting big words about innovation and exploration, you sure fail at such small adventures as googling how to enable multiarch support. BIG FAIL!
https://wiki.debian.org/Multiarch

A little spoon feeding:
Installing e.g. 32 bit package named foo on a multiarch enabled system:

Code: Select all

apt-get install foo:i386

Not even close. That post is more to make fun of people than to provide real solutions

Exactly! It's there to make fun of people like you, who are stubborn and won't listen or even provide error/config file outputs after the umpteenth query to do so by other users. Maybe the shame of being made fun of will make you people

1. read the forum guidelines (because had you done so, you'd know that support here can only be given to a clean Debian system)
2. read Debian documentation and search the forums for previously discussed topics
3. get it into your skulls that Mint, Ubuntu and even Knoppix are not official Debian. Repeat after me: They are not official Debian! They have their own forums.
4. realise that even Debian with bits of PPA or outside packages which install into the core directory structure in /usr (not /usr/local or /opt -- e.g. I'll let Google Chrome or similar packages which cleanly install into /opt and don't touch core system packages slide) are not official Debian.
5. see that Debian Stable is the only officially supported Debian (well, with oldstable for a while and the LTS stuff). You might get lucky and have people on the forums who happen to run Testing or Sid/Experimental with a similar problem like you, but that's just luck.
6. find out that Debian, and especially Debian Stable, are not exactly hot test beds for new GNU/Linux technology. Want something like that? Arch, Fedora,... Take a pick!