Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsen si...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? Just some things I'm able to rattle off that come to mind with git.. Some arguments `for git'... 1. One tool to rule them all: - cvsup/csup can be replaced with git archive [1]. - cvs git scales a bit better. - less support cost for p4 and lower likelihood of downtime in the event of critical failure (perforce's proprietary DB is a pain to recover I've recently discovered from other dealings). - svn - cvs exporter is no longer required as it's all one SCM. - As a side-effect, the bits present in CVS and SVN would now be 100% in sync, unlike cvs which can lead svn in terms of commits (at least that was the case when I last talked to someone about version numbering in pkg_install done by re@). 2. More evolved tool: - branches are cheap and can be local or remote. - distributed SCM seem to work well with large groups of developers. - works better with branching and merging from what I've seen. Some arguments against git... - The one caveat to cvsup/csup that's awesome is its componentization capability, i.e. being able to selectively download components in src / ports; I'm not 100% sure but there doesn't appear to be a clear analog in git. It might be achievable through gits remote.group in git-config, git-remote, etc, but I would need to prototype whether or not this is true. - Higher learning curve. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). - More items might be here Some more git experienced folks could comment here, but it would be nice to unify all of the systems under `one flag' for the sake of simplicity and hopefully the sanity of the tool maintainers (Simon, et all). Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon Jan 24 11, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsen si...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? Just some things I'm able to rattle off that come to mind with git.. it would also be nice to have github running on freebsd.org. that way it would be much easier to discuss src changes without having to point people at a file, a function or even a specific line. also it would finally kill the mailinglists, which have lots of issues: spam, broken mailman installation, people going berserker when they see lines 80 etc. there have been a few attempts to introduce a code review system, but since that was all hosted on foreign websites the idea never cought on and afaik those websites weren't being supported/promoted by freebsd.org. but personally i don't expect a change like this to happen in the near future. basically most of the freebsd administrative people are quite conservative. i wouldn't be surprised if some them are still trying to run freebsd on their typewriters. ;) cheers. alex Some arguments `for git'... 1. One tool to rule them all: - cvsup/csup can be replaced with git archive [1]. - cvs git scales a bit better. - less support cost for p4 and lower likelihood of downtime in the event of critical failure (perforce's proprietary DB is a pain to recover I've recently discovered from other dealings). - svn - cvs exporter is no longer required as it's all one SCM. - As a side-effect, the bits present in CVS and SVN would now be 100% in sync, unlike cvs which can lead svn in terms of commits (at least that was the case when I last talked to someone about version numbering in pkg_install done by re@). 2. More evolved tool: - branches are cheap and can be local or remote. - distributed SCM seem to work well with large groups of developers. - works better with branching and merging from what I've seen. Some arguments against git... - The one caveat to cvsup/csup that's awesome is its componentization capability, i.e. being able to selectively download components in src / ports; I'm not 100% sure but there doesn't appear to be a clear analog in git. It might be achievable through gits remote.group in git-config, git-remote, etc, but I would need to prototype whether or not this is true. - Higher learning curve. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). - More items might be here Some more git experienced folks could comment here, but it would be nice to unify all of the systems under `one flag' for the sake of simplicity and hopefully the sanity of the tool maintainers (Simon, et all). Thanks! -Garrett -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On 24.1.2011 9:13, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremypeterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsensi...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I think des is working on svnup to work directly on the SVN tree. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? As long as we're choosing bikeshed colour, I would like to drop mercurial here :) Mainly because of this: - Higher learning curve. I found Mercurial to have an easier learning curve and to be something like a DSCM for the users of CVS/SVN. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). I don't know if we're talking about the same thing, but I've also noticed git tends to do things the long way around which should be simple. Git's also much lower level. They both support pretty much the same feature set; here's a cute but dated comparison: http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ Hg is/was AFAIK used by Sun. Anyway, personally, svn is good enough :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Querying bsnmpd through /var/run/snmpd.sock
On Sun, 23 Jan 2011, Eugene Grosbein wrote: EGbsnmpd running with mibII module opens local socket /var/run/snmpd.sock EGmentioned in snmp_mibII(3) manual page: EG EG The mibII module opens a socket that is used to execute all network EG related ioctl(2) functions. This socket is globally available under the EG name mib_netsock. EG EGHow do I use the socket? I hope to be able to call mib_find_if_sys() function EGfrom another process using the socket. Is there a documentation for this? The socket works just like a UDP socket with the additional plus that the daemon knows whether you're root or not. As I said in my previous mail, easiest would be to implement an additional table with the sysindex as index and ifIndex as a row. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Tracking down a problem with php on FreeBSD
On 23.1.2011 23:58, Ruslan Mahmatkhanov wrote: Good day! We are using custom php application on FreeBSD 8.1R amd64. It is started with php-fpm 5.3.3 from ports as backend and nginx 0.8.54 as frontend. Several times per day this app is making self unavailable. I think it would be more appropriate to ask this on the stable@ list. Simple php-fpm restart solves the problem, but i need to track it down to the cause of this situation and ask for your assistance and instructions on how to debug it. Some facts about this: On one hand, FPM is said to be very experimental... Personally, I've been using apache22-worker or apache22-event + mod_fcgid for years without trouble. - I don't know how to manually reproduce this, but it happens several times every day - It happens on FreeBSD 7.x too - It happens with apache+mod_php instead php-fpm - It happens with lighthttpd instead nginx - It happens with both SHED_4BSD and SHED_ULE - It doesn't happen on php = 5.2.12 - It happens with and w/o eaccelerator It looks very application-specific, possibly not really an OS problem (or maybe a problem of different expectations from the OS when porting from Linux). - `top -mio` shows very high (8-9 for VCSW) VCSW/IVCSW values for php-fpm processes and LA is more than 120 How many real user request are in these 120? Do any users at the time of problem (this doesn't look like a crash) receive valid responses? - user seeing http 502 error code in browser - php-fpm log has many of this lines in time of crash: Jan 23 17:56:58.176425 [WARNING] [pool world] server reached max_children setting (100), consider raising it Did you try raising it? Does the error happen ONLY when this limit is reached? 2011/01/23 17:57:00 [error] 38018#0: *26006023 writev() failed (54: Connection reset by peer) while sending request to upstream, client: xx.xx.xx.xx, server: some.server.org, request: POST /?ctrl=Chat a=chatList__path=chat_listh=8093b9e1cf448762d5677e21bded97ae h1=38ca8b747a46098c3b1a4f39e6658170 HTTP/1.1, upstream: fastcgi://127.0.0.1:9002, host: some.server.org, referrer: http://some.server.org/; 2011/01/23 17:57:00 [error] 38016#0: *26029878 kevent() reported about an closed connection (54: Connection reset by peer) while reading response header from upstream, client: xx.xx.xx.xx, server: some.server.org, request: POST /?ctrl=Locationa=refresh __path=refreshh=276f591df26a65d9a1736f6e1006f4ab h1=3c0916c16b1fc2e7015b71e90bbc3d23 HTTP/1.1, upstream: fastcgi://127.0.0.1:9002, host: some.server.org, referrer: http://some.server.org/; 2011/01/23 17:57:02 [crit] 38020#0: *26034390 open() /tmp/nginx /client_temp/1/74/000741 failed (13: Permission denied) while sending request to upstream, client: xx.xx.xx.xx, server: some.server.org, request: POST /?ctrl=Chata=send__path=chat_send h=4a27d8d382ba9b1059412323a451ef84 h1=b0a53c86e3c744a01356a5030559ed1a HTTP/1.1, upstream: fastcgi://127.0.0.1:9002, host: some.server.org, referrer: http://some.server.org/; 2011/01/23 17:57:02 [alert] 38020#0: *26034390 http request count is zero while sending to client, client: xx.xx.xx.xx, server: some.server.org, request: POST /?ctrl=Chata=send__path=chat_send h=4a27d8d382ba9b1059412323a451ef84 h1=b0a53c86e3c744a01356a5030559ed1a HTTP/1.1, upstream: fastcgi://127.0.0.1:9002, host: some.server.org, referrer: http://some.server.org/; 2011/01/23 17:57:03 [error] 38014#0: *25997903 upstream prematurely closed connection while reading response header from upstream, client: 109.229.69.186, server: some.server.org, request: POST /?ctrl=Chata=chatList__path=chat_list h=c8723de73c4f8ebb98f9bf746d75e965 h1=3ab289760a009b07b73c6d96cc94a509 HTTP/1.1, upstream: fastcgi://127.0.0.1:9002, host: some.server.org, referrer: http://some.server.org/; These are some very varied errors, not especially consistent with each other. Did you try some generic socket TCP tuning like described in http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel ? Other than that, you will probably have to debug the php-fpm processes. Start by observing in which state they are (top without -mio). If the processes are blocking, try procstat -k pid on them. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 5:33 AM, Ivan Voras ivo...@freebsd.org wrote: On 24.1.2011 9:13, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremypeterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsensi...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I think des is working on svnup to work directly on the SVN tree. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? As long as we're choosing bikeshed colour, I would like to drop mercurial here :) Mainly because of this: - Higher learning curve. I found Mercurial to have an easier learning curve and to be something like a DSCM for the users of CVS/SVN. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). I don't know if we're talking about the same thing, but I've also noticed git tends to do things the long way around which should be simple. Git's also much lower level. They both support pretty much the same feature set; here's a cute but dated comparison: http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ Hg is/was AFAIK used by Sun. Anyway, personally, svn is good enough :) Ok. Obviously this was just a fleeting thought so let's close the git topic. I do hope that whatever des has cooking up though can replace cvsup/csup reliably though, and if CVS would die at least that would be nice... Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 02:33:25PM +0100, Ivan Voras wrote: On 24.1.2011 9:13, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremypeterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsensi...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of ... As long as we're choosing bikeshed colour, I would like to drop mercurial here :) As long as it is not GPL. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On 24 January 2011 19:31, Diane Bruce d...@db.net wrote: As long as it is not GPL. Unless there's a missing smiley in that sentence there, it is a tough requirement. Of the major SCMs, only Subversion is non-GPL-ed (even CVS is...). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote: On 24 January 2011 19:31, Diane Bruce d...@db.net wrote: As long as it is not GPL. Unless there's a missing smiley in that sentence there, it is a tough IRL I'm known to be very dry humoured, I am deadly in e-mail or IRC. requirement. Of the major SCMs, only Subversion is non-GPL-ed (even QED CVS is...). CVS is/was dual licenced. There is also the work openbsd started with CVS sometime ago. Given the work that is being done on clang/llvm to get a non GPL compiler into the tree, perhaps efforts would be better spent on finding SCMs that were also non GPL. There certainly would not be a chance of putting mercurial or git into base for example. Perhaps a point to consider. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 11:48 AM, Diane Bruce d...@db.net wrote: On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote: On 24 January 2011 19:31, Diane Bruce d...@db.net wrote: As long as it is not GPL. Unless there's a missing smiley in that sentence there, it is a tough IRL I'm known to be very dry humoured, I am deadly in e-mail or IRC. requirement. Of the major SCMs, only Subversion is non-GPL-ed (even QED CVS is...). CVS is/was dual licenced. There is also the work openbsd started with CVS sometime ago. Given the work that is being done on clang/llvm to get a non GPL compiler into the tree, perhaps efforts would be better spent on finding SCMs that were also non GPL. There certainly would not be a chance of putting mercurial or git into base for example. But we don't compile CVS, SVN, etc into our sources. I thought that was the whole point of doing the gcc - clang (and friends) conversion, not that the GPL is an undesirable license. Maybe I was missing something about the whole textproc stuff being replaced though (groff, etc) with NetBSD equivalents *shrugs*. Given that this is getting more philosophical than technical, maybe we should move the discussion elsewhere (i.e. not hackers@)? Perhaps a point to consider. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 12:12:19PM -0800, Garrett Cooper wrote: On Mon, Jan 24, 2011 at 11:48 AM, Diane Bruce d...@db.net wrote: On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote: On 24 January 2011 19:31, Diane Bruce d...@db.net wrote: ... But we don't compile CVS, SVN, etc into our sources. I thought which rcs. If you check, the file format on the SVN server is rcs compatible, in fact local checkins using svn will work just fine. Given that this is getting more philosophical than technical, maybe we should move the discussion elsewhere (i.e. not hackers@)? I'd suggest we support fossil (devel/fossil) http://fossil-scm.org No. But in future, keep in mind us old timers are not _that_ conservative. Perhaps a point to consider. Thanks! You are welcome. -Garrett - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
They both support pretty much the same feature set; here's a cute but dated comparison: http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ http://wiki.freebsd.org/VersionControl Table of features comparing SVN HG GIT MTN http://wiki.freebsd.org/ section Development resources (near base of page) Clickable to docs on Mercurial HG Git etc. Anyone having info not documented there already, could help by contributing there ? Maybe add another tool column or add another attribute row, whatever ? Disclaimer: I'm not an author, just a reader, no opinion on one over the other, but that table seems a central place to work toward informed choice ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
Regardless of the benefits, unless there's someone to setup the infrastructure to run things, we're not going to change. We should at least have a master seed for git that people can pull from before we talk about doing anything further. git has the ability to pull from svn, so this should be relatively easy to get going. Warner On 01/24/2011 01:13, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremypeterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsensi...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? Just some things I'm able to rattle off that come to mind with git.. Some arguments `for git'... 1. One tool to rule them all: - cvsup/csup can be replaced with git archive [1]. - cvs git scales a bit better. - less support cost for p4 and lower likelihood of downtime in the event of critical failure (perforce's proprietary DB is a pain to recover I've recently discovered from other dealings). - svn- cvs exporter is no longer required as it's all one SCM. - As a side-effect, the bits present in CVS and SVN would now be 100% in sync, unlike cvs which can lead svn in terms of commits (at least that was the case when I last talked to someone about version numbering in pkg_install done by re@). 2. More evolved tool: - branches are cheap and can be local or remote. - distributed SCM seem to work well with large groups of developers. - works better with branching and merging from what I've seen. Some arguments against git... - The one caveat to cvsup/csup that's awesome is its componentization capability, i.e. being able to selectively download components in src / ports; I'm not 100% sure but there doesn't appear to be a clear analog in git. It might be achievable through gits remote.group in git-config, git-remote, etc, but I would need to prototype whether or not this is true. - Higher learning curve. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). -More items might be here Some more git experienced folks could comment here, but it would be nice to unify all of the systems under `one flag' for the sake of simplicity and hopefully the sanity of the tool maintainers (Simon, et all). Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
