Verify devel branch works and merge it into master once 0.8 has been released.

[NSkelsey]

I am going to stop playing around with this until, 0.8 gets tagged and work out issues from there. Right now when I run the vagrant setup process, then run the parser php runs into errors which may or may not be my fault, the fault of the commit I am using or just a bug.

For future reference here is the error:

[Mon Oct 14 19:37:08 2013] [error] [client 192.168.42.1] PHP Stack trace:, referer: http://192.168.42.33/admin/?page=parse&noframe=1
[Mon Oct 14 19:37:08 2013] [error] [client 192.168.42.1] PHP   1. {main}() /var/www/statedecoded/htdocs/index.php:0, referer: http://192.168.42.33/admin/?page=parse&noframe=1
[Mon Oct 14 19:37:08 2013] [error] [client 192.168.42.1] PHP   2. MasterController->execute() /var/www/statedecoded/htdocs/index.php:284, referer: http://192.168.42.33/admin/?page=parse&noframe=1
[Mon Oct 14 19:37:08 2013] [error] [client 192.168.42.1] PHP   3. require() /var/www/statedecoded/includes/class.MasterController.inc.php:48, referer: http://192.168.42.33/admin/?page=parse&noframe=1

[waldoj]

runs into errors which may or may not be my fault

If you're having errors, they're my fault. Maybe I wrote documentation poorly, maybe I didn't provide enough inline text, maybe I let a bug slip into the code. But errors are my fault. Period.

For future reference here is the error:

I'm confused by this error, because there's never actually an error, just a stack trace. Is there maybe something else listed above that in the error message that actually complains about a bug in particular?

[NSkelsey]

Yeah there was more above that unfortunately in a fit of rage I destroyed the VM. I'll have to investigate what this next one thinks.

[NSkelsey]

Ok so it was totally my fault (The laws I was trying to import where actually broken static links) and the purported error was really just a PHP notice. So I guess that's good news. This means that the current vagrant setup will get you within two steps of importing laws (updating a line in config.inc.php and moving the laws in). I am going to do the merge tomorrow.

[NSkelsey]

Decided to do the push now, could one of you @waldoj or @rtsio give the updated setup a whirl, if you have vagrant it should be about a 20 minute process. Just be aware that the code you are using for the statedecoded portion of the site references the most recent commit, specifically this one: statedecoded/statedecoded@9ea2569

[rtsio]

@NSkelsey would love to but I've never worked with vagrant before, so it would be faster for @waldoj to do it, I test on EC2 micro instances

[waldoj]

The laws I was trying to import where actually broken static links

Interesting! This makes me wonder if a file-validity step ought to be included. I'd omitted it because it really, really slows down the process of importing tens of thousands of files, but maybe it's worth at least testing the first file.

I'll download this and try it out shortly, @NSkelsey. I'm looking forward to it!

[waldoj]

So I got this far:

• Download a copy of this repository and unzip it into a directory.
• At the command line, change into the directory that contains this repository.
• Download the git submodules using: git submodule init; git submodule update

It ended like such:

# git submodule init; git submodule update
fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git

So I clone the repository, instead of downloading it as a ZIP, and then it went like such:

# git submodule init; git submodule update
Submodule 'modules/solr' () registered for path 'modules/solr'
Submodule 'src' () registered for path 'src'
fatal: Needed a single revision
Unable to find current revision in submodule path 'src'

I'm running vagrant up anyway. Vagrant is chewing it over now. :)

[waldoj]

Things are happening!

[NSkelsey]

 Download a copy of this repository and unzip it into a directory.

This needs to change to git clone... My bad

 # git submodule init; git submodule update
 Submodule 'modules/solr' () registered for path 'modules/solr'
 Submodule 'src' () registered for path 'src'
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'src'

I tried to reproduce the submodule problem on my Mac partition and the command seems to work fine. So I am not sure what is causing that.

  I'm running vagrant up anyway. Vagrant is chewing it over now. :)

I am curious to hear what ended up happening, because if the submodules didn't get downloaded the puppet run should have failed.

[waldoj]

It's still running, though it's been stuck for at least ~20 minutes. Here's a Gist of the output.

[NSkelsey]

Hmmm, do you see network traffic? It may be downloading solr very slowly or if not it may have just got stuck. In either case you can log into the box and run to try the puppet setup again. (It should be idempotent)

sudo puppet apply -vd --modulepath
'/etc/puppet/modules:/tmp/vagrant-puppet/modules-0' --manifestdir
/tmp/vagrant-puppet/manifests --detailed-exitcodes
/tmp/vagrant-puppet/manifests/default.pp

A better option would be to discard the box and try again cleanly. For whats it worth, I just did the vagrant up on my mac and it worked swimmingly.

[waldoj]

No network traffic. I'll try again.

[waldoj]

I ran vagrant destroy, deleted statedecoded-vagrant/, cloned it from GitHub again, and ran git submodule init; git submodule update again, with the same result:

# git submodule init; git submodule update
Submodule 'modules/solr' () registered for path 'modules/solr'
Submodule 'src' () registered for path 'src'
fatal: Needed a single revision
Unable to find current revision in submodule path 'src'

Any theories?

[NSkelsey]

Different versions of git? Here is mine:

Ishtar $ git --version
git version 1.7.7.5 (Apple Git-26)

Apparently there are things called git subtrees which do similar things but are supported by more versions of git. Bleh

[waldoj]

#  git --version
git version 1.7.7

[NSkelsey]

Ok I will have to test this on other systems. But try removing the submodule directories (src and modules/solr) and running:

git submodule update --init

This stackoverflow was my reference

If that doesn't work I am finding a better way to include these files...

[waldoj]

It looks like that went well:

# git submodule update --init
Submodule 'modules/solr' () registered for path 'modules/solr'
Submodule 'src' () registered for path 'src'
Cloning into modules/solr...
remote: Counting objects: 285, done.
remote: Compressing objects: 100% (159/159), done.
remote: Total 285 (delta 131), reused 259 (delta 107)
Receiving objects: 100% (285/285), 47.25 KiB, done.
Resolving deltas: 100% (131/131), done.
Submodule path 'modules/solr': checked out '8d791eeb24a0caa296ef3cf8b8f3cfd743ba28e6'
Cloning into src...
remote: Counting objects: 7709, done.
remote: Compressing objects: 100% (3787/3787), done.
remote: Total 7709 (delta 3954), reused 7452 (delta 3706)
Receiving objects: 100% (7709/7709), 62.93 MiB | 2.39 MiB/s, done.
Resolving deltas: 100% (3954/3954), done.
Submodule path 'src': checked out '9ea25690375f26e85e5770191bb4fad0278da4e6'

vagrant up worked, too. I'll start playing around with it!

[waldoj]

By gum, it works!

[NSkelsey]

:) I will update the readme

and now onto solr problems!