Aleksey Cheusov | 1 Nov 2008 01:20
Picon
Favicon

Re: bin/39466: /bin/sh: eval and redirections

The following reply was made to PR bin/39466; it has been noted by GNATS.

From: Aleksey Cheusov <cheusov <at> tut.by>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: bin/39466: /bin/sh: eval and redirections
Date: Fri, 31 Oct 2008 22:30:05 +0200

 I think this bug is more serious than I thought before.

    ~>cat /home/cheusov/tmp/1.sh
    #!/bin/sh

    cat < /dev/null > /not/exist
    echo $?
    ~>/home/cheusov/tmp/1.sh        
    /home/cheusov/tmp/1.sh: cannot create /not/exist: directory nonexistent
    0
    ~>

 HINT: commands that do not need fork (built-ins, like echo, printf etc.)
 work properly.

 -- 
 Best regards, Aleksey Cheusov.

Aleksey Cheusov | 1 Nov 2008 01:20
Picon
Favicon

Re: bin/39709: improvements for '/bin/sh -x'

The following reply was made to PR bin/39709; it has been noted by GNATS.

From: Aleksey Cheusov <cheusov <at> tut.by>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: bin/39709: improvements for '/bin/sh -x'
Date: Fri, 31 Oct 2008 22:31:43 +0200

 The patch below improves '/bin/sh -x' output.
 Demo:

     0 ~>cat /home/cheusov/tmp/1.sh 
     #!/bin/sh

     echo a
     echo b c 'd e'
     echo 'a b' c '' '"'
     echo "'"
     echo "aaa'bbb"
     0 ~>/bin/sh -x /home/cheusov/tmp/1.sh # original shell
     + echo a
     a
     + echo b c d e
     b c d e
     + echo a b c  "
     a b c  "
     + echo '
     '
     + echo aaa'bbb
     aaa'bbb
(Continue reading)

dholland | 1 Nov 2008 05:53
Picon

Re: bin/39732 (ping6: It takes interval seconds to send the first echo-request)

Synopsis: ping6: It takes interval seconds to send the first echo-request

State-Changed-From-To: pending-pullups-≥closed
State-Changed-By: dholland <at> NetBSD.org
State-Changed-When: Sat, 01 Nov 2008 04:53:17 +0000
State-Changed-Why:
fixed, thanks for the report

Alan Barrett | 1 Nov 2008 12:59
Gravatar

Re: misc/39737: the build attempts to run autoconf/automake/autoheader

On Sun, 12 Oct 2008, apb <at> cequrux.com wrote:
>         Some makefiles contain rules that attempt to run autoconf,
>         automake, autoheader, and similar tools, depending on the time
>         stamps of various files.  If the source tree is read-only, this
>         will fail.  If the source tree is writable, it will cause files
>         to be overwritten, or unwanted files to be created.
 [...]
> 	For a workaround, run the following script and commit the results.

At present I am using the following workaround to ensure that all
"configure" and "Makefile" files are newer than the *.in files from
which they are generated, and similarly to ensuer that *.in files are
newer than *.ac or *.am files.

for pattern in '*.ac' '*.am' '*.in' 'configure' 'Makefile' ; do
    echo "$pattern"
    find . -name "$pattern" -exec touch \{\} \+
    sleep 1
done

--apb (Alan Barrett)

mlelstv | 1 Nov 2008 13:35
Picon

lib/39846: netbsd-5 build failure in compat/lib

>Number:         39846
>Category:       lib
>Synopsis:       netbsd-5 build failure in compat/lib
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Nov 01 12:35:00 +0000 2008
>Originator:     Michael van Elst
>Release:        netbsd-5
>Organization:
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."
>Environment:
	
	
System: NetBSD henery 4.0_STABLE NetBSD 4.0_STABLE (HENERY) #1: Sun Aug 3 10:27:48 CEST 2008
mlelstv <at> henery:/home/netbsd4/obj.i386/home/netbsd4/src/sys/arch/i386/compile/HENERY i386
Architecture: i386
Machine: i386
>Description:
Cross-building netbsd-5/amd64 fails with

cleandir ===> compat/lib/libcrypto_idea
cd: can't cd to /home/netbsd5/src/compat/lib/libcrypto_idea
(Continue reading)

