Re: linux/types.h <-> glibc interferences

2007-08-23 Thread Steve Langasek
On Thu, Aug 23, 2007 at 10:08:44PM +0200, Bastian Blank wrote:

> linux/types.h exports some POSIX types. It can be asked to stop this
> with __KERNEL_STRICT_NAMES. features.h defines this. So currently
> anything works if features.h is included before linux/types.h.

> This is not properly fixable by the glibc. The attached patch fixes it
> in linux, but I'm unsure if this will not break other things like
> alternative libc.

Is there some specific reported issue that this change is intended to fix?
I haven't noticed any complaints about the current behavior.

I assume this isn't intended as the fix for 429064, since 429064 is
reporting an issue with a kernel type which is currently *not* guarded with
__KERNEL_STRICT_NAMES; your patch fixes this, but only as a side-effect.

Anyway, it's my understanding that userspace apps are never supposed to
define __KERNEL__ and doing so with linux-libc-dev gives broken includes, so
in terms of overall design this change looks wrong to me (or at least,
gratuitously strict).  If there's userspace code that wants to get the
kernel types under the standard posix names, why break that?

(For an example of code that probably breaks with this change, I offer you
aboot, the alpha bootloader; it's not great code, but we have to maintain it
all the same...)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: linux/types.h <-> glibc interferences

2007-08-23 Thread Bastian Blank
On Thu, Aug 23, 2007 at 02:46:14PM -0700, Steve Langasek wrote:
> Is there some specific reported issue that this change is intended to fix?
> I haven't noticed any complaints about the current behavior.

#434040 and a hand full of packages on the buildd.

> Anyway, it's my understanding that userspace apps are never supposed to
> define __KERNEL__ and doing so with linux-libc-dev gives broken includes, so
> in terms of overall design this change looks wrong to me (or at least,
> gratuitously strict).

__KERNEL__-only parts of the headers are filtered out for
linux-libc-dev.

>If there's userspace code that wants to get the
> kernel types under the standard posix names, why break that?

Please provide a less strict fix which works. Userspace code can only
use this definitions within a freestanding compiler without libc.

> (For an example of code that probably breaks with this change, I offer you
> aboot, the alpha bootloader; it's not great code, but we have to maintain it
> all the same...)

Thats what I expected.

Bastian

-- 
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



linux/types.h <-> glibc interferences

2007-08-23 Thread Bastian Blank
Hi folks

linux/types.h exports some POSIX types. It can be asked to stop this
with __KERNEL_STRICT_NAMES. features.h defines this. So currently
anything works if features.h is included before linux/types.h.

This is not properly fixable by the glibc. The attached patch fixes it
in linux, but I'm unsure if this will not break other things like
alternative libc.

Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3
diff --git a/include/linux/types.h b/include/linux/types.h
index 0351bf2..a9779d6 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -14,10 +14,10 @@
 #include 
 #include 
 
-#ifndef __KERNEL_STRICT_NAMES
-
 typedef __u32 __kernel_dev_t;
 
+#ifdef __KERNEL__
+
 typedef __kernel_fd_set		fd_set;
 typedef __kernel_dev_t		dev_t;
 typedef __kernel_ino_t		ino_t;
@@ -32,7 +32,6 @@ typedef __kernel_timer_t	timer_t;
 typedef __kernel_clockid_t	clockid_t;
 typedef __kernel_mqd_t		mqd_t;
 
-#ifdef __KERNEL__
 typedef _Bool			bool;
 
 typedef __kernel_uid32_t	uid_t;
@@ -46,51 +45,14 @@ typedef __kernel_old_uid_t	old_uid_t;
 typedef __kernel_old_gid_t	old_gid_t;
 #endif /* CONFIG_UID16 */
 
-/* libc5 includes this file to define uid_t, thus uid_t can never change
- * when it is included by non-kernel code
- */
-#else
-typedef __kernel_uid_t		uid_t;
-typedef __kernel_gid_t		gid_t;
-#endif /* __KERNEL__ */
-
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 typedef __kernel_loff_t		loff_t;
-#endif
 
-/*
- * The following typedefs are also protected by individual ifdefs for
- * historical reasons:
- */
-#ifndef _SIZE_T
-#define _SIZE_T
 typedef __kernel_size_t		size_t;
-#endif
-
-#ifndef _SSIZE_T
-#define _SSIZE_T
 typedef __kernel_ssize_t	ssize_t;
-#endif
-
-#ifndef _PTRDIFF_T
-#define _PTRDIFF_T
 typedef __kernel_ptrdiff_t	ptrdiff_t;
-#endif
-
-#ifndef _TIME_T
-#define _TIME_T
 typedef __kernel_time_t		time_t;
-#endif
-
-#ifndef _CLOCK_T
-#define _CLOCK_T
 typedef __kernel_clock_t	clock_t;
-#endif
-
-#ifndef _CADDR_T
-#define _CADDR_T
 typedef __kernel_caddr_t	caddr_t;
-#endif
 
 /* bsd */
 typedef unsigned char		u_char;
@@ -104,27 +66,18 @@ typedef unsigned short		ushort;
 typedef unsigned int		uint;
 typedef unsigned long		ulong;
 
-#ifndef __BIT_TYPES_DEFINED__
-#define __BIT_TYPES_DEFINED__
-
+typedef		__u8		uint8_t;
 typedef		__u8		u_int8_t;
 typedef		__s8		int8_t;
+typedef		__u16		uint16_t;
 typedef		__u16		u_int16_t;
 typedef		__s16		int16_t;
+typedef		__u32		uint32_t;
 typedef		__u32		u_int32_t;
 typedef		__s32		int32_t;
-
-#endif /* !(__BIT_TYPES_DEFINED__) */
-
-typedef		__u8		uint8_t;
-typedef		__u16		uint16_t;
-typedef		__u32		uint32_t;
-
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 typedef		__u64		uint64_t;
 typedef		__u64		u_int64_t;
 typedef		__s64		int64_t;
-#endif
 
 /* this is a special 64bit data type that is 8-byte aligned */
 #define aligned_u64 unsigned long long __attribute__((aligned(8)))
@@ -160,7 +113,7 @@ typedef unsigned long blkcnt_t;
 #define pgoff_t unsigned long
 #endif
 
