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
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
imited to man:
> >
> > $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 dash -c true
> > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded
> > (cannot open shared object file): ignored.
> > $
>
> > This message on debia
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
es.
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 han
t.
Realistically 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 p
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
gpgv-win32-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
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 Personal/Business Loan)"):
> It has been closed by Credible Fin
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)"):
> It has been closed by Credible Finance (reply to
bugs, and not throwing useful software out of Debian.
Please would you make a decision quickly.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
e. Whether to 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 JacksonThese o
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
ill try 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 JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk,
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
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 behavio
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.
To
PS here are the two test programs I wrote while preparing the bug
report.
#include
#include
#include
#defineBOTHER 001
int main(int argc, const char **argv) {
struct termios to;
int r;
r = tcgetattr(0, &to); if (r) { perror("tcgetattr"); exit(-1); }
const char *arg = argv[1]
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 tc*sp
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) t
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;
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.
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
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 want
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: e
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 Debia
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 reco
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. ldconfig
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 consensu
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
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 ma
;d be following the discussion 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
> >
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 o
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 o
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()
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 recentl
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.
>
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
m
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 syste
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 s
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 int
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
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.
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
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]
45 matches
Mail list logo
