| From | Subject | Date |
|---|---|---|
| Rodrigo Ferreri | Tecnologia a precios imperdibles!
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
Para visualizar este correo en el explorador, clic aqum
Este correo ha sido enviado a tech@openbsd.org | Remover suscripcisn
[IMAGE]
| Aug 26, 3:51 pm 2010 |
| Matthieu Herrb | libraries updates in recent X snapshots - please test.
Hi,
recent X snapshots (dated aug 25 or later) contain a number of
un-committed updates to various X libs, that need some wide testing.
So, if you track -current, please update X as well as your base system
from snapshots and give it a try.
Updates include:
- libfreetype 2.4.2 (with the byte-code for true type font hinting
enabled again)
- libxcb 1.7 and libX11 1.3.5 which contain bug fixes for multi-threaded
X applications
- libXi 1.3.2. Mostly a bug-fix release.
Hopefully ...
| Aug 26, 1:40 pm 2010 |
| Joerg Goltermann | kernel build failed without IPSEC
kernel build failed, if IPSEC is *not* defined:
../../../../netinet/in_proto.c:214: error: 'etherip_input' undeclared here (not in a function)
../../../../netinet/in_proto.c:216: error: 'etherip_sysctl' undeclared here (not in a function)
got OK from claudio@ need one more.
OK?
Index: in_proto.c
===================================================================
RCS file: /cvs/src/sys/netinet/in_proto.c,v
retrieving revision 1.53
diff -u -p -r1.53 in_proto.c
--- in_proto.c 11 May 2010 ...
| Aug 26, 1:23 pm 2010 |
| Gilles Chehade | Re: libevent signal whoopsie
I haven't observed the issue but the diff is ok by me
--
Gilles Chehade
| Aug 26, 2:27 pm 2010 |
| Nicholas Marriott | libevent signal whoopsie
hi
libevent has this clever stuff to reinitialise signals if the backend
requires it after calling event_reinit() (typically called after
fork()).
unfortunately, it isn't enabled for poll and select, so both parent and
child continue to use the same socketpair for signals.
one byte is written into this socketpair to wake up the main event loop
on a signal, so there is an occasional race between the processes to
read this byte, causing the losing process to hang, blocked in recv().
this ...
| Aug 26, 1:07 pm 2010 |
| Claudio Jeker | Re: multiple specified interfaces for rarpd
Looks right but take that with a grain of salt since it is IPv6 stuff and
| Aug 26, 5:26 am 2010 |
| Kenneth R Westerback | Re: multiple specified interfaces for rarpd
This seems like a good idea to me. Code looks correct though I can't
immediately think of a way to test. ok krw@.
| Aug 26, 4:59 am 2010 |
| Jonathan Gray | Re: multiple specified interfaces for rarpd
previous diff missed usage as pointed out by sthen/jmc
Index: rarpd.8
===================================================================
RCS file: /cvs/src/usr.sbin/rarpd/rarpd.8,v
retrieving revision 1.17
diff -u -p -r1.17 rarpd.8
--- rarpd.8 23 May 2008 15:23:53 -0000 1.17
+++ rarpd.8 26 Aug 2010 10:49:47 -0000
@@ -30,11 +30,11 @@
.Sh SYNOPSIS
.Nm rarpd
.Op Fl adflt
-.Ar interface
+.Ar if0 Op Ar ... ifN
.Sh DESCRIPTION
.Nm
services Reverse ARP requests on the Ethernet ...
| Aug 26, 3:51 am 2010 |
| Claudio Jeker | Re: multiple specified interfaces for rarpd
Ugh, I start to see pink elephants and IPv6 in places where there isn't. I
think I should go and see a doctor :)
| Aug 26, 7:12 am 2010 |
| Claudio Jeker | Re: make carp(4) work on IPv6 only setups
Hmm. Something is funky because when I tried it did not work. Maybe
it was may testing that managed to confuse ip6_output in a similar manner
as it is confusing me. I still think that setting the scope on that link
local multicast address is better then hoping that ifaof_ifpforaddr()
returns a link local address.
| Aug 26, 6:25 am 2010 |
| Stuart Henderson | Re: make carp(4) work on IPv6 only setups
One thing I ran into when testing (which I knew before, but forgot) was
that the autoconfigured link-local addresses are excluded from carp,
so unless you configure a real address you won't see any announcement
Yes, I agree. ok.
| Aug 26, 6:34 am 2010 |
| Claudio Jeker | Re: bgpd config to announce one netblock only to one upstream
Are you sure that problem still exists in 4.8 or -current? Because the way
networks are handled changed completely. There is no longer a special
static/connected global rule. Now explicit rules have a higher precedence
then the dynamic "network inet ..." ones.
| Aug 26, 12:52 pm 2010 |
| Chris Cappuccio | Re: bgpd config to announce one netblock only to one upstream
That sounds good. I missed that stuff, I didn't think it was much different from 4.7 to current when I submitted the PR. I'll retest.
Thanks,
Chris
| Aug 26, 12:59 pm 2010 |
| Chris Cappuccio | Re: bgpd config to announce one netblock only to one upstream
Here's an example that might work. You can twist it around depending on how localpref is setup with your providers to make it work better. If you happen to also be using "network inet static" (redistribute static routes via BGP) and you happen to be statically routing these same subnets beyond your router, you will run into this bug: http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=6406
# policy:
# community 2:100 announced to all ebgp peers
# community 2:99 announced to ...
| Aug 26, 11:58 am 2010 |
| Claudio Jeker | Aug 26, 7:32 am 2010 | |
| Gilles Chehade | Re: misc. ctl parser.c cleanup
hi ted,
the diff is ok by me
gilles
--
Gilles Chehade
| Aug 26, 2:47 pm 2010 |
| previous day | today | next day |
|---|---|---|
| August 25, 2010 | August 26, 2010 | August 27, 2010 |
