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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Glibc 2.4 development branch for debian-glibc package
As Roland declared glibc 2.4 release plan in the list, I create glibc 2.4 branch for developing debian-glibc package based on glibc-2.4. You can pull 2.4 branch from: svn co svn+ssh://svn.debian.org/svn/pkg-glibc/glibc-package/branches/glibc-2.4 It's based on the latest svn trunk revision 1255. This branch may be hard work because the official glibc does not support linuxthreads any more. We need to confirm they can be still ok with kernel 2.4 series. So our work cannot be finished before Roland release 2.4. I think the current glibc 2.3.6 leaded by Aurelien will be in unstable, and glibc 2.4 branch will be entered after a lot of tests in experimental, like we experienced in glibc (ex:) 2.2->2.3 or nptl transition. Aurelien already worked a lot (and thanks to Clint, Denis, too!), and he said he had a lot of TODOs. He told me that he would concentrate for 2.3.6 development for a while. 2.4 branch will synchronize with 2.3.6 (and 2.3.7?) trunk periodically. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: compiling libc with --disable-hidden-plt
At Thu, 23 Feb 2006 10:46:25 +0100, Andrea Gasparini wrote: > i'm at first post in this list, and i'm searching for a solution to one > problem, so excuse me if it's not pefectly in topic here... > > So, this is the problem: > i want to wrap almost all system call with LD_PRELOAD, and i would like to > write a minimal library (rewrite all libc is quite boring... :-P ) > I would prefer to write only write(), open() and not having to rewrite > functions like fopen(), printf() and so on... > > I found that with --disable-hidden-plt configure option i can build a > dynamic library that can be preloaded with my own library: something like > $LD_PRELOAD="./libtest.so ./libc.nohidden.so" a.out > > > but it doesn't work... or better: it works for write(),open() that i > directly write into "libtest.so", but printf doesn't call write, so i > can't intercept it... Glibc internally handles system call directly. It also sometimes uses wrapper name prefixed with __ . -- 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]
Re: glibc 2.3.6-3
At Thu, 23 Feb 2006 22:43:26 +0100, Aurelien Jarno wrote: > I have just uploaded glibc 2.3.6-2. It is now time to think to the next > upload, glibc 2.3.6-3. Gook work! > Personally here is the things I would like to see in it: > > - Split of libc6 and libc6-dev into libraries and binaries. This is > required as per policy, but become more important for multiarch support. > But maybe there is a reason for having binaries and libraries in the > same package? It depends on the policy. You could split them. However, I wonder we need to do so. > - More architectures using the multiarch directories for the 64-bit > version of the glibc. This will however depends on other packages > > - A policy for the debian/patches directory. This is currently a bit a > mess (and I contributed to it) in this directory, except for the locale > data which is separated. I think the information we need in the patch > filename is: >- a short part telling what the patch does >- the architecture for which it applies >- the upstream status (debian specific, in upstream BTS, fixed in > CVS). For example xfree86 uses number to define that: 000 (patches from > upstream or merged in upstream), 001-899 (patches that should be merged > in upstream), 900-999 (patches that are specific to debian or were > rejected by upstream). I already tried your idea (numbering them), but finally the attempt was failed. 10_cvs.diff is the example of such remains. > Maybe some more information could be put in the filename. Don't hesitate > to give ideas. Then we could put a README file containing the policy in > this directory. I seconded that the information should be always included in the filename. 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]
Re: timezone data packaged separately and in volatile?
At Tue, 7 Feb 2006 14:30:01 +1100, Anand Kumria wrote: > On Thu, Feb 02, 2006 at 11:42:31PM +0100, Lionel Elie Mamane wrote: > > Hi, > > > > I just realised that the timezone data in glibc is taken from an > > upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data > > sometimes changes, more rapidly than our release cycle (and than any > > release cycle we can reasonable have). > > But that doesn't mean that we can issue an update to a stable package. > > Currently they are mainly done for security purposes -- but stable updates > should not be confined to only that. They should be done to keep the > system functional. Note that I was planning to separate timezone package from glibc package (but I forgot it). It'll be available by the next release, etch. -- 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#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#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#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#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 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#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#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. > > 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 > > > > 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#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]
Re: 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#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#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#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#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#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 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#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]
Re: r1026 - in glibc-package/trunk/debian: . debhelper.in local/etc_init.d rules.d script.in
At Sun, 28 Aug 2005 09:01:32 +0900, GOTO Masanori wrote: > Thanks for your notification. OK, finally i486 emulation is dead. > Actually bswap and cmpxchg are not included in bash and init, but > glibc ix86 libraries have them a lot. How about to change this > warning part in -6 as follows? I put it: if [ "$realarch" = i386 ] then # From glibc 2.3.5-7 and linux-2.6 2.6.12-1, real-i386 is dropped. #if dpkg --compare-versions "$kernel_ver" lt 2.4.24 #then echo WARNING: This machine has real i386 class processor. echo Debian etch and later does not support such old hardware echo any longer. echo The reason is that \"bswap\" instruction is not supported echo on i386 class processors, and some core libraries have echo such instruction. You\'ll see illegal instruction error echo when you upgrade your Debian system. #fi fi However this change rejects to install new glibc even if sarge kernel (that includes i486 emulation patch) is used. In etch, we don't have any security support for kernels that has i486 emu code, so IMHO it's acceptable. 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#325600: libc6.1: Threads remain 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#325600: libc6.1: Threads remain 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 > 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]
Re: 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#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]
Re: r1026 - in glibc-package/trunk/debian: . debhelper.in local/etc_init.d rules.d script.in
At Sat, 27 Aug 2005 18:59:09 -0400, Andres Salomon wrote: > > +# intel i386 requires a recent kernel > > +if [ "$realarch" = i386 ] > > +then > > + if dpkg --compare-versions "$kernel_ver" lt 2.4.24 > > + then > > + echo WARNING: This machine has i386 class processor. > > + echo Debian sarge and later, you need to use at least a 2.4.24 > > + echo or 2.6.0 kernel on i386. Please upgrade your kernel > > + echo before installing glibc. > > + echo The reason is that "bswap" instruction is not supported > > + echo on i386 class processors, and newer kernel can emulate > > + echo such lacking instructions. > > + exit_check > > + fi > > +fi > > FYI, from the linux-2.6 2.6.12-1 changelog: > > * Dropped the following patches: > [...] > - x86-i486_emu.patch (buggy and insecure 80486 instruction emulation > for 80386; we're no longer supporting this) (closes: #250468) > > So, this warning is no longer true (at least for etch/sid). Thanks for your notification. OK, finally i486 emulation is dead. Actually bswap and cmpxchg are not included in bash and init, but glibc ix86 libraries have them a lot. How about to change this warning part in -6 as follows? if [ "$realarch" = i386 ] then echo WARNING: This machine has i386 class processor. echo Debian etch and later no longer supports on such hardware. echo Please don't upgrade your system. echo The reason is that "bswap" instruction is not supported echo on i386 class processors, and some core libraries have them. exit_check fi Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r1026 - in glibc-package/trunk/debian: . debhelper.in local/etc_init.d rules.d script.in
At Sat, 27 Aug 2005 19:20:46 -0400, Daniel Jacobowitz wrote: > On Fri, Aug 26, 2005 at 01:56:34PM +0900, GOTO Masanori wrote: > > > > Check is used for example glibc mets invalid kernel version like > > > > 2.6.1220050825 or glibc detects pre 2.4.24 running kernel on real > > > > i386 architecture that does not support an important instruction. > > Either of these are just as likely to prevent the init.d script from > running entirely (in fact I'm nearly positive that you won't get > through rcS with either of these problems). That's why I don't think > the init.d script is useful. You can see another example of this issue: mips sysvipc, amd64 nptl. Even if rc script does not run through entrirely, users may be able to see the warning in the first stage: S01glibc.sh. I think saving such case is the sufficient reason to add this script. Note that this script is not harmful because it just checks a version and outputs the kernel incompatibility message. It's a small cost to check additionally. My another thought is we can use this message when we drop kernel 2.2 support. Users are notified by the messages each time when they boot up before real-drop is happenned. 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]
Re: r1026 - in glibc-package/trunk/debian: . debhelper.in local/etc_init.d rules.d script.in
At Thu, 25 Aug 2005 23:42:03 -0400, Daniel Jacobowitz wrote: > I don't get it. What's the point? Almost 100% of the time, if we need > to complain about a kernel version, things are going to break so badly > that the #!/bin/sh at the top of the script isn't going to work. If /bin/sh does not work simply, we should bump up MIN_KERNEL_VERSION. In that case, we just get "FATAL: kernel too old" message from ld.so. Please read my explanation: > > Check is used for example glibc mets invalid kernel version like > > 2.6.1220050825 or glibc detects pre 2.4.24 running kernel on real > > i386 architecture that does not support an important instruction. Why don't we need to have libc6.preinst scripts that checks kernel version? Don't you use your own compiled kernel or old kernel? /etc/init.d/glibc.sh just extends it to each kernel boot time. It's simple, and useful for not only libc6 installation time but also each boot time. > So you're adding more work to the boot process that will pretty much > never do any good... I don't have much idea to do such clever way. Initrd is another place, but it's out of scope about user's non initrd kernel image. I think replacing/changin /sbin/init is overkill for this purpose. 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]
Re: r1026 - in glibc-package/trunk/debian: . debhelper.in local/etc_init.d rules.d script.in
At Fri, 26 Aug 2005 02:43:39 +, Masanori Goto wrote: > * Introduce bootstrap kernel version check script. > - debian/debhelper.in/libc.preinst: Move detection script to... > - debian/script.in/kernelcheck.sh: ...this, new file. > - debian/local/etc_init.d/glibc.sh: New file, it includes > kernelcheck.sh. > - debian/debhelper.in/libc.postinst: Invoke /etc/init.d/glibc.sh as S01. > - debian/rules.d/debhelper.mk: Add replacing KERNEL_VERSION_CHECK and > EXIT_CHECK for libc.preinst and glibc.sh. > - debian/debhelper.in/libc.dirs: Create etc/init.d. This commit introduces /etc/init.d/glibc.sh. This file is invoked through /etc/rcS.d/S01glibc.sh, it checks kernel version incompatibility with glibc package. The checking script is used in libc.preinst, but now both libc.preinst and /etc/init.d/glibc.sh have the detection code. The purpose of this change is to inspect some problematic kernel version numbers, not only libc6 installation time but also during kernel booting up. Check is used for example glibc mets invalid kernel version like 2.6.1220050825 or glibc detects pre 2.4.24 running kernel on real i386 architecture that does not support an important instruction. I choised to use S01glibc.sh, because this check should be done earlier than other scripts invocation. I'll put glibc 2.3.5-5 soon after ppc64 stuff is put and test is done. 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]
Re: Locales and belocs-locales-data, some explanations
At Thu, 25 Aug 2005 22:40:02 +0200, Denis Barbier wrote: > > On Tue, Aug 09, 2005 at 01:48:14AM +0200, Denis Barbier wrote: > > * By default, locales are written into the old format (not into an > > archive file). My motivation was that if someone needs to add a > > local locale, she can compile her locale into $HOME/share/locale > > and set LOCPATH to $HOME/share/locale:/usr/lib/locale if she > > wants to use either her preferred locale or a system one, e.g. > > with LANGUAGE=xx_XX:de > > But this will work only if system locales are compiled in old > > style, not with archive. I also made benchmarks to see if > > archive was faster, and IIRC noticed no significant difference. > > This behavior can be overridden by the --archive flag. > > Bruno Haible wrote in > http://mail.gnome.org/archives/locale-list/2005-August/msg00014.html > > Similarly, he has put all the locale data files into a single big > archive, to reduce the number of open() calls at program startup. > > > On Red Hat, locales are compiled into both old and new formats, > certainly to take advantage of both sides. Yes, I agree with this thought. Note that I have been adding localeall package that contains all pregenerated locales data - both old and new format. However, it's nice to have both old and new data for the current locales package, too. 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#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 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#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#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#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]
Re: 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]
Re: 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
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]
Re: Processed: libc bug appears to be dangerous for arm
At Tue, 23 Aug 2005 20:18:02 -0700, Debian Bug Tracking System wrote: > > severity 324795 critical > Bug#324795: libc6 in stable broken on arm4vl > Severity set to `critical'. Why did you bump up severity of this report? Do you have this problem too? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 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#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#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#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]
Re: kernel build version dependency and NPTL support
At Sat, 20 Aug 2005 09:05:02 +0200, Gerhard Tonn wrote: > > Linux debian01 2.6.11-1-s390x #1 SMP Mon Apr 4 18:37:40 CEST 2005 > s390x GNU/Linux > > The buildd runs now on a different machine with a 2.4 kernel. I will > build glibc on debian01 in the future. I uploaded glibc 2.3.5-4 on s390 by hands, but I expect you'll set up 2.6 kernel on s390. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
At Wed, 17 Aug 2005 03:06:12 +0200, Zoran Dzelajlija wrote: > Well, for one thing, upgrading libc6 triggers the breakage on > unrelated, already installed packages - and there's a lot of those > linked to eg. libssl-0.9.7.so. BTW. looks like there are some patches > which mitigate this issue, see eg. the libc6 build in this > third-party repository: > > deb http://debian.linux-systeme.com unstable main > > (I haven't taken a good look at the diff, but the changelog says > > * Add PaX support. How did you fix your package? > It seems reasonable to include some global workaround until all these > broken library packages get fixed, since the breakage appears to have > wide effects on the affected systems. Since there is a workaround in > glibc available, maybe it's better to leave a copy of the bug here, > perhaps for you to examine the patch and see if it would be a good idea > to apply it? I think it's decided by the trade-off between workaround and the correct fix. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel build version dependency and NPTL support
I found NPTL/buildd kernel mismatch problem today when I saw the s390 build log failure at http://buildd.debian.org/~jeroen/status/package.php?p=glibc /build/buildd/glibc-2.3.5/build-tree/s390-nptl/elf/ld.so.1 --library-path ... /build/buildd/glibc-2.3.5/build-tree/s390-nptl/timezone/zic -d /build/buildd/glibc-2.3.5/debian/tmp-nptl/usr/share/zoneinfo -L /dev/null -y ./yearistype africa FATAL: kernel too old make[3]: *** [/build/buildd/glibc-2.3.5/debian/tmp-nptl/usr/share/zoneinfo/Africa/Algiers] Error 1 ** Build finished at 20050819-1021 FAILED [dpkg-buildpackage died] "FATAL: kernel too old" is barfed by ld.so. It refuses to execute on old kernel 2.4. I guess the s390 buildd debian01 uses 2.4 kernel. ld.so built with NPTL requires 2.6 kernel, because using NPTL requires 2.6 kernel, and ld.so checks such minimum supported kernel version which is defined as 2.6 and decided by build time. I don't want to use "make -k" to build glibc, we should build glibc/s390 on 2.6 kernel. I don't also want to modify glibc/s390 package to work on 2.4 kernel - the current ld.so refusal is natural behavior. In future, we'll add more NPTL supported architecture. However if some buildd on that architectures are kernel 2.4, we can't generate such packages. To fix this problem, we need to choose the below two different approaches: (1) All buildd should go to 2.6 kernel. (2) Gentoo's package has kernel version dependency, but we debian does not have it. So I would like to propose that each debian package that depends on the environmental factor should have explicit specifier. For example, glibc debian/control has "Build-Env-Depends: kernel-2.6". Buildd teams, release managers, and glibc teams, how do you deal with this problem? Any comments are welcome. BTW, note that I can access to kernel 2.6 s390 machine - I'll upload glibc 2.3.5-4 on s390 by hand. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: future libc6-sparcv9 and libc6-sparcv9b support
At Thu, 18 Aug 2005 16:36:53 -0400 (EDT), David S. Miller wrote: > Yes, because the optimized memcpy/memset in the sparcv9 package > is severely suboptimal for UltraSPARC-III and later chips, which > is what the sparcv9b package is needed for. ... > Right, it will be necessary. To be honest, pure traditional sparc 32-bit > support is a real roadblock to progress in any of these areas. At Thu, 18 Aug 2005 06:20:50 -0700, Ben Collins wrote: > When that happens there will only be libc6 package (with standard v9 > optimization), and v9b optimized packages. The 64-bit package will never > go away. Thanks to Ben, David and Jakub, I understand the current status of sparc/v9/v9b/64 packages. > You guys can decide when and if to do this. Yes, we can select when we drop the old sparc32 support, with seeing the circumstance. IMHO etch is the nice time to work on it to add NPTL. The first step is to support NPTL on sparcv9/v9b/64 - but it needs a bit modification to debian/rules.d/debhelper.mk and so on. 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#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]
Re: future libc6-sparcv9 and libc6-sparcv9b support
At Thu, 18 Aug 2005 12:58:58 +0200, Christoph Hellwig wrote: > I think m68k has no nptl either, and as m68k are a very vocal minority > you'll have more flames about that ;-) > > Let's try to get NPTL working on 2.3 with all supported architectures > first, that's been long overdue - long term dropping LT is the only > choice, but that'll need a lot more flamewars first unfortunately. Exactly... your point makes much sense. We should talk with Andreas Schwab. 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(¤t->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]
Re: future libc6-sparcv9 and libc6-sparcv9b support
At Thu, 18 Aug 2005 02:39:23 -0400 (EDT), David S. Miller wrote: > > I have a question about optimization package: libc6-sparcv9 and > > libc6-sparcv9b. Both packages are prepared for optimized versions of > > libc6. They are currently supported - but I would like to know what > > the advantage of those packages is. Just optimization? Are those > > packages widely used? > > Besides being compiled with the proper optimization and feature > options, they use memcpy and memset implementations which are > several orders of magnitude faster than plain Sparc versions. > > Every single UltraSPARC debian system I have has these special > versions of the library installed. You can feel the difference > these libraries make, performance wise, in many cases. Well, we sometimes meet words "optimization makes faster", but we merely see the actual result of performance gain. How much is the improvement of such optimized packages? Is sparcv9b valuable compared with sparcv9? > > These days 2.6 kernel is getting popularity, so it's nice time to > > support NPTL on sparc systems. But having a lot of optimized packages > > and variants like NPTL take much longer build time + maintenance cost. > > If we replace unpopular optimized libc6 packages with NPTL libc6 in > > future, it's much valuable for users, I think. > > > > How about to drop libc6-sparcv9/sparcv9b and introduce NPTL-enabled > > libc6 in future? > > You'll only get NPTL to work on sparcv9 and later anyways. > Pure traditional sparc 32-bit NPTL is non-functioning even > in the current glibc tree. And I doubt there is much incentive > to write the support. > > Only sparcv9 and later work with NPTL, and since it requires TLS this > means current CVS binutils is necessary as well especially if you wish > to build 64-bit NPTL enabled glibc on sparc as well. Thanks for your precious follow up. From your suggestion, normal libc6 package (that's also usable for pre sparcv9 archs) does not have any NPTL support, but libc6-sparcv9 (and v9b) can have NPTL support. IIRC, you have worked for 64bit NPTL support on sparc, so I expect libc6-sparc64 will be able to support NPTL without hassle. BTW, if we move to glibc 2.4 series in future, at that time we may need to drop LT support. It means the traditional pre sparcv9 system will be also dropped. Is that acceptable direction for sparc users? (Note that dropping LT is not decided and I think we shouldn't do so currently). Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 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#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]
Re: 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]
Re: 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#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]
future libc6-sparcv9 and libc6-sparcv9b support
Hi, I have a question about optimization package: libc6-sparcv9 and libc6-sparcv9b. Both packages are prepared for optimized versions of libc6. They are currently supported - but I would like to know what the advantage of those packages is. Just optimization? Are those packages widely used? These days 2.6 kernel is getting popularity, so it's nice time to support NPTL on sparc systems. But having a lot of optimized packages and variants like NPTL take much longer build time + maintenance cost. If we replace unpopular optimized libc6 packages with NPTL libc6 in future, it's much valuable for users, I think. How about to drop libc6-sparcv9/sparcv9b and introduce NPTL-enabled libc6 in future? 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#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#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 locales (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#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#321718: Upgrade caused many libs to complain about "executable stack"
At Mon, 8 Aug 2005 10:09:38 -0400, Daniel Jacobowitz wrote: > > 08:47 mprotect(0xb000, 4096, > > PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid > > argument) > > 08:47 mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = > > -1 EFAULT (Bad address) > > 08:55 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#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#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#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#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#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]
Re: Bug#322724: ncurses doesn't build with gcc -m64 on i386
At Fri, 12 Aug 2005 14:42:56 -0400, Daniel Jacobowitz wrote: > > yes. trying to build the packages from amd64-libs for biarch. > > Then you've got glibc messed up, not ncurses. You can't install the > i386 headers and expect things to work; you might be able to just > install the x86_64 headers, though. That'd be simpler than installing > both sets and generating wrappers. I would like to know: should we have the standard x86_64 glibc/lkh packages as i386 package like amd64-libs? I expect a future biarch (that provides x86_64 and i386 packages at the same time on the same machine) saves this problem. During DebConf5, Scott proposed dpkg filter mechanism, and Tollef proposed dpkg multiarch extension Features:. I think the approach "biarch mechanism in dpkg" is sane. But if the current biarch is not usable well, we should consider to support x86_64 glibc/lkh in the standard i386 package. 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#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#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#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#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#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#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]
Close bugs tagged as woody
These bugs are tagged as woody, because they're well-known problems and for keeping open to come to light what the problem is. However, as you know, sarge was released. Our stable version was moved from woody to sarge. It's high time to close old woody's bugs that are still open. Now I close these bugs. If you have any objections to close them, please reopen and let us know your trouble. 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 which used __user but failed to include > 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]
Re: r984 - in glibc-package/trunk/debian: . patches
At Wed, 3 Aug 2005 22:50:29 +0200, Denis Barbier wrote: > On Wed, Aug 03, 2005 at 08:15:05PM +, Masanori Goto wrote: > > + ur_PK/UTF-8 \ > > + uz_UZ/ISO-8859-1 \ > > ++uz_UZ.UTF-8 UTF-8 \ > > Oops, I was referring to the SUPPORTED file shipped by the locales > package. When patching original source file, you should add > uz_UZ.UTF-8/UTF-8 \ > instead. Right! I fixed it, thanks for your notification and double checking. 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#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#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 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 > > 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-x11&ver=6.8.2.dfsg.1-4&arch=sparc&stamp=1122655926&file=log&as=raw Regards, -- gotom
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#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#318244: segmentation fault with many files
At Fri, 15 Jul 2005 11:18:26 -0500, Manoj Srivastava wrote: > This does not seem to be something that changes in make are > going to fix. make essentially makes a glob (3) call; and that > library call is where the segmentation violation occurs. Considering > that the number of entries in the directory are insanely high, this > could be something that libc was not prepared for (memory > exhausted?). Did you really confirm what the problem was? Don't reassign it before doing meaningful investigations. Tuukka, is it easy to reappear this problem again? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296532: ldconfig: /usr/lib is not a symbolic link
tags 296532 unreproducible moreinfo thanks > I'm not sure what caused this. Every time ldconfig is run, it spews: > > /sbin/ldconfig: /usr/lib/ is not a symbolic link > > So this gets kind of annoying every time a library package is installed. > > It hasn't happened until recently. A strace log is attached for your > debugging convenience. It's not really an important bug since > everything still seems to work fine. Does this problem still occur on your environment? If so, we consider how to resolve the bug - if not, it's OK to close, I think. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299137: (no subject)
tags 299137 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]
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#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#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]