-#endif /* __KERNEL_STRICT_NAMES */
+#endif /* __KERNEL__ */
 
 /*
  * Below are truly Linux-specific types that should never collide with
@@ -182,10 +135,8 @@ typedef __u16 __bitwise __le16;
 typedef __u16 __bitwise __be16;
 typedef __u32 __bitwise __le32;
 typedef __u32 __bitwise __be32;
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
-typedef __u64 __bitwise __le64;
-typedef __u64 __bitwise __be64;
-#endif
+__extension__ typedef __u64 __bitwise __le64;
+__extension__ typedef __u64 __bitwise __be64;
 typedef __u16 __bitwise __sum16;
 typedef __u32 __bitwise __wsum;
 
@@ -198,8 +149,6 @@ typedef u64 resource_size_t;
 typedef u32 resource_size_t;
 #endif
 
-#endif	/* __KERNEL__ */
-
 struct ustat {
 	__kernel_daddr_t	f_tfree;
 	__kernel_ino_t		f_tinode;
@@ -207,4 +156,6 @@ struct ustat {
 	char			f_fpack[6];
 };
 
+#endif	/* __KERNEL__ */
+
 #endif /* _LINUX_TYPES_H */


Some of your Debian packages might need attention

2007-08-23 Thread DDPOMail robot
Dear GNU Libc Maintainers,

The following possible problem(s) were detected in the package(s)
you maintain in Debian:

=== glibc:
= This package has 1 RC bug(s) more than 30 days old:
- #382175 
  glibc: contains possibly non-free code

This is a semi-automated mail. These mails are sent monthly.
For more information about these mails, refer to
http://wiki.debian.org/qa.debian.org/DdpoByMail

We are sorry if this mail was useless for you. If you think it was
avoidable (that we can detect easily that the problems weren't
actually problems), please reply to it and let us know.

If you don't want to receive this type of mail any more, you can reply
to this mail and use one of the following commands at the beginning of
the mail:
- unsubscribe 
You will no longer receive any mail for any package
- ignore  
You will no longer receive information about that package in those
mails. So if that package is the only one with problems, you won't
receive anything.
- ignore  
You will no longer receive information about this bug.

All commands are manually processed, but you will receive
confirmation. The commands are just here so that we know precisely
what you want.

A more detailed status of your packages is available from the DDPO.
See: 
http://qa.debian.org/[EMAIL PROTECTED]

Don't hesitate to reply to this mail if you have questions. The wiki
page will be updated with useful information.
-- 
DDPOMail, run by Lucas Nussbaum


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Processed: reopening 433870

2007-08-23 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.7
> reopen 433870
Bug#433870: Sarge: TimeZone: New Zealand change to daylight time transition
'reopen' may be inappropriate when a bug has been closed with a version;
you may need to use 'found' to remove fixed versions.
Bug reopened, originator not changed.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#433870: marked as done (Sarge: TimeZone: New Zealand change to daylight time transition)

2007-08-23 Thread Debian Bug Tracking System
Your message dated Thu, 23 Aug 2007 09:33:02 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#433870: fixed in openoffice.org 2.2.1-8
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: libc6
Version: 2.3.2.ds1-22sarge6
Severity: normal

The New Zealand Government has altered the dates when Daylight Time
will start and end starting this year.  Daylight Time will begin one
week earlier (on the last Sunday in September, instead of the first
Sunday in October), and finish two weeks later:

http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended?OpenDocument

The tzdata package in testing and unstable (2007f-9) includes this
change, and the timezone is correctly reported in those versions (as
seen in, eg, "tzdump -v Pacific/Auckland").  I have filed another bug
on tzdata in stable (etch) about this problem.

In oldstable (sarge) the timezone information is included in the libc6
package, which is based on tzdata 2006p-1, and is now out of date for
New Zealand (Pacific/Auckland).

I see that there was a libc6 update for sarge last year
(2.3.2.ds1-22sarge5) which included time zone data 2006p-1, and brought
in the correct time zone information for the USA and Western Australia.

Is another update planned for sarge to bring in the updated tzdata (2007f)
that includes the New Zealand time zone change?  If not, can you recommend
the best way to update this time zone information on sarge based systems?
(And yes, I'm upgrading them to Etch as fast as possible, but there's a
bunch to do.)

Ewen

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.17.8-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

-- no debconf information


--- End Message ---
--- Begin Message ---
Source: openoffice.org
Source-Version: 2.2.1-8

We believe that the bug you reported is fixed in the latest version of
openoffice.org, which is due to be installed in the Debian FTP archive:

broffice.org_2.2.1-8_all.deb
  to pool/main/o/openoffice.org/broffice.org_2.2.1-8_all.deb
libmythes-dev_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/libmythes-dev_2.2.1-8_i386.deb
libuno-cil_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/libuno-cil_2.2.1-8_i386.deb
mozilla-openoffice.org_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/mozilla-openoffice.org_2.2.1-8_i386.deb
openoffice.org-base_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-base_2.2.1-8_i386.deb
openoffice.org-calc_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-calc_2.2.1-8_i386.deb
openoffice.org-common_2.2.1-8_all.deb
  to pool/main/o/openoffice.org/openoffice.org-common_2.2.1-8_all.deb
openoffice.org-core_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-core_2.2.1-8_i386.deb
openoffice.org-dbg_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-dbg_2.2.1-8_i386.deb
openoffice.org-dev-doc_2.2.1-8_all.deb
  to pool/main/o/openoffice.org/openoffice.org-dev-doc_2.2.1-8_all.deb
openoffice.org-dev_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-dev_2.2.1-8_i386.deb
openoffice.org-draw_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-draw_2.2.1-8_i386.deb
openoffice.org-dtd-officedocument1.0_2.2.1-8_all.deb
  to 
pool/main/o/openoffice.org/openoffice.org-dtd-officedocument1.0_2.2.1-8_all.deb
openoffice.org-evolution_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-evolution_2.2.1-8_i386.deb
openoffice.org-filter-binfilter_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-filter-binfilter_2.2.1-8_i386.deb
openoffice.org-filter-mobiledev_2.2.1-8_all.deb
  to pool/main/o/openoffice.org/openoffice.org-filter-mobiledev_2.2.1-8_all.deb
openoffice.org-gcj_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-gcj_2.2.1-8_i386.deb
openoffice.org-gnome_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-gnome_2.2.1-8_i386.deb
openoffice.org-gtk_2.2.1-8_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-gtk_2.2.1-8_i386.deb
openoffice.org-help-cs_2.2.1-8_all.deb
  to pool/main/o/openoffice.org/openoffice.org-help-cs_2.2.1-8_all.deb
openoffice.org-help-da_2.2.1-8_all.deb
  to pool/main/o/openoffice.org/openoffice.org-help-da_2.2.1-8_all.deb
openoffice.org-help-de_2.2.1-8_all.deb
  to pool/main/o/openoffice.org/openoffice.org-help-de_2.2.1-8_all.deb
openoffice.org-he

Bug#433870: marked as done (Sarge: TimeZone: New Zealand change to daylight time transition)

2007-08-23 Thread Debian Bug Tracking System
Your message dated Thu, 23 Aug 2007 09:34:06 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#433870: fixed in openoffice.org 1:2.3.0~oog680m2-1
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: libc6
Version: 2.3.2.ds1-22sarge6
Severity: normal

The New Zealand Government has altered the dates when Daylight Time
will start and end starting this year.  Daylight Time will begin one
week earlier (on the last Sunday in September, instead of the first
Sunday in October), and finish two weeks later:

http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended?OpenDocument

The tzdata package in testing and unstable (2007f-9) includes this
change, and the timezone is correctly reported in those versions (as
seen in, eg, "tzdump -v Pacific/Auckland").  I have filed another bug
on tzdata in stable (etch) about this problem.

In oldstable (sarge) the timezone information is included in the libc6
package, which is based on tzdata 2006p-1, and is now out of date for
New Zealand (Pacific/Auckland).

I see that there was a libc6 update for sarge last year
(2.3.2.ds1-22sarge5) which included time zone data 2006p-1, and brought
in the correct time zone information for the USA and Western Australia.

Is another update planned for sarge to bring in the updated tzdata (2007f)
that includes the New Zealand time zone change?  If not, can you recommend
the best way to update this time zone information on sarge based systems?
(And yes, I'm upgrading them to Etch as fast as possible, but there's a
bunch to do.)

Ewen

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.17.8-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

-- no debconf information


--- End Message ---
--- Begin Message ---
Source: openoffice.org
Source-Version: 1:2.3.0~oog680m2-1

We believe that the bug you reported is fixed in the latest version of
openoffice.org, which is due to be installed in the Debian FTP archive:

broffice.org_2.3.0~oog680m2-1_all.deb
  to pool/main/o/openoffice.org/broffice.org_2.3.0~oog680m2-1_all.deb
libmythes-dev_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/libmythes-dev_2.3.0~oog680m2-1_i386.deb
libuno-cil_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/libuno-cil_2.3.0~oog680m2-1_i386.deb
mozilla-openoffice.org_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/mozilla-openoffice.org_2.3.0~oog680m2-1_i386.deb
openoffice.org-base_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-base_2.3.0~oog680m2-1_i386.deb
openoffice.org-calc_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-calc_2.3.0~oog680m2-1_i386.deb
openoffice.org-common_2.3.0~oog680m2-1_all.deb
  to pool/main/o/openoffice.org/openoffice.org-common_2.3.0~oog680m2-1_all.deb
openoffice.org-core_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-core_2.3.0~oog680m2-1_i386.deb
openoffice.org-dbg_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-dbg_2.3.0~oog680m2-1_i386.deb
openoffice.org-dev-doc_2.3.0~oog680m2-1_all.deb
  to pool/main/o/openoffice.org/openoffice.org-dev-doc_2.3.0~oog680m2-1_all.deb
openoffice.org-dev_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-dev_2.3.0~oog680m2-1_i386.deb
openoffice.org-draw_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-draw_2.3.0~oog680m2-1_i386.deb
openoffice.org-dtd-officedocument1.0_2.3.0~oog680m2-1_all.deb
  to 
pool/main/o/openoffice.org/openoffice.org-dtd-officedocument1.0_2.3.0~oog680m2-1_all.deb
openoffice.org-evolution_2.3.0~oog680m2-1_i386.deb
  to 
pool/main/o/openoffice.org/openoffice.org-evolution_2.3.0~oog680m2-1_i386.deb
openoffice.org-filter-binfilter_2.3.0~oog680m2-1_i386.deb
  to 
pool/main/o/openoffice.org/openoffice.org-filter-binfilter_2.3.0~oog680m2-1_i386.deb
openoffice.org-filter-mobiledev_2.3.0~oog680m2-1_all.deb
  to 
pool/main/o/openoffice.org/openoffice.org-filter-mobiledev_2.3.0~oog680m2-1_all.deb
openoffice.org-gcj_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-gcj_2.3.0~oog680m2-1_i386.deb
openoffice.org-gnome_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-gnome_2.3.0~oog680m2-1_i386.deb
openoffice.org-gtk_2.3.0~oog680m2-1_i386.deb
  to pool/main/o/openoffice.org/openoffice.org-gtk_2.3.0~