On Thursday 24 August 2006 11:08, Daniel Tryba wrote:
On Wed, Aug 23, 2006 at 10:16:30PM +0200, Francesco Pietra wrote:
[snip]
Any guess at what that means? I naively understand it was failure by the
OS, not failure of hardware.
I had the same errors on a Tyan K8SSA and first thought it
While computing with mpqc2.3.1 (debian etch amd6a; dual opterons; 8GB ram ECC;
raid 1; filesystem ext3; grub on its own partition):
Led of HD permanently lighted.
Messages on screen:
ATA: abnormal status 0x58 on port 0x1C5F
ata3: command 0x35 timeout, stat 0x50 host_stat 0x24
ata 4: same
Here's the status of the lkdi rebuilds for 3.1r3.
l-k-di-${arch}: accepted into stable (no rebuild necessary)
l-k-di-amd64-2.6: build available in gluck:~dannf/3.1r3-lkdi-rebuilds
amd64 guys: should i upload this somewhere?
l-k-di-m68k-2.6: porter poked for update
l-k-di-[hppa
On Sunday 30 July 2006 21:00, dann frazier wrote:
Here's the status of the lkdi rebuilds for 3.1r3.
Thanks Dann.
l-k-di-amd64-2.6: build available in gluck:~dannf/3.1r3-lkdi-rebuilds
amd64 guys: should i upload this somewhere?
They should preferably end up in:
http://amd64
Hi Steve:
Did you succeed installing kde?
I have just installed amd64 eich for dual opterons, X-system is waiting to
install kde. Thnks for informing me
francesco pietra
On Thursday 13 April 2006 09:15, Steve Juranich wrote:
I just installed a fresh debian system on my spankin' new Athlon 64
beautifully as you describe below) and OpenMotif to
run a package (that I could compile for 64) that uses OpenGL for the graphics
engine, just to see the results in virtual space. Do you know the status of
these affairs in amd64 that we have installed?
Implicitly I need to recompile the generic kernel
for 64) that uses OpenGL for the graphics
engine, just to see the results in virtual space. Do you know the status of
these affairs in amd64 that we have installed?
Implicitly I need to recompile the generic kernel that I have installed.
Compiler/libraries (Motiv or Lesstif installed)?
Cheers
On Thursday 13 April 2006 09:15, Steve Juranich wrote:
So I'm assuimg this all has to do with the migration over to the main debian
FTP sites and that testing/etch will eventually catch up. Is this a correct
assumption?
Correct. Many packages currently miss in Etch.
If it is correct,
I just installed a fresh debian system on my spankin' new Athlon 64 X2 3800.
Things have gone pretty well so far, but I guess I just hit everything at just
the right time as far as repository sanity goes.
I've tried the past couple of days to `apt-get install kde' with no joy. I
keep getting
I am very happy to announce that the debian-installer images targeted for
Beta2 are now in testing (except AMD64) and that daily (etch_d-i) netinst
and buisinesscard CD images using them are now available from [1].
These images use the 2.6.15-7 kernel.
Note: full CD images are not yet
On Tue, Mar 07, 2006 at 01:52:49PM +0100, Frans Pop wrote:
I am very happy to announce that the debian-installer images targeted for
Beta2 are now in testing (except AMD64) and that daily (etch_d-i) netinst
and buisinesscard CD images using them are now available from [1].
These images use
(already sent to d-boot)
On Tuesday 07 March 2006 13:52, Frans Pop wrote:
I am very happy to announce that the debian-installer images targeted
for Beta2 are now in testing (except AMD64) and that daily (etch_d-i)
netinst and buisinesscard CD images using them are now available from
[1].
I've made a complete mess of CD images for Beta2 so far as the result of a
wrong assumption. This means, as some installation reports and comments
have shown, that CD images linked from [1] have been broken since last
Friday.
The good news is that there are now good Beta2 netinst and
I'm curious about the status of the Sarge 3.1r1 updates for the amd64
port. Any idea when they'll be available?
--
Joe Bowman
Progeny Linux Systems
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Kurt Roeckx wrote:
Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file doesn't
list `source' in Architecture field.
Second try.. this seems like it's expecting a sourceful upload for some
reason, which it shouldn't if you have the debian-installer source
package already in
On Sat, Nov 05, 2005 at 03:19:06PM +0100, Kurt Roeckx wrote:
On Sat, Nov 05, 2005 at 12:22:49AM +0100, Kurt Roeckx wrote:
The problem now seems to be that rootskel-locale still seems to
exist in testing for some reason. It's unclear to me why it
still exists. This is causing the
Kurt Roeckx wrote:
The next problem is to actually get it into the archive. It's
getting rejected:
Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file doesn't
say debian-installer-images_20051026 for Source
Rejected: debian-installer-images_20051026_amd64.tar.gz: should be
On Sun, Nov 06, 2005 at 02:39:38PM -0500, Joey Hess wrote:
Kurt Roeckx wrote:
The next problem is to actually get it into the archive. It's
getting rejected:
Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file
doesn't say debian-installer-images_20051026 for Source
Kurt Roeckx wrote:
I would be suprised if it generated broken .changes files. I've
attached it.
It's broken, what's the listed debian-installer_20051026_amd64.deb?
Files:
cf4dca5ef36c3ab9e8794be42533fd5e 574138 devel optional
debian-installer_20051026_amd64.deb
On Sun, Nov 06, 2005 at 06:27:52PM -0500, Joey Hess wrote:
Kurt Roeckx wrote:
I would be suprised if it generated broken .changes files. I've
attached it.
It's broken, what's the listed debian-installer_20051026_amd64.deb?
dpkg -I debian-installer_20051026_amd64.deb
new debian package,
Sven Luther [EMAIL PROTECTED] writes:
The problem with miboot is that there are 200 or so m68k instructions in the
boot sector, which have not been changed since over 10 years probably, and
probably nobody at appple even remembers them, and thus we are not shipping
miboot even in non-free,
On Fri, Nov 04, 2005 at 10:02:37PM -0500, Joey Hess wrote:
You know, amd64 is the only arch to build the monolithic target by
default. I think that this is because it used to be hard to get
businesscard CDs for amd64, but we build them now. And also there used
to be the mirror selection
On Sat, Nov 05, 2005 at 12:22:49AM +0100, Kurt Roeckx wrote:
The problem now seems to be that rootskel-locale still seems to
exist in testing for some reason. It's unclear to me why it
still exists. This is causing the monolithic target to fail to
build because it can't find the locale.
On Fri, 4 Nov 2005, Sven Luther wrote:
Actually, we could simply make an exception for miboot and get it into the
archive, i think it is no worse than other cases (like amiboot, which is
linked to parts of amigaos, and thus non-free), and we do distribute those (or
at least used to distribute
On Fri, Nov 04, 2005 at 10:45:30AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
Actually, we could simply make an exception for miboot and get it into the
archive, i think it is no worse than other cases (like amiboot, which is
linked to parts of amigaos, and thus
On Fri, Nov 04, 2005 at 11:57:12AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
On Fri, Nov 04, 2005 at 10:45:30AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
Actually, we could simply make an exception for miboot and get it into
On Fri, 4 Nov 2005, Sven Luther wrote:
On Fri, Nov 04, 2005 at 10:45:30AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
Actually, we could simply make an exception for miboot and get it into the
archive, i think it is no worse than other cases (like amiboot,
On Fri, Nov 04, 2005 at 01:27:52PM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
On Fri, Nov 04, 2005 at 11:57:12AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
On Fri, Nov 04, 2005 at 10:45:30AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
On Fri, Nov 04, 2005 at 11:57:12AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
On Fri, Nov 04, 2005 at 10:45:30AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
Actually, we could simply make
On Fri, Nov 04, 2005 at 12:01:17PM +0100, Sven Luther wrote:
On Fri, Nov 04, 2005 at 11:57:12AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
On Fri, Nov 04, 2005 at 10:45:30AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven Luther wrote:
On Fri, Nov 04, 2005 at 02:00:03PM +0100, Sven Luther wrote:
On Fri, Nov 04, 2005 at 05:53:53AM -0700, Christian T. Steigies wrote:
On Fri, Nov 04, 2005 at 12:01:17PM +0100, Sven Luther wrote:
On Fri, Nov 04, 2005 at 11:57:12AM +0100, Geert Uytterhoeven wrote:
On Fri, 4 Nov 2005, Sven
On Fri, Nov 04, 2005 at 08:04:22AM -0700, Christian T. Steigies wrote:
It is an AmigaOS binary, built from free source with free compilers. So we
just have to
include all the free AmigaOS software to be able to ship a precompiled
amiboot? As I said,
no problem with me, maybe we include all
On Wed, Nov 02, 2005 at 02:08:07PM -0500, Joey Hess wrote:
This was resolved, only to hit the next problem with amd64: The amd64
archive signing key is not trusted by apt. So currently testing amd64
installs only work from the netinst CD, all the other install methods,
which use apt
On Fri, Nov 04, 2005 at 08:04:22AM -0700, Christian T. Steigies wrote:
On Fri, Nov 04, 2005 at 02:00:03PM +0100, Sven Luther wrote:
On Fri, Nov 04, 2005 at 05:53:53AM -0700, Christian T. Steigies wrote:
On Fri, Nov 04, 2005 at 12:01:17PM +0100, Sven Luther wrote:
On Fri, Nov 04, 2005 at
On Fri, Nov 04, 2005 at 02:17:22PM -0600, Eric Shattow wrote:
I have used miBoot on a nubus ppc mac (6116cd) and it is not the
optimal solution. My suggestion as a user is that you forget about
using miBoot at all, and foster development for a new GPL'ed
bootloader based on EMILE. Laurent
On 11/4/05, Sven Luther [EMAIL PROTECTED] wrote:
On Fri, Nov 04, 2005 at 08:04:22AM -0700, Christian T. Steigies wrote:
On Fri, Nov 04, 2005 at 02:00:03PM +0100, Sven Luther wrote:
On Fri, Nov 04, 2005 at 05:53:53AM -0700, Christian T. Steigies wrote:
On Fri, Nov 04, 2005 at 12:01:17PM
Kurt Roeckx wrote:
We've pushed apt 0.6.42.2 to testing in the amd64 archive. We
didn't have the problem with the gcc-4.0 dependency and did a
local override to get the new apt in testing.
That's very good (and timely) news. Is there any status on getting the
debian-installer package built
. Is there any status on getting the
debian-installer package built?
The problem now seems to be that rootskel-locale still seems to
exist in testing for some reason. It's unclear to me why it
still exists. This is causing the monolithic target to fail to
build because it can't find the locale.
I've
Kurt Roeckx wrote:
The problem now seems to be that rootskel-locale still seems to
exist in testing for some reason. It's unclear to me why it
still exists. This is causing the monolithic target to fail to
build because it can't find the locale.
I've asked the amd64 ftp-master too look at
On Wed, Nov 02, 2005 at 02:08:07PM -0500, Joey Hess wrote:
installer/doc/devel/release-checklist as we can. At a minimum we need to
make sure that businesscard, netinst, and full CDs (once we get some)
work for i386 and powerpc and that the desktop task installs ok and
works.
Joeyh, i wonder
An update on the d-i beta status. We're getting really close, AKA most
things seem likely to work now. Ccing some other relevant lists.
debian-boot:
- Thanks to fjp, base-installer 1.35.4 should get d-i working again with
secure apt and CDs, but we're currently mssing uploads of successful
On Wed, Nov 02, 2005 at 02:08:07PM -0500, Joey Hess wrote:
amd64 has also not built the most recent version of the debian-installer
package, and has been marked as building for over a day at
http://people.debian.org/~igloo/status.php?email=packages=debian-installerarches=
Additionally, it
On Tue, Oct 18, 2005 at 12:33:06AM +0200, Frederik Schueler wrote:
check out sarge-unsupported aka stinkypete:
deb http://amd64.debian.net/debian-amd64/ stinkypete main
(available on your favorite mirror)
actually, it contains the following packages from maintainers who where
not
-official status
of the port before testing became etch.
But what about now, to what extent is AMD64 official enough, to change this
kind of behaviour? I guess further requests in the bug report are useless.
Thanks for your work and patience (especially Goswin),
Frank
1: http://bugs.debian.org
Hello,
On Mon, Oct 17, 2005 at 11:47:40PM +0200, Frank Siegert wrote:
I always found it strange that cdrdao (which is required by e.g. k3b) is not
in the official AMD64 archive. Now I found this bugreport[1], already
attached is a fix, which has been tested by quite a few people. And still
On Mon, Sep 19, 2005 at 08:50:07PM -0500, Ken Bloom wrote:
Display:14.0 WXGA High-Definition BrightView Widescreen (1280 x
768) display
Hmm, interesting. That is 15:9 ratio. Most I have seen were the 15.4
WXGA which are 1280x800 (16:10 ratio).
Wireless connectivity:54g Integrated
I have previously posted to vox-tech@lists.lugod.org about attempts to
install Linux on my Turion64 based Compaq Presario v2310us laptop. I'm
posting this as a howto to both vox-tech, and also debian-amd64, so that
there should be an internet record of how to get a successful system
working.
In
.
Maybe Andreas can give a little status update for the archive. With
sid having the new compiler the amd64 part of the archive becomes
quickly redundant. I guess after the C++ transition it can cease to
exist.
Yes, when the C++ transition is complete, the amd64/gcc4 archive will
have served its
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
On Fri, 8 Jul 2005, Goswin von Brederlow wrote:
3rd party software is nearly completly 32bit and our 32bit libs are
already in the wrong place for rpath then. We can move
/emul/ia32-libs/lib/* to /lib/i486-linux/ (same for usr/lib in all
cases) without changing anything.
We can also move
Hugo Mills [EMAIL PROTECTED] writes:
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote:
Stephan Seitz [EMAIL PROTECTED] writes:
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
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.
GOMBAS Gabor [EMAIL PROTECTED] writes:
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
Does that dlopen
David Wood [EMAIL PROTECTED] writes:
On Fri, 8 Jul 2005, Goswin von Brederlow wrote:
3rd party software is nearly completly 32bit and our 32bit libs are
already in the wrong place for rpath then. We can move
/emul/ia32-libs/lib/* to /lib/i486-linux/ (same for usr/lib in all
cases) without
Dne st 6. července 2005 22:16 Hugo Mills napsal(a):
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote:
It is impossible to install two packages that contain the same
filename. Libraries use /usr/lib/arch-os/ to make libs differ between
archs.
That's not _entirely_
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.
Miroslav Maiksnar [EMAIL PROTECTED] writes:
Dne st 6. Äervence 2005 22:16 Hugo Mills napsal(a):
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote:
It is impossible to install two packages that contain the same
filename. Libraries use /usr/lib/arch-os/ to make libs differ
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
Goswin von Brederlow wrote:
[EMAIL PROTECTED] (Bob Proulx) writes:
This has been a long standing behavior of rpm that is now
exploited for use in biarch.
That sounds like there is no special biarch support at all in rpm but
just the support to have multiple versions of a package installed
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 the
* 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 or
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 for
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.
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
On Tue, Jul 05, 2005 at 09:13:47PM -0400, David Wood wrote:
On Wed, 6 Jul 2005, Kurt Roeckx wrote:
There are not going to be any symlinks at all. There is no need
So, the posted documents are not correct on this (basic, major) point?
They're not (directly) the way that the Debian
On Tue, Jul 05, 2005 at 04:40:17PM -0400, David Wood wrote:
But it is not incompatible unless you remove the links - and then you are
no longer following the proposal.
As I understand it, /usr/lib is a symlink/hardlink/bindmount to
/usr/lib/i386-linux, not the other way around.
If
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
any good use case for it and so we weren't going to try and support it.
It just doesn't
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
* 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
any good use case for it and so we
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
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 is its ability to use win32 codecs, and thus be actually
useful
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
On Wed, Jul 06, 2005 at 08:45:43AM -0400, Stephen Frost wrote:
you've described. You havn't given any reason why a user would have any
use for it. There are quite a few reasons why trying to do such would
Hm, normally, I wouldn't need a firefox with flash plugin or a
mplayer/xine with old
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
[EMAIL PROTECTED] (Bob Proulx) writes:
This is where it gets ugly. The /usr/share part overlaps between the
two packages. As long as the md5sum of a file is the same rpm will
allow packages to overlap files. (Personally I think that is a bad
thing and should not have been designed that
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
David Wood [EMAIL PROTECTED] writes:
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 is its ability to use
David Wood [EMAIL PROTECTED] writes:
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
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
Mplayer can play all the common files in 64bit directly except the mov
files of current movie trailers. Anything else mplayer needs w32codecs
for are rather uncommon in my experience.
I find 64-bit unplayable real, wmv and mov files to be by far
Stephan Seitz [EMAIL PROTECTED] writes:
On Wed, Jul 06, 2005 at 08:45:43AM -0400, Stephen Frost wrote:
you've described. You havn't given any reason why a user would have any
use for it. There are quite a few reasons why trying to do such would
Hm, normally, I wouldn't need a firefox with
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
Stephan Seitz [EMAIL PROTECTED] writes:
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
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
101 - 200 of 315 matches
Mail list logo
