Hello, All.
I read that Debian Testing/Unstable and Ubuntu 11.10 support multiarch.
As I read, in order to get multiarch in Ubuntu, I need write
foreign-architecture i386 to /etc/dpkg/dpkg.cfg
But it does not work in Debian Testing for now. After it dpkg prints
this message:
dpkg: error
Hello, All.
I read that Debian Testing/Unstable and Ubuntu 11.10 support multiarch.
As I read, in order to get multiarch in Ubuntu, I need write
foreign-architecture i386 to /etc/dpkg/dpkg.cfg
But it does not work in Debian Testing for now. After it dpkg prints
this message:
dpkg: error
On Sat, Dec 24, 2011 at 04:54:53PM +0200, Роман Франчук wrote:
Is it possible to get multiarch on debian testing? What can I do in
order to get it?
You need a version of dpkg which is not in the archive yet. You'll have
to build a version from git from the pu/multiarch branch. Be aware
24.12.2011 18:21, brian m. carlson пишет:
You need a version of dpkg which is not in the archive yet. You'll have
to build a version from git from the pu/multiarch branch. Be aware that
while some of the infrastructure works just fine, some software (e.g.
aptitude) is buggy.
What troubles
24.12.2011 18:21, brian m. carlson пишет:
On Sat, Dec 24, 2011 at 04:54:53PM +0200, Роман Франчук wrote:
Is it possible to get multiarch on debian testing? What can I do in
order to get it?
You need a version of dpkg which is not in the archive yet. You'll have
to build a version from git
I just noticed that the latest libc6 updates brought us some brand
new directories such as /etc/ld.so.conf.d/, /lib/ldconfig/... Does this mean
that, unannounced, real multiarch support the Debian way (or a first step
towards this) is entering unstable? Where can some documentation
Giacomo Mulas [EMAIL PROTECTED] writes:
I just noticed that the latest libc6 updates brought us some brand
new directories such as /etc/ld.so.conf.d/, /lib/ldconfig/... Does this mean
Been there for a while, at least /lib/ldconfig/
that, unannounced, real multiarch support the Debian
Alexander Samad [EMAIL PROTECTED] writes:
Hi
sorry if this email is a bit off topic, but still enough to ask I think.
What is the status of multiarch and debian (specifically amd64 port).
I like lots of other users have migrated to amd64, I am finding it a
bit of a pain to get some
Hi,
I've been working on wrappers for apt and dpkg-deb to get some
resemblance of multiarch that can still make it for etch. The first
thing I made to work is installing amd64 kernels on i386 and anyone
interested is welcome to try a very alpha release:
ftp://mrvn.homeip.net/apt-get-multiarch
On Tue, Apr 25, 2006 at 07:02:35PM +0200, Goswin von Brederlow wrote:
Hi,
I've been working on wrappers for apt and dpkg-deb to get some
resemblance of multiarch that can still make it for etch. The first
thing I made to work is installing amd64 kernels on i386 and anyone
Either you've made
[EMAIL PROTECTED] wrote:
On Tue, Apr 25, 2006 at 07:02:35PM +0200, Goswin von Brederlow wrote:
Hi,
I've been working on wrappers for apt and dpkg-deb to get some
resemblance of multiarch that can still make it for etch. The first
thing I made to work is installing amd64 kernels on i386
On Wed, Apr 26, 2006 at 01:01:57AM +0100, Jo Shields wrote:
[EMAIL PROTECTED] wrote:
On Tue, Apr 25, 2006 at 07:02:35PM +0200, Goswin von Brederlow wrote:
Hi,
I've been working on wrappers for apt and dpkg-deb to get some
resemblance of multiarch that can still make it for etch
[EMAIL PROTECTED] writes:
On Wed, Apr 26, 2006 at 01:01:57AM +0100, Jo Shields wrote:
[EMAIL PROTECTED] wrote:
On Tue, Apr 25, 2006 at 07:02:35PM +0200, Goswin von Brederlow wrote:
Hi,
I've been working on wrappers for apt and dpkg-deb to get some
resemblance of multiarch that can
[EMAIL PROTECTED] (Lennart Sorensen) writes:
On Wed, Dec 14, 2005 at 11:17:30AM +0100, Mario Lang wrote:
So I guess the final answer is either we figure out
a preprocessor based patch which makes the necessary
adjustments for 64bit archs, and leaves the code basically
the same for 32bit
Anthony DeRobertis [EMAIL PROTECTED] writes:
Mario Lang wrote:
In this specific case, that is a very hypothetical thesis... I cant really
imagine an arch which does say 80bit or 128bit floating point math
faster than 64bit...
M68K comes to mind, I think that might do 80bit FP faster than
Mario Lang wrote:
Yes, thanks for the nice demonstration, so memcpy
is not really the problem, however, changing the amount of bits
used for a single slot is going to be... QUoting the author,
going to more than 64bit would be a loss of performance, going
to less than 64bit would be a loss of
Mario Lang wrote:
[EMAIL PROTECTED] (Lennart Sorensen) writes:
On Tue, Dec 13, 2005 at 01:53:04PM +0100, Mario Lang wrote:
SuperCollider is for some reason I am going to explain below a bit
strange when it comes to porting it to AMD64:
SC consists of two separate programs, the
On Wed, Dec 14, 2005 at 11:17:30AM +0100, Mario Lang wrote:
Yes, thanks for the nice demonstration, so memcpy
is not really the problem, however, changing the amount of bits
used for a single slot is going to be... QUoting the author,
going to more than 64bit would be a loss of performance,
On Wed, Dec 14, 2005 at 08:36:08AM -0200, Eduardo M KALINOWSKI wrote:
I'd strongly advise the author to avoid such hacks and write proper
portable code. Unless he wants his package to be another OpenOffice.org.
It already is another openoffice.org, just not quite as big. :)
Len Sorensen
--
supercollider?
I am not up-to-date with how multiarch is exactly ment to work
these days, would it fit this kind of application?
If so, whats the proper way to do it, and can this already be done
with the infrastructure currently in amd64 sid?
--
CYa,
Mario
--
To UNSUBSCRIBE, email to [EMAIL
, and build the language client in a sid-ia32
chroot, do the ld.so.conf magic and symlink sclang. That works
nicely.
However, I am kind of wondering how to solve this properly
when it comes to packaging supercollider?
I am not up-to-date with how multiarch is exactly ment to work
these days, would
of wondering how to solve this properly
when it comes to packaging supercollider?
I am not up-to-date with how multiarch is exactly ment to work
these days, would it fit this kind of application?
If so, whats the proper way to do it, and can this already be done
with the infrastructure
Mario Lang wrote:
In this specific case, that is a very hypothetical thesis... I cant really
imagine an arch which does say 80bit or 128bit floating point math
faster than 64bit...
M68K comes to mind, I think that might do 80bit FP faster than it does
64-bit (because the FPU does 80-bit).
Matthew A. Nicholson [EMAIL PROTECTED] writes:
Are there any new updates on multiarch or is it still just a purposal?
I say we organize a team to get multiarch working and stop sitting on
our hands.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble
Are there any new updates on multiarch or is it still just a purposal?
I say we organize a team to get multiarch working and stop sitting on
our hands.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Fri, Jul 08, 2005 at 08:23:10PM +0200, Goswin von Brederlow wrote:
$ apt-cache show liferea-mozilla
[...]
Depends: liferea (= 0.9.1-1), mozilla-browser, [...]
Gabor
Does that dlopen mozilla?
Looking at the /proc/.../maps file it does.
Gabor
--
On Thu, Jul 07, 2005 at 05:32:45PM +0200, Thomas Steffen wrote:
I wouldn't call that just fine. Setting the environment variables
means that you break any 64bit process that Openoffice might want to
spawn, which is a certain way to get really strange bugs. I bet that
printing using kprinter
[EMAIL PROTECTED] (Bob Proulx) writes:
Thomas Steffen wrote:
The better way to do it is to have three (sub)packages: i386, x86_64
and shared. That is a bit like -common and -bin, but the packages
differ only in architecture, not in the name. Imho that is the way to
go.
However, if you
Stephen Frost [EMAIL PROTECTED] writes:
* Bob Proulx ([EMAIL PROTECTED]) wrote:
Goswin von Brederlow wrote:
Hugo Mills [EMAIL PROTECTED] writes:
How? You can't install your two multiarch versions of libvorbis
without a hacked package manager that understands how to do it.
You
[EMAIL PROTECTED] (Lennart Sorensen) writes:
If we could ignore rpath problems, then moving everything to an arch dir
under each lib dir would take care of the libs since the ld loader can
handle the new locations. Building software may or may not work since
configure scripts might get
are the blockers for a
package maintainer who wants to get started with multiarch? It sounds like
just some symlinks in base packages are all that need to change...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
archs, we are only saying we won't make this a policy. It is
left to each package maintainer to decide if he wants to make the
multiarch change for his binary too or not and nearly every one will
not.
All right, this is a solution I can live with. Until now I thought,
that it would
GOMBAS Gabor [EMAIL PROTECTED] writes:
On Wed, Jul 06, 2005 at 02:33:39AM +0200, Goswin von Brederlow wrote:
Configure scripts have sometimes hardcoded paths to /usr/lib.
And /usr/include. Don't forget that some packages install
architecture-specific header files under /usr/include.
in dependency trees.
This is one thing that is unsaid or unclear in the multiarch
proposal. Packages can have one of 3 types:
1. Multi-arch: yes
This is a library package. Any number of architectures of this
package can be installed at the same time and packages depending on
it require the same
back to my original question: what are the blockers
for a package maintainer who wants to get started with multiarch? It
sounds like just some symlinks in base packages are all that need to
change...
and I repeat my answere: gcc, binutils, libtools, automake,
autoconf. Toolchain issues.
By all
true. In Tollef's multiarch proposal, files
in /usr/share/doc/package can indeed overlap between packages with
precisely the same name differing only in architecture. My preliminary
patches to dpkg supported that behaviour.
Wouldn't be better have /usr/share/doc/package/arch-os/ directories
On 7/8/05, Miroslav Maiksnar [EMAIL PROTECTED] wrote:
Wouldn't be better have /usr/share/doc/package/arch-os/ directories? No
files will be overlapping and all libs will have it's own copyright and
README files (which may differ between different arch-os combinations).
No, I don't think so.
between
archs.
That's not _entirely_ true. In Tollef's multiarch proposal, files
in /usr/share/doc/package can indeed overlap between packages with
precisely the same name differing only in architecture. My preliminary
patches to dpkg supported that behaviour.
Wouldn't be better have
On Thu, Jul 07, 2005 at 04:10:46AM +0200, Goswin von Brederlow wrote:
That why you read Toleffs proposal for multiarch for debian fo details.
You name packages lib32foo and lib64foo or something non
conflicting. Or you use the multiarch patch for dpkg.
How about mips? They have 3
On Tue, Jul 05, 2005 at 05:26:46PM +0200, Thomas Steffen wrote:
No, for all practical purposes you do not have that. I could not get a
single third part binary to work without a chroot. And recommending a
chroot is just a different way of saying that it is not supported.
Well, Vmware runs
Thomas Steffen wrote:
The better way to do it is to have three (sub)packages: i386, x86_64
and shared. That is a bit like -common and -bin, but the packages
differ only in architecture, not in the name. Imho that is the way to
go.
However, if you look closer, you find that both approaches
.
depends upon 'libm.so.6()(64bit)' fine.
Now that '(64bit)' is something they had to add for biarch support.
I believe that is the only addition for biarch support. I can't see
anything else different from the outside of the box.
There was talk about doing the same for multiarch early
Goswin von Brederlow wrote:
Hugo Mills [EMAIL PROTECTED] writes:
How? You can't install your two multiarch versions of libvorbis
without a hacked package manager that understands how to do it.
You name packages lib32foo and lib64foo or something non
conflicting. Or you use
* Bob Proulx ([EMAIL PROTECTED]) wrote:
Goswin von Brederlow wrote:
Hugo Mills [EMAIL PROTECTED] writes:
How? You can't install your two multiarch versions of libvorbis
without a hacked package manager that understands how to do it.
You name packages lib32foo and lib64foo
On Thu, 7 Jul 2005, Bob Proulx wrote:
I really don't like needing to change the package names to be uniquely
named. I think for multiarch to really work in Debian then dpkg needs
to have a split brain where the architecture specific packages are
tracked separately.
I think he just means
On 7/7/05, GOMBAS Gabor [EMAIL PROTECTED] wrote:
Well, Vmware runs just fine without any kind of chroot.
Yes, I did get the test version of VMware running, but it was not
without issues.
OOo also runs
fine if you just _install_ it in a chroot but call it from the outside
(well, you need to
On Wed, Jul 06, 2005 at 02:33:39AM +0200, Goswin von Brederlow wrote:
Configure scripts have sometimes hardcoded paths to /usr/lib.
And /usr/include. Don't forget that some packages install
architecture-specific header files under /usr/include.
Libtool adds rpath if libraries are not in
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote:
Also programs don't depend on something like galeon (i hope).
$ apt-cache show liferea-mozilla
[...]
Depends: liferea (= 0.9.1-1), mozilla-browser, [...]
Gabor
--
Goswin von Brederlow wrote:
Adam Stiles writes:
Most current 64 bit Linux distributions are not pure 64-bit but
contain both 32 and 64 bit libraries. In other words, they are
multi-arch.
Not multiarch but biarch. Not quite the same thing.
No. They have ia32-libs preinstalled.
Multi
On 7/6/05, Bob Proulx [EMAIL PROTECTED] wrote:
[RedHat x86_64]
Thanks for your insight in the RedHat way. With already three OSes
installed on my AMD64, I don't feel like trying another one (an
Solaris 10 would be first anyway), but their approach is definitely
relevant for us. Both as an example
multiarch is most
likely to go. Unfortunately, the relevant site seems to be down, but
take a look at [1], and possibly some of the other (Google cached)
files in [2].
And why not have them? Obviously there is a need - to ease migration...
If I may venture a little further, the idea that all
on this so much.
I am not saying that one starts multiarch and immediately pretends its
finished. Only that one can start, without breaking anything... so why not
start?
Why not make /usr/lib/i386-linux and make the links? New packages would
eventually follow the new standard directly
program both 32bit and 64bit at the same time.
If we don't then I consider multiarch very broken.
Len Sorensen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Tue, Jul 05, 2005 at 07:54:06PM -0400, Stephen Frost wrote:
apt-get install A::amd64;
Should automatically uninstall the i386 version of A and install the
amd64 version.
If that's how it is going to behave, I will stick with a chroot for
32bit. Much more useful then. I do have reason to
the same
program both 32bit and 64bit at the same time.
If we don't then I consider multiarch very broken.
That's nice.
Stephen
signature.asc
Description: Digital signature
On Tue, Jul 05, 2005 at 04:56:34PM -0400, David Wood wrote:
Why bother making it hard when you can just make it easy and link the
whole directory?
You can't make a link to a child of yourself since then the child has no
parent dir to beling to if the parent isn't a directory.
it would work if
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
On Tue, Jul 05, 2005 at 07:54:06PM -0400, Stephen Frost wrote:
apt-get install A::amd64;
Should automatically uninstall the i386 version of A and install the
amd64 version.
If that's how it is going to behave, I will stick with a chroot for
in the real world. Does not work in pure64, except in chroot. I'm
not even saying multiarch would help solve this problem (I don't know),
just commenting generally.
Wine: interesting. I'll (optimistically) take another look.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
Getting the toolchain adapted is more important than some trivial mv
commands for libs.
You're right, of course, but I don't understand why we should avoid doing
them. With the new dirs in place and linked from the old locations,
package
El mié, 06-07-2005 a las 09:32 -0400, David Wood escribió:
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my
pure64. What problems do you have?
The only important thing that distinguishes mplayer from all the other
video players
David Wood [EMAIL PROTECTED] writes:
can't be a symlink to /usr/lib/i386-linux after all. So if programs on
I don't understand. Why not?
Just try it:
- mkdir /usr/lib/i386-linux
- rm -r /usr/lib
- ln -s /usr/lib/i386-linux /usr/lib
Does that work on your machine?
Matthias
--
To
El mié, 06-07-2005 a las 09:11 -0400, Matthias Julius escribió:
David Wood [EMAIL PROTECTED] writes:
can't be a symlink to /usr/lib/i386-linux after all. So if programs on
I don't understand. Why not?
Just try it:
- mkdir /usr/lib/i386-linux
- rm -r /usr/lib
Does that work on
codecs, so I would use the 64bit version. But
sometimes I need flash, the realplayer or old video codecs.
Of course I could build a chroot, but then I wouldn't need multiarch.
So why don't create /usr/bin/i386 and /usr/bin/amd64 and populate
/usr/bin with symlinks to the programs. You could build
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
1) We are not that compatible to begin with
In what way? We follow LSB and such.
Different baseline libraries, different _available_, _packaged_
libraries, different compiler versions, different directory structures
(for instance, important
Digesting about 8 things into a single response...
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
You only need dpkg support to utilize it. The design is such that the
debs shall remain compatible to older debian. You just don't get the
multiarch benefits. So apt/dpkg are not realy blocking
bug but illustrative.
Now that '(64bit)' is something they had to add for biarch support.
There was talk about doing the same for multiarch early on but it
breaks backwards compatibility, i.e. old packages that don't have the
(64bit) will break. We improved that by having libraries state
Multiarch
Stephen Frost [EMAIL PROTECTED] writes:
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote:
What's the reason for having both versions of a given app installed?
I'm pretty sure it was decided that was a bad idea and that there wasn't
Matthias Julius [EMAIL PROTECTED] writes:
David Wood [EMAIL PROTECTED] writes:
can't be a symlink to /usr/lib/i386-linux after all. So if programs on
I don't understand. Why not?
Just try it:
- mkdir /usr/lib/i386-linux
- rm -r /usr/lib
- ln -s /usr/lib/i386-linux /usr/lib
Does that
win32 codecs, and thus be actually
useful in the real world. Does not work in pure64, except in
chroot. I'm not even saying multiarch would help solve this problem (I
don't know), just commenting generally.
Wine: interesting. I'll (optimistically) take another look.
Mplayer can play all the common
from the old
locations, package conversion can start. Until then, the process waits
to start. Why wait?
We shouldn't. We just have to test this very carefully or the fallout
of a bad upload will create too much oposition to including multiarch
patches and slow us down overall.
Imaging the bad
the most
common media I run across, but of course, it's not a scientific survey...
But if you do need w32codecs then just stick with a 32bit
mplayer. With multiarch that will be just apt-get install mplayer-686
w32codecs. Till then it means a chroot or some manual fiddling.
Quite right. Let
with flash plugin or a
mplayer/xine with old codecs, so I would use the 64bit version. But
sometimes I need flash, the realplayer or old video codecs.
Of course I could build a chroot, but then I wouldn't need multiarch.
So why don't create /usr/bin/i386 and /usr/bin/amd64 and populate
/usr/bin
David Wood [EMAIL PROTECTED] writes:
On Wed, 6 Jul 2005, Hugo Mills wrote:
They're not (directly) the way that the Debian multiarch is most
likely to go. Unfortunately, the relevant site seems to be down, but
take a look at [1], and possibly some of the other (Google cached)
files in [2
Goswin von Brederlow [EMAIL PROTECTED] writes:
Better not try that with /usr/lib. :)
Well, you always have a backup. Right?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote:
We are not saying you shouldn't make binaries coinstallable for
multiple archs, we are only saying we won't make this a policy. It is
left to each package maintainer to decide if he wants to make the
multiarch change for his
Matthias Julius wrote:
Goswin von Brederlow [EMAIL PROTECTED] writes:
Better not try that with /usr/lib. :)
Well, you always have a backup. Right?
ob-oldtimer-quip
It's not the backup that'll kill you, it's having a dynamically linked
copy of ln that needs something in /usr/lib/ that'll
wants to make the
multiarch change for his binary too or not and nearly every one will
not.
All right, this is a solution I can live with. Until now I thought,
that it would be impossible, even with multiarch, to install two
programs together.
It is impossible to install two packages that contain
tony mancill [EMAIL PROTECTED] writes:
Matthias Julius wrote:
Goswin von Brederlow [EMAIL PROTECTED] writes:
Better not try that with /usr/lib. :)
Well, you always have a backup. Right?
ob-oldtimer-quip
It's not the backup that'll kill you, it's having a dynamically linked
copy of ln
On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote:
Something else ugly... Just curious, why would this break:
mkdir /usr
mkdir /usr/lib
ln -s /usr/lib /usr/lib/i386-linux
It's recursive, but it appears functional...
Yes but now all the i386 files are also in /usr/lib which would
won't make this a policy. It is
left to each package maintainer to decide if he wants to make the
multiarch change for his binary too or not and nearly every one will
not.
If you did allow it, you could almost have a single nfs server handle
all package installs for multiple architectures
Brederlow;
debian-amd64@lists.debian.org
Subject: Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
Of course there is also the issue of how to deal with calling the 32
or
64bit version of program x if you have both versions installed.
Perhaps
a helper tool
On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote:
On Wed, 6 Jul 2005, Hugo Mills wrote:
They're not (directly) the way that the Debian multiarch is most
likely to go. Unfortunately, the relevant site seems to be down, but
take a look at [1], and possibly some of the other (Google
would not even need to be changed except at the
end or in prerelease multiarch systems (although, maybe, why wait?); the
idea is that nothing would, in fact, need to change, until you are ready,
while you can simultaneously prepare your packages for the new standard.
--
To UNSUBSCRIBE, email
then, the process waits
to start. Why wait?
We shouldn't. We just have to test this very carefully or the fallout
of a bad upload will create too much oposition to including multiarch
patches and slow us down overall.
Imaging the bad blood you would create if you break libc6.
Agreed. It's
make this a policy. It is
left to each package maintainer to decide if he wants to make the
multiarch change for his binary too or not and nearly every one will
not.
All right, this is a solution I can live with. Until now I thought,
that it would be impossible, even with multiarch, to install
specific in Debian wouldn't work, and couldn't be
elegantly made to work, with the scheme? Reading it, I can't see what that
would be - but that's not saying much, that's why I'm asking.
Sure you can. Just test them.
How? You can't install your two multiarch versions of libvorbis
without
coinstallable for
multiple archs, we are only saying we won't make this a policy. It is
left to each package maintainer to decide if he wants to make the
multiarch change for his binary too or not and nearly every one will
not.
If you did allow it, you could almost have a single nfs server handle
all
Hugo Mills [EMAIL PROTECTED] writes:
On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote:
On Wed, 6 Jul 2005, Hugo Mills wrote:
They're not (directly) the way that the Debian multiarch is most
likely to go. Unfortunately, the relevant site seems to be down, but
take a look at [1
On 7/5/05, Goswin von Brederlow [EMAIL PROTECTED] wrote:
But you don't realy gain anything by multiarch for amd64. Only 3
things come to my mind: OpenOffice, Flash support and w32codecs +
32bit mplayer. And only OO is in Debian.
The big advantage is binary compatibility with the rest
The current timeline is as follows:
- get security support fully working
- split the archive by architectures to reduce mirror bandwith
- add amd64 to sid/etch
- rebuild and upload all packages from an official buildd
BTW, is there an estimation when amd64 will be added to sid/etch?
[..]
But you don't realy gain anything by multiarch for amd64. Only 3
things come to my mind: OpenOffice, Flash support and w32codecs +
32bit mplayer. And only OO is in Debian.
And OOo 2.0, which is due really soon, will natively support 64-bits
architectures.
MfG
Goswin
Jérôme Warnier [EMAIL PROTECTED] writes:
[..]
But you don't realy gain anything by multiarch for amd64. Only 3
things come to my mind: OpenOffice, Flash support and w32codecs +
32bit mplayer. And only OO is in Debian.
And OOo 2.0, which is due really soon, will natively support 64-bits
Thomas Steffen [EMAIL PROTECTED] writes:
On 7/5/05, Goswin von Brederlow [EMAIL PROTECTED] wrote:
But you don't realy gain anything by multiarch for amd64. Only 3
things come to my mind: OpenOffice, Flash support and w32codecs +
32bit mplayer. And only OO is in Debian.
The big advantage
On 7/5/05, Goswin von Brederlow [EMAIL PROTECTED] wrote:
All current linux distributions are pure64.
That might be a matter of definition. From the user's point of view,
most commercial distributions are multiarch. After all, it is
difficult to sell a better distribution that is not even
On Tuesday 05 July 2005 15:44, Goswin von Brederlow wrote:
All current linux distributions are pure64. They only differ slightly
in the amount of 32bit libs preinstalled (what debian has as
ia32-libs). Multiarch is something that goes way beyond what other
amd64 distributions have.
Multiarch
On Tue, 5 Jul 2005, Adam Stiles wrote:
Binary compatibility is irrelevant at best {every Linux machine already has a
compiler installed} and harmful at worst {Windows has wide-scale binary
compatibility -- and rampant malware}. All that matters is _source_
compatibility: that the same
On Tue, 5 Jul 2005, Goswin von Brederlow wrote:
But you don't realy gain anything by multiarch for amd64. Only 3
things come to my mind: OpenOffice, Flash support and w32codecs +
32bit mplayer. And only OO is in Debian.
Maybe add wine to that list? (Disclaimer, haven't tried it lately)
I
.
second, it looks there's no reason to wait to start.
Am I a bonehead or is it just a matter of moving some directories and
symlinks around in etch and then the super-gradual process (many many
years if you want) of migrating things from using the legacy symlinks to
the multiarch dirs... Why
David Wood wrote:
On Tue, 5 Jul 2005, Goswin von Brederlow wrote:
But you don't realy gain anything by multiarch for amd64. Only 3
things come to my mind: OpenOffice, Flash support and w32codecs +
32bit mplayer. And only OO is in Debian.
Maybe add wine to that list? (Disclaimer, haven't
, for a start. And in dselect, apt, and all apt's
friends. I had a go at doing the dpkg support last year, and it
defeated me(*). It is very much non-trivial...
Why? If I read this correctly...
http://www.linuxbase.org/futures/ideas/multiarch/
All the directories that get moved are symlinked from
1 - 100 of 157 matches
Mail list logo
