Michael Biebl wrote:
> halt is not supposed to poweroff the machine, that sysvinit's halt did
> that is a bug that was never fixed.
Excuse me, when I disagree. It is regulated as follows in initscripts:
/etc/defaults/halt:
HALT=poweroff
Thus there is no bug in sysvinit's halt, but /etc/default/h
Package: initscripts
Version: 2.88dsf-13.7
Description
In parallel execution of the init-scripts, a race between checkfs
and mdadm-raid is possible that makes checkfs fail because
/dev/md0 is not yet created by mdadm-raid if the raid-device
is listed with fsck in the fstab, too.
Possible Correct
Package: mdadm
Version: 3.1.4-1+8efb9d1
Lately, an otherwise good array now suddenly fails to be assembled at boot time:
May 19 09:19:35 x64 kernel: md: Waiting for all devices to be available before
autodetect
May 19 09:19:35 x64 kernel: md: If you don't use raid, use raid=noautodetect
May 19 0
Package: sane-utils
Architecture: amd64
Version: 1.0.21-1
Basically, scanning persistently fails with "sane_start: Invalid argument".
I did a full reinstallation, so i might have lost some manual configurations,
but i doubt.
Earlier, the scanner worked well and was actually always a no-brainer.
Thomas,
(thank you for maintaining ncurses for so long.)
> But doing that, some features of ncurses (like any curses implementation)
> would not work. In short the _nc_freeall, etc., are only useful for
> debugging, not for a production library.
But this precisely is the point i do not underst
Hi,
i stumbled over this bug, too, and write to ask what the state of resolution is.
The libncurses5-dbg is not distributed with --disable-leaks, at time of writing.
If no semantic issues are know i would suggest not only to build the debugging
library with --disable-leaks, but the production lib
vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
==18028== valgrind: Unrecognised instruction at address 0x451C22.
(gdb) info symbol 0x451c22
strpbrk + 82 in section .text
(gdb) x/2i 0x451c22
0x451c22 : nopw %cs:0x0(%rax,%rax,1)
0x451c30 : add$0x4,%rax
(gdb) x/14bx strpbrk
Package: valgrind
Version: 1:3.2.3-1
Architecture: amd64
$ cat t.c
#include
int main()
{
printf("Hello World!\n");
return 0;
}
I compiled things static for a little more diagnostics, i.e. function names
below.
Basically same results with a dynamic binary. E.g. "valgrind ls"
$ cc -Wall -O2
Package: nowebm
Version: 2.11b-1.4
Some, but not all manual pages are empty:
-rw-r--r-- 1 root root 27 Sep 15 16:26 /usr/share/man/man1/cpif.1.gz
-rw-r--r-- 1 root root 28 Sep 15 16:26 /usr/share/man/man1/noweb.1.gz
-rw-r--r-- 1 root root 34 Sep 15 16:26 /usr/share/man/man1/nuweb2noweb.1.gz
-rw-r
Petter,
On Monday 11 September 2006 00:56, Petter Reinholdtsen wrote:
> Actually, it is probably the same as bug #386500.
> If it work, please let us know, so we can merge this bug into #386500
> and close it.
I ran the script you posted for the above bug.
And yes - it did. Case closed. Thanks
Package: initscripts
Distribution: unstable
Hi,
perhaps related to the bug #386347, something different happend,
also related to /dev/shm.
- /etc/network/run is a link to /dev/shm/network
- /etc/network/ifstate is a link to run/ifstate
Now the /dev/shm/network directory is not longer
created, m
Package: vim-full
Version: 7.0.17
Vim appears as if compiled with a wrong default path, i.e.
/usr/local/share/vim instead of /usr/share/vim/vimcurrent
/etc/vimrc is not sourced for unknown, but perhaps likely
reason. When sourced manually, it complains about files not found.
~/.vimrc would be sou
Stefano,
> Are you sure you are invoking Vim as 'vim', as in the example above, or
> are you invoking it as 'vi'? In the latter case what you got is the
> intended behaviour (see the latest NEWS items).
You hit the nail right on the top!
Thanks - the problem was unobvious for me and since i use
Package: vim
Version: 1:7.0-017+3
The configuration is now in /etc/vimrc and /usr/share/vim/vim70/debian.vim
But changing something in any of these files does not have any effect.
Putting something into ~/.vimrc is recognized, but it starts from something
so minimal, that the program cannot be us
14 matches
Mail list logo
