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 http://forums.debian.net/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!

[GarryRicketson]

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??

If you mean start a new topic in the development forum, Please don't
do that, this does not have anything to do with Debian development.

This is a hack:

You might find more interest and ideas on a "hackers" forum. But I have my doubts.
This forum is not about taking a basically reliable , stable ,fully functional OS and "hacking" it down,, chopping it up into pieces, mixing in all sorts of other
bits and pieces from other less reliable distros, essentially destroying it.
If you want to hack away at something, go out and chop some firewood a while,
basicly that is all you are doing.
To build something, a program, or even a OS, takes time and patience, as well as lots of study , research. Same, if one wants to build some cabinets, they have to learn to
be a carpenter. ,, You need to learn how to develop, and build, real programming,
not just "hacking" away at the "wood pile".
This is not to knock "hackers", every body starts some where, and for some that is
they way the learn, "hacking" making some changes, and see if it works, but unless they understand and accept the reason, WHY it does not work, so when they try again
they don't just do the same thing over again,I get the feeling this is waste of time, so
I am going to shut up. But please do not go starting another thread in the developers forum, this is not about development , it is about flat out self destruction.

[HadrianKross]

I posted here because improvements (even ease of use) for this and similar issues could help upstream.

Glad I and others are stubborn, otherwise Deb and Ian have no children.

Nothing about my system is broken.

I compiled alien from source last night--along with a number of new installs, not to mention new source(s)--without issue. A broken installer/package manager can do none of that..

Currently working on getting Unity3d and silverlight working natively (well pseudo natively in iceweasel):
http://pipelight.net/cms/install/instal ... ebian.html
A few winetricks as well, not to mention a hypervisor project; to name a few.

If I'd stayed stuck in package management I'd have accomplished none of that.

apt should make life easier; not more complicated. So far it, along with Aptitude and Synaptics, has been a time-saver... as far as linux goes, there's always source...as in open source, as in people helping people out--not flaming them for going off the arch.

The original question is rather complicated, given the nature of multiarch along with attempting to make it friendly for compilation of other archs/kernels/emulated hardware.

If upstream chooses to make the data file generic (if it is in fact generic), there's a reason. There's also a reason why it may or may not mesh with another arch. Simply assuming the manager is hosed doesn't show a lot of thought. I'm not assuming any issues upstream; just wondering why.

Thanks for the refresher about the multiarch wiki.

I currently see no reason to upgrade beyond what I have now; it's going along steadily, and I'm learning a lot as I go. I'm also learning that I'll probably be keeping a number of the wheezy packages for compatability's sake--along with several other distros. Package-->Keep/Hold in aptitude will probably come in very handy.

How about for the fresh debian install then?
a single wheezy stable source...which I've never seen btw.
The wiki I suppose??

--

FYI, I won't be doing a minimal debian install on a laptop. Maybe some sort of arm array; 20 bucks a pop is hard to beat. DSL and Puppy are debian based right??

--

edit:
as I expressed in the post--about it being a hack--if you read the rest of it, it's pretty clear I'm not in favor of that method.

edit:
https://wiki.debian.org/Multiarch links to https://wiki.ubuntu.com/MultiarchSpec for the "Main spec".

edit:

"Installing cross-dependencies
To install build-dependencies of a package before cross-building:
apt-get build-dep -a <arch> <package>"

this looks helpful, does it recompile or simply reorganize files??

edit:
from experience, everything is a development issue; whether it is even addressed is a matter of resources. deleting posts is probably a very bad idea in an open forum...

[kiyop]

(partially snip by kiyop)
cat /etc/apt/sources.list; ls /etc/apt/sources.list.d
deb http://ftp.de.debian.org/debian stable main contrib non-free
deb http://security.debian.org stable/updates main contrib non-free

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

deb http://ftp.de.debian.org/debian stable-updates main contrib non-free

deb http://debian-knoppix.alioth.debian.org ./

I am really curious if your mixed debian stable/testing/unstable/experimental and knoppix can survive or not.
I am looking forward to your solution.

[HadrianKross]

Problem is the damn thing keeps mutating...

Probably a parallel there to RL.

We'll see. I've got the live build on hand if not, but this one seems plausable.

the pipelight sources changed things a bit (not many packages to worry about); hopefully won't prove cancerous...

according to aptitude and iceweasel pipelight-multi:amd64 isn't working though, so trying i386.

should be more lively once I fully wrap my head around multi/64. planning for that to be increadibly anti-climactic.

There's a book that's the precursor to the film "Heavy Metal"; talks about mindpower and handpower (60's/70's I think). The ending, at least, seems applicable.

--

I'll probably stay with the new pipelight sources as well.
Inspired by Knoppix.

--

edit:
looks like adding a "deb-src" copy for each of my sources is necessary for multiarch; seems as though it will recompile them though--trying to avoid that...