Getting rid of the only race condition that matters:
Create the link first, with an unused name. Instead of
relying on the return code, which may be wrong for NFS,
call stat to find out if you created the file. Rename the
link over top of the file it is intended to replace. In case
that fails,
Package: procps
Version: 1:3.3.3-2
The command line parser is now broken.
Values accepted by kill(2) are rejected by kill(1).
(yes this is useful) It failed when I did this:
$ /bin/kill -9 -1
/bin/kill: invalid option -- '1'
Usage:
kill [options] pid [...]
Options:
pid [...]send
Steve Langasek writes:
On Mon, Apr 06, 2009 at 05:33:35PM +, Thorsten Glaser wrote:
If you need a specific locale (as seems from mksh, not
sure if it is a bug in that program), you need to set it.
You can only set a locale on a glibc-based system if it's
installed beforehand, which root
Roger Leigh writes:
On Tue, Apr 07, 2009 at 09:24:38PM +0200, Adeodato Simó wrote:
+ Thorsten Glaser (Tue, 07 Apr 2009 18:54:59 +):
Except the ton which sets LC_ALL=C to get sane (parsable,
dependable, historically compatible) output.
These would then unset all other LC_* and LANG and
Andrew McMillan writes:
On Wed, 2009-04-08 at 10:15 +0200, Giacomo A. Catenazzi wrote:
So I've a question: what does UTF-8 mean in this context (C.UTF-8) ?
...
So given a character which is outside of the 0x00 = 0x7f range, in an
environment which does not specify an encoding, I would like to
Giacomo A. Catenazzi writes:
[Andrew McMillan probably]
I think nobody should use C or C.UTF-8 as user encoding.
And I really hope that Debian will try to convince user to
use a proper locale.
Debian doesn't ship a proper locale. I want sorting according
to the raw Unicode values. I want
I don't have this supgid in my procps, so I don't have this bug.
I do however have environ, which readproc sets as follows:
if (unlikely(flags PROC_FILLENV))
p-environ = file2strvec(path, environ);
else
p-environ = NULL;
Remember that this is some of the most
On Mon, Nov 23, 2009 at 6:42 AM, Craig Small csm...@debian.org wrote:
The xcalloc is in the original code, I can even see it in the 3.2.7
code.
Yeah, I know.
So is the solution to test the result of the file2str on the status file
and if that fails set certain pointers to null?
something
Long ago, I got complaints the other way. I guess the
argument was related to reliability and getting all the data
into grep, but of course this is a defective argument as
long as the kernel is free to swap out the argv[] data.
I think there was also some argument related to
the behavior of BSD,
I could update that code to handle recent 2.6.xx kernels,
but I'd rather rip it out entirely. I suppose the code might
be useful for the guy who does the Cygwin (Windows!!!)
port, and there might be a person running a.out binaries.
My first suspicion is that you are using a broken libc.
There
with dyntick kernel (2.6.21), vmstat sometimes report
0 interrupt. This is because with dyntick, timer interrupt
are not always interupt 0 (pit) but it can be also apic
(counted as local interrypt).
So vmstat should take care of local interrupt (and may be mmi)
in its report.
If vmstat
For reliability and performance, ps does not sort
output by default. This has not changed.
Kernel behavior regarding PID allocation and /proc
readdir() ordering can make it seem like ps is sorting,
but ps does not sort by default.
Perhaps the kernel ought to scramble the order
a bit just to make
That was a really interesting description from Samuel Thibault.
I spent a good while picking over the kernel code on the
assumption that the kernel's signal was erroneously being
subjected to the security checks that would apply to xterm.
The xterm sends a SIGHUP part, if done directly, looks
Many random thoughts on this one:
Direct use of readdir64 would avoid burdening
procps with needless 64-bit operations elsewhere.
The 64-bit operations show up very high in gprof
profiles on i386.
Isn't ino_t already 64-bit on x86_64? Note that
usage of 32-bit procps on x86_64 is not supported.
Package: glibc
I'm getting this error message:
ERROR: ld.so: object '/home/albert/olpc/sugarize/libsugarize.so' from
LD_PRELOAD cannot be preloaded: ignored.
A google search reveals many frustrated people unable to
deal with this. The normal problems involve LD_PRELOAD
when:
a. something is
Package: file
# puredigital used it for the CVS disposable camcorder
8 lelong 4 ZBM bitmap image data
4 leshort x %u x
6 leshort x %u
# really le32 operation,destination,payloadsize (but quite predictable)
# 01 00 00 00 00 00 00 c0 00 02 00 00
0 string
ARM isn't the only disassembler to crash. (it's the only one holding
up free firmware though)
It's time for some automated testing, don't you think? The following
commands will do.
With a larger data size, such as 16 MB, they ought to be part of the build.
dd bs=1k count=64 if=/dev/urandom
I just saw the crash on an ELF file.
I did objdump -D myfile.elf.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
$ gdb --args objdump -D r
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There
Package: binutils-multiarch
Version: 2.18~cvs20070812-1
Severity: important
I'm trying to disassemble raw ARM code. You can use any random
input file to test this; the bug report email will do nicely.
(invalid instructions should be reported as such, as they are
when disassembling ELF files)
In
ELF notes tend to be reliable. The crufty old method
probably should go away at some point; you really
need to supply the proper ELF notes.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I don't think there is any bug at all. There is just the
annoyance of not knowing exactly what memory is
available; AFAIK you can not know that until you try
to use it.
The slab is not really a cache. In some cases it can
be a cache, but generally it isn't. It's regular kernel
memory
On 5/13/07, Anton Zinoviev [EMAIL PROTECTED] wrote:
On Sat, May 12, 2007 at 08:35:22PM -0400, Albert Cahalan wrote:
That's wrong too, since it'd still load a default font.
I had to uninstall this defective package because it insisted
on loading a font at boot. That really screwed me up
at line 170 of /etc/init.d/console-screen.kbd.sh you call unicode_start
in this way:
unicode_start /dev/tty? /dev/tty?
without specifying the font. Without this option unicode_start will load
a default font.
I think that the right way should be:
unicode_start ${CONSOLE_FONT} /dev/tty?
The error dialog box does not provide a button to delete
the cache and metadata files. There isn't even a menu
option or toolbar button for it.
Data recovery requires a nerd.
More than any other email client, evolution is meant
for non-nerd use. This isn't /bin/mail, mh, or emacs rmail.
In
I was wrong. Version 1.2.13 is showing the problem.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Perhaps this will help:
Have a dozen lockfiles per interface (console, IP address, whatever),
or per user, or per interface+user pair.
Each attempt must take a lock on just one of the available files.
Each success immediately releases a lock.
Each failure waits 5 seconds AS A BACKGROUND
The package name still indicates that this is a library.
Somebody looking for apps won't bother with this.
People don't always see the full description. They
see lib and may logically assume that the package
will automatically be installed if needed; there is
normally no reason to directly
Part of the problem is libgcc:
$ readelf -a /lib/libgcc_s.so.1 | egrep LOAD
LOAD 0x00 0x 0x 0x12024 0x12024 R E 0x1
LOAD 0x012024 0x00022024 0x00022024 0x002d0 0x00664 RWE 0x1
Another part is that -msecure-plt is not the default:
$ echo 'int
From: Chris Lawrence [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Fri, 11 Aug 2006 18:13:47 -0500
Subject: Fixed
According to the original submitter, this bug is fixed.
No way. I'm the original submitter, and I certainly
said nothing about the bug being fixed. Unless you've
done something to
On 8/12/06, Chris Lawrence [EMAIL PROTECTED] wrote:
More to the point, this is a general issue with all MUAs that depend
on an MTA to accomplish delivery for them, and (IMHO) loading down
reportbug with functionality that is only necessary to diagnose
people's broken mail systems wouldn't be a
Package: gcc-4.1
Version: 4.1.1-5
Severity: important
The note.GNU-stack and PT_GNU_STACK stuff apears
to be missing on PowerPC.
This contributes to insecurity on powerpc.
After this gets fixed, the whole damn system needs
to be rebuilt. I don't know where to request that.
--
To UNSUBSCRIBE,
Package: gcc-4.1
Version: 4.1.1-5
Severity: important
__trampoline_setup in /lib/libgcc_s.so.1 puts code on the stack.
This contributes to insecurity on powerpc.
A half-way fix is to mmap a page for this evil crud.
This still violates good practice, needing the OS to
allow either write+execute
Package: gcc-4.1
Version: 4.1.1-5
Severity: important
The -msecure-plt and -mbss-plt options are ignored.
This contributes to insecurity on powerpc.
(checked via md5sum: not one bit of difference)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
I forgot to point out:
Once this is fixed, all powerpc packages need
to be rebuilt ASAP.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
It seems that a 2.x.x release crashes when it finds files
from a 3.x.x release:
$ /usr/bin/valgrind --version
valgrind-3.2.0-Debian
$ /usr/local/bin/valgrind --version
valgrind-2.2.0-ppc
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
It's not very nice to make the older
How should he know if the mime type isn't good ? Divination ?
When there is no viewer for the given MIME type,
If the MIME type is something firefox has awareness of,
it is probably good. The only exception I know of is RPM
files usually being served as something related to RealPlayer.
If the
I'm on the austin-group mailing list, which is the discussion
list for the POSIX committee.
According to discussion on the austin-group mailing list,
the POSIX spec never intended to disallow the traditional
syntax. Very rarely is traditional syntax disallowed, and only
with some major
Use of a comma suggests decimal. Use of a colon suggests hex.
I'd like to see both, like this:
Device type: 22,64 016:00040
Hex matches up with /proc/*/maps and the pmap command.
Hex is generally what the kernel prints to the log. Unfortunately
we still have an ls command that uses decimal, and
Package: firefox
Version: 1.5.dfsg+1
(note: not a dupe bug beyond the 1st two paragraphs)
Web servers often do not supply the correct MIME type.
When I try to view such a file, firefox gives me the choice
of saving it or viewing it with something lame like gedit.
I most recently saw the
Package: firefox
Version: 1.5.dfsg+1
(note: not a dupe bug beyond the 1st two paragraphs)
Web servers often do not supply the correct MIME type.
When I try to view such a file, firefox gives me the choice
of saving it or viewing it with something lame like gedit.
I most recently saw the
The built-in editor sucks. Cursor movement is oddly defective.
There is no built-in help. Even if there were help, editing this
string is only semi-natural for experienced C programmers.
The man page hints at a solution, then refers to some other
document in some unknown location. Defaults should
Package: valgrind
Version: 1:3.1.1-1
Severity: grave
I had the previous version of valgrind working fine. That version doesn't
seem to be available anymore. It may be that valgrind is incompatible
with the latest C library, which was probably upgraded at the same time.
The package is obviously
Package: libimage-exiftool-perl
This package happens to include a library. It is not exclusively
library code though. It contains /usr/bin/exiftool.
Of course I ignored this package at first. It appears to be a
library, which would get automatically installed as needed.
Only after spotting the
The real fix is to not depend on the contents of the file
to determine the size of a static memory allocation; but
there may be some security implications to be considered
here before making that change.
I'd say the opposite is true. This sounds like a whopping
big security hole as it is right
That is indeed a serious error.
Besides going either direction, memcpy doesn't need to work via bytes.
It could use 16-byte vector registers. It could use something like
PowerPC's dcbz instruction, which causes a cache line (of the
destination) to be allocated in an all-zero state rather than
I lost all sorts of apps that Debian no longer packages.
I even lost penguineyes. Want to package it for me?
I guess it was wrong to rely on shared libraries. Debian
should use static linking. About the only thing stable
is the kernel system call interface.
Really, it's not cool to break old
Package: xterm
Version: 210-3
Severity: normal
It's coming up as black-on-white now.
I realize that this is all sophisticated-looking, and I realize
that that are arcane ways to configure this, but...
We have gnome-terminal for people who don't care about
compatibility with the real thing and
On 5/21/06, Thomas Dickey [EMAIL PROTECTED] wrote:
On Sun, May 21, 2006 at 09:20:17AM +0200, Albert Cahalan wrote:
That is indeed a serious error.
no - it's a stupid but benign error:
source and destination addresses are the same
Consider this entirely reasonable implementation
On 5/21/06, Thomas Dickey [EMAIL PROTECTED] wrote:
On Sun, May 21, 2006 at 05:09:32PM -0400, Albert Cahalan wrote:
End result: it acts like bzero() when src==dst
hmm - someone should fix that broken implementation of memcpy.
It's damn fast. I like fast libraries, don't you?
The ISO
On 5/21/06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Albert Cahalan [EMAIL PROTECTED] writes:
I lost all sorts of apps that Debian no longer packages.
I even lost penguineyes. Want to package it for me?
I guess it was wrong to rely on shared libraries. Debian
should use static linking
Package: pam
The default (only?) delay policy is awful. Bad logins should
be rate-limited via a per-interface or per-user token bucket.
Currently, any failed login forces a delay. There isn't any sort
of allowance for a small number of typing errors. I hit this
damn delay several times each day.
Once the 1.2 release gets to debian-stable, I guess you can close this.
Until then, I still say that the priority is not set according to Debian policy.
The current package is unusable.
On 11/7/05, Mark Purcell [EMAIL PROTECTED] wrote:
severity 335079 normal
thanks
Albert,
Thanks for this bug report about dropouts. We shall investigate, although if
this problem was common I would think there would be more reports available.
As such I am lowering the priority to normal.
Sure, this ought to be fixed to use gcc's option to not delete files, but...
You really need to stop building stuff as root. That's nuts. This is not
a Windows system. Use the fakeroot tools if you must, but that should
not be required. There are lots of errors that could wipe out /dev/null,
and
Some time ago, bold was removed from the default settings.
People with real terminals tended to hate it, and the Slackware
maintainer hated it. It did look kind of gaudy and gross.
So, I think this will be no different on i386 if you have the same
version and no ~/.toprc file to override the
You need to upgrade your kernel.
Package: asterisk
Version: 1:1.0.9.df
Severity: grave
I use IAX protocol over an uncongested LAN to the IAXy adapter.
I hear dropouts of about 1 second, alternating with OK sound for about
2 or 3 seconds. I get this when just listening to the local asterisk demo
sounds, as well as with VOIP over
On 9/27/05, Johannes Berg [EMAIL PROTECTED] wrote:
On Mon, 2005-09-26 at 18:54 -0400, Albert Cahalan wrote:
The gimp is currently broken as well. It can't save PNG images.
In the xterm I started gimp from, I get this:
libpng error: Call to NULL write function
I had
I don't really like the idea of bin-NMUing all those packages without
understanding the cause. If it turns out to be a real bug somewhere that
needs fixing, the whole bin-NMU dance will have to be done all over
again.
Me neither, but I am not qualified to find out the cause. Josselin
On 9/27/05, Frank Küster [EMAIL PROTECTED] wrote:
Johannes Berg [EMAIL PROTECTED] wrote:
On Mon, 2005-09-26 at 18:54 -0400, Albert Cahalan wrote:
The gimp is currently broken as well. It can't save PNG images.
In the xterm I started gimp from, I get this:
libpng error
Well, I think it's clear: We need a binary-only upload of tetex-bin.
I've never done that on one of the developer machines; is there any DD
on the powerpc list who is willing to save me from learning ;-)?
To be safe, do everything that depends on the library.
To sum things up: An update of libpng has caused tetex-bin (actually the
pdftex binary) to fail when including a png image. Since we (teTeX
maintainers) made no changes, we suspected that it's a change in libpng,
but there were no changes that could cause this, either.
The gimp is currently
I see no reason why this package should be restricted to just PCs.
I wish to modify avi files on my Mac.
Well I see the one - I'm the maintainer of the packages and as well
as developer of avifile itself - I really don't have time to work
on all platforms - if you have time and
Package: avifile-utils
Version: 1:0.7.43.20050224-1
Severity: important
I see no reason why this package should be restricted to just PCs.
I wish to modify avi files on my Mac.
The main oddities of the powerpc port are:
1. byte order is big-endian, so casting and unions may be bad
2. the char
Subject: crash w/ Florida law
Package: xpdf-reader
Version: 3.00-13
Here is the Florida Administrative Code:
http://fac.dos.state.fl.us/faconline/chapter64.pdf
The index doesn't work too well. Try following the
instructions I was given for finding Chapter 64V-1,
the Vital Statistics code:
In
Subject: crash w/ Florida law
Package: xserver-common
Version: multiple
At least two people have managed to crash X by
trying to read the Florida law using xpdf.
-- instructions for trying it --
Here is the Florida Administrative Code:
On Sat, 2005-07-30 at 16:31 -0400, David Nusinow wrote:
reassign 320627 xserver-xorg
thanks
On Sat, Jul 30, 2005 at 02:10:55PM -0400, Albert Cahalan wrote:
At least two people have managed to crash X by
trying to read the Florida law using xpdf.
Hi Albert,
Could you do two things
On Thu, 2005-07-21 at 00:15 -0600, Sebastian Kuzminsky wrote:
Albert Cahalan [EMAIL PROTECTED] wrote:
Subject: missing /usr/bin/git
Package: cogito
Version: 0.11.3+20050610-1
Linus picked the name he picked, so that's the way it is.
His tool is important for Linux development
Subject: missing /usr/bin/git
Package: cogito
Version: 0.11.3+20050610-1
Linus picked the name he picked, so that's the way it is.
His tool is important for Linux development. Leaving git
out of the package is not at all good.
The relatively obscure GNU Interactive Tools will just
have to find a
Subject: name conflict
Package: git
Version: 4.3.20-7
Linus has chosen the name git for a tool that is now
critical to Linux development. The relatively obscure
GNU Interactive Tools should be renamed to avoid conflict.
(both package name and executable name)
--
To UNSUBSCRIBE, email to
Subject: writes when nothing should be written
Package: aptitude
Version: 0.2.15.9-2
The following command takes a long time to execute. It should read
very little, compute very little, and write absolutely nothing.
# aptitude install some-package-that-does-not-exist
Reading Package Lists...
Subject: no way to cancel everything
Package: aptitude
Version: 0.2.15.9-2
Well, I've looked high and low for this, expecting that of
course it must exist, but no luck. So if it does exist, then
consider this bug report as the need to document something.
It appears that there is no way to cancel
We're not going to restore the migration scripts, they
were impossible to get right.
So you can't make it perfect.
Surely you can migrate:
1. background color or image
2. mouse focus policy
3. desktop pager layout (4x2 for example)
4. taskbar location and thickness
--
To UNSUBSCRIBE,
Subject: more trouble deleting mail
Package: evolution
Version: 2.0.3-1.2
This time, I had plenty of disk space. :-)
While I don't have exact numbers, the problem
went something like this:
1. have 5100 messages in the Inbox
2. mark 100 messages for deletion (via a VFolder)
3. expunge
4. now 5200
So now the title is this:
Mails can't be deleted if there's not enough disk space
Well, true, but that's not really the big problem. This bug
causes several problems:
1. can not delete mail (minor)
2. database gets corrupt (grave)Ouch!
3. no error message about disk space problem
Subject: unable to delete mail
Package: evolution
Version: 2.0.3-1.2
Severity: grave
Evolution is unable to delete mail. This makes the package in question
unusable or mostly so, thus the severity. One can not simply keep getting
more mail without deleting any. Space is not infinite, so now I
Subject: slow screen update after delete
Package: evolution
Version: 2.0.3-1.2
When I hit the Del key, several seconds pass before the
strikeout line is drawn over the message. This is important
feedback that the Del key was accepted, and must not be delayed.
Probably some processing is being
Subject: unable to set X-Debbugs-CC: header
Package: evolution
Version: 2.0.3-1.2
It seems that evolution does not support custom headers.
If I'm wrong, then consider this bug to be a serious
usability issue. I've been using evolution for years
now, and I certainly haven't found a way to set
I so tried to use curent kernel headers:
/usr/include/linux - /usr/src/linux/innclude/linux
/usr/include/asm - /usr/src/linux/innclude/asm
This has destroyed your ability to compile C programs.
You'd better undo the damage. Raw kernel headers may
not be used with glibc. You need headers that
On Fri, 2005-01-28 at 00:53 +0100, Robert Millan wrote:
I'm attaching two patches, one with the debian-specific changes and another
with the upstream changes. I think this addresses all your concerns about
my previous patch.
There is simply no need to be patching minimal.c.
This file does not
On Wed, 2005-01-26 at 12:33 +0100, Robert Millan wrote:
On Tue, Jan 25, 2005 at 11:41:43PM -0500, Albert Cahalan wrote:
In general I'm moving away from PAGE_SIZE, but I
sure do wish to keep it in minimal.c. Note that
this file is not compiled in by default, and that
it already supports
On Wed, 2005-01-26 at 17:15 +0100, Robert Millan wrote:
On Wed, Jan 26, 2005 at 10:26:51AM -0500, Albert Cahalan wrote:
Eeew. The BSDisms in glibc never fail to sicken me.
I've noticed that signal() is broken (it should map
to the Linux system call, which correctly follows the
7th
On Thu, 2005-01-27 at 11:26 +1100, Craig Small wrote:
On Tue, Jan 25, 2005 at 10:45:50PM -0500, Albert Cahalan wrote:
Opteron systems require an x86-64 ps.
I don't understand what you mean by this? It just needs procps
recompilied with 64 bit enabled?
If so, the 64 bit people have been
On Wed, 2005-01-26 at 21:27 +0100, Robert Millan wrote:
On Wed, Jan 26, 2005 at 12:35:39PM -0500, Albert Cahalan wrote:
Before long, it'll probably be added to the standard.
The last time around, SIGSYS was added.
Just make the FreeBSD header files do this:
#define SIGPOLL 23
Opteron systems require an x86-64 ps.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Woah you're brave...
Adding a top-level common.h is wrong.
See the proc/*.h files, including proc/procps.h.
In general I'm moving away from PAGE_SIZE, but I
sure do wish to keep it in minimal.c. Note that
this file is not compiled in by default, and that
it already supports FreeBSD.
You should
Support for RT signals is easily detectable
through the SIGRTMIN macro. Of course, sig.c
should stop defining SIGRTMIN to a hardcoded value :)
SIGRTMIN is not supplied by older C libraries.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
88 matches
Mail list logo
