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 li
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 n
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
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)
> >
> > d
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 determi
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 po
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/
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 i
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
Excerpts from Raphael Hertzog's message of Tue Aug 02 20:43:21 +0200 2011:
> reopen 636352
> severity 636352 wishlist
> retitle 636352 dpkg: provide a way to query the multiarch path component
> without dpkg-dev
> thanks
>
> On Tue, 02 Aug 2011, Michal Suchanek wrote:
> > Also you can have librar
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.con
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 surely
>> include both.
>
> Sorry I have been a bit quick to close the report. But
Processing commands for cont...@bugs.debian.org:
> reopen 636352
Bug #636352 {Done: Raphael Hertzog } [dpkg] dpkg: no option
to deretmine multiarch architecture
> severity 636352 wishlist
Bug #636352 [dpkg] dpkg: no option to deretmine multiarch architecture
Severity set to 'wishlist' from 'norma
reopen 636352
severity 636352 wishlist
retitle 636352 dpkg: provide a way to query the multiarch path component
without dpkg-dev
thanks
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
Package: dpkg
Version: 1.16.0.3
Severity: normal
Since libraries are allowed to install in
/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH) and it is necessary to
pick libnss_dns.so.* from there to have DNS lookup working in initramfs
dpkg-architecture from dpkg-dev (and hence build-essintials) is
15 matches
Mail list logo
