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,
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 a
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
Package: valgrind
Version: 1:3.2.3-1
Architecture: amd64
$ cat t.c
#include stdio.h
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
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 strpbrk+82: nopw %cs:0x0(%rax,%rax,1)
0x451c30 strpbrk+96: add$0x4,%rax
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
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
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
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
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
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.
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
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
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
14 matches
Mail list logo
