headers
Havard Eidnes | 5 Apr 2009 14:25
Picon

Re: Package binaries for NetBSD/alpha 3.1 / pkgsrc-2008Q4

Hi,

I've uploaded the results of a bulk rebuild for NetBSD/alpha
3.1 to

   ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/alpha/3.1_2008Q4/

A total of 2.1GB of packages were uploaded for a total count of
1318 packages.

The list packages available in new versions or which were not
available earlier is: bison-2.4.1nb1, dovecot-1.1.11, hal-0.5.11nb23,
liboil-0.3.15nb1, libsndfile-1.0.17nb5, mediawiki-1.13.5, mpack-1.6,
net-snmp-5.4.2.1nb1, optipng-0.6.2.1, p5-Readonly-XS-1.04nb3,
pdksh-5.2.14nb4, php5-imap-5.2.8nb5, png-1.2.35, privoxy-3.0.8nb2,
samba-3.0.32nb3, tor-0.2.0.34, typo3-4.2.6, and wireshark-1.0.6.

The source tree this was built from was updated Mar 10 2009, and the
packages were built on a system running 3.1_STABLE.  This is the last
update for this arch/version/branch from this corner; I'll next update
and build for the 2009Q1 packages.

Regards,

- Håvard
Permalink | Reply | 0 comments |
headers
Aaron B. | 5 Apr 2009 13:55

Semi-OT: DS10L Hardware Issues


Not exactly NetBSD related, but I do run (ran?) it on my DS10L before
this problem.

It currently refuses to boot, thowing out six beeps. The documentation
states this as 'Memory error (or bad checksum) detected.' I've swapped
the ram three different good pairs of sticks.

Any ideas of what to try next?

--

-- 
Aaron B. <sparked <at> zadzmo.org>
Permalink | Reply | 0 comments |
headers
Scott Ellis | 16 Apr 2009 00:51
Favicon

Free UDB (Multia) in San Diego

I'm doing some closet-cleaning, and am getting rid of my Multia.  It's 
free for the asking, and it's the 166MHz version with 64MB RAM, SCSI 
controller, and PCI slot (currently filled with a Matrox Millenium II, 
which is yours if you want it!).  I can throw in an NE2000 PCMCIA NIC if 
you like also.

The system works great under -current, including truecolor X11 using 
Xorg and the Matrox card.  The floppy drive sounds a little funny (I bet 
it doesn't work, but it probes okay!), and the CMOS battery has been 
replaced with three AA batteries (don't forget to change them!).  The 
300MB SCSI drive and netbooting both work fine, so it's easy to get up 
and running with NetBSD on it.

It's pretty heavy, so unless you want to pay exorbitant shipping fees, 
I'd prefer it go to a good home in San Diego, CA.  Shoot me an email if 
you're interested!

	ScottE
	scotte <at> warped.com
Permalink | Reply | 0 comments |
headers
Jarle Greipsland | 17 Apr 2009 19:01
Picon
Picon

Build problem in usr.bin/crunch/crunchide

Hi,

I tried to do a native build of -current today on an alpha
system, and it failed:
    compile  crunchide/exec_ecoff.o
cc1: warnings being treated as errors
/usr/src/usr.bin/crunch/crunchide/exec_ecoff.c: In function 'check_ecoff':
/usr/src/usr.bin/crunch/crunchide/exec_ecoff.c:67: warning: comparison between signed and unsigned
--- exec_ecoff.o ---
*** [exec_ecoff.o] Error code 1

I "fixed" this by adjusting the warning level in the Makefile
(see below).  But I'm sure someone can come up with a better fix.

					-jarle

Index: usr.bin/crunch/crunchide/Makefile
===================================================================
RCS file: /cvsroot/src/usr.bin/crunch/crunchide/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- usr.bin/crunch/crunchide/Makefile   8 Apr 2007 09:36:34 -0000       1.16
+++ usr.bin/crunch/crunchide/Makefile   17 Apr 2009 17:00:11 -0000
 <at>  <at>  -5,6 +5,7  <at>  <at> 
 PROG=   crunchide
 SRCS=  crunchide.c exec_aout.c exec_coff.c exec_ecoff.c exec_elf32.c \
        exec_elf64.c
+WARNS?=        2

 .if    ${MACHINE_ARCH} == "alpha"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen M. Jones | 21 Apr 2009 17:40
Favicon

ifconfig delay on up

Under 4.x and previous versions I've noticed that bringing up an ethernet
interface takes about 60 seconds before it becomes active.  But bringing
down an interface is instantaneous.  Is there a way to avoid the delay on
bringing an interface up?
Permalink | Reply | 6 comments |
headers
der Mouse | 21 Apr 2009 19:17

Re: ifconfig delay on up

> Under 4.x and previous versions I've noticed that bringing up an
> ethernet interface takes about 60 seconds before it becomes active.
> But bringing down an interface is instantaneous.  Is there a way to
> avoid the delay on bringing an interface up?

I have never seen that.  However, I have seen something similar enough
it could easily be confused with that: I have comparatively often seen
switches which take long times - 30 seconds, 60 seconds - from the time
link comes up to the time they start forwarding packets.

In my experience this is usually due to spanning tree, and the fix,
when it's a problem, is to disable spanning tree on that port (or, when
possible, to set it to assume spanning tree will show no loops and thus
start forwarding immediately, to be changed later if appropriate).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 5 comments |
headers
Miles Nordin | 21 Apr 2009 19:58

Re: ifconfig delay on up

>>>>> "dm" == der Mouse <mouse <at> Rodents-Montreal.ORG> writes:

    dm> is to disable spanning tree on that port

That is what the software people always ask the netadmins to do.
``spanning tree is causing me problems.  I don't know what it is but i
have Issues.  please disable it.''

    dm> (or, when possible, to set it to assume spanning tree
    dm> will show no loops and thus start forwarding immediately, to
    dm> be changed later if appropriate).

right, the vocational school will have taught your high school
graduate netadmin to set cisco's 'portfast' feature for an old
network, or for a new network to set 802.1w RST mode and configure the
port as an edge port.  In both cases, spanning tree remains active and
the delay is gone.  The first case is not ``standard'', and the second
case is.  The second case may be marginally safer.  and the email you
get back from netadmin probably says something like ``k., done''
leading to the confusion.  You tell everyone ``after disabling
spanning tree our Issues went away.''  not so.

But if you have to stand in for the net admin without going to the
vocational school first, you should not be disabling spanning tree.
It's not necessary, and if you did it, it would disable certain hacks
for avoiding storms (some documented some not), and if the hacks did
not work and you did encounter a storm it could last until you remove
the loop with spanning tree off, but it'll only last about 1 minute
with portfast / 802.1w-edge.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane