On Mon, Sep 30, 2013 at 09:22:06PM +, Bill Allombert wrote:
We should add official support for ppc64 and maybe sparc64 at least for use
as a multiarch extension to ppc/sparc, even if we do not have time to make a
full
port. Otherwise the introduction of multiarch will likely result
Hi.
On 02/10/13 12:56, Jonathan Dowland wrote:
Actually I wonder how many 32 bit powerpc
users there are compared to 64 bit. IN the mac world, I'd wager
more G4s than G5s (the mac pro or xserves), not sure about other
powerpc worlds.
Maybe these figures from popcon are indicative; it seems
On Wed, Oct 02, 2013 at 12:56:51PM +0100, Jonathan Dowland wrote:
On Mon, Sep 30, 2013 at 09:22:06PM +, Bill Allombert wrote:
We should add official support for ppc64 and maybe sparc64 at least for use
as a multiarch extension to ppc/sparc, even if we do not have time to make
a full
Gawroriski (!DD)
sparc64: Steven Gawroriski (!DD), Kieron Gillespie (!DD)
We should add official support for ppc64 and maybe sparc64 at least for use
as a multiarch extension to ppc/sparc, even if we do not have time to make a
full
port. Otherwise the introduction of multiarch will likely result
) but “deceiving” gcc to use the
multiarch files instead.
For example to use an amd64 → i486 fake cross-toolchain you do:
$ dpkg --print-architecture
amd64
$ apt-get install libgcc-4.8-dev:i386 libc6-dev:i386
$ ln -s ../../i486-linux-gnu/4.8 /usr/lib/gcc/x86_64-linux-gnu/4.8/32
$ ./gen-cross
Hi,
I filed bug #708299 [1] but realize that it's not really an issue with
that package: dpkg doesn't like it when buildd adds an architecture
specific entry to changelog.Debian:
snip
Preparing to replace libgl1-mesa-dri:amd64 8.0.5-4 (using
.../libgl1-mesa-dri_8.0.5-4+b1_amd64.deb) ...
Hi David,
David Mohr damaili...@mcbf.net (16/05/2013):
I filed bug #708299 [1] but realize that it's not really an issue
with that package: dpkg doesn't like it when buildd adds an
architecture specific entry to changelog.Debian: […]
everyone knows:
Scenario:
a Intel x64 (T5500) with Wheezy i386 installed.
It's possible use the multiarch support of dpkg
to migrate to Wheezy amd64 ?
(after installation of linux-image-amd64, libc6-amd64)
Thanks
Walter
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject
On Mon, May 06, 2013 at 12:03:15PM +0100, Walter Valenti wrote:
a Intel x64 (T5500) with Wheezy i386 installed.
It's possible use the multiarch support of dpkg
to migrate to Wheezy amd64 ?
(after installation of linux-image-amd64, libc6-amd64)
Migrating a live system between architectures
On Lu, 06 mai 13, 12:03:15, Walter Valenti wrote:
Scenario:
a Intel x64 (T5500) with Wheezy i386 installed.
It's possible use the multiarch support of dpkg
to migrate to Wheezy amd64 ?
(after installation of linux-image-amd64, libc6-amd64)
This belongs on debian-user, see
http
Le 2013-05-05 03:50, Adam Borowski a écrit :
On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of
the
build process (i.e. ocaml doesn't build-depend
On Sat, 2013-05-04 at 06:36:31 +0200, Matthias Klose wrote:
Am 19.04.2013 00:33, schrieb Guillem Jover:
I think the full-multiarch support for python in
experimental should really be reverted.
No. This is backward, and the wrong way to go forward.
Sorry, but the way to go forward
of OCaml wrt multiarch. There are actually two compilers.
One of them is the bytecode one and uses its own binary format for
compiled objects. For pure OCaml code, this bytecode is portable (pretty
much like Java). There is no shared library mechanism and all
executables are statically linked
On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of the
build process (i.e. ocaml doesn't build-depend on itself). So no need
for cross-compilation
Le 05/05/2013 03:50, Adam Borowski a écrit :
On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of the
build process (i.e. ocaml doesn't build-depend
Am 19.04.2013 00:33, schrieb Guillem Jover:
I think the full-multiarch support for python in
experimental should really be reverted.
No. This is backward, and the wrong way to go forward. I do acknowledge that
there are issues with the current state of dpkg, but I'm not seeing how you
On Sun, Apr 21, 2013 at 02:42:32AM +0300, Uoti Urpala wrote:
Should that set of running architectures be just architecture?
No. Some packages can have multiple runing architecturs. The most
obvious case is M-A:same packages where you can install the same package
for multiple architectures.
on a package Q are either all of
type 1 or all of type 2, as long as Q only exposes one kind of
interface; in the current multiarch spec Q indicates this by
Multi-Arch: same for 1 and foreign for 2. However, dependency types
3 and 4 require adding more information in the depending package to
allow
Helmut Grohne wrote:
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
3) P runs a script using system interpreter X, and depends on the
interpreter environment supporting functionality provided by Q.
Q needs to work for the arch matching installed version of X.
P (all)
that have
popped up requiring these additional capabilities are a minority.
Having to split a small number of packages to achieve true multiarch
seems like a good trade off to complicating the dependency syntax to me.
Helmut
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
adding such splitting of packages the system could
represent the required constraints, but I'm not sure if such splitting
is a practical way.
Having to split a small number of packages to achieve true multiarch
seems like a good trade off to complicating the dependency syntax to me.
Have you tried
On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
- Third party modules for interpreters should be cross-buildable.
Many build systems for interpreter languages are written in the
interpreter language itself. So you do require the interpreter
for the build, and the
and development files. What about
cross-building third party modules?
I haven't looked at the cross-building part much myself, so I'll let
Neil or Wookey answer that. I'll just point out that I have worked on
'full multiarch' support in perl [1] with a co-installable libperl and
the standard
On Thu, Apr 18, 2013 at 11:01:17PM -0700, Steve Langasek wrote:
On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
I don't see a need to have the perl:i386 interpreter installed on amd64
in order to build third party i386 perl modules, the amd64 interpreter
should be fine, just
On Fri, Apr 19, 2013 at 05:26:41PM +0300, Niko Tyni wrote:
On Thu, Apr 18, 2013 at 11:01:17PM -0700, Steve Langasek wrote:
On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
I don't see a need to have the perl:i386 interpreter installed on amd64
in order to build third party
On Fri, Apr 19, 2013 at 08:01:40AM -0700, Steve Langasek wrote:
On Fri, Apr 19, 2013 at 05:26:41PM +0300, Niko Tyni wrote:
The modules aren't linked against libperl, it's
the other way around: libperl loads them at run time with dlopen(3).
They are effectively plugins in a private
On Fri, Apr 19, 2013 at 12:33:07AM +0200, Guillem Jover wrote:
As I pointed out on the debian-perl mailing list, after having
discussed about multiarch support for perl, I don't think a fully
multiarchified perl (nor at least python) should be uploaded to sid,
as going full multiarch
On Thu, Apr 18, 2013 at 04:41:35PM +0200, Matthias Klose wrote:
- Ruby: Afaik, not yet started on multiarch.
Ruby 2.0 has multiarch support upstream. The Debian packaging is not
finished yet, but it will have multiarch.
I do not plan to multiarch 1.9.
--
Antonio Terceiro terce...@debian.org
on the interpreter environment supporting functionality
provided by Q.
Q needs to work for arch.
In the most common case dependencies on a package Q are either all of
type 1 or all of type 2, as long as Q only exposes one kind of
interface; in the current multiarch spec Q indicates this by
Multi-Arch
Am 16.04.2013 15:19, schrieb Wookey:
+++ Игорь Пашев [2013-04-16 16:49 +0400]:
2013/4/16 Neil Williams codeh...@debian.org:
On Tue, 16 Apr 2013 16:11:24 +0400
So, is it important, that multiarch dirs go after crossdirs:
our @librarypaths = (DEFAULT_LIBRARY_PATH, @crosslibrarypaths
/MultiArch
- Ruby: Afaik, not yet started on multiarch.
- Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
are available in Debian bug reports.
Currently the shared libraries are split out into separate packages,
and are co-installable. Not yet tested if this enough to run
Hello,
On 18 April 2013 16:41, Matthias Klose d...@debian.org wrote:
- Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
are available in Debian bug reports.
Currently the shared libraries are split out into separate packages,
and are co-installable. Not yet tested if
. Packages are available in
experimental, but because I didn't backport this to 2.6 and 3.2, not
much useful. Install an Ubuntu raring (13.04) chroot to experiment
with these. Details at http://wiki.debian.org/Python/MultiArch
- Ruby: Afaik, not yet started on multiarch.
- Tcl/Tk: Wookey
into separate packages,
and are co-installable. Not yet tested if this enough to run an
embedded interpreter.
Could I please have more info? :)
Well there are patches to move .so libraries from /usr/lib/tk8.*/ to
/usr/lib/$(MULTIARCH)/tk8.*, same for tcl and matching tcltk-defaults
package
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose d...@debian.org wrote:
- running a gdb:amd64 on i386 to debug 64bit binaries. This is the
reason for our current gdb64 package on i386, but it is missing the
support for the python based pretty printer.
Installing gdb:amd64 on i386
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose d...@debian.org wrote:
- running a gdb:amd64 on i386 to debug 64bit binaries. This is the
reason for our current gdb64 package on i386, but it is missing the
support for the python based pretty printer.
Installing gdb:amd64 on i386
in
experimental, but because I didn't backport this to 2.6 and 3.2, not
much useful. Install an Ubuntu raring (13.04) chroot to experiment
with these. Details at http://wiki.debian.org/Python/MultiArch
Will there be a way to co-install modules too?
As for GObject introspection modules (which replace
Goswin von Brederlow writes (Re: multiarch and interpreters/runtimes):
Co-installability of interpreters is generally not planed and would
have to be made as custom solutions, i.e. place the interpreter in
/usr/lib/x86_64-linux-gnu/perl/ and provide /usr/bin/perl as
alternative.
I think it's
are split out into separate
packages, and are co-installable. Not yet tested if this enough to
run an embedded interpreter.
Could I please have more info? :)
Well there are patches to move .so libraries from /usr/lib/tk8.*/ to
/usr/lib/$(MULTIARCH)/tk8.*, same for tcl and matching tcltk
Hi!
On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura bugzi...@tut.by wrote:
Hello,
By the way, have you contacted Sergei on this?
I saw the bugreports and I'm planning to start working on them after
wheezy release.
Personally, I'm not yet convinced about this interpreter
Hello,
On Thu, 18 Apr 2013 22:13:04 +0400
Sergei Golovan sgolo...@debian.org wrote:
To Sergei (added to Cc): I'd like to join the effort in packaging
Tcl/Tk and stuff, as I said before; but as you've been the most
active person on the team for quite some time I'm a bit hesitant
about
On Thu, Apr 18, 2013 at 06:15:26PM +0100, Ian Jackson wrote:
Goswin von Brederlow writes (Re: multiarch and interpreters/runtimes):
Co-installability of interpreters is generally not planed and would
have to be made as custom solutions, i.e. place the interpreter in
/usr/lib/x86_64-linux
Matthias Klose d...@debian.org writes:
There are maybe not many use cases where you do want to install an
interpreter like python or perl for a foreign architecture, but there
are some use case where such a setup makes sense.
One additional use case: I want to be able to do this in order to
. Packages are available in
experimental, but because I didn't backport this to 2.6 and 3.2, not
much useful. Install an Ubuntu raring (13.04) chroot to experiment
with these. Details at http://wiki.debian.org/Python/MultiArch
As I pointed out on the debian-perl mailing list, after having
correct default Config.sh from
multiarch location). And even after that a few things still required
manual patching.
The package history in launchpad has all the debdiffs as usual, and
debian pts should have links to those as well by now ;-)
I'm sure a few things are still missing for the initial
On Thu, Apr 18, 2013 at 04:18:20PM +0100, Neil Williams wrote:
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose d...@debian.org wrote:
- running a gdb:amd64 on i386 to debug 64bit binaries. This is the
reason for our current gdb64 package on i386, but it is missing the
support
Hi, all.
Now, /usr/share/perl5/Dpkg/Shlibs.pm defines default library search path as:
use constant DEFAULT_LIBRARY_PATH =
qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
/emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
and adds multiarch dirs only for crosscompiling
On Tue, Apr 16, 2013 at 7:34 PM, Игорь Пашев wrote:
Now, /usr/share/perl5/Dpkg/Shlibs.pm defines default library search path as:
Sounds like a topic for the debian-dpkg list?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
2013/4/16 Paul Wise p...@debian.org:
On Tue, Apr 16, 2013 at 7:34 PM, Игорь Пашев wrote:
Now, /usr/share/perl5/Dpkg/Shlibs.pm defines default library search path as:
Sounds like a topic for the debian-dpkg list?
No.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
/usr/lib);
and adds multiarch dirs only for crosscompiling:
if ($crossprefix) {
push @crosslibrarypaths, /lib/$multiarch, /usr/lib/$multiarch,
/$crossprefix/lib, /usr/$crossprefix/lib,
/$crossprefix/lib32, /usr/$crossprefix/lib32,
/$crossprefix/lib64
On Tue, 16 Apr 2013, Игорь Пашев wrote:
I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
and put them in first positions.
Why?
This modules tries to mimick ld.so's logic to find libraries as closely
as possible.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get
2013/4/16 Raphael Hertzog hert...@debian.org:
On Tue, 16 Apr 2013, Игорь Пашев wrote:
I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
and put them in first positions.
Why?
This modules tries to mimick ld.so's logic to find libraries as closely
as possible.
/lib
On Tue, 16 Apr 2013 16:11:24 +0400
Игорь Пашев pashev.i...@gmail.com wrote:
2013/4/16 Raphael Hertzog hert...@debian.org:
On Tue, 16 Apr 2013, Игорь Пашев wrote:
I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
and put them in first positions.
Why
against the built binaries for the current architecture of the
current build.
The shared library libfoo.so.1.2.3 lives in /usr/lib/$triplet for
runtime usage but the -dev package which provides the .so symlink which
is used to find the actual .so.N.N.N file is not necessarily in a
MultiArch path
On 16 April 2013 13:29, Neil Williams codeh...@debian.org wrote:
On Tue, 16 Apr 2013 16:11:24 +0400
Игорь Пашев pashev.i...@gmail.com wrote:
2013/4/16 Raphael Hertzog hert...@debian.org:
On Tue, 16 Apr 2013, Игорь Пашев wrote:
I think it would be better to add multiarch dirs
+++ Neil Williams [2013-04-16 13:29 +0100]:
On Tue, 16 Apr 2013 16:11:24 +0400
Игорь Пашев pashev.i...@gmail.com wrote:
/lib:/usr/lib was the default path, now it is
/lib/multiarch:/usr/lib/multiarch, isn't it?
No - there's confusion here between the runtime link path and the
build time
+++ Игорь Пашев [2013-04-16 16:49 +0400]:
2013/4/16 Neil Williams codeh...@debian.org:
On Tue, 16 Apr 2013 16:11:24 +0400
So, is it important, that multiarch dirs go after crossdirs:
our @librarypaths = (DEFAULT_LIBRARY_PATH, @crosslibrarypaths);
?
That's actually a rather problematic
On Tue, 16 Apr 2013, Wookey wrote:
So in general it seems like a good idea to me for dpkg shlibs to check
multiarch paths at build time if it doesn't already, because it'll
need to soon. I am of course happy to hear of reasons why that will
break things and we should not do it yet.
All
On 24 January 2013 04:56, Paul Johnson pauljoh...@gmail.com wrote:
This is a multiarch issue I had not considered before. Have you seen
it? I never wanted to be a cross compiler, I really only want to
build amd64. But I have some i386 libraries for a particular program
(acroread).
I
Paul Johnson pauljohn32 at gmail.com writes:
I've just learned that, if I build amd64 packages, I can't install
them for testing because I've not also built the i386 packages.
Just test in cowbuilder --login.
That's really inconvenient! I don't understand why there has to be a
linkage
This is a multiarch issue I had not considered before. Have you seen
it? I never wanted to be a cross compiler, I really only want to
build amd64. But I have some i386 libraries for a particular program
(acroread).
I've just learned that, if I build amd64 packages, I can't install
them
, leave the
dependencies unresolved, and just run Evince as is to test.
I expect your answer will be yes, it really is that hard, you have to
learn how to compile for i386 too. I'm trying
(http://wiki.debian.org/Multiarch/HOWTO), but not making progress. I'm
like a collection of monkies trying
My previous experiments with multiarch cross-building had run into lots
of build-dependency and tool problems and as a result I hadn't got
arround to actually building anything beyond trivial test programs.
Unfortunately I have now discovered that when I try to link against
some libraries I
Hi Peter,
On Sat, Oct 06, 2012 at 12:28:07AM +0100, peter green wrote:
My previous experiments with multiarch cross-building had run into
lots of build-dependency and tool problems and as a result I hadn't
got arround to actually building anything beyond trivial test
programs.
Unfortunately
Too bad, a personal attack in the first (level of) answer already.
On 2012-08-10 20:22, Steve Langasek wrote:
[...]
... says the man who thinks multiarch should be held up indefinitely because
a perl reimplementation of apt should take precedence.
No, I don't think so. Neither of 'multiarch
Jonathan Nieder dixit:
pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309
Yes, but that was not the main showstopper for pcc.
Besides upstream bugs on some architectures (recently,
even Linux/amd64 broke again – I’m following pcc dev),
the main problem was how to get
On Mon, Jul 23, 2012 at 06:44:58AM -0500, Jonathan Nieder wrote:
Hi,
Goswin von Brederlow wrote:
On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote:
c) Compatibility wrapper. If someone needs this, feel free to email
me and I'll help out however I can.
If you
multiarch. People should work on
implementing a compatibility wrapper and to make upstream toolchain
multiarch aware. Until this is done, this bug should be kept opened.
just do it.
To be realistic, is anyone actually going to do this?
Avenues forward:
a) Help upstream authors
Hi,
Goswin von Brederlow wrote:
On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote:
a) Help upstream authors of toolchain components with hardcoded
header and library search paths to implement multiarch.
[...]
What I don't understand is why compilers (which probably means
Jonathan Nieder jrnie...@gmail.com writes:
Goswin von Brederlow wrote:
What I don't understand is why compilers (which probably means ld
from binutils in all cases) won't use ld.so.conf to find the libs.
It only does so to find libs linked into libs you link against. So
it is used
affects 637232 + release-notes
quit
Hi,
Matthias Klose wrote:
On 08/09/2011 07:31 PM, Aurelien Jarno wrote:
I got fed up by people reporting bug on libc6, while this problem results
from a decision Debian to implement multiarch. People should work on
implementing a compatibility wrapper
Processing commands for cont...@bugs.debian.org:
affects 637232 + release-notes
Bug #637232 [general] general: Multiarch breaks support for non-multiarch
toolchain
Bug #639214 [general] eglibc: changes to paths concerning crt1.o, crti.o and
crtn.o breaks building LLVM Trunk
Bug #644986
On Thu, Jun 14, 2012 at 09:22:43PM -0700, Russ Allbery wrote:
Theodore Ts'o ty...@mit.edu writes:
If a required package (such as e2fslibs, which is required by e2fsprogs)
provides multiarch support, then Lintian requires that the package have
a dependency on the package multiarch-support
If a required package (such as e2fslibs, which is required by e2fsprogs)
provides multiarch support, then Lintian requires that the package have
a dependency on the package multiarch-support[1].
However, this causes debcheck to complain because you now have a
required package depending
Theodore Ts'o ty...@mit.edu writes:
If a required package (such as e2fslibs, which is required by e2fsprogs)
provides multiarch support, then Lintian requires that the package have
a dependency on the package multiarch-support[1].
However, this causes debcheck to complain because you now
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Goswin von Brederlow writes (Re: Bug#664257: multiarch tuples are not
documented/defined):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
What change to the Debian operating system, or to processes,
documents, infrastructure
reassign 664257 debian-policy 3.9.3.1
affects 664257 =
tags 664257 = upstream
quit
Goswin von Brederlow wrote:
It is a bug in Debian: The multiarch tuples are not documented/defined
in Debian.
Fine, reassigning to policy.
Never say I didn't do anything for you... :)
Policy maintainers, see
Processing commands for cont...@bugs.debian.org:
reassign 664257 debian-policy 3.9.3.1
Bug #664257 [general] multiarch tuples are not in the FHS
Bug reassigned from package 'general' to 'debian-policy'.
Ignoring request to alter found versions of bug #664257 to the same values
previously set
Trimming the cc list down to something somewhat less large.
Jonathan Nieder jrnie...@gmail.com writes:
Goswin von Brederlow wrote:
It is a bug in Debian: The multiarch tuples are not documented/defined
in Debian.
Fine, reassigning to policy.
Never say I didn't do anything for you
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Matthias Klose writes (Bug#664257: multiarch tuples are not
documented/defined):
On 18.04.2012 05:16, Jonathan Nieder wrote:
I think the Multiarch/Tuples wiki page is now in a sane state, though
as always it could presumably be improved
Goswin von Brederlow writes (Re: Bug#664257: multiarch tuples are not
documented/defined):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
What change to the Debian operating system, or to processes,
documents, infrastructure or organisational arrangements, maintained
by the Debian
Matthias Klose writes (Bug#664257: multiarch tuples are not
documented/defined):
On 18.04.2012 05:16, Jonathan Nieder wrote:
I think the Multiarch/Tuples wiki page is now in a sane state, though
as always it could presumably be improved even more. I think future
required improvements can
On 20.04.2012 16:55, Ian Jackson wrote:
Matthias Klose writes (Bug#664257: multiarch tuples are not
documented/defined):
On 18.04.2012 05:16, Jonathan Nieder wrote:
I think the Multiarch/Tuples wiki page is now in a sane state, though
as always it could presumably be improved even more. I
]] Matthias Klose
I won't fight for this. But it's some kind of Debian responsibility to
address/forward these. Just filing this with the FHS and/or LSB is likely
getting ignored. If you have better ways to track progress with this issue,
please tell here.
JFTR, the FHS and the LSB has a
severity 664257 important
thanks
On 18.04.2012 05:16, Jonathan Nieder wrote:
Hi Matthias,
Steve McIntyre wrote:
I've updated http://wiki.debian.org/Multiarch/Tuples with lots more
information such as links to external ABI specs where I could find
them.
I think the Multiarch/Tuples
Processing commands for cont...@bugs.debian.org:
severity 664257 important
Bug #664257 [general] multiarch tuples are not documented/defined
Severity set to 'important' from 'serious'
thanks
Stopping processing here.
Please contact me if you need assistance.
--
664257: http://bugs.debian.org
Processing commands for cont...@bugs.debian.org:
retitle 664257 multiarch tuples are not in the FHS
Bug #664257 [general] multiarch tuples are not documented/defined
Changed Bug title to 'multiarch tuples are not in the FHS' from 'multiarch
tuples are not documented/defined'
tags 664257
Hi Matthias,
Steve McIntyre wrote:
I've updated http://wiki.debian.org/Multiarch/Tuples with lots more
information such as links to external ABI specs where I could find
them.
I think the Multiarch/Tuples wiki page is now in a sane state, though
as always it could presumably be improved even
On Sat, Mar 17, 2012 at 07:03:09AM +0100, Matthias Klose wrote:
Package: general
Severity: serious
Tags: wheezy, sid
While we strive to get multiarch ready for squeeze, there is
currently nothing to point to what the multiarch tuples actually
mean, neither on the Debian side nor on some kind
On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
I would like to do multiarch conversion for the icu packages. I
understand the concept and the implementation, and I have looked at
http://wiki.debian.org/Multiarch/Implementation. One issue not covered
is what to do if your package already
On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
One issue not covered is what to do if your package already builds
32-bit libraries on a 64-bit system by building 32-bit explicitly and
packaging as lib32whatever.
The lib32*
On 2012-03-24 10:50 +0100, Adam Borowski wrote:
On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
One issue not covered is what to do if your package already builds
32-bit libraries on a 64-bit system by building 32-bit explicitly
: ia32-libs ( ver)
Description: ia32-libs-i386 transitional package
That means that ia32-libs in amd64 alone will be uninstallable and users
will have to enable multiarch before they can install or upgrade
ia32-libs. But other than that the upgrade should be smooth.
It makes sense to provide
On Sat, 2012-03-24 at 14:56 +0100, Goswin von Brederlow wrote:
[...]
FYI: Since I have recieved no objections from ftp-master nor the release
team the plan for ia32-libs now looks as follows:
Ia32-libs becomes a transitional package depending on ia32-libs-i386.
ia32-libs-i386 is a new
Ben Hutchings b...@decadent.org.uk writes:
On Sat, 2012-03-24 at 14:56 +0100, Goswin von Brederlow wrote:
[...]
FYI: Since I have recieved no objections from ftp-master nor the release
team the plan for ia32-libs now looks as follows:
Ia32-libs becomes a transitional package depending on
On Sat, 2012-03-24 at 18:37 +0100, Goswin von Brederlow wrote:
Ben Hutchings b...@decadent.org.uk writes:
On Sat, 2012-03-24 at 14:56 +0100, Goswin von Brederlow wrote:
[...]
FYI: Since I have recieved no objections from ftp-master nor the release
team the plan for ia32-libs now looks
Goswin von Brederlow goswin-...@web.de wrote:
Sven Joachim svenj...@gmx.de writes:
On 2012-03-24 10:50 +0100, Adam Borowski wrote:
On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
One issue not covered is what to do if your
Please cc me on replies as I am not presently subscribed to
debian-devel.
I would like to do multiarch conversion for the icu packages. I
understand the concept and the implementation, and I have looked at
http://wiki.debian.org/Multiarch/Implementation. One issue not covered
is what to do
to pin down and document the definition of each multiarch
tuple. Perhaps you read it as a request to pin down and document the
definition of the term multiarch tuple, without necessarily pinning
down the details for each arch.
It would certainly be useful to clarify which is needed before
was giving examples of not what the upstream gcc folks were
looking for? I'm not sure I understand the point of your question.
Ah, maybe this is where we are talking past each other: I read this as
a request to pin down and document the definition of each multiarch
tuple. Perhaps you read
101 - 200 of 907 matches
Mail list logo
