Bug#382175: cleanup this bug
submitter 382175 Branden Robinson <[EMAIL PROTECTED]> thanks On Mon, Aug 14, 2006 at 06:45:08PM +, Brian M. Carlson wrote: > On Sun, Aug 13, 2006 at 10:51:54PM -0400, Branden Robinson wrote: > > On Wed, Aug 09, 2006 at 09:56:53PM +, Brian M. Carlson wrote: > > > I agree. However, I am not willing to keep this bug under my name. As > > > I can be somewhat of a hothead, if this issue is important to you, I > > > suggest that you take the status of submitter. I have instructed > > > control@ to handle that, but it may not work. > > > > > > If you are unwilling to take that on, please reassign it to someone > > > else who is willing, or close the bug. > > > > I don't mind it being assigned to me if Adrian doesn't want it, either. > > That's fine. Would you take it, then? If Adrian wants it > after that, then you and he can argue it out. I haven't heard anything from Adrain since you sent this, so I'll take it for now. > I'm having troubles with the BTS which I am in the process of attempting > to sort out, but I don't expect this message to appear in the bug logs, > for example. Hopefully everything will work again for me within a few > days. Therefore, you may obviously send this message to the bug, if you > desire. Certainly. :) > > > I also was unable to write a replacement as I originally planned (which > > > would have solved the whole debacle), because the documentation is so > > > poor that I could not have possibly reproduced the relevant interfaces > > > correctly. > > > > Well, would you be willing to write a complete description[1] of the RPC > > implementation? That way it can be clean-roomed. > > I would be thrilled to do that. If there is anything special I need to > know (I'm at least vaguely aware of most of the standard procedures), > please do feel free to inform me. Awesome. No, I don't have any specialized knowledge about cleanrooming -- I just think I understand the basic principles. > I presume that I will need to document interfaces and the functionality > of each interface with sufficient detail to allow (as you said) "a > skilled C programmer" who is familiar with RFCs 1831 and 1832 to > reproduce code of equivalent functionality. Right. > I am aware that I should not expose any implementation details, Actually, I am not sure this is true. The classic cleanrooming scenario is when Phoenix Technologies had one team of engineers study the IBM BIOS ROM at the instruction level, and write a specification from that, and then gave that specification to another team of engineers who wrote a work-alike from scratch. It might be wise to avoid documenting implementation details for other reasons, particuarly if you see something egregiously bad in the existing code, like a memory leak or a security vulnerability. Admittedly, it might be easier to repel charges of plagiarism or copyright infringement if implementation details are omitted, especially for simple code which might end up looking nearly identical to the work being reimplmented due to common C idioms. But anything terribly clever implementation-wise could probably reasonably be documented in the specification. > but to what extent is binary compatibility an issue? Is it acceptable to > document the sizes of structures (taking into account 32- and 64-bit > machine differences)? These are good questions. Shooting for binary compatibility is probably desirable, but this is mostly a gut feeling on my part given the overall mission of replacement. I'd be inclined to defer to the programmers actually performing the reimplementation. It might be worthwhile to explicitly set off information like this, as well as any described implementation code, in some prominent way. Note also that'd I'd argue that anything which would break binary compatibility is an interface, whether it's characterized that way by the source code or not. If I can get a glimpse inside of your black box due to structure alignment, for example, then that part of your box is not black. :) > I also should not discuss implementation details or any other > "privileged" information with any potential reimplementor. I would not disclose things like extensive comment literals, names of symbols that are hidden to the library's users, or unreachable code. If there is a long comment that is important to understanding the code, it would be necessary to rewrite it, I would think. > If someone can provide a good online reference, or even a book that the > University of Houston or Houston Public Library is likely to have, then > I can educate myself before I start working. The only thing I know of is: Warden, R. (1992). Software
Bug#382175: cleanup this bug
On Wed, Aug 09, 2006 at 09:56:53PM +, Brian M. Carlson wrote: > On Wed, Aug 09, 2006 at 01:54:40PM +0200, Adrian Bunk wrote: > > - archived bug #181493 already tried to handle the Sun RPC without any > > result > > it seems there was a big discussion whether the licence could be > > interpreted in a way that it does not fail the DFSG, but the > > only proper solution seems to be tha a Debian developer simply > > contacts Sun asking for clarification and putting this clarification > > in debian/copyright > > I agree. However, I am not willing to keep this bug under my name. As > I can be somewhat of a hothead, if this issue is important to you, I > suggest that you take the status of submitter. I have instructed > control@ to handle that, but it may not work. > > If you are unwilling to take that on, please reassign it to someone > else who is willing, or close the bug. I don't mind it being assigned to me if Adrian doesn't want it, either. > > flamewar -> bug closing -> banning people from [EMAIL PROTECTED] > > why did noone contact Sun and report back instead? > > Because I don't speak for Sun, FSF, or Debian. Due to the recent > concern on -legal about people speaking for the project when there has > been no GR (and therefore no project opinion), I am unwilling to ask. > > I also was unable to write a replacement as I originally planned (which > would have solved the whole debacle), because the documentation is so > poor that I could not have possibly reproduced the relevant interfaces > correctly. Well, would you be willing to write a complete description[1] of the RPC implementation? That way it can be clean-roomed. I've had some dealings with some Sun engineers and engineering managers on the operating systems side of things, and can pursue this further if the time is right for an overture. I don't want to presume the success of the latter, so I think it would be a good idea to identify potential team members for a re-implementation under the LGPL or a GPL-compatible non-copyleft like the MIT/X11 license or 2-clause BSD. > And yes, Branden, I Cc'd you, but this isn't a mailing list, it is a > bug. I will not Cc you further unless instructed otherwise. I do not insist that people honor mail headers that are not present. :) Continuing to CC me is fine, unless I become the submitter, in which case the -submitter address will suffice. [1] "Complete" as in "good enough for a skilled C programmer to reimplement", not as in "good enough to earn the approval of the ISO Secretariat without editing". :) -- G. Branden Robinson| Religious bondage shackles and Debian GNU/Linux | debilitates the mind and unfits it [EMAIL PROTECTED] | for every noble enterprise. http://people.debian.org/~branden/ | -- James Madison signature.asc Description: Digital signature
Bug#343365: libc6: strfry() SEGVs
Package: libc6
Version: 2.3.5-8
Severity: important
When I attempt to use strfry() as documented, it segfaults.
Please see the following attachments:
* my C source code
* my compiled ELF executable
* a transcript of my GDB session
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9-powerpc-smp
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
-- no debconf information
/* cc -Wall -Werror -std=c99 */
#define _GNU_SOURCE /* strfry() */
#include /* printf() */
#include /* malloc() */
#include /* strfry(), strncpy() */
int main(int argc, char **argv) {
char *string;
string = malloc(sizeof(char) * 8);
(void) strncpy(string, "bletch", sizeof(char) * 8);
(void) printf("%s\n", string);
(void) strncpy(string, "greunk", sizeof(char) * 8);
(void) strfry(string);
(void) printf("%s\n", string);
free(string);
return 0;
}
/* vim:set cindent et sts=4 sw=4 tw=80: */
strfry
Description: application/executable
$ gdb ./strfry ./core
GNU gdb 6.3.90_20051119-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".
Core was generated by `./strfry'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/debug/libc.so.6...done.
Loaded symbols for /usr/lib/debug/libc.so.6
Reading symbols from /lib/ld.so.1...Reading symbols from
/usr/lib/debug/lib/ld-2.3.5.so...done.
done.
Loaded symbols for /lib/ld.so.1
#0 __initstate_r (seed=1133653892, arg_state=0xffee50c "", n=32,
buf=0xffee4f0) at random_r.c:252
252 random_r.c: No such file or directory.
in random_r.c
(gdb) bt full
#0 __initstate_r (seed=1133653892, arg_state=0xffee50c "", n=32,
buf=0xffee4f0) at random_r.c:252
type = 1133648766
degree = 33618226
separation = 4146
state = (int32_t *) 0xffee4f0
old_type = 0
old_state = (int32_t *) 0x0
#1 0x0ff3a8e8 in strfry (string=0x18a4 "bletch") at strfry.c:35
state = '\0'
init = 0
rdata = {fptr = 0x0, rptr = 0x0, state = 0x0, rand_type = 0, rand_deg =
0, rand_sep = 0, end_ptr = 0x0}
i = 268362992
#2 0x14c8 in main (argc=1, argv=0x73d4) at strfry.c:14
string = 0x18a4 "bletch"
(gdb) quit
Bug#267205: libc6-dev: /usr/include/gnu/stubs.h uses non-portable whitespace
reassign 267205 xutils retitle 267205 xutils: [makedepend] spuriously complains about standards-compliant whitespace being non-portable tag 267205 = upstream thanks On Mon, Aug 23, 2004 at 05:01:12PM +0900, GOTO Masanori wrote: > Falk Hueffner wrote: > > The C standard does not require this, nor does any cpp in the real > > world for 10 years, so IMHO you should rather fix makedepend. > > Correct. ISO C99 6.10 Preprocessing directives, Description: > > A preprocessing directive consists of a sequence of > preprocessing tokens that begins with a # preprocessing token > that (at the start of translation phase 4) is either the first > character in the source file (optionally after white space > containing no new-line characters) or that follows white space > containing at least one new-line character, and is ended by > the next new-line character.129) > > It's not even bug. Branden, are you OK to reassign this report to > X11, or to close it? On Wed, Aug 25, 2004 at 01:46:25PM +0900, GOTO Masanori wrote: > At Tue, 24 Aug 2004 15:40:23 +0200, > Falk Hueffner wrote: > > [Christoph Hellwig wrote:] > > > Also #error is a GNU extension anyway > > Even if #error is an extension, the directive syntax should be > confirmed with the above mention. > > > No, it's not. > > Falk is also correct. ISO C99 6.10 Preprocessing directives, Syntax: > > control-line: > # include pp-tokens new-line > ... > # error pp-tokens_opt new-line I am reassigning this bug. Thanks for the citations. :) There are situations where being standards-compliant and portable are conflicting aims, but I don't think this is one of them, at least for the Debian system. -- G. Branden Robinson|There is no housing shortage in Debian GNU/Linux |Lincoln today -- just a rumor that [EMAIL PROTECTED] |is put about by people who have http://people.debian.org/~branden/ |nowhere to live.-- G. L. Murfin signature.asc Description: Digital signature
Bug#267205: libc6-dev: /usr/include/gnu/stubs.h uses non-portable whitespace
Package: libc6-dev Version: 2.3.2.ds1-16 Severity: normal File: /usr/include/gnu/stubs.h This file uses non-portable whitespace, to wit: #ifdef _LIBC #error Applications may not define the macro _LIBC #endif The leading space before the hash mark is not correct. # error Applications may not define the macro _LIBC would be better (and portable). This causes tools like X11's "makedepend" script to howl. A lot. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.4.25-powerpc-smp Locale: LANG=C, LC_CTYPE=en_US.UTF-8 Versions of packages libc6-dev depends on: ii libc62.3.2.ds1-16GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-17 Linux Kernel Headers for developme -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265163: locales: locale.alias aliases some names to unsupported locales
Package: locales
Version: 2.3.2.ds1-15
Severity: normal
Tags: upstream
Some of the locale aliases in /etc/locale.alias map names to unsupported
locales. Namely, "eucJP" and "eucKR" aren't spelled correctly per
/usr/share/i18n/SUPPORTED, and the "SJIS" codeset isn't supported at all.
I'm attaching two files:
* A Python script I wrote that found this problem.
* A patch to correct the problem. I corrected all but one problem; I had
to drop the alias for "japanese.sjis", as adding support for the SJIS
character set to glibc is beyond my ability, and I don't even know if
that's a desirable solution.
Thanks for looking into this.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.4.25-powerpc-smp
Locale: LANG=C, LC_CTYPE=en_US.UTF-8
Versions of packages locales depends on:
ii debconf 1.4.30 Debian configuration management sy
ii libc6 [glibc-2.3.2.ds1-15] 2.3.2.ds1-15 GNU C Library: Shared libraries an
-- debconf information:
* locales/default_environment_locale: None
* locales/locales_to_be_generated: en_US ISO-8859-1, en_US.ISO-8859-15 ISO-8859-15,
en_US.UTF-8 UTF-8
#!/usr/bin/python
import os
import re
RUNTIME_DEBUG = True
# Build a dictionary of canonical locales according to the GNU C library. The
# keys in this dictionary are the locale names, and the values are the character
# sets used by each locale name.
glibc_locales_canonical = { }
glibc_locale_file = open(os.path.join("/", "usr", "share", "i18n", "SUPPORTED"))
for line in glibc_locale_file.readlines():
(left_side, right_side) = re.split(r'\s', line, 1)
glibc_locales_canonical[(left_side.strip())] = right_side.strip()
glibc_locale_file.close()
if RUNTIME_DEBUG:
print "Canonical glibc locales: %s" % (glibc_locales_canonical.keys(),)
glibc_locales_aliased = { }
glibc_alias_file = open(os.path.join("/", "etc", "locale.alias"))
for line in glibc_alias_file.readlines():
# Ignore blank lines and lines beginning with a comment character.
# beginning with "XCOMM".
if re.match(r'$', line) \
or re.match(r'#', line):
continue
(left_side, right_side) = re.split(r'\s', line, 1)
glibc_locales_aliased[(left_side.strip())] = right_side.strip()
# glibc is a little weird; it aliases names to locale specifications
# *including* the codeset, whereas it omits the codeset from the officially
# supported list except when necessary for disambiguation purposes.
# Consequently, if we don't find the alias's target in the canonical list,
# we have to fall back to seeing if it is in the canonical list using the
# same codeset that is explicitly stated.
if right_side.strip() not in glibc_locales_canonical.keys():
# Try harder to find it.
goal_locale = right_side.strip()
found = False
for locale in glibc_locales_canonical.keys():
if not re.match(r'\.', locale):
locale_with_codeset = '.'.join([ locale,
glibc_locales_canonical[locale] ])
if goal_locale == locale_with_codeset:
found = True
break
if not found:
print "Warning: glibc bug: glibc locale %s is aliased to" \
" non-canonical glibc locale %s" \
% (left_side.strip(), right_side.strip())
glibc_alias_file.close()
if RUNTIME_DEBUG:
print "Aliased glibc locales: %s" % (glibc_locales_aliased.keys(),)
# vim:set ai et sts=4 sw=4 tw=80:
--- /etc/locale.alias.dpkg-dist 2004-08-11 19:15:44.0 -0500
+++ /etc/locale.alias 2004-08-11 19:17:57.0 -0500
@@ -49,14 +49,13 @@
hungarian hu_HU.ISO-8859-2
icelandic is_IS.ISO-8859-1
italian it_IT.ISO-8859-1
-japanese ja_JP.eucJP
-japanese.euc ja_JP.eucJP
-ja_JP ja_JP.eucJP
-ja_JP.ujis ja_JP.eucJP
-japanese.sjis ja_JP.SJIS
-korean ko_KR.eucKR
-korean.euc ko_KR.eucKR
-ko_KR ko_KR.eucKR
+japanese ja_JP.EUC-JP
+japanese.euc ja_JP.EUC-JP
+ja_JP ja_JP.EUC-JP
+ja_JP.ujis ja_JP.EUC-JP
+korean ko_KR.EUC-KR
+korean.euc ko_KR.EUC-KR
+ko_KR ko_KR.EUC-KR
lithuanian lt_LT.ISO-8859-13
norwegian no_NO.ISO-8859-1
nynorsknn_NO.ISO-8859-1
Bug#235876: glibc: patch for backtrace support on ia64 and x86-64
Package: glibc Severity: normal This patch depends on the patch referenced in #235870 being applied to gcc-3.3 to provide the desired functionality[1], but doesn't break compilation or anything if that is not done. Please apply the following patches to glibc to enable backtrace support on ia64 and x86-64. http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/sysdeps/ia64/backtrace.c?rev=1.1&content-type=text/plain&cvsroot=glibc http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/sysdeps/x86_64/backtrace.c?rev=1.1&content-type=text/plain&cvsroot=glibc http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/unwind.h.diff?r1=1.3&r2=1.4&cvsroot=glibc [1] http://sources.redhat.com/ml/libc-hacker/2003-10/msg8.html (and succeeding messages in the thread) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.20-586tsc Locale: LANG=C, LC_CTYPE=en_US.UTF-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#220814: Is this bug an l-k-h problem?
On Sat, Jan 03, 2004 at 01:46:51PM -0500, Daniel Jacobowitz wrote: > I'm a bit confused by the bug log. Is this a bug in > linux-kernel-headers, and if so, could you give me a testcase for it? James Troup is one who asserted that it was a bug in linux-kernel-headers. I took his word for it. > Or was it just an incompatibility that X has been updated to work > around? It looks like X tries to work around it, but fails. -- G. Branden Robinson|America is at that awkward stage. Debian GNU/Linux |It's too late to work within the [EMAIL PROTECTED] |system, but too early to shoot the http://people.debian.org/~branden/ |bastards. -- Claire Wolfe signature.asc Description: Digital signature
Bug#220814: Is this bug an l-k-h problem?
On Sat, Jan 03, 2004 at 01:46:51PM -0500, Daniel Jacobowitz wrote: > I'm a bit confused by the bug log. Is this a bug in > linux-kernel-headers, and if so, could you give me a testcase for it? James Troup is one who asserted that it was a bug in linux-kernel-headers. I took his word for it. > Or was it just an incompatibility that X has been updated to work > around? It looks like X tries to work around it, but fails. -- G. Branden Robinson|America is at that awkward stage. Debian GNU/Linux |It's too late to work within the [EMAIL PROTECTED] |system, but too early to shoot the http://people.debian.org/~branden/ |bastards. -- Claire Wolfe signature.asc Description: Digital signature
Re: Bug#219714: xfree86: FTBFS on i386: lnx_io.c: structure has no member named `rate'
On Sat, Nov 08, 2003 at 02:00:19PM +0100, Michel Dänzer wrote: > The new linux-kernel-headers. I tend to consider this incompatible > change a bug in them, however current XFree86 CVS works around it, this > patch is all that should be needed. /me grumbles loudly at the Linux kernel and GNU C Library people. Thanks, Michel! -- G. Branden Robinson| Intellectual property is neither Debian GNU/Linux | intellectual nor property. [EMAIL PROTECTED] | Discuss. http://people.debian.org/~branden/ | -- Linda Richman signature.asc Description: Digital signature
Re: Bug#219714: xfree86: FTBFS on i386: lnx_io.c: structure has no member named `rate'
On Sat, Nov 08, 2003 at 02:00:19PM +0100, Michel Dänzer wrote: > The new linux-kernel-headers. I tend to consider this incompatible > change a bug in them, however current XFree86 CVS works around it, this > patch is all that should be needed. /me grumbles loudly at the Linux kernel and GNU C Library people. Thanks, Michel! -- G. Branden Robinson| Intellectual property is neither Debian GNU/Linux | intellectual nor property. [EMAIL PROTECTED] | Discuss. http://people.debian.org/~branden/ | -- Linda Richman signature.asc Description: Digital signature
Bug#215779: libc6: ld.so(8) does not document LD_ASSUME_KERNEL variable
Package: libc6 Version: 2.3.2-7 Severity: normal File: /usr/share/man/man8/ld.so.8.gz It might good to document how this doodad works especially given its new important with respect to LinuxThreads vs. NPTL issues. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux zuul.progeny.com 2.4.20-586tsc #1 Mon Feb 10 11:12:41 EST 2003 i686 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information
Bug#215779: libc6: ld.so(8) does not document LD_ASSUME_KERNEL variable
Package: libc6 Version: 2.3.2-7 Severity: normal File: /usr/share/man/man8/ld.so.8.gz It might good to document how this doodad works especially given its new important with respect to LinuxThreads vs. NPTL issues. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux zuul.progeny.com 2.4.20-586tsc #1 Mon Feb 10 11:12:41 EST 2003 i686 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[nptl branch] latest NPTL diffs
The changes are getting pretty minimal now. * glibc-package/debian/rules.d/control.mk: Pull the architecture-specific package names of the C shared library package into a variable; expand that variable in $(control_deps), and clean the corresponding control files generated during the build process. * glibc-package/debian/sysdeps/ia64.mk: Enable NPTL build on ia64. (Jeff Bailey and I both know this isn't being committed right now due to kernel issues on his IA-64 machine, but he implied I should keep passing it along as a reminder that it needs to be committed eventually.) -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB Index: glibc-package/debian/rules.d/control.mk === RCS file: /cvs/glibc/glibc-package/debian/rules.d/control.mk,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 control.mk --- glibc-package/debian/rules.d/control.mk 2 Oct 2003 16:14:08 - 1.8.2.2 +++ glibc-package/debian/rules.d/control.mk 2 Oct 2003 23:12:35 - @@ -1,4 +1,6 @@ -control_deps := $(addprefix debian/control.in/, libc6 libc6.1 libc0.3 libc1 sparc64 s390x opt) +libc_shlib_names = libc6 libc6.1 libc0.3 libc1 + +control_deps := $(addprefix debian/control.in/, $(libc_shlib_names) sparc64 s390x opt) threads_archs := alpha arm i386 m68k mips mipsel powerpc sparc ia64 hppa s390 sh3 sh4 sh3eb sh4eb freebsd-i386 @@ -29,3 +31,6 @@ sed -e '[EMAIL PROTECTED]@%$(libc)%g;[EMAIL PROTECTED]@%glibc%g' \ -e '[EMAIL PROTECTED]@%$(threads_archs)%g' < [EMAIL PROTECTED] > $@ rm [EMAIL PROTECTED] + +clean:: + rm -f $(patsubst %,debian/control.in/%,$(libc_shlib_names)) Index: glibc-package/debian/sysdeps/ia64.mk === RCS file: /cvs/glibc/glibc-package/debian/sysdeps/Attic/ia64.mk,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 ia64.mk --- glibc-package/debian/sysdeps/ia64.mk22 Sep 2003 21:20:58 - 1.1.2.1 +++ glibc-package/debian/sysdeps/ia64.mk2 Oct 2003 23:12:35 - @@ -1 +1,3 @@ +GLIBC_PASSES += nptl + libc = libc6.1
[nptl branch] latest NPTL diffs
The changes are getting pretty minimal now. * glibc-package/debian/rules.d/control.mk: Pull the architecture-specific package names of the C shared library package into a variable; expand that variable in $(control_deps), and clean the corresponding control files generated during the build process. * glibc-package/debian/sysdeps/ia64.mk: Enable NPTL build on ia64. (Jeff Bailey and I both know this isn't being committed right now due to kernel issues on his IA-64 machine, but he implied I should keep passing it along as a reminder that it needs to be committed eventually.) -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB Index: glibc-package/debian/rules.d/control.mk === RCS file: /cvs/glibc/glibc-package/debian/rules.d/control.mk,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 control.mk --- glibc-package/debian/rules.d/control.mk 2 Oct 2003 16:14:08 - 1.8.2.2 +++ glibc-package/debian/rules.d/control.mk 2 Oct 2003 23:12:35 - @@ -1,4 +1,6 @@ -control_deps := $(addprefix debian/control.in/, libc6 libc6.1 libc0.3 libc1 sparc64 s390x opt) +libc_shlib_names = libc6 libc6.1 libc0.3 libc1 + +control_deps := $(addprefix debian/control.in/, $(libc_shlib_names) sparc64 s390x opt) threads_archs := alpha arm i386 m68k mips mipsel powerpc sparc ia64 hppa s390 sh3 sh4 sh3eb sh4eb freebsd-i386 @@ -29,3 +31,6 @@ sed -e '[EMAIL PROTECTED]@%$(libc)%g;[EMAIL PROTECTED]@%glibc%g' \ -e '[EMAIL PROTECTED]@%$(threads_archs)%g' < [EMAIL PROTECTED] > $@ rm [EMAIL PROTECTED] + +clean:: + rm -f $(patsubst %,debian/control.in/%,$(libc_shlib_names)) Index: glibc-package/debian/sysdeps/ia64.mk === RCS file: /cvs/glibc/glibc-package/debian/sysdeps/Attic/ia64.mk,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 ia64.mk --- glibc-package/debian/sysdeps/ia64.mk22 Sep 2003 21:20:58 - 1.1.2.1 +++ glibc-package/debian/sysdeps/ia64.mk2 Oct 2003 23:12:35 - @@ -1 +1,3 @@ +GLIBC_PASSES += nptl + libc = libc6.1
[nptl branch] build failure on IA-64 when x86-specific autoconf.h used
As discussed on IRC, linux-kernel-headers/include/linux/autoconf.h contains all kinds of architecture specific settings. If you have an x86-flavored autoconf.h, a build on IA-64 will fail very early. Here's the relevant output: /usr/bin/make -C build-tree/ia64-libc install_root=/root/glibc-2.3.2/debian/tmp-libc install make[1]: Entering directory `/root/glibc-2.3.2/build-tree/ia64-libc' LANGUAGE=C LC_ALL=C; export LANGUAGE LC_ALL; \ /usr/bin/make -r PARALLELMFLAGS="" CVSOPTS="" -C /root/glibc-2.3.2/build-tree/glibc-2.3.2 objdir=`pwd` install make[2]: Entering directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2' /usr/bin/make -C csu subdir_lib make[3]: Entering directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2/csu' make[3]: Leaving directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2/csu' make[3]: Entering directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2/csu' gcc-3.3 ../sysdeps/unix/sysv/linux/init-first.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -fstrict-aliasing -g -pipe -I../include -I. -I/root/glibc-2.3.2/build-tree/ia64-libc/csu -I.. -I../libio -I/root/glibc-2.3.2/build-tree/ia64-libc -I../sysdeps/ia64/elf -I../linuxthreads/sysdeps/unix/sysv/linux/ia64 -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/ia64 -I../sysdeps/unix/sysv/linux/ia64 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ia64/fpu -I../sysdeps/ia64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/lib/gcc-lib/ia64-linux/3.3.2/include -isystem /root/glibc-2.3.2/linux-kernel-headers/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DHAVE_INITFINI -D_ASM_IA64_CURRENT_H -o /root/glibc-2.3.2/build-tree/ia64-libc/csu/init-first.o -MD -MP -MF /root/glibc-2.3.2/build-tree/ia64-libc/csu/init-first.o.dt In file included from /root/glibc-2.3.2/linux-kernel-headers/include/asm/elf.h:14, from ../sysdeps/unix/sysv/linux/ia64/sys/procfs.h:32, from ../linuxthreads_db/proc_service.h:20, from ../linuxthreads_db/thread_dbP.h:7, from ../linuxthreads/descr.h:44, from ../linuxthreads/sysdeps/ia64/tls.h:121, from ../include/tls.h:6, from ../include/link.h:38, from ../include/dlfcn.h:3, from ../sysdeps/generic/ldsodefs.h:32, from ../sysdeps/unix/sysv/linux/ldsodefs.h:25, from ../sysdeps/unix/sysv/linux/ia64/ldsodefs.h:23, from ../sysdeps/unix/sysv/linux/init-first.c:30: /root/glibc-2.3.2/linux-kernel-headers/include/asm/page.h:27:3: #error Unsupported page size! make[3]: *** [/root/glibc-2.3.2/build-tree/ia64-libc/csu/init-first.o] Error 1 make[3]: Leaving directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2/csu' make[2]: *** [csu/subdir_lib] Error 2 make[2]: Leaving directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2' make[1]: *** [install] Error 2 make[1]: Leaving directory `/root/glibc-2.3.2/build-tree/ia64-libc' make: *** [/root/glibc-2.3.2/stamp-dir/install_libc] Error 2 debuild: fatal error at line 456: dpkg-buildpackage failed! If one uses an autoconf.h from an IA-64-specific kernel headers package, the macros that asm/page.h wants to see are defined. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB
[nptl branch] build failure on IA-64 when x86-specific autoconf.h used
As discussed on IRC, linux-kernel-headers/include/linux/autoconf.h contains all kinds of architecture specific settings. If you have an x86-flavored autoconf.h, a build on IA-64 will fail very early. Here's the relevant output: /usr/bin/make -C build-tree/ia64-libc install_root=/root/glibc-2.3.2/debian/tmp-libc install make[1]: Entering directory `/root/glibc-2.3.2/build-tree/ia64-libc' LANGUAGE=C LC_ALL=C; export LANGUAGE LC_ALL; \ /usr/bin/make -r PARALLELMFLAGS="" CVSOPTS="" -C /root/glibc-2.3.2/build-tree/glibc-2.3.2 objdir=`pwd` install make[2]: Entering directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2' /usr/bin/make -C csu subdir_lib make[3]: Entering directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2/csu' make[3]: Leaving directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2/csu' make[3]: Entering directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2/csu' gcc-3.3 ../sysdeps/unix/sysv/linux/init-first.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -fstrict-aliasing -g -pipe -I../include -I. -I/root/glibc-2.3.2/build-tree/ia64-libc/csu -I.. -I../libio -I/root/glibc-2.3.2/build-tree/ia64-libc -I../sysdeps/ia64/elf -I../linuxthreads/sysdeps/unix/sysv/linux/ia64 -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/ia64 -I../sysdeps/unix/sysv/linux/ia64 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ia64/fpu -I../sysdeps/ia64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/lib/gcc-lib/ia64-linux/3.3.2/include -isystem /root/glibc-2.3.2/linux-kernel-headers/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DHAVE_INITFINI -D_ASM_IA64_CURRENT_H -o /root/glibc-2.3.2/build-tree/ia64-libc/csu/init-first.o -MD -MP -MF /root/glibc-2.3.2/build-tree/ia64-libc/csu/init-first.o.dt In file included from /root/glibc-2.3.2/linux-kernel-headers/include/asm/elf.h:14, from ../sysdeps/unix/sysv/linux/ia64/sys/procfs.h:32, from ../linuxthreads_db/proc_service.h:20, from ../linuxthreads_db/thread_dbP.h:7, from ../linuxthreads/descr.h:44, from ../linuxthreads/sysdeps/ia64/tls.h:121, from ../include/tls.h:6, from ../include/link.h:38, from ../include/dlfcn.h:3, from ../sysdeps/generic/ldsodefs.h:32, from ../sysdeps/unix/sysv/linux/ldsodefs.h:25, from ../sysdeps/unix/sysv/linux/ia64/ldsodefs.h:23, from ../sysdeps/unix/sysv/linux/init-first.c:30: /root/glibc-2.3.2/linux-kernel-headers/include/asm/page.h:27:3: #error Unsupported page size! make[3]: *** [/root/glibc-2.3.2/build-tree/ia64-libc/csu/init-first.o] Error 1 make[3]: Leaving directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2/csu' make[2]: *** [csu/subdir_lib] Error 2 make[2]: Leaving directory `/root/glibc-2.3.2/build-tree/glibc-2.3.2' make[1]: *** [install] Error 2 make[1]: Leaving directory `/root/glibc-2.3.2/build-tree/ia64-libc' make: *** [/root/glibc-2.3.2/stamp-dir/install_libc] Error 2 debuild: fatal error at line 456: dpkg-buildpackage failed! If one uses an autoconf.h from an IA-64-specific kernel headers package, the macros that asm/page.h wants to see are defined. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
another patch for the NPTL branch
Attached. * debian/debhelper.in/libc-dev.install: ship the kernel asm and linux headers * debian/debhelper.in/locales.install: more restrictive wildcards so we don't accidentally grab the regular file locale.alias; this makes the binary rule idempotent because dh_link will get confused later * debian/rules.d/debhelper.mk: fix cut-n-paste typo in nptl support list generation for dh_install * debian/sysdeps/ia64.mk: enable NPTL support for IA-64 * debian/debhelper.in/libc-nptl.install: NEW; list of files to install for NPTL support in libc package -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB Index: debian/debhelper.in/libc-dev.install === RCS file: /cvs/glibc/glibc-package/debian/debhelper.in/Attic/libc-dev.install,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 libc-dev.install --- debian/debhelper.in/libc-dev.install27 Sep 2003 21:38:09 - 1.1.2.2 +++ debian/debhelper.in/libc-dev.install2 Oct 2003 16:58:37 - @@ -8,3 +8,5 @@ debian/tmp-libc/usr/lib/*.so usr/lib debian/tmp-libc/usr/include/* usr/include +linux-kernel-headers/include/asm* usr/include +linux-kernel-headers/include/linux usr/include Index: debian/debhelper.in/locales.install === RCS file: /cvs/glibc/glibc-package/debian/debhelper.in/Attic/locales.install,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 locales.install --- debian/debhelper.in/locales.install 27 Sep 2003 21:38:09 - 1.1.2.2 +++ debian/debhelper.in/locales.install 2 Oct 2003 16:58:37 - @@ -1,4 +1,5 @@ -debian/tmp-libc/usr/share/locale/* usr/share/locale +debian/tmp-libc/usr/share/locale/[a-z][a-z] usr/share/locale +debian/tmp-libc/usr/share/locale/[a-z][a-z]_[A-Z][A-Z] usr/share/locale debian/tmp-libc/usr/share/locale/locale.alias etc debian/tmp-libc/usr/share/i18n/* usr/share/i18n debian/local/usr_sbin/locale-gen usr/sbin Index: debian/rules.d/debhelper.mk === RCS file: /cvs/glibc/glibc-package/debian/rules.d/Attic/debhelper.mk,v retrieving revision 1.1.2.7 diff -u -r1.1.2.7 debhelper.mk --- debian/rules.d/debhelper.mk 2 Oct 2003 16:14:08 - 1.1.2.7 +++ debian/rules.d/debhelper.mk 2 Oct 2003 16:58:37 - @@ -65,7 +65,7 @@ # We probably don't care for now. for x in $(NPTL); do \ z=debian/$(libc).install; \ - cat debian/debhelper.in/libc-opt.install >>$$z; \ + cat debian/debhelper.in/libc-nptl.install >>$$z; \ sed -e "s#TMPDIR#debian/tmp-$$x#" -i $$z; \ sed -e "s#DEB_SRCDIR#$(DEB_SRCDIR)#" -i $$z; \ sed -e "s#DESTLIBDIR#tls#" -i $$z; \ Index: debian/sysdeps/ia64.mk === RCS file: /cvs/glibc/glibc-package/debian/sysdeps/Attic/ia64.mk,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 ia64.mk --- debian/sysdeps/ia64.mk 22 Sep 2003 21:20:58 - 1.1.2.1 +++ debian/sysdeps/ia64.mk 2 Oct 2003 16:58:37 - @@ -1 +1,3 @@ +GLIBC_PASSES += nptl + libc = libc6.1 --- /dev/null 2003-09-30 15:01:41.0 -0500 +++ debian/debhelper.in/libc-nptl.install 2003-10-01 16:41:43.0 -0500 @@ -0,0 +1 @@ +debian/tmp-nptl/lib/*.so* lib/nptl
another patch for the NPTL branch
Attached. * debian/debhelper.in/libc-dev.install: ship the kernel asm and linux headers * debian/debhelper.in/locales.install: more restrictive wildcards so we don't accidentally grab the regular file locale.alias; this makes the binary rule idempotent because dh_link will get confused later * debian/rules.d/debhelper.mk: fix cut-n-paste typo in nptl support list generation for dh_install * debian/sysdeps/ia64.mk: enable NPTL support for IA-64 * debian/debhelper.in/libc-nptl.install: NEW; list of files to install for NPTL support in libc package -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB Index: debian/debhelper.in/libc-dev.install === RCS file: /cvs/glibc/glibc-package/debian/debhelper.in/Attic/libc-dev.install,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 libc-dev.install --- debian/debhelper.in/libc-dev.install27 Sep 2003 21:38:09 - 1.1.2.2 +++ debian/debhelper.in/libc-dev.install2 Oct 2003 16:58:37 - @@ -8,3 +8,5 @@ debian/tmp-libc/usr/lib/*.so usr/lib debian/tmp-libc/usr/include/* usr/include +linux-kernel-headers/include/asm* usr/include +linux-kernel-headers/include/linux usr/include Index: debian/debhelper.in/locales.install === RCS file: /cvs/glibc/glibc-package/debian/debhelper.in/Attic/locales.install,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 locales.install --- debian/debhelper.in/locales.install 27 Sep 2003 21:38:09 - 1.1.2.2 +++ debian/debhelper.in/locales.install 2 Oct 2003 16:58:37 - @@ -1,4 +1,5 @@ -debian/tmp-libc/usr/share/locale/* usr/share/locale +debian/tmp-libc/usr/share/locale/[a-z][a-z] usr/share/locale +debian/tmp-libc/usr/share/locale/[a-z][a-z]_[A-Z][A-Z] usr/share/locale debian/tmp-libc/usr/share/locale/locale.alias etc debian/tmp-libc/usr/share/i18n/* usr/share/i18n debian/local/usr_sbin/locale-gen usr/sbin Index: debian/rules.d/debhelper.mk === RCS file: /cvs/glibc/glibc-package/debian/rules.d/Attic/debhelper.mk,v retrieving revision 1.1.2.7 diff -u -r1.1.2.7 debhelper.mk --- debian/rules.d/debhelper.mk 2 Oct 2003 16:14:08 - 1.1.2.7 +++ debian/rules.d/debhelper.mk 2 Oct 2003 16:58:37 - @@ -65,7 +65,7 @@ # We probably don't care for now. for x in $(NPTL); do \ z=debian/$(libc).install; \ - cat debian/debhelper.in/libc-opt.install >>$$z; \ + cat debian/debhelper.in/libc-nptl.install >>$$z; \ sed -e "s#TMPDIR#debian/tmp-$$x#" -i $$z; \ sed -e "s#DEB_SRCDIR#$(DEB_SRCDIR)#" -i $$z; \ sed -e "s#DESTLIBDIR#tls#" -i $$z; \ Index: debian/sysdeps/ia64.mk === RCS file: /cvs/glibc/glibc-package/debian/sysdeps/Attic/ia64.mk,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 ia64.mk --- debian/sysdeps/ia64.mk 22 Sep 2003 21:20:58 - 1.1.2.1 +++ debian/sysdeps/ia64.mk 2 Oct 2003 16:58:37 - @@ -1 +1,3 @@ +GLIBC_PASSES += nptl + libc = libc6.1 --- /dev/null 2003-09-30 15:01:41.0 -0500 +++ debian/debhelper.in/libc-nptl.install 2003-10-01 16:41:43.0 -0500 @@ -0,0 +1 @@ +debian/tmp-nptl/lib/*.so* lib/nptl
updates to NPTL branch in Debian CVS
people will not need this package.
+
+Package: libc6.1-prof
+Architecture: alpha ia64
+Section: libdevel
+Priority: extra
+Depends: libc6.1 (= ${Source-Version})
+Description: GNU C Library: Profiling Libraries.
+ Static libraries compiled with profiling info (-pg) suitable for use
+ with gprof.
+
+Package: libc6.1-pic
+Architecture: alpha ia64
+Section: libdevel
+Priority: optional
+Conflicts: libc-pic
+Provides: libc-pic, glibc-pic
+Depends: libc6.1 (= ${Source-Version})
+Description: GNU C Library: PIC archive library
+ Contains an archive library (ar file) composed of individual shared objects.
+ This is used for creating a library which is a smaller subset of the
+ standard libc shared library. The reduced library is used on the Debian
+ boot floppies. If you are not making your own set of Debian boot floppies
+ using the `boot-floppies' package, you probably don't need this package.
+
diff -urN
glibc-debian-cvs.for-diffing/glibc-package/debian/debhelper.in/libc-nptl.install
glibc-2.3.2.for-diffing/debian/debhelper.in/libc-nptl.install
---
glibc-debian-cvs.for-diffing/glibc-package/debian/debhelper.in/libc-nptl.install
1969-12-31 19:00:00.0 -0500
+++ glibc-2.3.2.for-diffing/debian/debhelper.in/libc-nptl.install
2003-10-01 10:10:03.0 -0500
@@ -0,0 +1 @@
+debian/tmp-nptl/lib/*.so* lib/nptl
diff -urN glibc-debian-cvs.for-diffing/glibc-package/debian/rules
glibc-2.3.2.for-diffing/debian/rules
--- glibc-debian-cvs.for-diffing/glibc-package/debian/rules 2003-09-27
18:25:39.0 -0500
+++ glibc-2.3.2.for-diffing/debian/rules2003-09-30 17:05:34.0
-0500
@@ -30,6 +30,7 @@
# limitations, they can be overridden and spread all over.
build-tree := build-tree
stamp := $(CURDIR)/stamp-dir/
+DUMMY := $(shell mkdir -p $(stamp))
# Beyond here you shouldn't need to customise anything:
@@ -116,7 +117,7 @@
clean:: debhelper-clean
rm -rf $(patsubst %,debian/tmp-%,$(GLIBC_PASSES))
rm -rf $(build-tree)
- rm -rf $(stamp)*
+ rm -rf $(stamp)
rm -f log-*
rm -f linux-kernel-headers/include/asm
diff -urN
glibc-debian-cvs.for-diffing/glibc-package/debian/rules.d/debhelper.mk
glibc-2.3.2.for-diffing/debian/rules.d/debhelper.mk
--- glibc-debian-cvs.for-diffing/glibc-package/debian/rules.d/debhelper.mk
2003-09-27 18:25:39.0 -0500
+++ glibc-2.3.2.for-diffing/debian/rules.d/debhelper.mk 2003-10-01
10:06:50.0 -0500
@@ -17,7 +17,7 @@
fi
dh_compress -p$(curpass)
- dh_fixperms -p$(curpass)
+ dh_fixperms -p$(curpass) -X ld-
dh_makeshlibs -p$(curpass)
dh_installdeb -p$(curpass)
@@ -60,7 +60,7 @@
for x in $(NPTL); do \
z=debian/$(libc).install; \
- cat debian/debhelper.in/libc-opt.install >>$$z; \
+ cat debian/debhelper.in/libc-nptl.install >>$$z; \
sed -e "s#TMPDIR#debian/tmp-$$x#" -i $$z; \
sed -e "s#DEB_SRCDIR#$(DEB_SRCDIR)#" -i $$z; \
sed -e "s#DESTLIBDIR#$$x#" -i $$z; \
diff -urN glibc-debian-cvs.for-diffing/glibc-package/debian/sysdeps/ia64.mk
glibc-2.3.2.for-diffing/debian/sysdeps/ia64.mk
--- glibc-debian-cvs.for-diffing/glibc-package/debian/sysdeps/ia64.mk
2003-09-22 16:20:58.0 -0500
+++ glibc-2.3.2.for-diffing/debian/sysdeps/ia64.mk 2003-09-30
17:05:37.0 -0500
@@ -1 +1,3 @@
+GLIBC_PASSES += nptl
+
libc = libc6.1
--
Branden Robinson | GPG signed/encrypted mail welcome
[EMAIL PROTECTED] | 1024D/9C0BCBFB
Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C
| 72E8 0F42 191A 9C0B CBFB
updates to NPTL branch in Debian CVS
ll not need this package.
+
+Package: libc6.1-prof
+Architecture: alpha ia64
+Section: libdevel
+Priority: extra
+Depends: libc6.1 (= ${Source-Version})
+Description: GNU C Library: Profiling Libraries.
+ Static libraries compiled with profiling info (-pg) suitable for use
+ with gprof.
+
+Package: libc6.1-pic
+Architecture: alpha ia64
+Section: libdevel
+Priority: optional
+Conflicts: libc-pic
+Provides: libc-pic, glibc-pic
+Depends: libc6.1 (= ${Source-Version})
+Description: GNU C Library: PIC archive library
+ Contains an archive library (ar file) composed of individual shared objects.
+ This is used for creating a library which is a smaller subset of the
+ standard libc shared library. The reduced library is used on the Debian
+ boot floppies. If you are not making your own set of Debian boot floppies
+ using the `boot-floppies' package, you probably don't need this package.
+
diff -urN
glibc-debian-cvs.for-diffing/glibc-package/debian/debhelper.in/libc-nptl.install
glibc-2.3.2.for-diffing/debian/debhelper.in/libc-nptl.install
--- glibc-debian-cvs.for-diffing/glibc-package/debian/debhelper.in/libc-nptl.install
1969-12-31 19:00:00.0 -0500
+++ glibc-2.3.2.for-diffing/debian/debhelper.in/libc-nptl.install 2003-10-01
10:10:03.0 -0500
@@ -0,0 +1 @@
+debian/tmp-nptl/lib/*.so* lib/nptl
diff -urN glibc-debian-cvs.for-diffing/glibc-package/debian/rules
glibc-2.3.2.for-diffing/debian/rules
--- glibc-debian-cvs.for-diffing/glibc-package/debian/rules 2003-09-27
18:25:39.0 -0500
+++ glibc-2.3.2.for-diffing/debian/rules2003-09-30 17:05:34.0 -0500
@@ -30,6 +30,7 @@
# limitations, they can be overridden and spread all over.
build-tree := build-tree
stamp := $(CURDIR)/stamp-dir/
+DUMMY := $(shell mkdir -p $(stamp))
# Beyond here you shouldn't need to customise anything:
@@ -116,7 +117,7 @@
clean:: debhelper-clean
rm -rf $(patsubst %,debian/tmp-%,$(GLIBC_PASSES))
rm -rf $(build-tree)
- rm -rf $(stamp)*
+ rm -rf $(stamp)
rm -f log-*
rm -f linux-kernel-headers/include/asm
diff -urN glibc-debian-cvs.for-diffing/glibc-package/debian/rules.d/debhelper.mk
glibc-2.3.2.for-diffing/debian/rules.d/debhelper.mk
--- glibc-debian-cvs.for-diffing/glibc-package/debian/rules.d/debhelper.mk
2003-09-27 18:25:39.0 -0500
+++ glibc-2.3.2.for-diffing/debian/rules.d/debhelper.mk 2003-10-01 10:06:50.0
-0500
@@ -17,7 +17,7 @@
fi
dh_compress -p$(curpass)
- dh_fixperms -p$(curpass)
+ dh_fixperms -p$(curpass) -X ld-
dh_makeshlibs -p$(curpass)
dh_installdeb -p$(curpass)
@@ -60,7 +60,7 @@
for x in $(NPTL); do \
z=debian/$(libc).install; \
- cat debian/debhelper.in/libc-opt.install >>$$z; \
+ cat debian/debhelper.in/libc-nptl.install >>$$z; \
sed -e "s#TMPDIR#debian/tmp-$$x#" -i $$z; \
sed -e "s#DEB_SRCDIR#$(DEB_SRCDIR)#" -i $$z; \
sed -e "s#DESTLIBDIR#$$x#" -i $$z; \
diff -urN glibc-debian-cvs.for-diffing/glibc-package/debian/sysdeps/ia64.mk
glibc-2.3.2.for-diffing/debian/sysdeps/ia64.mk
--- glibc-debian-cvs.for-diffing/glibc-package/debian/sysdeps/ia64.mk 2003-09-22
16:20:58.0 -0500
+++ glibc-2.3.2.for-diffing/debian/sysdeps/ia64.mk 2003-09-30 17:05:37.0
-0500
@@ -1 +1,3 @@
+GLIBC_PASSES += nptl
+
libc = libc6.1
--
Branden Robinson | GPG signed/encrypted mail welcome
[EMAIL PROTECTED] | 1024D/9C0BCBFB
Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C
| 72E8 0F42 191A 9C0B CBFB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NTPL support integration with Debian's glibc packages
[Please CC me on replies.] Hello glibc maintainers, Jeff Bailey and I have spoken on IRC a couple of times over the past few days about the intersection between NPTL and Debian's glibc packages, and he encouraged me to mail this list after he brought me up to speed on the current efforts. Progeny is interested in seeing NPTL support, at least at the C library level, in Debian sarge. Since the Release Manager's deadline for major changes to major packages is drawing nigh, we'd like to find out what we can do to help make this happen. I got the impression from Jeff that most of the work has already been done by GOTO Masanori, but integration and further work has been a little delayed because of the importance of getting glibc's release-critical bugs squashed. I'm familiar with Christian Leber's packages, but unfortunately those are mainly useful as a proof-of-concept; Jeff explained that Debian's glibc needs to retain LinuxThreads compatibility by default at least for one more Debian distribution release. Here are the major points as I understand them: * A libc6-nptl package will be created which provides a libc6 shared object. This package will not ship a shlibs file; instead, packages requiring NPTL support will be expected to depend on it explicitly. (The lack of support in the packaging system for versioned Provides: makes use of a shlibs file imprudent.) * The dynamic loader (ld-2.3.1.so) will have to be hacked with a patch from Red Hat that performs runtime checking of whether an object needs to use the NPTL version of libc6 or not. * A libc6-nptl-dev package will be created. Details on this appear to be a bit fuzzy still. Jeff seemed to think that the entry points in the libc6.so and libc6-nptl.so objects will be the same. I.e., the symbol offsets won't change despite the differences in the threading implementation. Do we know this to be true? * The package build process will obviously have to be changed to support building the C library twice; once with the stock threading implementation, and once with the NPTL patch applied. * Open question: will libc6-nptl (and libc6-nptl-dev) have those names even or architectures that use the package name "libc6.1" instead of "libc6"? * Open question: how will the new -nptl packages interact with the existing alternative versions of the C library package? E.g., the 64-bit version, the SPARCv9 version, and so forth. It seems to me that it could get complex to have eight different versions of the C library on SPARC: 32-bit, LinuxThreads, SPARCv(something-less-than-9) 32-bit, LinuxThreads, SPARCv9 32-bit, NPTL, SPARCv(something-less-than-9) 32-bit, NPTL, SPARCv9 64-bit, LinuxThreads, SPARCv(something-less-than-9) 64-bit, LinuxThreads, SPARCv9 64-bit, NPTL, SPARCv(something-less-than-9) 64-bit, NPTL, SPARCv9 ...and then we'd need a -dev package for each of those as well? For non-UltraSPARC 64-bit architectures, we'd still need four different shared library packages and four different -dev packages for full coverage, right? I'm available to work on these issues (once a consensus is reached, if it hasn't been already, on the open questions). Please let me know which plow I need to hitch myself to. :) -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#181493: SUN RPC code is DFSG-free
On Mon, Sep 08, 2003 at 01:34:54PM +0200, Andreas Barth wrote: > This would lead to the following code in stable (whichever release > name stable is, release name in []): > now Oct 03 Dez 03 Oct 04 > 1 sun[woody] sun[woody] sun[sarge] sun[sarge+1] > 2 sun[woody] sun[woody] sun[sarge] new[sarge+1] > 3 sun[woody] sun[woody] sun[woody] new[sarge] > 4 sun[woody] sun[woody] none[sarge] new[sarge+1] > 5 sun[woody] none[woody] none[sarge] new[sarge+1] Your analysis presumes that the act of releasing is not meaningful. Of course the old (presumably, for the sake of argument) non-DFSG-free code will continue to be available in old product. We didn't know it was non-DFSG-free then. We do now. If we make a release containing this non-DFSG-free code at any point after our awareness of this fact has been established, then we are *knowingly* violating clause one of the Social Contract, instead of unknowingly violating it. I regard that as a significant distinction. I guess you don't. In other news, Manoj Srivastava has pointed out that an alternative implementation of RPC, DCE RPC, has been released under the LGPL. He knows more about its feature set than I do, though, so I'll let him speak to that. -- G. Branden Robinson| The software said it required Debian GNU/Linux | Windows 3.1 or better, so I [EMAIL PROTECTED] | installed Linux. http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Re: Bug#181493: SUN RPC code is DFSG-free
[Mailing Debian glibc package maintainers and Debian Release Manager in their official capacities. My apolgies for the duplicate for those of you who are also subscribed to debian-legal, which is CCed.] On Thu, Sep 04, 2003 at 05:17:28PM +1000, Anthony Towns wrote: [...] > No, the burden of proof is on those who advocate a change, and it's not > been met. I wish you had been more forthcoming with your understanding of the removal of DFSG-non-free works from main way back around http://lists.debian.org/debian-ctte/2001/debian-ctte-200108/msg0.html >. The fact that I could cite the presence of the DFSG-non-free chunk of XFree86 source in Debian main all the way back (AFAIK) to its very first packaging for the Debian Project as precedent for its retention would definitely have saved us all an irritating flamewar. To recapitulate: * The Sun RPC license fails the DFSG on its face, as it withholds essential freedoms from people who do not develop software using it for themselves. * No advocate of an alternative interpretation of this license which would render it DFSG-free has been able to do better that cite second-rumors of some sort of clarification being made in the past, somewhere. * To date, at least in the logs of this bug report as far as I can tell, no advocate of retaining the SUN RPC code in Debian main has identified a single person from whom this license-clarifying hearsay was uttered, which makes it impossible to verify even the fact that such claims were made. * Former inclusion of a DFSG-non-free work in Debian main due to ignorance was not a good enough reason to retain it there in August 2001, and to my knowledge we haven't changed our Social Contract such that it is now. Given the above, all we have are bare assertions that the SUN RPC code is somehow DFSG-free despite its explicit terms, and all questions as to how exactly this is so have been dismissed as unimportant. This is no way to run a railroad, or a Free Software distribution. Is any member of the GNU C Library maintenance team in Debian attempting to research this problem via their upstream contacts? If not, do any members of this team object to another Debian Developer doing so? For the Release Manager: What standard do you set for the repudiation of the aforementioned hearsay? You are placing the Developers in the interesting posititon of proving a negative, and obviously we cannot poll everyone in the world who's ever had anything to do with the SUN RPC license or the conditions of its inclusion in the GNU C Library (this is mainly due to the low likelihood that a comprehensive list of such people can be made). For example, which of the following (either singly or in combination) would serve as repudiation of the alleged license clarification?: * Sun Microsystems, Inc. asserts that the license terms under which the code appears in the GNU C Library are the only ones under which the code is available; * A person with commit rights to the GNU C Library source repository upstream asserts that no such clarification has been made; * No person with commit rights to the GNU C Library source repository who responds to our queries is able to claim firsthand knowledge of any such clarification; * Every person who has ever had commit rights to the GNU C Library source repository swears out an affidavit that they know of no other terms under which the SUN RPC code is available for distribution with the GNU C Library. (Feel free to add your own criteria; as with many endeavors to prove a negative, such a list is going to be open-ended.) -- G. Branden Robinson| The only way to get rid of a Debian GNU/Linux | temptation is to yield to it. [EMAIL PROTECTED] | -- Oscar Wilde http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Bug#181493: SUN RPC code is DFSG-free
On Thu, Sep 04, 2003 at 05:17:28PM +1000, Anthony Towns wrote: > On Tue, Aug 26, 2003 at 03:15:05PM -0500, Branden Robinson wrote: > > You ground your argument on "second hand reports of clarifications" in > > the first quoted paragraph, but then expect debian-legal to furnish > > first-hand clarifications? > > Yes. If you're too lazy to be bothered doing that, don't expect anyone > else -- either the release manager nor the glibc maintainers -- to care > about your ravings. > > > The burden of proof is on those > > who claim it's been "clarified" to come up with evidence of such. > > No, the burden of proof is on those who advocate a change, and it's not > been met. Ah, so in general, when people find a flagrant DFSG violation in main, the best thing they can do is just leave it alone. Otherwise, it's a "change", and past inclusion is always sufficient present for future retention. Got it. -- G. Branden Robinson|If a man ate a pound of pasta and a Debian GNU/Linux |pound of antipasto, would they [EMAIL PROTECTED] |cancel out, leaving him still http://people.debian.org/~branden/ |hungry? -- Scott Adams pgp0.pgp Description: PGP signature
Bug#207354: libc6: SEGV in glob64() on PowerPC
On Wed, Aug 27, 2003 at 09:31:24AM +0900, GOTO Masanori wrote: > At Tue, 26 Aug 2003 09:49:59 -0500, > Branden Robinson wrote: > > Got this while running kmix. > > > > 0x0eb4eb7c in glob64 () from /lib/libc.so.6 > > #0 0x0eb4eb7c in glob64 () from /lib/libc.so.6 > > > > I'll restart kmix with LD_LIBRARY_PATH=/usr/lib/debug and see if it > > happens again. > > Please show the test case or test code. Can't do that until I get a full backtrace. I'll just have to wait until it crashes again. -- G. Branden Robinson| The power of accurate observation Debian GNU/Linux | is frequently called cynicism by [EMAIL PROTECTED] | those who don't have it. http://people.debian.org/~branden/ | -- George Bernard Shaw pgp0.pgp Description: PGP signature
Bug#181493: SUN RPC code is DFSG-free
On Tue, Aug 26, 2003 at 07:16:34PM +1000, Anthony Towns wrote:
> On Mon, Aug 25, 2003 at 01:26:22AM -0700, Don Armstrong wrote:
> > On Mon, 25 Aug 2003, Andreas Barth wrote:
> > > So, this license is specific to be used only as "part of a product or
> > > programm".
> > You're missing the key phrase on which Branden's argument (and mine)
> > is based on: 'developed by the user'
> >
> > This phrase read conservatively
>
> ...is not the author's intention, as indicated by second hand reports
> of clarifications ("BSD, but can't use the original literally") by
> the copyright holder, and the copyright holder's (lack of) response to
> copious reuse and redistribution.
[...]
> If anyone on -legal believes clarifications are necessary or would
> be helpful, please feel free to get them from Sun.
You ground your argument on "second hand reports of clarifications" in
the first quoted paragraph, but then expect debian-legal to furnish
first-hand clarifications?
Well, I haven't heard of any such clarification being made, so we're
down to the credibility of the claimants.
Who has asserted to you the existence of these "clarifications"? Have
these people any stake in the existence of such claims?
The Sun RPC fails the DFSG on its face. The burden of proof is on those
who claim it's been "clarified" to come up with evidence of such.
This is the converse of the old UWash Pine license issue, where UWash
took a license that was DFSG-free on its face and "interpreted" it in a
non-free way.
--
G. Branden Robinson| Never underestimate the power of
Debian GNU/Linux | human stupidity.
[EMAIL PROTECTED] | -- Robert Heinlein
http://people.debian.org/~branden/ |
pgp0.pgp
Description: PGP signature
Bug#207354: libc6: SEGV in glob64() on PowerPC
Package: libc6 Version: 2.3.2-3 Severity: important Got this while running kmix. 0x0eb4eb7c in glob64 () from /lib/libc.so.6 #0 0x0eb4eb7c in glob64 () from /lib/libc.so.6 I'll restart kmix with LD_LIBRARY_PATH=/usr/lib/debug and see if it happens again. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux redwald 2.4.19-powerpc #1 Mon Sep 9 09:01:43 EDT 2002 ppc Locale: LANG=C, LC_CTYPE=en_US Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#207199: locales: locale-gen should complain about malformed /etc/locale.gen files
Package: locales Version: 2.3.2-3 Severity: normal # cat /etc/locale.gen en_US.ISO-8859-1 en_US.UTF-8 # locale-gen Generating locales... Generation complete. Hmph. # locale-gen + LOCALEGEN=/etc/locale.gen + LOCALES=/usr/share/i18n/locales + '[' -f /etc/locale.gen -a -s /etc/locale.gen ']' + rm -rf '/usr/lib/locale/*' + umask 022 + echo 'Generating locales...' Generating locales... + read locale charset + '[' -n en_US.ISO-8859-1 -a -n '' ']' + continue + read locale charset + '[' -n en_US.UTF-8 -a -n '' ']' + continue + read locale charset + '[' -n '' -a -n '' ']' + continue + read locale charset + echo 'Generation complete.' Generation complete. This tool expects two "words" in each line of locale.gen. It should complain if the input is malformed. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux tentacle 2.4.19-pre7-ben0 #1 Tue Jun 18 10:25:42 EST 2002 ppc Locale: LANG=C, LC_CTYPE=C Versions of packages locales depends on: ii debconf 1.3.9 Debian configuration management sy hi libc6 [glibc-2.3.2-3] 2.3.2-3GNU C Library: Shared libraries an -- debconf information: * locales/default_environment_locale: C * locales/locales_to_be_generated: en_US.ISO-8859-1, en_US.UTF-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#181493: SUN RPC code is DFSG-free
On Sat, Aug 23, 2003 at 06:50:19PM +1000, Anthony Towns wrote: > > I'm personally concerned about this particular phrase, as it seems to > > preclude Debian from distributing software with Sun RPC in it unless > > Debian itself is developing the product or program using Sun RPC. > > Which we are, viz "The Debian Distribution". ...which means the license violates either DFSG 5, DFSG 6, or DFSG 8. If the fact that we *are* "the Debian Project" or *are* a group of "developers of products or programs" are facts that render us compliant with the license, then the license is not DFSG-free. Who you are, or what you do (apart from the copyright-protected activity of distribution of the Work-in-Itself) does not matter to a Free license. If it does, the license is not Free. If citing who we are or what we do is a defense to a claim of copyright infringement, then the license is discriminatory. -- G. Branden Robinson| Debian GNU/Linux | If ignorance is bliss, [EMAIL PROTECTED] | is omniscience hell? http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Bug#181493: Is the Sun RPC License DFSG-free?
On Fri, Aug 22, 2003 at 06:39:47AM +, Brian M. Carlson wrote: > Copyright (C) 1984, Sun Microsystems, Inc. > > Sun RPC is a product of Sun Microsystems, Inc. and is > provided for unrestricted use provided that this legend is > included on all tape media and as a part of the software > program in whole or part. Uh, *all* tape media? Is that all tape media in the world, including that which I don't own? If it's the tape media I own, do I have to put this "legend" even on tape media that do not contain anything copyrighted by Sun Microsystems? I *assume* that this restriction is not meant to be construed more broadly than copyright law will permit. If it is meant to impact things that have nothing to do with the code, then this flagrantly violates DFSG 9. Furthermore, does "on all tape media" mean physically marked on the tape cartridge, or merely present electromagnetically, probably encoded as data? If the former, it's at least as onerous as the BSD advertising clause. If the latter, I don't think it's a problem. > Users may copy or modify Sun RPC > without charge, but are not authorized to license or > distribute it to anyone else except as part of a product or > program developed by the user. This violates DFSG 1 and arguably DFSG 5. It might skate through DFSG 1's backwards-bent wording if the sentence stopped at "part of a product or program". But it doesn't stop there. You can't redistribute this code unless you develop with it. This requires distributors to be software developers, not ordinary joes who've never written a line of code in their lives. > SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND > INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND > FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF > DEALING, USAGE OR TRADE PRACTICE. Okay. > Sun RPC is provided with no support and without any > obligation on the part of Sun Microsystems, Inc. to assist in > its use, correction, modification or enhancement. Okay. > SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT > TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY > PATENTS BY SUN RPC OR ANY PART THEREOF. Okay. > In no event will Sun Microsystems, Inc. be liable for any > lost revenue or profits or other special, indirect and > consequential damages, even if Sun has been advised of the > possibility of such damages. Okay. For reference: 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. 9. License Must Not Contaminate Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software. -- G. Branden Robinson|I had thought very carefully about Debian GNU/Linux |committing hara-kiri over this, but [EMAIL PROTECTED] |I overslept this morning. http://people.debian.org/~branden/ |-- Toshio Yamaguchi pgp0.pgp Description: PGP signature
Re: Bug#170507: xfree86: FTBFS on hppa: 'SHMBLA' undeclared
reassign 170507 glibc retitle 170507 glibc: header goofup on hppa breaks XFree86 compilation thanks On Sun, Nov 24, 2002 at 04:24:23PM +, Matthew Wilcox wrote: > On Sun, Nov 24, 2002 at 09:12:40PM +0900, ISHIKAWA Mutsumi wrote: > > SHMLBA is defined in /usr/include/bits/shm.h as: > > > > /* Segment low boundary address multiple. */ > > #define SHMLBA (__getpagesize ()) > > extern int __getpagesize (void) __THROW __attribute__ ((__const__)); > > > > But on hppa these defines are missing. > > I can not find these defines anywhere on the hppa environment. > > > > Is this glibc's bug on hppa environment? > > Yes. It should be: > > include/asm-parisc/shmparam.h:#define SHMLBA 0x0040 /* attach addr > needs to be 4 Mb aligned */ > > -- > Revolutions do not require corporate support. > -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | pgpACFb8ec48H.pgp Description: PGP signature
Re: Bug#170507: xfree86: FTBFS on hppa: 'SHMBLA' undeclared
reassign 170507 glibc retitle 170507 glibc: header goofup on hppa breaks XFree86 compilation thanks On Sun, Nov 24, 2002 at 04:24:23PM +, Matthew Wilcox wrote: > On Sun, Nov 24, 2002 at 09:12:40PM +0900, ISHIKAWA Mutsumi wrote: > > SHMLBA is defined in /usr/include/bits/shm.h as: > > > > /* Segment low boundary address multiple. */ > > #define SHMLBA (__getpagesize ()) > > extern int __getpagesize (void) __THROW __attribute__ ((__const__)); > > > > But on hppa these defines are missing. > > I can not find these defines anywhere on the hppa environment. > > > > Is this glibc's bug on hppa environment? > > Yes. It should be: > > include/asm-parisc/shmparam.h:#define SHMLBA 0x0040 /* attach addr needs to be >4 Mb aligned */ > > -- > Revolutions do not require corporate support. > -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | msg01962/pgp0.pgp Description: PGP signature
Bug#165603: man-db: me too
On Tue, Oct 22, 2002 at 01:54:10AM +0100, Colin Watson wrote: > Aha! On the off-chance, I tried this in a chroot with glibc 2.3.1 and it > segfaulted. Ditto with en_US, which I'm guessing Branden's using. You seem to have already narrowed this down, but yes, that's the case. $ locale LANG=POSIX LC_CTYPE=en_US LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= Not sure why that stuff didn't show up in reportbug's output. -- G. Branden Robinson|I must despise the world which does Debian GNU/Linux |not know that music is a higher [EMAIL PROTECTED] |revelation than all wisdom and http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven pgpryKMEH7o0s.pgp Description: PGP signature
Bug#165603: man-db: me too
On Tue, Oct 22, 2002 at 01:54:10AM +0100, Colin Watson wrote: > Aha! On the off-chance, I tried this in a chroot with glibc 2.3.1 and it > segfaulted. Ditto with en_US, which I'm guessing Branden's using. You seem to have already narrowed this down, but yes, that's the case. $ locale LANG=POSIX LC_CTYPE=en_US LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= Not sure why that stuff didn't show up in reportbug's output. -- G. Branden Robinson|I must despise the world which does Debian GNU/Linux |not know that music is a higher [EMAIL PROTECTED] |revelation than all wisdom and http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven msg01470/pgp0.pgp Description: PGP signature
Re: Bug#163031: xterm: bug in deletion of multi-byte characters with unicode-xterm
severity 163031 wishlist reassign 163031 kernel,libc6,shellutils retitle 163031 Request for UTF8 mode merge 139771 163031 thanks On Tue, Oct 01, 2002 at 11:02:29PM +0200, Johannes Groedem wrote: > When I delete a multibyte-character (UTF-8) in xterm (with backspace), > it appears to only delete the last byte of the multibyte-character. This bug has already been filed. Merging. -- G. Branden Robinson| Debian GNU/Linux | Ab abusu ad usum non valet [EMAIL PROTECTED] | consequentia. http://people.debian.org/~branden/ | msg01151/pgp0.pgp Description: PGP signature
Bug#162612: libc6-dev: telling gcc to optimize causes C99 violations, thanks to endian.h
On Fri, Sep 27, 2002 at 06:34:59PM -0400, Ben Collins wrote: > hopper:~$ gcc-2.95 -c -o twofish.o -O2 -g twofish.c > hopper:~$ gcc-3.2 -c -o twofish.o -O2 -g twofish.c > hopper:~$ > > I'm not seeing the problem. Because you're a SPARC bigot. :) Do it on an i386. I couldn't repro it either -- not on a SPARC. Still can on an i386. -- G. Branden Robinson| Organized religion is a sham and a Debian GNU/Linux | crutch for weak-minded people who [EMAIL PROTECTED] | need strength in numbers. http://people.debian.org/~branden/ | -- Jesse Ventura msg01095/pgp0.pgp Description: PGP signature
Bug#162612: libc6-dev: telling gcc to optimize causes C99 violations, thanks to endian.h
On Fri, Sep 27, 2002 at 02:05:53PM -0400, Ben Collins wrote: > > $ gcc-3.2 -c -o twofish.o -O1 -g twofish.c > > twofish.c:214:1: warning: "BIG_ENDIAN" redefined > > In file included from /usr/include/bits/string2.h:52, > > from /usr/include/string.h:360, > > from /usr/include/memory.h:30, > > from twofish.c:156: > > /usr/include/endian.h:47:1: warning: this is the location of the previous > > definition > > One thing I want to note is that if you need strict c99, then you should > add this to cflags: --std=c99 -D_ISOC99_SOURCE > > The --std=c99 tells the compiler to be strictly c99 conforming, and the > _ISOC99_SOURCE tells glibc to also be such. > > You should retest with that. > > Second of all, BIG_ENDIAN is only defined if __USE_BSD is defined. It's > likely that somewhere, either _BSD_SOURCE or _GNU_SOURCE is defined. Neither is the case. The source file is twofish.c; you can get it at: http://www.macfergus.com/niels/code/TwofishClib-v0.2.zip Unzip the archive and compile it like this: gcc -c -o twofish.o -O2 -g twofish.c contrast with gcc -c -o twofish.o -g twofish.c -- G. Branden Robinson| Convictions are more dangerous Debian GNU/Linux | enemies of truth than lies. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | msg01090/pgp0.pgp Description: PGP signature
Bug#162612: libc6-dev: telling gcc to optimize causes C99 violations, thanks to endian.h
Package: libc6-dev Version: 2.2.5-14.3 Severity: normal Please see attachment. -- G. Branden Robinson| The greatest productive force is Debian GNU/Linux | human selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | --- Begin Message --- Dear Branden, Jan Nieuwenhuizen, a friend of mine here in the Netherlands, had another look at the BIG_ENDIAN naming conflict. Here is what he found. === 15:29:55 fred@peder:~/usr/src/twofish-clib $ gcc-3.2 -c -o twofish.o -O1 -g twofish.c twofish.c:214:1: warning: "BIG_ENDIAN" redefined In file included from /usr/include/bits/string2.h:52, from /usr/include/string.h:360, from /usr/include/memory.h:30, from twofish.c:156: /usr/include/endian.h:47:1: warning: this is the location of the previous definition 15:30:44 fred@peder:~/usr/src/twofish-clib $ head -400 /usr/include/string.h | tail -40 declare the function if the `basename' macro is available (defined in ) which makes the XPG version of this function available. */ extern char *basename (__const char *__filename) __THROW; # endif #endif #if defined __GNUC__ && __GNUC__ >= 2 # if defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__ \ && !defined __NO_INLINE__ && !defined __cplusplus /* When using GNU CC we provide some optimized versions of selected functions from this header. There are two kinds of optimizations: - machine-dependent optimizations, most probably using inline assembler code; these might be quite expensive since the code size can increase significantly. These optimizations are not used unless the symbol __USE_STRING_INLINES is defined before including this header. - machine-independent optimizations which do not increase the code size significantly and which optimize mainly situations where one or more arguments are compile-time constants. These optimizations are used always when the compiler is taught to optimize. One can inhibit all optimizations by defining __NO_STRING_INLINES. */ /* Get the machine-dependent optimizations (if any). */ # include /* These are generic optimizations which do not add too much inline code. */ # include # endif #endif __END_DECLS #endif /* string.h */ 15:31:24 fred@peder:~/usr/src/twofish-clib $ dpkg -S /usr/include/string.h libc6-dev: /usr/include/string.h 15:33:04 fred@peder:~/usr/src/twofish-clib $ dpkg -S /usr/include/bits/string2.h libc6-dev: /usr/include/bits/string2.h 15:33:13 fred@peder:~/usr/src/twofish-clib === It is clear that the libc library defines the BIG_ENDIAN macro if optimisations are switched on. I don't have the full C99 standard, but I did find the final committee draft on the web. It states in the chapter that defines all the different header files: === 7.1.3 Reserved identifiers 1 Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers. All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces. Each macro name in any of the following subclauses (including the future library directions) is reserved for use as specified if any of its associated headers is included; unless explicitly stated otherwise (see 7.1.4). All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage.143) Each identifier with file scope listed in any of the following subclauses (including the future library directions) is reserved for use as macro and as an identifier with file scope in the same name space if any of its associated headers is included. 2 No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined. 3 If the program removes (with #undef) any macro definition of an identifier in the first group listed above, the behavior is undefined. === Which I read to state that the library isn't allowed to define something called BIG_ENDIAN. (I looked at all the other sections referred to, but none allow BIG_ENDIAN to be defined.) My conclus
Re: Bug#148130: xserver-xfree86: message "X: warning; nice() of process failed: Success" on error output stream
reassign 148130 xserver-common thanks On Sat, May 25, 2002 at 09:46:43AM +0200, Jan Gregor wrote: > Package: xserver-xfree86 > Version: 4.1.0-16 > Severity: normal > > I found message "X: warning; nice() of process failed: Success" on > startup of xfree86 in standard error output. This behavior is exhibited by the X server wrapper, which is in the xserver-common package, FYI. And, as it happens, I fixed this with my upload of 4.1.0-17. This is what happens when your distribution's libc maintainer changes the semantics of nice() while we're in a freeze, and then changes them back again, still within the freeze. ObCCJustification: -- G. Branden Robinson|Kissing girls is a goodness. It is Debian GNU/Linux |a growing closer. It beats the [EMAIL PROTECTED] |hell out of card games. http://people.debian.org/~branden/ |-- Robert Heinlein pgpAFz1QepI0i.pgp Description: PGP signature
Re: Bug#148130: xserver-xfree86: message "X: warning; nice() of process failed: Success" on error output stream
reassign 148130 xserver-common thanks On Sat, May 25, 2002 at 09:46:43AM +0200, Jan Gregor wrote: > Package: xserver-xfree86 > Version: 4.1.0-16 > Severity: normal > > I found message "X: warning; nice() of process failed: Success" on > startup of xfree86 in standard error output. This behavior is exhibited by the X server wrapper, which is in the xserver-common package, FYI. And, as it happens, I fixed this with my upload of 4.1.0-17. This is what happens when your distribution's libc maintainer changes the semantics of nice() while we're in a freeze, and then changes them back again, still within the freeze. ObCCJustification: -- G. Branden Robinson|Kissing girls is a goodness. It is Debian GNU/Linux |a growing closer. It beats the [EMAIL PROTECTED] |hell out of card games. http://people.debian.org/~branden/ |-- Robert Heinlein msg00354/pgp0.pgp Description: PGP signature
Re: libX11 is borked (or is it glibc ?)
On Sun, Oct 15, 2000 at 09:02:42PM -0400, Daniel Jacobowitz wrote: > To compile against a library built under an old glibc, the library > needs to be recompiled to the new libc. I think there's already a > forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - > right, Branden? Not exactly. When the 4.x packages are done, here's what will happen to 3.x, as can be previewed on samosa: 1) some 3.x servers will be built for alpha and i386 2) libc5-compatible X libraries will be built for i386 It is true however that the problem described will go away. -- G. Branden Robinson | Debian GNU/Linux| Never attribute to malice that which can [EMAIL PROTECTED] | be adequately explained by stupidity. http://www.debian.org/~branden/ | pgpKTVTaJgJgL.pgp Description: PGP signature
