Cyril Brulebois k...@debian.org (06/09/2011):
Can we give dpkg more exposure than “build from git”? It's been 2+
months already since that announcement and one cannot really test
“Multiarch in Debian unstable” as written in the subject.
It's been even more time now, can we please get
On Wed, 07 Sep 2011, Stefano Zacchiroli wrote:
On Tue, Sep 06, 2011 at 09:56:42AM +0200, Cyril Brulebois wrote:
Can we give dpkg more exposure than “build from git”? It's been 2+
months already since that announcement and one cannot really test
“Multiarch in Debian unstable” as written
and one cannot really test
“Multiarch in Debian unstable” as written in the subject.
Thanks for your efforts.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Steve Langasek vor...@debian.org writes:
On Wed, Jun 29, 2011 at 09:53:26AM +0200, Joachim Breitner wrote:
But for now, the resume is that we put it into the sysadminâs hand to
install nss packages for all architectures he thinks his users want to
run binaries on?
Yes, that's the only
On 27 June 2011 20:54, Steve Langasek vor...@debian.org wrote:
Next steps for maintainers
==
If you are a maintainer of a shared library package, you can convert it to
multiarch today following the instructions in the Debian wiki:
Brian May br...@microcomaustralia.com.au writes:
I have converted Heimdal. Correctly I hope! Unfortunately, by uploading
this I will cause short term breakage to other packages. e.g libpam-krb5
debian/rules has:
LDFLAGS=-L/usr/lib/heimdal
If I got this right it now needs to be changed to:
On 7 July 2011 11:44, Russ Allbery r...@debian.org wrote:
Couldn't you leave the *.so links where they are right now and only move
the actual shared libraries? Then packages that are using
heimdal-multidev wouldn't need to change anything.
You mean leave the links in /usr/lib/heimdal/*.so?
Brian May br...@microcomaustralia.com.au writes:
On 7 July 2011 11:44, Russ Allbery r...@debian.org wrote:
Couldn't you leave the *.so links where they are right now and only
move the actual shared libraries? Then packages that are using
heimdal-multidev wouldn't need to change anything.
On Wed, Jun 29, 2011 at 09:53:26AM +0200, Joachim Breitner wrote:
But for now, the resume is that we put it into the sysadmin’s hand to
install nss packages for all architectures he thinks his users want to
run binaries on?
Yes, that's the only option I see at present.
--
Steve Langasek
On Fri, Jul 01, 2011 at 12:48:39AM +0200, Michael Biebl wrote:
Am 29.06.2011 00:39, schrieb Michael Biebl:
Am 28.06.2011 19:56, schrieb Joachim Breitner:
The only nss modules outside of eglibc that *are* available in biarch
today
are nss_ldap, nss_mdns*, nss_myhostname, and
Den 28. juni 2011 19:56, skrev Joachim Breitner:
I tend to agree with Bernhard that it would be nice if it were made easy
for the user (e.g. a user on amd64 who runs some application in wine and
is surprised that the foo.local addresses stop working).
Actually, I think the current status quo
Am 29.06.2011 00:39, schrieb Michael Biebl:
Hi,
Am 28.06.2011 19:56, schrieb Joachim Breitner:
The only nss modules outside of eglibc that *are* available in biarch today
are nss_ldap, nss_mdns*, nss_myhostname, and nss_extrausers.
nss_gw_name would be if the depedency libnl had multilibs
Hi,
Am Dienstag, den 28.06.2011, 23:22 +0100 schrieb Steve Langasek:
I agree it would be nice, but this seems to map to the (long unsolved)
problem of conditional depends - where you want A to pull in B only if C is
also installed. If you solve that, you've got the NSS module question
solved
On 29/06/2011 09:53, Joachim Breitner wrote:
Hi,
Am Dienstag, den 28.06.2011, 23:22 +0100 schrieb Steve Langasek:
I agree it would be nice, but this seems to map to the (long unsolved)
problem of conditional depends - where you want A to pull in B only if C is
also installed. If you solve
Am Montag, 27. Juni 2011, 16:20:23 schrieb Steve Langasek:
So this:
So it should be a matter of changing that to print this instead on Debian
multiarch: $ gcc -print-multi-os-directory
x86_64-linux-gnu
$ gcc -print-multi-os-directory -m32
i486-linux-gnu
would definitely be wrong,
On Tue, Jun 28, 2011 at 01:44:36AM +0200, Adam Borowski wrote:
On Mon, Jun 27, 2011 at 11:54:53AM +0100, Steve Langasek wrote:
Multiarch handling of header files (/usr/include) will require
more per-package attention, because architecture-dependent and
architecture-independent header files
Hi,
Am Montag, den 27.06.2011, 11:54 +0100 schrieb Steve Langasek:
Next steps for maintainers
==
If you are a maintainer of a shared library package, you can convert it to
multiarch today following the instructions in the Debian wiki:
On Tue, Jun 28, 2011 at 02:05:05AM +0200, Vincent Lefevre wrote:
http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html
This particular issue will not occur with multiarch, because /usr/lib/arch
will never be a symlink to /usr/lib in the canonical implementation.
There will be the same
* Steve Langasek vor...@debian.org [110628 08:42]:
On the downside, files which are the same would be duplicated, but since a
vast majority of libraries use #ifdefs instead of modifying the files, the
waste would be infinitessimally low.
I don't know what this vast majority of libraries
On Tue, Jun 28, 2011 at 07:40:03AM +0200, Hendrik Sattler wrote:
Am Montag, 27. Juni 2011, 16:20:23 schrieb Steve Langasek:
So this:
So it should be a matter of changing that to print this instead on Debian
multiarch: $ gcc -print-multi-os-directory
x86_64-linux-gnu
$ gcc
On Tue, Jun 28, 2011 at 10:58:47AM +0200, Joachim Breitner wrote:
Am Montag, den 27.06.2011, 11:54 +0100 schrieb Steve Langasek:
Next steps for maintainers
==
If you are a maintainer of a shared library package, you can convert it to
multiarch today following
On Tue, Jun 28, 2011 at 02:30:51AM +0200, Vincent Lefevre wrote:
On 2011-06-27 15:59:27 +0100, Simon McVittie wrote:
If by fat binaries you mean executables,
No, I meant libraries (the term fat binary is used by the GMP library,
but is here restricted to x86 subarchs).
If by fat
Zitat von Steve Langasek vor...@debian.org:
One question, though:
How are build tools like CMake converted to use Multiarch directories for
the installation rule?
I don't have a generic recipe for converting cmake to install to the
multiarch directory. If someone has one, please add it to
* Steve Langasek vor...@debian.org [110628 00:36]:
Is there anything for nss plugins yet? As plugins for libc one needs to
make sure that if it is installed, it is installed for all installed libcs.
With bi-arch/multilib one can get there by just having it compiled for all
possible
On 2011-06-28 09:54:34 +0100, Steve Langasek wrote:
On Tue, Jun 28, 2011 at 02:05:05AM +0200, Vincent Lefevre wrote:
http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html
This particular issue will not occur with multiarch, because
/usr/lib/arch will never be a symlink to /usr/lib in
On 2011-06-28 10:34:14 +0100, Steve Langasek wrote:
On Tue, Jun 28, 2011 at 07:40:03AM +0200, Hendrik Sattler wrote:
Am Montag, 27. Juni 2011, 16:20:23 schrieb Steve Langasek:
So this:
So it should be a matter of changing that to print this instead on
Debian
multiarch: $ gcc
On Tue, Jun 28, 2011 at 03:19:27PM +0200, Bernhard R. Link wrote:
* Steve Langasek vor...@debian.org [110628 00:36]:
Is there anything for nss plugins yet? As plugins for libc one needs to
make sure that if it is installed, it is installed for all installed
libcs.
With
Hi,
Am Dienstag, den 28.06.2011, 15:32 +0100 schrieb Steve Langasek:
No special handling has been proposed for nss modules beyond
that - though this is already a substantial improvement over the status
quo,
where about half our nss modules have biarch versions available and the
On Tue, Jun 28, 2011 at 07:56:42PM +0200, Joachim Breitner wrote:
libnss-myhostname and libnss-extrausers ship the biarch versions of the
module in the same package. libnss_mdns builds a separate lib32nss-mdns
biarch package, and biarch libnss_ldap is only available in ia32-libs. So
Hi,
Am 28.06.2011 19:56, schrieb Joachim Breitner:
The only nss modules outside of eglibc that *are* available in biarch today
are nss_ldap, nss_mdns*, nss_myhostname, and nss_extrausers.
nss_gw_name would be if the depedency libnl had multilibs support.
I'll be happy to take patches for
On 06/27/2011 01:54 PM, Steve Langasek wrote:
currently the only authoritative way to get the multiarch path for a system
is by calling dpkg-architecture, so many of these patches are not yet
upstreamable; with the result that some upstream projects now have a hard
time building on Debian
Hello,
2011/6/27 Török Edwin edwinto...@gmail.com:
I think gcc already provides a way to find out the multiarch directory, so it
should be only a matter of patching gcc.
Please try not to confuse multiarch with multilibs.
There is also multiarch designation for sparc machines so they use
Hi,
On 2011-06-27 11:54:53 +0100, Steve Langasek wrote:
Work is ongoing to formulate a proper, distribution-neutral interface for
querying the correct multiarch path for a system. In the meantime, if you
are an upstream affected by this issue, or a maintainer of a package whose
upstream is
On Mon, Jun 27, 2011 at 12:16:41PM +, Hector Oron wrote:
2011/6/27 Török Edwin edwinto...@gmail.com:
I think gcc already provides a way to find out the multiarch directory,
so it should be only a matter of patching gcc.
Please try not to confuse multiarch with multilibs.
What multilib
On Mon, Jun 27, 2011 at 03:06:10PM +0300, Török Edwin wrote:
On 06/27/2011 01:54 PM, Steve Langasek wrote:
currently the only authoritative way to get the multiarch path for a system
is by calling dpkg-architecture, so many of these patches are not yet
upstreamable; with the result that
On Mon, Jun 27, 2011 at 03:31:24PM +0200, Vincent Lefevre wrote:
On 2011-06-27 11:54:53 +0100, Steve Langasek wrote:
Work is ongoing to formulate a proper, distribution-neutral interface for
querying the correct multiarch path for a system. In the meantime, if you
are an upstream affected
On Mon, 27 Jun 2011 at 15:31:24 +0200, Vincent Lefevre wrote:
Related to that, will Linux support fat binaries[*] one day?
I doubt it; but multiarch doesn't make them any more problematic.
If this is possible, where should they be installed, and how
libraries would be searched in a consistent
* Steve Langasek vor...@debian.org [110627 13:00]:
http://wiki.debian.org/Multiarch/Implementation
If you have any questions about the multiarchification of libraries, please
don't hesitate to ask on debian-devel@lists.debian.org.
Is there anything for nss plugins yet? As plugins for libc
On Mon, Jun 27, 2011 at 03:19:53PM +0200, Adam Borowski wrote:
[...]
Before the conversion of amd64 -m32 to i386, and sparc -m64 to sparc64, it
could keep using biarch paths for the time being but provide the correct
multiarch one when no -m is specified.
Otherwise, it produces oh so useful:
On Mon, Jun 27, 2011 at 06:31:19PM +0200, Bernhard R. Link wrote:
* Steve Langasek vor...@debian.org [110627 13:00]:
http://wiki.debian.org/Multiarch/Implementation
If you have any questions about the multiarchification of libraries, please
don't hesitate to ask on
On Mon, Jun 27, 2011 at 11:54:53AM +0100, Steve Langasek wrote:
Multiarch handling of header files (/usr/include) will require
more per-package attention, because architecture-dependent and
architecture-independent header files are currently mixed together in a
single directory and we probably
On 2011-06-27 15:42:47 +0100, Steve Langasek wrote:
On Mon, Jun 27, 2011 at 03:31:24PM +0200, Vincent Lefevre wrote:
How libraries are searched is not clear, but depending on how this
is done, there may be compatibility issues when the user installs
software in his home directory, in case
On 2011-06-27 15:59:27 +0100, Simon McVittie wrote:
If by fat binaries you mean executables,
No, I meant libraries (the term fat binary is used by the GMP library,
but is here restricted to x86 subarchs).
If by fat binaries you mean shared libraries, they could either go in
/usr/lib, or go in
43 matches
Mail list logo
