Bug#598033: alsa-base: the configuration of snd-usb-audio is broken when USB audio is used alone
Package: alsa-base Version: 1.0.23+dfsg-1 Severity: normal If I unload all the alsa devices (by the command sudo alsa unload), then connect the single USB audio device to my PC, lsmod shows snd_usb_audio is loaded. However, the device numbering configuration is broken. For example, $ ls /dev/snd/ by-id/ by-path/ controlC1 pcmC0D0c pcmC0D0p seq timer controlC1 should be controlC0 because pcmC0D0c and pcmC0D0p is C0. I fixed this issue by comment out the line in /etc/modprobe.d/alsa-base.conf like: # Keep snd-usb-audio from beeing loaded as first soundcard #options snd-usb-audio index=-2 Now it works. Is this line really needed? The problem was, I couldn't listen to music on the movie sites (such as youtube.com) with web browser (Google Chrome) because flash accesses controlC0 but it didn't exist. I prefer to load snd-usb-audio as the first soundcard, but I don't think it's good idea to number controlC1 instead of controlC0. -- Package-specific info: --- Begin additional package status --- Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libasound2 1.0.23-1 shared library for ALSA applications --- End additional package status --- --- Begin /proc/asound/version --- Advanced Linux Sound Architecture Driver Version 1.0.21. --- End /proc/asound/version --- --- Begin /proc/asound/cards --- 0 [Device ]: USB-Audio - Kenwood Audio Device Kenwood Kenwood Audio Device at usb-:00:1d.7-3.4.2, full speed --- End /proc/asound/cards --- --- Begin /dev/snd/ listing --- total 0 drwxr-xr-x 2 root root 60 Sep 26 01:46 by-id drwxr-xr-x 2 root root 60 Sep 26 01:46 by-path crw-rw 1 root audio 116, 6 Sep 26 01:46 controlC0 crw-rw 1 root audio 116, 5 Sep 26 01:46 pcmC0D0c crw-rw 1 root audio 116, 4 Sep 26 01:50 pcmC0D0p crw-rw 1 root audio 116, 3 Sep 26 01:46 seq crw-rw 1 root audio 116, 2 Sep 26 01:46 timer --- End /dev/snd/ listing --- -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-bpo.4-amd64 (SMP w/8 CPU cores) Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) Shell: /bin/sh linked to /bin/bash Versions of packages alsa-base depends on: ii linux-sound-base 1.0.23+dfsg-1 base package for ALSA and OSS soun ii lsof 4.81.dfsg.1-1 List open files ii module-init-tools 3.12-1tools for managing Linux kernel mo ii udev 160-1 /dev/ and hotplug management daemo Versions of packages alsa-base recommends: ii alsa-utils1.0.23-2 Utilities for configuring and usin Versions of packages alsa-base suggests: ii alsa-oss 1.0.17-4 ALSA wrapper for OSS applications ii apmd 3.2.2-14 Utilities for Advanced Power Manag ii oss-compat0.0.4+nmu3 OSS compatibility package Versions of packages libasound2 depends on: ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib -- Configuration Files: /etc/modprobe.d/alsa-base.conf changed [not included] -- debconf information: alsa-common/card-list: alsa-base/alsactl_store_on_shutdown: always autosave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8
I don't agree with the concept of UTF-8-CJK because it's over exaggerated. Is it a locale dependent issue, or character encoding issue? According to UAX#11, your point doesn't make sense because your reference just mention about character mapping. Instead, When processing or displaying data section says, Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default. If the all legacy applications use wcwidth() supposing the width of ambiguous font size = 2, it's OK to introduce your idea - but I'm not sure it's true or not. Font rendering application should basically consider the font size. Why doesn't rxvt consider about such font rendering size? Or should we introduce special environment variable or locale tag to decide the behavior of wcwidth value for ambiguous characters? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#406475: marked as forwarded (lv: weird behavior when viewing a file of very long name)
At Sun, 27 May 2007 12:27:59 -0700, Yoshio Nakamura wrote: lv 4.51 When 'lv' displays a file that has a filename longer than the terminal width, it displays the full filename at the bottom of the screen (taking more than one line), but this forces the first line of the file off of the screen. This was reported by Oohara Yuuma in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406475 Indeed. It would be nice to fix when the terminal is narrow. Yuuma also reports that pressing 'b' or 'u' to go up only results in printing the filename again. The user must press space then 'b' or 'u' to see the first line. 'less' avoids this problem by only displaying the last characters of the filename on the last line of the terminal. 'more' only displays --More--(x%), unless there are many files to display, in which case it also has the same problem --More--(Next file: VeryLongFilename.txt) Please fix the problem where the first line of the file to be displayed is not displayed. Narita-san, do you have any insights about these issues? 成田さん、すぐに直すのは大変でしょうか？ Thanks, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424027: ttf-kochi-mincho: some glyphs become thin when bold
At Wed, 23 May 2007 11:53:28 +0900, Kazuhiro NISHIYAMA wrote: Thanks for your report. However, we still provide ttf-kochi-mincho, but it'll be deprecate because it's not maintained these days. I'll add such statement for these packages. Could you use ttf-sazanami and test it again if possible? When I use ttf-sazanami-mincho, it looks good. At first I found problems when I see HTML such as h1 style=' font-family: serif;'キーボード/h1 in iceweasel. After I change serif font of iceweasel to sazanami-mincho, the problem is solved. OK. I'll add a description that recommends ttf-sazanami fonts. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424027: ttf-kochi-mincho: some glyphs become thin when bold
At Tue, 15 May 2007 20:40:07 +0900, Kazuhiro NISHIYAMA wrote: following glyphs become thin when bold on gucharmap, iceweasel, and so on. * U+30AD KATAKANA LETTER KI * U+30AE KATAKANA LETTER GI * U+30B7 KATAKANA LETTER SI * U+30B8 KATAKANA LETTER ZI * U+30F3 KATAKANA LETTER N * U+FF7C HALFWIDTH KATAKANA LETTER SI * U+FF8D HALFWIDTH KATAKANA LETTER HE * U+FF9D HALFWIDTH KATAKANA LETTER N Thanks for your report. However, we still provide ttf-kochi-mincho, but it'll be deprecate because it's not maintained these days. I'll add such statement for these packages. Could you use ttf-sazanami and test it again if possible? Thanks, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378015: lha not being built for amd64.
At Wed, 12 Jul 2006 17:22:32 +0100, Rob Andrews wrote: Package: lha Version: 1.14i-10 Severity: normal lha is not being built for the amd64 port. I thought that maybe the build was failing, but after apt-get -b source lha successfully built and packaged it, I figured this was not the case. My tests show that it does work once built. This is caused because non-free amd64 packages are not automatically built. I don't know this should be handled by each package maintainer level... Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401301: marked as done (lha: LHa Multiple Vulnerabilities)
At Wed, 13 Dec 2006 15:03:26 -0800, Debian Bug Tracking System wrote: To: [EMAIL PROTECTED] Subject: Fixed From: Moritz Muehlenhoff [EMAIL PROTECTED] Date: Wed, 13 Dec 2006 23:35:27 +0100 Message-ID: [EMAIL PROTECTED] Version: 1.14i-10.1 Thanks for your help! I'll check the patch. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399205: libsmbios-dev: where is libsmbios.so ?
libsmbios-dev does not provide libsmbios.so, making it impossible to link against libsmbios. libsmbios1 has libsmbios.so - or do I misunderstand your bug report? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391828: should use $(CURDIR) instead of $(PWD) in debian/rules
Hi, I saw the following from http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=391828 I'm just commiting a fix for this in my archive. I'll try to make a release with this fix and a few others shortly. Do you have any plans to upload a newer version of the package? Now the bug is marked as release critical - it should be fixed. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381562: klic: FTBFS: No targets specified and no makefile found.
Julien, Mohammed, At Sun, 6 Aug 2006 19:51:47 +0200, Mohammed Adnène Trojette wrote: On Sat, Aug 05, 2006, Julien Danjou wrote: Do you want to use X-based multi-window tracer? (yes or no) [no] touch configure-stamp There is a missing space that prevents the build when using dash. The following trivial patch should address the issue on dash. This is caused by this: | if ( echo test line\c; echo ) | grep c /dev/null 2/dev/null ; then | n='-n' | c='' | else | n='' | c='\c' | fi bash verifies the first while dash verifies the second. Hence the trailing space. Either use #! /bin/bash in Configure or add the space to your debian/configure.expect script to fix the bug. Thanks for your reports and tracking this bug. I fixed to change debian/configure.expect to see the trailing space. I've uploaded it. Thanks again, Masanori Goto
Bug#367295: ttf-kochi-*: warn of obsolescence in Description
At Mon, 31 Jul 2006 01:04:34 +0800, Dan Jacobson wrote: But ttf-kochi-* fonts became obsolete because upstream authors stopped OK, but dpkg -p ttf-kochi-* still talks about them like they are great. The user is not warned... Exactly. I'll change the descriptions of ttf-kochi-* packages. to develop new fonts. Please use ttf-sazanami-* fonts instead. I will drop kochi when sazanami get more popularity. Wait, I can't remove them without ruining xpdf!: The following packages will be REMOVED: ttf-kochi-gothic* ttf-kochi-mincho* xpdf-japanese* Indeed. apt-cache showpkg ttf-kochi-mincho shows: Reverse Depends: libpango1.0-common,ttf-kochi-mincho mgp,ttf-kochi-mincho ttf-kochi-mincho-subst-naga10,ttf-kochi-mincho ttf-kochi-mincho-subst-naga10,ttf-kochi-mincho xpdf-japanese,ttf-kochi-mincho ttf-kochi-mincho-naga10,ttf-kochi-mincho ttf-kochi-gothic-naga10,ttf-kochi-mincho sun-java5-jre,ttf-kochi-mincho gs-cjk-resource,ttf-kochi-mincho xdvik-ja,ttf-kochi-mincho vflib2,ttf-kochi-mincho ttf-kochi-gothic,ttf-kochi-mincho mgp,ttf-kochi-mincho libpango1.0-common,ttf-kochi-mincho libkiten1,ttf-kochi-mincho kiten,ttf-kochi-mincho kanjipad,ttf-kochi-mincho gjiten,ttf-kochi-mincho advi-examples,ttf-kochi-mincho advi,ttf-kochi-mincho I'll check these dependencies. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367295: U+8392 etc. wrong
At Mon, 15 May 2006 05:49:16 +0800, Dan Jacobson wrote: Package: ttf-kochi-mincho-naga10 Version: 1.0.20030809-4 Severity: normal The characters at U+8392 and those nearby are wrong! Compare ttf-kochi-gothic. Absolutely. I guess authors did not paste characters correctly. I reported this bug to the BSS at http://wiki.fdiary.net/font/?kochi-alternative . But ttf-kochi-* fonts became obsolete because upstream authors stopped to develop new fonts. Please use ttf-sazanami-* fonts instead. I will drop kochi when sazanami get more popularity. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270520: lm_batmon: patch for ACPI support
Dear Christian, lm_batmon only works with APM, not with ACPI. I've created a small patch that enables ACPI support. It was sucessfully tested on a Thinkpad T30 with vanilla Kernel 2.6.7. Thank you for your ACPI modification. Finally, your patch have been merged into the upstream original source tarball. I'll upload newer Debian version lm-batmon_0.98-1.deb. Regards, Masanori Goto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368284: still uses X11R6 directories
Dear Frank,
Great, thanks for your change, I'll upload it with applying your fix
after tests.
Thanks,
-- gotom
At Sun, 21 May 2006 01:56:58 -0500,
Frank Lichtenheld wrote:
Package: xipmsg
Severity: serious
Tags: patch
This is a policy violation now.
Patch (despite changelog entry not intended for immediate upload):
diff -Naur xipmsg-0.8088/debian/changelog xipmsg-0.8088.nmu/debian/changelog
--- xipmsg-0.8088/debian/changelog2006-05-21 00:34:55.0 -0500
+++ xipmsg-0.8088.nmu/debian/changelog2006-05-21 01:52:50.0
-0500
@@ -1,3 +1,15 @@
+xipmsg (0.8088-1.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Adapt menu file and XIpmsg_jp.ad to new location of files after
+rebuild with new Xorg.
+ * Change build-depends on xutils to xutils-dev
+ * Add Pre-Depends on x11-common since we still use /usr/lib/X11
+ * Delete debian/conffiles because debhelper actually takes care
+of that for us
+
+ -- Frank Lichtenheld [EMAIL PROTECTED] Sun, 21 May 2006 01:50:16 -0500
+
xipmsg (0.8088-1.1) unstable; urgency=high
* Non-maintainer upload.
diff -Naur xipmsg-0.8088/debian/conffiles xipmsg-0.8088.nmu/debian/conffiles
--- xipmsg-0.8088/debian/conffiles2006-05-21 00:34:55.0 -0500
+++ xipmsg-0.8088.nmu/debian/conffiles1969-12-31 18:00:00.0
-0600
@@ -1,2 +0,0 @@
-/etc/X11/app-defaults/XIpmsg
-/etc/X11/ja_JP.eucJP/app-defaults/XIpmsg
diff -Naur xipmsg-0.8088/debian/control xipmsg-0.8088.nmu/debian/control
--- xipmsg-0.8088/debian/control 2006-05-21 00:34:55.0 -0500
+++ xipmsg-0.8088.nmu/debian/control 2006-05-21 01:30:56.0 -0500
@@ -2,11 +2,12 @@
Section: x11
Priority: optional
Maintainer: GOTO Masanori [EMAIL PROTECTED]
-Build-Depends: debhelper (= 4.0.0), xutils, libx11-dev, libxt-dev, x-dev,
libxaw7-dev
+Build-Depends: debhelper (= 4.0.0), xutils-dev, libx11-dev, libxt-dev,
x-dev, libxaw7-dev
Standards-Version: 3.6.0
Package: xipmsg
Architecture: any
+Pre-Depends: x11-common (= 1:7.0.0)
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: A pop up style message communication software
IP Messenger is a pop up style message communication software
diff -Naur xipmsg-0.8088/debian/dirs xipmsg-0.8088.nmu/debian/dirs
--- xipmsg-0.8088/debian/dirs 2006-05-21 00:34:55.0 -0500
+++ xipmsg-0.8088.nmu/debian/dirs 2006-05-21 00:40:34.0 -0500
@@ -1,8 +1,4 @@
etc/X11/app-defaults
etc/X11/ja_JP.eucJP/app-defaults
-etc/X11
-usr/X11R6/bin
-usr/X11R6/lib/X11/xipmsg
-usr/X11R6/man/man1
usr/lib/menu
usr/share/doc/xipmsg
diff -Naur xipmsg-0.8088/debian/menu xipmsg-0.8088.nmu/debian/menu
--- xipmsg-0.8088/debian/menu 2006-05-21 00:34:55.0 -0500
+++ xipmsg-0.8088.nmu/debian/menu 2006-05-21 00:35:28.0 -0500
@@ -1,2 +1,2 @@
?package(xipmsg):needs=x11 section=Apps/Net\
- title=xipmsg command=/usr/X11R6/bin/xipmsg
+ title=xipmsg command=/usr/bin/xipmsg
diff -Naur xipmsg-0.8088/debian/rules xipmsg-0.8088.nmu/debian/rules
--- xipmsg-0.8088/debian/rules2006-05-21 00:34:55.0 -0500
+++ xipmsg-0.8088.nmu/debian/rules2006-05-21 01:45:54.0 -0500
@@ -33,7 +33,7 @@
# Add here commands to compile the package.
xmkmf -a
$(MAKE)
- sed 's!XIPM_XBMDIR!/usr/X11R6/lib/X11/xipmsg!g' XIpmsg_jp.ad.in
XIpmsg_jp.ad
+ sed 's!XIPM_XBMDIR!/usr/lib/X11/xipmsg!g' XIpmsg_jp.ad.in XIpmsg_jp.ad
touch build-stamp
Gruesse,
Frank Lichtenheld
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-powerpc
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330680: cifs: files with large file names are missing
I use cifs to mount a couple of samba shares and files with long names are not displayed. When I access the same shares, using LAN Browsing in konqueror, the files are there. It looks like it has too do with the total length (inclusive directories) of the filename. for example: /incoming/test2/a 92 characters long filename : gives problems /incoming/test/a 92 characters long filename : doesn't Try the latest 2.6.15 kernel image. It works nicely under my environment with such long filenames that includes space characters. CIFS allows 255 characters per one directory name. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353031: posix_fadvise defines missing
At 16 Feb 2006 13:00:08 -0500, Greg Stark wrote: The man pages come from manpages-dev. It seems like the necessary #defines should be included in each man page along with the necessary #includes. I suspect I'll be tilting at windmills trying to convince people of this though. Can we reassign your report to manpages-dev, or just close it? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350103: Please update debconf PO translation for the package glibc 2.3.5-13
At Fri, 27 Jan 2006 11:50:11 +0100, [EMAIL PROTECTED] wrote: you are noted as the last translator of the debconf translation for glibc. The English template has been changed, and now some messages are marked fuzzy in your translation or are missing. I would be grateful if you could take the time and update it. Please respect the Reply-To: field and send your updated translation to [EMAIL PROTECTED] if this bug is still open, or file a new one otherwise. Here are the changes which have been performed on English templates, to follow recommandations from http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s6.5.4 I've committed Japanese translation to svn. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339110: [INTL:pt] Portuguese translation for glibc (Debconf)
Thanks, I see the difference between pt_BR and pt. I put it in. -- gotom At Tue, 20 Dec 2005 23:18:35 +, Miguel Figueiredo wrote: pt.po it's for European Portuguese (Portuguese) and pt_BR.po it's for Brazilien Portuguese. One doesn't replace the other. At Wed, 21 Dec 2005 21:45:37 +, Rui Branco wrote: In fact our pt.po is different from the pt_BR.po. Our pt.po is the European Portuguese translation, and the pt_BR.po the Brazilian Portuguese translation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#149902: Australian time zones
At Tue, 20 Dec 2005 08:26:29 +0100, Martijn van Oosterhout wrote: Wow, this is a bug come back from the dead. I read the summary in glibc and think it's wierd. For example, the counts supposedly showing Eastern Standard Time to be more popular than Australia Eastern Standard Time are bogus. The first search is obviously going to include the results of the second. A simple calculation shows that even then the prefix was four times as common as without. Current figures from Google: Australian Eastern Standard Time site:.au 155000 Eastern Standard Time site:.au206000 Eastern Standard Time -Australian Eastern Standard Time site:.au 5 This information is probably useful to change upstream timezone maintainer's mind. Do you have actual information of the goverment statements? If Australian goverment decided to encourage using AEST instead of EST, it's also useful. If you have one, we should transfer your information to upstream. But in my mind the argument is simple: EST is ambiguous, AEST is not. The issue I had has to do with input, not output. Saying 9:00 EST is ambiguous, but 9:00 AEST is not even recognised as a valid date. Obviously you can't remove all ambiguity, but it's certainly worth removing whenever possible. There is still no way to specify an Australian timezone to date, which I suppose is the real bug. Yes, you can affect it with environment variables, but still... $ date --date='9:00 Australia/Sydney' date: invalid date `9:00 Australia/Sydney' $ date --date='9:00 EST' Tue Dec 20 15:00:00 CET 2005 --- ??? Not european time. What is it? $ date --date='9:00 AEST' date: invalid date `9:00 AEST' Actually upstream author also considered this ambiguity, and they finally decided short abbreviated timezone could be conflicted each other - for example they explained IST in their arguments (did you see australasia file?). -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339827: linuxthreads crashes when using user stacks
At Mon, 19 Dec 2005 21:29:43 -0500, Daniel Jacobowitz wrote: On Tue, Dec 20, 2005 at 10:38:47AM +0900, GOTO Masanori wrote: At Sun, 20 Nov 2005 14:22:22 -0500, Daniel Jacobowitz wrote: Steve Langasek agreed. I am planning to bump the requirement up from 2.2.whatever to 2.4.0 for i486 and powerpc; i486 in order to enable floating stacks, and powerpc because we've been getting bug reports that indicate that static binaries are already broken there under 2.2, and no one wants to debug it. Any objections before I do this? Is it already done? If it's pended, I'll ask it to [EMAIL PROTECTED] The security support for 2.2 series was finished, we have no reason to support 2.2 kernel. No, it isn't :-( I didn't get around to it; if you could, that would be great. Okay, I see. It's time to transit. Note that the current status of the support kernel versions are: amd64 2.6.0 i386(i686) 2.6.0 i386(amd64) 2.6.0 *(nptl) 2.6.0 ppc64 2.6.0 s390x 2.4.1 sparc64 2.4.18 sparcv9 2.4.18 sparcv9b2.4.18 others 2.2.0 They'll be changed to: i386(i486) 2.4.1 powerpc 2.4.1 (?) BTW, note that some architectures like m68k could not compile the recent glibc with kernel 2.4.x or 2.6.x. Might want to check with the s390x and sparc porters, too. If 2.4 is dead for those architectures, we don't need to carry it around. ARM could probably use a bump, but I'm not sure to what. Thanks for your comments. I'll consider about such architectures. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. Okay, I close it. If you think there's bugs in libc, please tell me about it. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#149902: Australian time zones
At Fri, 9 Dec 2005 16:43:48 +1100, [EMAIL PROTECTED] wrote: The official list of timezones for Australia, as provided by the Australian Government, does not include EST anywhere on the page. AEST is the correct abbreviation. quote url=http://www.australia.gov.au/about-australia-13time; There are three times zones in Australia - * Australian Eastern Standard Time (AEST): Greenwich Mean Time (GMT) plus 10 hours for standard time and 11 hours for daylight savings time. AEST is followed in these regions: o New South Wales o Victoria o Queensland o Tasmania o Australian Capital Territory * Australian Central Standard Time (ACST): GMT plus 9 ½ hours for standard time and 10 ½ hours for daylight savings time. ACST is followed in these regions: o South Australia o Northern Territory * Australian Western Standard Time (AWST): GMT plus 8 hours. AWST is followed in these regions: o Western Australia /quote This should be re-opened as a bug. Timeanddate.com do not have the most correct timezone information on their website, the Australian Government do. Note that you probably want to know why AEST vs EST is long-standing problem: the short summary is available in glibc source tree timezone/australasia. Not only one governmental page but also showing another information source would be nice idea to change time zone maintainers. -- gotom
Bug#340147: /etc/init.d/glibc.sh must use ': exit 0' instead of 'exit 0'
At Mon, 21 Nov 2005 10:42:14 +0100, Petter Reinholdtsen wrote: The script /etc/init.d/glibc.sh can not be sourced, as it contain 'exit 0' at the end of the script. This is against policy, specifying that all .sh scripts in /etc/rcS.d/ will be sourced. I discovered this while fixing sysv-rc (bug #339955), as the boot started to fail because glibc.sh terminated the script running the files in /etc/rcS.d/. Changing 'exit 0' to ': exit 0' solved the issue. Setting severity serious, as this Debian Policy §9.3.1 require .sh scripts in runlevel S to be sourced, and this is impossible as long as this bug is open. I've modified it as your request. -- gotom
Bug#339110: [INTL:pt] Portuguese translation for glibc (Debconf)
At Mon, 14 Nov 2005 23:26:04 +, Rui Branco wrote: Portuguese translation for glibc's debconf messages by Simão Pedro Cardoso [EMAIL PROTECTED] Feel free to use it. For translation updates please contact last translator and/or CC the Portuguese translation team traduz _at_ debianpt.org Thanks for your work, but I have a question: there's already pt_BR.po in libc6 files. Is your pt.po different from pt_BR.po? Or is it just updates from pt_BR.po (so your file should be renamed from pt.po to pt_BR.po)? -- gotom
Bug#339827: linuxthreads crashes when using user stacks
At Sun, 20 Nov 2005 14:22:22 -0500, Daniel Jacobowitz wrote: Steve Langasek agreed. I am planning to bump the requirement up from 2.2.whatever to 2.4.0 for i486 and powerpc; i486 in order to enable floating stacks, and powerpc because we've been getting bug reports that indicate that static binaries are already broken there under 2.2, and no one wants to debug it. Any objections before I do this? Is it already done? If it's pended, I'll ask it to [EMAIL PROTECTED] The security support for 2.2 series was finished, we have no reason to support 2.2 kernel. Note that the current status of the support kernel versions are: amd64 2.6.0 i386(i686) 2.6.0 i386(amd64) 2.6.0 *(nptl) 2.6.0 ppc64 2.6.0 s390x 2.4.1 sparc64 2.4.18 sparcv9 2.4.18 sparcv9b2.4.18 others 2.2.0 They'll be changed to: i386(i486) 2.4.1 powerpc 2.4.1 (?) BTW, note that some architectures like m68k could not compile the recent glibc with kernel 2.4.x or 2.6.x. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340388: CONFIG_USB_AUDIO should be compiled with 2.6.14
Package: linux-image-2.6.14-2-686-smp Version: 2.6.14-3 Severity: wishlist Hi, I request you to change .config settings as follows: CONFIG_OBSOLETE_OSS_USB_DRIVER=y CONFIG_USB_AUDIO=m It's an obsolete device driver, but it's useful with some USB audio devices. Because alsa snd-usb-audio sometimes disconnects with such usb peripherals. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329108: gcc-4.0 FTBFS on, uh, i386
At Mon, 19 Sep 2005 19:27:15 +0200, Matthias Klose wrote: On the latest i386 Sid, gcc-4.0 does not build from source, on my machine, and on a buildd (see the logs). With dash as sh, I get: this is known, we're waiting on proper 64bit support from glibc. I'd like to downgrade this one until we have the support. Goto, you did say, you wanted address this after the last update. any news? Does this mean glibc needs to support i386 support on amd64? If so, no progress yet because I thought Jeff worked for it. Should it to be available for gcc-4.0? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328795: very old package, should this be removed?
severity 328795 normal thanks [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. I guess plum fits [1] and [4]. It's one idea to find unmaintained old packages - but this package is binary-all - it's also true that such package just works fine even after three years upload. Upstream does not update this program for a long time because it's mostly completed. Of course, it's sure to update this package's debian version, though. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324795: libc6 in stable broken on arm4vl
At Sun, 11 Sep 2005 01:05:42 -0400, Rob Warren wrote: I've just installed sarge onto the second netwinder without any problems with libc 2.3.2.ds1-22 with the netboot image, kernel 2.4.27. ...then I tried to boot from the kernel I was previously using (2.2.19) and got the dreaded result: unsupported llseek call standard What was this message come from? Dmesg? Tried with 2.2.17 and got the same result. Can we add a dependency to the libc package to prevent this from happening to others? Before doing any work, I would like to clear what your problem was. Previously we discussed as follows: libc6 from 2.2.5-11.8 to 2.3.2.ds1-22 with a message along the lines of 'can't seek in file xx'. dmesg would report 'Bad number of arguments for llseek()' (paraphrasing) every so often. It was impossible to reserve the package install. Weird. Grep told me that dmesg (kernel 2.2.19) and glibc should not warn such kind of messages. This means we need to confirm that your kernel is special or debian standard one. If you use your custom kernel, we may not reappear such kind of problem again. Could you describe the following stuff? (1) your exact kernel version and how to get it (2) the exact warning/error message. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326594: fpsetdefaults function missing in glibc-2.3.5
At Sun, 4 Sep 2005 11:41:17 +0200, Matthias Klose wrote: glibc-2.3.5 doesn't have the fpsetdefaults function anymore, which was available in 2.3.2. Is the omission intended? If yes, is there a replacement function? Currently the python fpectl module fpectl FTBFS. I guess python misdetected OS: HP-UX, not Linux. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327219: libc6: FVWM bombs when KDE windows are resized if non-KDE audio players are running.
At Thu, 8 Sep 2005 06:26:19 -0700 (PDT), Kokushoku Karasu wrote: This has to be the weirdest bug I've seen. Earlier I had a strange exit of FVWM, at the time I had been messing with the window for k3b, then I see the kdm greeting screen. Conclusion, something crashed. After two more unplanned exits, I did some investigating. Results: When trying to resize a KDE program's window in FVWM if I have xmms or plaympeg running, there's a (good) chance that FVWM will make a forced exit. KDE itself doesn't seem affected by this. Nor did any of the other WMs I tested. The programs I've seen it exit with: Konqueror, Kmail, k3b, I would call it grave, but an earlier version does not have this bug. I suppose it could be a bug in one of the main KDE system files, or in some dependancy of xmms' or plaympeg's. There're a lot of fvwm variants. Please describe the actual package name you use, because I can't reassign your report to the appropriate package. I think this problem is not libc6 matter, but kde, fvwm and X11 interaction issue. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324900: nscd: umount /var fails (unclean shutdowns)
At Thu, 1 Sep 2005 15:00:23 +0200, Gabor Gombas wrote: Why is this unconditionally happenned? What setting does this cause this problem? Because bash calls getpwuid() to initialize the value of $SHELL before executing the script. I understand the whole story - this problem could be happenned on all Debian system - but almost all people including me uses 4 (Let /var be the same filesystem as /), so this problem is hidden. Indeed, there're some activities and discussions to modify init processes. I expect your described choice 3 or 5 will be accepted widely. 3. Convert /etc/init.d/rc to be an ELF executable instead of a shell script 5. Redesign the init system so unmounting of local file systems is done _after_ /etc/init/rc has finished (and the program that does the unmounting must not be a shell script) I think this problem is not only glibc problem - rathar, should I reassign it to the appropriate package, for example /etc/init.d/rc (sysv-rc) to tell to the maintainer about this kind of issue? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325802: libc6: glibc.sh uses dpkg
At Wed, 31 Aug 2005 01:12:25 -0400, Daniel Jacobowitz wrote: /etc/init.d/glibc.sh uses dpkg --compare-versions extensively. [EMAIL PROTECTED]:~% which dpkg /usr/bin/dpkg Init scripts, at least this early, can't use /usr. It isn't mounted yet! Good point, I missed this issue. I don't know the exact way to fix for this: (1) Use sed script instead of dpkg. (2) Don't mind even if dpkg is existed at /usr/bin - this check is just passed through. (3) dpkg should be put at /bin instead of /usr/bin. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324900: nscd: umount /var fails (unclean shutdowns)
At Wed, 31 Aug 2005 17:48:20 +0200, Gabor Gombas wrote: Well, if /bin/sh is bash, then it is not weird at all, it is the same bash vs. NSS problem that came up several times in the past (last time quite recently on debian-devel). Previously it only happened with NSS modules that link to libraries under /usr, now it also affects nscd. Thanks for your detailed explanation. - by calling /etc/init.d/rc, bash is executed - bash unconditionally does some NSS calls during startup (getpwuid etc.); this in turn - loads all NSS modules that serve passwd maps - if a module uses libraries from /usr, now you have a live memory mapping under /usr so you cannot unmount it during shutdown Why is this unconditionally happenned? What setting does this cause this problem? - bash (libc) connects to nscd - nscd sends a file descriptor of /var/db/nscd/passwd to bash, and bash does an mmap(2) on the received fd - now you have a live memory mapping under /var thus you cannot unmount it during shutdown - /etc/init.d/rc eventually kills nscd but that does not help, since the bash process executing /etc/init.d/rc still has the cache file mapped (deleting the cache file also doesn't help since unlink(2) only operates on the directory and does not invalidate the memory mapping) Zlatko, could you confirm what process actually has this mapping using lsof? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309846: locales: new localedef.1 manual page
At Wed, 31 Aug 2005 00:17:09 +0200, Denis Barbier wrote: Attached is a new version of the localedef.1 manual page (debian/local/manpages/localedef.1) and a diff against the previous version (the former is there so that people who want to review it can more easily get a complete version). I have added descriptions of options that were missing (presumably added since the manual page was originally written years ago), and clarified the behavior in general. I hope it is complete and correct, but it might not be. I had to read through the source and experiment, and I may have overlooked or misinterpreted something. Should be better than the current version, however. I'm sorry I missed your patch. Here are points which could be modified: * When the output directory does not exist, localedef aborts and its error message is not very helpful, so this could be mentioned in this man page. This is for instance annoying when testing the --prefix flag. * I18NPATH is a colon separated list of directories. It cannot be applied cleanly to the current svn... Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324900: nscd: umount /var fails (unclean shutdowns)
At Fri, 26 Aug 2005 11:52:30 +0200, Zlatko Calusic wrote: No file-rc, and no long running (bash or other) processes. Here's process list just before /etc/init.d/umountfs runs the umount command, with only kernel daemons removed (they're not interesting, and too many of them): UIDPID PPID C STIME TTY TIME CMD root 1 0 0 12:42 ?00:00:00 init [6] root 1119 1 0 12:47 ?00:00:00 /bin/sh /etc/init.d/rc 6 root 1421 1119 0 12:47 ?00:00:00 /bin/sh /etc/rc6.d/S40umountfs stop root 1424 1421 0 12:47 ?00:00:00 ps -ef As you can see, we have just init, bash that has just spawned /etc/init.d/rc (from initscripts), and rc has reached S40umountfs in runlevel 6. The real question would be, how in the hell rc managed to have /var/db/nscd/passwd mapped, when nscd has exited long ago. Even bigger mistery happens when I disable persistent cache, than rc somehow inherits file descriptor (or was it also file mapping?) to a deleted file in /var/run?! rc1119 root mem REG8,9 217016 228931 /var/db/nscd/passwd It's very weird behavior. Please disable nscd when your boot up time, and then run /etc/init.d/nscd. You can see which processes have such nscd file descriptor (fd), and you can clear process inheritance with pstree easily. If nothing has nscd fd, we can clear rc behaves oddly. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317082: Status report?
At Sat, 27 Aug 2005 16:16:14 -0400, Nathanael Nerode wrote: #317082 is moreinfo. Has a decision been made on how to fix this? If not, frankly it should be downgraded to important, because it only hurts biarch -- meaning it isn't actually a blocker for any single subarchitecture -- and that's not nearly as bad as holding up every package on every single arch. In glibc side, I added lib64gcc1 for s390x Depends in 2.3.5-4. So it's probably OK to split this report for glibc and dpkg. But, the actual fix for dpkg is under discussion, and I would like to keep discussing about it. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325600: libc6.1: Threads remain defunct on Alpha with libc6. 2.3.5-4
At Mon, 29 Aug 2005 13:18:01 -0400, Thomas Evans wrote: Threads that have properly called pthread_detach() and pthread_exit() are not being cleaned up and remain in the process list as defunct until the parent exits. This does not occur on systems running testing and has appeared only recently. This is Linuxthreads/alpha bug. Currently glibc package don't execute test suite for alpha because some tests are stopped due to this kind of problem. Upstream already moved to NPTL - but I expect someone looks at this problem. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325600: libc6.1: Threads remain defunct on Alpha with libc6. 2.3.5-4
At Mon, 29 Aug 2005 20:28:01 -0400, Thomas Evans wrote: When you state Upstream already moved to NPTL, do you mean the mainline libc development, or do youe mean that Debian/alpha libc is moving to NPTL? The mainline libc, not debian alpha glibc. But I guess adding debian alpha NPTL is not difficult task - but (1) I have no access to the alpha machine without appropriate privileges (2) alpha buildd is not 2.6 kernel. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64.
severity 325226 important thanks At Sat, 27 Aug 2005 00:07:17 +0200, Kurt Roeckx wrote: It seems that on amd64, all binaries and libraries in the libc6 pacakge have a wrong dynamic linker in the binaries. ldd /lib/libc.so.6 /lib/ld-linux-x86-64.so.2 (0x002a95556000) ldd /usr/bin/iconv libc.so.6 = /lib/libc.so.6 (0x002a9566e000) /lib/ld-linux-x86-64.so.2 (0x002a95556000) ... The ABI says that it should be /lib64/ld-linux-x86-64.so.2, and every other binary and lib does have that, except for things in the libc6 package. Note that that we have a /lib64 - lib symlinks, and that everything should get installed in /lib, it's just that the path in the binaries itself is wrong. I don't think it's really important, but it's probably nice to have this fixed. If you're going to fix this, could you please provide a patch for this so I can test it before you upload it? This bug exists in both sarge (2.3.2.ds1-22) and sid (2.3.5-4). Actually this bug is serious and grave. However, considering this problem, I need to investigate this issue more. In addition, I plan to fix /lib64 - /lib things (I'll post about it). I'm sorry but I put glibc 2.3.5-5 without two patches from Andreas' ppc64 and the fix for your problem, because testing is dammed. I focus them in the next 2.3.5-6. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324900: nscd: umount /var fails (unclean shutdowns)
At Thu, 25 Aug 2005 09:59:46 +0200, Zlatko Calusic wrote: GOTO Masanori [EMAIL PROTECTED] writes: At Wed, 24 Aug 2005 20:14:43 +0200, Zlatko Calusic wrote: With the latest changes in nscd functionality, namely using persistent database in /var/db/nscd, /var partition can't be cleanly umounted. I tried to avoid the problem by disabling persistent database, but even that didn't help because nscd keeps open descriptor to a deleted file in /var/run, and somehow /etc/init.d/rc inherits it. This is the relevant part of the lsof output fired just before the umount line in /etc/init.d/umountfs: COMMANDPID USER FD TYPE DEVICESIZE NODE NAME rc2470 root DEL REG3,9 1093449 /var/run/nscd/dbUUHtCX I missed this line. /var/run/nscd/dbXX is created at nscd_init() in nscd/connections.c. However, even if this file is created, it's closed soon in the same initialization routine. rc does not have any relations with this temporary file. So, if this file is marked as open, someone takes over fd of /var/run/nscd/dbXX and it passes to rc. Why didn't your nscd shutdown before /etc/init.d/umountfs was invoked? Under my standard sid environment, such problem does not occur because nscd is stopped before umount is executed. But it DID! To prove it, here's full lsof output, there's no mentioning of nscd running. I'm also confused how that one reference leaks to /etc/init.d/rc. But it happens on three machines, so it is very repeatable here. Could you reinstall libc6 and nscd packages again? Hmm, is this problem repeatable even after rebooting the system? If so, rc or some packages behave incorrectly. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323849: locales: error on install: double free or corruption
reassign 323849 libterm-readline-gnu-perl severity 323849 important merge 304604 323849 322746 thanks At Thu, 18 Aug 2005 13:30:59 -0700, Ross Boylan wrote: My system is mostly testing, but I upgraded parts to unstable, including glibc. During that same upgrade, I got the error: - Setting up locales (2.3.5-3) ... Generating locales (this might take a while)... en_US.ISO-8859-1... done en_US.UTF-8... done eu_ES.ISO-8859-1... done [EMAIL PROTECTED] done fr_FR.ISO-8859-1... done fr_FR.UTF-8... done [EMAIL PROTECTED] done Generation complete. *** glibc detected *** double free or corruption (!prev): 0x089a79c8 *** dpkg: error processing locales (--configure): subprocess post-installation script killed by signal (Aborted) This is known bug, but not glibc. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324900: nscd: umount /var fails (unclean shutdowns)
At Thu, 25 Aug 2005 12:56:04 +0200, Zlatko Calusic wrote: rc1119 root mem REG8,9 217016 228931 /var/db/nscd/passwd This is another file which is not /var/run/nscd/dbXX. This is the process list at the same time (kernel daemons and ps itself excluded): UIDPID PPID C STIME TTY TIME CMD root 1 0 0 12:42 ?00:00:00 init [6] root 1119 1 0 12:47 ?00:00:00 /bin/sh /etc/init.d/rc 6 root 1421 1119 0 12:47 ?00:00:00 /bin/sh /etc/rc6.d/S40umountfs stop What next? Before shutting down, lsof | grep nscd probably shows /var/db/nscd or /var/run/nscd files. Could you try it? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324900: nscd: umount /var fails (unclean shutdowns)
At Thu, 25 Aug 2005 17:57:00 -0400, Daniel Jacobowitz wrote: On Thu, Aug 25, 2005 at 05:53:05PM +0200, Zlatko Calusic wrote: GOTO Masanori [EMAIL PROTECTED] writes: At Thu, 25 Aug 2005 12:56:04 +0200, Zlatko Calusic wrote: rc1119 root mem REG8,9 217016 228931 /var/db/nscd/passwd Note, this is a long-running bash. Not many people use file-rc (that's what this is, right?) It explains why most people don't see this issue. Why does file-rc cause problems? Does glibc open the nscd cache files directly rather than communicating with it via a socket? Or does it communicate via shared memory? Quick look at the source, mmap is used to share database file with mmap MAP_SHARED, so the main communication should be done via a socket. rc827 root mem REG8,9 217016 228931 /var/db/nscd/passwd [Is /var/db even FHS?] FHS states as follows. 5.5.2 /var/lib/misc : Miscellaneous variable data This directory contains variable data not placed in a subdirectory in /var/lib. An attempt should be made to use relatively unique names in this directory to avoid namespace conflicts. Note that this hierarchy should contain files stored in /var/db in current BSD releases. These include locate.database and mountdtab, and the kernel symbol database(s). LDAP or DB data sometimes puts their db files on /var/lib/misc (I think misc is vague term, though). Actually debian/patches/fhs-linux-paths.dpatch contains the following changes: --- glibc-2.1.1/sysdeps/unix/sysv/linux/paths.h~Thu May 27 13:16:33 1999 +++ glibc-2.1.1/sysdeps/unix/sysv/linux/paths.h Thu May 27 13:17:55 1999 @@ -71,7 +71,7 @@ /* Provide trailing slash, since mostly used for building pathnames. */ #define_PATH_DEV /dev/ #define_PATH_TMP /tmp/ -#define_PATH_VARDB /var/db/ +#define_PATH_VARDB /var/lib/misc/ Another chioce is to use /var/cache - it's for application specific caching data. But currently I use /var/db instead of /var/lib/misc - I have wondered this change is widely accepted. I would like to hear from all you guys about this placement. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301438: Native ppc64 support - new patch for glibc 2.3.5-4
At Wed, 24 Aug 2005 15:44:05 +0200, Andreas Jochens wrote: * debian/control.in/powerpc: New libc6-(dev-)powerpc packages for ppc64. This name powerpc is confusable with the current powerpc - could I rename it from powerpc to ppc32? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301438: Native ppc64 support - new patch for glibc 2.3.5-4
At Fri, 26 Aug 2005 12:13:36 +0900, GOTO Masanori wrote: * debian/control.in/powerpc: New libc6-(dev-)powerpc packages for ppc64. This name powerpc is confusable with the current powerpc - could I rename it from powerpc to ppc32? Note that ppc32 things is just for debian/control.in/ppc32. libc6-powerpc is OK for me. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324795: libc6 in stable broken on arm4vl
At Tue, 23 Aug 2005 22:38:15 -0400, Rob Warren wrote: Version: 2.3.2.ds1-22 Keeping up with Stable the new release for libc6 is broken. dpkg dies on the upgrade. Did you try to upgrade from woody to sarge? Or from sarge to the current sid? Please imagine 2.3.2.ds1-22 is broken - many arm users cannot use their machine. Linux jill 2.2.19 #1 Tue Dec 25 13:58:22 GMT 2001 armv4l unknown This kernel is not the standard debian supported kernel - it seems a bit old. Can you try newer kernel with glibc 2.3.2.ds1-22? llseek bad argument is the most common error message. Could you show us some examples of your messages? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with cannot stat `(0xffffe000)': No such file or directory]
At Wed, 24 Aug 2005 12:46:34 +0900, Horms wrote: On Tue, Aug 23, 2005 at 08:17:58AM -0400, Theodore Ts'o wrote: On Tue, Aug 23, 2005 at 07:49:23PM +0900, Simon Horman [Horms] wrote: long time no see. It seems that the problem is indeed fixed if you get the sarge (or later) versions of e2fsprogs and glibc. However, some people don't have that, and its causing some breakage for those people. Would it be possible for you to add the conflicts that Ted suggested to the next glibc release. This would seem like a nice way to make the problem go away for everyone. Hmm, OK. This is how I understand the problem. If you are using the sarge versions of e2fsprogs (1.37-2sarge1) and libc6 (2.3.2), you're fine. If you are using the latest unstable versions of e2fsprogs (1.38-1 or the just uploaded 1.38-2) and glibc (2.3.5) you're also fine. The problem comes if you are using the sarge (1.37-2sarge1) version of e2fsprogs (or any version of e2fsprogs before 1.37-5) and an unstable version of glibc which is newer than 2.3.4, due to the change in what ldd outputs (the linux-gate.so entry). Since we can't retroactively fix e2fsprogs (although I suppose I am trying to get an updated 1.37-2sarge2 into the next stable update, I could try to convince the release managers to let me get an additional conflicts added, or to get the linux-gate.so filtering added to -2sarge2), the only way to fix this is to add the conflicts line to libc6. Thanks to Simon and Ted with the detailed explanation, I understand what the problem is. On the other hand, do we have to support these kinds of wierd cross-release dependencies? I have in the past updated to an unstable version of libc on a stable system, for various sordid reasons, but I always considered it something hazardous that might break things. I don't know that supporting a mix-and-match between stable and unstable is something we have to do, and if it means adding extra hair into libc6's dependencies that in practice may not get removed for a long time, is it worth doing? I'm not sure that kind of mixing and matching is really supported, in the sense that if a new version exists, the recommended solution is always to upgrade. I think your idea is worthwile, as people do mix and match, but I'll also understand if Goto-san doesn't wan the extra cruft in control - it will become irrelevant over time. I'm going to reassign this bug to libc6, Goto-san can close it from there in whatever way he sees fit. Thinking about this issue, I agree with Ted's opinion - we don't probably need to consider about cross-release. However, actually this problem was caused by glibc, and such change made old e2fsprogs unusable. It's a bit hard to decide, but in this case I choose to add Conflicts: e2fsprogs (= 1.37-2sarge1). Ted, is this version = 1.37-2sarge1 correct value? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324795: libc6 in stable broken on arm4vl
severity 324795 normal tags 324795 moreinfo thanks At Wed, 24 Aug 2005 09:11:30 -0400, Rob Warren wrote: I was upgrading from woody to sarge when apt-get choked on upgrading libc6 from 2.2.5-11.8 to 2.3.2.ds1-22 with a message along the lines of 'can't seek in file xx'. dmesg would report 'Bad number of arguments for llseek()' (paraphrasing) every so often. It was impossible to reserve the package install. Weird. Grep told me that dmesg (kernel 2.2.19) and glibc should not warn such kind of messages. Linux jill 2.2.19 #1 Tue Dec 25 13:58:22 GMT 2001 armv4l unknown This kernel is not the standard debian supported kernel - it seems a bit old. Can you try newer kernel with glibc 2.3.2.ds1-22? 2.2.19 is the last kernel that I've run without problems; the machine had an uptime of 221 days when I tried to upgrade. Uptime is not important information for this kind of userland issue. Getting someone to access the machine is non-trivial and is going to require shipping the computer. I won't be able to try anything for a few weeks until I get access to the machine. If so, we can't track down any more too - please send us the detailed information if you have an access for that machine. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with cannot stat `(0xffffe000)': No such file or directory]
At Wed, 24 Aug 2005 11:30:30 -0400, Theodore Ts'o wrote: Actually, to be completely correct, the right value should be Conflicts: e2fsprogs ( 1.35-7), as linux-gate.so started being filtered in e2fsprogs 1.35-7. OK, I changed from (= 1.37-2sarge1) to ( 1.35-7). Thanks! Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324455: gmp: FTBFS on alpha
At Tue, 23 Aug 2005 01:27:43 -0700, Steve Langasek wrote: - cmpult Y, X, RV + cmpule Y, X, RV excb mt_fpcr $f3 ldt $f0, 0(sp) but I don't have time for testing. Thanks, after looking at the diff between divq.S and divqu.S and doing a little googling (aka, the Babelfish methodology for learning assembly), I came to the same conclusion, and my test build of glibc just finished up -- this one-liner does indeed fix the problem. I put this kind of patch with the additional fix for svn, it'll be fixed in 2.3.5-5. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324900: nscd: umount /var fails (unclean shutdowns)
At Wed, 24 Aug 2005 20:14:43 +0200, Zlatko Calusic wrote: With the latest changes in nscd functionality, namely using persistent database in /var/db/nscd, /var partition can't be cleanly umounted. I tried to avoid the problem by disabling persistent database, but even that didn't help because nscd keeps open descriptor to a deleted file in /var/run, and somehow /etc/init.d/rc inherits it. This is the relevant part of the lsof output fired just before the umount line in /etc/init.d/umountfs: COMMANDPID USER FD TYPE DEVICESIZE NODE NAME rc2470 root DEL REG3,9 1093449 /var/run/nscd/dbUUHtCX Why didn't your nscd shutdown before /etc/init.d/umountfs was invoked? Under my standard sid environment, such problem does not occur because nscd is stopped before umount is executed. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324450: glibc: ftbfs [sparc] current build architecture sparc does not appear in package's list (s390)
At Sun, 21 Aug 2005 23:55:42 -0700, Blars Blarson wrote: glbic failed to build on a sparc buildd. It is currently building on my sparc pbuilder, I'll report when the build finishes. I changed it, -5 should fix this problem. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324526: Compiling and linking Verilog simulations with VCS 7.2 does not work after libc6 upgrade
At Mon, 22 Aug 2005 11:52:08 -0400, Ravi Nanavati wrote: After upgrading libc6 (from 2.3.2.ds1-22) to 2.3.5-3 I am no longer able to compile and link Verilog simulations with Synopsys VCS. The problem appears to be missing symbols in libc6. The error messages I get are as follows: gcc -o ../simv 5NrI_d.o 5NrIB_d.o KDF7_1_d.o SIM_l.o /tools/vcs7.2.new/vcs7.2/gui/virsim/linux/vcdplus/vcs7_2/libvirsim.a /tools/vcs7.2.new/vcs7.2/linux/lib/libvcsnew.so -ldl -lc -lm -ldl /tools/vcs7.2.new/vcs7.2/gui/virsim/linux/vcdplus/vcs7_2/libvirsim.a(vcspli.o): In function `vs_clStrCmpCI(char *, char *)': : undefined reference to `__ctype_toupper' I guess your application is not part of Debian, and it was static linked. During glibc 2.3.x development, some symbols like __ctype_b is changed to hidden attribute - so old static linked libraries built with glibc 2.2.x does not work on 2.3.x. In sarge, we introduce workaround code, so your application worked OK. But most other distros already dropped such local modification nowadays. For that reason, we decided to drop supporting such old static linked applications/libraries from etch. If you want to enable it again, please recompile debian glibc package and install it locally, with removing the first # character at the following line in debian/patches/00list: #glibc23-ctype-compat # g: untilsarge Note that I don't test this patch is still applicable. I'll close this report by writing about this transition to the appropriate place (ex: README.Debian or FAQ). Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324549: glibc: FTBFS on hurd-i386: gcc-4.0 build failures [patch]
At Mon, 22 Aug 2005 20:54:07 +0200, Michael Banck wrote: attached is a dpatch which fixes gcc-4.0 build issues on hurd-i386. The parts by Roland McGrath have been taken from CVS, the part by Alfred M. Szmidt has not been applied yet and was thus taken from http://sources.redhat.com/ml/libc-alpha/2005-08/msg00018.html Thanks! I include your patch for the next 2.3.5-5. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with cannot stat `(0xffffe000)': No such file or directory]
At Tue, 23 Aug 2005 12:54:13 +0900, Horms wrote: So the dependency isn't on e2fsprogs, per-se, but rather that e2fsprogs's initrd script has to filter out the linux-gate.so.1 entry, but if you have a newer than a certain glibc, it is incompatible with e2fsprogs 1.35-2, and you need to upgrade to a newer version of e2fsprogs. I originally added the linux-gate.so filtration in response to a bug filed from the amd64 port, but apparently it is now required for all platforms given the newer glibc in unstable. The only way to fix this with dependencies is to ask glibc to add a conflicts with (e2fsprogs 1.35-7). Hi Ted, Thanks for that, certainly saved me a lot of bother not having to track it down. I've CCed the glibc maintainers for their consideration. I don't know what the actual problem is, but I fixed this kind of ldd filtering problem for mkinitrd during the final stage of sarge development. Does this help you? * GOTO Masanori - Make mkinitrd work with new ldd format which change is introduced in glibc 2.3.4. (Closes: #301455, #303281) This change also fixes amd64 mkinitrd breakage. (Closes: #279382, #292080, #295412, #295422, #297724) Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321724: try upgrading your kernel?
At Thu, 18 Aug 2005 13:33:51 -0700, Joshua Kwan wrote: (Debian glibc maintainers: this message is re: bug#321724. Does there need to be a kernel version = 2.4.27 restriction on i386 when upgrading to libc6 2.3.5? Thank you.) I'll put the patch to -4 that mitigates this problem. Of course, upgrading kernel is always good idea. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310477: localedef: typo in --help
At Wed, 17 Aug 2005 12:41:39 +0100, Adam D. Barratt wrote: At Mon, 23 May 2005 23:28:01 +0300, Lars Wirzenius wrote: The English output of localedef --help contains this: --posixBe strictly POSIX conform The last word should surely be conforming. You'll find POSIX conform has been used like a noun via google. That Google indexes pages containing broken English does not make that English correct. :-) posix-conformance 45,900 posix-conformant 7,260 posix-conform4,060 The current wording certainly does not make sense in English. Either the suggested wording or, for instance, Conform strictly to POSIX does. I'm not native speaker, but I would like to hear the opinion who knowns POSIX very well. BTW, Lars, why don't you send patches to upstream? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317082: Not just a dpkg bug
At Wed, 17 Aug 2005 22:05:42 +0200, Andreas Jochens wrote: I guess you will generally have many more issues than this one when you try to build 64-bit packages on a 32-bit buildd (e.g. compiling and running 64-bit programs from configure scripts, running 'make check' or 'make test' targets, using binaries which have been built by the package itself etc.) In the end it will be much easier to require a 64-bit machine to be used to build 32/64-bit biarch packages instead of trying to circumvent all these issues. Yes, that's one solution. However, instead, I would like to propose supporting 32bit and 64bit binaries as separated architectures. For example, think about ppc32 and ppc64. My proposal is to have both Debian/dists/sid/main/binary-powerpc and Debian/dists/sid/main/binary-ppc64. It's similar to the different architecture between i386 and amd64 - but ppc32 and ppc64 are not distinguished so much. If a package has (ex:) Features: biarch in debian/control (like Tollef's proposal), ppc64 buildd picks up to build this package. If it does not biarch capable package, it should not be built. It reduces much disk spaces on mirror servers, and the 90% of non-biarch-needed (binaries and libraries) packages do not need to consider about biarch problems. To install both 32/64 bit packages, we need to consider about the file duplication in /usr/share and /usr/bin - but fortunatelly the proposal of Scott's dpkg modification, FILTERS and CLASSES, probably fix this kind of problems. It's very simple way and we don't modify a lot of packages. If you guys like this idea, I'll write the proposal to debian-devel lists. Or is this idea already proposed? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317082: Not just a dpkg bug
At Thu, 18 Aug 2005 10:24:14 +0200, Andreas Jochens wrote: There is already an inofficial buildd for the ppc64 architecture running for 'unstable'. The respective ppc64 package archive is located at deb http://debian-ppc64.alioth.debian.org/gcc4 unstable main and almost 95% of all source packages from 'unstable' have already been compiled for the ppc64 architecture. Indeed - if we put this thought forward, we'll reach to the whole native ppc64 support of all packages. BTW I think supporting all binary packages as 64bit native does not have much sense - most packages do not use such large memory space, and even they run slower than 32bit binaries. This is because I would like to introduce (ex:) Features flags. A small number of packages still need some minor patches to make this work, notably 'glibc' (see #301438 - the patch in that bug is outdated, but I could supply an updated patch for this). I didn't put your patch because the native ppc64 support was not adopted, from the discussion that was done in debian-powerpc lists. If your patch does not have any impact, please send your latest version to me. With this setup, the ppc64/powerpc situation would become very similar to the amd64/i386 situation and the same solution for multiarch/biarch support could be used for both cases. Yes. The current partial support for biarch imposes various modifications on package maintainers. Such method will not be spereaded - debian is the large voluntary organization, reducing cost of package maintainer's load is the primal principle. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321718: Upgrade caused many libs to complain about executable stack
At Mon, 15 Aug 2005 10:12:31 -0400,
Daniel Jacobowitz wrote:
I don't know what the exact problem is - Does this problem occur with
2.4 kernel? Can all furious PaX reports be fixed using 2.6 kernel?
This is separate from the PaX problems - it's stock 2.4. I don't know
why it happens, but someone would need to set up a 2.4 system to debug
it on.
Thanks, I confirmed the problem.
When I booted up with 2.4.18-bf2.4, then I invoked ssh,
libcrypto.so.0.9.7 got Error 14. But kernel 2.4.26-1-686 does not
break. As you already stated, this is because 2.4.18-bf2.4 returns
EFAULT instead of ENOMEM when the second of problematic mprotect() is
called during resolving libcrypto.so [1]. Then I looked at
/proc/pid/maps. It says even on 2.4.18-bf2.4 [2]:
b000-c000 rwxp 00:00 0
So the problem is the return value of mprotect is changed during
2.4.18 and 2.4.26. I found some mail of this modifications:
http://www.linux-mips.org/archives/linux-mips/2002-06/msg00215.html
--- mm/mprotect.c 4 Mar 2002 11:13:35 - 1.1.1.1
+++ mm/mprotect.c 25 Jun 2002 07:00:55 -
@@ -284,7 +284,7 @@
down_write(current-mm-mmap_sem);
vma = find_vma_prev(current-mm, start, prev);
- error = -EFAULT;
+ error = -ENOMEM;
if (!vma || vma-vm_start start)
goto out;
@@ -317,7 +317,7 @@
nstart = tmp;
vma = next;
if (!vma || vma-vm_start != nstart) {
- error = -EFAULT;
+ error = -ENOMEM;
goto out;
}
}
I found 2.6 kernel changelog said (Hi Adrian!):
[EMAIL PROTECTED]
[PATCH] mprotect return value fix
From: Marc-Christian Petersen [EMAIL PROTECTED]
2.4 patch from Adrian Bunk.
ERRORS
The mprotect() function shall fail if:
...
[ENOMEM]
Addresses in the range [addr,addr+len) are invalid for the
address space of a process, or specify one or more pages which
are
not mapped.
This modification was done because mprotect returned EFAULT instead of
ENOMEM, that was simply POSIX violation. The actual problem is linux
kernel 2.4. But in order to work glibc 2.3.5 on etch, we need to fix
adhoc patch to change dl-execstack.c. I don't know it's acceptable
for upstream, but it's worth fixing. If it'll be rejected, this patch
should be marked as until-etch if etch does not support any 2.4
kernel hopefully. Now the patch that I have not tested yet. Is this
solution desired for the next 2.3.5-4?
--- sysdeps/unix/sysv/linux/dl-execstack.c.gotom2005-08-18
20:55:21.448088096 +0900
+++ sysdeps/unix/sysv/linux/dl-execstack.c 2005-08-18
20:57:02.500725760 +0900
@@ -84,7 +84,7 @@
page -= size;
else
{
- if (errno != ENOMEM) /* Unexpected failure mode. */
+ if (errno != (ENOMEM | EFAULT)) /* Unexpected failure
mode. */
return errno;
if (size == GLRO(dl_pagesize))
@@ -107,7 +107,7 @@
page += size;
else
{
- if (errno != ENOMEM) /* Unexpected failure mode. */
+ if (errno != (ENOMEM | EFAULT)) /* Unexpected failure
mode. */
return errno;
if (size == GLRO(dl_pagesize))
BTW, I found the similar problem (which I checked for 2.4.19):
http://lists.debian.org/debian-glibc/2003/02/msg00353.html
Regards,
-- gotom
[1]
2.4.18:
mprotect(0xb000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) =
-1 EINVAL (Invalid argument)
mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EFAULT (Bad
address)
2.4.26:
mprotect(0xb000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) =
-1 EINVAL (Invalid argument)
mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM
(Cannot allocate memory)
mprotect(0xbfffc000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM
(Cannot allocate memory)
mprotect(0xbfffe000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM
(Cannot allocate memory)
mprotect(0xb000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0xbfffe000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM
(Cannot allocate memory)
2.6.9:
mprotect(0xb000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0
[2]
2.6 kernel: b000-c000 rwxp b000 00:00 0
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321718: Upgrade caused many libs to complain about executable stack
if (errno != ENOMEM errno != EFAULT) Thanks, this is one of the best bug that I have produced, I go to sleep now... Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323798: [sparc] corrupted double-linked list
At Thu, 18 Aug 2005 15:56:19 +0200, Andreas Barth wrote: during building openmotif on sparc, this error happened: gcc -g -O2 -Wall -Wno-unused -Wno-comment -o .libs/periodic periodic.o ../../../lib/Xm/.libs/libXm.so -L/usr/X11R6/lib ../../../lib/Mrm/.libs/libMrm.so /build/buildd/openmotif-2.2.3/work/openMotif-2.2.3/lib/Xm/.libs/libXm.so -lXmu -lXext -lXp -lXt -lSM -lICE -lX11 creating periodic ../../../clients/uil/uil -o periodic.uid periodic.uil -I./../../../clients/uil -I../../../clients/uil Severe: internal error - submit defect report *** glibc detected *** corrupted double-linked list: 0x00077450 *** please see http://experimental.ftbfs.de/build.php?arch=pkg=openmotif for the full build log. There's no sparc build log... (From what I read, I guess this is an glibc defect - if not, please reassign this bug accordingly) The recent glibc started to detect malloc-ed memory corruption anytime. In most case, such defect is caused by application, in this case, uil. Please use valgrind to uil on i386, you probably find the actual problem. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322146: glibc: FTBFS (powerpc): Unmet build dependencies: gcc-3.4 (= 3.4.4-6)
At Sat, 13 Aug 2005 08:25:32 +0200,
Andreas Jochens wrote:
Will the separation character problem (',' vs. '|') in the glibc
Build-Depends also be fixed?
OK, fixed in cvs. Thanks.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321719: libc6: locale -a returns values even if locales package is not installed
At Wed, 17 Aug 2005 08:04:35 +0200, Marc Haber wrote: On Wed, Aug 17, 2005 at 11:47:43AM +0900, GOTO Masanori wrote: Please try: ls -al /usr/lib/locale/locale-archive . If it's existed, then try to remove this file and invoke locale -a again. I guess it's simply locales.prerm bug. The file exists, and removing it makes locale -a return C and POSIX. Thanks. I fixed it, it'll be reflected in the next 2.3.5-4. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317082: Not just a dpkg bug
At Wed, 17 Aug 2005 17:00:23 +0100, Scott James Remnant wrote: I don't think this is just a dpkg-dev bug, these bi-arch systems need to provide ldd or an equivalent that can read either form of shared library that it would support. objdump isn't a solution either, while it sometimes can read the other shared library, it doesn't provide the linker search patch which is of critical importance to get this stuff right. So I'm including libc6-dev (for want of a better package) in this bug, as we first need ldd on these bi-arch systems (or something similar) for dpkg-shlibdeps to use before we can fix that! ldd is very hard to handle 64bit binaries on 32bit systems without breaking glibc, kernel and various technical beautiful concepts. Please look at /usr/bin/ldd. It just passes LD_* variable to dynamic linker. When dynamic linker is invoked from kernel elf module, it parses LD_* environment variable and put the library path message to stdout. So ldd is just wrapper to take notice to dynamic linker. The actual dynamic linker path is specified in each binaries. For example, do strings /bin/ls |grep ld on both i386 and amd64. You'll find 64bit binaries designate 64bit dynamic loader that is placed in /lib64. And, dynamic loader itself is built with 64bit code - so we cannot invoke even dynamic loader. OK, now back to the discussion. The above means we cannot use ldd to search pathes. OTOH, Ryan suggested me to look at dpkg-shlibdeps in dpkg-cross package as I described. It's something adhoc fix, but I think we have no other way to support biarch nicely. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323352: nscd segfaults when persistent database files are not available (seemingly)
At Tue, 16 Aug 2005 03:21:35 -0500, Mark Nipper wrote: I should not this doesn't happen on my testing machines with libc6 2.3.2.ds1-22. I diff'ed the standard nscd.conf between the two versions and aside from additional comment junk, the apparent problems seem to be these: --- persistent passwd yes shared passwd yes 41a54,55 persistent group yes shared group yes 47a62,63 persistent hosts yes shared hosts yes So persistent database files were not enabled in 2.3.2.ds1-22 but are in 2.3.5-3, yet the installation scripts do not bother creating /var/db/nscd when it doesn't exist. Seemingly nscd does not fail gracefully upon trying to delete a cache entry in a file which does not exist in the first place. Yes, I added /var/db/nscd to nscd installation dir, thanks. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321719: libc6: locale -a returns values even if locales package is not installed
At Sun, 07 Aug 2005 09:43:06 +0200, Marc Haber wrote: $ locale -a locale: Cannot set LC_CTYPE to default locale: No such file or directory C POSIX de_DE de_DE.iso88591 [EMAIL PROTECTED] de_DE.utf8 [EMAIL PROTECTED] deutsch german $ dpkg --list locales Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- pn localesnone (no description available) [57/[EMAIL PROTECTED] sid-clamav-getfiles]:~$ Please try: ls -al /usr/lib/locale/locale-archive . If it's existed, then try to remove this file and invoke locale -a again. I guess it's simply locales.prerm bug. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310477: localedef: typo in --help
At Mon, 23 May 2005 23:28:01 +0300, Lars Wirzenius wrote: The English output of localedef --help contains this: --posixBe strictly POSIX conform The last word should surely be conforming. You'll find POSIX conform has been used like a noun via google. I think this trivial change is not needed. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316914: dbus-1 does not start because of segmentation fault
Hi, These bugs are marked as important when glibc 2.3.2.ds1 is used in sarge. Nowadays we have new glibc 2.3.5-3 in unstable. Could you test dbus-1 with new glibc? I guess this problem is already fixed. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322506: libc6-udeb has an unnecessary dependency on libnss-files-udeb
At Sun, 14 Aug 2005 15:05:38 -0400, Joey Hess wrote: I changed now. BTW, is it ok to leave dependency Depends: libnss-dns-udeb? Good point, we do currently include libc on at least one image (boot floppy) without libnss-dns, so it's not really a dependency and the dependency should be removed. OK, I'll remove libnss-dns dependency, too. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317082: Bug#322953: glibc: FTBFS (powerpc): ppc64 build pass fails because of missing Build-Depends on 'libc6-dev-ppc64 [powerpc]' and 'lib64gcc1 [powerpc]'
merge 322953 317082 severity 317082 serious thanks At Sat, 13 Aug 2005 20:28:23 +0200, Andreas Jochens wrote: When building 'glibc' on in a clean chroot on powerpc/unstable, I get the following error: touch /glibc-2.3.5/stamp-dir/install_libc Installing ppc64 rm -rf /glibc-2.3.5/debian/tmp-ppc64 /usr/bin/make -C build-tree/powerpc-ppc64 -j 1 \ install_root=/glibc-2.3.5/debian/tmp-ppc64 install make[1]: Entering directory `/glibc-2.3.5/build-tree/powerpc-ppc64' make[1]: *** No rule to make target `install'. Stop. make[1]: Leaving directory `/glibc-2.3.5/build-tree/powerpc-ppc64' make: *** [/glibc-2.3.5/stamp-dir/install_ppc64] Error 2 A look in 'build-tree/powerpc-ppc64/config.log' shows the following 'configure' script failure: configure:27: checking for forced unwind support configure:51: gcc-3.4 -m64 -o conftest -g -O2 -isystem /glibc-2.3.5/debian/include conftest.c 5 /usr/bin/ld: cannot find -lgcc_s_64 collect2: ld returned 1 exit status This can be fixed by adding a Build-Depends on 'libc6-dev-ppc64 [powerpc]' and 'lib64gcc1 [powerpc]' to debian/control. Perhaps 'libc6-dev-ppc64' should Depend on 'lib64gcc1' because it will not really be usable without it. May be this kind of self dependency can be avoided somehow, but I could not find a different solution for this yet. Please read my mail: bugs.debian.org/317082 BTW, it causes FTBFS on various 64 bit architectures: ppc64, sparc64, s390x. Scott, please don't drop this bug's severity. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321718: Upgrade caused many libs to complain about executable stack
At Mon, 8 Aug 2005 10:09:38 -0400, Daniel Jacobowitz wrote: 08:47 waldi mprotect(0xb000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument) 08:47 waldi mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EFAULT (Bad address) 08:55 waldi PROT_GROWSDOWN seems to be new in 2.4.21 and 2.5 I have no idea why waldi thinks PROT_GROWSDOWN is the problem. Rather, the EFAULT is the problem. At a guess, this is the case that we expect ENOMEM for in dl-execstack.c, but 2.4.18 is returning EFAULT instead for the same case. I don't know what the exact problem is - Does this problem occur with 2.4 kernel? Can all furious PaX reports be fixed using 2.6 kernel? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322768: libc6: sshd after upgrade not working
At Fri, 12 Aug 2005 20:50:25 +0200, Adrian Bunk wrote: After upgrading from the sarge libc6, sshd on my computer no longer accepted connections. Restarting sshd fixed the problem. It seems the restart services question in the postinst should be asked for upgrades from 2.3.5 . I've set the severity of this bug based on the problems a non-working sshd can cause for non-local users (and the fix for this issue is trivial). Do you have your sshd error log? If so, could you send us to prove definitely? I intend to enable restarting sevice question again in 2.3.5-4. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322146: glibc: FTBFS (powerpc): Unmet build dependencies: gcc-3.4 (= 3.4.4-6)
reassign 322146 gcc-3.4 close 322146 3.4.4-7 thanks At Tue, 09 Aug 2005 12:17:14 +0200, Andreas Jochens wrote: When trying to build 'glibc' in a clean chroot on powerpc/unstable, I get the following error: # apt-get build-dep glibc # cd glibc-2.3.5; dpkg-buildpackage -b dpkg-buildpackage: source package is glibc dpkg-buildpackage: source version is 2.3.5-3 dpkg-buildpackage: source changed by GOTO Masanori [EMAIL PROTECTED] dpkg-buildpackage: host architecture powerpc dpkg-checkbuilddeps: Unmet build dependencies: gcc-3.4 (= 3.4.4-6) dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: (Use -d flag to override.) This can be fixed by replacing 'gcc-4.0 [!powerpc !m68k] | gcc-3.4 (= 3.4.4-6) [powerpc] | gcc-3.4 [m68k]' with 'gcc-4.0 [!powerpc !m68k], gcc-3.4 [powerpc m68k]' in the Build-Depends. Note that the separation character should be ',' instead of '|' to make sure that the second item gets processed by 'apt-get build-dep' and that the gcc-3.4 version requirement (= 3.4.4-6) cannot be fulfilled because unstable still has 3.4.4-5. biarch ppc64 needs new gcc-3.4. Matthias uploaded gcc-3.4 3.4.4-7, this bug is already fixed. I think it's OK to close now. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#246689: Surely this is fixed now?
At Thu, 11 Aug 2005 21:36:37 -0400, Daniel Jacobowitz wrote: On Thu, Aug 11, 2005 at 12:44:00PM +0200, Christoph Hellwig wrote: On Thu, Aug 11, 2005 at 04:14:55AM -0400, Nathanael Nerode wrote: PPC libc6 should be built with TLS and NPTL We have new enough GCC now, and new glibc. Is this fixed in the current glibc version in unstable? glibc in sid doesn't seem to provide NTPL yet on ppc. That's correct. It's now fixable, but not yet fixed. OK... Ppc64 biarch is done, the next step in 2.3.5-x is, supporting ppc/nptl and built with gcc-4.0. I'll try to add the former in 2.3.5-4 (note that 2.3.5-3 is getting two considerable problems, it's not reached testing yet, it'll stop a lot of packages). Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321712: No errors
At Wed, 10 Aug 2005 17:24:26 -0300 (BRT), Nelson A. de Oliveira wrote: 3 days after restaring Apache and no more errors. Maybe close the bug? We'll fix glibc to introduce restarting apache question again. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322506: libc6-udeb has an unnecessary dependency on libnss-files-udeb
At Wed, 10 Aug 2005 23:51:18 -0400, Joey Hess wrote: libc6-udeb depends on libnss-files-udeb, which is unnecessary since most d-i images don't need that udeb at all, and the udebs that do need it seems to depend on it (openssh-client-udeb, openssh-server-udeb). I changed now. BTW, is it ok to leave dependency Depends: libnss-dns-udeb? d-i has ignored unfilled dependencies when building images, but we plan to change that, which would pull this into all our initrds. So please remove that dependency. Yes, that's nice plan. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321912: Paje cannot start without resolving the symbol
Package: paje.app Version: 1.3.2-4 Severity: important When I invoked to start Paje, I got an error. It seems this application is not usable entirely. Warning - GNUSTEP_SYSTEM_ROOT is not set - using /usr/lib/GNUstep/System 2005-08-08 15:43:36.000 Paje[4457] NOTE: Only one display per host fully supported. 2005-08-08 15:43:36.000 Paje[4457] XShm not supported. 2005-08-08 15:43:36.000 Paje[4457] Falling back to normal XImage:s (will be slower). /usr/lib/GNUstep/System/Applications/Paje.app/Paje: relocation error: /usr/lib/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./libgnustep-back: undefined symbol: FTC_Manager_Lookup_Size Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321712: libc6: relocation error: /lib/tls/i686/cmov/libnss_dns.so.2: symbol __res_maybe_init, version GLIBC_PRIVATE
At Sun, 7 Aug 2005 10:43:43 -0400, Daniel Jacobowitz wrote: Are libc6-i686 and libc6 the same version? Have they been upgraded since you last restarted apache? Note that during glibc 2.3.5-2, I add this check code. If version number between libc6-i686 and libc6 are not matched, the post/pre scripts automatically create /etc/ld.so.nohwcap. You can see this inconsistency at /etc/ld.so.hwcappkgs. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321712: libc6: relocation error: /lib/tls/i686/cmov/libnss_dns.so.2: symbol __res_maybe_init, version GLIBC_PRIVATE
At Mon, 8 Aug 2005 09:47:48 -0400, Daniel Jacobowitz wrote: On Mon, Aug 08, 2005 at 10:46:40PM +0900, GOTO Masanori wrote: At Sun, 7 Aug 2005 10:43:43 -0400, Daniel Jacobowitz wrote: Are libc6-i686 and libc6 the same version? Have they been upgraded since you last restarted apache? Note that during glibc 2.3.5-2, I add this check code. If version number between libc6-i686 and libc6 are not matched, the post/pre scripts automatically create /etc/ld.so.nohwcap. You can see this inconsistency at /etc/ld.so.hwcappkgs. I think that's not the problem here - I misleaded you - I just meant we don't need to consider the version mismatch between libc6-i686 and libc6 from glibc 2.3.5-2. we need to restart nss-using applications between these two versions. Does this problem already identify the culprit (thus nss), and is restaring services all ok? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321912: Paje cannot start without resolving the symbol
At Mon, 8 Aug 2005 16:54:49 +0200, Vincent Danjean wrote: On Mon, Aug 08, 2005 at 03:45:14PM +0900, GOTO Masanori wrote: Package: paje.app Version: 1.3.2-4 Severity: important When I invoked to start Paje, I got an error. It seems this application is not usable entirely. Warning - GNUSTEP_SYSTEM_ROOT is not set - using /usr/lib/GNUstep/System 2005-08-08 15:43:36.000 Paje[4457] NOTE: Only one display per host fully supported. 2005-08-08 15:43:36.000 Paje[4457] XShm not supported. 2005-08-08 15:43:36.000 Paje[4457] Falling back to normal XImage:s (will be slower). /usr/lib/GNUstep/System/Applications/Paje.app/Paje: relocation error: /usr/lib/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./libgnustep-back: undefined symbol: FTC_Manager_Lookup_Size I'm aware of this problem. This is not a Paje bug. It is a libfreetype6 bug that affect most of GNUStep applications (until the libfreetype6 maintainer does a new upload that corrects the binary interface of its library, or until the GNUStep maintainers recompile their packages against the current libfreetype6 library). Ah, I'm sorry, I don't usually use GNUStep, so I didn't notice the actual problem.. For me, I downgraded the libfreetype6 on my system (thanks to snapshot.debian.net) so that Paje and other GNUStep application work again. OK, I'll try to use old version. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#214387: Removing -lpthread from link line avoids the problem
Hi, At Fri, 31 Oct 2003 15:11:47 +0100, Raphael Manfredi wrote: I've noticed that the problem disappears (did not manifest itself in 6 hours) if I remove the unneeded -lpthread in the link line. The -lpthread comes via the pkg-config --libs libxml-2.0 call but is otherwise unneeded by gtk-gnutella. This should narrow the scope of your investigation considerably... The difference to use pthread is small - when multiple threads are used, __libc_writev adds cancellation processing. If a thread which sent cancellation signal, writev may be interrupted. BTW, I guess this problem is already fixed in linux kernel 2.6 + glibc 2.3.5. Please check the problem again. If you notice the problem is already fixed, please let us know. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310445: libc6: static binary fails with assertion bad dynamic tag
At Mon, 23 May 2005 18:07:02 +0200, Laurent Bonnaud wrote: I have a static binary that runs well on sarge and sid systems. On this system with libc6 from experimental, it fails: $ ./multivideo.static Gdk-WARNING **: locale not supported by C library multivideo.static: dynamic-link.h:62: elf_get_dynamic_info: Assertion `! bad dynamic tag' failed. Aborted I got: ./multivideo.static Gdk-WARNING **: locale not supported by C library Segmentation fault I don't know what the actual problem is, but it seems (1) locale processing is changed from 2.3.2 to 2.3.5 (2) static binaries are sometimes incompatible with old glibc. Unfortunatelly we have no source for multivideo - it's hard to track down the problem. Do you have any source to reappear? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#207391: glibc: fails to build if /bin/sh != bash
tags 207391 fixed-upstream thanks I fixed this problem during glibc 2.3.90. It'll be fixed automatically in the next glibc major update. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303263: gawk: symbol _dl_catch_error, version GLIBC_PRIVATE not defined...
severity 303263 serious thanks I met this bug during the recent glibc compilation. I bump up the severity of this bug. James, please rebuild and upload it again. If you have no time to do so, I can help you to do NMU. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320515: bug confusion?
At Tue, 2 Aug 2005 10:02:46 -0400, Josh Metzler wrote: As far as I understand, #318979 caused xorg-x11 to FTBFS on sparc because it included asm-sparc/fbio.h which used __user but failed to include linux/compiler.h where __user was defined. This was apparently fixed in linux-kernel-headers_2.6.13+0rc3-1. So, #318979 is no longer a problem. What Adeodato is saying is that xorg-x11 will again FTBFS if it is uploaded before *this* bug (#320515) is fixed. And, because xorg-x11 has never successfully built on sparc, a number of packages that are waiting on it to build (kde having the biggest dependency chain) cannot yet be uploaded for the gcc 4.0 transition. So, you can forget about bug #318979. Yes, I was confused. I understood the explanation from vorlon that (1) the previous version was compiled with old lkh - so the bug #318979 was happenned, (2) but unfortunatelly new lkh has another problem with xorg-x11, so it'll be got FTBFS again. Looking through this bug, the problem was introduced for compat_ioctl - the header used long type accidentally. I'll check it more. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312902: Missing UTF-8 locales
At Tue, 2 Aug 2005 22:09:50 +0200, Denis Barbier wrote: I've checked and all localedata is available in SUPPORTED with the current 2.3.5-3 development in svn - it'll be OK when 2.3.5 is into unstable. According to /usr/share/i18n/locales/[EMAIL PROTECTED] files, Uzbek language can be written with latin or cyrillic scripts. The former is uz_UZ locale, with ISO-8859-1 charset, and the latter is [EMAIL PROTECTED] with UTF-8 charset. But latin script can of course be also used with UTF-8 charset, thus uz_UZ.UTF-8 UTF-8 should be added to SUPPORTED. Thanks for your elaborate review and investigations as usual. I'll reflect your suggestion to cvs-localedata.dpatch. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#214414: acknowledged by developer (Re: Bug#214414: bug report)
At Mon, 01 Aug 2005 15:04:36 +1200, Dru wrote: According to http://sources.redhat.com/bugzilla/show_bug.cgi?id=121 , it was marked as invalid. I think it's OK to close this report. If you have another information, please let us know. Yip its ok appears to have been working fine this year so someone must of fixed it Thanks, now I've gotten the full ack of closing from the submitter :) Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320515: BITS_PER_LONG used unconditionally but defined only if __KERNEL__ is defined
At Mon, 1 Aug 2005 14:24:19 +0200, Adeodato Simó wrote: This bug also affects xorg-x11, which FTBFS with current l-k-h as some input drivers #include linux/joystick.h Hello, Please consider prioritizing this bug, since we can't get a first build of xorg-x11 on SPARC until it gets fixed (previously we were bitten by #318979). I'm bumping the severity to serious with the approval of the Release Team. Before applying a patch, I would like to hear why this bug affects only sparc? Looking at the following build log, I found linux-kernel-headers 2.6.12.0-1 was used. This means the bug #318979 is not related with xorg-x11 FTBFS, I think. If so, bumping up the severity of this bug is clearly wrong. In addition, to fix the problem, please increase xorg-x11's lkh Build-Depends version. http://buildd.debian.org/fetch.php?pkg=xorg-x11ver=6.8.2.dfsg.1-4arch=sparcstamp=1122655926file=logas=raw Regards, -- gotom
Bug#318244: segmentation fault with many files
At Fri, 29 Jul 2005 19:51:34 +0300 (EEST), Tuukka Toivonen wrote: ulimit -a core file size(blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files(-n) 1024 pipe size (512 bytes, -p) 8 stack size(kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes(-u) unlimited virtual memory(kbytes, -v) unlimited Tuukka, is it easy to reappear this problem again? Yes, it is easy to reproduce with the following script: create a new empty directory and run the script in it: I tried and it worked even the number was twice: [EMAIL PROTECTED]:/tmp/318244$ cat Makefile config.h: $(wildcard */) echo hmm [EMAIL PROTECTED]:/tmp/318244$ LANG=C make clean make: *** No rule to make target `clean'. Stop. [EMAIL PROTECTED]:/tmp/318244$ ls | wc 280002 280002 2577799 [EMAIL PROTECTED]:/tmp/318244$ stat -f . File: . ID: 0Namelen: 255 Type: ext2/ext3 Blocks: Total: 2519839Free: 618524 Available: 592924 Size: 4096 Inodes: Total: 1281696Free: 612886 [EMAIL PROTECTED]:/tmp/318244$ uname -r 2.6.10-1-k7 The difference is kernel version and filesystem. Could you track down this problem more? I think strace/ltrace probably help you. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320515: BITS_PER_LONG used unconditionally but defined only if __KERNEL__ is defined
At Mon, 1 Aug 2005 17:38:17 +0200, Adeodato Simó wrote: Before applying a patch, I would like to hear why this bug affects only sparc? No, it's not sparc-specific. What I meant is that, from a release management point of view, it is preventing xorg-x11 from being a candidate for testing, since (for different reasons over time, one of them being the mentioned #318979) there has not been a successful build of the package in SPARC yet. And this is blocking other packages from doing their C++ ABI transition as well. So, the bug is serious because it breaks compilation of other packages, and the release team would wish (I believe) a quick solution for the reason explained in the previous paragraph. Looking at the following build log, I found linux-kernel-headers 2.6.12.0-1 was used. This means the bug #318979 is not related with xorg-x11 FTBFS, I think. If so, bumping up the severity of this bug is clearly wrong. Again, sorry if my words were not clear enough. I was not talking about an already existing FTBFS on sparc, but about a _future_ one, when xorg-x11 would be retried in that arch with l-k-h 2.6.13+0rc3-1 (as you say, last time it was tried with still 2.6.12.0-1). But Eugene Konev has stated that such retry _would_ fail, and I've asked the X.org packagers for confirmation. I still don't understand the actual point of your suggestion. I just want to know why #318979 causes FTBFS of xorg-x11. Even if a bug prevents xorg-x11 from the testing, whether lkh 2.6.13+0rc3-1 cannot compile the future xorg-x11 on sparc or not, we should clear the problem and what the actual bug is. Could you explain me the problem of xorg-x11? Regards, -- gotom
Bug#319422: glibc: typo in po/pt_BR.po
Guilherme, Leslie, I'm Debian Project GNU C Library package developer. Leslie, I got the following report from Guilherme that reported glibc.po in pt_BR translation has a typo: http://bugs.debian.org/319422/ At Sun, 31 Jul 2005 12:36:43 -0300, Guilherme de S. Pastore wrote: As you noticed, the translation hasn't been updated in a very long time, and LDP-BR (the team you're contacting) seems to be pretty inactive. The translator used to work for Conectiva, which became Mandriva with Mandrake, and I guess he is not active anymore. Hmm, I guess LDP-BR rejected my mail because I was not pt_BR translation list members... Each translation is managed under GNU translation team. I can't put your patch to Debian straightforwardly. Rodrigo and translators, could you review this patch? It was submitted to Debian distribution, created by Guilherme. Could you forward this there, then, or give me instructions on how to? Or perhaps ask for revision on [EMAIL PROTECTED] I can't see why it would hurt that much to apply a patch on the Debian version. It's just a gross gender mistake we have releasing with, and I wouldn't want one more version with one of this kind, really. I'm one of GNU translation project maintainer, and Japanese co-TP coordinator. From the view point of the maintainer, GNU translation Project requires the disclaimer - so I don't want to apply Debian specific local patch to each .po, before getting review from official maintainers. I'd be even willing to update and fix all the translations related to the GNU project (from glibc to whatever else is available/necessary), but I don't really know how to do it. If you could point be in the right direction, I'd be really grateful. Thanks for your offer! The first step is to see at GNU translation project: http://www.iro.umontreal.ca/translation/HTML/ I think it's the first step to subscribe pt_BR.po mailing list. Leslie, could you coordinate Guilherme's activities? Thanks in advance, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320244: glibc crashes in execvp()
At Thu, 28 Jul 2005 00:27:11 +0400, Serge Belyshev wrote: This bug was reported to upstream developers, see http://sources.redhat.com/bugzilla/show_bug.cgi?id=1125 and it is already fixed in current CVS HEAD. I have attached backported patch for debian glibc package. Thanks for your checking glibc 2.3.5, I'll put the patch to svn. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311053: libc6: sched_setaffinity broken on ppc
tags 311053 fixed-upstream thanks It should be fixed in 2.3.5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304426: [mips/mipsel] Incomplete clobber spec for syscalls
tags 304426 fixed-upstream thanks At Wed, 13 Apr 2005 03:27:35 +0200, Thiemo Seufer wrote: Glibc for mips/mipsel has currently an incomplete list of clobbered registers for syscalls. This apparently caused no problem so far, at least when compiling with gcc-3.3, but I observed in similiar code breakage when using gcc-3.4. The appended patch adds memory and argument registers to that list and uses for brk the standard inline syscall implementation, which fixes the incomplete clobber list there as well. It should be fixed in 2.3.5. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297010: linux-kernel-header: O_NOATIME needed for lvm
tags 297010 fixed-upstream thanks It should be fixed in 2.3.5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#165921: acknowledged by developer (Re: Bug#165921: libc6: Please use debconf to warn of likely breakage on major upgrade)
tags 165921 woody tags 205039 woody thanks Both two bugs are marked as woody because it's used for woody - sarge transition. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#175163: (no subject)
tags 175163 fixed-upstream thanks It should be fixed in 2.3.5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298488: (no subject)
tags 298488 fixed-upstream thanks It should be fixed in 2.3.5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
