Re: struct user conflicts on arm
On 17 December 2011 09:17, peter green peter.gr...@postgrad.manchester.ac.uk wrote: While we are talking about modifying sys/ucontext.h David Given raised another issue with that header (for those reading on the linaro list his post can be found at http://lists.debian.org/debian-arm/2011/12/msg00048.html) David GivenThis might be a good time to mention that on ARM, sys/ucontext.h defines David Givenboth symbols and preprocessor macros called R0, R1, R2, etc in the David Givenglobal namespace; this is causing one of my packages to fail to build David Givendue to symbol collision. David Given David GivenI'm fixing the package, but naming symbols stuff like that is still David Givenpretty antisocial... Does anyone know what the impact of renaming these to use a REG_ prefix like i386, amd64 and sparc do* would be? at worst the packages that had to be workaround on arm* for this, can have the workaround removed. Since you're in the process of fixing things for glibc/arm, would you mind also looking at WCHAR_MIN/MAX undefined for arm? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937 Thanks Konstantinos -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabsevwuj2s_yfmvkgb_tvbhdhqg94tyryxeyvzlwc05g9tc...@mail.gmail.com
Re: Bug#652356: please use argument-safe bswap macros on all architectures
On Sat, Dec 17, 2011 at 02:52:53AM +, Thorsten Glaser wrote: Aurelien Jarno dixit: I have dropped it in favor of the default version for the next upload. Why don’t you just use these? (Tested for 32-bit and 64-bit both.) I am not an m68k porter, and I am not planning to try things. m68k is lagging upstream wrt other architectures. Please work with upstream to fix things, then I can include tested and accepted patches. I’ve not looked at other architectures atm though. Other architectures don't have this problem with byteswap.h -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111217112848.gg9...@hall.aurel32.net
Processed: tagging 652428
Processing commands for cont...@bugs.debian.org: tags 652428 + pending Bug #652428 [eglibc] eglibc: [INTL:ru] Russian debconf templates translation update Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 652428: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652428 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.132412147731031.transcr...@bugs.debian.org
Re: [SRM] Uploading new upstream stable version to Squeeze?
On Wed, Dec 14, 2011 at 07:40:53PM +, Adam D. Barratt wrote: On Wed, 2011-12-14 at 07:54 +0100, Aurelien Jarno wrote: On Tue, Dec 13, 2011 at 06:41:54PM +, Adam D. Barratt wrote: On Tue, 2011-12-13 at 17:55 +0100, Aurelien Jarno wrote: Would it be possible to upload this, and do a call for test for people wanting to test it before the actual point release? That would also help people having problems due the bugs mentioned above. Ack, please go ahead. Thanks, I have just done the upload. Thanks; I've marked the package for acceptance at the next dinstall. As you pointed me on IRC, the build failed on arm, mips and mipsel. It's due to a file out of sync between the main repository and the ports repository hosting theses architectures. I have backported the missing change to version 2.11.3-2 and uploaded it. As for the sparc build failure, I have no idea what it could be, and I am not able to reproduce it. The package also built fine on the second try on the build daemons. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111217113626.gh9...@hall.aurel32.net
r5090 - in glibc-package/trunk/debian: . po
Author: aurel32
Date: 2011-12-17 11:31:05 + (Sat, 17 Dec 2011)
New Revision: 5090
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/po/ru.po
Log:
* Update Russian debconf translation, by Yuri Kozlov. Closes: #652428.
Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2011-12-17 01:00:24 UTC (rev
5089)
+++ glibc-package/trunk/debian/changelog2011-12-17 11:31:05 UTC (rev
5090)
@@ -3,6 +3,7 @@
* patches/m68k/local-byteswap.diff: drop the m68k optimized version of
bits/byteswap.h. Closes: #652356.
* Add m68k expected tests results.
+ * Update Russian debconf translation, by Yuri Kozlov. Closes: #652428.
-- Aurelien Jarno aure...@debian.org Wed, 14 Dec 2011 00:42:25 +0100
Modified: glibc-package/trunk/debian/po/ru.po
===
--- glibc-package/trunk/debian/po/ru.po 2011-12-17 01:00:24 UTC (rev 5089)
+++ glibc-package/trunk/debian/po/ru.po 2011-12-17 11:31:05 UTC (rev 5090)
@@ -1,26 +1,26 @@
# translation of ru.po to Russian
# Translation of glibc debconf .po to Russian
-# This file is distributed under the same license as the PACKAGE package.
+# This file is distributed under the same license as the eglibc package.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER.
#
# Yuri Kozlov kozlo...@gmail.com, 2006.
# Sergey Alyoshin alyoshi...@gmail.com, 2007, 2008.
-# Yuri Kozlov yu...@komyakino.ru, 2009.
+# Yuri Kozlov yu...@komyakino.ru, 2009, 2011.
msgid
msgstr
-Project-Id-Version: eglibc 2.9-18\n
+Project-Id-Version: eglibc 2.13-23\n
Report-Msgid-Bugs-To: egl...@packages.debian.org\n
POT-Creation-Date: 2011-10-30 11:52-0700\n
-PO-Revision-Date: 2009-06-27 12:46+0400\n
+PO-Revision-Date: 2011-12-17 09:26+0400\n
Last-Translator: Yuri Kozlov yu...@komyakino.ru\n
Language-Team: Russian debian-l10n-russ...@lists.debian.org\n
Language: ru\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
-X-Generator: KBabel 1.11.4\n
-Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n%10=2 n
-%10=4 (n%10010 || n%100=20) ? 1 : 2);\n
+X-Generator: Lokalize 1.0\n
+Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n%10=2
+n%10=4 (n%10010 || n%100=20) ? 1 : 2);\n
#. Type: multiselect
#. Choices
@@ -111,10 +111,10 @@
yourself is xdm - because automatic restart might disconnect your active X11
sessions.
msgstr
-Запущенные сервисы и программы, которые используют NSS, должны быть
+Запущенные службы и программы, которые используют NSS, должны быть
перезапущены, иначе они не будут способны выполнять поиск или
аутентификацию. В процессе установки возможно перезапустить некоторые
-сервисы (такие, как ssh или telnetd), но другие программы не могут быть
+службы (такие, как ssh или telnetd), но другие программы не могут быть
автоматически перезапущены. Одна из таких программ, которая требует ручной
остановки и перезапуска после обновления glibc, это xdm, так как её
автоматический перезапуск может отключить ваши активные сессии X11.
@@ -126,7 +126,7 @@
This script detected the following installed services which must be stopped
before the upgrade: ${services}
msgstr
-Этот сценарий определил следующие установленные сервисы, которые должны быть
+Этот сценарий определил следующие установленные службы, которые должны быть
остановлены перед обновлением: ${services}
#. Type: boolean
@@ -143,7 +143,7 @@
#. Description
#: ../debhelper.in/libc.templates:2001
msgid Services to restart for GNU libc library upgrade:
-msgstr Для обновления GNU libc должны быть перезапущены следующие сервисы:
+msgstr Для обновления GNU libc должны быть перезапущены следующие службы:
#. Type: string
#. Description
@@ -155,11 +155,11 @@
review the following space-separated list of init.d scripts for services to
be restarted now, and correct it if needed.
msgstr
-Запущенные сервисы и программы, которые используют NSS, должны быть
+Запущенные службы и программы, которые используют NSS, должны быть
перезапущены, иначе они не будут способны выполнять поиск или аутентификацию
-(для таких сервисов, как ssh, это может повлиять на возможность входа в
+(для таких служб, как ssh, это может повлиять на возможность входа в
систему). Просмотрите следующий разделённый пробелами список из скриптов
-init.d для сервисов, которые будут сейчас перезапущены и отредактируйте его
+init.d для служб, которые будут сейчас перезапущены и отредактируйте его
при необходимости.
#. Type: string
@@ -175,8 +175,7 @@
#. Description
#: ../debhelper.in/libc.templates:3001
msgid Failure restarting some services for GNU libc upgrade
-msgstr
-Произошёл сбой при перезапуске некоторых сервисов для обновления GNU libc
+msgstr Произошёл сбой при перезапуске некоторых служб для обновления GNU libc
#. Type: error
#. Description
@@
r5091 - glibc-package/branches/glibc-branch-squeeze/debian
Author: aurel32 Date: 2011-12-17 11:31:43 + (Sat, 17 Dec 2011) New Revision: 5091 Modified: glibc-package/branches/glibc-branch-squeeze/debian/changelog Log: Upload to stable Modified: glibc-package/branches/glibc-branch-squeeze/debian/changelog === --- glibc-package/branches/glibc-branch-squeeze/debian/changelog 2011-12-17 11:31:05 UTC (rev 5090) +++ glibc-package/branches/glibc-branch-squeeze/debian/changelog 2011-12-17 11:31:43 UTC (rev 5091) @@ -1,10 +1,10 @@ -eglibc (2.11.3-2) UNRELEASED; urgency=low +eglibc (2.11.3-2) stable; urgency=low * Add patches/arm/cvs-tls-unallocated.diff and patches/mips/cvs-tls-unallocated.diff to fix FTBFS on armel, mips and mipsel. - -- Aurelien Jarno aure...@debian.org Thu, 15 Dec 2011 09:46:52 +0100 + -- Aurelien Jarno aure...@debian.org Sat, 17 Dec 2011 02:09:58 +0100 eglibc (2.11.3-1) stable; urgency=low -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rbsus-00084f...@vasks.debian.org
Bug#652356: please use argument-safe bswap macros on all architectures
Aurelien Jarno dixit:
I am not an m68k porter, and I am not planning to try things. m68k is
lagging upstream wrt other architectures. Please work with upstream to
fix things, then I can include tested and accepted patches.
I’m not an m68k porter either, but this fix is easily done from working
with a libc (BSD libc in my case) skills. But okay. Am I guessing that
libc-po...@sourceware.org is “upstream”? It was hard to find information
about eglibc-ports on the ’net.
Anyway, here it is:
Dixi quod…
Aurelien Jarno dixit:
I have dropped it in favor of the default version for the next upload.
Why don’t you just use these? (Tested for 32-bit and 64-bit both.)
I’ve not looked at other architectures atm though.
--- usr/include/m68k-linux-gnu/bits/byteswap.h~2011-12-17
02:44:08.0 +
+++ usr/include/m68k-linux-gnu/bits/byteswap.h 2011-12-17 02:49:34.0
+
@@ -1,5 +1,5 @@
/* Macros to swap the order of bytes in integer values. m68k version.
- Copyright (C) 1997, 2002, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1997, 2002, 2008, 2011 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
@@ -50,15 +50,15 @@
#if defined __GNUC__ __GNUC__ = 2 !defined(__mcoldfire__)
# define __bswap_32(x) \
__extension__ \
- ({ unsigned int __bswap_32_v; \
- if (__builtin_constant_p (x))\
- __bswap_32_v = __bswap_constant_32 (x);\
+ ({ unsigned int __bswap_32_v, __bswap_32_x = (x); \
+ if (__builtin_constant_p (__bswap_32_x)) \
+ __bswap_32_v = __bswap_constant_32 (__bswap_32_x); \
else \
__asm__ __volatile__ (ror%.w %#8, %0;\
swap %0; \
ror%.w %#8, %0 \
: =d (__bswap_32_v) \
- : 0 ((unsigned int) (x))); \
+ : 0 (__bswap_32_x)); \
__bswap_32_v; })
#else
static __inline unsigned int
@@ -85,11 +85,12 @@
__extension__
\
({ union { unsigned long long int __ll; \
unsigned long int __l[2]; } __bswap_64_v, __bswap_64_r;\
- if (__builtin_constant_p (x))\
- __bswap_64_r.__ll = __bswap_constant_64 (x); \
+ unsigned long long int __bswap_64_x = (x);
\
+ if (__builtin_constant_p (__bswap_64_x)) \
+ __bswap_64_r.__ll = __bswap_constant_64 (__bswap_64_x);
\
else \
{ \
- __bswap_64_v.__ll = (x); \
+ __bswap_64_v.__ll = __bswap_64_x; \
__bswap_64_r.__l[0] = __bswap_32 (__bswap_64_v.__l[1]);\
__bswap_64_r.__l[1] = __bswap_32 (__bswap_64_v.__l[0]);\
} \
Aurelien Jarno dixit:
Other architectures don't have this problem with byteswap.h
I see. I didn’t know that for sure, so I suggested that in
general someone should look at it.
bye,
//mirabilos
PS: Please fix your MTA; hall.aurel32.net is sending 8-bit
data to a receiving MTA that does not announce 8BITMIME
support in its EHLO response. Or your MUA to use Quoted-
Printable by default.
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1112171247170@herc.mirbsd.org
Re: struct user conflicts on arm
Konstantinos Margaritis wrote:
Does anyone know what the impact of renaming these to use a REG_ prefix like
i386, amd64 and sparc do* would be?
at worst the packages that had to be workaround on arm* for this, can
have the workaround removed.
I have prepared a patch (attatched) that eliminates the dependency on
sys/procfs.h and renames R? to REG_R?. I have tested it by modifying the
header locally. I am now attempting to rebuild glibc with the patch.
After rebuilding glibc I will install it and attempt to rebuild GDB.
Please comment on the patch and advise on the best route for submission
(that is should I go through debian, through eglibc or direct to glibc?)
Since you're in the process of fixing things for glibc/arm
Note that I am not a glibc developer nor am I a dd (and even if I was a
dd I don't think I would NMU glibc). I'm just a user with an interest
in the future of debian on arm.
would you
mind also looking at WCHAR_MIN/MAX undefined for arm?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937
They most certainly are defined. The trouble is that WCHAR_MAX is defined
in a strange way.
#define __WCHAR_MAX ( (wchar_t) - 1 )
This definition is fine for normal c or c++ code but
it cannot be properly evaluated in the context of a
preprocessor conditional.
The bug report has a patch (actually a replacement for
an existing patch) which looks fine to me.
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h
===
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h 2006-08-17 01:23:58.0 +
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h 2011-12-17 12:52:43.0 +
@@ -23,7 +23,6 @@
#include features.h
#include signal.h
-#include sys/procfs.h
/* We need the signal context definitions even if they are not used
included in signal.h. */
@@ -35,47 +34,64 @@
#define NGREG 18
/* Container for all general registers. */
-typedef elf_gregset_t gregset_t;
+typedef greg_t gregset_t[NGREG];
/* Number of each register is the `gregset_t' array. */
enum
{
- R0 = 0,
-#define R0 R0
- R1 = 1,
-#define R1 R1
- R2 = 2,
-#define R2 R2
- R3 = 3,
-#define R3 R3
- R4 = 4,
-#define R4 R4
- R5 = 5,
-#define R5 R5
- R6 = 6,
-#define R6 R6
- R7 = 7,
-#define R7 R7
- R8 = 8,
-#define R8 R8
- R9 = 9,
-#define R9 R9
- R10 = 10,
-#define R10 R10
- R11 = 11,
-#define R11 R11
- R12 = 12,
-#define R12 R12
- R13 = 13,
-#define R13 R13
- R14 = 14,
-#define R14 R14
- R15 = 15
-#define R15 R15
+ REG_R0 = 0,
+#define REG_R0 REG_R0
+ REG_R1 = 1,
+#define REG_R1 REG_R1
+ REG_R2 = 2,
+#define REG_R2 REG_R2
+ REG_R3 = 3,
+#define REG_R3 REG_R3
+ REG_R4 = 4,
+#define REG_R4 REG_R4
+ REG_R5 = 5,
+#define REG_R5 REG_R5
+ REG_R6 = 6,
+#define REG_R6 REG_R6
+ REG_R7 = 7,
+#define REG_R7 REG_R7
+ REG_R8 = 8,
+#define REG_R8 REG_R8
+ REG_R9 = 9,
+#define REG_R9 REG_R9
+ REG_R10 = 10,
+#define REG_R10 REG_R10
+ REG_R11 = 11,
+#define REG_R11 REG_R11
+ REG_R12 = 12,
+#define REG_R12 REG_R12
+ REG_R13 = 13,
+#define REG_R13 REG_R13
+ REG_R14 = 14,
+#define REG_R14 REG_R14
+ REG_R15 = 15
+#define REG_R15 REG_R15
};
+struct _libc_fpstate
+{
+ struct
+ {
+unsigned int sign1:1;
+unsigned int unused:15;
+unsigned int sign2:1;
+unsigned int exponent:14;
+unsigned int j:1;
+unsigned int mantissa1:31;
+unsigned int mantissa0:32;
+ } fpregs[8];
+ unsigned int fpsr:32;
+ unsigned int fpcr:32;
+ unsigned char ftype[8];
+ unsigned int init_flag;
+};
/* Structure to describe FPU registers. */
-typedef elf_fpregset_t fpregset_t;
+typedef struct _libc_fpstate fpregset_t;
/* Context to describe whole processor state. This only describes
the core registers; coprocessor registers get saved elsewhere
Re: Bug#652356: please use argument-safe bswap macros on all architectures
On Sat, Dec 17, 2011 at 12:51:48PM +, Thorsten Glaser wrote: Aurelien Jarno dixit: I am not an m68k porter, and I am not planning to try things. m68k is lagging upstream wrt other architectures. Please work with upstream to fix things, then I can include tested and accepted patches. I’m not an m68k porter either, but this fix is easily done from working If you are not an m68k porter, you should simply stop to care about m68k porting issues. The glibc maintainers can add patches or pull patches from upstream to fix some issues, but they are not there to replace missing porters or upstream writing or testing patches. And we are not going to add random patches not even test built on m68k to fix this kind of issue, as anyway you would be the first to complain if it does not build or has side effects. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111217143154.ga...@volta.aurel32.net
Processed: tagging 636286
Processing commands for cont...@bugs.debian.org: tags 636286 + wontfix Bug #636286 [src:eglibc] eglibc: SIGSEGV in strcoll in UTF-8 locales with certain characters Added tag(s) wontfix. thanks Stopping processing here. Please contact me if you need assistance. -- 636286: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636286 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.132413272218347.transcr...@bugs.debian.org
Bug#652356: please use argument-safe bswap macros on all architectures
Aurelien Jarno dixit: If you are not an m68k porter, you should simply stop to care about m68k porting issues. I care about the entire Open Source ecosystem. (Way to motivate people.) bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you 13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺ 16:06⎜Draget:#cvs Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty 17:14⎜ldiain:#cvs Thanks big help you are :-) bioe007 mira|nwt: ty again 18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks 18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-) 18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that 21:57⎜bhuey:#cvs yeah, I really appreciate help 18:50⎜«grndlvl:#cvs» thankyou18:50⎜«grndlvl:#cvs» worked perfectly 20:50⎜paolo:#cvs i see. mirabilos, thnks for your support 00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx 18:44⎜«arcfide:#cvs» mirabilos, I am running OpenBSD. 18:59⎜«arcfide:#cvs» Hrm, yes, I see what you mean. 19:01⎜«arcfide:#cvs» Yeah, thanks for the help. 21:33⎜«CardinalFang:#cvs» Ugh. Okay. Sorry for the dumb question. Thank you 21:34⎜centosian:#cvs mirabilos: whoa that's sweet 21:52⎜«garrett__:#cvs» much appreciated «garrett__:#cvs» thanks for your time 23:39⎜symons:#cvs this worked, thank you very much 16:26⎜schweizer:#cvs ok thx, i'll try that 20:00⎜«stableable:#cvs» Thank you.20:50⎜«s833:#cvs» mirabilos: thanks a lot.19:34⎜bobbytek:#cvs Thanks for confirming :) 20:08⎜tsolox:#cvs ...works like a charm.. thanks mirabilos -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1112171443480@herc.mirbsd.org
eglibc override disparity
There are disparities between your recently accepted upload and the override file for the following file(s): libc6-i386_2.11.3-2_amd64.deb: package says priority is optional, override says standard. locales-all_2.11.3-2_amd64.deb: package says section is localization, override says libs. Please note that a list of new sections were recently added to the archive: cli-mono, database, debug, fonts, gnu-r, gnustep, haskell, httpd, java, kernel, lisp, localization, ocaml, php, ruby, vcs, video, xfce, zope. At this time a script was used to reclassify packages into these sections. If this is the case, please only reply to this email if the new section is inappropriate, otherwise please update your package at the next upload. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please file a bug against ftp.debian.org and explain why. Please INCLUDE the list of packages as seen above, or we won't be able to deal with your request due to missing information. Please make sure that the subject of the bug you file follows the following format: Subject: override: BINARY1:section/priority, [...], BINARYX:section/priority Include the justification for the change in the body of the mail please. [NB: this is an automatically generated mail; if you already filed a bug and have not received a response yet, please ignore this mail. Your bug needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rc0ov-0003ka...@franck.debian.org
Re: struct user conflicts on arm
On Sat, Dec 17, 2011 at 7:57 AM, peter green plugw...@p10link.net wrote: mind also looking at WCHAR_MIN/MAX undefined for arm? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937 They most certainly are defined. The trouble is that WCHAR_MAX is defined in a strange way. #define __WCHAR_MAX ( (wchar_t) - 1 ) This definition is fine for normal c or c++ code but it cannot be properly evaluated in the context of a preprocessor conditional. The bug report has a patch (actually a replacement for an existing patch) which looks fine to me. ISO C99 says that WCHAR_MAX must be a constant expression and the above definition is such an expression. Technically the program needs fixing (see below though for the standards matter but so do users), there is nothing wrong with a type cast and a constant value e.g. signed -1 converted to unsigned int (ARM GNU/Linux value for wchar_t). However, the real issue here is that it differs from x86, the most common architecture, and differences from x86 cause porting problems. The patch itself is insufficient because it doesn't take into account wordsize. When we switch to the 64-bit ARM ABI it should just work. Therefore you need to check for __WORDSIZE and *only* define a value if we are *not* 64-bits. You don't want to define anything for the 64-bit case until the 64-bit ARM ABI is out and finalized. Your patch to fix ucontext namespace pollution looks good, please post that to libc-ports for review and make sure to state what testing you've done with the patch. At a minimum you should run the glibc testsuite and build gdb with those newly installed headers. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADZpyiys+=ldp6x1tnycqh+cwo-ixajsr5dhu-vmn_b13hg...@mail.gmail.com
Re: [m68k] eglibc expected(?) testsuite results
On Sat, 17 Dec 2011, Thorsten Glaser wrote: Finn Thain dixit: It might be worth running the tests on physical hardware instead of an emulator. You just volunteered. You just promoted me to Debian Developer. Finn -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LNX.2.00.1112181005020.3372@nippy.intranet
Re: struct user conflicts on arm
ISO C99 says that WCHAR_MAX must be a constant expression and the above definition is such an expression. Technically the program needs fixing (see below though for the standards matter but so do users), there is nothing wrong with a type cast and a constant value e.g. signed -1 converted to unsigned int (ARM GNU/Linux value for wchar_t). However, the real issue here is that it differs from x86, the most common architecture, and differences from x86 cause porting problems. The patch itself is insufficient because it doesn't take into account wordsize. When we switch to the 64-bit ARM ABI it should just work. Therefore you need to check for __WORDSIZE and *only* define a value if we are *not* 64-bits. You don't want to define anything for the 64-bit case until the 64-bit ARM ABI is out and finalized. Thanks for the info, I may look at this later. The ucontext namespace pollution seems to be a bigger issue though. Your patch to fix ucontext namespace pollution looks good, please post that to libc-ports for review should I send it immidiately or should I wait until I have test results to give them? and make sure to state what testing you've done with the patch. At a minimum you should run the glibc testsuite Afaict the debian packaging automatically runs the testsuite and compares it against a list of expected failures (ideally that list would be empty but in real life). Right now i'm running into unexpected testsuite failures (unfortunately the last test build I didn't take a log of so i've got to run it again to find out details of the failures) but I do not know if those failures are related to my patch, related to changes in the build environment since the package was last built in debian or related to my hardware. Further testing will be neeed to establish that (and said testing takes a while, a beagleboard xm isn't exactly a speed demon). and build gdb with those newly installed headers. Will do once I get glibc built and installed, are there any specific tests you want doing with gdb or is testing it still builds sufficient?? Cheers, Carlos. Thanks for the help and advice so-far. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eed39e0.30...@p10link.net
İyi Seneler Diler Reklam Projesinde SON 10 GÜN...
Sayın Yetkili; Yeni yılda firmalarımız için hazırladığımız İYİ SENELER DİLER proje detayları aşağıdaki gibidir. 29-30-31 Aralık tarihlerinde her kanalda günde 7 defa şeklinde yayınlanacaktır. 1.SKYTURK 21 ADET 4SN.LİK KUŞAK REKLAM(84sn.) 2.KANALTURK 21 ADET 4SN.LİK KUŞAK REKLAM(84sn.) 3.KANAL24 21 ADET 4SN.LİK KUŞAK REKLAM(84sn.) 4.SAMANYOLU HABER 21 ADET 4SN.LİK KUŞAK REKLAM(84sn.) 5.TGRT HABER 21 ADET 4SN.LİK KUŞAK REKLAM(84sn.) 6.ULKE TV 21 ADET 4SN.LİK KUŞAK REKLAM(84sn.) 7.BUGUN TV 21 ADET 4SN.LİK KUŞAK REKLAM(84sn.) 8.A HABER 21 ADET 4SN.LİK KUŞAK REKLAM(84sn.) Toplam Spot: 168 adet kuşak reklam. Toplam Süre: 672sn. SADECE ve SADECE 3.350 TL+KDV Değerlendirmelerinizi bekler, İyi çalışmalar dilerim. Saygılarımla... ALTERNATİF MEDYA Büşra ALTAŞ Reklam Satış Müdürü T:0216 459 0 444 F:0216 459 0 555 bu...@alternatifmedya.tv busra.alternatifme...@gmail.com Not: Mail almak istemiyorsanız bu maili 'listenizden çıkmak istiyorum' diye cevaplamanız yeterlidir. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8127679475dc9382a267262d07241...@alternatifmedya.org
