Re: The vim port needs a refresh
On 5/28/2013 02:44, Martin Wilke wrote: On the first note, complain about the patches to the upstream, not to us. This patches problem has been around since forever and so long the upstream is not changing anything about it, nor do we. Hi Martin, This statement is hand-waives the entire discussion, which took as a *given* that upstream is the problem who crazy policies will not change. I already said that 95% of the blame (probably more) should get allocated there. The whole discussion started because upstream will clearly not change. About rolling your own distfile, I completely disagree because we do not know what the maintaner has changed, and seeing it from the security view, I prefer to get all my patches from the original mirrors. 1. Yes, some amount of trust is necessary but hopefully we don't have maintainers that aren't trusted. 2. A trivial script can verify the roll-up contains only official patches, which could be executed by the committer prior to committing changes to distfile. That's a pretty easy security issue to address. I get your point but that issue could be solved. John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
mail/claws-mail: INBOX shows still moved or deleted mails, filtering not working properly
After a struggle with OpenLDAP and Thunderbird (core dumps all over the place when using Thunderbird with OpenLDAP backed users), I moved to Evolution, which is unsatisfying, since calendar function immediately makes Evolution crahs on all tested FreeBSD platforms (9.1-STABLE, 10.0-CURRENT). I tried mail/claws-mail for now and I'm surprised how cryptic and fast an email client can be, but I also have serious struggles with this email client. When fetch and filtering Emails from the account of our computer center's IMPA4 mail servers, the moved and even deleted emails remain visible (but greyished) in the INBOX or any other folder and marked deleted. Filtered and filter induced moves of mails also are greyed, still visible in the main INBOX of the email account but marked with the flag for new mail in INBOX. I can not delete them from INBOX. This behaviour is odd. I searched Grand Master Google for that and found relatively old bug reports about such behaviour, but that should be solved. I exclude misconfigurations, since I already configured those immediate actions as recommended. Nor Evolution nor thunderbird show that weird behaviour and they operate as expected on all mail actions. Maybe someone could give me a hint what to check. Personally, I consider this behaviour a bug and renders another email client unusable on FreeBSD, but I might be terribly wrong here and still suffer from a configuration inconvenience. Please CC me, I'm no subscriber of both lists. Thanks in advance, Oliver Hartmann ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
using ports or gems (easy_install)
Hi everybody, I would like to known how you manage your gem (ruby) or easyinstall (python). Do you use ports ? or directly gems or easyinstall ? or both ? For exemple when you want install some software with lots of dependances you can use (if the software use easy_install) just one easy_install and everything is installed, you can use ports for some packages but sometime not every packages are in the ports so you should need to installed it through easy_install. After that same question about updating So what you do ? And why ? Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: mar 28 mai 2013 09:36:34 CEST ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: using ports or gems (easy_install)
Hi, I would like to known how you manage your gem (ruby) or easyinstall (python). Do you use ports ? or directly gems or easyinstall ? or both ? As far as I can, I use ports, for consistency. But I am using mostly Perl and CPAN is very well integrated in FreeBSD ports. Voila. Olivier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
portupgrade broken after ruby upgrade
Hi, Seems that portupgrade is broken after the upgrade from ruby18 to ruby19: ... root@yokozuna:/usr/ports# portupgrade -a invalid byte sequence in UTF-8 Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ ... I've rebuilt the pkgdb and reinstalled portupgrade but that didn't help. Regards, Marco -- You will lose your present job and have to become a door to door mayonnaise salesman. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portupgrade broken after ruby upgrade
On Tue, 28 May 2013 11:12:18 +0200 (CEST) Marco Beishuizen articulated: Seems that portupgrade is broken after the upgrade from ruby18 to ruby19: ... root@yokozuna:/usr/ports# portupgrade -a invalid byte sequence in UTF-8 Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ ... I've rebuilt the pkgdb and reinstalled portupgrade but that didn't help. I set Ruby19 as the default on my system over a year ago, and never had a problem. Portupgrade is linked against and runs perfectly with it. Did you update the ports as specified in the UPDATING file? what is the output of: pkg_info -R ruby-1.9\* and pkg_info -R ruby-1.8\* if you still have it installed? -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/claws-mail: INBOX shows still moved or deleted mails, filtering not working properly
On Tue, 28 May 2013 09:17:55 +0200 O. Hartmann wrote: I tried mail/claws-mail for now and I'm surprised how cryptic and fast an email client can be, but I also have serious struggles with this email client. When fetch and filtering Emails from the account of our computer center's IMPA4 mail servers, the moved and even deleted emails remain visible (but greyished) in the INBOX or any other folder and marked deleted. ... Nor Evolution nor thunderbird show that weird behaviour and they operate as expected on all mail actions. This is how a traditional IMAP client works, you mark as deleted and manually expunge - and move is done through copy,delete and expunge. In the advanced section of the per account preferences there is a setting that starts Move deleted mails to trash ..., check that you haven't unset that. BTW please don't cross post without a very good reason. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portupgrade broken after ruby upgrade
On Tue, 28 May 2013, the wise Jerry wrote: Did you update the ports as specified in the UPDATING file? Yes, but that didn't do anything. what is the output of: pkg_info -R ruby-1.9\* and pkg_info -R ruby-1.8\* if you still have it installed? ... root@yokozuna:/usr/ports# pkg_info -R ruby-1.9\* Information for ruby-1.9.3.429,1: Required by: ruby19-bdb-0.6.6_1 ruby19-date2-4.0.19 portupgrade-2.4.10.5_1,2 ... I've deinstalled ruby18. Regards, Marco -- Time will end all my troubles, but I don't always approve of Time's methods. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portupgrade broken after ruby upgrade
On 5/28/2013 4:12 AM, Marco Beishuizen wrote: Hi, Seems that portupgrade is broken after the upgrade from ruby18 to ruby19: ... root@yokozuna:/usr/ports# portupgrade -a invalid byte sequence in UTF-8 Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ ... I've rebuilt the pkgdb and reinstalled portupgrade but that didn't help. Regards, Marco Portupgrade does not handle major ruby upgrades well. I recommend rebuilding portupgrade and its databases: # make -C /usr/ports/ports-mgmt/portupgrade build deinstall install clean # rm -f /var/db/pkg/pkgdb.db # rm -f /usr/ports/*.db # pkgdb -fu # portsdb -fu -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Another Firefox 21.0 crash
On 2013-05-26 01:07, Ted Faber wrote: I'm seeing a repeatable, consistent segmentation fault before the first window appears (though firefox -ProfileManager brings up the profile manager, but crashes when I try to actually start the browser). I've deleted ~/.mozilla and just about everything I can think to get rid of. The system is a 9.1 i386 system: FreeBSD ylum.lunabase.org 9.1-STABLE FreeBSD 9.1-STABLE #28 r250528: Sat May 11 17:19:54 PDT 2013 r...@ylum.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 Firefox is built under the most recent clang port. Firefox options are all the defaults (make rmconfig). I rebuilt all the ports from scratch within the last week. I've attached a gdb trace from just running the firefox binary under gdb. I'm not sure I believe it, but clues are scarce on the ground. I can get a ktrace if it will help. ... (gdb) info threads 19 Thread 36d0a200 (LWP 101008/StreamTrans #4) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 15 Thread 362f5600 (LWP 101652/HTML5 Parser) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 14 Thread 362c0f80 (LWP 101651/Cache I/O) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 * 13 Thread 2d8c7e00 (LWP 101017/DOM Worker) 0x282a854b in strcasecmp_l () from /lib/libc.so.7 11 Thread 2d8c4e80 (LWP 101007/Timer) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 10 Thread 28504c80 (LWP 101006/JS Watchdog) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 9 Thread 28504a00 (LWP 101005/firefox) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 8 Thread 28504780 (LWP 100838/JS GC Helper) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 7 Thread 28503380 (LWP 100836/Hang Monitor) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 6 Thread 28502e80 (LWP 100811/Socket Thread) 0x2826785b in poll () from /lib/libc.so.7 5 Thread 2d860f80 (LWP 100810/XPCOM CC) 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 4 Thread 28501d00 (LWP 100806/Gecko_IOThread) 0x282b030b in kevent () from /lib/libc.so.7 3 Thread 28501f80 (LWP 100804/firefox) 0x2826785b in poll () from /lib/libc.so.7 2 Thread 28501080 (LWP 100663/firefox) 0x2a4fc85b in js::StackSpace::sizeOf () from /usr/local/lib/firefox/libxul.so Since it seems libthr.so is involved, and a lot of thread signalling is going on, I suspect r251047 may help here. It fixes a tricky problem with deferred signal delivery, and it looks like this is what you are experiencing here. Can you please do a backtrace of all threads (e.g. thread apply all bt) too? Note that r251047 should apply cleanly to an up-to-date stable/9 tree, but you will have to rebuild and reinstall libc and libthr (or just build and install world). -Dimitry ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The vim port needs a refresh
On Fri, 24 May 2013 16:23:18 -0500, Kenta Suzumoto ken...@hush.com wrote: - It fetches almost 700 patches from what seems like a dial-up connection in AUSTRALIA. Australia's deploying fiber, so joke's on you! But honestly this is horrible. I'm sitting at my desk at a well-peered ISP with plenty of bandwidth and low, low latency and these patches are taking forever. Someone should just add a pre-fetch routine that downloads the first 1000 patches in a tarball, puts them in distfiles, and they well all be verified and the remaining few be fetched normally. Someone should teach upstream a serious lesson about versioning. Maybe someone just needs to fork vim and tag releases on github so we can actually have a sane upstream. Good grief! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Is latest portsnap snapshot still corrupted
I see from a related thread that the snapshot is supposedly fixed, but as of earlier this AM I'm still getting errors. So, is the snapshot broken again or should I be using portsdb too? Stan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portupgrade broken after ruby upgrade
On Tue, 28 May 2013, the wise Bryan Drewery wrote: root@yokozuna:/usr/ports# portupgrade -a invalid byte sequence in UTF-8 Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ Portupgrade does not handle major ruby upgrades well. I recommend rebuilding portupgrade and its databases: # make -C /usr/ports/ports-mgmt/portupgrade build deinstall install clean # rm -f /var/db/pkg/pkgdb.db # rm -f /usr/ports/*.db # pkgdb -fu # portsdb -fu Sorry, didn't work either. Still the same error message. Regards, Marco -- We really don't have any enemies. It's just that some of our best friends are trying to kill us. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Is latest portsnap snapshot still corrupted
On 28/05/2013 13:29, Stan Gammons wrote: I see from a related thread that the snapshot is supposedly fixed, but as of earlier this AM I'm still getting errors. So, is the snapshot broken again or should I be using portsdb too? The root cause of the problem is fixed, but the portsnap servers have not necessarily had good copies of the data pushed out to them yet. There's going to be a full synch of the mirrors happening later today. Cheers Matthew ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: using ports or gems (easy_install)
Le 28/05/2013 ? 14:50:25+0700, Olivier Nicole a écrit Hi, I would like to known how you manage your gem (ruby) or easyinstall (python). Do you use ports ? or directly gems or easyinstall ? or both ? As far as I can, I use ports, for consistency. Me too. But what you do when you cannot ? (Like the ports don't exist) ? I see three possibility : 1/ write the ports (unfortunately not for me) 2/ wait until someone does (many time it's impossible) 3/ use easy_install or gem But I am using mostly Perl and CPAN is very well integrated in FreeBSD ports. Yes much better than ruby or python. Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: mar 28 mai 2013 15:03:58 CEST ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The vim port needs a refresh
On 5/28/2013 14:09, Mark Felder wrote: On Fri, 24 May 2013 16:23:18 -0500, Kenta Suzumoto ken...@hush.com wrote: - It fetches almost 700 patches from what seems like a dial-up connection in AUSTRALIA. Australia's deploying fiber, so joke's on you! But honestly this is horrible. I'm sitting at my desk at a well-peered ISP with plenty of bandwidth and low, low latency and these patches are taking forever. Someone should just add a pre-fetch routine that downloads the first 1000 patches in a tarball, puts them in distfiles, and they well all be verified and the remaining few be fetched normally. Someone should teach upstream a serious lesson about versioning. Maybe someone just needs to fork vim and tag releases on github so we can actually have a sane upstream. Good grief! Well Mark, haven't you realized yet that there's actually no problem and this is almost completely about (your) laziness[1]? All patches only take 74 seconds to download[2] so there is no sympathy for your obviously single data point anecdote, you're clearly doing something wrong. You need to stop complaining and start think about folks with slow connections[3] who also rebuild Vim frequently. Your prefetch/fork idea is obviously unworkable because the security issues can't be solved.[4] [1]http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083880.html [2]http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083849.html [3]http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083844.html [4]http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083882.html Regards, John P.S. Hopefully it's obvious this is tongue in cheek. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/ace | 6.1.9 | 6.2.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The vim port needs a refresh
On Tue, 28 May 2013 15:14:52 +0200 John Marino wrote: All patches only take 74 seconds to download[2] so there is no sympathy for your obviously single data point anecdote, Well at the point you provided one data-point there was only one data point. And it was like pulling teeth to get you to eliminate the alternative explanations. Was it really too much to ask that you provided some actual evidence. you're clearly doing something wrong. You need to stop complaining and start think about folks with slow connections[3] who also rebuild Vim frequently. Don't make things up. I never said anything about frequent rebuilds, the patches all get redownloaded on the next rebuild. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
sysutils/fsc (fbsd service monitor) broken build w/ clang-devel-3.4.r181598_3
Hi and thanks for your work on fsc service monitoring tool.
I have been using it for a while but haven't tried to rebuild it very
often until today. It may have worked with earlier versions of clang.
PR filed. Here is the error message.
Warning: Object directory not changed from original
/usr/ports/sysutils/fsc/work/fsc/fscd
clang -O2 -pipe -fno-strict-aliasing -std=c99 -std=gnu99
-Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -c fscd.c
fscd.c:977:13: error: variable 'sendstr' is used uninitialized whenever
'if' condition is false
[-Werror,-Wsometimes-uninitialized]
} else if (strcmp(arglst[0], status) == 0) {
^~~~
fscd.c:984:16: note: uninitialized use occurs here
send(sock_fd, sendstr, strlen(sendstr), 0);
^~~
fscd.c:977:9: note: remove the 'if' if its condition is always true
} else if (strcmp(arglst[0], status) == 0) {
^~
fscd.c:934:15: note: initialize the variable 'sendstr' to silence this
warning
char *sendstr;
^
= NULL
1 error generated.
*** [fscd.o] Error code 1
Stop in /usr/ports/sysutils/fsc/work/fsc/fscd.
*** [all] Error code 1
Stop in /usr/ports/sysutils/fsc/work/fsc.
*** [do-build] Error code 1
Stop in /usr/ports/sysutils/fsc.
:w
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portupgrade broken after ruby upgrade
On 5/28/2013 7:37 AM, Marco Beishuizen wrote: On Tue, 28 May 2013, the wise Bryan Drewery wrote: root@yokozuna:/usr/ports# portupgrade -a invalid byte sequence in UTF-8 Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ Portupgrade does not handle major ruby upgrades well. I recommend rebuilding portupgrade and its databases: # make -C /usr/ports/ports-mgmt/portupgrade build deinstall install clean # rm -f /var/db/pkg/pkgdb.db # rm -f /usr/ports/*.db # pkgdb -fu # portsdb -fu Sorry, didn't work either. Still the same error message. Regards, Marco Hm, do you mind mailing me a tarball of your /var/db/pkg ? -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
portsnap fetch failed on FreeBSD 8.2
Hello, I am a newbie to FreeBSD world. :) I got a task to port Java to a private-built FreeBSD system which is branched from FreeBSD 8.2. As a start of this, I tried to learn port stuffs, and did 'portsnap fetch' but failed. After that, I tried to change portsnap server, and I even tried a generic FreeBSD 8.2 version, which failed too with merely the same error. Here is what I got in most of the cases (not totally the same for each time, but I suppose they are familiar): == # portsnap fetch Looking up us.portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... ahdone. Fetching snapshot generated at Tue May 28 08:03:52 CST 2013: 7719e39e7b7751c91689858400a3a514488a0d852d194b100% of 8943 kB 63 kBps 00m00s Extracting snapshot... snap/99cac1a150337b4349092e169edc231ca5025106d00d801c4b09e49c748bd8a5.gz: (Empty error message) tar: Error exit delayed from previous errors. == I suppose the downloaded tarball (/var/db/portsnap/7719e39e7b7751c91689858400a3a514488a0d852d194b.tgz) is broken since I cannot unpack it manually too, and I saw the file on the server becomes bigger (seems 60MB+) when I tried it hours later. Server data corrupted? Or anyone knows what might be the problem here? Thanks. Peter ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash
On Tue, May 28, 2013 at 02:00:00PM +0200, Dimitry Andric wrote: On 2013-05-26 01:07, Ted Faber wrote: I'm seeing a repeatable, consistent segmentation fault before the first window appears (though firefox -ProfileManager brings up the profile manager, but crashes when I try to actually start the browser). [ snip] Since it seems libthr.so is involved, and a lot of thread signalling is going on, I suspect r251047 may help here. It fixes a tricky problem with deferred signal delivery, and it looks like this is what you are experiencing here. Can you please do a backtrace of all threads (e.g. thread apply all bt) too? Attached. Note that r251047 should apply cleanly to an up-to-date stable/9 tree, but you will have to rebuild and reinstall libc and libthr (or just build and install world). My svn fu is weak. Any chance you can roll a quick patch for me? (Or better yet, tell me the appropriate hex to start from?) I'm happy to try it out. -- http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG Thread 21 (Thread 2d8c1f00 (LWP 101544/StreamTrans #6)): #0 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 #1 0x281bb9d2 in pthread_kill () from /lib/libthr.so.3 #2 0x281be919 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b383475 in PRP_NakedNotify () from /usr/local/lib/libplds4.so.1 #4 0x2b3842fa in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #5 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #6 0x29e13743 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29e1388f in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #8 0x29e118c4 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #10 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #11 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #12 0x281b3f1a in pthread_getprio () from /lib/libthr.so.3 #13 0x in ?? () Thread 15 (Thread 3678f880 (LWP 101644/HTML5 Parser)): #0 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 #1 0x281bb9d2 in pthread_kill () from /lib/libthr.so.3 #2 0x281be919 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b384381 in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #4 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #5 0x29e10022 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #6 0x29e11898 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #8 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #10 0x281b3f1a in pthread_getprio () from /lib/libthr.so.3 #11 0x in ?? () Thread 14 (Thread 36789200 (LWP 101643/Cache I/O)): #0 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 #1 0x281bb9d2 in pthread_kill () from /lib/libthr.so.3 #2 0x281be919 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b384381 in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #4 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #5 0x29e10022 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #6 0x29e11898 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #8 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #10 0x281b3f1a in pthread_getprio () from /lib/libthr.so.3 #11 0x in ?? () Thread 13 (Thread 2d8c3080 (LWP 101642/DOM Worker)): #0 0x282a854b in strcasecmp_l () from /lib/libc.so.7 #1 0x282a8666 in strcasecmp () from /lib/libc.so.7 #2 0x282d195e in .cerror () from /lib/libc.so.7 #3 0x283477b8 in .got () from /usr/local/lib/libffi.so.6 #4 0x28345e87 in ffi_call_SYSV () from /usr/local/lib/libffi.so.6 #5 0x28345cbe in ffi_call () from /usr/local/lib/libffi.so.6 #6 0x2a6c295b in js::SizeOfDataIfCDataObject () from /usr/local/lib/firefox/libxul.so #7 0x2a41d167 in js::AutoMaybeTouchDeadZones::~AutoMaybeTouchDeadZones () from /usr/local/lib/firefox/libxul.so #8 0x2a3ec016 in js::AutoCTypesActivityCallback::AutoCTypesActivityCallback () from /usr/local/lib/firefox/libxul.so #9 0x2a41d127 in js::AutoMaybeTouchDeadZones::~AutoMaybeTouchDeadZones () from /usr/local/lib/firefox/libxul.so #10 0x2a41969f in
Re: portupgrade broken after ruby upgrade
On Tue, 28 May 2013, the wise Bryan Drewery wrote: root@yokozuna:/usr/ports# portupgrade -a invalid byte sequence in UTF-8 Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ Portupgrade does not handle major ruby upgrades well. I recommend rebuilding portupgrade and its databases: # make -C /usr/ports/ports-mgmt/portupgrade build deinstall install clean # rm -f /var/db/pkg/pkgdb.db # rm -f /usr/ports/*.db # pkgdb -fu # portsdb -fu Not sure this will help in your current stat, but for others who haven't upgraded yet, the notes in UPDATING were incorrect and have been updated, and after some testing I believe they should work better now. My apologies for the mistake. Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portsnap fetch failed on FreeBSD 8.2
W dniu 2013-05-28 17:51, Xu Zhe pisze: I got a task to port Java to a private-built FreeBSD system which is branched from FreeBSD 8.2. As a start of this, I tried to learn port stuffs, and did 'portsnap fetch' but failed. After that, I tried to change portsnap server, and I even tried a generic FreeBSD 8.2 version, which failed too with merely the same error. Here is what I got in most of the cases (not totally the same for each time, but I suppose they are familiar): Please take a look at this: http://lists.freebsd.org/pipermail/freebsd-ops-announce/2013-May/06.html Problem you've described should be fixed by now. If it's not please wait for a few more hours. -- best regards, Lukasz Wasikowski ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portsnap fetch failed on FreeBSD 8.2
于 5/29/13 12:08 AM, Łukasz Wąsikowski 写道: W dniu 2013-05-28 17:51, Xu Zhe pisze: I got a task to port Java to a private-built FreeBSD system which is branched from FreeBSD 8.2. As a start of this, I tried to learn port stuffs, and did 'portsnap fetch' but failed. After that, I tried to change portsnap server, and I even tried a generic FreeBSD 8.2 version, which failed too with merely the same error. Here is what I got in most of the cases (not totally the same for each time, but I suppose they are familiar): Please take a look at this: http://lists.freebsd.org/pipermail/freebsd-ops-announce/2013-May/06.html Problem you've described should be fixed by now. If it's not please wait for a few more hours. Got it. Thanks! Peter ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The vim port needs a refresh
On Tue, 28 May 2013 15:16:00 +0100 RW rwmailli...@googlemail.com wrote: On Tue, 28 May 2013 15:14:52 +0200 John Marino wrote: All patches only take 74 seconds to download[2] so there is no sympathy for your obviously single data point anecdote, Well at the point you provided one data-point there was only one data point. And it was like pulling teeth to get you to eliminate the alternative explanations. Was it really too much to ask that you provided some actual evidence. you're clearly doing something wrong. You need to stop complaining and start think about folks with slow connections[3] who also rebuild Vim frequently. Don't make things up. I never said anything about frequent rebuilds, the patches all get redownloaded on the next rebuild. The real issue is not the number of patches, but the fact that every single patch is downloaded by invoking the fetch(1) command, creating lots of overhead not limited to the fetch command itself. The ports system wasn't designed for such an amount of distfiles in a single port I guess. I just timed fetching the patches through ports vs. fetching over HTTP/1.1 using ftp/curl vs calling fetch directly. The VIM tarball was already downloaded, so this is really just the patches (plus downloading 6mb is barely noticeable on a fast line). It's a slow machine on a fast line. Fetch: [user@server /usr/ports/editors/vim]$ time sudo make fetch real4m57.327s user0m17.010s sys 0m39.588s Curl: [user@server /tmp]$ longcurlcommandline real0m15.291s user0m0.026s sys 0m0.272s Fetch on the command line (after initial make fetch, so this is only measuring transmission of the files): cd /usr/ports/editors/distfiles time for name in 7.3.*; do fetch http://artfiles.org/vim.org/patches/7.3/$name done real1m25.329s user0m0.660s sys 0m3.174s So just the fact we're invoking fetch for every file costs us about one minute - I assume the time lost is much bigger on a slow line with long latency. The remaining 3.5 minutes are spent somewhere in the ports infrastructure and clearly depend on the performance of the machine used. For comparison I timed make fetch on a reasonably fast server (good IO, fast datacenter connection), make fetch still took about 120 seconds(!). So the bottomline is: - Using HTTP/1.1 and keepalive could safe a lot of time - The ports infrastructure creates a lot of overhead per patch file Maybe there's something we can do to improve the situation. Cheers, Michael PS: I don't use vim myself and have no stake in this discussion whatsoever. -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The vim port needs a refresh
On Tue, May 28, 2013 at 07:51:37PM +0200, Michael Gmelin wrote:
On Tue, 28 May 2013 15:16:00 +0100
RW rwmailli...@googlemail.com wrote:
On Tue, 28 May 2013 15:14:52 +0200
John Marino wrote:
All
patches only take 74 seconds to download[2] so there is no sympathy
for your obviously single data point anecdote,
Well at the point you provided one data-point there was only one data
point. And it was like pulling teeth to get you to eliminate the
alternative explanations. Was it really too much to ask that you
provided some actual evidence.
you're clearly doing
something wrong. You need to stop complaining and start think about
folks with slow connections[3] who also rebuild Vim frequently.
Don't make things up. I never said anything about frequent rebuilds,
the patches all get redownloaded on the next rebuild.
The real issue is not the number of patches, but the fact that every
single patch is downloaded by invoking the fetch(1) command, creating
lots of overhead not limited to the fetch command itself. The ports
system wasn't designed for such an amount of distfiles in a single
port I guess.
I just timed fetching the patches through ports vs. fetching over
HTTP/1.1 using ftp/curl vs calling fetch directly. The VIM tarball was
already downloaded, so this is really just the patches (plus
downloading 6mb is barely noticeable on a fast line). It's a slow
machine on a fast line.
Fetch:
[user@server /usr/ports/editors/vim]$ time sudo make fetch
real4m57.327s
user0m17.010s
sys 0m39.588s
Curl:
[user@server /tmp]$ longcurlcommandline
real0m15.291s
user0m0.026s
sys 0m0.272s
Fetch on the command line (after initial make fetch, so this is only
measuring transmission of the files):
cd /usr/ports/editors/distfiles
time for name in 7.3.*; do
fetch http://artfiles.org/vim.org/patches/7.3/$name
done
real1m25.329s
user0m0.660s
sys 0m3.174s
So just the fact we're invoking fetch for every file costs us about one
minute - I assume the time lost is much bigger on a slow line with
long latency. The remaining 3.5 minutes are spent somewhere in the
ports infrastructure and clearly depend on the performance of the
machine used. For comparison I timed make fetch on a reasonably fast
server (good IO, fast datacenter connection), make fetch still took
about 120 seconds(!).
So the bottomline is:
- Using HTTP/1.1 and keepalive could safe a lot of time
- The ports infrastructure creates a lot of overhead per patch file
Maybe there's something we can do to improve the situation.
Cheers,
Michael
PS: I don't use vim myself and have no stake in this discussion
whatsoever.
Someone in this thread proposed to change the port to use phttpget, so I
gave it a try using a German mirror nearby with 6 Mbit/s downlink:
$ time /usr/libexec/phttpget ftp.vim.ossmirror.de $(eval echo
/pub/vim/patches/7.3/{$(make -C /usr/ports/editors/vim -VPATCHFILES | sed 's/\
/,/g')})
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.001: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.002: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.003: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.004: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.005: 200 OK
[...]
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.974: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.984: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.985: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.1000: 200 OK
real0m12.509s
user0m0.154s
sys 0m0.089s
That's really nice!
Compare this to the current version using fetch(1):
time make PATCH_SITES=http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/ fetch
=== Found saved configuration for vim-7.3.669_1
=== vim-7.3.1014 depends on file: /usr/local/sbin/pkg - found
= 7.3.002 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.002
7.3.002 100% of 1610 B 16 MBps 00m00s
= 7.3.003 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.003
7.3.003 100% of 1299 B 1281 kBps 00m00s
= 7.3.004 doesn't seem to exist in /usr/ports/distfiles/vim.
[...]
= 7.3.984 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.984
7.3.984 100% of 1706 B 2852 kBps 00m00s
= 7.3.985 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.985
7.3.985 100% of 1691 B 14 MBps 00m00s
= 7.3.1000 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch
Re: The vim port needs a refresh
Am 28.05.2013 19:51, schrieb Michael Gmelin: On Tue, 28 May 2013 15:16:00 +0100 RW rwmailli...@googlemail.com wrote: On Tue, 28 May 2013 15:14:52 +0200 John Marino wrote: All patches only take 74 seconds to download[2] so there is no sympathy for your obviously single data point anecdote, Well at the point you provided one data-point there was only one data point. And it was like pulling teeth to get you to eliminate the alternative explanations. Was it really too much to ask that you provided some actual evidence. you're clearly doing something wrong. You need to stop complaining and start think about folks with slow connections[3] who also rebuild Vim frequently. Don't make things up. I never said anything about frequent rebuilds, the patches all get redownloaded on the next rebuild. The real issue is not the number of patches, but the fact that every single patch is downloaded by invoking the fetch(1) command, creating lots of overhead not limited to the fetch command itself. The ports system wasn't designed for such an amount of distfiles in a single port I guess. I just timed fetching the patches through ports vs. fetching over HTTP/1.1 using ftp/curl vs calling fetch directly. The VIM tarball was already downloaded, so this is really just the patches (plus downloading 6mb is barely noticeable on a fast line). It's a slow machine on a fast line. Fetch: [user@server /usr/ports/editors/vim]$ time sudo make fetch real4m57.327s user0m17.010s sys 0m39.588s Curl: [user@server /tmp]$ longcurlcommandline real0m15.291s user0m0.026s sys 0m0.272s Fetch on the command line (after initial make fetch, so this is only measuring transmission of the files): cd /usr/ports/editors/distfiles time for name in 7.3.*; do fetch http://artfiles.org/vim.org/patches/7.3/$name done real1m25.329s user0m0.660s sys 0m3.174s So just the fact we're invoking fetch for every file costs us about one minute - I assume the time lost is much bigger on a slow line with long latency. The remaining 3.5 minutes are spent somewhere in the ports infrastructure and clearly depend on the performance of the machine used. For comparison I timed make fetch on a reasonably fast server (good IO, fast datacenter connection), make fetch still took about 120 seconds(!). So the bottomline is: - Using HTTP/1.1 and keepalive could safe a lot of time - The ports infrastructure creates a lot of overhead per patch file Maybe there's something we can do to improve the situation. Probably. On the fetching side, we have: - /usr/src/usr.sbin/portsnap/phttpget/phttpget.c /usr/libexec/phttpget - the possibility to specify multiple URLs on fetch(1)'s command line - the xargs command to assemble command lines with a decent amount of URL arguments Given that connection setup for FTP costs considerable amounts of time especially with FTP. On the URL list generation, we have excessive external command in shell scripts; try make -nC /usr/ports/editors/vim fetch-url-list-int to see the commands. I suppose fewer external commands and more make-internal processing could help quite a bit. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The vim port needs a refresh
On 28 May 2013 06:08, Jeremy Messenger mezz.free...@gmail.com wrote:
On Sat, May 25, 2013 at 3:50 AM, Chris Rees cr...@freebsd.org wrote:
On 24 May 2013 22:23, Kenta Suzumoto ken...@hush.com wrote:
Hello all. The editors/vim port is currently a mess and needs some
changes.
- It fetches almost 700 patches from what seems like a dial-up
connection in AUSTRALIA.
You might as well be downloading a 1080p movie from a rock in the
north pole, because that's about how fast it is.
This can be very easily avoided by putting all the patches into a
single tarball and hosting it anywhere decent. I've
seen someone in ##freebsd on freenode handing out a tarball with all
the patches many times, and everyone asks
why isn't this the default? why is some random guy giving me
distfiles? etc. Seems like a no-brainer.
- By default, it builds lots of gui stuff that certainly almost no one
wants
It almost seems like the vim-lite port should be renamed vim and the
vim port should be renamed gvim. I had to
google to come up with this solution, because I can't even disable
that stuff in make config (another problem!)
.if ${.CURDIR}==/usr/ports/editors/vim
WITH_VIM_OPTIONS=yes
WITHOUT_X11=yes
.endif
People shouldn't have to find this hack to be able to install vim
normally (and no, telling them to use vim-lite isn't normal).
I'm surprised that none of these changes have been made yet. I've
heard it's because the maintainer won't listen to reason
but I have no way to know if that's the case or not. I also heard bapt@had
an optionsNG patch that he wouldn't
integrate into the port for some reason. Please, let's get this stuff
fixed once and for all. None of it requires a large amount
of work on anyone's part.
I'm very sad to talk of a fellow developer like this, but I'm afraid
the maintainer of vim is a contrarian who thinks he knows better than
everyone else on the matter.
For years, people have been begging him to get over his fear of
OPTIONS, and he sits in the way of progress against almost everyone's
wishes.
FYI, the OPTIONS is not required to have. I agree with him pretty much
everything about the OPTIONS. I have refused to add OPTIONS in any of
my ports before I gave up a lot of them long time ago. All of his
thought of OPTIONS are very valid. The OPTIONS still has bugs.
BTW: I always have BATCH=yes in my make.conf, because I hate OPTIONS a
lot.
Putting BATCH=yes in your environment is entirely up to you, but forcing
every user of the ports tree to learn a new way of dealing with certain
ports because They're mine and they're special is absolutely wrong.
If you don't like OPTIONS, fix them, but please don't labour under the
misapprehension that users are happy to have an inconsistent ports tree and
unpredictable ports tree on the whim of a few maverick developers.
Chris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The vim port needs a refresh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.05.2013 22:24, schrieb Lars Engels:
Someone in this thread proposed to change the port to use phttpget, so I
gave it a try using a German mirror nearby with 6 Mbit/s downlink:
$ time /usr/libexec/phttpget ftp.vim.ossmirror.de $(eval echo
/pub/vim/patches/7.3/{$(make -C /usr/ports/editors/vim -VPATCHFILES | sed
's/\ /,/g')})
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.001: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.002: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.003: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.004: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.005: 200 OK
[...]
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.974: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.984: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.985: 200 OK
http://ftp.vim.ossmirror.de//pub/vim/patches/7.3/7.3.1000: 200 OK
real 0m12.509s
user 0m0.154s
sys 0m0.089s
That's really nice!
Compare this to the current version using fetch(1):
This incurs massive overhead from the generation of the fetch URLs, on
top of fetch being slower.
You would have to come up with something similar to your phttpget line,
only that it runs fetch(1) instead. Try:
$ make -C /usr/ports/editors/vim fetch FETCH_CMD=true
to see how slow URL generation is.
On one of my reasonably fast amd64 machines (dual-core 2.1 GHz AMD
BE-2350), residing on the T-Home domestic backbone near the Ruhr area in
Germany with a 3000/384 kBit/s ADSL that has roughly 50 ms ping round
trips, it generates approximately 1.7 fetch commands in 1 s, and see
below for fetch speed:
time make PATCH_SITES=http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/ fetch
=== Found saved configuration for vim-7.3.669_1
=== vim-7.3.1014 depends on file: /usr/local/sbin/pkg - found
= 7.3.002 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.002
7.3.002 100% of 1610 B 16 MBps 00m00s
= 7.3.003 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.003
7.3.003 100% of 1299 B 1281 kBps 00m00s
= 7.3.004 doesn't seem to exist in /usr/ports/distfiles/vim.
[...]
= 7.3.984 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.984
7.3.984 100% of 1706 B 2852 kBps 00m00s
= 7.3.985 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.985
7.3.985 100% of 1691 B 14 MBps 00m00s
= 7.3.1000 doesn't seem to exist in /usr/ports/distfiles/vim.
= Attempting to fetch
http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/7.3.1000
7.3.1000 100% of 1637 B 1715 kBps 00m00s
=== Fetching all distfiles required by vim-7.3.1014 for building
Total time : 3:48.55s
CPU utilisation (percentage): 54.5%
Now, using a similar approach as yours, I get, with fetch:
$ time fetch $(eval echo -O
http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/{$(make -C
/usr/ports/editors/vim -VPATCHFILES | tr ' ' ',')})
...
real2m2.841s
user0m1.083s
sys 0m5.238s
Which takes some 2 min of wasted CPU time out of your calculation.
Not that it helps overly in terms of wallclock time.
Using curl with -O cuts this down to:
real1m5.195s
user0m0.668s
sys 0m1.479s
And wget -nv to:
real1m15.426s
user0m0.845s
sys 0m1.536s
Finally, so you can compare gains whilst taking line speed out of the
picture, phttpget:
real0m22.673s
user0m0.530s
sys 0m0.659s
The computer on its link should be able to fetch a tarball in c. 11 s
wallclock time, we have 3.7 MB of payload in patches and the link
manages roughly 355 kB/s.
Now, any takers for make make fetch more efficient jobs?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlGlHjAACgkQvmGDOQUufZWaNgCgjERowRAqRo2Rgv8rQOZQiA7f
ahcAoMkjJxeFHGBe7hcZIjZb8rrLh+0/
=XoQd
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Is latest portsnap snapshot still corrupted
On Tue, 2013-05-28 at 13:39 +0100, Matthew Seaman wrote: The root cause of the problem is fixed, but the portsnap servers have not necessarily had good copies of the data pushed out to them yet. There's going to be a full synch of the mirrors happening later today. Cheers Matthew It's working now. Thanks Matthew. Stan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: using ports or gems (easy_install)
Albert, I would like to known how you manage your gem (ruby) or easyinstall (python). Do you use ports ? or directly gems or easyinstall ? or both ? As far as I can, I use ports, for consistency. Me too. But what you do when you cannot ? (Like the ports don't exist) ? I see three possibility : 1/ write the ports (unfortunately not for me) 2/ wait until someone does (many time it's impossible) 3/ use easy_install or gem I use the solution 3 (cpan in the case of Perl). Best regards, olivier But I am using mostly Perl and CPAN is very well integrated in FreeBSD ports. Yes much better than ruby or python. Regards. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash (new backtrace)
On Tue, May 28, 2013 at 08:52:35AM -0700, Ted Faber wrote: On Tue, May 28, 2013 at 02:00:00PM +0200, Dimitry Andric wrote: On 2013-05-26 01:07, Ted Faber wrote: I'm seeing a repeatable, consistent segmentation fault before the first window appears (though firefox -ProfileManager brings up the profile manager, but crashes when I try to actually start the browser). [ snip] Since it seems libthr.so is involved, and a lot of thread signalling is going on, I suspect r251047 may help here. It fixes a tricky problem with deferred signal delivery, and it looks like this is what you are experiencing here. Can you please do a backtrace of all threads (e.g. thread apply all bt) too? Attached. Note that r251047 should apply cleanly to an up-to-date stable/9 tree, but you will have to rebuild and reinstall libc and libthr (or just build and install world). My svn fu is weak. Any chance you can roll a quick patch for me? (Or better yet, tell me the appropriate hex to start from?) I'm happy to try it out. OK, I improved my svn fu, pulled the tree, extracted the patch, applied it, made and installed world. Now I see different behavior, but no better. Still gets a SEGV, but a different trace. (Attached) Any ideas? -- http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2d8c8e00 (LWP 100778/DOM Worker)] 0x282d19d0 in .cerror () from /lib/libc.so.7 (gdb) where #0 0x282d19d0 in .cerror () from /lib/libc.so.7 #1 0x3612ab00 in ?? () #2 0x in ?? () (gdb) thread apply all bt Thread 19 (Thread 36d0a200 (LWP 100783/StreamTrans #4)): #0 0x281bc313 in pthread_kill () from /lib/libthr.so.3 #1 0x281bba12 in pthread_kill () from /lib/libthr.so.3 #2 0x281be959 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b383475 in PRP_NakedNotify () from /usr/local/lib/libplds4.so.1 #4 0x2b3842fa in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #5 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #6 0x29e13743 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29e1388f in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #8 0x29e118c4 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #10 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #11 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #12 0x281b3f4a in pthread_getprio () from /lib/libthr.so.3 #13 0x in ?? () Thread 15 (Thread 362f5600 (LWP 100780/HTML5 Parser)): #0 0x281bc313 in pthread_kill () from /lib/libthr.so.3 #1 0x281bba12 in pthread_kill () from /lib/libthr.so.3 #2 0x281be959 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b384381 in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #4 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #5 0x29e10022 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #6 0x29e11898 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #8 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #10 0x281b3f4a in pthread_getprio () from /lib/libthr.so.3 #11 0x in ?? () Thread 14 (Thread 362bef80 (LWP 100779/Cache I/O)): #0 0x281bc313 in pthread_kill () from /lib/libthr.so.3 #1 0x281bba12 in pthread_kill () from /lib/libthr.so.3 #2 0x281be959 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b384381 in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #4 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #5 0x29e10022 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #6 0x29e11898 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #8 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #10 0x281b3f4a in pthread_getprio () from /lib/libthr.so.3 #11 0x in ?? () Thread 13 (Thread 2d8c8e00 (LWP 100778/DOM Worker)): #0 0x282d19d0 in .cerror () from /lib/libc.so.7 #1 0x3612ab00 in ?? () #2 0x in ?? () Thread 11 (Thread 2d8c5e80 (LWP 100776/Timer)): #0 0x281bc313 in pthread_kill () from /lib/libthr.so.3 #1 0x281bba12 in pthread_kill () from /lib/libthr.so.3 #2
sysutils/kdeadmin4 does not compile/link in head
Hello, This is on 10-CURRENT r250588; with clang it does not work either: # cd /usr/ports/sysutils/kdeadmin4 # svn info Path: . Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head/sysutils/kdeadmin4 Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 319094 Node Kind: directory Schedule: normal Last Changed Author: makc Last Changed Rev: 318452 Last Changed Date: 2013-05-18 22:34:41 +0200 (Sat, 18 May 2013) # make clean # make install USE_GCC=any ... /usr/local/kde4/lib/libkabc.so.5: undefined reference to `KRES::Resource::qt_metacast(char const*)' /usr/local/kde4/lib/libkabc.so.5: undefined reference to `KRES::IdMapper::save()' /usr/local/kde4/lib/libkabc.so.5: undefined reference to `KRES::Factory::self(QString const)' *** [kuser/kuser] Error code 1 1 error *** [kuser/CMakeFiles/kuser.dir/all] Error code 2 [ 38%] Building CXX object ksystemlog/src/lib/CMakeFiles/ksystemlog_lib.dir/processOutputLogFileReader.o [ 38%] Building CXX object ksystemlog/src/lib/CMakeFiles/ksystemlog_lib.dir/kioLogFileReader.o ... [ 44%] Building CXX object ksystemlog/src/lib/CMakeFiles/ksystemlog_lib.dir/logViewSearchWidget.o /usr/ports/sysutils/kdeadmin4/work/kdeadmin-4.10.3/ksystemlog/src/lib/levelPrintPage.cpp:127: warning: unused parameter 'msg' [ 44%] Building CXX object ksystemlog/src/lib/CMakeFiles/ksystemlog_lib.dir/view.o In file included from /usr/ports/sysutils/kdeadmin4/work/kdeadmin-4.10.3/ksystemlog/src/lib/view.cpp:42: /usr/local/kde4/include/ktreewidgetsearchline.h:211: warning: 'virtual void KTreeWidgetSearchLine::updateSearch(QTreeWidget*)' was hidden /usr/ports/sysutils/kdeadmin4/work/kdeadmin-4.10.3/ksystemlog/src/lib/logViewFilterWidget.h:80: warning: by 'virtual void LogViewWidgetSearchLine::updateSearch(const QString)' Linking CXX static library ../../../lib/libksystemlog_lib.a [ 44%] Built target ksystemlog_lib 1 error *** [all] Error code 2 1 error *** [do-build] Error code 1 Stop in /usr/ports/sysutils/kdeadmin4. -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
