Re: svn - but smaller?
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 like: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 22270 mkushnir 1 1020 44944K 31804K CPU01 6:22 97.56% a.out It's because of typo in the send_command() procedure. 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/ No more CPU eating and/or strange lockups (so far). Tested both against local and remote repository. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
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 formatting (see README). The patch against the original svnup.c v0.56 is named svnup.c.diff-original. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013
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 European technical conference for users and developers of BSD-based systems. The conference will take place Saturday and Sunday 28-29 September at the Hilton Conference Centre in St. Julian's, Malta (tutorials and FreeBSD Developer Summit on preceding Thursday and Friday, talks on Saturday and Sunday). [Yes, very nice weather at that time of year, about 26/19C sunny no rain, Social event on Saturday evening is going to be a sunset beach BBQ] Call for Proposals -- The EuroBSDcon program committee is inviting BSD developers and users to submit innovative and original talk proposals not previously presented at other European conferences. Topics of interest to the conference include, but are not limited to applications, architecture, implementation, performance and security of BSD-based operating systems, as well as topics concerning the economic or organizational aspects of BSD use. Presentations are expected to be 45 minutes and are to be delivered in English. Call for Tutorial Proposals --- The EuroBSDcon program committee is also inviting qualified practitioners in their field to submit proposals for half or full day tutorials on topics relevant to development, implementation and use of BSD-based systems. Half-day tutorials are expected to be 2.5 to 3 hours and full-day tutorials 5 to 6 hours. Tutorials are to be held in English. Submissions --- Proposals should be sent by email to submiss...@eurobsdcon.org. They should contain a short and concise text description in about 100 words. The submission should also include a short CV of the speaker and an estimate of the expected travel expenses. Please submit each proposal as a separate email. Important dates --- The EuroBSDcon program committee is accepting talk and tutorial proposals until Monday, May 25 2013. Other important dates will be announced soon at the conference website http://2013.EuroBSDcon.org/. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Release ISO images have broken RockRidge data
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=224835view=markup
Line 688 has:
p-attr.rr_entry.TF.h.length[0] = 4;
This should be 5, because after the 4 bytes of generic SUSP header
there is one byte of flags. See typedef of ISO_RRIP_TF in
.../iso9660_rrip.h line 135.
---
The reason for the missing hardlink info can be seen in line 648:
/* Ignoring the serial number for now */
The program would have to detect hardlink relations among files
which get copied from the local filesystem into the ISO image.
It would then have to mark hardlink siblings by giving them the
same serial number.
This would not show them as hardlinks in mounted images on FreeBSD
or Linux. But xorriso would respect them, if -hardlinks is set to on.
(Done by command -for_backup.)
---
There is a small bug with makefs and the Expiration Time in the
Primary Volume Descriptor.
http://svnweb.freebsd.org/base/stable/8/usr.sbin/makefs/cd9660.c?revision=225249view=markup
Line 687:
memset(diskStructure.primaryDescriptor.expiration_date, '0' ,17);
should be something like
memset(diskStructure.primaryDescriptor.expiration_date, '0' ,16);
((char *) diskStructure.primaryDescriptor.expiration_date)[16] = 0;
ECMA-119 (ISO 9660 for cheapos) 8.4.26.1:
If all characters in RBP 1 to 16 of this field are the digit ZERO
and the number in RBP 17 is zero, it shall mean that the date and
time are not specified.
I just fixed a contrary bug in libisofs. {:)
---
A year ago FreeBSD 8 had problems with large files in mounted ISO 9660
images and with mounting multi-session images:
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038549.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038552.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038563.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038566.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038570.html
I wonder whether these have been fixed meanwhile.
---
Have a nice day :)
Thomas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
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 resource greedy. Most of the time it showed something like: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 22270 mkushnir 1 1020 44944K 31804K CPU01 6:22 97.56% a.out It's because of typo in the send_command() procedure. 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/ No more CPU eating and/or strange lockups (so far). Tested both against local and remote repository. 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? Also, what advantage, in this particular case, is there in statically linking? Here it turns a 21.5K i386 binary into one of 575K. If this makes it into base, as I hope it may, that seems a little excessive? cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
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_written) instead of strlen(command) - total_bytes_written. But then I've noticed that John have used non-blocking IO (useless in our case) while not handling IO errors, that lead us to permanent cycling on EAGAIN. So I've replaced John's code with the simpler one that blocks on write() and removed fcntl(..., O_NONBLOCK). Then I've run a lot of tests again my own repository located on the same machine and sometime svnup was locked permanently with send/recieve queues filled up (remote fetching was OK). I've digged a bit in svn code and deceided that it would be helpful to use SO_KEEPALIVE and to set SNDBUF (at least) to the COMMAND_BUFFER value. Also, what advantage, in this particular case, is there in statically linking? Here it turns a 21.5K i386 binary into one of 575K. If this makes it into base, as I hope it may, that seems a little excessive? There is no advantage. I've compiled both binaries for myself to be able to svnup hundreds of mahines w/o wondering about exact release =) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
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 slower checkout time: real91m38.824s user0m26.216s sys 0m13.858s at 4 Mbit/s link, while the original 0.56 takes ~55min given the same load/network conditions. -- Markiyan On 11.04.2013 16:03, Ian Smith wrote: 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 resource greedy. Most of the time it showed something like: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 22270 mkushnir 1 1020 44944K 31804K CPU01 6:22 97.56% a.out It's because of typo in the send_command() procedure. 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/ No more CPU eating and/or strange lockups (so far). Tested both against local and remote repository. 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? Also, what advantage, in this particular case, is there in statically linking? Here it turns a 21.5K i386 binary into one of 575K. If this makes it into base, as I hope it may, that seems a little excessive? cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Ghosted logins in w/who
On 10 April 2013 15:59, damon...@mac.hush.com 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 On 4/10/2013 at 9:49 AM, Tom Evans wrote:On Wed, Apr 10, 2013 at 3:09 PM, wrote: If I wipe the utmp file all the w/who content goes away, resets if you will. But in a matter of moments the problem reappears.. is this something that needs to be submitted as a bug report do you think? Thanks! Damon Hi Damon Fabian was explaining to you that utmp was replaced by utmpx. All programs in base that wrote to utmp now write to utmpx instead. If you still have programs not from base that write to utmp, you will get incorrect/crazy values reported - you must rebuild all tools that currently write to utmp so that they no longer do so. Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
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, 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.56 takes ~55min given the same load/network conditions. So my fresh measurements of the original 0.56 version at 4Mbit/s has shown: real27m45.944s user3m43.608s sys 22m35.469s while drawing about 97% of CPU time and 30..50 MB RSS memeory: https://docs.google.com/file/d/0B9Q-zpUXxqCnM1lHVWhNRWF6aUk/edit?usp=sharing Here is how the patched version was doing in roughly equivalent conditions: https://docs.google.com/file/d/0B9Q-zpUXxqCndUhTT2tySV8wdU0/edit?usp=sharing -- Markiyan. -- Markiyan On 11.04.2013 16:03, Ian Smith wrote: 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 resource greedy. Most of the time it showed something like: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 22270 mkushnir 1 1020 44944K 31804K CPU01 6:22 97.56% a.out It's because of typo in the send_command() procedure. 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/ No more CPU eating and/or strange lockups (so far). Tested both against local and remote repository. 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? Also, what advantage, in this particular case, is there in statically linking? Here it turns a 21.5K i386 binary into one of 575K. If this makes it into base, as I hope it may, that seems a little excessive? cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: kern/165903: mbuf leak
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 send the full diags as mentioned below. Thanks. 1. This PR does not contain output from dmesg nor pciconf -lvbc, nor does your Email. Output from this matters. 2. Please try 9.1-STABLE and see if there is an improvement; there have been a huge number of changes/fixes to em(4) between 9.1-RELEASE and now. You can try this: https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.1-RELENG_9-r249 290-JPSNAP/ Other output that would be useful on a machine where the current mbuf count is actively very high: * vmstat -z * netstat -Q * netstat -n -x It would also be beneficial to provide any sysctl.conf and loader.conf adjustments you do. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
IKEv2/IPSEC Road Warrior VPN Tunneling?
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 IPs are not known in advance, such as a person with a laptop or smartphone in a random hotel. (And is there a better list for this in the freebsd-* paradigm for the question?) -- -- Karl Denninger /The Market Ticker ®/ http://market-ticker.org Cuda Systems LLC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re:News Alumina
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 ImportExport CO.,LTD TEL: +86-532-80934379 FAX: +86-532-80934379 MSN:jacky20110...@hotmail.com TradeManager: cn1001706274 SKYPE: Jacky20110822 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
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.56 takes ~55min given the same load/network conditions. You may just fix typo and not use other fixes. I doubt they actual for remote fetching. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
