Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
On Mon, 2006-02-20 at 02:23 -0800, Steve Langasek wrote: > If there's > consensus that putting this stuff in /usr/lib32 on amd64 is prettier than > /emul/ia32-linux, I see no reason not to move forward. My sense is that the "concensus" that exists is around FHS compliance. While I personally consider /usr/lib32 pretty ugly, I am sensitive to the fact that we have always tried to be FHS compliant in Debian. I'm willing to consider a cluefully constructed patch. Looking over the open bug reports, it's well past time for another general update of ia32-libs. I'll try to make time for it this week. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
On Tue, 2006-02-21 at 07:10 +0100, Aurelien Jarno wrote: > Moving 32-bit libraries to (/usr)/lib32 won't make the amd64 port > compliant with the FHS, which is almost impossible given the current > setup, ie 64-bit libraries in /lib. However, it would make it compliant > with the part of the FHS which says that alternative libraries have to > be in (/usr)/lib. And it would make us compatible with other > distributions like Gentoo or Ubuntu that have choosen to use (/usr)/lib32. What sort of value should we assign to achieving that level of "compatibility" with other distributions before multiarch, where I expect us to be in the lead and others to be trying to figure out if/how to be compatible with Debian? Part of the reason I'm unhappy about the current FHS situation is that seems generally to get defined as "32" or "64" and the definition of what belongs in the unqualified version of the directories feels inconsistent across architectures. Part of what I like about our multiarch strategy is generalizing this to handle more "interesting" cases like emulated execution environments, etc. The world just isn't as simple as 32 vs 64 implies... I'm inclined to make as few "structural changes" to ia32-libs as possible pending multiarch implementation. The reason is that anything we change is going to make work for people, including work we can't anticipate or judge the scale of, like users who have laboriously worked to manually install additional libraries on their systems. If we're going to put people through a transition process, I'd prefer it be the transition to multiarch! So, can we achieve any useful cross-distro compatibility results with clueful application of an additional symlink or three? Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote: > The only change planned is to make libc6-dev-i386 and libc6-i386 provide > a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I > still have to find how to do that cleanly in the debhelper files). > > Bdale, do you agree with such a change? Yes, I think we can handle that. It means some small work on ia32-libs to stop delivering any conflicting files, but I'm sure we can work that out easily enough. If you want to provide me a patch for ia32-libs that does what you want it to do, that would be welcome. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
subscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.3.1-6
[EMAIL PROTECTED] (Jeff Bailey) writes: > I would like to hear from some other arch's about how -6 is working for > them. My build of your updated -6 sources on ia64 completed successfully. For what it's worth, these were the start and end times of the pbuilder run on an HP rx2600 dual 900Mhz Itanium 2, running sid and mostly idle otherwise: Current time: Fri Dec 20 09:57:53 MST 2002 Current time: Fri Dec 20 10:40:18 MST 2002 The resulting binary packages are installed and working in the main root of the machine in question. So far, so good. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bad {MIN}SIGSTKSZ on debian glibc-2.2.5-14.3
I don't know anything about this header file offhand... Could someone
investigate and give us an answer, please?
Bdale, at Linux Conf Australia this week
From: David Mosberger <[EMAIL PROTECTED]>
Subject: [ia64 R&D] bad {MIN}SIGSTKSZ on debian glibc-2.2.5-14.3
It appears that Debian/stable ships with a stale header file:
/usr/include/bits/sigstack.h, contains:
#define MINSIGSTKSZ 2048
#define SIGSTKSZ8192
These values are far too small and should be replaced with:
#define MINSIGSTKSZ 131027
#define SIGSTKSZ262144
I think this headerfile has been corrected for "unstable" already, but
since this is effectively an ABI-change, it would be good to fix it in
"stable" too.
Can do?
--david
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.3.1-6
[EMAIL PROTECTED] (Jeff Bailey) writes: > I would like to hear from some other arch's about how -6 is working for > them. My build of your updated -6 sources on ia64 completed successfully. For what it's worth, these were the start and end times of the pbuilder run on an HP rx2600 dual 900Mhz Itanium 2, running sid and mostly idle otherwise: Current time: Fri Dec 20 09:57:53 MST 2002 Current time: Fri Dec 20 10:40:18 MST 2002 The resulting binary packages are installed and working in the main root of the machine in question. So far, so good. Bdale
Bug#54172: LOG_NTP facility for syslog()?
Package: libc6-dev Severity: wishlist It would really be nice to have a LOG_NTP facility defined for syslog(). I don't know what it would take to get this included in libc6 and properly handled by the syslogd we ship with Debian, but it exists on other OS's, and ntpd output would be nice to be able to direct to somewhere other than daemon.log by default. Bdale
