Ask Your Question

Build failure after moving submodule

asked 2013-09-05 10:57:00 -0500

updated 2013-09-05 10:57:34 -0500

In the enu package. The initial release had an error related to headers, which I'm hoping I've resolved, but in the process of getting there, I moved a submodule within the package, which seems to triggered an issue with a git rebase operation:

$ bloom-release --track hydro --ros-distro hydro enu
==> Fetching 'enu' repository from ''
Cloning into '/tmp/tmpHts1LF'...
remote: Counting objects: 125, done.
remote: Compressing objects: 100% (82/82), done.
remote: Total 125 (delta 28), reused 122 (delta 27)
Receiving objects: 100% (125/125), 22.07 KiB, done.
Resolving deltas: 100% (28/28), done.
==> Setting release repository remote url to ''
==> git remote set-url origin <a href=""></a>
==> Testing for push permission on release repository
==> git remote -v
origin  <a href=""></a> (fetch)
origin  <a href=""></a> (push)
==> git push --dry-run
Everything up-to-date
==> Releasing 'enu' using release track 'hydro'
==> git-bloom-release hydro
Processing release track settings for 'hydro'
Checking upstream devel branch for package.xml(s)
Cloning into '/tmp/tmpWfQzCL/upstream'...
remote: Counting objects: 183, done.
remote: Compressing objects: 100% (83/83), done.
remote: Total 183 (delta 86), reused 177 (delta 82)
Receiving objects: 100% (183/183), 30.35 KiB, done.
Resolving deltas: 100% (86/86), done.
Submodule 'libswiftnav' (<a href=""></a>) registered for path 'libswiftnav'

Cloning into 'libswiftnav'...

Submodule path 'libswiftnav': checked out '8ab443d2c801480958b434d9f179e57c916f9f4f'

Looking for packages in 'hydro' branch... found 'enu'.
Detected version '1.0.2' from package(s): ['enu']

Executing release track 'hydro'
==> bloom-export-upstream /tmp/tmpWfQzCL/upstream git --tag 1.0.2 --display-uri <a href=""></a> --name enu --output-dir /tmp/tmpIG1vfW
Checking out repository at '' to reference '1.0.2'.
Exporting to archive: '/tmp/tmpIG1vfW/enu-1.0.2.tar.gz'
md5: 134e1a7b9d8b4533fc6d94188541a6bf

==> git-bloom-import-upstream /tmp/tmpIG1vfW/enu-1.0.2.tar.gz  --release-version 1.0.2 --replace
The latest upstream tag in the release repository is 'upstream/1.0.1'.
Importing archive into upstream branch...
Creating tag: 'upstream/1.0.2'
Im happy.  You should be too.

==> git-bloom-generate -y rosrelease hydro --source upstream -i 0
Releasing package: ['enu']
Releasing package 'enu' for 'hydro' to: 'release/hydro/enu'
 [git-bloom-patch rebase]: 'execute_command' failed to call 'git rm -rf *' which had a return code (128):
 [git-bloom-patch rebase]: ```
fatal: pathspec 'libswiftnav' did not match any files

 [git-bloom-patch rebase]: ```
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/bloom/commands/git/", line 101, in try_execute
    retcode = func(*args, **kwargs)
  File "/usr/lib/pymodules/python2.7/bloom/", line 210, in decorated
    return f(*args, **kwds)
  File "/usr/lib/pymodules/python2.7/bloom/commands/git/patch/", line 146, in rebase_patches
    non_git_rebase ...
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2013-09-05 12:41:17 -0500

William gravatar image

It looks like the archive which was created contains a submodule reference. Which is annoying because the archive is supposed to be free of any vcs related files.

I don't think bloom can support this unless git archive ... also exports and flattens any submodule contents...

Currently I use vcstools to do an vcs agnostic "archive", which calls the correct vcs command based on the vcs being used. So bloom doesn't interact with the upstream directly ever. But since the .gitmodules file persists with the archive it is breaking things...

Can you open a ticket against bloom?

For now I would say submodules are not supported, at least until I figure out what needs to be done to support them correctly.

edit flag offensive delete link more


Ack, bummer. The package in a question is a pretty thin wrapper over the library which I'm submodule-ing in. Is there some other mechanism which would work better? Forking the library would be a big pain—another way would be to just copy it in, or have it cloned in in the build. Preference?

mikepurvis gravatar image mikepurvis  ( 2013-09-05 13:02:59 -0500 )edit

If the project doesn't provide debians, then I would release it as a third party package and then have the `enu` package depend on it. Otherwise you have some options: fix bloom to support submodules :), manually create a tarball of you upstream repository with the submodule folder populated but without the .gitmodules file and give that to bloom (vcs type tar), or you can copy the data directly into your repository, side stepping the submodule completely.

William gravatar image William  ( 2013-09-05 13:31:35 -0500 )edit

Hmm, third party release sounds like the most "correct" way to go. I'll maybe proceed down that road and ping you when I get stuck.

mikepurvis gravatar image mikepurvis  ( 2013-09-05 16:41:26 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2013-09-05 10:57:00 -0500

Seen: 942 times

Last updated: Sep 05 '13