Bug#498985: [Lynx-dev] Dumps Unicode file in broken encoding.
Thomas Dickey dixit: Without some charset in the document, or override via command-line or lynx configuration, the file will be treated as ISO-8859-1. He seems to be expecting lynx to treat it as UTF-8. I think this is what recent (X)HTML/HTTP standards assume as well. This is the reason I changed that locally – but you probably can only change the default on a full-UTF-8 operating system, since changing the assumed character set for local files would break OSes without locale and Unicode support, such as OpenBSD. Besides, some (few) webpages still display badly as they do not declare their character set, but the “webmasters” usually fix it upon reporting. bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498985: [Lynx-dev] Dumps Unicode file in broken encoding.
Atsuhito Kohda dixit: aqwa『~』$ lynx.cur --dump test.html * é * This is very interesting: [EMAIL PROTECTED]:~ $ lynx -dump test.htm * é * � [EMAIL PROTECTED]:~ $ lynx -version Lynx Version 2.8.7dev.9 (27 Apr 2008) libwww-FM 2.14, SSL-MM 1.4.1, ncurses 5.6.20080830(wide) Built on linux-gnu Sep 2 2008 02:14:03 [EMAIL PROTECTED]:~ $ lynx -dump test.htm * é * à [EMAIL PROTECTED]:~ $ lynx -version Lynx Version 2.8.7dev.8-MirOS (17 Feb 2008) libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.7m, ncurses 5.5.20051010(wide) No compilation information available. But this is also the key to the solution, because MirBSD always has the UTF-8 locale (also for assumed charset and display charset), so, back on Debian, I get this: [EMAIL PROTECTED]:~ $ lynx -assume_charset=utf-8 -display_charset=utf-8 -dump test.htm * é * à This, in the end, means that the stock lynx-cur configuration is broken, and this is not an upstream problem. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492377: mksh: strcasestr implicitly converted to pointer
tags 492377 + help reassign 492377 qa.debian.org thanks dann frazier dixit: Function `strcasestr' implicitly converted to pointer at ] scn.c:4 I suggest you read your eMail INBOX, as I already wrote to you in Message-ID: [EMAIL PROTECTED] that this is a FALSE POSITIVE and that I request help for how to deal with this bug in your automated checker. Excerpt from that eMail, for the archives: │http://buildd.debian.org/fetch.cgi?pkg=mksharch=ia64ver=35.2-1stamp=1216828593file=logas=raw │ │The mksh build process involves a configuration and a build step, similar │to what GNU autoconf does. (In fact, it does this twice, once for the │normal glibc binary, once for a small dietlibc binary.) However, in con- │trast to GNU autoconf, the configuration step is verbose. │ │The autoconf check for strcasestr() is expected to return no with dietlibc, │because the function is not defined. Since it is not declared in any sy- │stem header file (of dietlibc), we have no prototype, so the compile test │also triggers a false positive on the warning: │Diagnostic output from the autoconf checks is prepended by “] ” (and always │occurs on the file scn.c, akin to conftest.c in GNU autoconf). │ │What do you suggest to remove this false positive while keeping the confi- │guration process as warning-free as possible? As for a possible solution, I don’t think that adding an exemption of mksh to the checker is worth the effort, but I can’t think of a modifi- cation to the test that would NOT trigger the warning while staying warning-free in all other cases (as the test is EXPECTED to fail on Debian with Fefe’s dietlibc). Maybe I could play some sed magic to fool the regex your scanner uses, so that it doesn’t recognise warnings emitted during the configuration process? This would then be a Debian- specific kludge and NOT go in upstream. If you have any BETTER solutions, please let me know. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492377: mksh: strcasestr implicitly converted to pointer
dann frazier dixit: but mksh cannot release until it is fixed somehow Hm okay. I don't have any good solutions in mind Good, then I might try some workaround against the regex matcher. Can a non-DD get access to an IA64 test machine, or can I send a beta package for testing and NOT uploading to someone, once I hacked that potential workaround? TIA, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492377: mksh: strcasestr implicitly converted to pointer
Hi! implicit_pattern = re.compile(([^:]*):(\d+): warning: implicit declaration … I think that a simple addition to the already-existing sed command, like s/^[^:]*:[0-9]*:/config test;/ (which I did in mksh-35.2-2, pending to be uploaded by my sponsor¹) should avoid your script to be triggered. Note that the sed is only run on configure-time $CC calls anyway, not on calls to $CC used to really build mksh with the compiled results, so that real bugs in the source were to still be caught, if they then existed. ① I just realised I have a freeze exception on mksh, even if I don’t know why, so let’s use it… (I learned about the freeze 2 days ago on the media…) bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492377: marked as done (mksh: strcasestr implicitly converted to pointer)
Luk Claes dixit: Why did you restrict the build dependency on dietlibc to a whole list of architectures? This is the list of architectures dietlibc exists on (taken from its debian/control file, copied verbatim). On architectures without dietlibc, mksh-static is statically linked against glibc (in mksh-35.2-1 it was dynamically linked, since I forgot to add -static which the “diet” helper does by itself). Is the build dependency on locales-all really needed, if so in what way? Yes, one of the regression tests sets the locale to “en_US.UTF-8” and checks if mksh (non-static) switches to Unicode mode automatically then. Thanks for your attention ☺ I’m trying to get it as bug- and warning-free as possible, and more peoples’ eyes are helping with that. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499139: Possible problem with debconf and shell interaction?
tags 499139 +help thanks Hi, I verified #499139 with mksh, pdksh and – interestingly enough – ATT ksh93 on Debian GNU/Linux testing/unstable. I wonder if the file descriptor magic of debconf is at fault here instead, as, usually, the ksh93 behaviour is “right”. As I barely know debconf at all, I have slight problems what exactly is going on. With modified scripts (sh → mksh in both, a 33 added, and an initial “print test-ksh running: $0 $*” and “set -x”) I get this: [EMAIL PROTECTED]:~ $ ./test-ksh test-ksh running: ./test-ksh + . /usr/share/debconf/confmodule + [ ! ] + PERL_DL_NONLAZY=1 + export PERL_DL_NONLAZY + [ ] + exec /usr/share/debconf/frontend ./test-ksh debconf: DbDriver passwords warning: could not open /var/cache/debconf/passwords.dat: Permission denied + . /usr/share/debconf/confmodule + [ ! 1 ] + [ -z ] + exec + 31 + [ ] + exec + 2 + DEBCONF_REDIR=1 + export DEBCONF_REDIR + ./run-test + 33 run-test running: ./run-test + . /usr/share/debconf/confmodule + [ ! 1 ] + [ -z 1 ] + db_get dictionaries-common/default-ispell ./run-test[7]: 3 : bad file descriptor I decided to add the help tag instead of cloning twice and assigning the duplicates to pdksh and ksh93, but maybe someone can tell me, us, what is going on there, and maybe the pdksh and ksh93 maintainers can join in? (Is there a way to let them know of this bug report automatically? I just chime in this early due to a private mail from the originator…) bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499139: Possible problem with debconf and Korn shell interaction?
retitle 499139 Possible problem with debconf and Korn shell interaction? thanks .oO(Agustin, your first two retitles didn’t work ☺) For what it’s worth: You wrote… I have done further research on this and the result follows: GOOD: bash, dash, posh, pdksh BAD: ksh, mksh BAD2: zsh […] For this reason I tend to think this is a problem in mksh (and in its ancestor ksh). The ancestor of mksh is pdksh, not ATT ksh93, and all three show the same behaviour. (Usually, ATT ksh is “right”, whatever that means… for some things, that even means “authoritative”. But the pdksh deri- vates don’t follow them blindly either.) bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you 13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺ 16:06⎜Draget:#cvs Thank god I found you =) 17:14⎜ldiain:#cvs Thanks big help you are :-) 18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-) 18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499139: Possible problem with debconf and shell interaction?
Agustin Martin dixit: I may have messed up the names with all the sh changes. I just changed the shebang lines instead ;) Note /bin/ksh is a symbolic link, thus shouldn't be needed to be tested. The simple way to keep everybody joined is to abuse he BTS, reassigning bug report to e.g. 'mksh,pdksh,ksh', so it can be accessed from the three packages and everybody receives mails. I am bcc'ing those packages to keep them aware. Ah, okay, thanks. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499139: Possible problem with debconf and shell interaction?
Agustin Martin dixit: /bin# ln -sf pdksh sh and keep the shebang lines pointing to /bin/sh the test script runs (no hang and no error signalled, even with '-e' flag enabled in both scripts, and the right return value shown). However, if I explicitly change the shebang lines scripts seem to fail, Okay, that is a really useful information, I think I can have a look at this… once I got time. I don’t know what to do with that strace output though ;) I don’t use Linux myself. //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499139: Possible problem with debconf and shell interaction?
tags 499139 -help +upstream +confirmed thanks This seems to be related to #154540 – found after I got the information that it only happens to pdksh with FSH not set. Would a fix for this bug be worth a freeze exception? Otherwise, I’ll just fix it upstream, and the Debian package would be updated with a new upstream version in ~1-2 months or so. //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499139: Possible problem with debconf and shell interaction?
prepended to it: .Pp .D1 $ cat /foo/bar 2\*(Gt1 \*(Gt /dev/null \*(Ba cat \-n +.Pp +File descriptors created by input/output redirections are private to the +Korn shell, but passed to sub-processes if +.Fl o Ic posix +is set. .Ss Arithmetic expressions Integer arithmetic expressions can be used with the .Ic let @@ -3580,9 +3585,11 @@ and commands above for more details. .It Ic posix Enable POSIX mode. -Currently, this just turns off +Automatically enabled if the basename of the shell invocation begins with +.Dq sh . +As a side effect, setting this flag turns off .Ic braceexpand -mode when turned on, which can be turned back on manually. +mode, which can be turned back on manually. .It Ic restricted The shell is a restricted shell. This option can only be used when the shell is invoked. @@ -5525,7 +5532,7 @@ and many other persons, and is currently .An Thorsten Glaser Aq [EMAIL PROTECTED] . .Sh BUGS This document attempts to describe -.Nm mksh\ R35 +.Nm mksh\ R35c and up, compiled without any options impacting functionality, such as .Dv MKSH_SMALL , Index: src/bin/mksh/sh.h diff -up src/bin/mksh/sh.h:1.231 src/bin/mksh/sh.h:1.232 --- src/bin/mksh/sh.h:1.231 Sun Sep 14 20:24:59 2008 +++ src/bin/mksh/sh.h Wed Sep 17 19:31:30 2008 @@ -102,7 +102,7 @@ #ifdef EXTERN __RCSID($MirOS$); #endif -#define MKSH_VERSION R35 2008/09/14 +#define MKSH_VERSION R35 2008/09/17 #ifndef MKSH_INCLUDES_ONLY
Bug#499139: Possible problem with debconf and shell interaction?
Robert Luberda dixit: However I have never checked if it's true that POSIX doesn't specify what happens in this case. But if it is, debconf should be fixed not to use such constructions, I think. Right. Many people assume POSIX shells are similar to Bourne shells, but the Korn shells often differ subtilely. On the other hand, I could see that this behaviour (not closing any ex- cess file descriptors) has use cases. Now if there were a standard way to specify it… //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491634: ITP: libbsd-arc4random-perl -- CPAN module BSD::arc4random
Package: wnpp Severity: wishlist Owner: Thorsten Glaser [EMAIL PROTECTED] * Package name: libbsd-arc4random-perl Version : 1.30 Upstream Author : Thorsten Glaser [EMAIL PROTECTED] * URL : http://www.mirbsd.org/man3/arc4random * License : MirOS Licence (same as package mksh) Programming Lang: C, Perl Description : CPAN module BSD::arc4random I've prepared a package of a Perl module wrapping the arc4random(3) family of functions into ithreads-safe Perl functions and adding some syntactic sugar. The libbsd package’s implementation of arc4random(3) is used instead of the included convenience copy. This package makes access to a self-seeding PRNG easy, for example in programmes that can be extended by Perl plugins, such as irssi. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable'), (700, 'unstable'), (500, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498075: lintian: unusual-interpreter … #!/bin/mksh
Package: lintian Version: 1.24.2.1 Severity: wishlist #!/bin/mksh is not recognised by lintian yet. Please refer to the mksh package for a candidate. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.20 Debian package development tools ii file4.25-1 Determines file type using magic ii gettext 0.17-3 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl1.1600-9 Time and date functions for Perl ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.2-2 on-line manual pager ii perl [libdigest-sha 5.10.0-13Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.2-2on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
Package: lintian Version: 1.24.2.1 Severity: normal W: mircpio: manpage-has-errors-from-man usr/share/man/man1/mircpio.1.gz list open at EOF! A .Bl directive has no matching .El I’ve got three manpages in mdoc(7) format with this error now. All of them are valid (at least I think so), but have nested lists: │ .Bl ... │ ... │ .Bl ... │ ... │ .El │ ... │ .El I think this triggers the manpage-has-errors-from-man bug falsely. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.20 Debian package development tools ii file4.25-1 Determines file type using magic ii gettext 0.17-3 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl1.1600-9 Time and date functions for Perl ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.2-2 on-line manual pager ii perl [libdigest-sha 5.10.0-13Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.2-2on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
reassign 498082 man-db thanks Russ Allbery dixit: The error message is coming from man --warnings. It's possible that it may have some sort of problem. Can you double-check first that you have the most current man-db package? If so, I'll transfer the bug there. Oh okay. Sure. ii man-db 2.5.2-2on-line manual pager Looks current according to packages.d.o. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
Colin Watson dixit: Please note that man-db is almost never the real source of this kind of bug Okay, I did not know which of the many components may be the source. if you think the warning is incorrect, please reassign to groff-base, not to man-db. (I've reassigned this one.) Thanks. Could you please give me a copy of the manual page in question, since this package doesn't appear to be in the Debian archive? Yes, it does not appear… yet ;) but of course I’ve added three exemplars. There’s, interestingly enough, an iconv warning too (maybe in the mdoc macro package?) which lintian does not show. bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you 13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺ 16:06⎜Draget:#cvs Thank god I found you =) 17:14⎜ldiain:#cvs Thanks big help you are :-) 18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-) exemplars.tgz Description: Binary data
Bug#498082: lintian: false positive in manpages
Colin Watson dixit: Heh, you managed to find a case where it actually *was* a man-db bug after all! I did say almost never, I guess ... Happens ;-) This is triggered by your use of UTF-8 characters that aren't just recoded versions of ISO-8859-1 characters in comments at the top of the manual page. Ah, okay. The Debian Policy Manual documents the current situation: Due to limitations in current implementations, all characters in the manual page source should be representable in the usual legacy ^^ Interesting twist if this appears to comments as well. (But with your fix, I believe this won’t be necessary any more ☺) encoding for that language, even if the file is actually encoded in UTF-8. Safe alternative ways to write many characters outside that range may be found in groff_char(7). You can work around this bug by replacing those characters with some plain ASCII, perhaps something like this: -.\ * ` generates b-.\ * ' generates b-.\ * - generates b+.\ * ` generates U+2018 in groff, so use \` +.\ * ' generates U+2019 in groff, \' generates B4, so use \*(aq +.\ * - generates U+2010 in groff, \- generates U+2212, fixed in tmac/mdoc/doc-groff I think your mail arrived here in a broken state. After this fix, you still have a warning: `aV' not defined, but that's a genuine problem in your pages rather than in either groff or man-db. Interesting too. I will have to look at how GNU groff’s mdoc implementation defines the .Nx, .Ox c. macros then. (MirBSD uses ATT nroff (and offers GNU groff via ports) with the (a bugfixed) UCB mdoc implementation for both *roff processors, so that this issue has not appeared there yet.) Thanks for this quick fix and the coöperation! bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: GNU mdoc vs UCB mdoc (was Re: Bug#498082: lintian: false positive in manpages)
Colin Watson dixit:
would mean that line/byte numbers would be wrong, which could be
confusing.
They are wrong anyway, as the macro packages count for byte numbers
too, at least in the iconv example. But still a point: we could just
wc the macro package first.
mdoc; docj.tmac still has it, commented as parse argument vector
(recursive). As far as I can tell this was replaced by the
doc-parse-args macro, probably in Werner Lemberg's complete rewrite of
mdoc in March 2001. However, it wasn't obvious to me how to upgrade your
macro.
Interesting… why a rewrite, I wonder. But yes, parse argument vector
recursively sounds about right. Maybe I can use something like this:
│.if \n(.g \{\
│.de aV
│.doc-parse-args \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
│..
│.\}
I think this use of a more than two character macro will be tolerated
by ATT nroff since it’s if’d out anyway.
The other option would be GNU groff mdoc tmac file upstream considering
to add back support for the aV macro…
bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in Notes on Programming in C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428883: bashism in init script fails to start slapd
Hi, with the upload of mksh-30.1-1, no further action is needed, since it will not define the “stop” alias any more if called as /bin/sh. You therefore might want to close this bug report. On the other hand, other Korn shells – most prominently, pdksh – probably will still define this alias, so the bug is not solved for them. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#408850: using flags -fwhole-program --combine broken
Martin, can I use the account on the Alpha you gave me now to test this? Last time I tried it still did not work (you said something like the sid dchroot being broken). I have no other way to check that, and I didn't get real instructions how to reproduce it on non- alpha from that SuSE guy either, so I'm at a loss here. bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408850: mksh: FTBFS on experimental/alpha (Re: Log for failed build of mksh_28.9.20070118 (dist=experimental))
I have an idea…
Dixi:
Martin Zobel-Helas dixit:
/usr/include/sys/stat.h:217: error: conflicting types for 'stat'
/usr/include/sys/stat.h:365: error: previous definition of 'stat' was here
[...]
Sounds like a bug in the header file to me:
215 extern int __REDIRECT_NTH (stat, (__const char *__restrict __file,
216 struct stat *__restrict __buf),
stat64)
217 __nonnull ((1, 2));
363 extern __inline__ int
364 __NTH (stat (__const char *__path, struct stat *__statbuf))
365 {
366 return __xstat (_STAT_VER, __path, __statbuf);
367 }
The second one is missing the restrict qualifier. Could that
be the cause, possibly induced by invoking the C99 standard
during compiling with -std=gnu99 ?
Could please someone with access to an alpha try to build the version
of mksh currently in experimental, or even my “current playchild“
at http://users.unixforge.de/~tglaser/mksh_28.9.20070304.dsc, with
HAVE_CAN_STDG99=0 defined in the environment (of Build.sh, i.e. I'd
patch debian/rules appropriately) and show me the build log?
If so, we might at least have a workaround until that's fixed in
the system headers, because I've got a major update to mksh (i.e.
a new formal release) I'd like to get into unstable/testing, and
(thanks to playing around in experimental) only this bug is pre-
venting me from doing so.
@Pierre HABOUZIT: maybe your sample programme compiles fine as
long as you don't use -std=gnu99? Maybe the issue only appears
on alpha because it implies some kind of alignment changes?
Thanks!
bye,
//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
Bug#408850: mksh: FTBFS on experimental/alpha (Re: Log for failed build of mksh_28.9.20070118 (dist=experimental))
This version was uploaded to 'experimental' exactly to find out
possibly portability problems, e.g. with kfreebsd and hurd ;)
So I suppose that was a good move.
Martin Zobel-Helas dixit:
/usr/include/sys/stat.h:217: error: conflicting types for 'stat'
/usr/include/sys/stat.h:365: error: previous definition of 'stat' was here
[...]
Sounds like a bug in the header file to me:
215 extern int __REDIRECT_NTH (stat, (__const char *__restrict __file,
216 struct stat *__restrict __buf),
stat64)
217 __nonnull ((1, 2));
363 extern __inline__ int
364 __NTH (stat (__const char *__path, struct stat *__statbuf))
365 {
366 return __xstat (_STAT_VER, __path, __statbuf);
367 }
The second one is missing the restrict qualifier. Could that
be the cause, possibly induced by invoking the C99 standard
during compiling with -std=gnu99 ?
bye,
//mirabile
--
Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL.
-- Henry Nelson, March 1999
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424173: freebsd-utils: bash dependencies in shell scripts run by portable shell
Package: freebsd-utils
Version: 6.2-3
Severity: important
Tags: patch
A few scripts from freebsd-utils contain calls that are not
pure bourne/posix shell, namely:
[EMAIL PROTECTED]:~ # fgrep -nr 'exec -a' /bin /sbin
/bin/mount:17:exec -a mount /lib/freebsd/mount ${args}
/bin/sysctl:29:exec -a sysctl /lib/freebsd/sysctl ${args}
/sbin/route:32:exec -a route /lib/freebsd/route ${cmd} ${args} /dev/null
This could either be fixed (what is exec -a supposed to do?) or,
possibly better, be worked around by changing the first line of
all these scripts to #!/bin/bash which is installed anyway.
-- System Information:
Debian Release: lenny/sid
Architecture: kfreebsd-i386 (i686)
Kernel: kFreeBSD 5.4-1-486
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8)
Shell: /bin/sh linked to /bin/mksh
Versions of packages freebsd-utils depends on:
ii freebsd-hackedutils6.1-1 FreeBSD utilities needed for GNU/k
ii libbsd00.0-1.2+r1710 BSD compatibility library - shared
ii libc0.12.5-7 GNU C Library: Shared libraries
ii libfreebsd00.0-5 FreeBSD compatibility library - sh
ii libgeom0 6.2-1 FreeBSD GEOM library
ii libkiconv2 6.2-1 FreeBSD kernel side iconv library
ii libkvm06.2-1 FreeBSD kvm (kernel memory interfa
freebsd-utils recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424179: lynx-cur: please provide wide curses (UTF-8 capable) version
Package: lynx-cur Version: 2.8.7dev4-2 Severity: wishlist lynx currently has issues with pages with non-ASCII characters on an unicode capable terminal (which, for me, is uxterm running on my laptop, ssh'ing into the Debian system), most prominently www.google.co.jp Linking with libncursesw and using --with-screen=ncursesw --enable-widec configure options was enough to fix this problem when I encountered it on MirBSD, so I think this would be ok for Debian too. Look at the centericq-utf8 Debian package, it's exactly the same as the normal centericq Debian package but linked with ncursesw. Maybe you want to do it like that? On the other hand, adding libncursesw as lynx-cur dependency probably isn't bad either. -- System Information: Debian Release: lenny/sid Architecture: kfreebsd-i386 (i686) Kernel: kFreeBSD 5.4-1-486 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages lynx-cur depends on: ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii libc0.1 2.5-7 GNU C Library: Shared libraries ii libgnutls13 1.6.2-2the GNU TLS library - runtime libr ii libncursesw5 5.5-5 Shared libraries for terminal hand ii zlib1g1:1.2.3-14 compression library - runtime Versions of packages lynx-cur recommends: ii mime-support 3.39-1 MIME files 'mime.types' 'mailcap -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424173: freebsd-utils: bash dependencies in shell scripts run by portable shell
Cyril Brulebois dixit: IMHO fixing is better than workarounding. Using a bash shebang would add an (otherwise) unnecessary Depends: In Debian, it would not, because /bin/bash is, at the moment, required to be always there. and having POSIX-compliant scripts sounds *much* better to me. Same for me, but I guess we can already be lucky that all scripts using /bin/sh have to not use bashisms. If there's an easy way to fix this problem without making the script use bash, ok, but I haven't heard of such functionality in other shells, so I suppose changing the shebang line here would be fine. bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424208: module-init-tools: use of /usr/bin/{sort,uniq} before /usr is mounted
Package: module-init-tools Version: 6.2-3 Severity: grave Justification: renders package unusable S20module-init-tools calls '... | sort | uniq' but is run at a time during bootup where /usr is not yet mounted, and sort and uniq are, obviously, not available yet: [EMAIL PROTECTED]:~ # whence -p sort; whence -p uniq /usr/bin/sort /usr/bin/uniq Side note: 'foo | sort -u' does the same as 'foo | sort | uniq' and is usually much faster. This renders the script in question unusable whenever /usr is on a separate filesystem from /, which is usually recommended in most *nix install guides. -- System Information: Debian Release: lenny/sid Architecture: kfreebsd-i386 (i686) Kernel: kFreeBSD 5.4-1-486 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages module-init-tools depends on: ii debconf1.5.13Debian configuration management sy ii kfreebsd-image-5.4-1-486 [ 5.4-21kernel of FreeBSD 5.4 image ii libbsd00.0-1.2+r1710 BSD compatibility library - shared ii libc0.12.5-7 GNU C Library: Shared libraries ii libfreebsd00.0-5 FreeBSD compatibility library - sh module-init-tools recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424213: sendmail-bin: unportable shell code in postinst script
Package: sendmail-bin
Version: 8.14.1-2
Severity: important
The postinst script contains a shell function stop () { ... }
but this fails when using a Korn shell as /bin/sh, because it
is normally defined as shell alias:
$ for a in ash bash dash mksh pdksh ksh93 zsh; do env me=$a $a -c 'stop () {
echo $me works; }; stop'; done
ash works
bash works
dash works
mksh: syntax error: '(' unexpected
pdksh: syntax error: (' unexpected
ksh93: syntax error at line 1: (' unexpected
zsh works
The obvious fix is to change
| stop () {
into
| stop_mta () {
and adjust its uses accordingly, which is what I did.
Maybe dash should be changed to warn if ksh-reserved words are
used like this? I don't know. But the sendmail postinst script
should be changed to allow using any bourne/posix compatible
shell to be used as /bin/sh, as per Debian policy.
PS: Don't look too much at the package-specific info below,
I've configured sendmail differently than sendmailconfig wants.
-- Package-specific info:
Ouput of /usr/share/bug/sendmail-bin/script:
ls -alR /etc/mail:
/etc/mail:
total 528
drwxr-sr-x 7 smmta smmsp 1024 2007-05-15 21:02 .
drwxr-xr-x 55 root root 3072 2007-05-15 18:19 ..
-rw-r- 1 root root372 2007-05-11 04:30 access
-rw-r- 1 root root 65536 2007-05-11 04:30 access.db
-rw-r--r-- 1 root root281 2007-05-11 15:39 address.resolve
-rw-r- 1 root root 3937 2007-05-15 04:02 aliases
-rw-r- 1 root root 49152 2007-05-15 04:03 aliases.db
-rw-r--r-- 1 root root 3121 2007-05-15 03:06 databases
-rw-r- 1 root root 1086 2007-05-11 04:30 genericstable
-rw-r- 1 root root 65536 2007-05-11 04:30 genericstable.db
-r--r--r-- 1 root root 5663 2007-05-11 04:30 helpfile
-rw-r--r-- 1 root root 41962 2007-05-11 04:30 localhost.cf
-rw-r- 1 root root456 2007-05-11 04:30 local-host-names
drwxr-sr-x 2 smmta smmsp 512 2007-05-15 02:49 m4
-rw-r- 1 root root664 2007-05-11 04:30 mailertable
-rw-r- 1 root root 65536 2007-05-11 04:31 mailertable.db
drwxr-xr-x 2 root root512 2007-05-15 01:55 peers
-rw-r- 1 root root596 2007-05-11 04:30 relay-domains
drwxr-xr-x 2 root smmsp 512 2007-05-11 15:39 sasl
-rw-r--r-- 1 root root 69884 2007-05-15 04:00 sendmail.cf
-rw-r--r-- 1 root root 11879 2007-05-15 03:20 sendmail.conf
-rw-r--r-- 1 root smmsp 0 2007-05-15 04:07 sendmail.mc
-rw-r- 1 root root113 2007-05-11 04:30 service.switch
-rw-r--r-- 1 root root180 2007-05-11 15:39 service.switch-nodns
-rw--- 1 root root 1024 2007-05-15 21:02 smrandom
drwxr-sr-x 2 smmta smmsp 512 2007-05-15 02:49 smrsh
-rw-r--r-- 1 root root 2227 2007-05-11 04:31 spamd.conf
-rw-r--r-- 1 root root 42481 2007-05-15 21:01 submit.cf
-rw--- 1 root root 1024 2007-05-15 21:02 surandom
drwxr-xr-x 2 smmta smmsp 512 2007-05-15 02:59 tls
-rw-r- 1 root root664 2007-05-11 04:30 trusted-users
-rw-r- 1 root root725 2007-05-11 04:30 virtusertable
-rw-r- 1 root root 65536 2007-05-11 04:31 virtusertable.db
/etc/mail/m4:
total 4
drwxr-sr-x 2 smmta smmsp 512 2007-05-15 02:49 .
drwxr-sr-x 7 smmta smmsp 1024 2007-05-15 21:02 ..
-rw-r- 1 root smmsp0 2007-05-15 02:49 dialup.m4
-rw-r- 1 root smmsp0 2007-05-15 02:49 provider.m4
/etc/mail/peers:
total 6
drwxr-xr-x 2 root root 512 2007-05-15 01:55 .
drwxr-sr-x 7 smmta smmsp 1024 2007-05-15 21:02 ..
-rw-r--r-- 1 root root 328 2007-05-11 15:39 provider
/etc/mail/sasl:
total 4
drwxr-xr-x 2 root smmsp 512 2007-05-11 15:39 .
drwxr-sr-x 7 smmta smmsp 1024 2007-05-15 21:02 ..
/etc/mail/smrsh:
total 4
drwxr-sr-x 2 smmta smmsp 512 2007-05-15 02:49 .
drwxr-sr-x 7 smmta smmsp 1024 2007-05-15 21:02 ..
lrwxr-xr-x 1 root smmsp 26 2007-05-15 02:49 mail.local -
/usr/lib/sm.bin/mail.local
lrwxr-xr-x 1 root smmsp 17 2007-05-15 02:49 procmail - /usr/bin/procmail
/etc/mail/tls:
total 24
drwxr-xr-x 2 smmta smmsp 512 2007-05-15 02:59 .
drwxr-sr-x 7 smmta smmsp 1024 2007-05-15 21:02 ..
-rw-r--r-- 1 root smmsp7 2007-05-15 02:59 no_prompt
-rw--- 1 root smmsp 1191 2007-05-15 02:59 sendmail-client.cfg
-rw-r--r-- 1 root smmsp 1237 2007-05-15 02:59 sendmail-client.crt
-rw--- 1 root smmsp 1017 2007-05-15 02:59 sendmail-client.csr
-rw--- 1 root smmsp 1675 2007-05-15 02:59 sendmail-common.key
-rw--- 1 root smmsp0 2007-05-15 02:59 sendmail-common.prm
-rw--- 1 root smmsp 1191 2007-05-15 02:59 sendmail-server.cfg
-rw-r--r-- 1 root smmsp 1237 2007-05-15 02:59 sendmail-server.crt
-rw--- 1 root smmsp 1017 2007-05-15 02:59 sendmail-server.csr
-rwxr--r-- 1 root root 3154 2007-05-15 03:05 starttls.m4
sendmail.conf:
DAEMON_NETMODE=Dynamic;
DAEMON_NETIF=eth0;
DAEMON_MODE=None;
DAEMON_PARMS=;
DAEMON_HOSTSTATS=No;
DAEMON_MAILSTATS=No;
QUEUE_MODE=Daemon;
QUEUE_INTERVAL=10m;
QUEUE_PARMS=;
MSP_MODE=Cron;
MSP_INTERVAL=20m;
MSP_PARMS=;
MSP_MAILSTATS=${DAEMON_MAILSTATS};
MISC_PARMS=;
CRON_MAILTO=root;
CRON_PARMS=;
LOG_CMDS=No;
Bug#424207: module-init-tools: bashism in portable shell script
Package: module-init-tools Version: 6.2-3 Severity: normal S20module-init-tools uses shopt which is only supported by bash. Either rewrite* the code in question to use only portable shell idioms (preferred), or change the shebang line to #!/bin/bash instead, as per Debian policy that /bin/sh scripts must be portable. *) about the code in question also see my other bug report -- System Information: Debian Release: lenny/sid Architecture: kfreebsd-i386 (i686) Kernel: kFreeBSD 5.4-1-486 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages module-init-tools depends on: ii debconf1.5.13Debian configuration management sy ii kfreebsd-image-5.4-1-486 [ 5.4-21kernel of FreeBSD 5.4 image ii libbsd00.0-1.2+r1710 BSD compatibility library - shared ii libc0.12.5-7 GNU C Library: Shared libraries ii libfreebsd00.0-5 FreeBSD compatibility library - sh module-init-tools recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424232: net-tools: ifconfig -i option missing
Package: net-tools Version: 6.2-3 Severity: minor cosmetic: when doing an ifdown -a, the following message occurs: ifconfig: invalid option -- i usage: ifconfig [-L] [-C] interface address_family [address [dest_address]] [parameters] ifconfig interface create ifconfig -a [-L] [-C] [-d] [-m] [-u] [-v] [address_family] ifconfig -l [-d] [-u] [address_family] ifconfig [-L] [-C] [-d] [-m] [-u] [-v] Either make ifconfig handle -i (what's that supposed to do anyway?) or make ifdown not call ifconfig with -i. -- System Information: Debian Release: lenny/sid Architecture: kfreebsd-i386 (i686) Kernel: kFreeBSD 5.4-1-486 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages net-tools depends on: ii libbsd00.0-1.2+r1710 BSD compatibility library - shared ii libc0.12.5-7 GNU C Library: Shared libraries ii libfreebsd00.0-5 FreeBSD compatibility library - sh ii libipx26.2-1 FreeBSD IPX address conversion sup net-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424208: module-init-tools: use of /usr/bin/{sort,uniq} before /usr is mounted
Marco d'Itri dixit: On May 15, Thorsten Glaser [EMAIL PROTECTED] wrote: Package: module-init-tools Version: 6.2-3 Why do I keep receiving bugs for a kfreebsd-i386 package which I do not maintain? No idea, in this case I suspect there are two different packages with the same name. (I thought they are either the same package, or have different names.) Me disculpe per favore, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428883: bashism in init script fails to start slapd
Package: slapd
Version: 2.3.30-5
Severity: important
Tags: patch
Hi,
I've reported a similar bug to the sendmail-bin postinst script
some time ago, you'll find it at
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424213
for reference and deeper information.
The script defines a shell function stop(), however, all Korn
shells have stop defined as builtin alias (unalias would work,
but in the below patch, I've renamed the stop() function and,
for consistency, the start() function).
Maybe someone should scan all Debian packages for that issue.
I'd be appreciated if you apply the patch in a follow-up release,
as Debian Policy states that scripts beginning with #!/bin/sh must
be portable.
Thanks!
--- /etc/init.d/slapd 2007-06-14 19:50:50.0 +
+++ slapd.new 2007-06-14 21:47:11.0 +
@@ -177,7 +177,7 @@ stop_slurpd() {
}
# Start the OpenLDAP daemons
-start() {
+start_ldap() {
echo -n Starting OpenLDAP:
trap 'report_failure' 0
start_slapd
@@ -187,7 +187,7 @@ start() {
}
# Stop the OpenLDAP daemons
-stop() {
+stop_ldap() {
echo -n Stopping OpenLDAP:
trap 'report_failure' 0
stop_slurpd
@@ -198,12 +198,12 @@ stop() {
case $1 in
start)
- start ;;
+ start_ldap ;;
stop)
- stop ;;
+ stop_ldap ;;
restart|force-reload)
- stop
- start
+ stop_ldap
+ start_ldap
;;
*)
echo Usage: $0 {start|stop|restart|force-reload}
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/mksh
Kernel: Linux 2.6.18-4-k7
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages slapd depends on:
ii adduser 3.102 Add and remove users and groups
ii coreutils 5.97-5.3 The GNU core utilities
ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libdb4.2 4.2.52+dfsg-2 Berkeley v4.2 Database Libraries [
ii libiodbc2 3.52.4-5 iODBC Driver Manager
ii libldap-2.3-0 2.3.30-5 OpenLDAP libraries
ii libltdl3 1.5.22-4 A system independent dlopen wrappe
ii libperl5.85.8.8-7Shared Perl library
ii libsasl2-22.1.22.dfsg1-8 Authentication abstraction library
ii libslp1 1.2.1-6.2 OpenSLP libraries
ii libssl0.9.8 0.9.8c-4 SSL shared libraries
ii libwrap0 7.6.dbs-13 Wietse Venema's TCP wrappers libra
ii perl [libmime-base64-perl 5.8.8-7Larry Wall's Practical Extraction
ii psmisc22.3-1 Utilities that use the proc filesy
Versions of packages slapd recommends:
ii libsasl2-modules 2.1.22.dfsg1-8 Pluggable Authentication Modules f
-- debconf information:
slapd/password_mismatch:
slapd/fix_directory: true
slapd/invalid_config: true
* shared/organization: freewrt.org
slapd/upgrade_slapcat_failure:
slapd/upgrade_slapadd_failure:
slapd/backend: BDB
* slapd/dump_database: when needed
* slapd/allow_ldap_v2: true
slapd/no_configuration: false
slapd/migrate_ldbm_to_bdb: false
slapd/move_old_database: true
slapd/suffix_change: false
slapd/slave_databases_require_updateref:
* slapd/dump_database_destdir: /var/backups/slapd-VERSION
slapd/autoconf_modules: true
slapd/purge_database: false
* slapd/domain: freewrt.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428884: bashism in init script fails to start nscd
Package: nscd
Version: 2.3.6.ds1-8
Severity: important
Tags: patch
Hi,
I've reported a similar bug to the sendmail-bin postinst script
some time ago, you'll find it at
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424213
for reference and deeper information.
The script defines a shell function stop(), however, all Korn
shells have stop defined as builtin alias (unalias would work,
but in the below patch, I've renamed the stop() function and,
for consistency, the start() function).
Maybe someone should scan all Debian packages for that issue.
I'd be appreciated if you apply the patch in a follow-up release,
as Debian Policy states that scripts beginning with #!/bin/sh must
be portable.
Thanks!
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/mksh
Kernel: Linux 2.6.18-4-k7
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages nscd depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
nscd recommends no packages.
--- nscd.orig 2007-06-14 22:07:35.0 +
+++ /etc/init.d/nscd2007-06-14 22:08:07.0 +
@@ -21,7 +21,7 @@ umask 022
[ -x $DAEMON ] || exit 0
[ -d /var/run/nscd ] || mkdir -p /var/run/nscd
-start()
+start_nscd()
{
# Return
# 0 if daemon has been started
@@ -40,7 +40,7 @@ start()
$SECURE || return 2
}
-stop()
+stop_nscd()
{
# Return
# 0 if daemon has been stopped
@@ -68,7 +68,7 @@ status()
case $1 in
start)
echo -n Starting $DESC: $NAME
- start
+ start_nscd
case $? in
0) echo . ; exit 0 ;;
1) echo (already running). ; exit 0 ;;
@@ -77,7 +77,7 @@ start)
;;
stop)
echo -n Stopping $DESC: $NAME
- stop
+ stop_nscd
case $? in
0) echo . ; exit 0 ;;
1) echo (not running). ; exit 0 ;;
@@ -86,11 +86,11 @@ stop)
;;
restart|force-reload|reload)
echo -n Restarting $DESC: $NAME
- stop
+ stop_nscd
$DAEMON --invalidate passwd --invalidate group
case $? in
0|1)
- start
+ start_nscd
case $? in
0) echo . ; exit 0 ;;
1) echo (failed -- old process is still running). ;
exit 1 ;;
Bug#408850: using flags -fwhole-program --combine broken
unblock 408850 by 412070 thanks I'd recommend forwarding this to upstream, it doesn't seem to be Debian or Alpha specific. Unblocking from the Alpha issue and /delurk. I hope someone knowledgeable about gcc and on good terms with the SC can get this fixed. bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428884: bashism in init script fails to start nscd
Pierre Habouzit dixit: exists, so it's definitely a ksh only issue, and is not worth a stable update. The fix will appear in the soon to be uploaded 2.6 packages though. That is okay, as mksh only offers to be used as /bin/sh via debconf in the package currently in unstable, and the other Korn shells don't seem to do it. On the etch system the bug appeared because I symlinked /bin/sh there from hand, I just fixed it from hand too. Thanks for fixing! bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292330: use UTF-8 by default
Hi, wouldn't it be possible to at least make the en_US.UTF-8 locale forcibly generated, so that it can't be deselected by dpkg-reconfigure locales? If this one isn't installed, many apps break when I ssh from an OS that uses exclusively UTF-8 to a Debian box. Thanks! //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292330: use UTF-8 by default
martin f krafft dixit: Why en_US? Why not en_GB? Because how many applications come with en_US data files and how many speak proper English? I know it's sad, but it happens to be like this. If this one isn't installed, many apps break when I ssh from an OS that uses exclusively UTF-8 to a Debian box. etch uses UTF-8 by default. And you can always dpkg-reconfigure. Funnily I cannot if I'm not root. And I've seen etch boxen where en_US.UTF-8 was not installed. //mirabile -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292330: use UTF-8 by default
martin f krafft dixit: also sprach Thorsten Glaser [EMAIL PROTECTED] [2007.06.16.1323 +0100]: Funnily I cannot if I'm not root. And I've seen etch boxen where en_US.UTF-8 was not installed. Then please bug the admin. That's what I did, but the idea is not to have to do that. (Besides, C is installed by default, so we need some kind of C.UTF-8, whose role is – for LC_CTYPE – usually fulfilled by en_US.UTF-8.) //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#292330: use UTF-8 by default
martin f krafft dixit: Please stop CCing debian-project. I don't. Does a C.UTF-8 exist? If yes, then this is a sound proposal, I think. If not, one could probably easily create one. It would have to have all properties of C except for LC_CTYPE, which it would have to take from en_US.UTF-8. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292330: use UTF-8 by default
Roger Leigh dixit: Does a C.UTF-8 exist? If yes, then this is a sound proposal, I think. I believe that the C locale is supposed to be US_ASCII only. That applies to “C” but not to a hypothetical “C.UTF-8” locale, which would have to be set via setlocale(3) anyway, and differ from “C” only in “LC_CTYPE” category. //mirabile -- “Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL.” -- Henry Nelson, March 1999
Bug#421171: mksh: depends on removed libssp0 package
Sven Joachim dixit: Package: mksh Version: 29.2-1 Severity: grave Your package depends on libssp0 which is no longer present in the latest gcc-4.1 upload (4.1.2-4). Why is that library gone and/or how is ProPolice SSP in gcc 4.1+ then supposed to work without it? If the __guard_setup() and __stack_smash_handler() functions are now contained in libc, a simple recompile is in fact enough. bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421518: FTBFS (alpha): conflicting types for 'stat'
block 421518 by 408850
thanks
Falk Hueffner dixit:
/usr/include/sys/stat.h:208: error: conflicting types for 'stat'
/usr/include/sys/stat.h:435: error: previous definition of 'stat' was here
[...]
Full log at
http://buildd.debian.org/fetch.cgi?pkg=mkshver=29.2-1arch=alphastamp=1177564924file=log
Yes, I know. This bug seems to only trigger on alpha, maybe because of some
alignment contraints or something – I really don't have any idea… – and thus
I can't find a workaround for it. (If you want to be nice to me, get an alpha
and try the diff below; I don't really want to have my sponsor upload another
package if it's not really working around the alpha bug.)
I can only suspect the bug is triggered by use of -std=gnu99 (the restrict
keyword makes the difference, which doesn't exist in c89), but not on all
architectures, but, on the other hand, the bug is actually in machine in-
dependent code and a bug in the libc headers.
--- mksh-29.2/debian/rules.orig 2007-04-29 20:59:31.0 +
+++ mksh-29.2/debian/rules 2007-04-29 20:59:35.0 +
@@ -19,7 +19,7 @@ BUILD_ENV:=
BUILD_ENV+=CC='${CC}'
BUILD_ENV+=CFLAGS='${CFLAGS}'
# possibly work around PR#408850
-#BUILD_ENV+= HAVE_CAN_STDG99=0
+BUILD_ENV+=HAVE_CAN_STDG99=0
build: build-stamp
Caveat: this is just a (possible) work-around, not a fix. But if it turns
out to indeed make mksh buildable on alpha again, I'll have an upgraded
mksh package uploaded.
bye,
//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
Bug#421518: mksh build problems
unblock 421518 by 408850 reassign 408850 gcc retitle 408850 using flags -fwhole-program --combine broken thanks Hi all, thanks to Steve Langasek I now know that the “conflicting prototypes” issues for the mksh package appear due to use of the gcc flags “-fwhole-program --combine” which, supposedly, have gcc treat it as one single translation unit and optimise better. I suspect that this doesn't handle redeclaration well; it seems to be a gcc bug. Interestingly enough, the very same flags cause problems when using the FORTIFY_SOURCE definitions on SuSE (and I think Fedora) – it fails on a line saying something like “if (read(fd, buf, size) 0)” with a bunch of weird error messages; Pascal Bleser, whom I've added to the Cc: of this eMail can surely provide them to you if that's desired. (Thanks to Marcus “darix” Rückert for helping to track this down as well.) I have taken these facts as arguments against using the flags at all and changed upstream mksh to not test for and use them at all any more. A new mksh minor release (R29d) was put out; I'll have my sponsor upload the upgraded debian package shortly. This means: unblock 421518 by 408850, since it no longer depends on the fix (so that 421518 can be closed by an upgraded package), change 408850 to be a gcc bug now that we, thanks to vorlon, know the case. bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#292330: use UTF-8 by default
Mike Hommey dixit: it's not. We could create a neutral.utf-8 locale for sure Sounds like a plan. Maybe something short and uppercase, akin to C and POSIX, how about STD.UTF-8? but a C.utf-8 is really bad, because some programs check the locale for 'C' and when they foind that use hand optimized functions to replace the localized libc ones. Ugh. Really? Nah, please spare me the details. Note that you won't get strings split in the middle of a point code with UTF-8. This is possible with UTF-8. Try this one: ł (U+0142) = C5 82 You can split between the C5 and the 82. Anyways, maybe the general problem is that there should be a way to generate locales at the user level (and store everything in ~/.locale, for example) That'd be a nice additional idea, but it makes additional problems too, for example quotas, or when do these get updated, or that duplication is always bad. That would probably be a glibc issue then. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#430455: openssh-server: sshd in unstable not executable any longer, seems to be a shared library
Package: openssh-server
Version: 1:4.6p1-1
Severity: grave
Justification: renders package unusable
After upgrading to latest unstable today, I couldn't start
sshd any longer. Find below a typescript showing the issues:
[EMAIL PROTECTED]:~/tmp # /usr/sbin/sshd
/usr/sbin/sshd[1]: syntax error: '(' unexpected
1|[EMAIL PROTECTED]:~/tmp # #=== not a problem of the shell:
1|[EMAIL PROTECTED]:~/tmp # dash -c /usr/sbin/sshd
/usr/sbin/sshd[1]: syntax error: '(' unexpected
1|[EMAIL PROTECTED]:~/tmp # bash -c /usr/sbin/sshd
bash: /usr/sbin/sshd: cannot execute binary file
126|[EMAIL PROTECTED]:~/tmp # uname -a
GNU/kFreeBSD debian.mirbsd.org 7.0-1-686 #0 Sat May 6 14:43:46 CEST 2006 i686
i386 QEMU Virtual CPU version 0.7.2 GNU/kFreeBSD
[EMAIL PROTECTED]:~/tmp # #=== this seems to be the root of the problem:
[EMAIL PROTECTED]:~/tmp # file /usr/sbin/sshd
/usr/sbin/sshd: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD),
for GNU/kFreeBSD 5.4.0, stripped
[EMAIL PROTECTED]:~/tmp # #=== now compare with a normal programme:
[EMAIL PROTECTED]:~/tmp # file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for
GNU/kFreeBSD 5.4.0, dynamically linked (uses shared libs), stripped
[EMAIL PROTECTED]:~/tmp # #=== WTF is this a shared library, not an executable?
[EMAIL PROTECTED]:~/tmp # #=== the problem seems to appear on linux too:
[EMAIL PROTECTED]:~/tmp # wget
http://ftp.debian.org/debian/pool/main/o/openssh/openssh-server_4.6p1-2_i386.deb
--18:04:28--
http://ftp.debian.org/debian/pool/main/o/openssh/openssh-server_4.6p1-2_i386.deb
= `openssh-server_4.6p1-2_i386.deb'
Resolving ftp.debian.org... 128.101.240.212
Connecting to ftp.debian.org|128.101.240.212|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 243,496 (238K) [application/x-debian-package]
100%[] 243,496 188.60K/s
18:04:32 (88.38 KB/s) - `openssh-server_4.6p1-2_i386.deb' saved [243496/243496]
[EMAIL PROTECTED]:~/tmp # ar x openssh-server_4.6p1-2_i386.deb data.tar.gz
[EMAIL PROTECTED]:~/tmp # tar xzf data.tar.gz
[EMAIL PROTECTED]:~/tmp # file ./usr/sbin/sshd
./usr/sbin/sshd: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.6.1, stripped
Not only does this problem affect linux-i386 as well (and
not only kfreebsd-i386), but also at least the openssh-client
subpackage (file shows /usr/bin/ssh is also a shared object).
As you can see, it's also independent of the shell and appears
in the latest package on the server too.
I have no idea why it's no longer built as ELF executable,
nor how to fix it, but I can't run ssh, either as client or
as server, at the moment.
-- System Information:
Debian Release: lenny/sid
Architecture: kfreebsd-i386 (i686)
Kernel: kFreeBSD 7.0-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/mksh
Versions of packages openssh-server depends on:
ii adduser 3.103 Add and remove users and groups
ii debconf [debc 1.5.13 Debian configuration management sy
ii dpkg 1.14.4 package maintenance system for Deb
ii libc0.1 2.5-11 GNU C Library: Shared libraries
ii libcomerr21.38+1.39-WIP-2005.12.31-1 common error description library
ii libkrb53 1.4.4-8MIT Kerberos runtime libraries
ii libpam-module 0.79-3.1+kbsd Pluggable Authentication Modules f
ii libpam-runtim 0.79-4 Runtime support for the PAM librar
ii libpam0g 0.79-3.1+kbsd Pluggable Authentication Modules l
ii libssl0.9.8 0.9.8e-5 SSL shared libraries
ii libwrap0 7.6.dbs-13 Wietse Venema's TCP wrappers libra
ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip
ii openssh-clien 1:4.6p1-1 secure shell client, an rlogin/rsh
ii zlib1g1:1.2.3-15 compression library - runtime
openssh-server recommends no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340219: #340219 - /bin/which: calls printf which may not be available if /usr is not mounted
Package: debianutils
Version: 2.21
Followup-For: Bug #340219
While I'm in favour of #428189 too (you by the way forgot to mention
that, if printf is moved to /bin, we need a /usr/bin/printf symlink
to not break POSIX or existing scripts), there's a way to solve this
issue for Korn shells, which all have a “print” builtin, which is, in
contrast to “echo”, portable.
(Some Korn shells, at least pdksh and derivates, also have “whence -p”
that does the same as “which” does, but without support for -a, and if
the programme does not exist, n̲o̲ error message is printed, so I've not
attached a patch to make use of “whence -p”.)
Below patch introduces a shell function to output a one-line string,
depending on ‘$KSH_VERSION’ which is set for almost all Korn shells
(except maybe ksh88 which probably isn't suitable for Debian anyway).
If other shells don't have a printf builtin, the issue is NOT solved
for them with this patch (but would be with #428189). On the other
hand, even if #428189 were to be accepted, I'd still apply this patch
because it goes deeper to the root of the problem.
--- /bin/which 2007-06-11 14:36:51.0 +
+++ which.new 2007-06-24 13:51:13.0 +
@@ -1,13 +1,23 @@
#! /bin/sh
set -ef
+if test -n $KSH_VERSION; then
+ puts() {
+ print -r -- $*
+ }
+else
+ puts() {
+ printf '%s\n' $*
+ }
+fi
+
ALLMATCHES=0
while getopts a whichopts
do
case $whichopts in
a) ALLMATCHES=1 ;;
-?) printf Usage: %s [-a] args\n $0 ; exit 2 ;;
+?) puts Usage: $0 [-a] args; exit 2 ;;
esac
done
shift $(($OPTIND - 1))
@@ -28,7 +38,7 @@ for PROGRAM in $@; do
case $PROGRAM in
*/*)
if [ -f $PROGRAM ] [ -x $PROGRAM ]; then
-printf '%s\n' $PROGRAM
+puts $PROGRAM
RET=0
fi
;;
@@ -38,7 +48,7 @@ for PROGRAM in $@; do
ELEMENT=.
fi
if [ -f $ELEMENT/$PROGRAM ] [ -x $ELEMENT/$PROGRAM ]; then
- printf '%s\n' $ELEMENT/$PROGRAM
+ puts $ELEMENT/$PROGRAM
RET=0
[ $ALLMATCHES -eq 1 ] || break
fi
-- System Information:
Debian Release: lenny/sid
Architecture: kfreebsd-i386 (i686)
Kernel: kFreeBSD 5.4-1-486
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh
Versions of packages debianutils depends on:
ii libc0.1 2.5-10 GNU C Library: Shared libraries
debianutils recommends no packages.
-- no debconf information
Bug#430455: sshd in unstable not executable any longer, seems to be a shared library
Okay, I've found out more about the cause: sshd is compiled as PIE (position independent executable), but only Linux, NetBSD and MirBSD can execute them; FreeBSD, OpenBSD and DragonflyBSD cannot. (The DragonFly gcc ignores -pie because it knows that its kernel can't execute them anyway.) So the most “polite” solution to the problem would be to only build ssh with -pie if the kernel is Linux or kNetBSD. On the other hand, feel free to reassign the bug to the kfreebsd architecture maintainers, they might want to do something about either having gcc ignore the flag or fixing the kernel to execute PIEs. (Can't be so hard, since I seem to have added it to the MirBSD kernel _by accident_ while fixing something else… maybe I'll dig out the change and port it to Debian GNU/kFreeBSD.) bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#430455: sshd in unstable not executable any longer, seems to be a shared library
Aurelien Jarno dixit: Thorsten Glaser a C)crit : Could you give us more details? Sure, these are however also in the PR. What problem do you get with this binary? It's not executable. Which architecture are you kfreebsd-i386 And which kernel are you using? Both 5.4 and 7.0 show the bug. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430455: sshd in unstable not executable any longer, seems to be a shared library
close 430455 thanks Aurelien Jarno dixit: An upgrade to a 6.1 kernel may fix the bug. It did. So the bug is closed for openssh. How about, we either nuke the 5.4 and 7.0 kernels, or fix them too, so that no other user will experience this problem? bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430455: openssh PIEs, part II
Hi Colin, sorry I didn't know that the close command is deprecated. As for the PIEs, kFreeBSD 6.x kernel has gained a patch to support executing PIEs some time ago (since I only tested 5.4 and 7.0 I had not known that, plus I'm not exactly a heavy Debian user...), and they backported the fix to the 5.x kernel series (the 7.0 series are, according to the developers, experimental, and outdated). So there is no need on your part to not build PIEs on kFreeBSD any more. (I wonder what the benefit of a PIE is, do you happen to have a pointer to some docs/manual on it? I know (now) in theory what a PIE is, but don't see the point.) Sorry for the trouble. bye, //mirabile -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317785: typo in description
Tomas Pospisek dixit: in the description s/si- milar/similar/ Are we not allowed to wrap the text then? I will fix it with the next release which is due soon. Thanks, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490092: Lots of warnings in GForge
Package: gforge-common Version: 4.5.14-22etch2 X-Debbugs-CC: [EMAIL PROTECTED] GForge (I did not exactly know which subpackage, so I filed against gforge-common) produces a huge lot of warnings, so that our log files get pretty large: -rw-r- 1 root adm 2136984104 2008-07-09 21:15 /var/log/apache2/error.log -rw-r- 1 root adm 115545018 2008-07-06 07:30 /var/log/apache2/error.log.1.gz # gzip -l /var/log/apache2/error.log.1.gz compresseduncompressed ratio uncompressed_name 115545018 3505956420 96.7% /var/log/apache2/error.log.1 Most of these warnings are of the following kinds (only one per kind, that's why I have stripped actual numbers): - PHP Notice: Undefined index: number in /usr/share/gforge/www/include/trove.php on line number - PHP Notice: Undefined index: string in /usr/share/gforge/www/include/trove.php on line number - PHP Notice: Uninitialized string offset: number in /usr/share/gforge/www/include/trove.php on line number - PHP Notice: Only variables should be assigned by reference in /usr/share/gforge/www/include/BaseLanguage.class on line number - PHP Notice: Undefined variable: name in /usr/share/gforge/www/softwaremap/trove_list.php on line number - PHP Notice: Undefined offset: number in /usr/share/gforge/www/softwaremap/trove_list.php on line number The following ones could probably be fixed by checking if these are defined: - PHP Notice: Undefined index: HTTPS in /usr/share/gforge/common/include/session.php on line number - PHP Notice: Undefined variable: HTTP_ACCEPT_LANGUAGE in /usr/share/gforge/www/include/pre.php on line number There may be more, I just collected a few. Please fix these, as they are filling up the logs too rapidly, and may introduce issues. Thanks! //Th. Glaser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477587: [PATCH] Re: Bug#477587: Bug#477588: kfreebsd-{6,7}: bashism in debian/rules
tags 477587 + patch
tags 477588 + patch
thanks
FWIW, both “bashisms” work with mksh ☺
Untested diff below:
Index: kfreebsd-6/debian/rules
===
--- kfreebsd-6/debian/rules (revision 2166)
+++ kfreebsd-6/debian/rules (working copy)
@@ -2,8 +2,6 @@
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.
-SHELL = bash
-
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
@@ -28,15 +26,14 @@
HEADERS_DIR:= kfreebsd-headers-$(version)-$(abiname)
FLAVOR_DIR := flavor-$(version)-$(abiname)
-MAKE := make MACHINE_ARCH=$(cpu) CC=gcc-3.4 WERROR=
+MAKE := make MACHINE_ARCH=$(cpu) CC=gcc-3.4 WERROR=
PATH := $(CURDIR)/config:/usr/lib/freebsd:$(PATH)
control: clean
sed -e s/@major@/$(major)/g -e s/@version@/$(version)/g -e
s/@abiname@/$(abiname)/g -e s/@flavor@/$$flavor/g \
$(CURDIR)/debian/control.in $(CURDIR)/debian/control
for arch in `ls $(CURDIR)/debian/arch/` ; do \
- for config in `ls $(CURDIR)/debian/arch/$$arch/ | grep
\.config` ; do \
- flavor=$${config/.config/} ; \
+ for flavor in $$(echo $(CURDIR)/debian/arch/$$arch/*.config* |
sed 's/\.config//'); do \
test -f $(CURDIR)/debian/arch/$$arch/$$flavor.defines
recommends=`awk '/^Recommends: / {print $$2}'
$(CURDIR)/debian/arch/$$arch/$$flavor.defines` ; \
sed -e s/@major@/$(major)/g -e
s/@version@/$(version)/g -e s/@abiname@/$(abiname)/g -e
s/@flavor@/$$flavor/g -e s/@arch@/$$arch/g -e
s/@recommends@/$$recommends/g \
$(CURDIR)/debian/control.flavor.in
$(CURDIR)/debian/control ; \
@@ -55,7 +52,7 @@
src: src-stamp
src-stamp:
tar xfj $(CURDIR)/src.tar.bz2
-
+
set -e ; find src -type d -name CVS | xargs rm -rf
set -e ; find src -type f | (while read i ; do \
@@ -71,7 +68,7 @@
-e 's,#\( \|\t\)*include\(
\|\t\)*\(\|\)bpfilter.h\(\|\),,g' \
-e 's,#\( \|\t\)*include\( \|\t\)*\(\|\)pflog.h\(\|\),,g' \
; done)
-
+
set -e ; cd $(CURDIR)/src ; QUILT_PC=$(CURDIR)/.pc
QUILT_PATCHES=$(CURDIR)/debian/patches quilt push -a ; cd $(CURDIR)
install debian/gen-ld-u-options src/usr.sbin/config
@@ -81,7 +78,7 @@
build-indep: build-indep-stamp
build-indep-stamp: src
dh_testdir
-
+
cp -af src $(SRC_DIR)
touch build-indep-stamp
@@ -112,7 +109,7 @@
build-arch: $(foreach flavor,$(flavours),build-flavor-$(flavor)-stamp)
build-flavor-%-stamp: src config
cp -af src $(FLAVOR_DIR)-$*
-
+
# Add the abiname and the flavor to the kernel version
sed -i -e 's/^RELEASE=.*/RELEASE=$(version)-$(abiname)-$*/g'
$(FLAVOR_DIR)-$*/sys/conf/newvers.sh
@@ -132,11 +129,11 @@
touch build-flavor-$*-stamp
install-common-stamp: src
- dh_testdir
+ dh_testdir
dh_testroot
mkdir -p $(HEADERS_PACKAGE)/usr/src/$(HEADERS_DIR)
cd src \
-find . -type f -name *.h -not -regex .*modules.* -not
-regex .*sys/$(cpu)/.* -exec cp --parents {}
$(HEADERS_PACKAGE)/usr/src/$(HEADERS_DIR) \;
+find . -type f -name *.h -not -regex .*modules.* -not
-regex .*sys/$(cpu)/.* -exec cp --parents {}
$(HEADERS_PACKAGE)/usr/src/$(HEADERS_DIR) \;
find $(HEADERS_PACKAGE)/usr/src/$(HEADERS_DIR) -type f -exec chmod 644
{} \;
touch install-common-stamp
@@ -147,7 +144,8 @@
dh_testroot
dh_clean -k -pkfreebsd-image-$(version)-$(abiname)-$*
- mkdir -p $(IMAGE_PACKAGE)-$*/{boot,lib/modules/$(version)-$(abiname)-$*}
+ mkdir -p $(IMAGE_PACKAGE)-$*/boot \
+ $(IMAGE_PACKAGE)-$*/lib/modules/$(version)-$(abiname)-$*
# make the install target happy
install -o root -g root -m 644 \
@@ -160,7 +158,7 @@
install -o root -g root -m 644 \
$(FLAVOR_DIR)-$*/sys/boot/forth/loader.conf \
$(IMAGE_PACKAGE)-$*/boot/defaults/loader.conf
-
+
# now install the kernel
$(MAKE) -C $(FLAVOR_DIR)-$*/sys/$(cpu)/compile/$(configfile)
DESTDIR=$(IMAGE_PACKAGE)-$* install
mv $(IMAGE_PACKAGE)-$*/lib/modules/$(version)-$(abiname)-$*/kernel
$(IMAGE_PACKAGE)-$*/boot/kfreebsd-$(version)-$(abiname)-$*
@@ -179,7 +177,7 @@
# remove device.hints (built into kernel)
rm -f $(IMAGE_PACKAGE)-$*/boot/device.hints
-
+
# override file
mkdir -p $(IMAGE_PACKAGE)-$*/usr/share/lintian/overrides
install -p -o root -g root -m 644 \
@@ -194,13 +192,13 @@
# scripts
sed -e s/@RELEASE@/$(version)-$(abiname)-$*/g
debian/kfreebsd-image.postinst.in \
debian/kfreebsd-image-$(version)-$(abiname)-$*.postinst
-
+
# headers package
mkdir -p
Bug#264285: ksh not interpreting PS1 variable
Hi,
the behaviour you describe is normal for any Korn shell, since the idioms
you are trying to use are GNU bash extensions.
Instead of
export PS1='\033[0;[EMAIL PROTECTED] \033[0;33m\w\033[0;39m
$ '
you should use this (the lines 2 and 3 have a tab and a space inside the []):
: ${HOSTNAME:=$(ulimit -c 0;hostname -s 2-)}
[[ $HOSTNAME = @(localhost|*([ ])) ]] HOSTNAME=$(ulimit -c 0;hostname 2-)
[[ $HOSTNAME = @(localhost|*([ ])) ]] HOSTNAME=noname
export PS1='
[0;[EMAIL PROTECTED] [0;33m$PWD[0;39m
$ '
If your mail programme mungles these lines, here's a long version:
: ${HOSTNAME:=$(ulimit -c 0;hostname -s 2-)}
[[ $HOSTNAME = @(localhost|*([ ])) ]] HOSTNAME=$(ulimit -c 0;hostname 2-)
[[ $HOSTNAME = @(localhost|*([ ])) ]] HOSTNAME=noname
nl='
'
ca=$(print \\001)
cm=$(print \\r)
esc=$(print \\033)
export PS1=$ca$cm$ca$esc[0;[EMAIL PROTECTED]
$ca$esc[0;33m$ca\$PWD$ca$esc[0;39m$ca$nl\$
unset nl ca cm esc
Have fun!
bye,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469675: mksh - what to do about /bin/sh alternatives?
Package: mksh Version: 33.1-2 Severity: minor Tags: goal-dash, moreinfo Owner: [EMAIL PROTECTED] Hello! I just saw the following: # Switch /bin/sh to dash Advocate: Petter Reinholdtsen? Release-Team-Contact: ?? Description: Make sure dash is installed and preseed debconf question. Fix bashisms. Bug-User: [EMAIL PROTECTED] Bug-Tag: goal-dash Bug-Url: http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]tag=goal-dash State: confirmed A couple of shells (including mksh) still have a mechanism to be used as /bin/sh and there was no consensus about how to handle this when I looked last time. Please give me more information about how to change it to meet the release goals of Lenny – i.e., whether the ability to use a shell other than dash as /bin/sh is to be removed (from debconf, not by changing the link manually), or the debconf questions and scripts need to be adjusted. Thanks! //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#523671: still broken
Apparently, it has not been fixed with later runs: $ lynx -dump http://packages.qa.debian.org/m/mksh.html […] Overview of [4]mksh source package General information Latest version 37.3-2 Maintainer [5]Thorsten Glaser [6][email] Maintenance[7]DMUA Conforms to[8]3.8.1 […] Todo * The package should be updated to follow the last version of [29]Debian Policy (Standards-Version 3.8.0 instead of 3.8.1). Latest news [30]RSS * [2009-04-19] [31]mksh 37.3-2 MIGRATED to testing (Britney) […] [84]Debian Package Tracking System - Copyright 2002-2009 Raphal Hertzog and others. Report problems to the [85]qa.debian.org pseudopackage in the [86]Debian BTS. Last modified: Mon Apr 27 00:49:09 UTC 2009. [87]Valid XHTML 1.0 Strict -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548744: mksh: exit status of non-interactive file-not-found
Dixi quod: (as stdin replacement) More on this: t...@frozenfish:~ $ mksh t...@frozenfish:~ $ true x; echo $? mksh: cannot open x: No such file or directory 1 t...@frozenfish:~ $ ^D t...@frozenfish:~ $ bash t...@frozenfish:~$ true x; echo $? bash: x: No such file or directory 1 t...@frozenfish:~$ exit t...@frozenfish:~ $ PS1='$ ' zsh $ true x; echo $? zsh: no such file or directory: x 1 $ t...@frozenfish:~ $ ksh93 t...@frozenfish:...home/tg $ true x; echo $? ksh93: x: cannot open [No such file or directory] 1 t...@frozenfish:/home/tg $ t...@frozenfish:~ $ PS1='$ ' dash $ true x; echo $? dash: cannot open x: No such file 2 $ t...@frozenfish:~ $ PS1='$ ' dash x; echo $? dash: Can't open x 2 t...@frozenfish:~ $ PS1='$ ' dash -c x; echo $? dash: x: not found 127 bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548744: mksh: exit status of non-interactive file-not-found
Clint Adams dixit: % mksh /tmp/horsies ; echo $? /tmp/horsies: /tmp/horsies: No such file or directory 1 t...@herc:~ $ mksh /tmp/horsies; print $? /tmp/horsies: /tmp/horsies: No such file or directory 1 t...@herc:~ $ mksh -c /tmp/horsies; print $? mksh: /tmp/horsies: not found 127 According to SUSv3, the exit code should be 127: 127 A specified command_file could not be found by a non-interactive shell. I tend to disagree. While GNU bash, ATT ksh93 and zsh do the same thing for both, neither does dash, nor can I find (quickly) something in SUSv3 which says anything about the return code when the input file (as stdin replacement) cannot be opened. The case you bring forward is *not* a command_file. Geoff, can you shed some light on this? Is there, by chance, an eMail address (mailing list, maybe) where people can ask such questions on SUSv3 and shell behaviour? I'm adding you because you helped out so well last time when we had the $@ vs set -u issue. 10x, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548744: mksh: exit status of non-interactive file-not-found
Geoff Clare dixit: Clint is right. Look at the synopsis for sh: Okay, the HTML versions I had were not easy to search. Then I’ll fix that in mksh, and Clint should file it with dash too. The Austin Group mailing list is open to anyone to join. See www.opengroup.org/austin/lists.html Thanks! By the way, the base specifications (XBD, XSH, XCU, XRAT) of SUSv3 were superseded by the SUSv4 equivalents about a year ago. You can access the HTML version of the new specifications via www.opengroup.org/bookstore/catalog/c082.htm Very useful, greatly appreciated. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548744: mksh: exit status of non-interactive file-not-found
Geoff Clare dixit: So the 127 exit is required for sh /tmp/horsies if /tmp/horsies could not be found. Heh. The source code even *tried* to DTRT, setting exstat to 127, but the errorf() function doing the actual abortion set it to 1… fixed. //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541535: as: i8086 Intel syntax far jumps broken
found 541535 binutils/2.19.91.20090927-1 thanks Still there… //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549179: mksh: Stop on error when reading directory as script
tags 549179 wontfix severity 549179 wishlist thanks Jari Aalto dixit: mkdir tmp mksh tmp = No error messages, no status code $? to signify an error. t...@herc:~ $ cat tmp; echo $? 0 t...@herc:~ $ mksh tmp; echo $? 0 This is consistent with the rest of the operating system, ans as such not a bug, unless SUSv4 were to specifiy otherwise. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#445651: Conditional operator evaluates both arguments
Hi, I had a good laugh reading the recent posh changelog entries. Thanks for the appreciation of my patches, I wasn’t even aware of it ;) In fact, you might want to take a lot more bugfixes out of it; run our testsuite over it to see them (although it does test for a lot more things, feature enhancements as well). I’d like you however to notice in the source tarball (and pos- sibly debian/copyright) that the bugfixes were taken from mksh with permission. (If you take anything else, I’d like to have the full licence text retained however.) After reading through the arith-* tests, I’d agree that this is a bug. The test case (simplified, remove the +) works on: x=1 y=$((1 ? 20 : x=2)) This is an error because ?: binds stronger than = even in C, see http://www.mirbsd.org/man7/operator for reference. The working version would be: x=1 y=$((1 ? 20 : (x=2))) If we now change the sides, they should be exactly the same, as per C at least. The ATT Korn Shell agrees with us there: t...@frozenfish:~ $ ksh93 -c 'x=1; y=$((0 ? (x=2) : 20)); echo $x' 1 t...@frozenfish:~ $ mksh -c 'x=1; y=$((0 ? (x=2) : 20)); echo $x' 1 t...@frozenfish:~ $ ksh93 -c 'x=1; y=$((0 ? x=2 : 20)); echo $x' 1 t...@frozenfish:~ $ mksh -c 'x=1; y=$((0 ? x=2 : 20)); echo $x' 2 Clint, I don’t know if you have read the wlog entry http://www.mirbsd.org/permalinks/wlog-10_e20090707-tg-g10031.htm but if you’d like to co-operate with me on posh/mksh development, you’re welcome. I could certainly need someone else familiar with the code to look over my patches, at the very least. (Even if we may disagree with which ones to apply and which not to.) Another thing I could do is to make a check.pl category 'posh' or so, so that we can share the testsuite. I’ll have a look at it sometime. bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592093: actually, no…
22:37⎜mika:#grml this is so win² for FAI :) 22:38⎜mika:#grml because if thomas finally learns git we finally get a chance for its usage for FAI in the ⎜long run :) 22:38⎜lynx:#grml oh no… 22:39⎜* lynx:#grml should write git2cvs 22:39⎜gebi:#grml lynx: git-cvsserver? Besides, upon adopting you may move to a VCS of your choice, of course… bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606091: python2.6: please disable profiled bootstrap on m68k
Source: python2.6 Version: 2.6.6-7 Severity: normal Hi, please disable the profiled bootstrap of Python (any version, really) on m68k. The process running the testsuite for the profile feedback generation hangs at 0% CPU (and 0.00 load), and I had to kill it to make the compilation continue. (Benchmarking can thankfully be disabled in DEB_BUILD_OPTIONS, which was needed to get it to compile at all…) Thanks! -- System Information: Debian Release: squeeze/sid Architecture: m68k Kernel: Linux 2.6.32-5+m68k.3-atari Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh-static Versions of packages python2.6 depends on: ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co ii libc62.11.2-7+m68k.1 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2~m68k+1 Berkeley v4.8 Database Libraries [ ii libexpat12.0.1-7 XML parsing C library - runtime li ii libncursesw5 5.7+20100313-4 shared libraries for terminal hand ii libreadline6 6.1-3+b1GNU readline and history libraries ii libsqlite3-0 3.7.3-1 SQLite 3 shared library ii mime-support 3.51-1 MIME files 'mime.types' 'mailcap ii python2.6-minimal2.6.6-6+b1 A minimal subset of the Python lan python2.6 recommends no packages. Versions of packages python2.6 suggests: ii binutils 2.20.1-15 The GNU assembler, linker and bina pn python2.6-doc none (no description available) pn python2.6-profilernone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589469: mc paste with mouse
Gosh, just hold Shift while pasting, run mc with -d or inside GNU screen with disabled mouse support. I suggest this be closed. bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606821: mksh: bash-style process substitution
Jonathan Nieder dixit: This construct is also handy when one wants to update the current environment downstream from some other process. process | while IFS= read -pr line; do … done ↑ is the proper ksh idiom for that. ( ... )- runs ... in a subshell in the background, with its output connected to a pipe. Ah, interesting. I would have thought it ran the stuff first, wrote it to a temporary file and then passed that to the other process, sort of like a dynamic here document, from when I first read about it. (Didn’t know (…) existed.) On Linux and similar OSes this is typically implemented using /proc/fd. A more portable implementation would use FIFOs. I don’t know whether this works on all mksh target OSes, but that can surely be investigated. What do you think? Is it worth implementing in mksh? (…) is already on the wishlist – if you want to submit a patch, you’re welcome ;-) it should work on DEC ULTRIX 4.5, DEC OSF/1 V2.0, Minix 3, Haiku, Cygwin, UWIN, etc. though, and, if possible, Plan 9. ☺ A side note, I’d like to track upstream feature requests *not* inside the Debian BTS. We usually use the MirBSD mailing list for that, although there’s now a Launchpad project associated with mksh which can be used if desired. bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532810: update needed on /ports/m68k webpage
Francesca Ciceri dixit: w.r.t. the recent effort to revive the port and the progress about it). I’ll write on that later. Just FYI that I saw it and will RSVP. bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608247: dpkg-architecture is slow
Raphael Hertzog dixit: with concrete optimizations, a bug report saying it's slow is useless. I never meant this as bug report, just a sort of heads-up. If it is unfixable, unless things are rewritten in non-Perl, that’s the way it is. But still, I see a lot of slowness when building packages on m68k that is probably overlooked elsewhere; things where packages’ binary-arch makefile-depends on an excessive binary-indep (is this a bug? if so, I’ll report against git), dh5/dh7/cdbs relative slow- ness (and other home-brewn build systems which are even worse), etc. Thorsten, can you generate the profiling data on your machine so that we have a better idea of how it runs for you? Sure. It’s a VM though, so someone with real hardware might be able to provide “better” data. perl -d:Profile /usr/bin/dpkg-architecture I’m running this in “eatmydata cowbuilder --login” after updating the chroot now. This host system (3 GHz Athlon) is faster though, so I get an emulated 233 MHz 68040 instead of the 60 MHz one from a 1 GHz Athlon the initial one ran on. Raphaël Hertzog ◈ Debian Developer Nice Unicode ☺ bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 prof.out.gz Description: Binary data
Bug#532810: update needed on /ports/m68k webpage
Francesca Ciceri dixit: Debian currently runs on the 68020, 68030, 68040 and 68060 processors. Current Debian releases support Atari, Amiga, VMEbus, and some Macintosh systems. I’d keep the “Debian currently runs” but state that this is not in a released version and hasn’t been for a while, but that people are working on it and help be welcome. Then, replace “Current Debian releases support” with “Currently, the Debian/m68k port supports”. I’ll leave the text supplication to others, however this one would be nice to have ;-) Index: index.wml === RCS file: /cvsroot/webwml/webwml/english/ports/m68k/index.wml,v retrieving revision 1.26 diff -u -p -r1.26 index.wml --- index.wml 11 Oct 2008 12:45:07 - 1.26 +++ index.wml 29 Dec 2010 16:21:15 - @@ -92,6 +92,15 @@ system for Debian 3.1 and above) to the Together with Stephen Marenka, ported debian-installer (the installation system for Debian 3.1 and above) to the m68k architecture. +dtThorsten Glaser +dd +Collected patches from Debian/m68k maintainers, Linux/m68k developers, and +other people; brought Debian/m68k through the transition from linuxthreads +to NPTL with TLS by integrating those into the Debian packages and being +the human equivalent of a buildd for long enough to bootstrap sid again. +Finn Thain, Andreas Schwab and Geert Uytterhoeven provided valuable input +to this, besides those already mentioned above. + /dl w.r.t. the recent effort to revive the port and the progress about it). I’ve put up, on my people.d.o home directory, a tarball of a freshly made /var/cache/pbuilder/base.cow (which can also be used as a chroot of Debian unstable on any Linux/m68k machine, or rather as starting point for that) and plan to upgrade it every once in a while, for some time. I also intend to prepare an upgraded VM image and upload that. The current VM image is based on a much older unstable but works just fine as starting point (given a new kernel and the chroot), and is documented on: https://wiki.debian.org/Aranym/Quick (thanks, Stephen). I wrote about cowbuilder and the chroot on the Debian Wiki, too: https://wiki.debian.org/M68k/Cowbuilder (contains a download link) We currently have two pressing issues (res_init() segfaults, and gcj, possibly boehm-gc, fails out in sem_wait) but most packages can be compiled again (with cowbuilder; since buildd needs eMail and sendmail calls res_init, I haven’t made any further progress in setting up a buildd, but others here run one and can probably just throw away their current sid chroot, extract mine, put up a TLS capable kernel, and be done, as long as the unreleased repo is (currently) included in the in-chroot sources.list). I fudged some build-deps (mostly X stuff) to compile packages since I’ll *not* recompile x.org by hand; manual de- pendency resolution is… quite an intense job. The two issues were written about in: ‣ http://lists.debian.org/debian-glibc/2010/11/msg00077.html ‣ http://lists.debian.org/debian-68k/2010/12/msg0.html bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: mit XFree86® wär’ das nicht passiert - muhaha 15:48⎜thkoehler:#grml also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜novoid:#grml thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders… -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608247: dpkg-architecture is slow
Raphael Hertzog dixit: But he provides patches from time to time so I have some hopes that it means he's interested to look into the issue. :-) Indeed ☺ It seems really that perl is just slow on your setup. Yes, I thought so. Maybe the calls to the various dpkg-* and dh* tools could use cache files to save having to evaluate the same thing over and over again, generally? (Yes, lots of work – just a random idea.) bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608247: dpkg-architecture is slow
Guillem Jover dixit: Your initial time showed 7s, but the profile shows only 2s, maybe No, as I said, those are different machines (as I had already shut down the slower VM). bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499002: Intent to NMU for v1.7.4-rc0
Jonathan Nieder dixit: save time on autobuilders. Ah, I see it was already reported. Thanks, this should speed up m68k builds a lot ☺ I wonder though, why is the BUILD_DOCS, install-indep-real, etc. necessary, shouldn’t dpkg-buildpackage just call binary-arch and that be it? bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608476: kwalletcli: should add alternative for ssh-askpass and provide ssh-askpass
block 608476 by 603910 thanks Daniel Schaal dixit: kwalletcli should use the debian alternative system for kwalletaskpass and provide ssh-askpass. Do you think so? Okay, will do in time. Thanks for the patch! bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (241 (259) bugs: 0 RC, 172 (187) IN, 69 (82) MW, 0 FP) ‣ src:dash (74 (82) bugs: 3 (4) RC, 51 (57) IN, 20 (21) MW, 0 FP) ‣ src:mksh (4 bugs: 0 RC, 0 IN, 4 MW, 0 FP) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499002: [PATCH git] debian: do not build documentation on buildds (Re: Intent to NMU for v1.7.4-rc0)
Jonathan Nieder dixit:
Background:
[…]
Thanks. Right, I remember not reading anything about
binary-{indep,arch} being mandated, only binary… damn.
And about make not being able to show whether a target
exists… well, I think this is also making dh7 slow.
Good to know / get a refresher.
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532810: update needed on /ports/m68k webpage
Francesca Ciceri dixit: @@ -5,7 +5,9 @@ pThe Motorola 680x0 series of processors have powered personal computers and workstations since the mid-1980s. Debian currently runs -on the 68020, 68030, 68040 and 68060 processors. +on the 68020, 68030, 68040 and 68060 processors: this is an unofficial port +meaning that there's not an official and released m68k port but this port is +under development./p pPlease note that a a href=http://foldoc.org/foldoc.cgi?query=memory+management+unit; I’d add “… and released m68k port _any more_” here, since it used to be and people hope it will eventually become one. @@ -20,10 +22,31 @@ h2Status/h2 pThe Debian m68k port was first officially released with Debian 2.0 -(hamm)./p +(hamm) and was an official port until Debian 4.0 (etch). There's now an effort +to revive this port./p -pCurrent Debian releases support Atari, Amiga, VMEbus, and some Macintosh -systems./p +pCurrently, the Debian/m68k port supports Atari, Amiga, VMEbus, and some +Macintosh systems./p lgtm +pFor now, the m68k team is facing two pressing issues a +href=http://lists.debian.org/debian-glibc/2010/11/msg00077.html;ttres_init()/tt +segfaults/a and a Yes, no feedback on that from either 68k or eglibc yet, but I’ll try to look deeper into it and/or prod more people when getting back from VAC (possibly starting today). +href=http://lists.debian.org/debian-68k/2010/12/msg0.html;gcj, possibly +boehm-gc, fails out in ttsem_wait/tt/a, but Working on it, new eglibc is compiling, thanks _again_ to Andreas Schwab. Maybe it helps, maybe it isn’t. I think we shouldn’t hardcode such things on the main website but refer to something like the as-of-yet not created https://wiki.debian.org/M68k/Status instead. +p +Thorsten Glaser has created a +href=http://people.debian.org/~tg;a tarball/a of a freshly made http://people.debian.org/~tg/f/m68k/ I had that linked from https://wiki.debian.org/M68k/Cowbuilder which you mentioned, but maybe not visibly enough. (I’m not really good at structuring documentation, admittedly.) +tt/var/cache/pbuilder/base.cow/tt (which can also be used as a chroot +of Debian unstable on any Linux/m68k machine, or as starting point for that) … machine with a TLS capable kernel, … +and he plan to upgrade it quite regularly. At least for some time. I don’t promise I stick with m68k for long, but it peeked my interest, and I’m learning a lot. Rest looks good too. Thanks, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516774: klibc 1.5.21-1 and mksh
tags 516774 = patch
tags 516294 = upstream
thanks
Hi!
Please find attached a diff closing #516774 by adding mkstemp(3),
again with a minimalistic pseudo-arc4random(3) behind it. I’ve
revisited the code. An mkstemp testsuite from the ’net shows it
works, except for not caring how many ‘X’en are in the template.
Addressing #516294, it allows compiling and linking an mksh from
today’s CVS against it:
tg@tg-sidvm:~/b $ CPPFLAGS=-DMKSH_NO_LIMITS CC=klcc dash ../mksh/Build.sh -r
However, the signal problem persists:
tg@tg-sidvm:~/b $ ./mksh -c 'print hi'
hi
tg@tg-sidvm:~/b $ ./mksh -c 'ls'
Rebuild.sh eval.o expr.o histrap.o lalloc.o main.o mksh signames.inc
test.sh var.o
edit.o exec.o funcs.o jobs.o lex.o misc.o shf.o syn.o
tree.o
^C^\
130|tg@tg-sidvm:~/b $
This basically means: builtins can run fine, external programmes
never return (Haiku used to have the same problem, they fixed a
signal delivery related kernel bug of theirs to solve it; Syllable
Desktop and Plan 9 still have this problem).
Some more details (add -g to Build.sh to get a debugging executable):
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/tg/b/mksh...done.
Attaching to program: /home/tg/b/mksh, process 18642
0x08072b76 in __syscall_common ()
(gdb) bt
#0 0x08072b76 in __syscall_common ()
#1 0x0048 in ?? ()
#2 0x08060aac in j_waitj (j=0x0, flags=value optimized out, where=0x413
Address 0x413 out of bounds)
at ../mksh/jobs.c:987
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) info r
eax0xfdfe -514
ecx0x4131043
edx0x8075b17134699799
ebx0x807dd48134733128
esp0xbfcf9618 0xbfcf9618
ebp0xbfcf9688 0xbfcf9688
esi0xbfcf9650 -1076914608
edi0xb770e0e4 -1217339164
eip0x8072b760x8072b76 __syscall_common+26
eflags 0x246[ PF ZF IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x0 0
The part of the source:
987 sigsuspend(sm_default);
As I already stated, an 1.5.15 patched with C99, getrusage,
arc4random and mkstemp used to work, so a regression was
introduced later. (I had hoped for 1.5.21 to work, as maks’
blog posting said something about signal fixes.) However,
I can no longer get one of the older klibc to build on a
newer Debian unstable due to kernel headers related changes,
so bisecting is almost impossible (for me, that is).
I would greatly appreciate if someone could look at the
second issue and, addressing the first, accept the patch
adding mkstemp() as a feature.
Thanks in advance,
//mirabilos
--
15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-)diff -Nru klibc-1.5.21/debian/changelog klibc-1.5.21/debian/changelog
--- klibc-1.5.21/debian/changelog 2011-01-25 22:47:03.0 +
+++ klibc-1.5.21/debian/changelog 2011-01-28 12:59:52.0 +
@@ -1,3 +1,12 @@
+klibc (1.5.21-1+tg.1) unstable; urgency=low
+
+ * debian/patches/add-{arc4random,mkstemp}: add a minimalistic
+implementation of the arc4random() API on top of jrand48(3)
+to have a self-seeding PRNG; add simple mkstemp(3) implemen-
+tation using it. (Closes: #516774)
+
+ -- Thorsten Glaser t...@mirbsd.de Fri, 28 Jan 2011 12:59:06 +
+
klibc (1.5.21-1) unstable; urgency=low
* New upstream release (i386 signal(), make 3.82, cleanups)
diff -Nru klibc-1.5.21/debian/patches/add-arc4random
klibc-1.5.21/debian/patches/add-arc4random
--- klibc-1.5.21/debian/patches/add-arc4random 1970-01-01 00:00:00.0
+
+++ klibc-1.5.21/debian/patches/add-arc4random 2011-01-28 12:54:21.0
+
@@ -0,0 +1,206 @@
+* Include a helper function needed by add-mkstemp
+ implementing a minimal arc4random(3) API on top
+ of jrand48; self-seeding when /proc is mounted.
+
+ Entropy sources:
+ - 36 bytes from /proc/sys/kernel/random/uuid
+ - position of temp. buffer on stack (randomised on recent kernels)
+
+ Additional variation (non-random) via:
+ - PID of last stir call
+ - PID of current stir call
+ - count of arc4random() calls since last stir
+ - time of current stir call
+ - size of user-provided data
+ - position of arc4random_addrandom() argument on stack
+ - filedescriptor of /proc/sys/kernel/random/uuid
+ - count of bytes read from /proc/sys/kernel/random/uuid
+
+ After stirring, it's good
Bug#601126: eglibc: [m68k] please apply patch for TLS support
Hi,
another (updated) version of the patch, changelog collapsed and a
“Closes” tag added; hotfix sync’d from git repository.
Builds on amd64… m68k takes a few days longer ☺
bye,
//mirabilos
--
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success 22:21⎜mksh it’s a
very thin line anyway… with some, you don’t know which side they’re ondiff -u eglibc-2.11.2/debian/changelog eglibc-2.11.2/debian/changelog
--- eglibc-2.11.2/debian/changelog
+++ eglibc-2.11.2/debian/changelog
@@ -1,3 +1,14 @@
+eglibc (2.11.2-10+m68k.1) unreleased; urgency=low
+
+ * patches/m68k/cvs-fix-sem_t-alignment.patch: new from git (hotfix)
+ * sysdeps/m68k.mk: switch m68k to TLS (Closes: #601126)
+- remove libc_extra_config_options (all of them, we have __thread
+ and TLS now; sanity checks were only disabled for linuxthreads)
+- use NPTL instead of linuxthreads
+ * debhelper.in/libc.preinst: require (Debian) 2.6.32 kernel on m68k
+
+ -- Thorsten Glaser t...@mirbsd.de Sat, 29 Jan 2011 00:37:03 +0100
+
eglibc (2.11.2-10) unstable; urgency=low
* Add patches/amd64/cvs-avx-tcb-alignment.diff from upstream to fix
diff -u eglibc-2.11.2/debian/debhelper.in/libc.preinst
eglibc-2.11.2/debian/debhelper.in/libc.preinst
--- eglibc-2.11.2/debian/debhelper.in/libc.preinst
+++ eglibc-2.11.2/debian/debhelper.in/libc.preinst
@@ -292,33 +292,22 @@
mips*) realarch=mips;;
esac
- # The GNU libc requires a = 2.6.18 kernel (except on m68k)
+ # The GNU libc requires a = 2.6.32-3 Debian kernel on m68k
+ # for TLS, or a = 2.6.18 kernel on all other architectures
if [ $realarch != m68k ]
then
- if linux_compare_versions $kernel_ver lt 2.6.18
- then
- echo WARNING: this version of the GNU libc requires kernel
version
- echo 2.6.18 or later. Please upgrade your kernel before
installing
- echo glibc.
- kernel26_help
-
- exit 1
- fi
+ vmin=2.6.18
+ else
+ vmin=2.6.32
fi
-
- # The GNU libc is now built with --with-kernel= = 2.4.1 on m68k
- if [ $realarch = m68k ]
+ if linux_compare_versions $kernel_ver lt ${vmin}
then
- if linux_compare_versions $kernel_ver lt 2.4.1
- then
- echo WARNING: This version of glibc requires that you be running
- echo kernel version 2.4.1 or later. Earlier kernels contained
- echo bugs that may render the system unusable if a modern version
- echo of glibc is installed.
- kernel26_help
+ echo WARNING: this version of the GNU libc requires kernel version
+ echo ${vmin} or later. Please upgrade your kernel before installing
+ echo glibc.
+ kernel26_help
- exit 1
- fi
+ exit 1
fi
# From glibc 2.6-3 SPARC V8 support is dropped.
diff -u eglibc-2.11.2/debian/sysdeps/m68k.mk
eglibc-2.11.2/debian/sysdeps/m68k.mk
--- eglibc-2.11.2/debian/sysdeps/m68k.mk
+++ eglibc-2.11.2/debian/sysdeps/m68k.mk
@@ -2,2 +2 @@
-libc_add-ons = ports linuxthreads $(add-ons)
-libc_extra_config_options = $(extra_config_options) --disable-sanity-checks
--without-__thread --without-tls
+libc_add-ons = ports nptl $(add-ons)
diff -u eglibc-2.11.2/debian/patches/series eglibc-2.11.2/debian/patches/series
--- eglibc-2.11.2/debian/patches/series
+++ eglibc-2.11.2/debian/patches/series
@@ -152,6 +152,7 @@
m68k/cvs-define-m68k-tls-relocations.patch
m68k/cvs-tls-support.patch
+m68k/cvs-fix-sem_t-alignment.patch
m68k/cvs-versions-def-2-12.patch
m68k/local-compat.diff
m68k/local-dwarf2-buildfix.diff
only in patch2:
unchanged:
--- eglibc-2.11.2.orig/debian/patches/m68k/cvs-fix-sem_t-alignment.patch
+++ eglibc-2.11.2/debian/patches/m68k/cvs-fix-sem_t-alignment.patch
@@ -0,0 +1,65 @@
+This series of m68k related commits fixes alignment of sem_t due to
+the kernel using the lower two bit for internal purposes, whereas on
+Linux/m68k, the alignment of long is not natural. I refrain from
+patching a ChangeLog file, since I saw this break with gcc earlier.
+ -- tg@d.o
+
+From: Andreas Schwab sch...@linux-m68k.org
+Date: Sun, 2 Jan 2011 19:14:41 + (+0100)
+Subject: m68k: force alignment of sem_t
+X-Git-Tag: glibc-2.13~7
+X-Git-Url:
http://sourceware.org/git/?p=glibc-ports.git;a=commitdiff_plain;h=9524dbd1f3f91a9b381bb0e17dc5e150fe8be75a
+
+m68k: force alignment of sem_t
+---
+
+#diff --git a/ChangeLog.m68k b/ChangeLog.m68k
+#index ccd8b4e..feba28e 100644
+#--- a/ChangeLog.m68k
+#+++ b/ChangeLog.m68k
+#@@ -1,3 +1,8 @@
+#+2011-01-10 Andreas Schwab sch...@linux-m68k.org
+#+
+#+ * sysdeps/unix/sysv/linux/m68k/nptl/bits/semaphore.h (sem_t):
+#+ Force alignment.
+#+
+# 2010-12-26 Andreas Schwab sch...@linux-m68k.org
+#
+# * sysdeps/m68k/stackinfo.h
Bug#334917: [PATCH] Re: klibc barfs on m68k syscall interface
tag 334917 = patch
thanks
Hi,
I’ve fixed the m68k syscall of klibc and made it able to use
six-argument syscalls like mmap2. However, I could not yet
fully test it (only mostly; opendir() specifically fails) due
to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533
@m68k porters: Please have a look at the gcc bug as well.
@klibc: Please apply the patch, it’s better than what we have,
and (@packagers) with a binNMU it can be fixed once gcc works.
bye,
//mirabilos
--
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success 22:21⎜mksh it’s a
very thin line anyway… with some, you don’t know which side they’re ondiff -Nru klibc-1.5.21/debian/changelog klibc-1.5.21/debian/changelog
--- klibc-1.5.21/debian/changelog 2011-01-29 12:48:07.0 +0100
+++ klibc-1.5.21/debian/changelog 2011-01-29 15:48:04.0 +0100
@@ -1,3 +1,10 @@
+klibc (1.5.21-1+tg.2) unstable; urgency=low
+
+ * debian/patches/fix-m68k-syscalls: rewrite m68k syscall ABI
+to fix it (Closes: #334917) and support 6-argument syscalls.
+
+ -- Thorsten Glaser t...@mirbsd.de Sat, 29 Jan 2011 15:48:02 +0100
+
klibc (1.5.21-1+tg.1) unstable; urgency=low
* debian/patches/add-{arc4random,mkstemp}: add a minimalistic
diff -Nru klibc-1.5.21/debian/patches/fix-m68k-syscalls
klibc-1.5.21/debian/patches/fix-m68k-syscalls
--- klibc-1.5.21/debian/patches/fix-m68k-syscalls 1970-01-01
01:00:00.0 +0100
+++ klibc-1.5.21/debian/patches/fix-m68k-syscalls 2011-01-29
15:47:18.0 +0100
@@ -0,0 +1,99 @@
+* Fix #334917 by rewriting the syscall API
+* Document this has been tested
+
+Index: klibc-1.5.21/usr/klibc/arch/m68k/syscall.S
+===
+--- klibc-1.5.21.orig/usr/klibc/arch/m68k/syscall.S2011-01-29
13:28:39.0 +0100
klibc-1.5.21/usr/klibc/arch/m68k/syscall.S 2011-01-29 15:47:09.0
+0100
+@@ -11,17 +11,47 @@
+ .globl __syscall_common
+ .type __syscall_common, @function
+ __syscall_common:
+- movem.l %d2-%d6, -(%sp) /* 5 registers saved */
+- movem.l 24(%sp), %d1-%d6
++#if 0
++ /* debugging: define int32_t last_syscall; in your code... */
++ move.l %d0, (last_syscall) /* to see which is actually run */
++#endif
++ /*
++ * According to eglibc, separate moves are faster than movem;
++ * speed is important and this code is not duplicated anyway,
++ * so we do the same here. We use %a1 as scratch register for
++ * saving; syscall arguments are to be in %d1 to %d5 and %a0.
++ */
++ move.l 24(%sp), %a0/* orig.sp+24: arg 6 */
++ move.l %d5, -(%sp) /* push d5 (callee saved) */
++ move.l 24(%sp), %d5/* orig.sp+20: arg 5 */
++ move.l %d4, -(%sp) /* push d4 (callee saved) */
++ move.l 24(%sp), %d4/* orig.sp+16: arg 4 */
++ move.l %d3, -(%sp) /* push d3 (callee saved) */
++ move.l 24(%sp), %d3/* orig.sp+12: arg 3 */
++ move.l %d2, %a1/* save d2 (callee saved) in a1 */
++ move.l 20(%sp), %d2/* orig.sp+8: arg 2 */
++ move.l 16(%sp), %d1/* orig.sp+4: arg 1 */
+ trap#0
+- cmpi.l #-4095, %d0
+- blt.l 1f
++ move.l %a1, %d2/* restore d2 from a1 (scratch) */
++ move.l (%sp)+, %d3 /* pop d3..d5, see above */
++ move.l (%sp)+, %d4
++ move.l (%sp)+, %d5
++
++ /* syscall is done, result in %d0, registers are restored */
++ .globl __syscall_checkandout
++__syscall_checkandout:
++ /* now check for error */
++ cmp.l #-4095, %d0
++ bcs.l 1f /* jmp short if _not_ error */
++
++ /* prepare for error return */
+ neg.l %d0
+ move.l %d0, (errno)
+- moveq #-1, %d0
+-1:
+- movea.l %d0, %a0/* Redundant return */
+- movem.l (%sp)+, %d2-%d6 /* Restore registers */
++ move.l #-1, %d0
++ /* fallthrough to common return path */
++
++1:/* copy return value to %a0 for syscalls returning pointers */
++ move.l %d0, %a0
+ rts
+
+ .size __syscall_common,.-__syscall_common
+Index: klibc-1.5.21/usr/klibc/README.klibc
+===
+--- klibc-1.5.21.orig/usr/klibc/README.klibc 2011-01-29 14:49:53.0
+0100
klibc-1.5.21/usr/klibc/README.klibc2011-01-29 14:53:57.0
+0100
+@@ -44,7 +44,7 @@
+i386: Working
+ia64: Working static, shared untested
+m32r: Untested
+- m68k: Untested
++ m68k: Working
+m68knommu: Not yet ported
+mips: Working
+mips64: Not yet ported
+Index: klibc-1.5.21/usr/klibc/arch/m68k/vfork.S
Bug#334917: [PATCH] Re: klibc barfs on m68k syscall interface
maximilian attems dixit: well ok thanks for the effort, but please really do use git. Ah okay. I worked against the Debian package, because that is what I can test and install. The klibc git repo is at http://git.kernel.org/?p=libs/klibc/klibc.git;a=summary git clone it and work away. Will do. ++#if 0 ++ /* debugging: define int32_t last_syscall; in your code... */ ++ move.l %d0, (last_syscall) /* to see which is actually run */ ++#endif please no no ugly ifdefs. OK. I used that one to see whether the correct syscalls were run for mmap and select, but don’t really need it any more. Will drop. sorry but impossible to review as a patch in a patch, please use format-patch. Yes, I see. I don't take arch specific patches in Debian unless there is no way around, so please repost the patches considering aboves critiques. Noted. Thanks for the response anyway. bye, //mirabilos -- 22:20⎜asarch The crazy that persists in his craziness becomes a master 22:21⎜asarch And the distance between the craziness and geniality is only measured by the success 22:21⎜mksh it’s a very thin line anyway… with some, you don’t know which side they’re on -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532810: update needed on /ports/m68k webpage
Francesca Ciceri dixit: I've dropped the 'current issues' part and not mentioned the not-yet-created wiki.d.o/M68k/Status page: we could add this info when the page will be created. I’ve created it now and filled it with content; one of the issues has already been fixed by Andreas Schwab (thanks again), and we have some lead on the other. https://wiki.debian.org/M68k/Status bye, //mirabilos -- 22:20⎜asarch The crazy that persists in his craziness becomes a master 22:21⎜asarch And the distance between the craziness and geniality is only measured by the success 22:21⎜mksh it’s a very thin line anyway… with some, you don’t know which side they’re on -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516294: On the trail of sigsuspend(2)
SIGSUSPEND(2) Linux Programmer's Manual SIGSUSPEND(2)
NAME
sigsuspend - wait for a signal
SYNOPSIS
#include signal.h
int sigsuspend(const sigset_t *mask);
… and …
SIGSUSPEND(2) BSD Programmer's Manual SIGSUSPEND(2)
NAME
sigsuspend - atomically release blocked signals and wait for interrupt
SYNOPSIS
#include signal.h
int
sigsuspend(const sigset_t *sigmask);
… but …
root@ara2:~ # cat t.c
#include stdio.h
#include signal.h
int main(void) {
printf(%zu\n, sizeof(sigset_t));
return (0);
}
root@ara2:~ # klcc -o tklibc t.c; gcc -o tglibc t.c; ./tklibc; ./tglibc
4
128
No wonder mksh no longer works… any idea _why_, _where_, and how to fix?
Thanks in advance,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516294: On the trail of sigsuspend(2)
Dixi quod… root@ara2:~ # klcc -o tklibc t.c; gcc -o tglibc t.c; ./tklibc; ./tglibc 4 128 Hm. Apparently, it’s not that, because klibc appears to use the old-style functions and old_sigset_t is a long, so okay. (And no, it’s not related to that commit, 1.5.20 was broken too.) strace ./mksh -c lsshows: sigsuspend([INT ILL USR1 USR2 ALRM CHLD CONT STOP WINCH] Funnily enough, strace /bin/mksh -c ls says: rt_sigsuspend([]) = ? ERESTARTNOHAND (To be restarted) Now, from what I can gather from the manpages (this signal stuff is not my code and way past me by now, especially considering the time of day), sigprocmask() fills in sm_default which is used as sigsuspend() argument in the only place it’s called. Still, one has to wonder whether it’s related to this: - ticket: http://dev.haiku-os.org/ticket/5567 - commit: http://dev.haiku-os.org/changeset/35836 The symptoms are the same. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611691: ruby1.9.1: FTBFS on m68k: gc.c:2134: error: too few arguments to function 'mark_locations_array'
Source: ruby1.9.1
Version: 1.9.2.0-2
Severity: important
Justification: fails to build from source
Hi,
log attached. Note ruby1.8 built just fine, and ruby1.9 used
to build on m68k but not ruby1.9.1 (it got TLS and eglibc in
the meantime, though).
2111 static void
2112 mark_current_machine_context(rb_objspace_t *objspace, rb_thread_t *th)
2113 {
2114 rb_jmp_buf save_regs_gc_mark;
2115 VALUE *stack_start, *stack_end;
2116
2117 FLUSH_REGISTER_WINDOWS;
2118 /* This assumes that all registers are saved into the jmp_buf (and
stack) */
2119 rb_setjmp(save_regs_gc_mark);
2120
2121 SET_STACK_END;
2122 GET_STACK_BOUNDS(stack_start, stack_end, 1);
2123
2124 mark_locations_array(objspace,
2125 (VALUE*)save_regs_gc_mark,
2126 sizeof(save_regs_gc_mark) / sizeof(VALUE));
2127
2128 rb_gc_mark_locations(stack_start, stack_end);
2129 #ifdef __ia64
2130 rb_gc_mark_locations(th-machine_register_stack_start,
th-machine_register_stack_end);
2131 #endif
2132 #if defined(__mc68000__)
2133 mark_locations_array((VALUE*)((char*)STACK_END + 2),
2134 (STACK_START - STACK_END));
2135 #endif
2136 }
In the same file:
1310 static void
1311 mark_locations_array(rb_objspace_t *objspace, register VALUE *x,
register long n)
1312 {
1313 VALUE v;
1314 while (n--) {
1315 v = *x;
1316 VALGRIND_MAKE_MEM_DEFINED(v, sizeof(v));
1317 if (is_pointer_to_heap(objspace, (void *)v)) {
1318 gc_mark(objspace, v, 0);
1319 }
1320 x++;
1321 }
1322 }
Full build log attached.
-- System Information:
Debian Release: 6.0
Architecture: m68k
Kernel: Linux 2.6.32-5+m68k.5-atari
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh-static
- Copying COW directory
forking: rm -rf /var/cache/pbuilder/build//cow.4890
forking: cp -al /var/cache/pbuilder/base.cow
/var/cache/pbuilder/build//cow.4890
I: removed stale ilistfile /var/cache/pbuilder/build//cow.4890/.ilist
forking: chroot /var/cache/pbuilder/build//cow.4890 cowdancer-ilistcreate
/.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a
-links +1 -print0 \) | xargs -0 stat --format '%d %i '
- Invoking pbuilder
forking: pbuilder build --debbuildopts -B --debbuildopts -m'$DEBEMAIL'
--hookdir /root/pb-hook --binary-arch --buildplace
/var/cache/pbuilder/build//cow.4890 --buildresult /var/cache/pbuilder/result/
--debbuildopts -m'$DEBEMAIL' --no-targz --internal-chrootexec chroot
/var/cache/pbuilder/build//cow.4890 cow-shell /root/ruby1.9.1_1.9.2.0-2.dsc
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: using fakeroot in build.
I: Current time: Mon Jan 31 21:40:45 UTC 2011
I: pbuilder-time-stamp: 1296510045
I: copying local configuration
I: mounting /proc filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
W: no hooks of type D found -- ignoring
- Attempting to satisfy build-dependencies
- Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: m68k
Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (= 5), cdbs, quilt, patch, autoconf, m4, bison,
libgdbm-dev, libncurses5-dev, libreadline5-dev, tcl8.4-dev, tk8.4-dev,
zlib1g-dev, libssl-dev, procps, file, libffi-dev, ruby1.8, libyaml-dev
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in
`/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously deselected package pbuilder-satisfydepends-dummy.
(Reading database ... 10470 files and directories currently installed.)
Unpacking pbuilder-satisfydepends-dummy (from
.../pbuilder-satisfydepends-dummy.deb) ...
dpkg: dependency problems prevent configuration of
pbuilder-satisfydepends-dummy:
pbuilder-satisfydepends-dummy depends on debhelper (= 5); however:
Package debhelper is not installed.
pbuilder-satisfydepends-dummy depends on cdbs; however:
Package cdbs is not installed.
pbuilder-satisfydepends-dummy depends on quilt; however:
Package quilt is not installed.
pbuilder-satisfydepends-dummy depends on autoconf; however:
Package autoconf is not installed.
pbuilder-satisfydepends-dummy depends on m4; however:
Package m4 is not installed.
pbuilder-satisfydepends-dummy depends on bison; however:
Package bison is not installed.
pbuilder-satisfydepends-dummy depends on libgdbm-dev; however:
Package libgdbm-dev is not installed.
Bug#196367: priority dependencies and alternatives
Hi, with the latest developer news I saw mksh was listed. However, mksh needs to have dependencies on debconf ($foo) | cdebconf ($bar) in two flavours – one is added so lintian doesn’t complain due to mi- nimum version requirements for certain features, the other is added via misc:Depends from debhelper. Now, cdebconf has priority extra. Do I need to do something to my package, and if so, what? Downgrading all packages with an alternative dependency on cdebconf doesn’t seem sensible to me, so the language might need to change. bye, //mirabilos -- 15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#196367: priority dependencies and alternatives
Russ Allbery dixit: that clearly, but I'm quite confident that's the intention. Yes, thought so. However I was surprised to see it pop up in the list, and perhaps other packages are similarly affected, maybe not even this visible. So what now? Does ftpteam read here or do I contact them, and point out a likely mistake in their script? Or does the wording need a change first? bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611768: binutils: [m68k] please apply relocation fix from upstream
Source: binutils
Version: 2.20.1-16
Hi,
please apply the patch from Andreas Schwab to binutils:
http://sourceware.org/ml/binutils/2011-02/msg8.html
This is supposed to fix a problem where a simple programme just
calling res_init() on m68k segfaults due to invalid memory access
apparently due to broken reloaction.
I’ve cited part of the mailing list thread below for reference.
Thanks in advance,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
-- Forwarded message --
From: Thorsten Glaser t...@mirbsd.de
Message-ID: pine.bsm.4.64l.1101302028040.30...@herc.mirbsd.org
To: debian-...@lists.debian.org
Date: Sun, 30 Jan 2011 20:31:44 + (UTC)
Subject: Re: [m68k] res_init segfault, need help debugging
Dixi quod…
ara2:~# cat x.c
#include netinet/in.h
#include arpa/nameser.h
#include resolv.h
int
main(void)
{
return (res_init());
}
ara2:~# gcc x.c
ara2:~# ./a.out
Segmentation fault
Basically, the segfault is on accessing _res.retrans
in line 67 (first access of _res)
Now, _res is at 0xc014ce58 and the code in question is:
0xc00f1eb4 __res_init: linkw %fp,#0
0xc00f1eb8 __res_init+4: moveml %d2-%d5/%a2/%a5,%sp@-
0xc00f1ebc __res_init+8: lea %pc@(0xc0148000),%a5
0xc00f1ec4 __res_init+16: movel %a5,%d5
0xc00f1ec6 __res_init+18: addil #9916,%d5
0xc00f1ecc __res_init+24: movel %d5,%sp@-
0xc00f1ece __res_init+26: movel %d5,%sp@
0xc00f1ed0 __res_init+28: bsrl 0xc0040aa0 __tls_get_addr@plt
0xc00f1ed6 __res_init+34: addql #4,%sp
= 0xc00f1ed8 __res_init+36: moveal %a0@,%a2
0xc00f1eda __res_init+38: tstl %a2@
0xc00f1edc __res_init+40: bnes 0xc00f1ee2 __res_init+46
0xc00f1ede __res_init+42: moveq #5,%d0
0xc00f1ee0 __res_init+44: movel %d0,%a2@
0xc00f1ee2 __res_init+46: tstl %a2@(4)
0xc00f1ee6 __res_init+50: bnes 0xc00f1eee __res_init+58
0xc00f1ee8 __res_init+52: moveq #4,%d1
0xc00f1eea __res_init+54: movel %d1,%a2@(4)
0xc00f1eee __res_init+58: btst #0,%a2@(11)
0xc00f1ef4 __res_init+64: bnes 0xc00f1f5a __res_init+166
The access happens with:
a0 0xc0021be1 0xc0021be1
a2 0x0 0x0
If I read that right, it’s the equivalent of: mov a2,dword ptr [a0]
So, question, why does that access out-of-bounds memory? This is
apparently introduced with TLS support.
(gdb) info sharedlibrary
FromTo Syms Read Shared Object Library
0xc00021d8 0xc00148b0 Yes /lib/ld.so.1
0xc0040adc 0xc011ba62 Yes /lib/libc.so.6
According to info target there’s nothing there:
[…]
0xc001d05c - 0xc001d120 is .bss in /lib/ld.so.1
0xc0022174 - 0xc0022198 is .note.gnu.build-id in /lib/libc.so.6
[…]
bye,
//mirabilos
--
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success 22:21⎜mksh it’s a
very thin line anyway… with some, you don’t know which side they’re on
-- Forwarded message --
From: Andreas Schwab sch...@linux-m68k.org
Message-ID: m2r5br4l2p@igel.home
Cc: debian-...@lists.debian.org
Date: Tue, 01 Feb 2011 20:21:50 +0100
Subject: Re: [m68k] res_init segfault, need help debugging
It's a linker bug, see
http://sourceware.org/ml/binutils/2011-02/msg8.html.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540512: dash: dash upgrade breaks mksh-as-/bin/sh
Hi, for additional consideration of any solution: the current binary pak- kage “mksh” comes with two shells “mksh” and “mksh-static”, and both are suitable for use as /bin/sh (mksh-static even more so on ports like m68k where the reduced startup time is noticeable). So any solution should not use a binary package’s name as only key. (It was recently re-suggested I split mksh, but back when I first made the source package, waldi said binary packages are too expen- sive a ressource, so it was decided against. Unless there is demand for the split and an okay from ftpteam. Also, mksh-static is cur- rently using dietlibc if available, eglibc otherwise; I prefer to use klibc once it works though, so there will be three possibilities in the future – four might, if we get µClibc.) bye, //mirabilos -- 22:20⎜asarch The crazy that persists in his craziness becomes a master 22:21⎜asarch And the distance between the craziness and geniality is only measured by the success 22:21⎜mksh it’s a very thin line anyway… with some, you don’t know which side they’re on -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611768: [m68k] res_init segfault, need help debugging
Andreas Schwab dixit: It's a linker bug, see http://sourceware.org/ml/binutils/2011-02/msg8.html. I can confirm the fix. root@ara2:~ # ./resinit; print $?; LD_LIBRARY_PATH=/var/cache/pbuilder/build/cow.11168/tmp/buildd/eglibc-2.11.2/build-tree/m68k-libc ./resinit; print $? Segmentation fault 139 0 This is rebuilding eglibc after installing a patched binutils. Thanks again, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611926: eglibc compiles extremely huge binary-indep parts on buildds
Source: eglibc Version: 2.11.2-11 Hi, when building eglibc with --debbuildopts -B --binary-arch, after taking a day or so for locales-all ☺ it still creates a source archive in build-tree/eglibc-2.11.2.tar.xz which I think is for the eglibc-source arch:all deb. This creates unnecessary burden on all buildds, especially the slower architectures (think security buildds, too). Please separate the build-arch and build-indep parts. Thanks in advance, //mirabilos -- 22:20⎜asarch The crazy that persists in his craziness becomes a master 22:21⎜asarch And the distance between the craziness and geniality is only measured by the success 22:21⎜mksh it’s a very thin line anyway… with some, you don’t know which side they’re on -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601126: updated patch
Hi,
updated patch. Builds fine, my segfault’s gone too thanks to the
binutils change, and I unearthed another bug we can close. (That
is not in the package I just uploaded, but other than the debian
changelog, nothing differs.)
bye,
//mirabilos
--
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success 22:21⎜mksh it’s a
very thin line anyway… with some, you don’t know which side they’re ondiff -u eglibc-2.11.2/debian/changelog eglibc-2.11.2/debian/changelog
--- eglibc-2.11.2/debian/changelog
+++ eglibc-2.11.2/debian/changelog
@@ -1,3 +1,14 @@
+eglibc (2.11.2-11+m68k.1) unreleased; urgency=low
+
+ * patches/m68k/cvs-fix-sem_t-alignment.patch: new from git (hotfix)
+ * sysdeps/m68k.mk: enable TLS (Closes: #601126) (Closes: #446503)
+- remove libc_extra_config_options (all of them, we have __thread
+ and TLS now; sanity checks were only disabled for linuxthreads)
+- use NPTL instead of linuxthreads
+ * debhelper.in/libc.preinst: require (Debian) 2.6.32 kernel on m68k
+
+ -- Thorsten Glaser t...@mirbsd.de Wed, 02 Feb 2011 19:11:39 +
+
eglibc (2.11.2-11) unstable; urgency=low
* patches/kfreebsd/local-sysdeps.diff: remove stub marks for at*
diff -u eglibc-2.11.2/debian/sysdeps/m68k.mk
eglibc-2.11.2/debian/sysdeps/m68k.mk
--- eglibc-2.11.2/debian/sysdeps/m68k.mk
+++ eglibc-2.11.2/debian/sysdeps/m68k.mk
@@ -2,2 +2 @@
-libc_add-ons = ports linuxthreads $(add-ons)
-libc_extra_config_options = $(extra_config_options) --disable-sanity-checks
--without-__thread --without-tls
+libc_add-ons = ports nptl $(add-ons)
diff -u eglibc-2.11.2/debian/patches/series eglibc-2.11.2/debian/patches/series
--- eglibc-2.11.2/debian/patches/series
+++ eglibc-2.11.2/debian/patches/series
@@ -152,6 +152,7 @@
m68k/cvs-define-m68k-tls-relocations.patch
m68k/cvs-tls-support.patch
+m68k/cvs-fix-sem_t-alignment.patch
m68k/cvs-versions-def-2-12.patch
m68k/local-compat.diff
m68k/local-dwarf2-buildfix.diff
diff -u eglibc-2.11.2/debian/debhelper.in/libc.preinst
eglibc-2.11.2/debian/debhelper.in/libc.preinst
--- eglibc-2.11.2/debian/debhelper.in/libc.preinst
+++ eglibc-2.11.2/debian/debhelper.in/libc.preinst
@@ -292,33 +292,22 @@
mips*) realarch=mips;;
esac
- # The GNU libc requires a = 2.6.18 kernel (except on m68k)
+ # The GNU libc requires a = 2.6.32-3 Debian kernel on m68k
+ # for TLS, or a = 2.6.18 kernel on all other architectures
if [ $realarch != m68k ]
then
- if linux_compare_versions $kernel_ver lt 2.6.18
- then
- echo WARNING: this version of the GNU libc requires kernel
version
- echo 2.6.18 or later. Please upgrade your kernel before
installing
- echo glibc.
- kernel26_help
-
- exit 1
- fi
+ vmin=2.6.18
+ else
+ vmin=2.6.32
fi
-
- # The GNU libc is now built with --with-kernel= = 2.4.1 on m68k
- if [ $realarch = m68k ]
+ if linux_compare_versions $kernel_ver lt ${vmin}
then
- if linux_compare_versions $kernel_ver lt 2.4.1
- then
- echo WARNING: This version of glibc requires that you be running
- echo kernel version 2.4.1 or later. Earlier kernels contained
- echo bugs that may render the system unusable if a modern version
- echo of glibc is installed.
- kernel26_help
+ echo WARNING: this version of the GNU libc requires kernel version
+ echo ${vmin} or later. Please upgrade your kernel before installing
+ echo glibc.
+ kernel26_help
- exit 1
- fi
+ exit 1
fi
# From glibc 2.6-3 SPARC V8 support is dropped.
only in patch2:
unchanged:
--- eglibc-2.11.2.orig/debian/patches/m68k/cvs-fix-sem_t-alignment.patch
+++ eglibc-2.11.2/debian/patches/m68k/cvs-fix-sem_t-alignment.patch
@@ -0,0 +1,65 @@
+This series of m68k related commits fixes alignment of sem_t due to
+the kernel using the lower two bit for internal purposes, whereas on
+Linux/m68k, the alignment of long is not natural. I refrain from
+patching a ChangeLog file, since I saw this break with gcc earlier.
+ -- tg@d.o
+
+From: Andreas Schwab sch...@linux-m68k.org
+Date: Sun, 2 Jan 2011 19:14:41 + (+0100)
+Subject: m68k: force alignment of sem_t
+X-Git-Tag: glibc-2.13~7
+X-Git-Url:
http://sourceware.org/git/?p=glibc-ports.git;a=commitdiff_plain;h=9524dbd1f3f91a9b381bb0e17dc5e150fe8be75a
+
+m68k: force alignment of sem_t
+---
+
+#diff --git a/ChangeLog.m68k b/ChangeLog.m68k
+#index ccd8b4e..feba28e 100644
+#--- a/ChangeLog.m68k
+#+++ b/ChangeLog.m68k
+#@@ -1,3 +1,8 @@
+#+2011-01-10 Andreas Schwab sch...@linux-m68k.org
+#+
+#+ * sysdeps/unix/sysv/linux/m68k/nptl/bits/semaphore.h (sem_t):
+#+ Force alignment.
+#+
+# 2010-12-26 Andreas Schwab
Bug#612502: texinfo: FTBFS due to running configure+build twice, fix attached
Source: texinfo Version: 4.13a.dfsg.1-6 Severity: serious Tags: patch Justification: fails to build from source Hi, the debian/rules Makefile target patch is phony, that's why the stamp file mechanism doesn't work and the build is run twice. Due to GNU autotools fsckup, this _can_ (but not necessarily does) result in an FTBFS. Please apply the attached patch, tested on amd64 (works, doesn't run twice) and m68k (fixes the FTBFS). -- System Information: Debian Release: 6.0 APT prefers etch-m68k APT policy: (500, 'etch-m68k') (actually, it doesn't, but I have no idea where this comes from, I use unstable) Architecture: m68k Kernel: Linux 2.6.32-5+m68k.5-atari Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh-static Versions of packages texinfo depends on: ii libc6 2.11.2-11+m68k.1 Embedded GNU C Library: Shared lib texinfo recommends no packages. Versions of packages texinfo suggests: pn texinfo-doc-nonfree none (no description available) ii texlive-base 2009-11TeX Live: Essential programs and f pn texlive-generic-recommended none (no description available) ii texlive-latex-base2009-11TeX Live: Basic LaTeX packages -- no debconf information diff -u texinfo-4.13a.dfsg.1/debian/changelog texinfo-4.13a.dfsg.1/debian/changelog --- texinfo-4.13a.dfsg.1/debian/changelog +++ texinfo-4.13a.dfsg.1/debian/changelog @@ -1,3 +1,10 @@ +texinfo (4.13a.dfsg.1-6+m68k.1) unreleased; urgency=low + + * d/rules: depend build on $(QUILT_STAMPFN) instead of patch, to fix an +FTBFS caused by the build target having been run twice + + -- Thorsten Glaser t...@mirbsd.de Tue, 08 Feb 2011 19:23:02 +0100 + texinfo (4.13a.dfsg.1-6) unstable; urgency=low * update-info-dir: load not only /etc/environment, but also diff -u texinfo-4.13a.dfsg.1/debian/rules texinfo-4.13a.dfsg.1/debian/rules --- texinfo-4.13a.dfsg.1/debian/rules +++ texinfo-4.13a.dfsg.1/debian/rules @@ -21,7 +21,7 @@ tmpdir := $(CURDIR)/debian/tmp build: build-stamp -build-stamp: patch +build-stamp: $(QUILT_STAMPFN) # some man scripts have been touch by the patches, so the builder # will try to rebuild the man page from texi2dvi but that # spits out only a warning that no tex system is installed
Bug#612502: texinfo: FTBFS due to running configure+build twice, fix attached
Norbert Preining dixit: So *does* it FTBFS or not??? I think it may depend on the moon phase. The second run of configure, under fakeroot, had different results than the first, which led to a failure. Does building twice actually FTBFS? The first build resulted in an FTBFS already. (That aside, the patch aligns texinfo’s debian/rules with what the quilt readme suggests, and cuts down build time a lot, so…) bye, //mirabilos -- 22:20⎜asarch The crazy that persists in his craziness becomes a master 22:21⎜asarch And the distance between the craziness and geniality is only measured by the success 18:35⎜asarch Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612502: texinfo: FTBFS due to running configure+build twice, fix attached
Hilmar Preu�e dixit: Hm. I tried to build on Debian unstable, one time w/, one time w/o the patch. The build logs did not show a difference. No, I didn't found an evidence in the log, that something has been done twice. Interesting. See below… I used i386, is the problem limited to m86k and if yes, could you provide a build log? I do not think the problem is limited to m68k, but the FTBFS happened there (though I believe it MAY happen on any architecture, and that it doesn’t always happen on m68k). Hmpf of course I deleted the logs after I made the patch and had it working ☹ But let’s take some release architecture’s build logs: https://buildd.debian.org/fetch.cgi?pkg=texinfoarch=powerpcver=4.13a.dfsg.1-6stamp=1287048302file=logas=raw I’m downloading this to make sure we have the correct line numbers to compare (MD5 = 72786a7e2414bba2f30794cc0f314050). Please look at lines 1410 ff. There you see 「touch build-stamp」 (end of the build target), followed by 「# some man scripts」… which is a repeat of lines 275 ff. which follow after stamp-patched. This goes up to line 1829 (note that this repeat, IF it works at all, takes quite a while, which is why this patch is in general a good idea). From line 1830 onwards, we continue with the binary-arch target. Now, lines 1411 to 1829 (and onwards) run as root or under fakeroot, and it just happened that some configure result differed, leading to an FTBFS I’ve seen before (in BSD) because, IIRC, malloc was wrongly not detected correctly and defined to rpl_malloc in config.h, but not built in gnulib (since it worked in the first instance). As you can see in the following build log: http://buildd.debian-ports.org/fetch.php?pkg=texinfover=4.13a.dfsg.1-5arch=m68kstamp=1271634700file=logas=raw This doesn’t _always_ lead to an FTBFS even on m68k. But it definiti- vely _is_ a bad idea and a broken debian/rules file, so please just apply the patch for your next upload. Thanks in advance, //mirabilos -- 22:20⎜asarch The crazy that persists in his craziness becomes a master 22:21⎜asarch And the distance between the craziness and geniality is only measured by the success 18:35⎜asarch Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612502: texinfo: FTBFS due to running configure+build twice, fix attached
Hilmar Preu�e dixit: I applied the patch to our SVN, the next upload will have the fix. Thanks a lot! (As I said, it probably doesn’t FTBFS in 99.9% of all builds, across all architectures – but the double-build is wrong.) -- sigmentation fault How fitting ;-) bye, //mirabilos -- 13:47⎜tobiasu if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615501: Bugs closed by package upload to experimental
Package: ftp.debian.org Hi, I think uploads to experimental should NOT close a bug, but add a tag fixed-in-experimental (which already exists) instead. bye, //mirabilos -- 13:47⎜tobiasu if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615501: Bugs closed by package upload to experimental
Adam D. Barratt dixit: The tag exists because before the introduction of version tracking it was the only way of indicating that a bug was fixed in experimental but still affected unstable. Ah okay, thanks for the explanation. bye, //mirabilos -- 13:47⎜tobiasu if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611768: updated debdiff
Hi, applied the patch against the latest package from unstable. bye, //mirabilos -- 13:47⎜tobiasu if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)diff -u binutils-2.21.0.20110216/debian/changelog binutils-2.21.0.20110216/debian/changelog --- binutils-2.21.0.20110216/debian/changelog +++ binutils-2.21.0.20110216/debian/changelog @@ -1,3 +1,9 @@ +binutils (2.21.0.20110216-2+m68k.1) unreleased; urgency=low + + * d/patches/640_m68k_fix-TLS_GD-relocation: new, temp. (Closes: #611768) + + -- Thorsten Glaser t...@mirbsd.de Sun, 27 Feb 2011 15:25:22 + + binutils (2.21.0.20110216-2) unstable; urgency=low * Upload to unstable. diff -u binutils-2.21.0.20110216/debian/patches/series binutils-2.21.0.20110216/debian/patches/series --- binutils-2.21.0.20110216/debian/patches/series +++ binutils-2.21.0.20110216/debian/patches/series @@ -17,0 +18 @@ +640_m68k_fix-TLS_GD-relocation.patch only in patch2: unchanged: --- binutils-2.21.0.20110216.orig/debian/patches/640_m68k_fix-TLS_GD-relocation.patch +++ binutils-2.21.0.20110216/debian/patches/640_m68k_fix-TLS_GD-relocation.patch @@ -0,0 +1,33 @@ +Subject: [M68K] Fix TLS_GD relocation against localized symbol +From: Andreas Schwab schwab at redhat dot com + +A TLS_GD relocation is associated with two GOT slots, with the +relocation value actually being put in the second slot. When adjusting +this relocation against a localized symbol read the value from the +second slot, not the first one. + +Andreas. + + +2011-02-01 Andreas Schwab sch...@redhat.com + + * elf32-m68k.c (elf_m68k_finish_dynamic_symbol): For a TLS_GD + relocation read the value from the second GOT slot. + + +Index: binutils-2.21.0.20110216/bfd/elf32-m68k.c +=== +--- binutils-2.21.0.20110216.orig/bfd/elf32-m68k.c 2010-10-25 15:54:14.0 + binutils-2.21.0.20110216/bfd/elf32-m68k.c 2011-02-27 15:24:46.0 + +@@ -4390,6 +4390,11 @@ + break; + + case R_68K_TLS_GD32: ++/* The value for this relocation is actually put in ++ the second GOT slot. */ ++relocation = bfd_get_signed_32 (output_bfd, ++(sgot-contents ++ + got_entry_offset + 4)); + relocation += dtpoff_base (info); + break; +
Bug#614340: [Pkg-mailman-hackers] Bug#614340: Bug#614340: mailman: expose message-id to templates
On Sat, 26 Feb 2011, Thijs Kinkhorst wrote: On Monday 21 February 2011 08:21:58 Adrian von Bidder wrote: Please consider this trivial patch, which exposees message-ids to the templates used for the email archive. Thanks. Because there's currently a very small amount of manpower in the Debian Mailman team, I'm not eager on adding new wishlist-style patches to I’ll take it with my collection. (I just need to be able to allocate time for it, hopefully RSN.) bye, //mirabilos -- CeBIT 2011 – tarent ist dabei. Besuchen Sie uns auf der CeBIT 2011 und lernen Sie unser neues Identity- and Accessmanagement OSIAM kennen. Wir freuen uns auf Ihren Besuch in Halle 2, Stand D40/1. Sie wünschen ein persönliches Gespräch? – Wenden Sie sich an sa...@tarent.de. tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstraße 24, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 52675-93 • Fax: +49 228 52675-25 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Elmar Geese -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
