Ask Your Question
0

bloom fails for git rm -rf "src" [closed]

asked 2015-05-17 12:17:44 -0500

Hi I want to use bloom-release for my package, After entering everything I am getting the error:

'execute_command' failed to call 'git rm -rf "src"' which had a return code (128):

Now I wonder what I did wrong, or might there be a bug?

Well, I attached whats happening for it in the console below, hope somebody could tell me what exactly I am doing wrong. Maybe the repositories? Why do I need two repositories for the same package for example....

Thanks for your help...

Regards,

Christian

bloom-release --rosdistro indigo --track indigo h4r_thermapp_camera --edit
ROS Distro index file associate with commit '52b0f96c0d985defec2f5439ebd20271c4f179b7'
New ROS Distro index url: 'https://raw.githubusercontent.com/ros/rosdistro/52b0f96c0d985defec2f5439ebd20271c4f179b7/index.yaml'
Specified repository 'h4r_thermapp_camera' is not in the distribution file located at 'https://raw.githubusercontent.com/ros/rosdistro/52b0f96c0d985defec2f5439ebd20271c4f179b7/indigo/distribution.yaml'
Could not determine release repository url for repository 'h4r_thermapp_camera' of distro 'indigo'
You can continue the release process by manually specifying the location of the RELEASE repository.
To be clear this is the url of the RELEASE repository not the upstream repository.
For release repositories on GitHub, you should provide the `https://` url which should end in `.git`.
Here is the url for a typical release repository on GitHub: https://github.com/ros-gbp/rviz-release.git
==> Looking for a release of this repository in a different distribution...
No reasonable default release repository url could be determined from previous releases.
Release repository url [press enter to abort]: https://github.com/Hacks4ROS-releases/h4r_thermapp_camera.git
==> Fetching 'h4r_thermapp_camera' repository from 'https://github.com/Hacks4ROS-releases/h4r_thermapp_camera.git'
Cloning into '/tmp/tmpRxWX9Y'...
remote: Counting objects: 190, done.
remote: Compressing objects: 100% (95/95), done.
remote: Total 190 (delta 82), reused 190 (delta 82), pack-reused 0
Receiving objects: 100% (190/190), 43.28 KiB | 0 bytes/s, done.
Resolving deltas: 100% (82/82), done.
Checking connectivity... done.
Submodule 'src/ThermAppCam' (git@github.com:Hacks4ROS-forks/ThermAppCam.git) registered for path 'src/ThermAppCam'

Submodule path 'src/ThermAppCam': checked out 'dc8bd0642f0dd3451af536c89bde03ef188d9dd1'

Creating track 'indigo'...
Repository Name:
  upstream
    Default value, leave this as upstream if you are unsure
  <name>
    Name of the repository (used in the archive name)
  ['upstream']: 
Upstream Repository URI:
  <uri>
    Any valid URI. This variable can be templated, for example an svn url
    can be templated as such: "https://svn.foo.com/foo/tags/foo-:{version}"
    where the :{version} token will be replaced with the version for this release.
  [None]: https://github.com/Hacks4ROS/h4r_thermapp_camera.git
Upstream VCS Type:
  svn
    Upstream URI is a svn repository
  git
    Upstream URI is a git repository
  hg
    Upstream URI is a hg repository
  tar
    Upstream URI is a tarball
  ['git']: 
Version:
  :{ask}
    This means that the user will be prompted for the version each release.
    This also means that the upstream devel will be ignored.
  :{auto}
    This means the version will be guessed from the devel branch.
    This means that the devel branch must be set, the devel branch must exist,
    and there must be a valid package.xml in the upstream devel branch.
  <version ...
(more)
edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by cyborg-x1
close date 2015-06-26 04:07:58.873857

1 Answer

Sort by ยป oldest newest most voted
0

answered 2015-05-17 19:54:10 -0500

William gravatar image

You need a second repository, the release repository, because we use the Debian style of releasing, you can read more about it here:

https://wiki.debian.org/PackagingWithGit

The main advantage to this style is that you can release a package of which you do not have control over the upstream.

As for your error, it looks like you are using a submodule in your upstream, which is known not to work properly with bloom:

http://answers.ros.org/question/16799... https://github.com/ros-infrastructure...

However, I'm not 100% sure that's the issue. It also appears that release repository you provided is a fork of your upstream:

https://github.com/Hacks4ROS-releases...

I would recommend deleting that repository and starting over, following the tutorial for releasing the first time closely:

http://wiki.ros.org/bloom/Tutorials/F...

edit flag offensive delete link more

Comments

yes, you were right it was a fork, the issue with the submodule should be already solved as far as I could see.

cyborg-x1 gravatar imagecyborg-x1 ( 2015-05-27 03:32:00 -0500 )edit

actually I have to correct myself, I also had to remove the submodule, the feature is not yet merged into bloom.

cyborg-x1 gravatar imagecyborg-x1 ( 2015-06-26 04:06:20 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2015-05-17 12:17:44 -0500

Seen: 62 times

Last updated: May 17 '15