Re: [gitorious] Fedora packaging (was: Gitorious Versioning)
Hi, > #3: Fedora has dropped ruby-net-ldap in favor of net-ldap. I don't yet > know how much work it would be to patch Gitorious to use the net-ldap > Gem. Its the same. In fact, I think I did a merge request a couple of months ago with this change. It got delayed and I need to re-do the change based on the latest but didn't upgrade to the latest. But net-ldap is just a new version of net-ruby-ldap and the change (for me) took no effort. Bas > > If there's anything else I should know about in terms of dependencies > (present or future plans) I'm very interested. > > [1] https://fedoraproject.org/wiki/User:Ktdreyer/Gitorious > [2] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries > [3] https://issues.gitorious.org/issues/3 > > -- > To post to this group, send email to gitorious@googlegroups.com > To unsubscribe from this group, send email to > gitorious+unsubscr...@googlegroups.com -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Fedora packaging (was: Gitorious Versioning)
Nice summary. Having done a few,substantial webapps on other platforms but not RoR, I'm not sure how relevant my perspective is. All the same, I know that in *app deployment* I see value in bundling to isolate my apps for stability. Lockdown is the line of last defense against hyperactive upstream changes. But I also think that Fedora have eloquently articulated the causes which impel them to resist bundling in packaged apps. Thanks for sharing that well reasoned link. Packages inevitably require maintenance, and it only gets more expensive the longer it goes. On Aug 3, 2012 10:36 AM, "Ken Dreyer" wrote: > On Fri, Aug 3, 2012 at 3:15 AM, Marius Mårnes Mathiesen > wrote: > > While we're at the packaging topic: I saw some posts on a Fedora mailing > > list that you're working on packaging Gitorious for Fedora, that would be > > really great! Any news? Need help? > > Nice, thanks for asking. I've broken out all the steps that must be > done [1]. There's a brief summary under "High Level Steps and Issues". > > I spent a couple of weeks packaging up all the requisite gems, but I > was working against EPEL 6, and my specs are not up to the latest Ruby > standards for Fedora packaging. I anticipate this is still going to be > about 50% of the work. > > I think the other 50% is going to be Gitorious itself. Here's the > big-ish items that are relevant to you as the upstream project: > > #1: I'm pretty sure the old Rails version under vendor/ is going to be > a blocker to getting Gitorious itself into Fedora [2]. Fedora 17 has > Rails 3.0, and Fedora 18 is going to have Rails 3.2. I see a couple of > branches in mainline ("rails-3.0" and "rails-3.1"), and there's the > bug report in redmine [3] but I'm not sure where else to look. I'm a > RoR newbie so I don't have a good feel for how much work this would > involve... my guess is that it's a lot :) > > #2: Another big "unknown" for me is Ruby 1.9.3 compatibility. I'm > hoping that the test suite is going to assist me here. I would really > like to get "rake test" to pass during the builds on all versions of > Fedora and EPEL 6. (It looks like there's one or two gems that are > Ruby 1.8-only, also, so I need to get familiar with those.) > > #3: Fedora has dropped ruby-net-ldap in favor of net-ldap. I don't yet > know how much work it would be to patch Gitorious to use the net-ldap > Gem. > > If there's anything else I should know about in terms of dependencies > (present or future plans) I'm very interested. > > [1] https://fedoraproject.org/wiki/User:Ktdreyer/Gitorious > [2] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries > [3] https://issues.gitorious.org/issues/3 > > -- > To post to this group, send email to gitorious@googlegroups.com > To unsubscribe from this group, send email to > gitorious+unsubscr...@googlegroups.com > -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Fedora packaging (was: Gitorious Versioning)
On Fri, Aug 3, 2012 at 3:15 AM, Marius Mårnes Mathiesen wrote: > While we're at the packaging topic: I saw some posts on a Fedora mailing > list that you're working on packaging Gitorious for Fedora, that would be > really great! Any news? Need help? Nice, thanks for asking. I've broken out all the steps that must be done [1]. There's a brief summary under "High Level Steps and Issues". I spent a couple of weeks packaging up all the requisite gems, but I was working against EPEL 6, and my specs are not up to the latest Ruby standards for Fedora packaging. I anticipate this is still going to be about 50% of the work. I think the other 50% is going to be Gitorious itself. Here's the big-ish items that are relevant to you as the upstream project: #1: I'm pretty sure the old Rails version under vendor/ is going to be a blocker to getting Gitorious itself into Fedora [2]. Fedora 17 has Rails 3.0, and Fedora 18 is going to have Rails 3.2. I see a couple of branches in mainline ("rails-3.0" and "rails-3.1"), and there's the bug report in redmine [3] but I'm not sure where else to look. I'm a RoR newbie so I don't have a good feel for how much work this would involve... my guess is that it's a lot :) #2: Another big "unknown" for me is Ruby 1.9.3 compatibility. I'm hoping that the test suite is going to assist me here. I would really like to get "rake test" to pass during the builds on all versions of Fedora and EPEL 6. (It looks like there's one or two gems that are Ruby 1.8-only, also, so I need to get familiar with those.) #3: Fedora has dropped ruby-net-ldap in favor of net-ldap. I don't yet know how much work it would be to patch Gitorious to use the net-ldap Gem. If there's anything else I should know about in terms of dependencies (present or future plans) I'm very interested. [1] https://fedoraproject.org/wiki/User:Ktdreyer/Gitorious [2] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [3] https://issues.gitorious.org/issues/3 -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Re: message queue : preferred or recommended choices?
Thanks again, Maurius. I see that resque seems to be pretty popular. Cool. I get to reuse what I know about Redis. :) On Aug 3, 2012 2:18 AM, "Marius Mårnes Mathiesen" < marius.mathie...@gmail.com> wrote: > On Thu, Aug 2, 2012 at 8:29 PM, Carlos wrote: > >> >> I see the options have expanded to include resque and what appears to be >> a lightweight synchronous messaging mode. I'm really not interested in >> sync. I wonder if anyone can offer some general advice on picking resque >> versus stopm vs. activemq. I am not a Rubyist, but it looks to me like the >> ActiveMessaging page mentioned in the docs [ >> http://code.google.com/p/activemessaging/wiki/Installation] has not been >> updated in a while. I'd like to go with soemthing which is actively >> maintained. >> > > Carlos, > If we could do it without breaking existing installations we would throw > out the ActiveMessaging code right now and go with Rescue. You should be > able to do so by > > - install Redis > - set messaging_adapter: resque in gitorious.yml > - run the poller > > Cheers, > - Marius > > -- > To post to this group, send email to gitorious@googlegroups.com > To unsubscribe from this group, send email to > gitorious+unsubscr...@googlegroups.com > -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Re: LDAP Authentication
Oh wow thank you very much! Works like a charm! On Thursday, August 2, 2012 10:47:00 PM UTC-4, Federico Don wrote: > > could you try with this setup? > > production: > disable_default: false > methods: > - adapter: Gitorious::Authentication::LDAPAuthentication > host: 172.17.195.115 > port: 389 > base_dn: DC=example,DC=com > bind_username: user_ldap_bind > bind_password: password_user_ldap_bind > user_filter: > username_attribute: sAMAccountName > encryption: none > login_attribute: uid > distinguished_name_template: "uid={},OU=users,DC=example,DC=com" > attribute_mapping: > mail: email > > I hope your comment! > > Regards, > > 2012/8/2 Kevin Pelletier > >> Yes I do. I just did a new installation this week. >> >> Kevin >> >> On Thursday, August 2, 2012 11:38:36 AM UTC-4, Federico Don wrote: >>> >>> Do you have a last version for gitorious? >>> >>> Regards, >>> >>> 2012/8/1 Kevin Pelletier >>> This is my authentication.yml production: disable_default: true methods: - adapter: Gitorious::Authentication::**LDAPAuthentication host: 192.168.4.22 port: 389 base_dn: DC=lan,DC=lexum,DC=pri login_attribute: uid encryption: none attribute_mapping: mail: email username_attribute: sAMAccountName On Wednesday, August 1, 2012 10:46:56 AM UTC-4, Kevin Pelletier wrote: > > Hi Marius, > > Thanks for the quick reply. Indeed, it didn't work. I checked it out, > but still I'm having the same error message. This is what I did : > > git checkout features/ldap_authorization > > RAILS_ENV=production bundle exec script/test_ldap_connection > pelletierk ** > > Not there yet. > script/test_ldap_connection:**22**: private method `build_username' > called for # > (NoMethodError) > > Kevin > > On Wednesday, August 1, 2012 1:52:03 AM UTC-4, Marius Mårnes Mathiesen > wrote: >> >> Kevin, >> Would you mind trying to check out the features/ldap_authorization >> branch from mainline and see how it works there? There's quite a lot of >> new >> stuff in there, and I think there's a fix to the error message you're >> seeing as well. >> >> >> Cheers, >> - Marius >> >> On Tue, Jul 31, 2012 at 9:19 PM, Kevin Pelletier < >> kevvv.pellet...@gmail.com> wrote: >> >>> No I haven't. Still same error message >>> >>> >>> On Friday, April 20, 2012 7:12:12 PM UTC-4, beepy wrote: Did you ever get this solved? Ben, On Wednesday, 16 November 2011 11:00:48 UTC-8, Kevin Pelletier wrote: > > Hi, > > I've been trying out lately the latest feature with LDAP > Authentication. I'm not that much used to the ruby environment so > excuse my missing knowledge if this looks like an easy question. > When > I try to test the LDAP connection, this is the error I get : > > /home/git/gitorious/vendor/**rails/activesupport/lib/**active_ > **su**pport/ > dependencies.rb:443:in `load_missing_constant': uninitialized > constant > SampleCallback (NameError) > from > /home/git/gitorious/vendor/**rails/activesupport/lib/ > > active_support/dependencies.**rb:80:in `const_missing' > from > /home/git/gitorious/vendor/**rails/activesupport/lib/ > > active_support/dependencies.**rb:92:in `const_missing' > from > /home/git/gitorious/vendor/**rails/activesupport/lib/ > > active_support/inflector.rb:**361:in `constantize' > from > /home/git/gitorious/vendor/**rails/activesupport/lib/ > > active_support/inflector.rb:**360:in `each' > from > /home/git/gitorious/vendor/**rails/activesupport/lib/ > > active_support/inflector.rb:**360:in `constantize' > from > /home/git/gitorious/vendor/**rails/activesupport/lib/ > > active_support/core_ext/**string/inflections.rb:162:in > `constantize' > from /home/git/gitorious/lib/**gitorious/authentication/ > > ldap_authentication.rb:44:in `setup_attributes' > from /home/git/gitorious/lib/**gitorious/authentication/ > > ldap_authentication.rb:28:in `initialize' > from /home/git/gitorious/lib/**gitorious/authentication/ > > configuration.rb:41:in `new' > from /home/git/gitorious/lib/**gitor
Re: [gitorious] Re: Tests fail
Thanks, Marius. I will try with ruby 1.8. Based on some comments I read, I thought problems with ruby 1.9 might be limited to encodings...which I hoped I could work around. Maybe not. I realize that a lot of apps are frozen on ruby 1.8. That's ok. I don't see many people rushing to adopt python 3 either. :) On Aug 3, 2012 2:08 AM, "Marius Mårnes Mathiesen" < marius.mathie...@gmail.com> wrote: > On Fri, Aug 3, 2012 at 11:03 AM, Carlos wrote: > >> >> Possibly related: >> >> It appears that gitorious includes a locked down activesupport 2.3.5 in >> vendor/rails. >> I have the activesupport 3.2.7 installed from gems. Is this a problem? >> > > Carlos, > Gitorious uses a "vendored" version of Rails, and will not work with > system versions of it, but as long as you use Bundler, this version > shouldn't be used anyway. > > But your main problem is probably that you're running Ruby 1.9.3, which > isn't supported by Gitorious. The symptom you're seeing is that you need an > additional gem for test/unit under 1.9, but you're bound to run into more > problems once you get this resolved. You really should install an older > Ruby version on your server; you could use either rbenv ( > https://github.com/sstephenson/rbenv/) or rvm (https://rvm.io/) if you > need to run 1.9-based Ruby apps alongside Gitorious. > > Cheers, > - Marius > > -- > To post to this group, send email to gitorious@googlegroups.com > To unsubscribe from this group, send email to > gitorious+unsubscr...@googlegroups.com > -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Re: message queue : preferred or recommended choices?
On Thu, Aug 2, 2012 at 8:29 PM, Carlos wrote: > > I see the options have expanded to include resque and what appears to be a > lightweight synchronous messaging mode. I'm really not interested in > sync. I wonder if anyone can offer some general advice on picking resque > versus stopm vs. activemq. I am not a Rubyist, but it looks to me like the > ActiveMessaging page mentioned in the docs [ > http://code.google.com/p/activemessaging/wiki/Installation] has not been > updated in a while. I'd like to go with soemthing which is actively > maintained. > Carlos, If we could do it without breaking existing installations we would throw out the ActiveMessaging code right now and go with Rescue. You should be able to do so by - install Redis - set messaging_adapter: resque in gitorious.yml - run the poller Cheers, - Marius -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning
On Thu, Aug 2, 2012 at 3:37 AM, Ken Dreyer wrote: > Speaking as a packager, even if we didn't have backports and multiple > supported branches, it would be cool if Gitorious AS cut new versions > a bit more often. If that were the case, who knows, we might get a > step closer to ending the plethora of guides on the internet that say > "clone mainline and run whatever commit you land on" :) > Ken, While we're at the packaging topic: I saw some posts on a Fedora mailing list that you're working on packaging Gitorious for Fedora, that would be really great! Any news? Need help? Cheers, - Marius -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning
On Thu, Aug 2, 2012 at 3:37 AM, Ken Dreyer wrote: > On Wed, Aug 1, 2012 at 4:17 AM, dpwrussell wrote: > > I see that there is the concept of versioning for some time now in > > Gitorious, but all the installation instructions I have seen involve a > > checkout from mainline (If versioning is active I'd have expected a > checkout > > of a certain version branch). > > I've noticed this also, and from a package management perspective this > is not really ideal... I think the main reason people do this is that > Gitorious development happens pretty quickly, so master is now quite > different than what was tagged as v2.2.1. Various Gitorious guides out > there on the internet recommend running master because that's what > gets all the latest features and bugfixes. Gitorious AS doesn't really > do backports to stable branches. You basically have to pick whatever > tag "git describe" tells you (which is unfortunately seven months old > now) and freeze there, or else just go with the tip of master. > > Speaking as a packager, even if we didn't have backports and multiple > supported branches, it would be cool if Gitorious AS cut new versions > a bit more often. If that were the case, who knows, we might get a > step closer to ending the plethora of guides on the internet that say > "clone mainline and run whatever commit you land on" :) > Sorry, we've been lazy :-( The next scheduled minor version will introduce LDAP-backed authorization, and should be out within a couple of week. > I've spent ages looking, but I can't find out > > which version I'm running > > To find what version you're running, look in lib/gitorious.rb > Or use the included rake task (`[bundle exec] rake versioning:changelog`), it will list all known versions and highlight which of them you're currently using. > > > or what the roadmap is for releases. Where is this > > information? > > As for a release roadmap, I'm not sure there is an "official" one, but > there's plenty of items on the "Wishlist" and "Todo" wiki pages. > My colleague Thomas just (re-)mentioned that we should do a roadmap this morning, it's something we really need. Cheers, - Marius -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Re: Tests fail
On Fri, Aug 3, 2012 at 11:03 AM, Carlos wrote: > > Possibly related: > > It appears that gitorious includes a locked down activesupport 2.3.5 in > vendor/rails. > I have the activesupport 3.2.7 installed from gems. Is this a problem? > Carlos, Gitorious uses a "vendored" version of Rails, and will not work with system versions of it, but as long as you use Bundler, this version shouldn't be used anyway. But your main problem is probably that you're running Ruby 1.9.3, which isn't supported by Gitorious. The symptom you're seeing is that you need an additional gem for test/unit under 1.9, but you're bound to run into more problems once you get this resolved. You really should install an older Ruby version on your server; you could use either rbenv ( https://github.com/sstephenson/rbenv/) or rvm (https://rvm.io/) if you need to run 1.9-based Ruby apps alongside Gitorious. Cheers, - Marius -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
[gitorious] Re: Tests fail
Possibly related: It appears that gitorious includes a locked down activesupport 2.3.5 in vendor/rails. I have the activesupport 3.2.7 installed from gems. Is this a problem? On Friday, August 3, 2012 1:42:34 AM UTC-7, Carlos wrote: > > > I was able to get the tests to run -- more or less - by making simple > changes to > > # modified: test/functional/favorites_controller_test.rb > # modified: test/integration/git_http_cloning_test.rb > # modified: test/unit/message_thread_test.rb > > The tests are very noisy for me at the moment. I get that the deprecation > warning fro Config (RbConfig is preferred) may be coming from the fact that > I am running Ruby 1.9. But there are a number of other deprectation > warning which appear to be specific to gitorious or components it uses > internally. I won't dump logs here. > > The overall result is that I have not seen a clean run of rake test yet. > I'm wondering what the developers are using for a test arrangement and > what the expected regressions are at this time. > > FWIW: I am up-to-date with hash 3f1cf390bf05634451d825bc7bb0f10848710f3f > plus a the few edits I have described to get install/test to run this far. > > Thanks! > > > On Thursday, August 2, 2012 12:41:24 PM UTC-7, Carlos wrote: >> >> >> Hi. Sorry to pepper the list with questions, but I think these are >> things people trying to set up gitorious are likely to encounter. >> >> I got the databases created and setup for production, development and >> test environments. >> >> Then I try to run the tests: bundle exec rake test >> >> I get three stack-traces, one for each of the sets of tests (unit, >> functional and integration). They all look similar. Here's the trace for >> the unit tests failure: >> >> test/unit/message_thread_test.rb:18:in `require': cannot load such file >> -- test/unit/../test_helper (LoadError) >> from test/unit/message_thread_test.rb:18:in `' >> from >> /usr/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in >> >> `load' >> from >> /usr/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in >> >> `block in ' >> from >> /usr/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in >> >> `each' >> from >> /usr/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in >> >> `' >> >> The file $GITHOME/test/test_helper.rb is *definitely* there. All >> directories/files are owned by git:nogroup. I am running bundle as root. >> >> I tried playing with the path and filename, but it seems fine. I'm >> thinking this might be obvious to a ruby user. >> >> Any ideas? >> >> Platform is Ubuntu 12.04 >> >> # ruby --version >> ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux] >> >> # bundle --version >> Bundler version 1.1.5 >> >> -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
[gitorious] Re: Tests fail
I was able to get the tests to run -- more or less - by making simple changes to # modified: test/functional/favorites_controller_test.rb # modified: test/integration/git_http_cloning_test.rb # modified: test/unit/message_thread_test.rb The tests are very noisy for me at the moment. I get that the deprecation warning fro Config (RbConfig is preferred) may be coming from the fact that I am running Ruby 1.9. But there are a number of other deprectation warning which appear to be specific to gitorious or components it uses internally. I won't dump logs here. The overall result is that I have not seen a clean run of rake test yet. I'm wondering what the developers are using for a test arrangement and what the expected regressions are at this time. FWIW: I am up-to-date with hash 3f1cf390bf05634451d825bc7bb0f10848710f3f plus a the few edits I have described to get install/test to run this far. Thanks! On Thursday, August 2, 2012 12:41:24 PM UTC-7, Carlos wrote: > > > Hi. Sorry to pepper the list with questions, but I think these are things > people trying to set up gitorious are likely to encounter. > > I got the databases created and setup for production, development and test > environments. > > Then I try to run the tests: bundle exec rake test > > I get three stack-traces, one for each of the sets of tests (unit, > functional and integration). They all look similar. Here's the trace for > the unit tests failure: > > test/unit/message_thread_test.rb:18:in `require': cannot load such file -- > test/unit/../test_helper (LoadError) > from test/unit/message_thread_test.rb:18:in `' > from > /usr/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in > > `load' > from > /usr/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in > > `block in ' > from > /usr/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in > > `each' > from > /usr/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in > > `' > > The file $GITHOME/test/test_helper.rb is *definitely* there. All > directories/files are owned by git:nogroup. I am running bundle as root. > > I tried playing with the path and filename, but it seems fine. I'm > thinking this might be obvious to a ruby user. > > Any ideas? > > Platform is Ubuntu 12.04 > > # ruby --version > ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux] > > # bundle --version > Bundler version 1.1.5 > > -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
[gitorious] Grit::Git::GitTimeout
I keep getting this exception when people push to their repositories, it says that the push count since gc is 706 ... which is strange because I ran the repo_housekeeping script and it told me that it gc'ed this repository. This is running on a stand-alone server, 2 dual core CPU's (4 cores total) with 16 GB of RAM and the repositories are on a md based mirror with 2 SATA drives and no other IO on it (MySQL and OS are on a different md backed mirror). I moved this off a VMWare based virtual server because of IO issues, this server has plenty of IO power. Is there anything I can do to figure out why these are failing? Where should I start looking? Here are some stats for the repository: Commits: 3402 Repo size at fresh clone: 53M Files in repo: 835 Directories: 343 I'm at a loss here. Worst case I will most likely simply modify Grit to set the timeout to something longer than 10 seconds and hope that it doesn't re-appear for a while. An exception occured in #", project_id: 1, user_id: 1, created_at: "2011-07-01 00:00:00", updated_at: "2012-08-02 00:00:00", parent_id: 1, ready: true, kind: 3, owner_type: "User", owner_id: 1, hashed_path: "", description: nil, last_pushed_at: "2012-08-02 00:00:00", wiki_permissions: 0, deny_force_pushing: false, notify_committers_on_new_merge_request: true, last_gc_at: nil, merge_requests_enabled: true, disk_usage: 46292359, push_count_since_gc: 706>, @spec= #, @ref= #, @to_sha= #>, @user= # ! Grit::Git::GitTimeout: Grit::Git::GitTimeout -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
[gitorious] Grit::Git::GitTimeout
This exception keeps getting thrown, now I don't understand why, and I have no idea how to even start debugging the situation. Let me describe the hardware I am running on and some basic stats about the repository, if you guys have any ideas as to where I can start looking i'd appreciate that. Hardware: 2 CPU's with 2 cores is a total of 4 cores. 16 GB of RAM 4 x SATA drive (2 drives in an MD raid 1, and 2 more drives in an MD raid 1) The git repositories are sitting on the second md raid 1. The repository stats: Commits: 3402 .git size on fresh clone: 33M Files in repo: 835 Directories: 343 Worst case I will most likely increase the Grit timeout to 20 or even 30 seconds in an attempt to stave off this issue for a little while, although I have a bad feeling this will continue... Thanks, Bert An exception occured in #", project_id: 2, user_id: 7, created_at: "2011-07-20 23:31:31", updated_at: "2012-08-02 02:02:31", parent_id: 17, ready: true, kind: 3, owner_type: "User", owner_id: 7, hashed_path: "", description: nil, last_pushed_at: "2012-08-02 02:02:31", wiki_permissions: 0, deny_force_pushing: false, notify_committers_on_new_merge_request: true, last_gc_at: nil, merge_requests_enabled: true, disk_usage: 46292359, push_count_since_gc: 706>, @spec= #, @ref= #, @to_sha= #>, @user= #> ! Grit::Git::GitTimeout: Grit::Git::GitTimeout storage/git/gitorious/vendor/grit/lib/grit/git.rb:101:in `sh' /storage/git/gitorious/vendor/grit/lib/grit/git.rb:71:in `run' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /storage/git/gitorious/vendor/grit/lib/grit/git.rb:70:in `run' /storage/git/gitorious/vendor/grit/lib/grit/git.rb:57:in `method_missing' /storage/git/gitorious/lib/event_rendering/text.rb:322:in `diff_body' /storage/git/gitorious/lib/event_rendering/text.rb:318:in `add_diff_content' /storage/git/gitorious/lib/event_rendering/text.rb:243:in `render_push_summary' /storage/git/gitorious/lib/event_rendering/text.rb:104:in `render' /storage/git/gitorious/lib/event_rendering/text.rb:31:in `render' /storage/git/gitorious/app/models/favorite.rb:63:in `notify_about_event' /storage/git/gitorious/app/models/event.rb:166:in `notify_subscribers' /storage/git/gitorious/app/models/event.rb:165:in `each' /storage/git/gitorious/app/models/event.rb:165:in `notify_subscribers' /storage/git/gitorious/vendor/rails/activesupport/lib/active_support/callbacks.rb:178:in `send' /storage/git/gitorious/vendor/rails/activesupport/lib/active_support/callbacks.rb:178:in `evaluate_method' /storage/git/gitorious/vendor/rails/activesupport/lib/active_support/callbacks.rb:166:in `call' /storage/git/gitorious/vendor/rails/activesupport/lib/active_support/callbacks.rb:93:in `run' /storage/git/gitorious/vendor/rails/activesupport/lib/active_support/callbacks.rb:92:in `each' /storage/git/gitorious/vendor/rails/activesupport/lib/active_support/callbacks.rb:92:in `send' /storage/git/gitorious/vendor/rails/activesupport/lib/active_support/callbacks.rb:92:in `run' /storage/git/gitorious/vendor/rails/activesupport/lib/active_support/callbacks.rb:276:in `run_callbacks' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/callbacks.rb:344:in `callback' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/callbacks.rb:267:in `create' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/base.rb:2876:in `create_or_update_without_callbacks' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/callbacks.rb:250:in `create_or_update' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/base.rb:2540:in `save_without_validation' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/validations.rb:1078:in `save_without_dirty' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/dirty.rb:79:in `save_without_transactions' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/transactions.rb:229:in `send' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/transactions.rb:229:in `with_transaction_returning_status' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:136:in `transaction' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/transactions.rb:182:in `transaction' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/transactions.rb:228:in `with_transaction_returning_status' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/transactions.rb:196:in `save' /storage/git/gitorious/vendor/rails/activerecord/lib/active_record/transactions.rb:208:in