Bug#438184: getpwnam and getgrnam astonishing inefficiency

2007-08-15 Thread Ian Jackson
Package: libc6 Version: 2.3.6.ds1-13 While stracing dpkg I saw something strange so I investigated. Below is a fragment showing dpkg on sarge installing libadns1-bin. This is from the unpack phase and convers the installation of two files. I see similar behaviour on etch. 18 out of the 32

Re: glibc's getaddrinfo() sort order

2007-09-07 Thread Ian Jackson
Kurt Roeckx writes (Re: glibc's getaddrinfo() sort order): It's atleast in the spirit of the rfc to prefer one that's on the local network. It might be the intention of rule 9, but then rule 9 isn't very well written. I agree that applying RFC3484 section 6 rule 9 to IPv4 addresses is a

Re: glibc's getaddrinfo() sort order

2007-09-12 Thread Ian Jackson
Anthony Towns writes (Re: glibc's getaddrinfo() sort order): On Fri, Sep 07, 2007 at 01:06:06AM +0200, Kurt Roeckx wrote: It's atleast in the spirit of the rfc to prefer one that's on the local network. It might be the intention of rule 9, but then rule 9 isn't very well written. Rule 9

Re: glibc's getaddrinfo() sort order

2007-09-18 Thread Ian Jackson
Anthony Towns writes (Re: glibc's getaddrinfo() sort order): I'm not familiar with how getaddrinfo() has been implemented in the past I think this is an important point. If you're not familiar with the history then perhaps I can help explain. hostname-to-address lookups have up to recently

Re: glibc's getaddrinfo() sort order

2007-09-18 Thread Ian Jackson
Anthony Towns writes (Re: glibc's getaddrinfo() sort order): So if getaddrinfo() has always behaved in this way, I don't see a great deal of justification in changing it. The bug log indicated that there were pre-rfc implementations of getaddrinfo() that behaved more like gethostbyname() at

Re: glibc's getaddrinfo() sort order

2007-09-21 Thread Ian Jackson
Anthony Towns writes (Re: glibc's getaddrinfo() sort order): On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote: So do you have a use case where you think the behavior described in rule 9 *is* desirable? Any application written assuming this behaviour, works correctly on

Re: glibc's getaddrinfo() sort order

2007-09-21 Thread Ian Jackson
Anthony Towns writes (Re: glibc's getaddrinfo() sort order): As it happens I largely agree with that. I don't agree with making a decision to go against an IETF standard and glibc upstream lightly, though, no matter how many caps Ian expends repeating that it's at the least mature level of

Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch

2007-09-28 Thread Ian Jackson
on debian-ctte. I'm sorry you hadn't. I'll start CCing [EMAIL PROTECTED] Will that help ? On Fri, Sep 28, 2007 at 03:56:31PM +, Ian Jackson wrote: I don't know if you've been following the argument on the TC list about bug #438179. I think the Technical Committee are probably going to rule

Re: getaddrinfo() behaviour

2007-10-01 Thread Ian Jackson
Anthony Towns writes (Re: getaddrinfo() behaviour): In my opinion, if this isn't an RC issue, there's no urgency to having glibc changed prior to the standards changing, and as such, this isn't the last resort so the tech ctte shouldn't be deciding the issue, let alone overruling the

Re: getaddrinfo() behaviour

2007-10-01 Thread Ian Jackson
Ian Jackson writes (Re: getaddrinfo() behaviour): Limiting the TC's power to overrule a technical decision to only cases where the TC believes that the wrong behaviour makes the package unsuitable for release would eviscerate the only mechanism we have for dealing with errors by maintainers

Re: getaddrinfo() behaviour

2007-10-02 Thread Ian Jackson
Anthony Towns writes (Re: getaddrinfo() behaviour): The only reason suitability for release is relevant is in overriding the directive that we'll not make a technical decision until efforts to resolve it via consensus have been tried and failed. We haven't made efforts to get a consensus with

Bug#447609: ldconfig triggerisation

2007-10-22 Thread Ian Jackson
Source: glibc Version: 2.6.1-6 Severity: wishlist Tags: patch The attached patch triggerises the invocation of ldconfig by package maintainer scripts. By `triggerises' I mean that the patch arranges for ldconfig invocations by maintainer scripts to call dpkg-trigger instead of ldconfig.

Bug#447609: ldconfig triggerisation

2007-10-23 Thread Ian Jackson
Daniel Jacobowitz writes (Re: Bug#447609: ldconfig triggerisation): On Mon, Oct 22, 2007 at 04:07:05PM +0100, Ian Jackson wrote: [assumptions] Note that this is usually true but not always; it may be true enough for our purposes but I want to set the record straight. Thanks. The only

Bug#447609: ldconfig triggerisation

2007-10-23 Thread Ian Jackson
Daniel Jacobowitz writes (Re: Bug#447609: ldconfig triggerisation): On Tue, Oct 23, 2007 at 11:11:37AM +0100, Ian Jackson wrote: The only failure case I can think of would be a package which places libraries in the multi-arch directories, which Debian locates using a file in /etc

Bug#447609: ldconfig triggerisation

2007-10-23 Thread Ian Jackson
Clint Adams writes (Re: Bug#447609: ldconfig triggerisation): Why not just move to use of dpkg-trigger piecemeal in each postinst? That would involve no more invocations of ldconfig than we are already enduring. Because that would involve a great deal of additional dependency complexity: each

Bug#438179: RFC3484 rule 9 active again in glibc 2.7-5.

2008-02-22 Thread Ian Jackson
Aurelien Jarno writes (Re: RFC3484 rule 9 active again in glibc 2.7-5.): Upstream has committed a fix in the CVS (without telling anybody) so that for IPv4 addresses rule 9 is only applied when source and destination addresses are in the same subnet. I guess this is very close to the wanted

Bug#438179: RFC3484 rule 9 active again in glibc 2.7-5.

2008-02-24 Thread Ian Jackson
Aurelien Jarno writes (Re: RFC3484 rule 9 active again in glibc 2.7-5.): An IP which uses the same IP range as your computer, as defined by the netmask. In short a local server which can be reached without a gateway. Ah. I see. So what you mean is that it will now: * prefer a server in the

Bug#438179: RFC3484 rule 9 active again in glibc 2.7-5.

2008-02-26 Thread Ian Jackson
Aurelien Jarno writes (Re: RFC3484 rule 9 active again in glibc 2.7-5.): IP on different subnet are not sorted, IP on some local subnet are sorted by a longer common prefix with the interface address. Err, pardon my language, but WTF ?! What on earth is the justification for that ? Ian. --

Bug#369940: libc6 upgrade objects to my old a.out libc in /usr/local

2006-06-02 Thread Ian Jackson
Package: libc6 Version: 2.3.2.ds1-22sarge3 Preparing to replace libc6 2.3.2.ds1-22 (using .../libc6_2.3.2.ds1-22sarge3_i386.deb) ... These libraries were found in /usr/local/lib: libc.so.2 libc.so.2.2 libm.so.2 libm.so.2.2 A copy of glibc was found in an unexpected directory. It is not

Bug#682972: ttyname() (and /bin/tty) on /dev/tty return /dev/tty

2012-07-27 Thread Ian Jackson
Package: libc6 Version: 2.11.2-10 ttyname() should return the name of the tty device in a form than can be used by other processes (with different controlling terminals) to open it. Steps to reproduce: $ perl -e 'use POSIX; printf %s\n, ttyname(STDIN)' /dev/pts/117 $ perl -e 'use POSIX;

Bug#682972: ttyname() (and /bin/tty) on /dev/tty return /dev/tty

2012-07-27 Thread Ian Jackson
Ian Jackson writes (ttyname() (and /bin/tty) on /dev/tty return /dev/tty): Package: libc6 Version: 2.11.2-10 ttyname() should return the name of the tty device in a form than can be used by other processes (with different controlling terminals) to open it. Having considered and discussed

Bug#683826: cfsetspeed, real baud rates, custom baud rates (BOTHER)

2012-08-04 Thread Ian Jackson
Package: libc6 Version: 2.13-33 In summary, please: - Fix the documentation so that it no longer claims that tcgetispeed and tcgetospeed return actual baud rates. - Provide new functions tcgetispeedbps and tcgetospeedbps which do return actual baud rates. - Make all the

Bug#683826: Acknowledgement (cfsetspeed, real baud rates, custom baud rates (BOTHER))

2012-08-04 Thread Ian Jackson
PS here are the two test programs I wrote while preparing the bug report. #include termios.h #include stdio.h #include stdlib.h #defineBOTHER 001 int main(int argc, const char **argv) { struct termios to; int r; r = tcgetattr(0, to); if (r) { perror(tcgetattr); exit(-1); }

Bug#28250: Ping ? (re libc lost output bug)

2002-12-28 Thread Ian Jackson
On the 10th of July I wrote: So, could you please apply it to the libc in unstable ? What more needs to happen before you apply this patch ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#28250: Ping ? (re libc lost output bug)

2002-12-28 Thread Ian Jackson
On the 10th of July I wrote: So, could you please apply it to the libc in unstable ? What more needs to happen before you apply this patch ? Ian.

Bug#12411: [PATCH] A better Directory Lister example

2002-12-28 Thread Ian Jackson
H. S. Teoh writes (Bug#12411: [PATCH] A better Directory Lister example): ... I have declined to address this, since this example is mainly concerned with using the libc directory reading functions, not with handling stdout errors. I actually think it's a libc bug, #28250. * it prints the

Re: timezone data packaged separately and in volatile?

2006-02-07 Thread Ian Jackson
Martijn van Oosterhout writes (Re: timezone data packaged separately and in volatile?): The requirements for getting into a stable release update are not black magic, they're quite well known: http://people.debian.org/~joey/3.1r1/ 2. The package fixes a critical bug which can lead into

Bug#749345: if_nametoindex error behaviour assumptions

2014-05-26 Thread Ian Jackson
Package: libc6 Version: 2.13-38+deb7u1 As part of trying to determine the error behaviour of if_nametoindex, I wrote and ran the attached test program. I discovered by looking at the strace of a test run that if_nametoindex doesn't always properly check the errno values from its system calls.

Bug#749349: Please document if_nametoindex error behaviour

2014-05-26 Thread Ian Jackson
Package: glibc-doc-reference, libc6 Version: 2.13-1, 2.13-38+deb7u1 I have been writing a program which needs to call if_nametoindex. Naturally I need to deal with the possible error cases. RFC3493, which appears to be the standards document describing it, has this to say about its error

Re: Replacing ldconfig maintscripts with declarative methods

2015-08-25 Thread Ian Jackson
Niels Thykier writes (Replacing ldconfig maintscripts with declarative methods): A possible solution is to replace these scripts with an activate-no-await trigger (again, no-await to avoid trigger cycles). I would need libc-bin to promote its trigger to part of its API for this to work. I

Re: libc recently more aggressive about pthread locks in stable ?

2016-11-06 Thread Ian Jackson
do that would depend on its performance impact. TBH I wonder whether we really want to be giving an evidently shonky codebase boobytrapped mutexes by default. We could change the default mutex type to recursive and make all of these bugs go away. Ian. -- Ian Jackson <ijack...@chiark.greenend

libc recently more aggressive about pthread locks in stable ?

2016-11-05 Thread Ian Jackson
to make a patch to fix ghostscript, or at least file a proper bug. But, if there was a libc change, would it be possible to revert it or make some kind of workaround ? Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an a

Re: libc recently more aggressive about pthread locks in stable ?

2016-11-05 Thread Ian Jackson
Ian Jackson writes ("libc recently more aggressive about pthread locks in stable ?"): > I have just been debugging a ghostscript segfault on jessie amd64. ... > I recently encountered what seems to be a similar bug in ogg123 in > stable. #842796. > > Has something

Re: gnupg2 autopkgtest uses multi-arch which seems fragile

2018-07-09 Thread Ian Jackson
Ian Jackson writes ("Re: gnupg2 autopkgtest uses multi-arch which seems fragile"): > I looked in: > > * debian/tests/control in the gnupg2 source tree. > One test, of gpgv-win32. Depends on gpgv-win32, gnupg2, I have found it: debian/tests/gpgv-win32 manually ins

Re: gnupg2 autopkgtest uses multi-arch which seems fragile

2018-07-09 Thread Ian Jackson
32-stdout.gz: wine32:i386 : Depends: libc6:i386 (>= 2.17) but it is not going to be installed gpgv-win32-stdout.gz: Depends: libwine:i386 (= 3.0.2-1) but it is not going to be installed $ The test log is no more informative. Ian. -- Ian JacksonThese opinions

Bug#28250: closed by Credible Finance <y_mai...@yahoo.com> (reply to Credible Finance <crediblefinance....@gmail.com>) (Apply for a Personal/Business Loan)

2018-02-26 Thread Ian Jackson
Control: reopen -1 Control: retitle -1 perl can lose output due to stdio buffering Control: found -1 5.20.2-3+deb8u9 Debian Bug Tracking System writes ("Bug#28250 closed by Credible Finance (reply to Credible Finance ) (Apply for a

Bug#28251: closed by Credible Finance <y_mai...@yahoo.com> (reply to Credible Finance <crediblefinance....@gmail.com>) (Apply for a Personal/Business Loan)

2018-02-26 Thread Ian Jackson
Control: reopen -1 Control: retitle -1 libc should unilaterally report buffered write error on close Debian Bug Tracking System writes ("Bug#28251 closed by Credible Finance (reply to Credible Finance ) (Apply for a Personal/Business Loan)"):

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

2019-02-07 Thread Ian Jackson
ically our sensible choices for the default are C.UTF-8 One of en_{AU,GB,NZ}.UTF-8 All of these would be better than en_US.UTF-8 for the reasons given by Adam (although, Adam, really, could you try to be a little less rude?). The middle-endian dates and 12-hour clock are particularly poor default

Bug#942866: /usr/bin/getconf: getconf(1) should mention sysconf

2019-10-22 Thread Ian Jackson
. libc-bin suggests no packages. -- no debconf information >From 90d97e44554a3f1a8b3d5739598337da480c7e37 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Tue, 22 Oct 2019 15:15:30 +0100 Subject: [PATCH] getconf(1): Mention `sysconf', mostly for the benefit of search This makes this handy utility cons

Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename

2020-06-22 Thread Ian Jackson
Package: libc6 Version: 2.28-10 Severity: normal File: /lib/ld-linux.so.2 Hi. I found this behaviour: $ eatmydata man ls >/dev/null ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libeatmydata.so' from

Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]

2020-06-23 Thread Ian Jackson
jects are preloaded only from the > standard search directories and only if they have set-user-ID mode bit > enabled (which is not typical). Obviously it wouldn't be right for eatmydata to be loaded by actually setuid programs. Ian Jackson writes ("Re: Bug#963508: /lib/ld

Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename

2020-06-23 Thread Ian Jackson
Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename"): > On 2020-06-23 11:46, Ian Jackson wrote: > > Should apparmor make a difference between absolute paths and leafnames > > in LD_PRELOAD ? Because I can repr

Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename

2020-06-23 Thread Ian Jackson
libfaketime.so.1' from LD_PRELOAD cannot be preloaded > > (cannot open shared object file): ignored. > > $ > > > This message on debian-user seems related: > > https://lists.debian.org/debian-user/2017/03/msg00335.html > > Yes, there seems to be an issue