Attached --includes patch for spanish speaking countries.
--
Dios, gracias por tu amor infinito.
--
Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
http://www.pasosdejesus.org/dominio_publico_colombia.html
diff -ruN -x obj -x CVS src53orig/share/locale/ctype/Makefile
src/share/lo
> Whatever behavior you settle on for netcat, it will break somebody's
> script somewhere. That is the point I was trying to make.
And that right there is your misunderstanding.
Currently, it not possible to write a script with nc that works reliably.
Every script is already broken now.
The res
> (trimming the CC list...)
Don't worry, I'm sure 99% of subscribers send my mail to /dev/null anyway.
> >> > Using netcat to reliably get data is never going to be appropriate
> >> > for a production system, IMHO.
> >>
> >> Wow. You sure do set the bar low. Probably a lot of people are glad
>
(trimming the CC list...)
Creamy writes:
> On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote:
>> > Using netcat to reliably get data is never going to be appropriate
>> > for a production system, IMHO.
>>
>> Wow. You sure do set the bar low. Probably a lot of people are glad
>> tha
On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote:
> > Using netcat to reliably get data is never going to be appropriate
> > for a production system, IMHO.
>
> Wow. You sure do set the bar low. Probably a lot of people are glad
> that I don't accept that kind of balony.
Then make t
> > Look at it this way. Truncated output from some query is the worst
> > case -- it is a mysterious "sometimes you get scewed" behaviour.
> > By default, I want to get the maximum.
>
> It all depends on the protocol / applications used, IMHO. What about
> servers that expect the client to clos
> Using netcat to reliably get data is never going to be appropriate
> for a production system, IMHO.
Wow. You sure do set the bar low. Probably a lot of people are glad
that I don't accept that kind of balony.
> > Any reason this console version can't be included in the tree?
>
> Yes, the way your diff works discards the non-default values the user
> might have set up using wsconsctl keyboard#.repeat.del[1N].
...which doesn't work properly anyway, it seems:
I wrote a corrected patch, tested it, and ju
Theo de Raadt writes:
>> If we cared more about compat with past openbsd releases, then it
>> would be -q 0, but if I'm not mistaken, we're leaning towards switching
>> behavior to be compatible with gnu netcat by default.
>
> Actually, OpenBSD nc is the incompatible one.
Just being a prick: net
--
Dios, gracias por tu amor infinito.
--
Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
http://www.pasosdejesus.org/dominio_publico_colombia.html
Index: Makefile
===
RCS file: /cvs/src/share/locale/ctype/Makefile,v
The project is looking for some modern i386/amd64 machines in
edmonton, AB. They need to be relatively recent, and rack mountable. Ideally
they should have rails, or the ability to find rack mount rails for them.
1U is best, ideally something that runs OpenBSD well.
We'
> > The following patches add functionality to the console for a 'repeat' key,
> > basically a modifier key which adjusts the typematic delay whilst held down.
>
> Is there a real use case for this feature?
Fast cursor movement, scrolling, deleting. I use it every day, and can't
live without it.
Hi Miod,
Thanks for looking at my patches...
> > The following patch adds the keycodes for F13-F24 on a standard PC-122
> > terminal keyboard.
> >
> > Doesn't seem to conflict with anything else I've found.
>
> Well, it conflicts with the codes listed in the `USB HID to PS/2 Scan
> Code Transla
> > It would be rather weird to have OpenBSD change the default behavior of
> > its netcat version and then see the GNU folks doing the opposite change
> > because they prefer it and don't see a need to maintain compatibility
> > (which is what the GNU project has done for lots of software).
>
>
On Tue, Mar 19, 2013 at 08:43:55PM +0100, J??r??mie Courr??ges-Anglas wrote:
> Otto Moerbeek writes:
>
> > On Tue, Mar 19, 2013 at 03:16:50PM -0400, Ted Unangst wrote:
> >
> >> OK, thanks, I think I get it. Let me summarize:
> >>
> >> nc currently calls shutdown() when it gets EOF on input. Thi
> If we cared more about compat with past openbsd releases, then it
> would be -q 0, but if I'm not mistaken, we're leaning towards switching
> behavior to be compatible with gnu netcat by default.
Actually, OpenBSD nc is the incompatible one.
hobbit nc did not do shutdown.
gnu nc does not do shu
Otto Moerbeek writes:
> On Tue, Mar 19, 2013 at 03:16:50PM -0400, Ted Unangst wrote:
>
>> OK, thanks, I think I get it. Let me summarize:
>>
>> nc currently calls shutdown() when it gets EOF on input. This is the
>> right thing to do, because that's how well written network clients
>> indicate e
On Tue, Mar 19, 2013 at 08:12:15PM +0100, Martin Pelikan wrote:
> > >> Yes, but it would even be better if there would be an option to get
> > >> the shutdown on EOF behaviour back.
> > >>
> > >> Some servers wait until they see the shutdown from the client to finish
> > >> their work.
> >
> > wo
On Tue, Mar 19, 2013 at 20:24, Otto Moerbeek wrote:
>> Now that I better understand the problem, something like the -q
>> [delay] option seems like the better solution. Even when talking to a
>> broken server, we don't necessarily want nc hanging around forever,
>> and maybe we don't know if the s
On Tue, Mar 19, 2013 at 03:16:50PM -0400, Ted Unangst wrote:
> OK, thanks, I think I get it. Let me summarize:
>
> nc currently calls shutdown() when it gets EOF on input. This is the
> right thing to do, because that's how well written network clients
> indicate end of input. Some broken servers
OK, thanks, I think I get it. Let me summarize:
nc currently calls shutdown() when it gets EOF on input. This is the
right thing to do, because that's how well written network clients
indicate end of input. Some broken servers, however, treat shutdown as
a disconnect and abort the connection.
nc
On 2013/03/19 14:35, Ted Unangst wrote:
> On Tue, Mar 19, 2013 at 17:39, Stuart Henderson wrote:
> > On 2013/03/19 18:26, Otto Moerbeek wrote:
> >> On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
> >>
> >> > > wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
> >
> >> Yes, but it would even be better if there would be an option to get
> >> the shutdown on EOF behaviour back.
> >>
> >> Some servers wait until they see the shutdown from the client to finish
> >> their work.
>
> woah. Can somebody explain, using very small words, exactly what the
> problem is
On Tue, Mar 19, 2013 at 07:48:41PM +0100, Otto Moerbeek wrote:
> On Tue, Mar 19, 2013 at 02:35:49PM -0400, Ted Unangst wrote:
>
> > On Tue, Mar 19, 2013 at 17:39, Stuart Henderson wrote:
> > > On 2013/03/19 18:26, Otto Moerbeek wrote:
> > >> On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelika
On Tue, Mar 19, 2013 at 02:35:49PM -0400, Ted Unangst wrote:
> On Tue, Mar 19, 2013 at 17:39, Stuart Henderson wrote:
> > On 2013/03/19 18:26, Otto Moerbeek wrote:
> >> On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
> >>
> >> > > wfd is stdin, so doing a shutdown on it will mostly
On Tue, Mar 19, 2013 at 11:13, Andres Perera wrote:
>> +#define DECREMENT(x) x--
>
> why not (x)--?
I was lazy. (x) would be better.
> why not intmax_t instead of int64_t?
64 bits ought to be enough for anyone. :)
On Tue, Mar 19, 2013 at 17:39, Stuart Henderson wrote:
> On 2013/03/19 18:26, Otto Moerbeek wrote:
>> On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
>>
>> > > wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
>> >
>> > Of course you're right. I was so focused o
Hi,
This update xkeyboard-config to the latest release 2.8.
http://koba.devio.us/distfiles/xkeyboard-config-2.8.diff
Change:
* 18 bugs fixed
* Most important change: a lot of materials updated from Oracle (Sun keyboards)
* Updated translations
Tested on amd64.
Comments ? OK ?.
--
Alexandr Sha
On 2013/03/19 18:26, Otto Moerbeek wrote:
> On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
>
> > > wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
> >
> > Of course you're right. I was so focused on finding the bug I didn't
> > look above what the fd is :-(
On 2013/03/19 18:26, Otto Moerbeek wrote:
> On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
>
> > > wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
> >
> > Of course you're right. I was so focused on finding the bug I didn't
> > look above what the fd is :-(
On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
> > wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
>
> Of course you're right. I was so focused on finding the bug I didn't
> look above what the fd is :-(
>
> Are you okay with removing this particular shutd
I've certainly done the same with this.. congratulations - it panics.
it's not helpful - the issue is not when it goes negative. the issue is
missed increments in one of the many nfs cases, and a kassert in this
case doesn't help you find that. We've fixed it several times and then
something gets
> > +#define BIOCGQUEUE _IOR('B',126, u_int32_t)
> > +#define BIOCSQUEUE _IOW('B',127, u_int32_t)
>
> these ioctls can take u_int to be consistent with how you're using
> them.
Sorry everyone. I wanted to make it all the same type -- u_int32_t,
and obviously forgot it in the kernel part.
Do you
On Tue, Mar 19, 2013 at 16:10 +0100, Martin Pelikan wrote:
> Hi!
>
> Yesterday I got sick and tired of guessing what the enormous traffic in our
> default queue was, and filled an item from my wishlist since OpenBSD 4.7.
>
> It works like this:
>
> # tcpdump -Q queuename -ni em0
> tcpdump: liste
On Tue, Mar 19, 2013 at 10:47 AM, Ted Unangst wrote:
> Maybe we want, maybe we don't. Here's a check to prevent a counter
> from going negative, which usually means an accounting mistake
> somewhere. On the shortcomiing side, it only catches double
> decrements, not missing decrements, so maybe it
Maybe we want, maybe we don't. Here's a check to prevent a counter
from going negative, which usually means an accounting mistake
somewhere. On the shortcomiing side, it only catches double
decrements, not missing decrements, so maybe it's not worthwhile.
Anyway, it was like five minutes to make, f
> This mail contains changes required to the kernel, subsequent ones have the
> (most complicated) tcpdump(8) bit and (untested) pcap(3) bit.
Just as pcap_setdirection(3), it doesn't have any current user, but it
might be useful to some.
Index: lib/libpcap/Makefile
=
> This mail contains changes required to the kernel, subsequent ones have the
> (most complicated) tcpdump(8) bit and (untested) pcap(3) bit.
tcpdump(8) change follows:
Index: usr.sbin/tcpdump/privsep.c
===
RCS file: /cvs/src/usr.s
Hi!
Yesterday I got sick and tired of guessing what the enormous traffic in our
default queue was, and filled an item from my wishlist since OpenBSD 4.7.
It works like this:
# tcpdump -Q queuename -ni em0
tcpdump: listening on vic0, queue a, link-type EN10MB
... usual output ...
This mail conta
> wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
Of course you're right. I was so focused on finding the bug I didn't
look above what the fd is :-(
Are you okay with removing this particular shutdown(2) line?
--
Martin Pelikan
Resubmitting with patch inline, as requested.
Index: etc/changelist
===
RCS file: /cvs/src/etc/changelist,v
retrieving revision 1.78
diff -u -r1.78 changelist
--- etc/changelist 31 Dec 2012 22:04:20 - 1.78
+++ etc/change
Resending with patches inline, as requested.
Index: etc/netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.137
diff -u -r1.137 netstart
--- etc/netstart5 Dec 2012 07:08:38 - 1.137
+++ etc/netstart
On 19/03/13(Tue) 10:05, Ted Unangst wrote:
> On Tue, Mar 19, 2013 at 14:24, Martin Pieuchot wrote:
> > On 15/03/13(Fri) 16:59, Ted Unangst wrote:
> >> Replace LIST_END with NULL, for clarity and less characters.
> >>
> >> frag6.c was definitely a big fan of LIST_END.
> >
> > Careful, I had to edit
On Tue, Mar 19, 2013 at 14:24, Martin Pieuchot wrote:
> On 15/03/13(Fri) 16:59, Ted Unangst wrote:
>> Replace LIST_END with NULL, for clarity and less characters.
>>
>> frag6.c was definitely a big fan of LIST_END.
>
> Careful, I had to edit your diff to be able to apply it correctly.
>
> I'm mos
On 15/03/13(Fri) 16:59, Ted Unangst wrote:
> Replace LIST_END with NULL, for clarity and less characters.
>
> frag6.c was definitely a big fan of LIST_END.
Careful, I had to edit your diff to be able to apply it correctly.
I'm mostly ok with your diff, but in some place I think that it would be
The regression test in regress/lib/libc/locale/check_isw doesn't pass
in current.
My thinking for the attached patch is that since this test is
intended only for the POSIX locale, it should only test the portable
character set and the control characters set.
http://pubs.opengroup.org/onlinep
Diff below removes 4 global read-only variables "ifqmaxlen", "ipqmaxlen",
"ip6qmaxlen" and "mplsqmaxlen" that are all set to IFQ_MAXLEN and never
modified afterward.
ok?
Index: net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
ret
On 19/03/2013, at 7:56 PM, Reyk Floeter wrote:
> On Tue, Mar 19, 2013 at 05:57:16PM +1000, David Gwynne wrote:
>> this lets the code that picks the filenames to use for certificates
>> fall through to using the services name, instead of just the ip
>> addresses of the service.
>>
>> eg, if i ha
On Tue, Mar 19, 2013 at 05:57:16PM +1000, David Gwynne wrote:
> this lets the code that picks the filenames to use for certificates
> fall through to using the services name, instead of just the ip
> addresses of the service.
>
> eg, if i have this in relayd.conf:
>
> relay "sslnews.eait.uq
this lets the code that picks the filenames to use for certificates
fall through to using the services name, instead of just the ip
addresses of the service.
eg, if i have this in relayd.conf:
relay "sslnews.eait.uq.edu.au" {
listen on 0.0.0.0 port 563 ssl
50 matches
Mail list logo
