GitError raised on CentOS 5.6 about blueprint

[rcrowley]

I can't reproduce on the CentOS 5.6 ami-a14f1ce4 on EC2. I am going to try to reproduce on Rackspace Cloud's CentOS 5.5 image after upgrading it in-place to CentOS 5.6.

[rcrowley]

I can't reproduce on the CentOS 5.5 yum upgraded to 5.6 on Rackspace Cloud.

[lachie]

I'm getting something similar, Ubuntu 10.04.2 LTS, with git 1.7.4.1

# [blueprint] using cached blueprintignore rules
# [blueprint] searching for configuration files
# [blueprint] searching for APT packages
# [blueprint] searching for software built from source
# [blueprint] searching for Python packages
# [blueprint] searching for PEAR/PECL packages
# [blueprint] searching for Ruby gems
# [blueprint] searching for Yum packages
Traceback (most recent call last):
  File "/usr/local/bin/blueprint-create", line 60, in <module>
    b.commit(options.message or '')
  File "/usr/local/lib/python2.6/dist-packages/blueprint/__init__.py", line 238, in commit
    git.init()
  File "/usr/local/lib/python2.6/dist-packages/blueprint/git.py", line 45, in init
    raise GitError(p.returncode)
blueprint.git.GitError: 128

Same thing happens with HEAD or tag v3.0.5

[rcrowley]

@lachie could I trouble you to run this bit of shell code and paste the output back here, please?

Edit: replace "foo" with the name of a blueprint if you have one. Otherwise, this test doesn't make any sense.

export BLUEPRINT="foo"
git --git-dir="$HOME/.blueprints.git" ls-tree "$BLUEPRINT" >/tmp/debugging-tree
echo "git ls-tree: $?"
export BLOB="$(grep blueprint.json </tmp/debugging-tree | cut -f1 | cut -d" " -f3)"
rm -f /tmp/debugging-tree
echo "BLOB: $BLOB"
git --git-dir="$HOME/.blueprints.git" show "$BLOB" | head
echo "git show: $?"

[lachie]

I stuck the snippet in bp_debug.sh, then:

$ sh -x bp_debug.sh 
+ export BLUEPRINT=bp
+ git --git-dir=/root/.blueprints.git ls-tree bp
fatal: Not a git repository: '/root/.blueprints.git'
+ echo git ls-tree: 128
git ls-tree: 128
+ cut -d  -f3
+ cut -f1
+ grep blueprint.json
+ export BLOB=
+ rm -f /tmp/debugging-tree
+ echo BLOB: 
BLOB: 
+ head
+ git --git-dir=/root/.blueprints.git show 
fatal: Not a git repository: '/root/.blueprints.git'
+ echo git show: 0
git show: 0

so then I thought git init --bare .blueprints.git/

and:

$ blueprint create bp
# [blueprint] using cached blueprintignore rules
# [blueprint] searching for configuration files
# [blueprint] searching for APT packages
# [blueprint] searching for software built from source
# [blueprint] searching for Python packages
# [blueprint] searching for PEAR/PECL packages
# [blueprint] searching for Ruby gems
# [blueprint] searching for Yum packages
Traceback (most recent call last):
  File "/usr/local/bin/blueprint-create", line 60, in <module>
    b.commit(options.message or '')
  File "/usr/local/lib/python2.6/dist-packages/blueprint/__init__.py", line 238, in commit
    git.init()
  File "/usr/local/lib/python2.6/dist-packages/blueprint/git.py", line 45, in init
    raise GitError(p.returncode)
blueprint.git.GitError: 128

$ blueprint list
fatal: Not a git repository: '/root/.blueprints.git'
Traceback (most recent call last):
  File "/usr/local/bin/blueprint-list", line 19, in <module>
    for name in blueprint.Blueprint.iter():
  File "/usr/local/lib/python2.6/dist-packages/blueprint/__init__.py", line 49, in iter
    status, stdout = git.git('branch')
  File "/usr/local/lib/python2.6/dist-packages/blueprint/git.py", line 62, in git
    raise GitError(p.returncode)
blueprint.git.GitError: 128

$ cd .blueprints.git
$ git log
fatal: bad default revision 'HEAD'
$ git branch
(no output)
$ echo $?
0

hth & let me know if there's anything else I can help with.

[rcrowley]

@lachie: do you login as root directly? If not, are SUDO_UID and SUDO_GID set (meaningfully) in your environment? Does $SUDO_USER/.blueprints.git exist?

[lachie]

@rcrowley: I go in with sudo -i which gives me a root shell.

SUDO_UID & SUDO_GID seem to be set meaningfully (== login user's uid & gid).

There's no $SUDO_USER/.blueprints.git

[rcrowley]

sudo -i - now I can reproduce the issue. The problem is that the environment's HOME and SUDO_* don't agree in this instance. The workaround is not too difficult so I should have a patch soon.