Bug#739281: provides sendfile() prototype (in sys/sendfile.h) but no sendfile symbol
Package: libc0.1-dev Severity: normal Perhaps we could use emulated Linux-like sendfile() from Eric Wong. See: On 17/02/2014 09:12, Eric Wong wrote: Robert Millan r...@debian.org wrote: If you can write a Linux-compatible sendfile() which uses BSD-ish SYS_sendfile as backend, I guess they'll have no problem exporting a new symbol in glibc? After all, it's glibc who claims to provide it (via sys/sendfile.h). I emulate Linux sendfile on (non-Debian) FreeBSD that way in cmogstored. Feel free to grab the linux_sendfile() wrapper from cmogstored: http://bogomips.org/cmogstored.git/plain/http_get.c The linux_sendfile wrapper is trivial and I'm OK with relicensing from the existing GPLv3+ to any DFSG-approved license -- Robert Millan -- 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/530206eb.1000...@debian.org
Bug#665287: [#665287] clockid_t types (fwd)
2013/7/11 Petr Salinger petr.salin...@seznam.cz: The kernel support is available in HEAD (but not in STABLE-9). It could be easier to backport (kernel part of) http: //www.freebsd.org/cgi/query-pr.cgi?pr=16841 Uhm wrong PR number. into our kernel. Or even persuade upstream to MFC it into STABLE-9 ;-) Do you know which is the HEAD commit rev? -- Robert Millan -- 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/caofdtxps99nq+hghua9ps1wbjwnsmxygeogenqksy2hkvck...@mail.gmail.com
Bug#683825: please add assertion for non-zero status in _pthread_unlock()
Package: libc0.1 Version: 2.13-33 Severity: wishlist Tags: patch User: debian-...@lists.debian.org Usertags: kfreebsd The implementation of _pthread_unlock() doesn't react gracefully when it is asked to unlock a non-claimed resource. Thus, lock-__status can never be 0. Unfortunately when __status == 0 is passed, it will segfault in a very confusing way. Please use an assert() to give a more meaningful failure message. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-i386 (i686) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1 depends on: ii libc-bin 2.13-33 ii libgcc1 1:4.7.0-13 Versions of packages libc0.1 recommends: ii libc0.1-i686 2.13-33 Versions of packages libc0.1 suggests: ii debconf [debconf-2.0] 1.5.43 pn glibc-doc none ii locales2.13-33 ii locales-all [locales] 2.13-33 -- debconf information excluded --- a/linuxthreads/spinlock.c +++ b/linuxthreads/spinlock.c @@ -19,6 +19,7 @@ #include time.h #include stdlib.h #include limits.h +#include assert.h #include pthread.h #include internals.h #include spinlock.h @@ -172,6 +173,9 @@ int maxprio; #endif + /* spinlock must be taken in order to unlock it */ + assert (lock-__status != 0); + #if defined TEST_FOR_COMPARE_AND_SWAP if (!__pthread_has_cas) #endif
Bug#635192: Processed: Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
2012/6/29 Steven Chamberlain ste...@pyro.eu.org: #679198 is this bug. Did you mean #635192? Yes, sorry. In /usr/include/i386-kfreebsd-gnu/bits/fcntl.h : #if _POSIX_C_SOURCE = 200809L #define O_TTY_INIT 0x0008 /* Restore default termios attributes */ /* Defining O_CLOEXEC would break kfreebsd 8.1, see #635192 */ /* #define O_CLOEXEC 0x0010 */ #endif So it is undefined on purpose? Correct. Although leaving it undefined might be worse than defining it. E.g. consider programs doing: /* use O_CLOEXEC if possible */ #ifndef O_CLOEXEC #define O_CLOEXEC 0 #endif fd = open (..., O_CLOEXEC); // don't bother closing fd But the decision is up to glibc maintainers. -- Robert Millan -- 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/caofdtxosf-dnj+xy4ncbdh+parrpwkednniw6sluu9fl+jx...@mail.gmail.com
Bug#675606: LinuxThreads version bump
Package: libc0.1 Version: 2.13-32 Tags: patch Currently, perl relies on getconf to figure out whether threads have their own PID or not. They assume that this is true for linuxthreads but not for NPTL: $ getconf GNU_LIBPTHREAD_VERSION linuxthreads-0.10 $ getconf GNU_LIBPTHREAD_VERSION NPTL 2.11.3 Since this behaviour was changed in patched versions of linuxthreads, I think it'd be useful if they exposed a different version number so that users like perl can check for it. Patch attached. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-i386 (i386) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1 depends on: ii libc-bin 2.13-32 ii libgcc1 1:4.7.0-9 Versions of packages libc0.1 recommends: ii libc0.1-i686 2.13-32 Versions of packages libc0.1 suggests: ii debconf [debconf-2.0] 1.5.42 ii glibc-doc none ii locales2.13-32 ii locales-all [locales] 2.13-32 -- debconf information excluded Index: debian/patches/kfreebsd/local-use-thr-primitives.diff === --- debian/patches/kfreebsd/local-use-thr-primitives.diff (revision 5259) +++ debian/patches/kfreebsd/local-use-thr-primitives.diff (working copy) @@ -688,3 +688,8 @@ return errno; else return 0; +--- a/linuxthreads/Banner b/linuxthreads/Banner +@@ -1 +1 @@ +-linuxthreads-0.10 by Xavier Leroy ++linuxthreads-0.11 by Debian GNU/kFreeBSD
Bug#672774: build fix for multiarch-enabled kfreebsd-kernel-headers
Package: eglibc
Version: 2.13-32
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
As eglibc needs special handling for headers provided by kfreebsd-kernel-headers
package, it will FTBFS when kfreebsd-kernel-headers switches to multiarch-style
directories (e.g. /usr/include/x86_64-kfreebsd-gnu/machine).
Please consider fixing the problem preemptively using the attached patch. This
patch doesn't breal backward compatibility with current kfreebsd-kernel-headers
(0.79).
It's been tested on i386 and amd64, both with pristine kfreebsd-kernel-headers
and with a multiarch-enabled version.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-i386 (i386)
Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: debian/sysdeps/kfreebsd.mk
===
--- debian/sysdeps/kfreebsd.mk (revision 5248)
+++ debian/sysdeps/kfreebsd.mk (working copy)
@@ -18,21 +18,31 @@
endif
# Minimum Kernel supported
-with_headers = --with-headers=$(shell pwd)/debian/include --enable-kernel=$(call xx,MIN_KERNEL_SUPPORTED)
+with_headers = --with-headers=$(shell pwd)/debian/include:$(shell pwd)/debian/include/$(DEB_HOST_MULTIARCH) --enable-kernel=$(call xx,MIN_KERNEL_SUPPORTED)
KERNEL_HEADER_DIR = $(stamp)mkincludedir
$(stamp)mkincludedir:
rm -rf debian/include
mkdir debian/include
- for file in bsm net netatalk netipx nfs osreldate.h sys x86 vm ; do \
+ for file in bsm net netatalk netipx nfs osreldate.h sys x86 vm machine ; do \
if test -e $(KFREEBSD_HEADERS)/$$file ; then \
ln -s $(KFREEBSD_HEADERS)/$$file debian/include ; \
fi ; \
+ for arch in i386 x86_64 ; do \
+ if test -e $(KFREEBSD_HEADERS)/$${arch}-kfreebsd-gnu/$$file ; then \
+ mkdir -p debian/include/$${arch}-kfreebsd-gnu ; \
+ ln -s $(KFREEBSD_HEADERS)/$${arch}-kfreebsd-gnu/$$file debian/include/$${arch}-kfreebsd-gnu ; \
+ fi ; \
+ done ; \
done
# Link all machine directories. We can't just link machine
# because of explicit references to machine-amd64/* and
# machine-i386/*.
+ #
+ # FIXME: This can be removed when kfreebsd-kernel-headers switches to
+ # Multiarch-style directories.
+ #
find $(KFREEBSD_HEADERS) -maxdepth 1 -xtype d -name machine\* \
-exec ln -s '{}' debian/include ';'
@@ -42,7 +52,7 @@
touch $@
# Also to make configure happy.
-export CPPFLAGS = -isystem $(shell pwd)/debian/include
+CPPFLAGS = -isystem $(shell pwd)/debian/include -isystem $(shell pwd)/debian/include/$(DEB_HOST_MULTIARCH)
# This round of ugliness decomposes the FreeBSD kernel version number
# into an integer so it can be easily compared and then does so.
Index: debian/sysdeps/kfreebsd-amd64.mk
===
--- debian/sysdeps/kfreebsd-amd64.mk (revision 5248)
+++ debian/sysdeps/kfreebsd-amd64.mk (working copy)
@@ -8,10 +8,12 @@
i386_configure_target = i686-kfreebsd-gnu
i386_CC = $(CC) -m32
+i386_CPPFLAGS = -isystem $(shell pwd)/debian/include -isystem $(shell pwd)/debian/include/i386-kfreebsd-gnu
i386_CXX = $(CXX) -m32
i386_add-ons = ports linuxthreads $(add-ons)
i386_extra_cflags = -march=pentium4 -mtune=generic
i386_extra_config_options = $(extra_config_options) --disable-profile
+i386_with_headers = --with-headers=$(shell pwd)/debian/include:$(shell pwd)/debian/include/i386-kfreebsd-gnu --enable-kernel=$(call xx,MIN_KERNEL_SUPPORTED)
i386_slibdir = /lib32
i386_libdir = /usr/lib32
Index: debian/rules.d/build.mk
===
--- debian/rules.d/build.mk (revision 5248)
+++ debian/rules.d/build.mk (working copy)
@@ -23,6 +23,7 @@
@echo Configuring $(curpass)
rm -f $(DEB_BUILDDIR)/configparms
echo CC = $(call xx,CC) $(DEB_BUILDDIR)/configparms
+ echo CPPFLAGS = $(call xx,CPPFLAGS) $(DEB_BUILDDIR)/configparms
echo CXX = $(call xx,CXX) $(DEB_BUILDDIR)/configparms
echo BUILD_CC = $(BUILD_CC) $(DEB_BUILDDIR)/configparms
echo BUILD_CXX = $(BUILD_CXX) $(DEB_BUILDDIR)/configparms
@@ -66,6 +67,7 @@
cd $(DEB_BUILDDIR) \
CC=$(call xx,CC) \
CXX=$(call xx,CXX) \
+ CPPFLAGS=$(call xx,CPPFLAGS) \
AUTOCONF=false \
MAKEINFO=: \
$(CURDIR)/configure \
Bug#667687: new patch. eglibc upload urgently required!
2012/5/1 Aurelien Jarno aure...@debian.org: Are you sure this is correct? It seems to me that this can be a big problem if those packages migrate to testing before eglibc does. Not it's a mistake, I don't know how I managed that. I am going to fix that in an upload today. Thanks! -- Robert Millan -- 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/caofdtxmuq9fnklyktqbpwih0_unou6jbtp8eh+cg0qtokmu...@mail.gmail.com
Bug#667687: new patch. eglibc upload urgently required!
2012/4/22 Robert Millan r...@debian.org: I notice that my initial patch didn't handle the library dependency part. I'm attaching a new patch that fixes this issue. This makes new packages built against the patched libc0.1-dev depend on libc0.1 = 2.13-31. VERY IMPORTANT NOTICE: if this patch is introduced in a later version (rather than 2.13-31), you MUST change the version in debian/libc0.1.symbols.common to the first version that provides pthread_condattr_*etclock on GNU/kFreeBSD. Uhm, I notice you didn't include this part. Now packages that build with libc0.1-dev 2.13-31 won't have a versioned dependency on libc0.1 = 2.13-31. Are you sure this is correct? It seems to me that this can be a big problem if those packages migrate to testing before eglibc does. -- Robert Millan -- 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/caofdtxn33lcn-bmsfefx3k7y_waw8d2vd5obxpzbdy8hfmw...@mail.gmail.com
Bug#669960: buggy STAILQ_FOREACH_SAFE
Package: libc0.1-dev Version: 2.11.3-2 Tags: patch The STAILQ_FOREACH_SAFE implementation in sys/queue.h includes a broken reference and causes build failure on programs that use it. See attached patch. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1-dev depends on: ii kfreebsd-kernel-headers 0.53 kernel of FreeBSD headers for deve ii libc-dev-bin 2.11.3-2 Embedded GNU C Library: Developmen ii libc0.1 2.11.3-2 Embedded GNU C Library: Shared lib Versions of packages libc0.1-dev recommends: ii bcc [c-compiler] 0.16.17-3.1 16-bit x86 C compiler ii gcc [c-compiler] 4:4.4.5-1 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.5-4 The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.5-8 The GNU C compiler Versions of packages libc0.1-dev suggests: pn glibc-doc none (no description available) ii manpages-dev 3.27-1 Manual pages about using GNU/Linux -- no debconf information --- /usr/include/sys/queue.h~ 2012-04-21 19:43:25.0 +0200 +++ /usr/include/sys/queue.h2012-04-22 11:51:10.113666960 +0200 @@ -294,7 +294,7 @@ (var) = ((var)-field.stqe_next)) #defineSTAILQ_FOREACH_SAFE(var, head, field, tvar) \ - for ((var) = ((elm)-field.stqe_next); \ + for ((var) = ((head)-stqh_first); \ (var) ((tvar) = ((var)-field.stqe_next), 1);\ (var) = (tvar))
Bug#667687: new patch. eglibc upload urgently required!
Hi, I notice that my initial patch didn't handle the library dependency part. I'm attaching a new patch that fixes this issue. This makes new packages built against the patched libc0.1-dev depend on libc0.1 = 2.13-31. VERY IMPORTANT NOTICE: if this patch is introduced in a later version (rather than 2.13-31), you MUST change the version in debian/libc0.1.symbols.common to the first version that provides pthread_condattr_*etclock on GNU/kFreeBSD. Please could you give an estimate on when you'll be able to include it in glibc? This issue is currently blocking libsoup2.4 builds (see #663056). It does also have a major impact on other programs that use glib (see #667686). Also, the other fixes already committed to pkg-glibc are also quite important, as they are also blocking RC bugs in other packages. If you're all busy and can't prepare an upload right now, please say it so the package be NMUed. Thanks! -- Robert Millan setclock.diff Description: Binary data
Bug#667687: new patch. eglibc upload urgently required!
El 22 d’abril de 2012 17:08, Aurelien Jarno aure...@debian.org ha escrit: I have been mostly away from Debian stuff in the last weeks due to moving, but i'll try to catchup with glibc stuff during the next days and schedule an upload for the middle of the week. Good to hear, thanks. -- Robert Millan -- 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/caofdtxmxpmzu1gv_z+bdoq_ooxsm+d3qc3gui-esrnrwfyx...@mail.gmail.com
Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
tag 654783 pending thanks El 20 d’abril de 2012 8:47, Petr Salinger petr.salin...@seznam.cz ha escrit: In the original (plain linuxthreads) code, with thread implemented as freebsd process, the wakeup signal is sent to thread manager from kernel, after exit of thread. In current variant, with thread implemented as freebsd kernel thread, the wakeup signal is sent to thread manager from userspace, a few moments before exit. It is an expected race condition. It is also the reason, why || main_thread_exiting have been added. I expected, that loss of a wakeup does not matter, the child thread will be eaten only slightly later, when another thread exits and sends wake up. The only problem should be, when there is no another thread, it should be solved by || main_thread_exiting. But it does not suffice. The try eat dead child everytime is just workaround. Yep, eating dead children everytime doesn't sound like the cleanest option to me either ;-) The better way might be to add atomic counter [using gcc's __sync_fetch_and_add()] to track the number of expected dead or soon to be dead child and try to eat dead child when the number is above zero. Thanks for the heads-up. I notice you already fixed this in pkg-glibc SVN. Maybe it's not worth improving further... (IMHO time would be better spent on NPTL). Thank you! -- Robert Millan -- 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/CAOfDtXOQpP8BOjXXS5vHTLOFW=yr-kyvvw8fdg8syntxhi5...@mail.gmail.com
Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
CCing #663056 El 19 d’abril de 2012 1:12, Steven Chamberlain ste...@pyro.eu.org ha escrit: For now I still have Petr's change applied. I notice that libsoup2.4's connection-test (see #663056) has stopped failing. (Just had 100/100 test passes, was previously seeing about 50% failures.) Are you sure? You mean you tried 100 times? I don't know about connection-test, but context-test was a race condition. I'm also 100% sure Petr's change doesn't fix that (the reason for connection-test failure is well-known). After fixing context-test I got a connection-test pass, but I only tried once (at that time I assumed it was the same issue as context-test). -- Robert Millan -- 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/caofdtxpxc99mw9+gz8jqug0fs3to6rmdmh2tqy_wd2ufhz4...@mail.gmail.com
Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
CCing #575302 El 19 d’abril de 2012 1:12, Steven Chamberlain ste...@pyro.eu.org ha escrit: Also, perhaps related, I got through the (Python-powered) iceweasel 10.0.3esr test suite for the first time, without hangs (see #575302). Maybe this helped. That's really nice. Petr, could you give some explanation on that one-line patch you provided? Is it supposed to be the correct fix or is more work necessary? I'm not familiar with the whole picture but if you give some pointers I may be able to help. -- Robert Millan -- 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/CAOfDtXPRvgHCxe3igp43�7ny-vrkwdawkfgrpp6vd+80p...@mail.gmail.com
Bug#654783: about test_socket hang
El 18 d’abril de 2012 15:46, Steven Chamberlain ste...@pyro.eu.org ha escrit:
With it, I hit a tst-timer5 regression during build.
Don't worry about tst-timer5, it's a fake regression. Previously it
succeeded by exitting without testing anything.
On 18/04/12 07:02, Petr Salinger wrote:
- if (terminated_children || main_thread_exiting) {
+ if (1 || terminated_children || main_thread_exiting) {
Then I see 100/100 passes of test_socket. That used to hang always.
There are still occasional hangs in test_threading (about 20% of the
time) and also very rarely in test_signal (seen 1% of the time).
I did a few tries yesterday, in addition to the hangs you report I
also found that the testsuite itself is hanging. For example if you
disable test_socket and test_threading in debian/rules, it's still
possible that the process running the testsuite hangs after all tests
have finished.
--
Robert Millan
--
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/caofdtxnxyi_xut5aqduex1+wtxwsuc5aa4qp4rmnsevhhkm...@mail.gmail.com
Bug#667687: [PATCH] pthread_condattr_setclock()
tags 667687 patch thanks Hi, Here is a patch to implement pthread_condattr_setclock() and pthread_condattr_getclock(). It passes: - glibc testsuite - glib2.0 testsuite - libsoup2.4 testsuite Please consider including it with next upload. Note: as for #667686 and #663056, this palliates their effect (as it makes the problem go away on GNU/kFreeBSD) but doesn't fix them. It's possible that they pop up again in the future (e.g. when GNU/Hurd implements CLOCK_MONOTONIC). -- Robert Millan setclock.diff Description: Binary data
Bug#662018: fixed in glibc-bsd SVN
tags 642112 patch tags 662018 patch thanks Using patch tag for lack of a better word (upstream? pending?). Anyway these two can be fixed just by pulling latest code from glibc-bsd SVN. -- Robert Millan -- 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/CAOfDtXO5r4MdcwPswF=mhqmzql8yb8u6qa9ekr23jx7iy5m...@mail.gmail.com
Bug#667687: testcase
Testcase attached.
--
Robert Millan
#include stdio.h
#include pthread.h
#include time.h
void *
loop (void *null)
{
while (1);
}
int main ()
{
pthread_t thread;
pthread_mutex_t mutex;
pthread_cond_t cond;
pthread_condattr_t condattr;
struct timespec ts;
pthread_mutex_init (mutex, NULL);
pthread_condattr_init (condattr);
pthread_condattr_setclock (condattr, CLOCK_MONOTONIC);
pthread_cond_init (cond, condattr);
pthread_mutex_lock (mutex);
pthread_create(thread, NULL, loop, NULL);
clock_gettime (CLOCK_MONOTONIC, ts);
ts.tv_sec += 5;
pthread_cond_timedwait (cond, mutex, ts);
}
Bug#667448: pid 133(bootlogd) is using legacy pty devices - not logging anymore
Package: libc0.1 Version: 2.13-9 A few daemons (bootlogd and IIRC sshd as well) cause this kernel message to be printed in the console during boot. There was an attempt to fix this (see http://lists.debian.org/debian-bsd/2011/06/msg00111.html) but unfortunately the implementation of new ptys was not correct and had to be reverted (see #632452). -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120404064146.82414.98521.reportbug@thorin
Bug#642112: [PATCH] timers for kFreeBSD
El 1 d’abril de 2012 0:02, Robert Millan r...@debian.org ha escrit: I will test older kernels and port it to amd64. I added backward compatibility for kfreebsd-8.x. Tested with 8.1, 8.3~ and 9.0. In all cases it passes the full tst-timer* testsuite. This is an improvement over tst-timer4 and tst-timer5 [1] which didn't pass before my patch. Also tested with kfreebsd 8.1 on amd64 and passes the full tst-timer* testsuite. Note that ia32 userland on amd64 kernel can't run the new code (see #666728). When this happens it falls back to old compatibility code, so that there is no regression relative to previous version (passes the testsuite except tst-timer4 and tst-timer5, which fail as expected). TESTERS WANTED!!! If you can test this patch, specially with new situations (e.g. testsuites of other packages, or newer kernels on amd64, please do!). [1] Before my patch, tst-timer5 just pretends it works but doesn't. -- Robert Millan timer.diff Description: Binary data
Bug#642112: [PATCH] timers for kFreeBSD
El 31 de març de 2012 1:16, Robert Millan r...@debian.org ha escrit: Somewhat. My latest patch (after fixing other problems [1]) now passes tst-timer [2], but only *sometimes* (looks like a race). I isolated my code into a standalone app by renaming the timer_* functions and found that when run outside libc it nearly always (or always? can't recall) works, and when run as part of libc it nearly always fails, but sometimes works. Problem fixed [1]. Now it passes the whole testsuite, including tst-timer5 which was disabled before! \o/ Here's my latest patch. So far only tested with kfreebsd 9.0-1 on i386. I will test older kernels and port it to amd64. In the meantime, would someone be so kind to check if the testsuite problems in ruby, python, etc got better? [1] Grmf, turns out GCC was optimizing my busy wait loop into an infinite loop. Thankfully this taught me to ditch some of my broken cache coherency assumptions... -- Robert Millan timer.diff Description: Binary data
Bug#666454: sizeof(struct sigevent) is smaller than the kernel definition
Package: libc0.1-dev Version: 2.11.3-2 The kernel definition of sigevent_t includes a few bytes of reserved space, which are unused for now but may be eventually written by kernel when new features are implemented. AFAICT this is harmless for now, but it can become a problem in the future (e.g. buffer overflow). Unfortunately size of this struct can't be increased without breaking ABI. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1-dev depends on: ii kfreebsd-kernel-headers 0.53 kernel of FreeBSD headers for deve ii libc-dev-bin 2.11.3-2 Embedded GNU C Library: Developmen ii libc0.1 2.11.3-2 Embedded GNU C Library: Shared lib Versions of packages libc0.1-dev recommends: ii gcc [c-compiler] 4:4.4.5-1 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.5-4The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.5-8The GNU C compiler Versions of packages libc0.1-dev suggests: pn glibc-doc none (no description available) ii manpages-dev 3.27-1 Manual pages about using GNU/Linux -- no debconf information -- 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/20120330221350.21718.94432.reportbug@thorin
Bug#642112: [PATCH] timers for kFreeBSD
El 30 de març de 2012 9:11, Petr Salinger petr.salin...@seznam.cz ha escrit: /* Signal needed for the kernel-supported POSIX timer implementation. We can reuse the cancellation signal since we can distinguish cancellation from timer expirations. */ #define SIGTIMER SIGCANCEL Are you sure that the comment hold even for linuxthreads ? Somewhat. My latest patch (after fixing other problems [1]) now passes tst-timer [2], but only *sometimes* (looks like a race). I isolated my code into a standalone app by renaming the timer_* functions and found that when run outside libc it nearly always (or always? can't recall) works, and when run as part of libc it nearly always fails, but sometimes works. See attachment. [1] Among these, the test itself relied on undefined behaviour by calling timer_delete(-1). My current patch just replaces it with the newer version of the same test in nptl/sysdeps/pthread/tst-timer.c (which is a generic pthread test and doesn't depend on NPTL). [2] Tested on kfreebsd-10 / i386 only. -- Robert Millan timer.diff Description: Binary data
Bug#642112: [PATCH] timers for kFreeBSD
El 26 de març de 2012 0:14, Robert Millan r...@debian.org ha escrit: 9.0/i386 kernel running i386 binary - GOOD 10.0/i386 kernel running i386 binary - GOOD Sorry but my i386 tests were wrong, I did them while using unpatched libc (sigh). Here are some proper tests for i386 (same result using kfreebsd 8.3, 9.0 and 10-current): tst-timer: segfault tst-timer2: bad tst-timer3: good tst-timer4: bad tst-timer5: bad (not a regression, previously it was skipped) -- Robert Millan -- 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/CAOfDtXPKTj7�8ezSqP8rKKk38kNMASTq7hJaQ9wtswf6=o...@mail.gmail.com
Bug#642112: [PATCH] timers for kFreeBSD
El 25 de març de 2012 21:28, Christoph Egger christ...@debian.org ha escrit: It fails some regression tests on eglibc, is that on purpose? For tst-timer* I got the same failures with sid chroot on kfreebsd 8.1, however they work fine with kfreebsd-10. I don't have kfreebsd 8.3 and 9.0 handy atm (fsck'ed VM), but once we know we could fallback to old method using a getosreldate() check. If someone can test I'd appreciate, anyway I'll keep trying to recover that system :-( As for bug22 I doubt it has anything to do with my patch. In my tests it was working fine with kfreebsd 8.1 but failed with kfreebsd 10 (both using patched libc). Could it be a kernel-driven regression? -- Robert Millan -- 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/caofdtxmeib3x_hgojqkvtpwcazg_wsr3go7xodjps9+mrsh...@mail.gmail.com
Bug#642112: [PATCH] timers for kFreeBSD
El 25 de març de 2012 23:20, Christoph Egger christ...@debian.org ha escrit: My run was on latest kfreebsd-9 kernel from sid. I can test on my 8.3 systems later, though we'll need to get this working on 8.1 as that's what the buildds are running. Sorry I got confused. It works on all versions when it is built with i386 libc. Summary of my tests: 8.1/amd64 kernel running amd64 binary - BAD 8.1/amd64 kernel running i386 binary - GOOD 9.0/i386 kernel running i386 binary - GOOD 10.0/i386 kernel running i386 binary - GOOD -- Robert Millan -- 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/CAOfDtXN5V45XFWVbVJwouPA7pgWjZtvs8hdxGMCUuc=usxh...@mail.gmail.com
Bug#642112: [PATCH] timers for kFreeBSD
El 26 de març de 2012 0:14, Robert Millan r...@debian.org ha escrit: Sorry I got confused. It works on all versions when it is built with i386 libc. I think I know why, but can't fix it right now. timer_t is abused to store a pointer, but its size is only int32_t. timer_create() sets it here: *timerid = (timer_t) newp; and timer_settime() expects to find the whole 64-bit pointer there: struct timer *kt = (struct timer *) timerid; Unless someone has a bright idea, it seems that we'll have to store this in a global structure like the old LinuxThreads version was doing (c.f. __timer_alloc(), timer_ptr2id(), etc). -- Robert Millan -- 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/CAOfDtXOTOUXvAf97=LjxHyeLwDnguw8B_mfAbnP7uM9=pbh...@mail.gmail.com
Bug#662018: libsoup2.4: FTBFS on kfreebsd-*: test-suite FAIL: context-test
El 24 de març de 2012 1:46, Steven Chamberlain ste...@pyro.eu.org ha escrit: On 23/03/12 22:13, Robert Millan wrote: Actually it's in librt. Swapping that library with a patched version didn't change anything either. I'll try over the weekend to find space to do a full rebuild + normal dpkg install of eglibc though. Just FYI I'm close to producing a complete patch to implement monotonic timers. -- Robert Millan -- 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/caofdtxottt+ltlsxx6vdbfm4p3pqye6jz9t8qgwycj64f-2...@mail.gmail.com
Bug#642112: [PATCH] timers for kFreeBSD
Hi,
Attached patch adds a new implementation of timers for kFreeBSD. It
is heavily based on the Linux/NPTL counterpart.
I've verified that this fixes #642112 (timer_settime fails on kfreebsd
when timeout approaches max(time_t)) and #662018 (No support for
CLOCK_MONOTONIC). It also addresses a great deal (but not all) of
#665287 (bits/time.h advertises unsupported clockid_t types).
It's also likely that it fixes some of the problems outlined in
http://lists.debian.org/debian-bsd/2012/03/msg00149.html
Review and testing is much welcome, please do if you can.
Please don't commit to glibc-bsd repository yet. I haven't finished
testing it myself.
Thanks
--
Robert Millan
--- /dev/null
+++ b/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/kernel-posix-timers.h
@@ -0,0 +1,72 @@
+/* Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+ Contributed by Ulrich Drepper drep...@redhat.com, 2003.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public License as
+ published by the Free Software Foundation; either version 2.1 of the
+ License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; see the file COPYING.LIB. If not,
+ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA. */
+
+#include pthread.h
+#include setjmp.h
+#include signal.h
+#include sys/types.h
+
+/* The signal used for asynchronous cancelation. */
+#define SIGCANCEL (SIGTHR+1)
+
+/* Signal needed for the kernel-supported POSIX timer implementation.
+ We can reuse the cancellation signal since we can distinguish
+ cancellation from timer expirations. */
+#define SIGTIMER SIGCANCEL
+
+/* Callback to start helper thread. */
+extern void __start_helper_thread (void) attribute_hidden;
+
+/* Control variable for helper thread creation. */
+extern pthread_once_t __helper_once attribute_hidden;
+
+/* Whether helper thread is running. */
+extern int __helper_is_running attribute_hidden;
+
+/* List of active SIGEV_THREAD timers. */
+extern struct timer *__active_timer_sigev_thread attribute_hidden;
+/* Lock for the __active_timer_sigev_thread. */
+extern pthread_mutex_t __active_timer_sigev_thread_lock attribute_hidden;
+
+
+/* Type of timers in the kernel. */
+typedef int kernel_timer_t;
+
+
+/* Internal representation of timer. */
+struct timer
+{
+ /* Notification mechanism. */
+ int sigev_notify;
+
+ /* Timer ID returned by the kernel. */
+ kernel_timer_t ktimerid;
+
+ /* All new elements must be added after ktimerid. And if the thrfunc
+ element is not the third element anymore the memory allocation in
+ timer_create needs to be changed. */
+
+ /* Parameters for the thread to be started for SIGEV_THREAD. */
+ void (*thrfunc) (sigval_t);
+ sigval_t sival;
+ pthread_attr_t attr;
+
+ /* Next element in list of active SIGEV_THREAD timers. */
+ struct timer *next;
+};
--- /dev/null
+++ b/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/timer_create.c
@@ -0,0 +1,232 @@
+/* Copyright (C) 2003,2004, 2007, 2009 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+ Contributed by Ulrich Drepper drep...@redhat.com, 2003.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public License as
+ published by the Free Software Foundation; either version 2.1 of the
+ License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; see the file COPYING.LIB. If not,
+ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA. */
+
+#include errno.h
+#include pthread.h
+#include signal.h
+#include stdlib.h
+#include string.h
+#include time.h
+#include sysdep.h
+#include kernel-features.h
+#include kernel-posix-timers.h
+#include kernel-posix-cpu-timers.h
+
+#define __ASSUME_POSIX_TIMERS 1
+
+#ifdef SYS_ktimer_create
+# ifndef __ASSUME_POSIX_TIMERS
+static int compat_timer_create (clockid_t clock_id, struct sigevent *evp,
+ timer_t *timerid);
+# define timer_create static compat_timer_create
+# include nptl/sysdeps/pthread
Bug#662018: libsoup2.4: FTBFS on kfreebsd-*: test-suite FAIL: context-test
El 23 de març de 2012 2:24, Steven Chamberlain ste...@pyro.eu.org ha escrit: I don't /think/ it worked. I didn't have enough disk space to rebuild eglibc entirely. I built only libc0.1-i686, with your patch, and replaced only the libpthread library on my system and re-tested. The same problem as before. Actually it's in librt. -- Robert Millan -- 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/caofdtxptqnracbcwycb0u0y00pnpj9muu1ducjaeb0kkaka...@mail.gmail.com
Bug#662018: libsoup2.4: FTBFS on kfreebsd-*: test-suite FAIL: context-test
El 20 de març de 2012 21:38, Steven Chamberlain ste...@pyro.eu.org ha escrit:
Test case with extra debug info:
time = g_get_monotonic_time () + 5 * G_TIME_SPAN_SECOND;
debug_printf (1, g_cond_wait_until %lu\n, time);
if (g_cond_wait_until (test1_cond, test1_mutex, time))
g_thread_join (thread);
else {
time = g_get_monotonic_time ();
debug_printf (1, returned false at %lu\n, time);
debug_printf (1, timeout!\n);
g_thread_unref (thread);
errors++;
}
This smells like #662018.
I'll see if I can spend some time on it (this weekend if noone beats me to it).
--
Robert Millan
--
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/CAOfDtXN_pWt=5pJU2A1d65SDzVDED=iK=j1h5psvivpweuf...@mail.gmail.com
Bug#665287: bits/time.h advertises unsupported clockid_t types
Package: libc0.1-dev Version: 2.11.3-2 I found this while investigating #662018. bits/time.h advertises the following clockid_t types, however most of them are not provided. In fact, in most cases we don't have the facilities necessary to provide them: # define CLOCK_REALTIME 0 This one is ok AFAIK. # define CLOCK_PROCESS_CPUTIME_ID 2 This is not supported even on FreeBSD. On Linux-based systems, Linux 2.6.12 or later is required. I think this macro should be removed. # define CLOCK_THREAD_CPUTIME_ID 3 This one is supported on FreeBSD, however note that FreeBSD uses the kernel API (ktimer_create, etc), unlike GNU/kFreeBSD which currently implements CLOCK_REALTIME in userland. We *could* use the ktimer_* facilities for this, but it's awkward because ktimer_create() expects timer_t to be the kernel definition of this type (a pointer to struct __timer), whereas on GNU/kFreeBSD timer_t is an int32_t identifier. So if we really want to use the kernel facility we'd have to either bump ABI and fix the type disparity mess, or write an ugly kludge to map them (global hash table). # define CLOCK_MONOTONIC 4 This is #662018. Probably easy to implement on userland. # ifdef __USE_BSD #define CLOCK_VIRTUAL 1 #define CLOCK_PROF 2 #define CLOCK_UPTIME5 /* FreeBSD-specific. */ #define CLOCK_UPTIME_PRECISE7 /* FreeBSD-specific. */ #define CLOCK_UPTIME_FAST 8 /* FreeBSD-specific. */ #define CLOCK_REALTIME_PRECISE 9 /* FreeBSD-specific. */ #define CLOCK_REALTIME_FAST 10 /* FreeBSD-specific. */ #define CLOCK_MONOTONIC_PRECISE 11 /* FreeBSD-specific. */ #define CLOCK_MONOTONIC_FAST12 /* FreeBSD-specific. */ #define CLOCK_SECOND13 /* FreeBSD-specific. */ # endif These are accurately defined as FreeBSD-specific. Unavailable on GNU/kFreeBSD because of aforementioned issue. I don't think they should be defined unless/until we decide we're going to use ktimer_* API. Note that advertising unsupported features is very harmful because problems go undetected and even when they're detected it's hard to figure out what happened. This really needs to be resolved as quickly as possible. My proposal is to remove affected macros until we're certain that we will be able to support them. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1-dev depends on: ii kfreebsd-kernel-headers 0.53 kernel of FreeBSD headers for deve ii libc-dev-bin 2.11.3-2 Embedded GNU C Library: Developmen ii libc0.1 2.11.3-2 Embedded GNU C Library: Shared lib Versions of packages libc0.1-dev recommends: ii gcc [c-compiler] 4:4.4.5-1 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.5-4The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.5-8The GNU C compiler Versions of packages libc0.1-dev suggests: pn glibc-doc none (no description available) ii manpages-dev 3.27-1 Manual pages about using GNU/Linux -- no debconf information -- 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/20120322202149.6030.94522.reportbug@thorin
Bug#662018: libsoup2.4: FTBFS on kfreebsd-*: test-suite FAIL: context-test
El 22 de març de 2012 19:58, Robert Millan r...@debian.org ha escrit:
This smells like #662018.
I'll see if I can spend some time on it (this weekend if noone beats me to
it).
Please could someone test this? It's not correct, but it should do the trick.
--
Robert Millan
Index: eglibc-2.13/linuxthreads/sysdeps/pthread/timer_create.c
===
--- eglibc-2.13.orig/linuxthreads/sysdeps/pthread/timer_create.c
2012-03-22 20:32:57.0 +0100
+++ eglibc-2.13/linuxthreads/sysdeps/pthread/timer_create.c 2012-03-22
20:56:49.479267912 +0100
@@ -52,7 +52,7 @@
return -1;
}
- if (clock_id != CLOCK_REALTIME)
+ if (clock_id != CLOCK_REALTIME clock_id != CLOCK_MONOTONIC)
{
__set_errno (EINVAL);
return -1;
transition status
Hi, I figured it'd be useful to send a status update to summarize on what's done and what's missing: 659615: FTBFS on kfreebsd-amd64 - Fixed by maintainer since 15th Feb. 660395: xserver-xorg-input-joystick: FTBFS on kfreebsd-* - Fixed in NMU since 19th Feb. 660398: k3b: FTBFS on kfreebsd-* 660515: FTBFS on kfreebsd-* - Patch available. Tagged pending by maintainer since 20th Feb. Should it be NMUed? CCing maintainer. 660400: hal: FTBFS on kfreebsd-* - Fixed in NMU since 18th Feb. 660403: cdparanoia: FTFBS on kfreebsd-* - Unless there's further activity I recommend removing of kfreebsd-* binaries from testing. See http://bugs.debian.org./cgi-bin/bugreport.cgi?bug=660403#12 660397: qpxtool: FTBFS on kfreebsd-* 660401: dvd+rw-tools: FTBFS on kfreebsd-* - (eglibc bug) Tagged pending by maintainer since 20th Feb. Should it be NMUed? CCing maintainer. 659659: current version of ifconfig breaks D-I - Uploaded fix currently in NEW, expect RSN. 660396: sane-backends: FTBFS on kfreebsd-* - (kfreebsd-kernel-headers bug) Fixed today in 0.75. BinNMU? -- Robert Millan -- 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/CAOfDtXOD-EaosLx9utruzBQ5E_Va_V4=vdxhygrcxvqxfad...@mail.gmail.com
Re: sys/mount.h not C++ clean on kfreebsd
El 25 de febrer de 2012 12:56, Rene Engelhard r...@debian.org ha escrit: I would file a bug report but packages.debian.org doesn't seem to want to tell me what package sys/mount.h is in. libc0.1-dev There's already #660397 and #660401. -- Robert Millan -- 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/caofdtxoawacsese6fkeec87kk-jelepq2sow11ayzl_--xd...@mail.gmail.com
Re: transition status
El 25 de febrer de 2012 13:46, Adam D. Barratt a...@adam-barratt.org.uk ha escrit: 660397: qpxtool: FTBFS on kfreebsd-* 660401: dvd+rw-tools: FTBFS on kfreebsd-* - (eglibc bug) Tagged pending by maintainer since 20th Feb. Should it be NMUed? CCing maintainer. That's still less than a week. Aurelien, are there any plans for an upload in the near future? It seems that an upload is expected this weekend: http://lists.debian.org/debian-bsd/2012/02/msg00186.html btw, http://bugs.debian.org/src:kfreebsd-kernel-headers still lists two outstanding RC bugs. You need to use versioned -done mails, not just add fixed versions. Done. There's also mednafen and xine-lib, which I think have transitive dependencies via libsdl1.2? The latter still seems to be FTBFS on kfreebsd-amd64, despite the patch from #659615 being applied. I've just given it back for one last try. (as said in the other mail a k-k-h update is required) fwiw, there's a possibility that vlc might be a blocker, given that the new upstream version is FTBFS on multiple architectures (including kfreebsd-*). I'll have a look. -- Robert Millan -- 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/CAOfDtXOZxe64Tb+o1BUYX=9zgyudxftutx39jtzl_+8--lq...@mail.gmail.com
Bug#657810: sys/syscall.h and sys/errno.h
El 29 de gener de 2012 12:39, Petr Salinger petr.salin...@seznam.cz ha escrit: No, the bits/errno.h have to be part of eglibc, you can silently break ABI, by changing errno.h. Ok. I'll resync both files manually then. In fact, due to changes of ELAST it just happened, How do you increase ELAST then? Currently we need to increase it to 94 for ECAPMODE. -- Robert Millan -- 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/CAOfDtXNUfV_4DNCKGpvEgyD3BzWr-NRvG+5qj00pCz_=wt3...@mail.gmail.com
Bug#657810: sys/syscall.h and sys/errno.h
Package: libc0.1-dev kfreebsd-kernel-headers 0.70 includes properly patched versions of sys/syscall.h and sys/errno.h which could be used to compile glibc. Please consider using those instead of the in-tree copies. A patch for bits/errno.h is attached. sys/syscall.h can be used directly. -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Index: bits/errno.h === --- bits/errno.h (revision 4030) +++ bits/errno.h (working copy) @@ -41,124 +41,8 @@ # undef EILSEQ # undef ERANGE -#define EPERM 1 /* Operation not permitted */ -#define ENOENT 2 /* No such file or directory */ -#define ESRCH 3 /* No such process */ -#define EINTR 4 /* Interrupted system call */ -#define EIO 5 /* Input/output error */ -#define ENXIO 6 /* Device not configured */ -#define E2BIG 7 /* Argument list too long */ -#define ENOEXEC 8 /* Exec format error */ -#define EBADF 9 /* Bad file descriptor */ -#define ECHILD 10 /* No child processes */ -#define EDEADLK 11 /* Resource deadlock avoided */ - /* 11 was EAGAIN */ -#define ENOMEM 12 /* Cannot allocate memory */ -#define EACCES 13 /* Permission denied */ -#define EFAULT 14 /* Bad address */ -#define ENOTBLK 15 /* Block device required */ -#define EBUSY 16 /* Device busy */ -#define EEXIST 17 /* File exists */ -#define EXDEV 18 /* Cross-device link */ -#define ENODEV 19 /* Operation not supported by device */ -#define ENOTDIR 20 /* Not a directory */ -#define EISDIR 21 /* Is a directory */ -#define EINVAL 22 /* Invalid argument */ -#define ENFILE 23 /* Too many open files in system */ -#define EMFILE 24 /* Too many open files */ -#define ENOTTY 25 /* Inappropriate ioctl for device */ -#define ETXTBSY 26 /* Text file busy */ -#define EFBIG 27 /* File too large */ -#define ENOSPC 28 /* No space left on device */ -#define ESPIPE 29 /* Illegal seek */ -#define EROFS 30 /* Read-only filesystem */ -#define EMLINK 31 /* Too many links */ -#define EPIPE 32 /* Broken pipe */ +#include sys/errno.h -/* math software */ -#define EDOM 33 /* Numerical argument out of domain */ -#define ERANGE 34 /* Result too large */ - -/* non-blocking and interrupt i/o */ -#define EAGAIN 35 /* Resource temporarily unavailable */ -#define EWOULDBLOCK EAGAIN /* Operation would block */ -#define EINPROGRESS 36 /* Operation now in progress */ -#define EALREADY 37 /* Operation already in progress */ - -/* ipc/network software -- argument errors */ -#define ENOTSOCK 38 /* Socket operation on non-socket */ -#define EDESTADDRREQ 39 /* Destination address required */ -#define EMSGSIZE 40 /* Message too long */ -#define EPROTOTYPE 41 /* Protocol wrong type for socket */ -#define ENOPROTOOPT 42 /* Protocol not available */ -#define EPROTONOSUPPORT 43 /* Protocol not supported */ -#define ESOCKTNOSUPPORT 44 /* Socket type not supported */ -#define EOPNOTSUPP 45 /* Operation not supported */ -#define ENOTSUP EOPNOTSUPP /* Operation not supported */ -#define EPFNOSUPPORT 46 /* Protocol family not supported */ -#define EAFNOSUPPORT 47 /* Address family not supported by protocol family */ -#define EADDRINUSE 48 /* Address already in use */ -#define EADDRNOTAVAIL 49 /* Can't assign requested address */ - -/* ipc/network software -- operational errors */ -#define ENETDOWN 50 /* Network is down */ -#define ENETUNREACH 51 /* Network is unreachable */ -#define ENETRESET 52 /* Network dropped connection on reset */ -#define ECONNABORTED 53 /* Software caused connection abort */ -#define ECONNRESET 54 /* Connection reset by peer */ -#define ENOBUFS 55 /* No buffer space available */ -#define EISCONN 56 /* Socket is already connected */ -#define ENOTCONN 57 /* Socket is not connected */ -#define ESHUTDOWN 58 /* Can't send after socket shutdown */ -#define ETOOMANYREFS 59 /* Too many references: can't splice */ -#define ETIMEDOUT 60 /* Operation timed out */ -#define ECONNREFUSED 61 /* Connection refused */ - -#define ELOOP 62 /* Too many levels of symbolic links */ -#define ENAMETOOLONG 63 /* File name too long */ - -/* should be rearranged */ -#define EHOSTDOWN 64 /* Host is down */ -#define EHOSTUNREACH 65 /* No route to host */ -#define ENOTEMPTY 66 /* Directory not empty */ - -/* quotas mush */ -#define EPROCLIM 67 /* Too many processes */ -#define EUSERS 68 /* Too many users */ -#define EDQUOT 69 /* Disc quota exceeded */ - -/* Network File System */ -#define ESTALE 70 /* Stale NFS file handle */ -#define EREMOTE 71 /* Too many levels of remote in path */ -#define EBADRPC 72 /* RPC struct is bad */ -#define ERPCMISMATCH 73 /* RPC version wrong */ -#define EPROGUNAVAIL 74 /* RPC prog. not avail */ -#define EPROGMISMATCH 75 /* Program version wrong */ -#define EPROCUNAVAIL 76 /* Bad procedure for program */ - -#define ENOLCK 77
Bug#649185: FTBFS on kfreebsd-amd64
Package: eglibc Version: 2.13-21 With current kfreebsd-amd64 sid environment: # # Testsuite failures, someone should be working towards # fixing these! They are listed here for the purpose of # regression testing during builds. # Format: Failed test, Error Make error code [(ignored)] # annexc.out, Error 1 (ignored) check-localplt.out, Error 1 tst-aio10.out, Error 1 tst-aio4.out, Error 1 tst-aio9.out, Error 1 tst-clock1.out, Error 1 tst-longjmp_chk.out, Error 1 tst-mknodat.out, Error 1 tst-renameat.out, Error 1 tst-timer4.out, Error 1 tst-waitid.out, Error 1 tst-writev.out, Error 1 *** Encountered regressions that don't match expected failures: tst-clock1.out, Error 1 Note: all my filesystems are ZFS with noatime Contents of tst-clock1.out: $ cat ./build-tree/kfreebsd-amd64-libc/linuxthreads/tst-clock1.out diff 0-1: 0.399498734 diff 1-2: 0.100750224 diff 2-3: 0.100989666 diff 3-4: 0.101012583 diff 4-5: 0.101981538 diff 5-6: 0.100993701 difference between thread 6 and 7 too small (-1.808926071) -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/2018171708.40325.64131.reportbug@thorin
Bug#646918: /usr/include/sys/nlist_aout.h:51: error: redefinition of ‘struct nlist’
Package: libc0.1-dev
Version: 2.11.2-10
Severity: normal
The following code compiles on FreeBSD but not on Debian GNU/kFreeBSD:
#include a.out.h
#include sys/nlist_aout.h
main ()
{
struct nlist nl;
nl.n_un.n_strx = 0;
}
It appears there are conflicting definitions of struct nlist, one of them in
libc-dev and the other in kfreebsd-kernel-headers:
$ gcc /tmp/test.c -o /tmp/test
In file included from /tmp/test.c:2:
/usr/include/sys/nlist_aout.h:51: error: redefinition of ��struct nlist��
/tmp/test.c: In function ��main��:
/tmp/test.c:7: error: ��struct nlist�� has no member named ��n_un��
-- System Information:
Debian Release: 6.0.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc0.1-dev depends on:
ii kfreebsd-kernel-headers 0.53 kernel of FreeBSD headers for deve
ii libc-dev-bin 2.11.2-10 Embedded GNU C Library: Developmen
ii libc0.1 2.11.2-10 Embedded GNU C Library: Shared lib
Versions of packages libc0.1-dev recommends:
ii gcc [c-compiler] 4:4.4.5-1 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.5-4The GNU C compiler
ii gcc-4.4 [c-compiler] 4.4.5-8The GNU C compiler
Versions of packages libc0.1-dev suggests:
pn glibc-doc none (no description available)
ii manpages-dev 3.27-1 Manual pages about using GNU/Linux
-- no debconf information
#include a.out.h
#include sys/nlist_aout.h
main ()
{
struct nlist nl;
nl.n_un.n_strx = 0;
}
Bug#639658: altered pthread implementation for GNU/kFreeBSD
Hi,
Please would you consider including Petr's patch in experimental
uploads so that it can be more widely tested?
Thanks!
2011/9/20 Petr Salinger petr.salin...@seznam.cz:
Hi,
as you might know, our eglibc pthread implementation
is still linuxthreads based. I tried to alter current
LT version to use some thread primitives from kernel.
Instead of processes it uses kernel threads,
there is still a thread manager.
But it should fix #639658.
The hackish patch is attached, the geting/seting
of pthread scheduler priority have to be reimplemented.
There is no regression in our glibc testsuite on ka.
But it definitely needs more testing, on both real HW
and inside emulators.
Please test this partial patch, upload into experimental would be nice.
Petr
--
Robert Millan
diff -u a/linuxthreads/attr.c b/linuxthreads/attr.c
--- a/linuxthreads/attr.c 2006-08-17 03:23:45.0 +0200
+++ b/linuxthreads/attr.c 2011-09-20 17:02:25.0 +0200
@@ -365,11 +365,11 @@
? PTHREAD_CREATE_DETACHED
: PTHREAD_CREATE_JOINABLE);
- attr-__schedpolicy = __sched_getscheduler (descr-p_pid);
+ attr-__schedpolicy = __sched_getscheduler (getpid());
if (attr-__schedpolicy == -1)
return errno;
- if (__sched_getparam (descr-p_pid,
+ if (__sched_getparam (getpid(),
(struct sched_param *) attr-__schedparam) != 0)
return errno;
diff -u a/linuxthreads/cancel.c b/linuxthreads/cancel.c
--- a/linuxthreads/cancel.c 2006-08-17 03:23:45.0 +0200
+++ b/linuxthreads/cancel.c 2011-09-20 17:02:25.0 +0200
@@ -89,7 +89,7 @@
int pthread_cancel(pthread_t thread)
{
pthread_handle handle = thread_handle(thread);
- int pid;
+ long ktid;
int dorestart = 0;
pthread_descr th;
pthread_extricate_if *pextricate;
@@ -112,7 +112,7 @@
}
pextricate = th-p_extricate;
- pid = th-p_pid;
+ ktid = th-p_ktid;
/* If the thread has registered an extrication interface, then
invoke the interface. If it returns 1, then we succeeded in
@@ -139,7 +139,7 @@
if (dorestart)
restart(th);
else
-kill(pid, __pthread_sig_cancel);
+__thr_kill(ktid, __pthread_sig_cancel);
return 0;
}
diff -u a/linuxthreads/descr.h b/linuxthreads/descr.h
--- a/linuxthreads/descr.h 2011-09-20 19:38:20.0 +0200
+++ b/linuxthreads/descr.h 2011-09-20 17:44:58.0 +0200
@@ -26,6 +26,42 @@
#include lowlevellock.h
#include tls.h
+
+extern long int syscall (long int __sysno, ...);
+#include sys/syscall.h
+// should be in sys/thr.h
+struct rtprio;
+struct thr_param {
+void(*start_func)(void *); /* thread entry function. */
+void*arg; /* argument for entry function. */
+char*stack_base;/* stack base address. */
+size_t stack_size; /* stack size. */
+char*tls_base; /* tls base address. */
+size_t tls_size; /* tls size. */
+long*child_tid; /* address to store new TID. */
+long*parent_tid;/* parent accesses the new TID here. */
+int flags; /* thread flags. */
+struct rtprio *rtp; /* Real-time scheduling priority */
+void*spare[3]; /* TODO: cpu affinity mask etc. */
+};
+
+#define KTID_TERMINATED 1
+static inline int __thr_self(long *ktid)
+{ return syscall(SYS_thr_self, ktid);};
+
+static inline int __thr_kill(long ktid, int signo)
+{ return syscall(SYS_thr_kill, ktid, signo);};
+
+static inline int __thr_exit(long *ktid) // also *ktid = KTID_TERMINATED, wakeup(ktid)
+{ return syscall(SYS_thr_exit, ktid);}; // returns only for last thread in process
+
+static inline int __thr_new(struct thr_param *param, int param_size)
+{ return syscall(SYS_thr_new, param, param_size);};
+
+static inline int __lll_wait(long *addr, long val)
+{ return syscall(SYS__umtx_op, addr, UMTX_OP_WAIT, val, NULL, NULL);};
+
+
/* Fast thread-specific data internal to libc. */
enum __libc_tsd_key_t { _LIBC_TSD_KEY_MALLOC = 0,
_LIBC_TSD_KEY_DL_ERROR,
@@ -202,6 +238,8 @@
size_t p_alloca_cutoff; /* Maximum size which should be allocated
using alloca() instead of malloc(). */
/* New elements must be added at the end. */
+ long p_ktid; /* kernel thread ID */
+
/* This member must be last. */
char end_padding[];
diff -u a/linuxthreads/join.c b/linuxthreads/join.c
--- a/linuxthreads/join.c 2006-08-17 03:23:45.0 +0200
+++ b/linuxthreads/join.c 2011-09-20 17:02:25.0 +0200
@@ -89,6 +89,9 @@
}
/* Threads other than the main one terminate without flushing stdio streams
or running atexit functions. */
+
+ __thr_kill(__manager_thread-p_ktid, __pthread_sig_cancel);
+ __thr_exit((self-p_ktid));
_exit(0);
}
diff -u a/linuxthreads/manager.c b/linuxthreads/manager.c
--- a/linuxthreads/manager.c 2006-08-17 03:23:45.0 +0200
+++ b/linuxthreads/manager.c 2011
Bug#644023: FTBFS on kfreebsd-i386 (testsuite failure)
2011/10/1 Jonathan Nieder jrnie...@gmail.com: Robert Millan wrote: Encountered regressions that don't match expected failures: bug22.out, Error 1 And what is the content of bug22.out? Empty file. -- Robert Millan -- 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/CAOfDtXP9nAWspjACGN8R33iRf2=w4eohd-nygohzmfpuq_j...@mail.gmail.com
Bug#644023: FTBFS on kfreebsd-i386 (testsuite failure)
2011/10/2 Aurelien Jarno aurel...@aurel32.net: bug22 basically tries to write /dev/null. Is /dev correctly mounted on your system? Yes. -- Robert Millan -- 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/CAOfDtXP48=2V03h5R1B9AAP5SGKpwAhueM2uQ3PfM7E=oje...@mail.gmail.com
Bug#644023: FTBFS on kfreebsd-i386
2011/10/2 Petr Salinger petr.salin...@seznam.cz: What is your CPU ? It happens also on my PC (in 32 bit pass), with Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (note: running kfreebsd-i386 as a VirtualBox guest) -- Robert Millan -- 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/CAOfDtXMA23=g2vcopstxig5vewe5mtix2inty2kk1wwvkkt...@mail.gmail.com
Bug#644023: FTBFS on kfreebsd-i386 (testsuite failure)
2011/10/2 Robert Millan r...@debian.org: 2011/10/1 Jonathan Nieder jrnie...@gmail.com: Robert Millan wrote: Encountered regressions that don't match expected failures: bug22.out, Error 1 And what is the content of bug22.out? Empty file. OTOH, running it from command-line results in: Timed out: killed the child process -- Robert Millan -- 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/caofdtxmrea7egw0cw2+cadnrig-dyybk6e_rfcvd8a6ayvw...@mail.gmail.com
Bug#644023: FTBFS on kfreebsd-i386 (testsuite failure)
2011/10/2 Robert Millan r...@debian.org: OTOH, running it from command-line results in: Timed out: killed the child process More specifically, it is sitting on waitpid() call (line 341). Could this be related to #639658 ? -- Robert Millan -- 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/caofdtxpm6412qkbixh2gd6jr1ovbzufpcvzgdcx-hqsxciz...@mail.gmail.com
Bug#644023: FTBFS on kfreebsd-i386 (testsuite failure)
Package: eglibc Version: 2.13-21 User: debian-...@lists.debian.org Usertags: kfreebsd From build log: # # Testsuite failures, someone should be working towards # fixing these! They are listed here for the purpose of # regression testing during builds. # Format: Failed test, Error Make error code [(ignored)] # annexc.out, Error 1 (ignored) bug22.out, Error 1 check-localplt.out, Error 1 tst-aio10.out, Error 1 tst-aio4.out, Error 1 tst-aio9.out, Error 1 tst-longjmp_chk.out, Error 1 tst-mknodat.out, Error 1 tst-renameat.out, Error 1 tst-timer4.out, Error 1 tst-waitid.out, Error 1 *** Encountered regressions that don't match expected failures: bug22.out, Error 1 make: *** [/home/rmh/eglibc/eglibc-2.13/stamp-dir/check_libc] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-i386 (i686) Kernel: kFreeBSD 8.1-1-686 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20111001205603.93080.54316.reportbug@debian
Bug#637424: Implement amd64_set_gsbase and i386_set_fsbase
2011/8/17 Petr Salinger petr.salin...@seznam.cz: The best way should be to alter wine to use sysarch directly, just sysarch (AMD64_SET_GSBASE, teb) instead of amd64_set_gsbase( teb ) This seems gratuitous. I don't care myself, but I expect wine developers will. I won't be defending a gratuitous position to wine developers. I can only defend things I believe in. The second option is to insert into machine/sysarch.h always inline functions. I don't see a problem with using inline functions. Shall we do this? -- Robert Millan -- 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/caofdtxpd+unuavhtfmcnwso8tdwrhbkczheu1_x9pap13if...@mail.gmail.com
Bug#637424: Implement i386_get_gsbase i386_get_fsbase i386_set_gsbase i386_set_fsbase amd64_get_gsbase amd64_get_fsbase amd64_set_gsbase amd64_set_fsbase
2011/8/11 Robert Millan r...@debian.org:
2011/8/11 Aurelien Jarno aurel...@aurel32.net:
In any case, they will have to wait for 2.14. Anyway, what are the uses
cases for these?
wine needs amd64_set_gsbase and i386_set_fsbase.
Here's a new patch which only implements the syscall stubs needed by
wine (amd64_set_gsbase and i386_set_fsbase).
This patch also corrects a critical mistake: in setters, the pointers
are passed by reference just like with getters (this confusion led me
to report non-bug #637528, more details there).
--
Robert Millan
Index: i386/Makefile
===
--- i386/Makefile (revision 3681)
+++ i386/Makefile (working copy)
@@ -15,5 +15,5 @@
# For sys/vm86.h.
sysdep_routines += i386_vm86
# For machine/sysarch.h.
-sysdep_routines += i386_get_ldt i386_set_ldt
+sysdep_routines += i386_get_ldt i386_set_ldt i386_set_fsbase
endif
Index: i386/Versions
===
--- i386/Versions (revision 3681)
+++ i386/Versions (working copy)
@@ -4,4 +4,7 @@
ioperm; iopl;
i386_get_ldt; i386_set_ldt;
}
+ GLIBC_2.13 {
+i386_set_fsbase;
+ }
}
Index: i386/i386_set_fsbase.c
===
--- i386/i386_set_fsbase.c (revision 0)
+++ i386/i386_set_fsbase.c (revision 0)
@@ -0,0 +1,25 @@
+/* Copyright (C) 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
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+#include machine/sysarch.h
+
+int
+i386_set_fsbase (void *addr)
+{
+ return __sysarch (I386_SET_FSBASE, addr);
+}
Index: x86_64/Makefile
===
--- x86_64/Makefile (revision 3681)
+++ x86_64/Makefile (working copy)
@@ -14,4 +14,6 @@
ifeq ($(subdir),misc)
# For sys/io.h and sys/perm.h.
sysdep_routines += iopl ioperm
+# For machine/sysarch.h.
+sysdep_routines += amd64_set_gsbase
endif
Index: x86_64/amd64_set_gsbase.c
===
--- x86_64/amd64_set_gsbase.c (revision 0)
+++ x86_64/amd64_set_gsbase.c (revision 0)
@@ -0,0 +1,25 @@
+/* Copyright (C) 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
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+#include machine/sysarch.h
+
+int
+amd64_set_gsbase (void *addr)
+{
+ return __sysarch (AMD64_SET_GSBASE, addr);
+}
Index: x86_64/Versions
===
--- x86_64/Versions (revision 3681)
+++ x86_64/Versions (working copy)
@@ -5,4 +5,7 @@
GLIBC_2.10 {
ioperm;
}
+ GLIBC_2.13 {
+amd64_set_gsbase;
+ }
}
Bug#637424: Implement i386_get_gsbase i386_get_fsbase i386_set_gsbase i386_set_fsbase amd64_get_gsbase amd64_get_fsbase amd64_set_gsbase amd64_set_fsbase
2011/8/12 Aurelien Jarno aurel...@aurel32.net: wine needs amd64_set_gsbase and i386_set_fsbase. So what do we do at the end? Couldn't wine simply use the sysarch() function? I can't answer that, we'd have to ask wine developers. -- Robert Millan -- 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/CAOfDtXMWhsEB+-CVjTQxgNHQsQBGK=52Msx33Bgge8qLN+f=m...@mail.gmail.com
Bug#637424: Implement i386_get_gsbase i386_get_fsbase i386_set_gsbase i386_set_fsbase amd64_get_gsbase amd64_get_fsbase amd64_set_gsbase amd64_set_fsbase
Package: libc0.1
Version: 2.13-15
Severity: wishlist
Tags: patch
This patch implements the following syscall stubs:
i386_get_gsbase
i386_get_fsbase
i386_set_gsbase
i386_set_fsbase
amd64_get_gsbase
amd64_get_fsbase
amd64_set_gsbase
amd64_set_fsbase
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=ca_AD.utf8, LC_CTYPE=ca_AD.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc0.1 depends on:
ii libc-bin 2.13-15Embedded GNU C Library: Binaries
ii libgcc1 1:4.6.1-4 GCC support library
libc0.1 recommends no packages.
Versions of packages libc0.1 suggests:
ii debconf [debconf-2.0] 1.5.41 Debian configuration management sy
pn glibc-doc none (no description available)
ii locales 2.13-14Embedded GNU C Library: National L
-- debconf information excluded
Index: i386/i386_get_gsbase.c
===
--- i386/i386_get_gsbase.c (revision 0)
+++ i386/i386_get_gsbase.c (revision 0)
@@ -0,0 +1,25 @@
+/* Copyright (C) 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
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+#include machine/sysarch.h
+
+int
+i386_get_gsbase (void **addr)
+{
+ return __sysarch (I386_GET_GSBASE, addr);
+}
Index: i386/i386_set_gsbase.c
===
--- i386/i386_set_gsbase.c (revision 0)
+++ i386/i386_set_gsbase.c (revision 0)
@@ -0,0 +1,25 @@
+/* Copyright (C) 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
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+#include machine/sysarch.h
+
+int
+i386_set_gsbase (void *addr)
+{
+ return __sysarch (I386_SET_GSBASE, addr);
+}
Index: i386/Makefile
===
--- i386/Makefile (revision 3681)
+++ i386/Makefile (working copy)
@@ -15,5 +15,5 @@
# For sys/vm86.h.
sysdep_routines += i386_vm86
# For machine/sysarch.h.
-sysdep_routines += i386_get_ldt i386_set_ldt
+sysdep_routines += i386_get_ldt i386_set_ldt i386_get_fsbase i386_set_fsbase i386_get_gsbase i386_set_gsbase
endif
Index: i386/i386_get_fsbase.c
===
--- i386/i386_get_fsbase.c (revision 0)
+++ i386/i386_get_fsbase.c (revision 0)
@@ -0,0 +1,25 @@
+/* Copyright (C) 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
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+#include machine/sysarch.h
+
+int
+i386_get_fsbase (void **addr)
+{
+ return __sysarch
Bug#637424: Implement i386_get_gsbase i386_get_fsbase i386_set_gsbase i386_set_fsbase amd64_get_gsbase amd64_get_fsbase amd64_set_gsbase amd64_set_fsbase
2011/8/11 Robert Millan r...@debian.org: Package: libc0.1 Version: 2.13-15 Severity: wishlist Tags: patch This patch implements the following syscall stubs: i386_get_gsbase i386_get_fsbase i386_set_gsbase i386_set_fsbase amd64_get_gsbase amd64_get_fsbase amd64_set_gsbase amd64_set_fsbase On second thought, these calls may interact badly with TLS if application code uses them. Maybe it's better not to export them. -- Robert Millan -- 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/CAOfDtXN1txsfDrPYjn8_M6FgmR8Ah-vbeAnLs=z1DgE=kbe...@mail.gmail.com
Bug#637424: Implement i386_get_gsbase i386_get_fsbase i386_set_gsbase i386_set_fsbase amd64_get_gsbase amd64_get_fsbase amd64_set_gsbase amd64_set_fsbase
2011/8/11 Aurelien Jarno aurel...@aurel32.net: In any case, they will have to wait for 2.14. Anyway, what are the uses cases for these? wine needs amd64_set_gsbase and i386_set_fsbase. amd64_set_fsbase and i386_set_gsbase are not used by any program that I know of. Also, they should be considered carefully: since our TLS implementation relies on them, programs shouldn't mess with these functions AFAICT. The getters are neither needed by wine nor dangerous. -- Robert Millan -- 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/CAOfDtXNAxo0t6zqKMQyQtmF_m92=ua7jsctc1kmnx8k7r6o...@mail.gmail.com
Bug#522774: Bug#522773: possible solutions for __unused problem
2011/7/29 Moritz Mühlenhoff j...@inutil.org: We already asked you back in September 2009 to report this upstream. He did, precisely in September 2009: https://bugzilla.kernel.org/show_bug.cgi?id=14186 He still got no response though. -- Robert Millan -- 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/caofdtxmrxy9tx_5mzdgqoqw-5rvnsjmrtze5qze5yn3pber...@mail.gmail.com
Bug#635205: libc0.1-dev: no declaration of function 'issetugid'
2011/7/23 Kazuhiro NISHIYAMA z...@mbf.nifty.com: Man page of issetugid(2) says that unistd.h has `int issetugid(void);', but Debian GNU/kFreeBSD 6.0.2's unistd.h does not. Note that issetugid syscall stub is already provided, only the prototype is missing. I guess the only option is adding bits/unistd.h to sysdeps, but it seems like a PITA to maintain a branched version of that file... -- Robert Millan -- 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/CAOfDtXPErtwuUaYaZgqPetFY4xw=KvHCHy9vyPS2JoGD=sa...@mail.gmail.com
Bug#634152: FTBFS on kfreebsd-amd64
retitle 634152 [kfreebsd] FTBFS: tst-atime fails when building on ZFS thanks 2011/7/17 Jonathan Nieder jrnie...@gmail.com: What does the output in tst-atime.out say? $ cat ./build-tree/kfreebsd-amd64-libc/libio/tst-atime.out atime has not changed Note: Following suggestion by Petr I retested on another filesystem. It seems that this bug only appears when /tmp is mounted on ZFS. -- Robert Millan -- 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/CAOfDtXN3y_V6c10rtmPJYxJya+14+K0YL_-Q72H=aZQmfKp=o...@mail.gmail.com
Bug#634152: FTBFS on kfreebsd-amd64
Hi Jonathan, 2011/7/18 Jonathan Nieder jrnie...@gmail.com: Ah, sounds like /tmp was mounted with the noatime flag. Yes, indeed it was. How about something like this (untested)? It works! Regression is gone now. -- Robert Millan -- 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/caofdtxp+kddueveb4ocqmcsnu7n2+m70qlp6d2jr-r-48rn...@mail.gmail.com
Bug#634152: FTBFS on kfreebsd-amd64
Package: libc0.1 Version: 2.13-10 User: debian-...@lists.debian.org Usertags: kfreebsd It's a bit strange, because the buildds didn't seem to have this problem, but eglibc 2.13-10 fails to build on kfreebsd-amd64 due to testsuite errors. (this is pristine eglibc 2.13-10, without any of my local changes) I found the problem with kFreeBSD 8.2, then tried 8.1 to be sure it's not related to kernel version and found the same problem: # # Testsuite failures, someone should be working towards # fixing these! They are listed here for the purpose of # regression testing during builds. # Format: Failed test, Error Make error code [(ignored)] # annexc.out, Error 1 (ignored) check-localplt.out, Error 1 tst-aio10.out, Error 1 tst-aio4.out, Error 1 tst-aio9.out, Error 1 tst-atime.out, Error 1 tst-longjmp_chk.out, Error 1 tst-mknodat.out, Error 1 tst-renameat.out, Error 1 tst-timer4.out, Error 1 tst-waitid.out, Error 1 tst-writev.out, Error 1 *** Encountered regressions that don't match expected failures: tst-atime.out, Error 1 make: *** [/home/rmh/eglibc/test/eglibc-2.13/stamp-dir/check_libc] Error 1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1 depends on: ii libc-bin 2.13-10Embedded GNU C Library: Binaries ii libgcc1 1:4.6.1-1 GCC support library libc0.1 recommends no packages. Versions of packages libc0.1 suggests: ii debconf [debconf-2.0] 1.5.40 Debian configuration management sy ii glibc-doc 2.13-10Embedded GNU C Library: Documentat ii locales 2.13-10Embedded GNU C Library: National L -- debconf information excluded -- 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/20110717094923.80368.9644.report...@aybabtu.com
Bug#630695: LD_PRELOAD not working when running kfreebsd-9 (9.0~svn223109)
2011/7/14 Petr Salinger petr.salin...@seznam.cz: I also wonder if we should hunt down the other Linux-specific ELF notes in that file. I would say we should ignore all Linux-specific ELF notes. Yes, but that makes the patch more intrusive, increasing the maintenance cost. Is it worth it? Or in our glibc-ports/kfreebsd/dl-sysdep.c: #ifdef SHARED # define _dl_sysdep_start _dl_sysdep_start_ignored_code # include elf/dl-sysdep.c # undef dl_sysdep_start There isn't any real benefit in keeping in sync with upstream dl-sysdep.c, we only get breakage from that. It's a net loss IMHO. I think the macro kludge you describe is much better in the long term. We should try to include such fix also into point release of squeeze eglibc. Yes. I would include the RFTSIGZMB fix too. For AT_SECURE how about first using a less-intrusive approach, like the patch I sent, and once it reaches testing backport it to squeeze. -- Robert Millan -- 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/CAOfDtXMDD3gYJJxZEdJpRU3UqZQetf2B-fo0-tpP6QG_W=k...@mail.gmail.com
Bug#630695: LD_PRELOAD not working when running kfreebsd-9 (9.0~svn223109)
2011/6/16 Robert Millan r...@debian.org: $ fakeroot id -u ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. 1000 It seems that LD_* variables are selectively ignored by ld.so. The command above results in: $ LD_LIBRARY_PATH=/usr/lib64/libfakeroot LD_PRELOAD=libfakeroot-sysv.so /lib/ld-kfreebsd-x86-64.so.1 /bin/true ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. $ On a sane system you'd get the same message if LD_LIBRARY_PATH was not set. Another example: $ LD_SHOW_AUXV=yes /lib/ld-kfreebsd-x86-64.so.1 /bin/true $ In this example, LD_PRELOAD has been ignored completely (ktrace confirms this): $ LD_PRELOAD=/usr/lib64/libfakeroot/libfakeroot-sysv.so /lib/ld-kfreebsd-x86-64.so.1 /usr/bin/id -u 1000 $ However, depending on its content it is processed. Example with an invalid file name: $ LD_PRELOAD=foobar /lib/ld-kfreebsd-x86-64.so.1 /bin/true ERROR: ld.so: object 'foobar' from LD_PRELOAD cannot be preloaded: ignored. $ Another invalid file name. This time it is ignored: $ LD_PRELOAD=foo/bar /lib/ld-kfreebsd-x86-64.so.1 /bin/true $ As for LD_SHOW_AUXV=yes, I tried different combinations and it is always ignored, no matter what. -- Robert Millan -- 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/CAOfDtXPmsXYLUY7ciZ+iP-s-n8-ksHe_arxoaqYJ-cjr=nv...@mail.gmail.com
Bug#632452: *ERROR*: Could not open file: /dev/ttyp0
2011/7/3 Axel Beckert a...@debian.org: Hi Christoph? Christoph Egger wrote: I'm getting a *ERROR*: Could not open file: /dev/ttyp0 e.g. when trying to start an emacsclient here after today's updates (sid). Anyone else seeing those as well? Any idea where to report that bug? Could that be another symptom of http://bugs.debian.org/632452? Seems a lot like it, adding it to CC. Aurelien, I notice you don't consider this bug release-critical. Do you plan to let this migrate to wheezy? If there's no fix readily available, please consider reverting r3435 so that wheezy users are not affected. IIRC the previous state only caused a harmless warning with sshd. -- Robert Millan -- 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/caofdtxnvvcoxzcpjkyk+4fod-3hg04q6gugmn7vj-5dl47o...@mail.gmail.com
Bug#632452: screen stops working after upgrading to 2.13-8
Package: libc0.1 Version: 2.13-8 Severity: critical After upgrading 2.13-7 to 2.13-8, screen stops working. When run it prints the following errors: No more PTYs. Sorry, could not find a PTY. I suspect this might have been introduced with r3435: http://anonscm.debian.org/viewvc/glibc-bsd?view=revisionrevision=3435 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.2-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1 depends on: ii libc-bin 2.13-8 Embedded GNU C Library: Binaries ii libgcc1 1:4.6.1-1 GCC support library libc0.1 recommends no packages. Versions of packages libc0.1 suggests: ii debconf [debconf-2.0] 1.5.40 Debian configuration management sy pn glibc-doc none (no description available) ii locales 2.13-8 Embedded GNU C Library: National L -- debconf information excluded -- 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/20110702104006.2572.71929.report...@aybabtu.com
Bug#632453: preinst attemps to create /dev/null
Package: libc0.1 Version: 2.13-8 Severity: minor User: debian-...@lists.debian.org Usertags: kfreebsd The effect of this seems only cosmetical. Anyway, I verified that 2.13-7 didn't exhibit this problem. Note the special char (0xa0) after /dev/null. I suspect there might be a typo somewhere. S'està preparant per a reempla�ar libc0.1 2.13-8 (fent servir ��/libc0.1_2.13-8_kfreebsd-amd64.deb)�� /var/lib/dpkg/tmp.ci/preinst: 419: cannot create /dev/null�: Operation not supported /var/lib/dpkg/tmp.ci/preinst: 419: cannot create /dev/null�: Operation not supported /var/lib/dpkg/tmp.ci/preinst: 419: cannot create /dev/null�: Operation not supported /var/lib/dpkg/tmp.ci/preinst: 419: cannot create /dev/null�: Operation not supported /var/lib/dpkg/tmp.ci/preinst: 419: cannot create /dev/null�: Operation not supported S'està desempaquetant el reempla�ament de libc0.1�� -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.2-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1 depends on: ii libc-bin 2.13-8 Embedded GNU C Library: Binaries ii libgcc1 1:4.6.1-1 GCC support library libc0.1 recommends no packages. Versions of packages libc0.1 suggests: ii debconf [debconf-2.0] 1.5.40 Debian configuration management sy pn glibc-doc none (no description available) ii locales 2.13-8 Embedded GNU C Library: National L -- debconf information excluded -- 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/20110702104843.3255.39181.report...@aybabtu.com
Bug#629556: sys/mount.h, sys/sysproto.h
Also note that getvfsbyname() is being advertised in Debian GNU/kFreeBSD system headers: /usr/include/sys/mount.h:intgetvfsbyname(const char *, struct xvfsconf *); likewise for nlm_syscall() and nfssvc() syscall stubs: /usr/include/sys/sysproto.h:int nlm_syscall(struct thread *, struct nlm_syscall_args *); /usr/include/sys/sysproto.h:int nfssvc(struct thread *, struct nfssvc_args *); -- Robert Millan -- 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/banlktimrrsw-xuzvhmfapheknsibkmd...@mail.gmail.com
Bug#631867: sigev_notify_kqueue, SIGEV_KEVENT and SIGEV_THREAD_ID in bits/siginfo.h
Package: libc0.1-dev
Version: 2.13-7
Severity: wishlist
Tags: patch
Please consider this update for bits/siginfo.h, it's a resync with some
of the missing definitions from FreeBSD sys/signal.h.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 8.2-1-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc0.1-dev depends on:
ii kfreebsd-kernel-headers 0.55 kernel of FreeBSD headers for deve
ii libc-dev-bin 2.13-7 Embedded GNU C Library: Developmen
ii libc0.1 2.13-7 Embedded GNU C Library: Shared lib
Versions of packages libc0.1-dev recommends:
ii bcc [c-compiler] 0.16.17-3.1 16-bit x86 C compiler
ii gcc [c-compiler] 4:4.6.0-6 GNU C compiler
ii gcc-4.6 [c-compiler] 4.6.0-14GNU C compiler
Versions of packages libc0.1-dev suggests:
pn glibc-doc none (no description available)
ii manpages-dev 3.28-1 Manual pages about using GNU/Linux
-- no debconf information
Index: bits/siginfo.h
===
--- bits/siginfo.h (revision 3490)
+++ bits/siginfo.h (working copy)
@@ -199,6 +199,8 @@
void *sigev_notify_attributes; /* Really pthread_attr_t. */
} sigevent_t;
+#define sigev_notify_kqueue sigev_signo
+
/* `sigev_notify' values. */
enum
{
@@ -207,8 +209,12 @@
SIGEV_NONE = 0, /* Other notification: meaningless. */
# define SIGEV_NONE SIGEV_NONE
/* Not yet supported by the kernel. */
- SIGEV_THREAD = 2 /* Deliver via thread creation. */
+ SIGEV_THREAD = 2, /* Deliver via thread creation. */
# define SIGEV_THREAD SIGEV_THREAD
+ SIGEV_KEVENT = 3,
+# define SIGEV_KEVENT SIGEV_KEVENT
+ SIGEV_THREAD_ID = 4,
+# define SIGEV_THREAD_ID SIGEV_THREAD_ID
};
#endif /* have _SIGNAL_H. */
Bug#522774: possible solutions for __unused problem
It seems there are two traditions for attribute macros. The GNU one produced things like: #define __attribute_malloc__ __attribute__ ((__malloc__)) #define __attribute_pure__ __attribute__ ((__pure__)) #define __attribute_used__ __attribute__ ((__used__)) #define __attribute_noinline__ __attribute__ ((__noinline__)) #define __always_inline __inline __attribute__ ((__always_inline__)) The BSD one produced things like: #define __malloc_like __attribute__((__malloc__)) #define __pure __attribute__((__pure__)) #define __used __attribute__((__used__)) #define __noinline __attribute__ ((__noinline__)) #define __always_inline __attribute__((__always_inline__)) When it comes to __attibute__((__unused__)), it's just a matter of agreeing on whether to call it __attribute_unused__ or __unused. The problem is that there's severe NIH to overcome. As you can see with the bug you submitted to Linux developers, they're generally very hostile to portability. The same applies to Glibc (aka Drepper). Here are some possible ways out of this I can think of: - Propose to BSD folks that they accept __attribute_* prefix and define those macros (in addition to __unused etc), then begin accepting patches that replace __unused with __attribute_unused. - Propose to GCC folks that they define __attribute_* macros in stddef.h (they won't define __unused since this would break Linux and Glibc), then bring the same proposal to Clang folks. If both accept, FreeBSD is much more likely to backport it to GCC 4.2. - Work with standards bodies (POSIX?) so that they specify either definition (it doesn't matter to us which one, the offending definition will have to adapt). What I would definitely NOT do is waste any time trying to persuade Drepper to remove __unused from Glibc or Linux developers to remove __unused from Linux. -- Robert Millan -- 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/BANLkTimJePBuB8gMvXtP4bkMZXd=5fm...@mail.gmail.com
Bug#629556: also getosreldate()
retitle 629556 please provide getvfsbyname() and getosreldate() thanks getosreldate() also needed by NFS userland code (both fixes are in SVN). -- Robert Millan -- 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/BANLkTi=MErhkTtqEx=ZH2hAXJ=p3emo...@mail.gmail.com
Bug#629556: also getosreldate()
2011/6/18 Aurelien Jarno aurel...@aurel32.net: I start to wonder if all these functions have really their place in the GNU libc, as they are quite FreeBSD specific, while the functions there are supposed to functions common to all OS. Maybe it's the time to revive a specific freebsd library? I agree. But then why was libfreebsd merged into glibc? Alternatively couldn't we have these directly in the NFS userland code? Which functions are you referring to? getvfsbyname and getosreldate are not related to NFS (and getosreldate() is used in many places, I even had to implement a replacement in GRUB). getosreldate() also needed by NFS userland code (both fixes are in SVN). Please revert that (or leave them disabled). Whatever the decision, we have to handle that with the 2.14 upload for versioning reasons. Which functions should be removed/disabled? We have: Two userland functions (not NFS specific): getosreldate getvfsbyname Two syscall stubs: nfssvc nlm_syscall -- Robert Millan -- 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/banlktinvdx5_qitbdenv+7tkn5mkvip...@mail.gmail.com
Bug#522774: possible solutions for __unused problem
2011/6/18 Jonathan Nieder jrnie...@gmail.com: Hi Robert, Robert Millan wrote: When it comes to __attibute__((__unused__)), it's just a matter of agreeing on whether to call it __attribute_unused__ or __unused. I don't agree. It's perfectly fine for there to be multiple names for the thing Providing multiple names is fine, the problem is which ones to use. If BSD developers agree to provide both __attribute_unused and __unused, and switch their users to __attribute_unused, problem is solved. If Drepper agrees to provide __unused, problem would be solved but this won't happen. Would it be possible to collect a near-exhaustive list of identifiers like this (i.e., used in BSD application code and starting with __) that could cause trouble? Yes, just read the GNU and BSD versions of sys/cdefs.h... Then we can propose sed-ing them away at header installation time to the libc-ports maintainers (as Thorsten suggested), and I wouldn't be surprised if such a patch is accepted. ... but I don't think this will fly. - Propose to BSD folks that they accept __attribute_* prefix and define those macros (in addition to __unused etc), then begin accepting patches that replace __unused with __attribute_unused. If I were in their shoes, I wouldn't be happy about such patches. It sounds like heavy patching without much immediate benefit, with no end in sight (since glibc could start using another keyword the next day). I can see they wouldn't be excited about it, but they might also accept them. This is not a recurrent problem: it's irrelevant if glibc changes it to another keyword (heck, there isn't even any equivalent to __unused RIGHT NOW), what matters is that we'd have found a way out the name collision. - Propose to GCC folks that they define __attribute_* macros in stddef.h (they won't define __unused since this would break Linux and Glibc), then bring the same proposal to Clang folks. If both accept, FreeBSD is much more likely to backport it to GCC 4.2. Likewise, in their shoes I wouldn't accept such patches. The macros are not in the C or POSIX standard and are easy to define in terms of the __attribute__() feature, so they're not part of what a C compiler is supposed to do. Making each implementation of the standard headers add these macros would hinder portability between implementations (yes, there are more than two :)). Actually, I realized afer writing this that the point of these macros is precisely portability among different compilers. Moving them to a GCC header is out of the question (we might as well just use __attribute__((__unused__)) then). - Work with standards bodies (POSIX?) so that they specify either definition (it doesn't matter to us which one, the offending definition will have to adapt). That sounds like an excellent idea! Presumably the C working group would be likely to consider standardizing __attribute__((__unused__)) if it is proposed, since that syntax is already widely implemented. Well I have no experience working with standards bodies (and no spare time), but if someone wants to take it, I'm almost certain this would resolve our problem. -- Robert Millan -- 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/BANLkTimipbvr1-k=hn-3zaupvawflso...@mail.gmail.com
Bug#629556: also getosreldate()
2011/6/18 Aurelien Jarno aurel...@aurel32.net: Which functions should be removed/disabled? We have: All of them. You can't add new functions at a random time, it has to be coordinated to a new version (2.14 in this case) to nt break symbol versioning. OTOH we do want to make some changes that do not break the ABI from the glibc-bsd SVN. Adding the new functions now means we can't do that any more until version 2.14. And we do have fixes pending there. This has to be either removed or disabled, committed in a different branch, or provided as a patch (for example glibc-2.14.patch) in the glibc-ports. We usually use the latter solution. I've already disabled them earlier today. -- Robert Millan -- 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/BANLkTikkRd5Wa-MNQxwE=j1+vbyrkqa...@mail.gmail.com
Bug#630843: missing nfssvc() syscall stub
Package: libc0.1-dev Version: 2.13-4 Severity: wishlist The following syscall stub is missing. It is needed by NFS userland: extern int nfssvc (int, void *); -- System Information: Debian Release: 6.0.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.2-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1-dev depends on: ii kfreebsd-kernel-headers 0.55 kernel of FreeBSD headers for deve ii libc-dev-bin 2.13-4 Embedded GNU C Library: Developmen ii libc0.1 2.13-4 Embedded GNU C Library: Shared lib Versions of packages libc0.1-dev recommends: ii gcc [c-compiler] 4:4.6.0-5 The GNU C compiler ii gcc-4.6 [c-compiler] 4.6.0-11 The GNU C compiler Versions of packages libc0.1-dev suggests: pn glibc-doc none (no description available) pn manpages-dev none (no description available) -- no debconf information -- 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/20110617214226.17287.6259.reportbug@thorin
Bug#630843: missing nfssvc() syscall stub
retitle 630843 missing nfssvc() and nlm_syscall() thanks 2011/6/17 Robert Millan r...@debian.org: Package: libc0.1-dev Version: 2.13-4 Severity: wishlist The following syscall stub is missing. It is needed by NFS userland: extern int nfssvc (int, void *); Another stub is needed for NFS: nlm_syscall(). It's syscall macro is SYS_nlm_syscall (code 154). -- Robert Millan -- 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/banlktimg5xyfqotn2ytayqlocyjnlir...@mail.gmail.com
Bug#630695: LD_PRELOAD not working when running kfreebsd-9 (9.0~svn223109)
Package: libc0.1 Version: 2.13-7 Severity: normal User: debian-...@lists.debian.org Usertags: kfreebsd $ fakeroot id -u ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. 1000 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-0-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1 depends on: ii libc-bin 2.13-7 Embedded GNU C Library: Binaries ii libgcc1 1:4.6.0-13 GCC support library libc0.1 recommends no packages. Versions of packages libc0.1 suggests: ii debconf [debconf-2.0] 1.5.39 Debian configuration management sy pn glibc-doc none (no description available) ii locales 2.13-7 Embedded GNU C Library: National L -- debconf information excluded -- 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/20110616105711.1736.5939.reportbug@dimoni
Bug#629556: please provide getvfsbyname()
Package: libc0.1-dev Version: 2.13-4 Severity: wishlist FreeBSD libc provides getvfsbyname() function, which is used by NFS userland code. It can't be provided by libbsd because it's kFreeBSD-specific: http://svnweb.freebsd.org/base/head/lib/libc/gen/getvfsbyname.c -- System Information: Debian Release: 6.0.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.2-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1-dev depends on: ii kfreebsd-kernel-headers 0.55 kernel of FreeBSD headers for deve ii libc-dev-bin 2.13-4 Embedded GNU C Library: Developmen ii libc0.1 2.13-4 Embedded GNU C Library: Shared lib Versions of packages libc0.1-dev recommends: ii gcc [c-compiler] 4:4.6.0-5 The GNU C compiler ii gcc-4.6 [c-compiler] 4.6.0-11 The GNU C compiler Versions of packages libc0.1-dev suggests: pn glibc-doc none (no description available) pn manpages-dev none (no description available) -- no debconf information -- 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/20110607175424.27671.31813.reportbug@dimoni
Bug#629426: missing MNT_NFS4ACLS in sys/mount.h
Package: libc0.1-dev Version: 2.11.2-10 Severity: normal Tags: patch kFreeBSD has MNT_NFS4ACLS in sys/mount.h, but it is missing in the version of this file provided by Glibc. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.utf8, LC_CTYPE=ca_AD.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc0.1-dev depends on: ii kfreebsd-kernel-headers 0.53 kernel of FreeBSD headers for deve ii libc-dev-bin 2.11.2-10 Embedded GNU C Library: Developmen ii libc0.1 2.11.2-10 Embedded GNU C Library: Shared lib Versions of packages libc0.1-dev recommends: ii gcc [c-compiler] 4:4.4.5-1 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-29 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.5-4The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.5-8The GNU C compiler Versions of packages libc0.1-dev suggests: pn glibc-doc none (no description available) ii manpages-dev 3.27-1 Manual pages about using GNU/Linux -- no debconf information --- /usr/include/sys/mount.h 2011-01-24 00:27:52.0 +0100 +++ mount.h 2011-06-06 18:31:52.0 +0200 @@ -56,7 +56,6 @@ #define MNT_SYNCHRONOUS 0x0002 /* filesystem written synchronously */ #define MNT_NOEXEC 0x0004 /* can't exec from filesystem */ #define MNT_NOSUID 0x0008 /* don't honor setuid bits on fs */ -#define MNT_NODEV 0x0010 /* don't interpret special files */ #define MNT_UNION 0x0020 /* union with underlying filesystem */ #define MNT_ASYNC 0x0040 /* filesystem written asynchronously */ #define MNT_SUIDDIR 0x0010 /* special handling of SUID on dirs */ @@ -69,6 +68,7 @@ #define MNT_NOATIME 0x1000 /* disable update of file access time */ #define MNT_NOCLUSTERR 0x4000 /* disable cluster read */ #define MNT_NOCLUSTERW 0x8000 /* disable cluster write */ +#define MNT_NFS4ACLS 0x0010 /* * NFS export related mount flags. @@ -97,22 +97,22 @@ * but the 'mount' program may need changing to handle this. */ #define MNT_VISFLAGMASK (MNT_RDONLY | MNT_SYNCHRONOUS | MNT_NOEXEC | \ - MNT_NOSUID | MNT_NODEV | MNT_UNION | \ + MNT_NOSUID | MNT_UNION | \ MNT_ASYNC | MNT_EXRDONLY | MNT_EXPORTED | \ MNT_DEFEXPORTED | MNT_EXPORTANON| MNT_EXKERB | \ MNT_LOCAL | MNT_USER | MNT_QUOTA | \ MNT_ROOTFS | MNT_NOATIME | MNT_NOCLUSTERR| \ MNT_NOCLUSTERW | MNT_SUIDDIR | MNT_SOFTDEP | \ MNT_IGNORE | MNT_EXPUBLIC | MNT_NOSYMFOLLOW | \ - MNT_JAILDEVFS | MNT_MULTILABEL | MNT_ACLS) + MNT_GJOURNAL | MNT_MULTILABEL | MNT_ACLS | MNT_NFS4ACLS) /* Mask of flags that can be updated. */ -#define MNT_UPDATEMASK (MNT_NOSUID | MNT_NOEXEC | MNT_NODEV | \ +#define MNT_UPDATEMASK (MNT_NOSUID | MNT_NOEXEC | \ MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC | \ MNT_NOATIME | \ MNT_NOSYMFOLLOW | MNT_IGNORE | MNT_JAILDEVFS | \ MNT_NOCLUSTERR | MNT_NOCLUSTERW | MNT_SUIDDIR | \ - MNT_ACLS | MNT_USER) + MNT_ACLS | MNT_USER | MNT_NFS4ACLS) /* * External filesystem command modifier flags.
Bug#601419: Linux support is available now
forwarded 601419 http://sources.redhat.com/bugzilla/show_bug.cgi?id=12193
thanks
Hi,
It seems that my Linux patch was finally accepted and is now queued
for Linux 2.6.40, see:
https://patchwork.linux-mips.org/patch/2302/
https://lkml.org/lkml/2011/5/12/112
Here's an updated version of the Glibc patch (also available in
http://sources.redhat.com/bugzilla/show_bug.cgi?id=12193)
--
Robert Millan
diff -Nur eglibc-2.11.2/ports/sysdeps/mips/dl-machine.h
eglibc-2.11.2.new/ports/sysdeps/mips/dl-machine.h
--- eglibc-2.11.2/ports/sysdeps/mips/dl-machine.h 2008-10-18
20:20:55.0 +0200
+++ eglibc-2.11.2.new/ports/sysdeps/mips/dl-machine.h 2010-11-04
17:43:44.0 +0100
@@ -305,6 +305,18 @@
# define ARCH_LA_PLTEXIT mips_n64_gnu_pltexit
# endif
+/* We define an initialization function. This is called very early in
+ _dl_sysdep_start. */
+#define DL_PLATFORM_INIT dl_platform_init ()
+
+static inline void __attribute__ ((unused))
+dl_platform_init (void)
+{
+ if (GLRO(dl_platform) != NULL *GLRO(dl_platform) == '\0')
+/* Avoid an empty string which would disturb us. */
+GLRO(dl_platform) = NULL;
+}
+
/* For a non-writable PLT, rewrite the .got.plt entry at RELOC_ADDR to
point at the symbol with address VALUE. For a writable PLT, rewrite
the corresponding PLT entry instead. */
diff -Nur eglibc-2.11.2/ports/sysdeps/mips/dl-procinfo.c
eglibc-2.11.2.new/ports/sysdeps/mips/dl-procinfo.c
--- eglibc-2.11.2/ports/sysdeps/mips/dl-procinfo.c 1970-01-01
01:00:00.0 +0100
+++ eglibc-2.11.2.new/ports/sysdeps/mips/dl-procinfo.c 2010-11-04
17:27:13.0 +0100
@@ -0,0 +1,64 @@
+/* Data for Mips version of processor capability information.
+ Copyright (C) 2007 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+ Contributed by Robert Millan r...@gnu.org.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+/* This information must be kept in sync with the _DL_PLATFORM_COUNT
+ definitions in procinfo.h.
+
+ If anything should be added here check whether the size of each string
+ is still ok with the given array size.
+
+ All the #ifdefs in the definitions are quite irritating but
+ necessary if we want to avoid duplicating the information. There
+ are three different modes:
+
+ - PROCINFO_DECL is defined. This means we are only interested in
+ declarations.
+
+ - PROCINFO_DECL is not defined:
+
+ + if SHARED is defined the file is included in an array
+ initializer. The .element = { ... } syntax is needed.
+
+ + if SHARED is not defined a normal array initialization is
+ needed.
+ */
+
+#ifndef PROCINFO_CLASS
+#define PROCINFO_CLASS
+#endif
+
+#if !defined PROCINFO_DECL defined SHARED
+ ._dl_mips_platforms
+#else
+PROCINFO_CLASS const char _dl_mips_platforms[1][12]
+#endif
+#ifndef PROCINFO_DECL
+= {
+loongson2f
+ }
+#endif
+#if !defined SHARED || defined PROCINFO_DECL
+;
+#else
+,
+#endif
+
+#undef PROCINFO_DECL
+#undef PROCINFO_CLASS
diff -Nur eglibc-2.11.2/ports/sysdeps/mips/dl-procinfo.h
eglibc-2.11.2.new/ports/sysdeps/mips/dl-procinfo.h
--- eglibc-2.11.2/ports/sysdeps/mips/dl-procinfo.h 1970-01-01
01:00:00.0 +0100
+++ eglibc-2.11.2.new/ports/sysdeps/mips/dl-procinfo.h 2010-11-03
19:16:37.0 +0100
@@ -0,0 +1,68 @@
+/* Mips version of processor capability information handling macros.
+ Copyright (C) 2007 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+ Contributed by Robert Millan r...@gnu.org.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330
Bug#607573: setxattr, fsetxattr and lsetxattr are ENOSYS stubs
Package: libc0.1 Version: 2.11.2-7 Severity: normal User: debian-...@lists.debian.org Usertags: kfreebsd setxattr, fsetxattr and lsetxattr are ENOSYS stubs. This results in libacl breakage: $ setfacl -m u:rmh:r /tmp/test setfacl: /tmp/test: Function not implemented I think they can be implemented using the extattr family of system calls: http://www.freebsd.org/cgi/man.cgi?query=extattrsektion=2apropos=0manpath=FreeBSD+8.1-RELEASE -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.utf8, LC_CTYPE=ca_AD.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1 depends on: ii libc-bin 2.11.2-7 Embedded GNU C Library: Binaries ii libgcc1 1:4.5.1-6 GCC support library libc0.1 recommends no packages. Versions of packages libc0.1 suggests: ii debconf [debconf-2.0] 1.5.36 Debian configuration management sy pn glibc-doc none (no description available) ii locales 2.11.2-7 Embedded GNU C Library: National L -- debconf information excluded -- 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/20101219212823.82905.91298.report...@debian
Bug#602776: libc: missing syscall stubs for jail_set, jail_get, jail_remove
tags 602776 fixed-upstream thanks Fixed in glibc-bsd SVN. -- Robert Millan -- 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/aanlktimawpixvwvogkpscyvi-gzsx9gba75m8adt8...@mail.gmail.com
Bug#601419: libc6: please build a loongson-2f optimized library
See http://sources.redhat.com/bugzilla/show_bug.cgi?id=12193 -- Robert Millan -- 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/aanlktinmu6=x5fq7-barvdqxqfoph=qhp03zq_o2p...@mail.gmail.com
Bug#601419: libc6: please build a loongson-2f optimized library
2010/11/4 Aurelien Jarno aurel...@aurel32.net: Robert Millan a écrit : See http://sources.redhat.com/bugzilla/show_bug.cgi?id=12193 I am not sure you want to define an octeon2 platform. Contrary to longsoon which has specific instructions, octeon is following the standard MIPS instruction sets. It would make more sense to export MIPS32, 32R2, 64 and 64R2 capabilities. Having a MIPS32 optimized library eglibc makes a lot of sense for the vast majority of CPU we target (except longsoon). Thanks for the correction. Do you mind if I add this to upstream's bug log? -- Robert Millan -- 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/aanlktikqnlsfvv2ezvhttbpc8ksmbpv_kn_pnkwcs...@mail.gmail.com
Bug#601419: libc6: please build a loongson-2f optimized library
2010/11/1 Robert Millan r...@debian.org: 2010/10/31 Aurelien Jarno aurel...@aurel32.net: Wrong, for alpha we have code to add hardware capabilities support. I'm a bit confused now. I looked at the code in debian/patches/, and Never mind, I figured it out. It seems Linux should set AT_PLATFORM variable, which it doesn't yet. -- 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/aanlktin7zfansyvxxz1yvtriuj09zdga5tpknkmj4...@mail.gmail.com
Bug#601419: libc6: please build a loongson-2f optimized library
2010/10/31 Aurelien Jarno aurel...@aurel32.net: Wrong, for alpha we have code to add hardware capabilities support. I'm a bit confused now. I looked at the code in debian/patches/, and it adds some functions internal declarations, but I can't see where's the actual hardware detection. Can you give me some pointer? I know how to probe for loongson but I'm unsure where should this code be plugged. I assume similar changes to the ones in debian/patches/alpha/ will be needed, but still something seems missing. -- 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/aanlkti=brgctx-v1wd2=1elp5r1vwv9wll3gd5y7l...@mail.gmail.com
Bug#601419: libc6: please build a loongson-2f optimized library
2010/10/30 Aurelien Jarno aurel...@aurel32.net: I don't see any loongson-2f hardware capabilities in the current (e)glibc code. Yes. Note that it isn't the only one in this situation (libc6.1-alphaev67). How is it handled? One could use LD_LIBRARY_PATH, or enable it system-wide with: echo /lib/loongson-2f /etc/ld.so.conf.d/loongson-2f.conf ldconfig Both approaches are tested on my Yeeloong. -- 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/aanlktin5ok3jmi4som8ifaogwizgz473_+ynndow4...@mail.gmail.com
Bug#601419: libc6: please build a loongson-2f optimized library
Package: libc6
Version: 2.11.2-6
Severity: wishlist
Tags: patch
Please could you build a loongson-2f optimized library?
A (tested) patch is attached.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: mipsel (mips64)
Kernel: Linux 2.6.35.7-libre2-lemote (PREEMPT)
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii libc-bin 2.11.2-6 Embedded GNU C Library: Binaries
ii libgcc1 1:4.4.5-2 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy
pn glibc-doc none (no description available)
ii locales 2.11.2-6 Embedded GNU C Library: National L
-- debconf information excluded
diff -ur -x control eglibc-2.11.2/debian/control.in/opt eglibc-2.11.2.new/debian/control.in/opt
--- eglibc-2.11.2/debian/control.in/opt 2010-10-22 14:13:56.0 +0200
+++ eglibc-2.11.2.new/debian/control.in/opt 2010-10-20 11:58:09.0 +0200
@@ -107,3 +107,18 @@
needs to be installed on Alpha EV67/68 and EV7 machines. If you install
this on an older machine, it won't even be used.
+Package: libc6-loongson-2f
+Architecture: mipsel
+Section: libs
+Priority: extra
+Pre-Depends: libc6 (= ${binary:Version})
+Depends: ${misc:Depends}
+Description: Embedded GNU C Library: Shared libraries [Loongson 2F optimized]
+ Contains the standard libraries that are used by nearly all programs on
+ the system. This package includes shared versions of the standard C
+ library and the standard math library, as well as many others.
+ .
+ This set of libraries is optimized for the Loongson 2F. It only
+ needs to be installed on Lemote Loongson 2F machines. If you install
+ this on a non-Loongson, it won't even be used.
+
diff -ur -x control eglibc-2.11.2/debian/script.in/nohwcap.sh eglibc-2.11.2.new/debian/script.in/nohwcap.sh
--- eglibc-2.11.2/debian/script.in/nohwcap.sh 2010-10-22 14:13:56.0 +0200
+++ eglibc-2.11.2.new/debian/script.in/nohwcap.sh 2010-10-20 11:58:09.0 +0200
@@ -16,6 +16,9 @@
kfreebsd-i386)
hwcappkgs=libc0.1-i686
;;
+mipsel)
+ hwcappkgs=libc6-loongson-2f
+ ;;
sparc)
hwcappkgs=libc6-sparcv9 libc6-sparcv9b
;;
diff -ur -x control eglibc-2.11.2/debian/sysdeps/mipsel.mk eglibc-2.11.2.new/debian/sysdeps/mipsel.mk
--- eglibc-2.11.2/debian/sysdeps/mipsel.mk 2010-10-22 14:13:56.0 +0200
+++ eglibc-2.11.2.new/debian/sysdeps/mipsel.mk 2010-10-21 12:50:06.0 +0200
@@ -24,6 +24,18 @@
mips64_libdir = /usr/lib64
mips64_extra_config_options := $(extra_config_options) --disable-profile
+# build a loongson-2f optimized library
+EGLIBC_PASSES += loongson-2f
+DEB_ARCH_REGULAR_PACKAGES += libc6-loongson-2f
+loongson-2f_add-ons = ports nptl $(add-ons)
+loongson-2f_configure_target = mips32el-linux-gnu
+loongson-2f_CC = $(CC) -mabi=32
+loongson-2f_CXX = $(CXX) -mabi=32
+loongson-2f_extra_cflags = -march=loongson2f -mtune=loongson2f -O2
+loongson-2f_extra_config_options = $(extra_config_options) --disable-profile
+loongson-2f_rtlddir = /lib
+loongson-2f_slibdir = /lib/loongson-2f
+
# Need to put a tri-arch aware version of ldd in the base package
define mipsn32_extra_install
cp debian/tmp-mipsn32/usr/bin/ldd debian/tmp-libc/usr/bin
Bug#369453: makecontext/setcontext/getcontext not implemented on ARM architecture
On Mon, May 29, 2006 at 11:20:11PM +0100, David Given wrote: Package: libc6 Version: 2.3.6-7 Attempting to use any of the ucontext family of functions --- makecontext, setcontext, getcontext, swapcontext --- produces the following link-time error: makecontext is not implemented and will always fail It's right; it does. I realise they're a bit exotic, but they *are* specified in the standard, and more to the point my program requires them (for a coroutines implementation). Said program was developed on i386 and works fine there. I currently don't have any workarounds. Is this worth doing anything about in Debian, or should it be referred upstream? Hi David, I'm interested in these functions too. I might be able to implement them; please could you provide a minimal architecture-independent test case? Even if I can't do it, having this might be helpful to someone else. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412312: iconv fails when converting Catalan ela geminada character
No it does not, iconv is meant as a 1:1 converter. If you want more subtle and evolved conversions, please use recode. ŀ and Ŀ do not exist in latin1/9 so it's valid not to be able to convert them. Please do consider that echo $foo | iconv -f utf8 -t latin1 | iconv -f latin1 -t utf8 should be identity (if every character in $foo exists in utf8). With your request, it's no longer true, as converting e.g. ŀ back and forth would give you l· in utf-8 as well, which is incorrect. Hi Pierre, My real intention was gaining the ability to use ŀ and Ŀ in gettext translations, with the certainty that gettext will manage to convert them for people still using latin1. I was under the impression that iconv relied on the same backend that gettext does, and so that fixing iconv would automaticaly fix gettext. But as you put it, sounds like that's not the case. Do you know what is needed to archieve what we want? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412312: iconv fails when converting Catalan ela geminada character
Package: libc6 Version: 2.3.6.ds1-11 Severity: normal Tags: l10n This is basicaly it: $ echo ŀ | iconv -f utf-8 -t iso-8859-1 iconv: illegal input sequence at position 0 I would expect it to generate two iso-8859-1 characters out of ŀ, i.e. the equivalent of l·. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Versions of packages libc6 depends on: ii tzdata2006p-1Time Zone and Daylight Saving Time libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407540: please do not conflict on ia32-libs-dev for architectures other than ia64
Package: libc6-dev-i386
Version: 2.3.6.ds1-8
Severity: normal
Tags: patch
Please do not conflict on ia32-libs-dev for architectures other than ia64. This
breaks e.g. amd64 where this package doesn't need to provide its own ld.so, and
so there is no reason to conflict with it.
--- glibc-2.3.6.ds1/debian/control.in/i386~ 2007-01-19 11:58:38.0
+0100
+++ glibc-2.3.6.ds1/debian/control.in/i386 2007-01-19 12:00:12.0
+0100
@@ -14,7 +14,7 @@
Architecture: amd64
Section: libdevel
Priority: optional
-Conflicts: ia32-libs-dev
+Conflicts: ia32-libs-dev [ia64] | ia32-libs-dev ( 1.18)
Provides: lib32c-dev
Depends: libc6-i386 (= ${Source-Version}), libc6-dev (= ${Source-Version}),
lib32gcc1
Description: GNU C Library: 32bit development libraries for AMD64
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Versions of packages libc6-dev-i386 depends on:
ii lib32gcc11:4.1.1-21 GCC support library (32 bit Versio
ii libc6-dev2.3.6.ds1-8 GNU C Library: Development Librari
ii libc6-i386 2.3.6.ds1-8 GNU C Library: 32bit shared librar
libc6-dev-i386 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365628: postinst fails when LANG doesn't point to a valid locale
On Fri, Aug 11, 2006 at 12:21:04AM +0200, Denis Barbier wrote: On Thu, Jul 27, 2006 at 06:38:43PM +0200, Robert Millan wrote: OTOH, LANG is being passed as parameter now: if [ -n $SELECTED ] [ $SELECTED != None ]; then /usr/sbin/update-locale LANG=$SELECTED fi Unfortunately you can't trust locales/locales_to_be_generated as generated by locales.config, because this script could have been run in a previous version of locales that includes entries that are no longer valid. One solution would be to add --no-checks. Another, to check $SELECTED against __SUPPORTED_LOCALES__ to ensure it's in the list (and otherwise fallback to LANG=C). I still believe that something should be done when user selects non working locales, We could check locales_to_be_generated against the current list of locales, and if one of the locales that is no longer present has been selected, we migrate it using a list of known disappeared locales and their subtitutes (and use None as fallback substitute if the disappeared locale isn't known). As for default_environment_locale, we can wrap such check within a function and use it here, too. Would you like a patch for that? but I add --no-checks for now. Ok thanks. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365628: postinst fails when LANG doesn't point to a valid locale
reopen 365628 thanks On Fri, May 05, 2006 at 01:55:09AM +0200, Denis Barbier wrote: AIUI, the checks update-locale is expected to do (and those --no-checks avoids) are the ones passed as arguments (ala update-locale LANG=foo). The manpage doesn't make any reference to variables passed through the environment. You are right, this is fixed now. OTOH, LANG is being passed as parameter now: if [ -n $SELECTED ] [ $SELECTED != None ]; then /usr/sbin/update-locale LANG=$SELECTED fi Unfortunately you can't trust locales/locales_to_be_generated as generated by locales.config, because this script could have been run in a previous version of locales that includes entries that are no longer valid. One solution would be to add --no-checks. Another, to check $SELECTED against __SUPPORTED_LOCALES__ to ensure it's in the list (and otherwise fallback to LANG=C). Do you want me to send a patch for either of these? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#272265: ping
On Sun, Jun 04, 2006 at 01:49:57PM -0400, Clint Adams wrote: I'm interested in this, too. Could you consider that patch for next upload? You want each program statting /etc/resolv.conf all the time? Why not? The amount of data is very small, and would be cached by the kernel. Besides, the stats only would happen when attempting to resolve a hostname (which has a much higher cost in system resources then a simple stat). I don't think the overhead would be significant. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#272265: ping
Hi! I'm interested in this, too. Could you consider that patch for next upload? -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365628: postinst fails when LANG doesn't point to a valid locale
On Wed, May 03, 2006 at 01:43:58AM +0200, Denis Barbier wrote: -/usr/sbin/update-locale LANG +LANG= /usr/sbin/update-locale LANG fi if [ -n $SELECTED ] [ $SELECTED != None ]; then /usr/sbin/update-locale LANG=$SELECTED A slightly different fix has already been committed in SVN, update-locale is called with the --no-checks flag. But according to the manpage, I don't see why update-locale should care about the LANG env variable. Perhaps the problem is there? Several problems have been reported because of inconsistencies between LANG and LANGUAGE, so I try to make sure that selected locale is usable. If these consistency checks make more harm than good, they will be dropped. AIUI, the checks update-locale is expected to do (and those --no-checks avoids) are the ones passed as arguments (ala update-locale LANG=foo). The manpage doesn't make any reference to variables passed through the environment. (that said, if postinst works I don't really mind..) -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365570: import debconf selection from belocs-locales-data ?
Package: locales Version: 2.3.6-3 Severity: wishlist Hi, I think it would be nice if, when installing standard locales in a system that previously were using belocs-locales-data, the debconf selections from: belocs-locales-data/locales_to_be_generated belocs-locales-data/default_environment_locale were automaticaly imported into the default locales template (and, of course, unexistant locales were skipped). This is useful for locales that used to be only in belocs. When they're added to standard locales package, users would want to migrate. Would you like me to send a patch for this? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages locales depends on: ii debconf [debconf-2.0] 1.4.72 Debian configuration management sy ii libc6 [glibc-2.3.6-2] 2.3.6-7GNU C Library: Shared libraries locales recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365628: postinst fails when LANG doesn't point to a valid locale
Package: locales Version: 2.3.6-7 Severity: important Tags: patch # LANG=xx_XX DEBIAN_FRONTEND=noninteractive dpkg-reconfigure locales [...] *** update-locale: Error: invalid locale settings: when update-locale LANG is invoked, it verified LANG variable and, if invalid, aborts the script. The typical situation when this happens is: - You had belocs-locales-data installed. - You had LANG set to a locale that is only available in belocs, and not in glibc locales. - You attempt to replace belocs-locales-data with glibc locales. The following fix worked for me: --- /var/lib/dpkg/info/locales.postinst~2006-04-14 15:45:25.0 +0200 +++ /var/lib/dpkg/info/locales.postinst 2006-05-01 17:46:22.0 +0200 @@ -66,7 +66,7 @@ # Set default LANG environment variable if [ -e $EE ]; then # Remove previous definitions -/usr/sbin/update-locale LANG +LANG= /usr/sbin/update-locale LANG fi if [ -n $SELECTED ] [ $SELECTED != None ]; then /usr/sbin/update-locale LANG=$SELECTED But according to the manpage, I don't see why update-locale should care about the LANG env variable. Perhaps the problem is there? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages locales depends on: ii debconf [debconf-2.0] 1.4.72 Debian configuration management sy ii libc6 [glibc-2.3.6-2] 2.3.6-7GNU C Library: Shared libraries locales recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365651: file collision with lliurex-belocs-locales-data
Package: locales
Version: 2.3.6-7
Severity: wishlist
Tags: patch
This is found when upgrading LliureX 5.09 (a CDD based on sarge) to Debian etch.
Preparing to replace locales 2.3.4-17+lliurex9 (using
.../locales_2.3.6-7_all.deb) ...
Unpacking replacement locales ...
dpkg: error processing /var/cache/apt/archives/locales_2.3.6-7_all.deb
(--unpack):
trying to overwrite `/usr/share/locale/be/LC_MESSAGES/libc.mo', which is
also in package lliurex-belocs-locales-data
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/locales_2.3.6-7_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
lliurex-belocs-locales-data collides with locales, but doesn't Conflict with
them. Unfortunately Conflicts cannot be used in our side, because this package
is depended on by other system components that ought not be removed. The
transition for these could be handled separately by a few dummy packages.
However, for what glibc locales is concerned, a Replaces should be enough to
avoid dpkg failure. (I think it's safe to assume that noone will be silly
enough to upgrade to etch and then downgrade back to sarge-based lliurex):
Index: debian/control.in/main
===
--- debian/control.in/main (revision 1465)
+++ debian/control.in/main (working copy)
@@ -33,7 +33,7 @@
Priority: standard
Depends: ${locale:Depends}, debconf | debconf-2.0
Conflicts: base-config
-Replaces: base-config
+Replaces: base-config, lliurex-belocs-locales-data
Description: GNU C Library: National Language (locale) data [support]
Machine-readable data files, shared objects and programs used by the
C library for localization (l10n) and internationalization (i18n) support.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-amd64-k8
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to C)
Versions of packages locales depends on:
ii debconf [debconf-2.0] 1.4.72 Debian configuration management sy
ii libc6 [glibc-2.3.6-2] 2.3.6-7GNU C Library: Shared libraries
locales recommends no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361972: glibc 2.4
Btw, the same patch should be fine for glibc 2.4 as well, since the ca.po translation (in which [EMAIL PROTECTED] is based) hasn't changed yet. I'm only concerned about 2.3.6 (or whatever that gets into etch) for now, though. Thanks, -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360491: uname -m broken in ia32 chroot
Package: libc6 Version: 2.3.6-3 Severity: important When running an i386-linux-gnu chroot on an x86_64-linux-gnu host: $ uname -m x86_64 This seriously breaks lots of native autoconf checks. A massive number of packages will FTBFS or work improperly when built inside the chroot. I think uname() should have hardcoded (#ifdef __x86_64__) machine name instead of asking Linux which doesn't always know. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356735: Compiling libc-udeb with -Os ?
On Mon, Mar 13, 2006 at 11:14:35PM -0500, Joey Hess wrote: Robert Millan wrote: I've tested what would be the size saving when building glibc with -Os: Huh, I think I've checked whether -Os helped pretty much everything in d-i, but never thought to try libc. Good idea, and this space savings would in fact be useful; both because we're bursting at the seams of some of the smaller CD images, and because it would help keep d-i running in 32 mb of memory As you can see in the other mail, it seems to cause some breakage with nptl and librt. I'm not sure if d-i needs threading at all (or even what librt is ;). Is that an issue for libc-udeb ? If it is, perhaps we could patch nptl/librt code to add the proper -O option to override previous -Os. I think this could be accepted in upstream. (assuming that the uncompressed sizes, which you didn't show, arn't suprising). Ah, I thought d-i already compressed them (e.g. cloop). Well, here is it: $ du -hs * 2.1Mnormal 1.8Mtiny $ du -h */lib/*.so 100Knormal/lib/ld-2.3.6.so 1.3Mnormal/lib/libc-2.3.6.so 24K normal/lib/libcrypt-2.3.6.so 12K normal/lib/libdl-2.3.6.so 540Knormal/lib/libm-2.3.6.so 72K normal/lib/libpthread-2.3.6.so 80K normal/lib/libresolv-2.3.6.so 12K normal/lib/libutil-2.3.6.so 88K tiny/lib/ld-2.3.6.so 1.1Mtiny/lib/libc-2.3.6.so 24K tiny/lib/libcrypt-2.3.6.so 12K tiny/lib/libdl-2.3.6.so 500Ktiny/lib/libm-2.3.6.so 68K tiny/lib/libpthread-2.3.6.so 68K tiny/lib/libresolv-2.3.6.so 12K tiny/lib/libutil-2.3.6.so -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356735: Compiling libc-udeb with -Os ?
Package: glibc Severity: wishlist I've tested what would be the size saving when building glibc with -Os: $ du -h */*udeb 1020K normal/libc6-udeb_2.3.6-3_amd64.udeb 12K normal/libnss-dns-udeb_2.3.6-3_amd64.udeb 20K normal/libnss-files-udeb_2.3.6-3_amd64.udeb 888Ktiny/libc6-udeb_2.3.6-3_amd64.udeb 12K tiny/libnss-dns-udeb_2.3.6-3_amd64.udeb 16K tiny/libnss-files-udeb_2.3.6-3_amd64.udeb For the udeb I think it's significant. I would suggest adding a build pass for -Os (and possibly other tinification options), and use that to prepare the udebs. What do you think? Would you like a patch for this? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
