On Friday, April 12, 2013 1:09:53 AM UTC+6, Markiyan Kushnir wrote:
> > Another thing that might be worth of attention, the patched version has
> > been again back to slower checkout time:
> > real91m38.824s
> > user0m26.216s
> > sys 0m13.858s
> > at 4 Mbit/s link, while the original 0.
Hey guy,
copper trading here, exporting Alumina oxide with good quality and low price in
China.
Call me, let's talk details.
Rgds,
Jacky
Qingdao JuXiangDa Import&Export CO.,LTD
TEL: +86-532-80934379 FAX: +86-532-80934379
MSN:jacky20110...@hotmail.com
TradeManager: cn1001706274
SKYPE
Is there a "cookbook" for setting this up? There are examples for
setting up a tunnel between two fixed-address networks (e.g. a remote
LAN that needs to be "integrated" with a central LAN over IPSec but I
can't find anything addressing the other situation -- remote user(s)
where the connecting IP
I was already starting to load up a fresh 9.1-STABLE box for other testing, I
will also create a stock box (no changes anywhere) and let it idle for a few
days to see if the problem is still there.
I'll report back either way in the next few days with results.
If I still have problems, I will
On 11.04.2013 20:42, Markiyan Kushnir wrote:
I agree with Ian, there is no need to statically link to base libraries.
While not going into details of the patch, I can confirm no issues,
except of known ones, of course: ports/17, ports/177408.
Another thing that might be worth of attention,
On 10 April 2013 15:59, wrote:
> Got it. I'll double check to make sure everything was recompiled
> correctly. Thanks!
> Damon
While you're at it, I'll echo Ronald's concern-- make sure
/usr/include/utmp.h does NOT exist for you.
If it does, you must run make delete-old in /usr/src.
Chris
> O
I agree with Ian, there is no need to statically link to base libraries.
While not going into details of the patch, I can confirm no issues,
except of known ones, of course: ports/17, ports/177408.
Another thing that might be worth of attention, the patched version has
been again back to
> I'm sorry, but even ignoring all of your whitespace and style(9)
> differences, your patch appears to go well beyond correcting a typo,
> which I can't spot anyway, though I'm sure John will know what it is.
>
> Care to explain a little more?
Sure. Typo is "strlen(command - total_bytes_writte
On Thu, 11 Apr 2013, mrb...@gmail.com wrote:
> On Sunday, March 24, 2013 9:57:12 AM UTC+6, Markiyan Kushnir wrote:
> > Tested svnup for a while, and I can say it does its job well, and works
> > basically as I would expect, so thanks for your initiative. Although it
> > appears to be quite re
Hi,
i am not sure whether this is the correct source code version
of makefs, but here i can see the reason for the bad Rock Ridge
TF entries
http://svnweb.freebsd.org/base/stable/8/usr.sbin/makefs/cd9660/iso9660_rrip.c?revision=224835&view=markup
Line 688 has:
p->attr.rr_entry.TF.h.l
Excuse me for being slightly spammy but I've received feedback that we
haven't spread this information widely enough outside the inner circles
and interested people missed the announcement.
EuroBSDcon 2013: September 28-29 in Malta
=
EuroBSDcon is the Euro
On Thursday, April 11, 2013 1:14:57 PM UTC+6, mrb...@gmail.com wrote:
> I've placed the patched svnup.c (0.56), the diff and two statically linked
> binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/
I'm sorry, svnup.c.diff is the patch against filtered thru indent svnup.c, with
different
On Sunday, March 24, 2013 9:57:12 AM UTC+6, Markiyan Kushnir wrote:
> Tested svnup for a while, and I can say it does its job well, and works
> basically as I would expect, so thanks for your initiative. Although it
> appears to be quite resource greedy. Most of the time it showed
> something li
13 matches
Mail list logo
