Excerpts from Jonathan Nieder's message of Tue Aug 02 21:01:34 +0200 2011:
Hi,
Raphael Hertzog wrote:
On Tue, 02 Aug 2011, Michal Suchanek wrote:
Also you can have libraries for *both* subarchs and there is no way to
tell on what arch you are actually running, /etc/ld.so.conf will
On Wed, 03 Aug 2011, Michal Suchanek wrote:
It's also unlikely to be quickly fixed at this point. It would basically
require to rewrite a large part of dpkg-architecture in C.
Why the need to rewrite it?
Because we don't want the dpkg package to depend on perl. (But for
dpkg-dev it's fine)
Excerpts from Raphael Hertzog's message of Wed Aug 03 11:25:37 +0200 2011:
On Wed, 03 Aug 2011, Michal Suchanek wrote:
It's also unlikely to be quickly fixed at this point. It would basically
require to rewrite a large part of dpkg-architecture in C.
Why the need to rewrite it?
Michal Suchanek wrote:
It's possible to take some random binary which is likely to be native
(eg. /bin/sh), run ldd on it, and parse the output to determine what
libc is actually used.
But that's the point. Which libc is used depends on the binary.
/bin/sh might be an i386 binary and /bin/ls
Excerpts from Jonathan Nieder's message of Wed Aug 03 12:54:12 +0200 2011:
Michal Suchanek wrote:
It's possible to take some random binary which is likely to be native
(eg. /bin/sh), run ldd on it, and parse the output to determine what
libc is actually used.
But that's the point.
On 2011-08-03 13:11 +0200, Michal Suchanek wrote:
Excerpts from Jonathan Nieder's message of Wed Aug 03 12:54:12 +0200 2011:
Michal Suchanek wrote:
It's possible to take some random binary which is likely to be native
(eg. /bin/sh), run ldd on it, and parse the output to determine what
Hi!
On Wed, 2011-08-03 at 11:25:37 +0200, Raphael Hertzog wrote:
On Wed, 03 Aug 2011, Michal Suchanek wrote:
Note that if your package is arch: any, you can embed the multiarch
path in your package at build time. (This is currently not the case for
initramfs-tools)
dpkg is arch:any
Hi!
On Sat, 2011-07-30 at 08:15:38 -0400, Nicolas Stransky wrote:
On 07/30/2011 04:02 AM, Raphael Hertzog wrote:
On Fri, 29 Jul 2011, Nicolas STRANSKY wrote:
Simplistic tests involving tar show that the disk is able to produce
throughputs that are about 30x higher than the ones I observe when
On Wed, 03 Aug 2011, Guillem Jover wrote:
I understand it's annoying to not have dpkg-architecture around for
maintainer scripts. And duplication is not really desirable, but then
those packages do not really need any kind of table nor mapping, just the
matching multiarch triplet, which is
Excerpts from Raphael Hertzog's message of Wed Aug 03 14:32:42 +0200 2011:
On Wed, 03 Aug 2011, Guillem Jover wrote:
I understand it's annoying to not have dpkg-architecture around for
maintainer scripts. And duplication is not really desirable, but then
those packages do not really need
Excerpts from Sven Joachim's message of Wed Aug 03 13:58:50 +0200 2011:
On 2011-08-03 13:11 +0200, Michal Suchanek wrote:
Excerpts from Jonathan Nieder's message of Wed Aug 03 12:54:12 +0200 2011:
Michal Suchanek wrote:
It's possible to take some random binary which is likely to be
Raphael,
No offense, but I went through the entire bug, tried the ruby script
which did not work reliably (added duplicate architecture lines and
forgot some), and then I spent 1h trying to fix the file by hand, and
the more errors I fixed, the more dpkg --list would report more a few at
a time.
On Wed, Aug 03, 2011 at 08:46:40AM -0700, Marc MERLIN wrote:
My recommendation is that you provide a post-install that checks the
syntax of /var/lib/dpkg/status|available and fixes the files.
To make your life easier, I tared up my entire /var/lib/dpkg
if you want to see what an old DB looks
13 matches
Mail list logo
