Re: LibreSSL: is there any reason to keep opaque_prf_input?

2014-06-12 Thread Miod Vallat
> Miod Vallat writes: > > > You're right. What about the following diff? (major bump for libssl) > > Looks OK to me. There's also a few tendrils in regress: Indeed. Applied, thanks!

Re: We can dump(8) more than 2TB

2014-06-12 Thread Ted Unangst
On Thu, Jun 12, 2014 at 21:30, Christian Weisgerber wrote: > New diff. > > * Move all off_t variables that don't look like file sizes to > int64_t. > * Switch blockswritten to int64_t, so it won't wrap at 2TB. > * Same for blocksthisvol (deraadt@). > * Switch xferrate (tedu@) and blocksperfile fro

Re: nsd and unbound flags

2014-06-12 Thread Stuart Henderson
On 2014/06/12 21:58, Martin, Matthew wrote: > Since /var/nsd/etc/nsd.conf is the default path for nsd's config file, > I see no reason to break from the convention, for normal use: "". Same > for unbound. > > -Matthew Martin > > Index: rc.conf > ==

nsd and unbound flags

2014-06-12 Thread Martin, Matthew
Since /var/nsd/etc/nsd.conf is the default path for nsd's config file, I see no reason to break from the convention, for normal use: "". Same for unbound. -Matthew Martin Index: rc.conf === RCS file: /cvs/src/etc/rc.conf,v retrievin

Re: ftp.fr mirror is going down

2014-06-12 Thread Antoine Jacoutot
> ftp.fr is back. > Please hit it hard and let me know of any issue. I forgot to mention that the machine got re-installed so the ssh fingerprint changed. -- Antoine

Re: ftp.fr mirror is going down

2014-06-12 Thread Antoine Jacoutot
So, ftp.fr should be back in about 10 days in full shape on a much much better hardware for a long time hopefully ;-) Sorry for the inconvenience. ftp.fr is back. Please hit it hard and let me know of any issue. Thank you! -- Antoine

Re: We can dump(8) more than 2TB

2014-06-12 Thread Christian Weisgerber
New diff. * Move all off_t variables that don't look like file sizes to int64_t. * Switch blockswritten to int64_t, so it won't wrap at 2TB. * Same for blocksthisvol (deraadt@). * Switch xferrate (tedu@) and blocksperfile from long to uint64_t. * Since blocksperfile can be set with -B, move numa

Re: We can dump(8) more than 2TB

2014-06-12 Thread Theo de Raadt
> > Date: Thu, 12 Jun 2014 15:14:29 -0400 > > From: Ted Unangst > > > > On Thu, Jun 12, 2014 at 21:07, Christian Weisgerber wrote: > > > After writing 2TB (INT_MAX * TP_BSIZE), dump(8) stops reporting > > > progress because the blockswritten variable has wrapped around to > > > negative. It need

Re: We can dump(8) more than 2TB

2014-06-12 Thread Mark Kettenis
> Date: Thu, 12 Jun 2014 15:14:29 -0400 > From: Ted Unangst > > On Thu, Jun 12, 2014 at 21:07, Christian Weisgerber wrote: > > After writing 2TB (INT_MAX * TP_BSIZE), dump(8) stops reporting > > progress because the blockswritten variable has wrapped around to > > negative. It needs to be a larg

Re: We can dump(8) more than 2TB

2014-06-12 Thread Kenneth Westerback
On 12 June 2014 15:59, Christian Weisgerber wrote: > Ted Unangst: > >> > -intblockswritten; /* number of blocks written on current tape */ >> > +off_t blockswritten; /* number of blocks written on current tape */ >> > time_t tstart_writing; /* when started writing the first tap

Re: We can dump(8) more than 2TB

2014-06-12 Thread Christian Weisgerber
Ted Unangst: > > -intblockswritten; /* number of blocks written on current tape */ > > +off_t blockswritten; /* number of blocks written on current tape */ > > time_t tstart_writing; /* when started writing the first tape block */ > > longxferrate; /* averaged tra

Re: We can dump(8) more than 2TB

2014-06-12 Thread Ted Unangst
On Thu, Jun 12, 2014 at 21:07, Christian Weisgerber wrote: > After writing 2TB (INT_MAX * TP_BSIZE), dump(8) stops reporting > progress because the blockswritten variable has wrapped around to > negative. It needs to be a larger type like the tapesize variable; > see optr.c:timeest(). This only a

We can dump(8) more than 2TB

2014-06-12 Thread Christian Weisgerber
After writing 2TB (INT_MAX * TP_BSIZE), dump(8) stops reporting progress because the blockswritten variable has wrapped around to negative. It needs to be a larger type like the tapesize variable; see optr.c:timeest(). This only affects the terminal chatter. The actual dump functionality is fine

Re: mfi(4) vs WT and WB

2014-06-12 Thread Jim Giannoules
On Tue, Jun 10, 2014 at 10:05:56PM +0200, Mark Kettenis wrote: > > Date: Tue, 10 Jun 2014 21:55:04 +0200 > > From: Otto Moerbeek > > > > On Tue, Jun 10, 2014 at 09:52:23PM +0200, Mark Kettenis wrote: > > > > > > Date: Tue, 10 Jun 2014 21:34:56 +0200 > > > > From: Otto Moerbeek > > > > > > > >

Re: ftp(1) User-Agent

2014-06-12 Thread Adam Thompson
On 2014-06-12 11:32, Alexander Hall wrote: > On June 11, 2014 6:18:19 AM CEST, Lawrence Teo wrote: > >> This diff allows ftp(1) to change the User-Agent for HTTP(S) URL requests via the FTPUSERAGENT environment variable (personally I prefer HTTPUSERAGENT but FTPUSERAGENT is what's used by ft

Re: ftp(1) User-Agent

2014-06-12 Thread Alexander Hall
On June 11, 2014 6:18:19 AM CEST, Lawrence Teo wrote: >This diff allows ftp(1) to change the User-Agent for HTTP(S) URL >requests via the FTPUSERAGENT environment variable (personally I prefer >HTTPUSERAGENT but FTPUSERAGENT is what's used by ftp(1) on other BSDs). > >This is useful when fetchin

more bounded checks in libssl

2014-06-12 Thread Anil Madhavapeddy
Do these look right? The strl* ones are only for external users as it's not used in our tree. Index: src/crypto/buffer/buffer.h === RCS file: /cvs/src/lib/libssl/src/crypto/buffer/buffer.h,v retrieving revision 1.8 diff -u -p -u -r1

MacBookPro8,2 OpenBSD 5.5

2014-06-12 Thread Tihomir Koychev
Successful install openbsd 5.5 MP via http. As i found there is a problem detecting dvd drive during installation, but this is not the only problem. The problemis that the temperatureofthe processordoes not drop below80 degrees, andthe fanisat 100%. Currently i'm running OpenBSD 5.4 on MacBook4,1

Re: pkg_add: extract out-of-order archives

2014-06-12 Thread Marc Espie
On Thu, Jun 12, 2014 at 11:56:18AM +0200, Marc Espie wrote: > The neat effect will be to speed up updates, by relegating unchanged files > to the end of the archive, so they don't need to be fetched at all. It just occurred to me that the shuffle-stack change in gcc is going to make that optimisat

pkg_add: extract out-of-order archives

2014-06-12 Thread Marc Espie
I already sent a preliminary version of this patch to selected people. Now that packages use long names when needed, we can pinpoint every file in the archive based on its archived name. This patch changes pkg_add to be able to extract archives that contain elements out-of-order, e.g., match packa