mrg | 1 Nov 2008 19:03
Picon

Re: lib/39846 (netbsd-5 build failure in compat/lib)

Synopsis: netbsd-5 build failure in compat/lib

Responsible-Changed-From-To: lib-bug-people-≥mrg
Responsible-Changed-By: mrg <at> NetBSD.org
Responsible-Changed-When: Sat, 01 Nov 2008 18:03:04 +0000
Responsible-Changed-Why:
take.

dholland | 1 Nov 2008 19:56
Picon

Re: kern/32297 (when wep is activated transfers are 3 to 4 times slower)

Synopsis: when wep is activated transfers are 3 to 4 times slower

State-Changed-From-To: open->feedback
State-Changed-By: dholland <at> NetBSD.org
State-Changed-When: Sat, 01 Nov 2008 18:56:18 +0000
State-Changed-Why:
Since you were using current at the time... does this happen with 4.0 or
recent current? (Or 3.1...)

Also, what speed machine(s) were you using? Crypto sometimes does bog down
old hardware.

dholland | 1 Nov 2008 20:08
Picon

Re: kern/32297 (when wep is activated transfers are 3 to 4 times slower)

Synopsis: when wep is activated transfers are 3 to 4 times slower

State-Changed-From-To: feedback->open
State-Changed-By: dholland <at> NetBSD.org
State-Changed-When: Sat, 01 Nov 2008 19:08:01 +0000
State-Changed-Why:
Feedback mail bounced. Anyone tried WEP recently and want to comment? Or
do we not care about WEP? I'm also inclined to close this because the PR
doesn't say what hardware was in use and that's sort of critical...

www.NetBSD.org update | 1 Nov 2008 21:01
Picon

NetBSD Nightly Trouble Ticket Report

There are 4623 non-confidential bugs in 52 categories.

Category             critical  serious non-crit    TOTAL           Median TTC
admin                       0        1        0        1         12d 03:31:17
bin                        19      221      330      570         25d 05:42:00
install                    19       46       48      113      7m 24d 10:35:04
kern                      214      776      483     1473      2m  4d 02:19:58
lib                         7       58       85      150         16d 00:25:41
misc                        3       31      122      156          9d 10:06:27
pkg                       118      586      684     1388         10d 03:47:44
port-acorn26                0        2        2        4             12:28:42
port-acorn32                0        3        3        6  1y  4m 28d 05:06:42
port-alpha                 18       34       18       70      5m 22d 13:02:30
port-amd64                 15       19        9       43      1m  3d 23:24:14
port-amiga                  2        6        8       16      1m  4d 23:54:21
port-arc                    0        1        0        1  3y  4m 25d 19:05:35
port-arm                    3        6        2       11      3m  6d 21:39:44
port-atari                  2        1        0        3          5d 22:03:50
port-bebox                  0        1        0        1          5d 04:32:53
port-cats                   0        2        0        2      3m 23d 06:15:06
port-evbarm                 0        1        2        3          8d 12:01:31
port-evbmips                0        1        4        5      1m 25d 20:33:17
port-evbppc                 3        1        0        4      5m 27d 10:10:17
port-hp300                  1        0        1        2         18d 05:04:38
port-hp700                  1        0        1        2      7m 24d 16:11:25
port-hpcarm                 3        1        2        6      4m 28d 01:42:18
port-hpcmips                1        6        8       15         25d 10:51:04
port-hpcsh                  0        1        2        3      4m  1d 17:29:07
port-i386                  30       81       60      171      5m 29d 00:36:34
port-ia64                   0        0        1        1                  n/a
(Continue reading)

dholland | 1 Nov 2008 21:08
Picon

Re: kern/32297 (when wep is activated transfers are 3 to 4 times slower)

Synopsis: when wep is activated transfers are 3 to 4 times slower

State-Changed-From-To: open->closed
State-Changed-By: dholland <at> NetBSD.org
State-Changed-When: Sat, 01 Nov 2008 20:08:06 +0000
State-Changed-Why:
Conclusion: we do still mostly care about WEP, but this PR doesn't say what
network card was involved so there's nothing that can be done with it. Also,
such behavior is often a hardware or link-level issue.


Gmane