Bug#284274: Patch for the hardlink replacement bug request
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, remove the temporary file. I suggest temporary names that look like these: .fdupes-vtYoH1PGPa4lj^LIOfL_i~ .fdupes-wz_7uNXC2R4-ftNq-gl,Z~ .fdupes-kf9_9EQmw-v0nv_-HcyKS~ .fdupes-BTR6AlGWjz@rVSC^+@j+-~ .fdupes--SaeXuxNfj1U0mltgmWNN~ (dotfile, string fdupes, 128 random bits, tilde on end, and nothing that would be likely to trip up a bash shell) Note that you can't hope to support all the crazy things that exist in current and **future** kernels. There are numerous security modules, mount --bind tricks such as file-on-file mounting, union filesystems, network fs servers running on non-Linux systems, and so on. You have to draw the line somewhere; just make a note in the man page that the tool is intended for single-user use in non-crazy situations. Perfection is the enemy of good; we need this option working again. Right now I'm desperately rewriting this tool as a pile of nasty shell scripts, and I assure you that I totally don't care about cross-filesystem issues. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689278: kill won't handle a negative PID
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 signal to every pid listed -signal, -s, --signal signal specify the signal to be sent -l, --list=[signal] list all signal names, or convert one to a name -L, --tablelist all signal names in a nice table -h, --help display this help and exit -V, --version output version information and exit For more details see kill(1). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
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 needs to do. This is of course a horrid bug. I'm fighting it right now. I install a zam.mo file, nothing else, and I damn well expect that file to get used for messages! Obviously, it's UTF-8. Obviously, I expect towupper() to follow Unicode defaults. You can build-depend on the locales package and generate the locales you want locally, using LOCPATH to reference them. There's no need for Debian to guarantee the presence of a particular locale ahead of time - particularly one that isn't actually useful to end users, as C.UTF-8 would be. Unless plain C goes UTF-8, that's exactly the locale I need. The stupid broken en_US.UTF-8 fucks up the sort order. Granted, fixing en_US.UTF-8 would be sweet, but it may be far too late. We really need a do-nothing locale that follows the Unicode spec using the UTF-8 encoding. We could also use a do-nothing locale that follows the Unicode spec using the Latin-1 encoding. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: Subject: Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
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 LANGUAGE, and only set LC_CTYPE to C.UTF-8 to get old behaviour but with UTF-8 (and mbrtowc and iswctype and and and) available. Isn't setting LC_ALL=C.UTF-8 going to be about the same and less work? I'm genuinely interested if that would behave any different to what you said (unsetting all, setting LC_CTYPE). % sudo localedef -c -i POSIX -f UTF-8 C.UTF-8 % LANG=C.UTF8 locale charmap UTF-8 % LANG=C locale charmap ANSI_X3.4-1968 This appears to work correctly at first glance. However, I would ideally like the C/POSIX locales to be UTF-8 by default as on other systems (with a C.ASCII variant if required). By far the most critical thing is that the wctype.h functions work in the normal Unicode manner, with wchar_t assumed to be purely Unicode. This means iswupper() works, towupper() works, etc. This applies for locales called , C, and some-unknown-junk. The only possible exception would be when there are environment variables set which are known to need something else. Unrecognized locales and all other defaults have to support full Unicode. Note that none of the above necessarily requires UTF-8, though UTF-8 seems desirable. You could use Latin-1 and still have wchar_t work. This could all be configurable of course. Suppose /etc/locale had: UTF-8# setlocale with and no environment variables C Latin-1 # if the C locale is specifically requested unknown UTF-8 # if we don't recognize the locale broken UTF-8# if parts of the locale info are missing/broken Right now, gettext doesn't even distinguish those cases. This could be considered part of the problem. When I put a zam.mo file (Zapotec) in the right place and set LC_ALL to zam, I get the C locale!!! Any imperfection in a locale results in C, as ASCII as can be. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: Subject: Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
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 one day be able to categorically state that Debian will by default assume that character is unicode, encoded according to UTF-8. Damn right. The obscure languages of the world are numerous. Unlike the languages of countries that were wealthy enough to participate in native-language computing prior to UTF-8, these less-popular languages are getting done in UTF-8. We mostly aren't inventing new incompatible encodings. In such an environment, with a C.UTF-8 encoding selected, when I start a word processing program and insert an a-umlaut in there, I would expect that my file will be written with a UTF-8 encoded unicode character in it. I would not expect that if I sort the lines in that file, that the lines beginning with a-umlaut would sort before 'z'. Right... I would not expect that if I grep such a file for '^[[:alpha:]]$' that my a-umlaut line would appear. No. It's a letter in the Unicode spec. The proposal, at this stage is only that the C.UTF-8 locale is *installed* and *available* by default. Not that it *be* the default, but that it *be there* as a default. People will naturally continue to be free to uninstall it, or to leave their locale to 'C'. What if you don't set your locale to anything, or if you set it to something that isn't recognized? You should get UTF-8 in any of those cases. The mechanism isn't so important. It could be that the fallback locale used by gettext is no longer C (perhaps C.UTF-8), or it could be that the C locale does UTF-8. LC_ALL=pirate -- you get UTF-8, with messages from pirate.mo Yes, I think that the C.UTF-8 locale offers something different that the C locale doesn't. Primarily it offers us a way out of the current default encodings which are legacy encodings, without jumping boots and all into a world where suddenly our sort ordering is changed, and our users are screaming at us that en_US.UTF-8 is wrong for *them*, or that 'sort' is suddenly putting 'A' next to 'a' and all of their legacy shell scripts expect are broken because they expect a different behaviour. I believe that the list above might be the set of smallest useful incremental changes in this process. I would really like to see that second step taken too, where the default locale is set to the most basic UTF-8 locale possible, but I'm happy to see a second bug and further discussion, if that's what we need to do to get agreement. There are different meanings of default. By default, the locale should not be set in the environment. That should give UTF-8. It could map to C, C.UTF-8, (nil), or whatever. I still think that en_US.UTF-8 is the right default (note: I'm not a US citizen, nor I speak English). As a US citizen who does speak English, I guess I'm an authority on the en_US.UTF-8 locale. It is offensively defective. It sorts stuff in a crazy order designed by some moronic committee. I doubt it even accepts Cyrillic and Korean as having letters. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: Subject: Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
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 iswprint() to return non-zero for a Cyrillic character, a Korean character, etc. Debian shouldn't be setting locale-related environment variables unless the user specifically chooses. The implementation-specific defaults, applied in the absense of any environment variables, should support Unicode. * All ISO8859 locales are moved to a new locales-legacy-encodings package. This encoding is used also on CD/, floppy, remote filesystems, USB pens, on a lot of internet pages, etc. Nope. It's actually UTF-16 in VFAT, Joliet, CIFS, and so on. Linux has mount options to control how that gets make POSIX-compatible. You can choose UTF-8. (this should be Debian's default) But an ASCII7 C encoding allow you to do the same things. It doesn't forbid 8 bit characters (thus UTF-8). Unix is transparent on characters (i.e. binary and text are the same, you can grep binaries, ...). So scripts should use LANG=C on most cases. That leaves iswprint() and towupper() broken. (not that it must) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550009: memset
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 performance-critical code in all of procps. Adding a memset is not good. Even the xcalloc isn't such a good idea; it really should be a plain malloc. (and now I know why I've been getting bombed with backtraces, grrr...) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550009: memset
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 like that, with likely/unlikely on the test -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#450758: can't please everybody :-(
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, SysV, etc. This would need to be retested. (help wanted) I happen to also find the new behavior irritating. Got anything for me to say to the people who will surely scream at me if I change this back? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460331: bad Hz on ARM
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 have been some non-glibc ones that messed up the stack prior to calling main. The ELF notes were thus unavailable, causing procps to use the obsolete code that you see failing. My second suspicion is that you aren't using ELF. Might you also lack an MMU? If so you must be in considerable pain, as ps likes to mmap() a huge chunk of memory for the output buffer. ELF is the norm for 2.6.xx kernels. You might prefer the minimal.c version that can be found in the procps source package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421495: this is a kernel bug
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 were reporting interrupt 0 (pic), there would be a huge pile of bug reports from non-x86 users. There would even be a huge pile of bug reports from x86 users, because interrupt includes things like disk and network interrupts. The first number on the intr line in /proc/stat is the total sum. Interrupt 0 comes next, being from any source (PIC or not) that the CPU will interpret as interrupt 0. You believe that the APIC local interrupt counts as an interrupt. I tend to think that you are correct, but the kernel code doesn't count these. See the kernel's show_stat function, sum variable, in the fs/proc/proc_misc.c file. That's what vmstat reports. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430427: ps output order
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 this obvious. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416976: xterm and bash
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 like a bug. This signal should be kernel-generated. There does not appear to be a legitimate reason for xterm to be sending this signal. The rxvt code is correct IMHO. So I guess the xterm package needs a clone of this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469600: readdir with too many tasks
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. This can not be a problem for any 32-bit port. Such ports have a kernel limit that stops you. This is a fairly insane config. If you actually need it, then your app needs a redesign. If you don't need it, then you are wasting memory and screen space. Such PID numbers are not at all fun to type. This glibc translation is foul, evil, and wrong. It has caused numerous bugs over the years. For example, processes may go missing. You also get extra system calls being made. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457911: ld.so error message is crap
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 setuid b. 32-bit loaded into 64-bit, etc. Neither of those applies to me, although LD_PRELOAD is in use. At minimum, I expect messages like this: ignored for setuid/setgid ignored for architecture mismatch ignored for non-execute file ignored for file not found ignored for lack of permission to read ignored for lack of memory ignored for not being a shared object etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442819: more magic
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 \1\0\0\0\0\0\0\300\0\2\0\0 Marvell Libertas firmware # uncompressed 5:6:5 HighColor image for OLPC XO firmware icons 0 string C565 OLPC firmware icon image data 4 leshort x %u x 6 leshort x %u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438956: sh4al-dsp fails testing too
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 of=random-blob for i in `objdump --help | egrep supported.arch` ; do if objdump -w -z -D --prefix-addresses --show-raw-insn -b binary --architecture=$i random-blob ; then echo TRUE $i ; else echo FALSE $i ; fi ; done | egrep 'TRUE|FALSE' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438956: ELF too
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]
Bug#438956: backtrace
$ 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 is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-linux-gnu... (no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /usr/bin/objdump -D r (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) r: file format elf32-littlearm Disassembly of section .000: .000: Program received signal SIGSEGV, Segmentation fault. 0x0fefa01c in ?? () from /usr/lib/libopcodes-2.17.90-multiarch.20070812.so (gdb) bt #0 0x0fefa01c in ?? () from /usr/lib/libopcodes-2.17.90-multiarch.20070812.so #1 0x0fef9ef0 in ?? () from /usr/lib/libopcodes-2.17.90-multiarch.20070812.so #2 0x10009364 in ?? () #3 0x0fc5e938 in bfd_map_over_sections () from /usr/lib/libbfd-2.17.90-multiarch.20070812.so #4 0x10006714 in ?? () #5 0x10007308 in ?? () #6 0x10007498 in ?? () #7 0x1000767c in ?? () #8 0x0fa95340 in ?? () from /lib/libc.so.6 #9 0x0fa95584 in __libc_start_main () from /lib/libc.so.6 #10 0x in ?? () (gdb) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438956: crash when disassembling ARM code
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 case it matters, I'm on PowerPC. (32-bit, big-endian, with char being unsigned by default) $ objdump -D --target=binary -EL -z -w --architecture=arm /tmp/my-file /tmp/my-file: file format binary Disassembly of section .data: .data: Segmentation fault $ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378157: ELF notes
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]
Bug#386457: slab cache
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 allocations. (like a malloc for kernel use) Sometimes some of these allocations will be freed when you need memory for something else. There is no way to tell. Unless performance is going bad, there really isn't any reason to worry. Memory usage values are never going to be perfect or even close; getting them closer would cost performance! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421390: [Pkg-kbd-devel] Bug#421390: I want the tools, not your damn font!
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, as I was
using a kernel-supplied framebuffer font that wasn't available.
You have four options:
1. use the font face VGA16 of console-setup which is similar to the
kernel font.
Nope, that's 8 pixels wide. The kernel font is 12x22.
2. Use a line FONT=/usr/share/consolefonts/somefont in
/etc/default/console-setup in order to load a non-console-setup
font.
3. Remove/deactivate /etc/rcS.d/S49console-setup and leave only
S06keyboard-setup
AFAIK, it'll get reactivated every time I upgrade.
4. Remove console-setup entirely
Eh, yes. I'll probably be installing from source. :-(
An 8-pixel-wide font is no good for me. I'm sure other people
have nice 9x16 VGA ROM fonts they'd like to keep. (can you even
handle a 9-pixel-wide VGA font correctly?)
If you use a framebuffer, you don't have a 9x16 font. If framebuffer
is not used, then 9x16 fonts are handled correctly.
Right, I'm using 12x22.
The font file format lacks a flag to indicate that a font is
a VGA-compatible 9x16. How does it work? Normal 9x16
fonts may have arbitrary pixels in the 9th column, while
normal 8x16 fonts really shouldn't be given a 9th column.
In any case, DO NOT LOAD A FONT BY DEFAULT
While it would be useful to have a configuration option to tell
console-setup not to load a font (and maybe I will implement this in
some future version), I doubt that most people need such a feature.
Sure they would, because people like to install all packages.
Just as installing a TFTP server doesn't mean it should run
(serving / insecurely to the world), installing console tools
doesn't mean it should run.
The most serious problem is in unicode_start, which should just issue
the command to put the console in UTF-8 mode without touching the
console font.
I agree here with you at 100%. Both kbd and console-tools have a
version of unicode_start and any change in this utility has to be
coordinated between the two packages.
The font-loading behavior could remain if a font is specified.
Then if you pass ${CONSOLE_FONT} on the command line
and it is unset by default, you'll get the right behavior.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421390: I want the tools, not your damn font!
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? /dev/tty?
since ${CONSOLE_FONT} contains the font chosen by the user.
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, as I was
using a kernel-supplied framebuffer font that wasn't available.
An 8-pixel-wide font is no good for me. I'm sure other people
have nice 9x16 VGA ROM fonts they'd like to keep. (can you even
handle a 9-pixel-wide VGA font correctly?) In any case, DO NOT LOAD
A FONT BY DEFAULT
The most serious problem is in unicode_start, which should just issue
the command to put the console in UTF-8 mode without touching the
console font.
It might also be wrong to be putting the console in UTF-8 mode,
but that's at least debatable.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295270: no, really, this is grave
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 other words, permanent data loss is near certain. Until this is fixed, evolution really shouldn't be installable via debian-stable or debian-testing. Destroying people's email does horrible things for Linux's image. (dirty hack: put a fix this button on the error dialog) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335079: not fixed
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]
Bug#353086: suggested implementation
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 PROCESS before releasing a lock. Locking a file must be privileged of course, to reduce local denial-of-service annoyances. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369427: not fixed
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 install a library package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382748: more info
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 foo (void) { extern int bar; return bar; }' conftest.c
$ gcc -S conftest.c -fpic
$ if grep '[EMAIL PROTECTED]' conftest.s /dev/null 21;
then echo Secure ; fi
$
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279168: closed by Chris Lawrence [EMAIL PROTECTED] (Fixed)
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 verify that the mail goes through, the bug is certainly not fixed. There are several ways to fix this: a. poll the bugs.debian.org web site. b. do a direct SMTP connection yourself c. do some other protocol, like FTP or HTTP d. write a custom protocol for the job Until you get back a positive response from the Debian server, you have no idea what happened. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279168: closed by Chris Lawrence [EMAIL PROTECTED] (Fixed)
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 very good tradeoff. So an MTA is not allowed to have a bug? :-) Spam filters seem to eat half the legit email these days. There might be several on the path to bugs.debian.org. Supposing that the MTA is indeed misconfigured by the user's own action (can not blame Debian config), so what? It's still important to deliver the bug report. There is no need for reportbug to diagnose broken mail systems; there is only a need to deliver the bug report if at all possible and ensure that silent failure can never happen. Feel free to tell the user It looks like the email was eaten by a grue. before offering to try some other method. You may reopen the report, but it will probably be downgraded and marked wontfix. Please do reopen it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382741: note.GNU-stack missing on powerpc
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382746: powerpc libgcc writes code to the stack
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 or a dangerous transition from write to execute. It'd be an improvement though. Doing write+execute may be better, allowing the OS to locate the page within a segment (256 MiB chunk on PowerPC) which already has executable pages. A better method would be to supply a page full of trampoline functions in libgcc. Each function would: 1. examine its own address 2. map from the page of code to a page of data 3. use that data to implement the trampoline Trampoline setup would thus involve filling in the data and choosing the matching function to use. Once libgcc stops putting code on the stack, gcc needs to mark all executables as not requiring an executable stack. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382748: broken -msecure-plt and -mbss-plt on powerpc
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 [EMAIL PROTECTED]
Bug#382748: BTW, bug 382748 requires new binaries
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]
Bug#370361: does not detect version mismatch
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 release just crash with SEGV and no explanation. To avoid future problems like this, valgrind ought to detect the version mismatch. Note that valgrind was working fine until the upgrade. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374223: ignore MIME info if it is useless
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 MIME type is something that firefox does not have info for, then do as if firefox were just browsing the filesystem with a file:///tmp/filename.foo URL. Note that guessing is probably more accurate in all cases. The web server probably just maps file extensions to MIME, and probably does a bad job of it. The web server has no knowlege of what the client's MIME database contains. Quite sensibly, IE always makes a local determination of the MIME type, no matter what the web server provides. I'm just asking to do that when the web server provides a MIME type that is unhelpful, not all the time. Also, note that the application/octet-stream type really just means that the server has no clue. Try to determine the type by other means (magic and/or file extension) so that something useful can be done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339085: this matters
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 justification. Normally I'd say the POSIXLY_CORRECT environment variable would be useful, but this isn't even a correct interpretation of POSIX! As for Solaris, /usr/xpg4/bin is not normally used. Sun put it there as a checkbox item. It's about as relevant as the POSIX subsystem provided with Windows. Then again, that points to a solution. If the Solaris way is any example to be used, then we can do likewise. Install the defective tail and head in /usr/xpg4/bin where it won't bother anybody. SGI tends to require that an environment variable _XPG be set to a positive integer. (not sure on this specific issue) Setting UNIX95 to 1 (as HP sometimes uses) is OK too. The invalid suffix character in obsolescent option message from tail ++foo is crap. If the + is followed by a non-digit, then obviously the tradtitional syntax is not being used. I sure hope tail -6 foo and head -6 foo are not also getting hit by this. Last I argued with upstream, they were. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#166155: hex
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 tools like mknod that probably don't accept hex yet. The proper hex format varies by OS. Ones I know: %03x:%05x Linux (12,20 split) %02x:%06x HP-UX (8,25 split) %04x:%05x SysV(14,18 split) %04x:%04x BSD (16,16 split) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374223: ignore MIME info if it is useless
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 problem with a patch or config file in a bugzilla. It happens elsewhere too, commonly. When there is no viewer for the given MIME type, firefox should use file extensions and file magic to determine the MIME type. There is a good chance that the new MIME type will have a viewer. Note that IE will _always_ prefer the file extension over the web server's MIME type, even if the web server provided a useful type. I don't expect this to go over all that well with the W3 cultists, but it sure would make more web sites work as intended. So I only ask that firefox attempt do do something useful when the server's MIME type isn't any good. BTW, the version is as displayed by aptitude. It seems to be truncated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374224: browser itself is not a viewer option
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 problem with a patch or config file in a bugzilla. It happens elsewhere too, commonly. The browser itself should be a choice. Very often, the file is plain old ASCII text. BTW, the version is as displayed by aptitude. It seems to be truncated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#120604: Just change it please, ASAP
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 be usable, but this is not. I didn't even guess that this was configurable until I checked for existing bug reports prior to submitting a new one. For anyone needing a quick hack, put the following line at the end of your ~/.aptitude/config file. aptitude::UI::Package-Display-Format %c%a%M%S %p %Z %21v%21V; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370361: crashes even w/o tool if dynamic linking
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 unusable or mostly so.
$ cat easy.c
int main(int argc, char *argv[]){
return 0;
}
$ gcc -s -O2 easy.c
$ valgrind --tool=none ./a.out
==357== Nulgrind, a binary JIT-compiler for Linux.
==357== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==357== Using valgrind-2.2.0-ppc, a program supervision framework for Linux.
==357== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==357== For more details, rerun with: -v
==357==
==357==
==357== Process terminating with default action of signal 11 (SIGSEGV)
==357== Access not within mapped region at address 0x100380
==357==at 0x254779F0: (within /lib/ld-2.3.6.so)
==357==
Segmentation fault
$ gcc -s -O2 -static easy.c
$ valgrind --tool=none ./a.out
==364== Nulgrind, a binary JIT-compiler for Linux.
==364== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==364== Using valgrind-2.2.0-ppc, a program supervision framework for Linux.
==364== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==364== For more details, rerun with: -v
==364==
==364==
$ ls -ldog /lib/*ld*.* /lib/*libc[^a-z]*.*
-rwxr-xr-x 1 106372 May 21 23:13 /lib/ld-2.3.6.so
lrwxrwxrwx 1 11 May 27 03:24 /lib/ld.so.1 - ld-2.3.6.so
-rwxr-xr-x 1 1280052 May 21 23:13 /lib/libc-2.3.6.so
lrwxrwxrwx 1 13 May 27 03:24 /lib/libc.so.6 - libc-2.3.6.so
$ uname -a
Linux cube 2.6.17-rc5 #1 PREEMPT Sat May 27 20:35:12 EDT 2006 ppc GNU/Linux
$ cat /proc/cpuinfo
processor : 0
cpu : 7400, altivec supported
temperature : 47-49 C (uncalibrated)
clock : 450.00MHz
revision: 2.9 (pvr 000c 0209)
bogomips: 49.53
timebase: 24907667
platform: PowerMac
machine : PowerMac5,1
motherboard : PowerMac5,1 MacRISC2 MacRISC Power Macintosh
detected as : 68 (PowerMac G4 Cube)
pmac flags : 0014
L2 cache: 1024K unified
pmac-generation : NewWorld
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369427: very badly named
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 code on the net did I realize that the so-called lib package ought to be installed for itself.
Bug#147187: xdelta hack
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 now. Dear my... what if I had the file request 0x7654321, or 0xfee15bad ? (consider both signed and unsigned integer overflow) The quick hack is probably to multiply the allocations by 2. You could use sizeof(void*)/sizeof(int) if you like. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324001: overlapping memcpy()
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 fetched from RAM. Use memmove() if you must have an overlap.
Bug#333479: this was a serious error
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 binaries.
Bug#368285: incompatible color
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 probably hate it too. Many terminals did have a black-on-white option, but I've never seen anybody using it. No matter what the terminal (true VT100, VT101, VT102, Wyse 50/60, VT220, VT320, VT510, VT525, Linux console, Sun console) I've never seen black-on-white actually used. The apps tend to break, especially when they try to use the newer color features. Text becomes unreadable. Think cyan-on-white and yellow-on-white. Eeeew. I won't even see white-on-white. White-on-black is good.
Bug#324001: overlapping memcpy()
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 for PowerPC: if 32-byte aligned, do fast copy else if 8-byte aligned do double copy else if 4-byte aligned do float copy else do byte copy Then, for each 32-byte cache line, the fast copy code does: 1. prefetch the source cache line 2. allocate the destination cache line as all zeroes 3. fetch the source cache line 4. store the destination cache line End result: it acts like bzero() when src==dst
Bug#324001: overlapping memcpy()
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 standards for both C99 and POSIX/UNIX state: If copying takes place between objects that overlap, the behavior is undefined. There wouldn't be a memmove() function if it weren't needed.
Bug#333479: this was a serious error
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. About the only thing stable is the kernel system call interface. Really, it's not cool to break old binaries. I was not the one who made the decision to remove libpng2. But without a clear bug report, I can't really say what the problem is. If there is a specific bug, can you file it? What do you mean by you lost all sorts of apps? I don't see how this long-closed bug somehow lost apps. Easy: old stuff needs libpng2 new stuff depends on stuff that conflicts with libpng2 user needs the new stuff, and wants to keep the old stuff Not upgrading would leave me with plenty of security holes, so that isn't an option.
Bug#353086: bad delay implementation
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. Choosing some numbers that seem like good defaults, the following is better: Add a token to a bucket once every 5 seconds, up to a max of 5 tokens in the bucket. Login attempts block until a token becomes available. A failed login removes a token. This way, slow and clumsy humans are unlikely to hit the delay. Automated attacks will quickly become rate-limited to 12/minute.
Bug#335079: the 1.2 release in debian-unstable fixes it
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.
Bug#335079: dropouts
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. http://www.debian.org/Bugs/Developer#severities I consulted that document when I filed the bug. Quoting from that document: grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. Well, yes indeed, the package is unusable. I can not really hold a conversation with such severe dropouts. I miss so many words that asking the other party to repeat is often not enough. Basically I am without a phone right now. So, according to Debian policy, this is a grave bug.
Bug#336710: don't do that
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 even worse, so we have this idea of not using the root account to do random odd unprivileged tasks. Some call it least privilege. Here's a classic disaster you'll love: rm -rf $FOO/* What if $FOO is not set?
Bug#293981: I think it's a doc bug and version difference
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 default. A patch for the man page would be helpful I guess.
Bug#329079: fixed in newer kernel
You need to upgrade your kernel.
Bug#335079: dropouts
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 the net. When doing IAX2 over the net, the other party does not hear (not hear, heh) dropouts. A tcpdump trace shows that packets are not getting sent to the IAXy. They never leave the computer. This is a Mac, with the MPC7400 PowerPC G4 CPU. So far I've tried two kernel configs: The first was 2.6.13.2, and the second was 2.6.13.4 with a 1000 HZ tick and that evil ztdummy.ko driver loaded. Nothing changed.
Bug#322821: libpng12-0: new version breaks pdflatex
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 that problem with imagemagick's convert(1) and gimp as well. But again? That's odd as 1.2.8rel-1.0.1 fixed that for me, and it works in 1.2.8rel-2 as well. Works in -4 as well, which one do you have installed? Gee, I don't know. It's a mess: libpng2 1.0.18-1 libpng12-dev 1.2.8rel-1 libpng10-01.0.18-1 libpng12-01.2.8rel-1 Possibly of interest: * gimp depends on libpng12-0 (= 1.2.8rel) Yet: * gdk-imlib1 depends on libpng10-0 (= 1.0.18) * imlib1 depends on libpng10-0 (= 1.0.18) * libgdk-pixbuf2 depends on libpng10-0 (= 1.0.18) * libpng2 depends on libpng10-0 (= 1.0.15-2)
Bug#322821: powerpc and s390: buildd environments screwed?
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 (libpng maintainer, again in the Cc) already said he had no idea either, except toolchain changes on the affected arches. Maybe Ryan has some insight as buildd admin? The obvious assumption would be that we've gone through an unintended ABI change. That's very bad. Oh well. It happened. Let's put it behind us. Life goes on. Not that the cause wouldn't be interesting of course.
Bug#322821: png problems on powerpc and s390 (was: Bug#322821: libpng12-0: new version breaks pdflatex)
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: Call to NULL write function I had that problem with imagemagick's convert(1) and gimp as well. But again? That's odd as 1.2.8rel-1.0.1 fixed that for me, and it works in 1.2.8rel-2 as well. Works in -4 as well, which one do you have installed? Maybe there's some unintentional ABI change because some padding in the png structures was different/wrong? It seems as if this problem might not be powerpc-specific, but also occur on s390: Being from EBCDIC land, s390 probably also has an unsigned char by default. (dang this is dumb - all Linux ports should use the same default) There's also endianness, but that would affect many more architectures. Alignment seems to be the same between ppc and i386. (not that I would know or care about bitfields)
Bug#322821: libpng12-0: new version breaks pdflatex
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.
Bug#322821: libpng12-0: new version breaks pdflatex
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 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 also get a dialog box like this: PNG image Message Error while saving '/tmp/foo.png'. Could not save image. GIMP Message Saving '/tmp/foo.png' failed: Plug-In could not save image OK
Bug#328558: avifile-utils unavailable for powerpc
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 knowledge and you want to help me with making this packages usable on PowerPC you are welcome - avifile is written portable and if it doens't work on bigendian machines it's obviously a stupid bug somewhere (and I know it used to work on PowerPC) - but as majority of people are using mplayer which has tons of developers across all the platforms - I'm just about happy I do handle update of libs and so on for avifile for i386 platform ;) I have players, though admittedly they are cruddy. I want the tools, not the player. I really just want to make snapshots. (best would be lossless extraction of I-frames to JPEG) Simply allowing non-x86 builds would be a great start. There should be a package for me to install, but there isn't. Perhaps it would work. Blocking the build makes sense for something like valgrind, where failure on non-x86 has very obvious and non-trivial reasons. Add albert to the SourceForge project if you'd like me to give that a try. I'm kind of busy with the procps, saturntools, and tuxpaint projects though.
Bug#328558: avifile-utils unavailable for powerpc
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 type is unsigned by default (use signed char as needed) Along with the problems you've already handled for the x86-64 port (data type sizes, lib64, and any abuse of assembly code), the above should cover pretty much everything needed to support all Linux ports. So you can consider this a request to allow building for all the other ports as well: alpha, hppa, sparc, mips...
Bug#320626: crash w/ Florida law
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 the menu on the left side, scroll all the way to the bottom to 64V-1. You will need Adobe Acrobat Reader 4.05+ to view these file. The index doesn't work right. In fact, xpdf spits out all sorts of errors. It seems that some sort of interpreter stack fails to grow as large as needed. On the debian-powerpc mailing list, Sean Neakums and Ken Moffat report: I just had a go at chapter64.pdf with xpdf and my X server crashed, which is impressive. I can't remember the last time I've had X crash. Damn, I wish I'd read further down the thread before I tried. Yeah, mine crashed too (on x86). A vulnerability triggered by malicious official documents. That's at least two bugs by my count (xpdf and X), and fixing one might hide the other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320627: crash w/ xpdf
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: 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 the menu on the left side, scroll all the way to the bottom to 64V-1. You will need Adobe Acrobat Reader 4.05+ to view these file. --- On the debian-powerpc mailing list, Sean Neakums and Ken Moffat report: I just had a go at chapter64.pdf with xpdf and my X server crashed, which is impressive. I can't remember the last time I've had X crash. Damn, I wish I'd read further down the thread before I tried. Yeah, mine crashed too (on x86). A vulnerability triggered by malicious official documents. That's at least two bugs by my count (xpdf and X), and fixing one might hide the other. I have filed an xpdf bug as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320627: crash w/ xpdf
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? Report this bug using reportbug, as it will attach a number of useful documents that will help us figure out what this bug is. No, but I have filed a bug against reportbug. :-( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279168 Also, install xserver-xorg-dbg and follow the instructions on using it to report problems in /usr/share/doc/x11-common/FAQ.gz (or FAQ.html). I'll merge this bug with the one you report then. Thank you! That's not going to help I think, since X doesn't crash for me. It crashes for two other people. In my case, xpdf spews error messages about overflowing an interpreter stack. The document comes up mostly OK, except that the index (left panel) is truncated. I'll Cc: both others. Hopefully they can provide the required debug info. They are: Ken Moffat [EMAIL PROTECTED] Sean Neakums [EMAIL PROTECTED] Given that two other people managed to crash X, I figure that chances are pretty good that X will crash for you too. I guess I'm just lucky. :-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316677: missing /usr/bin/git
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. Leaving git out of the package is not at all good. The relatively obscure GNU Interactive Tools will just have to find a new name. Thanks for your bug report, sorry it's taken me so long to respond. I'll contact the GNU Interactive Tools people and see what they think. I expect the rule of thumb of first come, first served will prevail in this situation, but maybe there's something cool we can do with /etc/alternatives or something. We'll see. That's not a decent rule. It wasn't used with pgrep. The old one moved, because the new pgrep is a popular command that Solaris and OpenBSD supply under the same name. Later tonight (hopefully) I'll upload a new version of the package which will include the git program, installed as /usr/bin/gt. Cogito's cg script is installed as /usr/bin/cog, to avoid a similar name conflict with the cgvg package. Yes it's gross, but it's what the debian-devel list chose when I asked them... Arrrgh!!! That's basically saying that people should install from source when I need to use these tools. I may as well uninstall the package now. I'm going to leave your bug open until a better solution is reached. Just have the package conflict, and give it a higher priority than the obscure stuff. People can just uninstall the obscure stuff, which they probably aren't using anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316677: missing /usr/bin/git
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 new name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316676: name conflict
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312920: writes when nothing should be written
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... Done Building Dependency Tree Reading extended state information Initializing package states... Done Couldn't find any package whose name or description matched some-package-that-does-not-exist The following packages have been kept back: amphetamine amphetamine-data anacron apmd apt-show-source apt-show-versions apt-utils armagetron bind bsdmainutils bugsquish bumprace-data byacc cgoban chromium-data craft cron debconf debconf-i18n debconf-utils debsums defendguin defendguin-data dhcp3-common dhcpcd dictionaries-common doom-wad-shareware eject esound-common exim fda g++ gcc gconf2 gedit gedit-common gettext-base gksu gpm grep-dctrl gtans gzip icewm icewm-common icewm-themes jester joe kernel-package lftp libadns1-bin liballegro4a libapm1 libaudio2 libbonobo-conf0 libdaemon0 libdb4.3 libexif10 libfont-afm-perl libft-perl libgconf11 libgconf2-4 libgimpprint1 libgksu1.2-0 libgksuui1.0-0 libglade-gnome0 libglade0 libglade2-0 libgmp3 libgnome-desktop-2 libgnome-pilot2 libgnome2-0 libgnome2-common libgnomecanvas2-0 libgnomecanvas2-common libgnomecups1.0-1 libgnomeprint2.2-0 libgnomeprint2.2-data libgnomeprintui2.2-0 libgnomeprintui2.2-common libgnomeui-0 libgnomeui-common libgnomevfs2-0 libgnomevfs2-common libgtk-perl libgtkhtml2-0 libgtop1 libguile9 libhfsp0 libltdl3 libmikmod2 libmp3-info-perl libnspr4 libpam-modules libpam0g libperl5.8 libqt3c102-mt libsdl-net1.2 libsigc++-2.0-0 libssl0.9.6 libstdc++2.10-glibc2.2 libstdc++5 libwrap0 libxml-parser-perl login lsh-client lsh-utils lsof lwm makedev mawk mol mol-modules-source mozilla-firefox mozilla-firefox-dom-inspector mozplugger mp3burn mtr multicd netcat passwd pdksh perl perl-base perl-modules perlmagick phalanx pipenightdreams popularity-contest portmap powermgmt-base python-imaging python2.3-imaging python2.3-numeric python2.4 python2.4-dev sl spider ssh supertux supertux-data tar tkfont ttf-thryomanes twm ulogd ulogd-pcap unclutter webmagick wing wing-data wmctrl xarchon xarchon-theme-default xbat xbl xboing xcruise xdemineur xdigger xdm xevil xfishtank xfstt xgalaga xgammon xjewel xjig xkeycaps xlockmore-gl xmahjongg xoids xonix xpat2 xpenguins xpuyopuyo xpuzzles xscorch xsok xsoldier xt xtokkaetama xvier zblast-data zblast-x11 zsh 0 packages upgraded, 0 newly installed, 0 to remove and 185 not upgraded. Need to get 0B of archives. After unpacking 0B will be used. Writing extended state information... Done Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312923: no way to cancel everything
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 all pending changes. Maybe, if aptitude hadn't been quit, I could do Ctrl-C to take care of the problem. This is sort of hinted at in the docs. If this is correct, it should be made clear. But in any case, that doesn't do the job once aptitude has already been quit in the normal way. I shouldn't have to quit anyway; there should be a command to kill all pending changes. When I do quit in the normal way, it should work like this: If no pending changes, quit without confirmation. Else offer a choice: a. do not quit b. discard pending changes c. try to perform the update d. quit, retaining pending changes (highly unusual) In general, I want a fresh start when I run aptitude. Maybe I was having problems with broken packages. I'd like such problems to just GO AWAY instead of haunting me. BTW, I ended up having to uninstall the broken gnome-core package to unwedge myself from a recent debian-unstable problem. Fortunately this was possible and seemingly harmless. I had to mark several other things as hold too. Ugh. I'd much rather have just canceled all pending changes, then gone on with a clean slate. (knowing to avoid messing with the broken package until it gets repaired by the maintainer) I had some completely unrelated things I wanted to update, but was stopped until I mucked around with picky details in the GNOME mess. I should have been able to put that problem aside by canceling all pending updates, nice and fast. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306321: perfection is the enemy of good
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297199: more trouble deleting mail
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 messages, with 200 marked to delete! 5. expunge 6. now 5300, with 300 marked to delete! That is, the to-be-deleted messages are in triplicate. Rather than deleting them, evolution reproduces them. Oh, that's cute. Offensive work-around hack: 1. kill evolution 2. run elm -f .evolution/mail/local/Inbox 3. delete messages using elm 4. manually delete mysterious database files 5. restart evolution, if still desired Obviously, evolution is an excellent Microsoft Outlook clone. IMHO, it would be irresponsible to allow this package into a Debian release. Mail reliability is serious business. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295270: bug title
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 (important) It's the database corruption problem that let me to report the bug and mark it grave. I can somewhat accept that evolution may have trouble when disk space is low, although deleting mail is particularly desirable in such cases! It is not even remotely acceptable that the database gets corrupted. The lack of an explanation is moderately bad. Google let me to this: https://www.redhat.com/archives/fedora-list/2004-October/msg00932.html So that is how I figured out what needed to be done. I was rather nervous deleting undocumented important-looking files. Nobody should ever need to do this. I think a better title would be: Mailbox database gets corrupted if disk space gets low To make this really clear, making more disk space did NOT solve the problem. Even with 500 MB free, evolution would not work. I had to delete the Inbox database files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295270: unable to delete mail
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 really can't be downloading my incoming mail. I have 6856 messages. In a vfolder with 627 messages, I select all but 44. I hit the Del key, marking the selected messages for deletion. I choose to Expunge the messages. I get the following dialog box: --- Error while Expunging folder. Error storing `~/.evolution/mail/local/Inbox (mbox)': Summary and folder mismatch, even after a sync. OK --- I would not be surprised to find that this is a regression. Back around the 1.1 to 1.3 releases, a similar procedure would cause evolution to crash. The 1.4 release worked. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295280: slow screen update after delete
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 done where it shouldn't be, although a general performance improvement would be welcome too. Evolution 1.4 handled things just fine, so this isn't an impossible task: I have 6856 messages. I have about a dozen vfolders, some of which use body-text matching. I have a 450 MHz Mac G4 with 512 MB of PC100. I'm having evolution use POP to fill the local mbox, deleting mail from the server as it is received. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295278: unable to set X-Debbugs-CC: header
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 headers. I think I've used versions 1.0, 1.1, 1.2, 1.3, 1.4, and 2.0. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292927: bug w/ top on hppa
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 have been modified to support non-kernel usage. Anyway... please report: ps --info cat /proc/stat ; sleep 10 ; cat /proc/stat file -s /proc/kcore file /bin/ps Also, is your clock keeping correct time? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290719: ps on kfreebsd-gnu
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 normally get compiled. As for the other change, I guess that's about right, but perhaps you could supply a Linux kernel version via /proc. Then, as you /proc becomes more capable, you just change the Linux version being reported. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290719: ps on kfreebsd-gnu
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 FreeBSD. Well, currently it hardcoded PAGE_SIZE to 4096 when undefined. I think it's better to get it from system headers as FreeBSD (and GNU/kFreeBSD) have it =) Perhaps. Note that minimal.c is intended to work with all sorts of wimpy C libraries: uClibc, klibc, newlib Many of these libraries lack sysctl(). BTW, what C library are you using? You should not remove stuff from the example sysctl.conf. It's commented out anyway. Are your comments wrt debian or upstream? In the debian package, my patch makes a copy of sysctl.conf. This way we only modify the sysctl.conf.kfreebsd-gnu version so that linux-gnu systems are not affected. (the linux-gnu defaults aren't much useful to kfreebsd's sysctl namespace). Oh, OK. I wasn't sure if that was a separate file or not. SIGPOLL is in the UNIX standard. SIGIO is not there. This suggests that FreeBSD is less of a UNIX than Linux is. :-) Please fix your kernel and/or libc. The glibc manual says this about SIGPOLL: This is a System V signal name, more or less similar to `SIGIO'. It is defined only for compatibility. ... where the last phrase isn't really true -- this is a bug indeed. 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 Edition and SysV behavior of unsetting the signal handler when it is called). Also, fputs() does not have the correct SysV return value. I sure wish the glibc hackers would realize that, if I wanted BSD, I would not be running Linux! SIGPWR is not Linux-specific. AIX, HP-UX, IRIX, and Solaris all have it. Hopefully it will get into the next revision of POSIX. Here is the Solaris 9 description: Name Value DefaultEvent SIGPWR 19 Ignore Power Fail or Restart The IRIX description is identical. Looks like *BSD systems and GNU/k*BSD derivatives don't have it. Is there any way to conditionalise its use in the code? Oh, I suppose, but can't you just implement SIGPWR? All the real UNIX systems have it. There should be one signal left out. Find what it is. Hopefully, the default action matches that of SIGPWR. If so, then just call that SIGPWR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290719: ps on kfreebsd-gnu
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 Edition and SysV behavior of unsetting the signal handler when it is called). Also, fputs() does not have the correct SysV return value. I sure wish the glibc hackers would realize that, if I wanted BSD, I would not be running Linux! Well, for other BSDisms like strlcpy/strlcat they have a different opinion. I don't mind adding BSD features. I do that myself, all the time, with procps. It's losing the Real UNIX features that gets on my nerves. The mistake with signal() was especially offensive, since Linux already had a syscall for that. Glibc is really the Hurd library though. :-( Oh, I suppose, but can't you just implement SIGPWR? All the real UNIX systems have it. There should be one signal left out. Find what it is. Hopefully, the default action matches that of SIGPWR. If so, then just call that SIGPWR. I could try.. but I'm not sure if FreeBSD upstream would accept a patch for that. I didn't see SIGPWR in any standard. 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 #define SIGPWR 29 #define SIGIO SIGPOLL #define SIGLOST SIGPWR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290757: user error
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 consistent in their lack of assistance so the bug can just sit there until one of them looks into it. Yes, exactly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290719: ps on kfreebsd-gnu
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 #define SIGPWR 29 #define SIGIO SIGPOLL #define SIGLOST SIGPWR Ok, I'll send another patch. What do you want to do with PAGE_SIZE? Currently there are two files that depend on it. For the next release, likely procps-3.2.6, only minimal.c will use PAGE_SIZE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290757: user error
Opteron systems require an x86-64 ps. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290719: ps on kfreebsd-gnu
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 not remove stuff from the example sysctl.conf. It's commented out anyway. SIGPOLL is in the UNIX standard. SIGIO is not there. This suggests that FreeBSD is less of a UNIX than Linux is. :-) Please fix your kernel and/or libc. Redefining LINUX_VERSION is a huge mistake. You may wish to change how linux_version_code is set though, perhaps based on __FreeBSD_kernel_version and some knowledge of how FreeBSD kernels match up with Linux kernels. Probably you want something like: linux_version_code = LINUX_VERSION(2,0,0); TAB3 is also part of the UNIX standard, in termios.h. It's not even part of the XSI feature set, but just a regular feature required of all POSIX systems. I can not find XTABS in the UNIX and POSIX standard. SIGPWR is not Linux-specific. AIX, HP-UX, IRIX, and Solaris all have it. Hopefully it will get into the next revision of POSIX. Here is the Solaris 9 description: Name Value DefaultEvent SIGPWR 19 Ignore Power Fail or Restart The IRIX description is identical. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291458: SIGRTMIN
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 [EMAIL PROTECTED]
