ros-infrastructure / bloom Goto Github PK
View Code? Open in Web Editor NEWA release automation tool which makes releasing catkin (http://ros.org/wiki/catkin) packages easier.
License: Other
A release automation tool which makes releasing catkin (http://ros.org/wiki/catkin) packages easier.
License: Other
Bloom should strip out any .gitignore like files which are meta data about the repository from upstream because:
Bullet 2 example: I put "src" in .gitignore, but 'git add -f src/main.cc' in upstream. When branching in bloom the 'git add' is called on the source tree during branching so the src folder would get dropped.
There seems to be an error in printing the names of missing deps:
{{{
Fetched 6369B in 0s (106kB/s)
package ros-groovy-robot-model does not have dependency [ros-groovy-urdf]
package ros-groovy-robot-model does not have dependency [ros-groovy-srdf]
package ros-groovy-robot-model does not have dependency [ros-groovy-collada-urdf]
package ros-groovy-robot-model does not have dependency [ros-groovy-kdl-parser]
package ros-groovy-robot-model does not have dependency [ros-groovy-rosconsole-bridge]
Dependencies not satisfied for packages: ['ros-groovy-robot-model', 'ros-groovy-robot-model', 'ros-groovy-robot-model', 'ros-groovy-robot-model', 'ros-groovy-robot-model']
}}}
The name of the build package is shown repeatedly instead of the actual missing deps
I'm releasing octomap as 3rd party package, but mostly follow the "native" instructions since I have stack.xml already in upstream and want to use "bloom-import-upstream", instead of manually doing this e.g. from a tarball.
However, running bloom-import-upstream without artificially increasing the upstream version in stack.xml will fail. It should be possible to re-import upstream (the same version) for a re-release. Bloom is later asking for a proper version number again anyways, and one can increase the debian-revision number in bloom-generate-debian, but that's all not possible when bloom-import-upstream blocks before that.
After doing git bloom-generate-debian groovy, the "git push --all && git push --tag" trigger the builds on the farm (somehow) but for all distros (at least fuerte and groovy).
When running git-bloom-import-upstream you can get into a dead lock if svn prompts for svn credentials.
bloom should error out when there is a circular dependency
git push --all
requires always/most of the time to force the push.
This should not be necessary or the documentation what command the user should invoke after git bloom-release
should be updated.
I'm seeing the following error when trying to run bloom-import-upstream. I've installed bloom from apt. Any ideas on what might be going on?
$ git bloom-import-upstream --upstream-devel=groovy_devel
Traceback (most recent call last):
File "/usr/bin/git-bloom-import-upstream", line 5, in
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2711, in
parse_requirements(requires), Environment()
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: distribute>=0.6.24
eitan@grizzly:~/hidof/willow/rosdoc_lite-release$ vim /usr/bin/git-bloom-import-upstream
The url on http://www.ros.org/wiki/bloom points to https://github.com/ros/bloom/blob/master/doc/index.rst which does not render hyperlinks.
Of course, docs should also be udpated to not mention stsack.xml and to mention git-bloom-release :)
Moved from comment in #34
Manually running that command passes, but the next tag fails.
Reading control template from resources/em/control.em
Reading changelog template from resources/em/changelog.em
Reading rules template from resources/em/rules.cmake.em
Reading gbp.conf template from resources/em/gbp.conf.em
There is a nice error if you call it manually:
tfoote@btn:/tmp/gbp/robot_model-release$ git-bloom-generate-debian -t debian/groovy/robot_model groovy --debian-revision 0 --do-not-update-rosdep
Metapackage detected: robot_model
BuildDepends is set(['ivcon', 'orocos_kdl', 'catkin', 'urdfdom', 'assimp', 'rosconsole_bridge', 'ros_comm', 'urdfdom_headers', 'graphviz', 'geometry', 'angles', 'collada-dev', 'convex_decomposition', 'curl', 'ros', 'common_msgs']) for robot_model, from ./package.xml
BuildDepends in is ivcon out is ['ros-groovy-ivcon']
BuildDepends in is orocos_kdl out is ['ros-groovy-orocos-kdl']
BuildDepends in is catkin out is ['ros-groovy-catkin']
BuildDepends in is urdfdom out is ['ros-groovy-urdfdom']
BuildDepends in is assimp out is ['assimp-dev']
BuildDepends in is rosconsole_bridge out is ['ros-groovy-rosconsole-bridge']
BuildDepends in is ros_comm out is ['ros-groovy-ros-comm']
BuildDepends in is urdfdom_headers out is ['ros-groovy-urdfdom-headers']
BuildDepends in is graphviz out is ['graphviz']
BuildDepends in is geometry out is ['ros-groovy-geometry']
BuildDepends in is angles out is ['ros-groovy-angles']
Cannot resolve dependency ['collada-dev'].
If ['collada-dev'] is catkin project, make sure it has been added to the gbpdistro file.
If ['collada-dev'] is a system dependency, make sure there is a rosdep.yaml entry for it in your sources.
Because non-catkin projects do not have a package.xml in the upstream branch the release generator cannot create the release tag properly. The work around is for end users to use manually create the release tag after running the release generate which now only warns about this as of 86ddda5.
In the future the release generator should take a --package-version along side the already existing --package-name argument.
Here's a transcript of what happened:
itrotts@lsd:$ mkdir filters-release$ cd filters-release/
itrotts@lsd:
itrotts@lsd:/filters-release$ git init ./filters-release$ git bloom-config https://github.com/ijt/filters.git git master
Initialized empty Git repository in /wg/stor5/itrotts/filters-release/.git/
itrotts@lsd:
Upstream https://github.com/ijt/filters.git type: git
Freshly initialized git repository detected.
An initial empty commit is going to be made.
Continue [Y/n]? y
Upstream successively set.
itrotts@lsd:~/filters-release$ git-bloom-config
Current bloom configuration:
[bloom]
upstream = https://github.com/ijt/filters.git
upstreamtype = git
upstreambranch = master
See: 'git-bloom-config -h' on how to change the configs
itrotts@lsd:~/filters-release$ git-bloom-import-upstream
[git-bloom-import-upstream]: Searching in upstream development branch for the name and version
[git-bloom-import-upstream]: Upstream url: https://github.com/ijt/filters.git
[git-bloom-import-upstream]: Upstream type: git
[git-bloom-import-upstream]: Upstream branch: master
[git-bloom-import-upstream]: Checking for package.xml(s)
[git-bloom-import-upstream]: package.xml(s) found
[git-bloom-import-upstream]: Found upstream with version: 1.6.0
[git-bloom-import-upstream]: Upstream contains package: filters
[git-bloom-import-upstream]: Exporting version 1.6.0
Traceback (most recent call last):
File "/usr/bin/git-bloom-import-upstream", line 39, in
sys.exit(main())
File "/usr/lib/pymodules/python2.7/bloom/import_upstream.py", line 512, in main
retcode = import_upstream(cwd, tmp_dir, args)
File "/usr/lib/pymodules/python2.7/bloom/logging.py", line 109, in wrapper
result = fn(_args, *_kwargs)
File "/usr/lib/pymodules/python2.7/bloom/import_upstream.py", line 359, in import_upstream
upstream_repo.export_repository(version, tarball_path)
AttributeError: 'VcsClient' object has no attribute 'export_repository'
[git-bloom-import-upstream]: Exporting version 1.9.16
[git-bloom-import-upstream]: The latest upstream tag in the release repository is upstream/1.9.15
Usage: git-import-orig [-u version] /path/to/upstream-version.tar.gz
git-import-orig: error: no such option: --no-interactive
[git-bloom-import-upstream]: git-import-orig failed 'git import-orig /tmp/bloom_oVi270/upstream-1.9.16.tar.gz --no-interactive --no-merge'
At least, it seems so. It would be nice if it only checked out the tag it needs to release (--depth clone option for git repos).
Enable the use case to have an upstream without package.xml and provide the package.xml using a patch in the GBP.
I tried to release rosconsole_bridge using the bloom debs (0.1.8-1)and the sourcedeb failed here:
ros-groovy-rosconsole-bridge_0.2.1.orig.tar.gz does not exist, creating from 'release/rosconsole_bridge/0.2.1'
fatal: Not a valid object name release/rosconsole_bridge/0.2.1
http://jenkins.willowgarage.com:8080/view/Gsrc/job/ros-groovy-rosconsole-bridge_sourcedeb/2/console
It seems that the versioned tag for the release branch is not being created.
Console output below from the release. I manually created the tag and things are building again. : http://jenkins.willowgarage.com:8080/view/Gsrc/job/ros-groovy-rosconsole-bridge_sourcedeb/3/console
tfoote@btn:/tmp/rosconsole_bridge-release$ git bloom-import-upstream
[git-bloom-import-upstream]: upstream repo: https://kforge.ros.org/console_bridge/rosconsole_bridge
[git-bloom-import-upstream]: upstream type: hg
[git-bloom-import-upstream]: upstream branch: (No branch set)
requesting all changes
adding changesets
adding manifests
adding file changes
added 9 changesets with 14 changes to 7 files
updating to branch default
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
[git-bloom-import-upstream]: Checking for package.xml(s)
[git-bloom-import-upstream]: package.xml(s) found
[git-bloom-import-upstream]: Upstream has version 0.2.1
[git-bloom-import-upstream]: Upstream contains package: rosconsole_bridge
[git-bloom-import-upstream]: Exporting version 0.2.1
[git-bloom-import-upstream]: The latest upstream tag in the release repository is upstream/0.2.0
gbp:info: Importing '/tmp/bloom_NOrkYc/upstream-0.2.1.tar.gz' to branch 'upstream'...
gbp:info: Source package is ros-groovy-rosconsole-bridge
gbp:info: Upstream version is 0.2.1
gbp:info: Successfully imported version 0.2.1 of /tmp/bloom_NOrkYc/upstream-0.2.1.tar.gz
I'm happy. You should be too.
tfoote@btn:/tmp/rosconsole_bridge-release$ git bloom-release groovy
[git-bloom-release]: Running git-bloom-branch --src upstream release --interactive
[git-bloom-branch]: Changing to specified source branch upstream
[git-bloom-branch]: Found 1 packages.
[git-bloom-branch]: Branching these packages: ['rosconsole_bridge']
Continue [Y/n]? y
[git-bloom-branch]: Branching rosconsole_bridge_0.2.1 to release/rosconsole_bridge
[git-bloom-branch]: Branching rosconsole_bridge_0.2.1 to release/rosconsole_bridge returned 0
[git-bloom-release]: Running git-bloom-generate-debian-all --debian-revision 0 groovy release
[git-bloom-release]: This will run git-bloom-generate-debian on these pacakges: ['release/rosconsole_bridge']
Continue [Y/n]?
[git-bloom-release]: Branching to debian prefix with: git-bloom-branch --src release/rosconsole_bridge debian/groovy/rosconsole_bridge
[git-bloom-branch]: Changing to specified source branch release/rosconsole_bridge
[git-bloom-branch]: Found 1 packages.
[git-bloom-branch]: Branching these packages: ['rosconsole_bridge']
[git-bloom-branch]: Branching rosconsole_bridge_0.2.1 to debian/groovy/rosconsole_bridge
[git-bloom-branch]: Branching rosconsole_bridge_0.2.1 to debian/groovy/rosconsole_bridge returned 0
[git-bloom-release]: Calling 'git-bloom-generate-debian -t debian/groovy/rosconsole_bridge groovy --debian-revision 0'
[git-bloom-release]: Updating rosdep
BuildDepends is set([]) for rosconsole_bridge, from ./package.xml
rosconsole_bridge has the following dependencies for ubuntu oneiric
Run dependencies:
set()
Build dependencies:
set()
source_dir=.
Reading control template from resources/em/control.em
Reading changelog template from resources/em/changelog.em
Reading rules template from resources/em/rules.cmake.em
Reading gbp.conf template from resources/em/gbp.conf.em
+ cd . && git add debian
+ cd . && git commit -m + Creating debian mods for distro: oneiric, rosdistro: groovy, upstream version: 0.2.1
[debian/groovy/rosconsole_bridge d625048] + Creating debian mods for distro: oneiric, rosdistro: groovy, upstream version: 0.2.1
6 files changed, 78 insertions(+)
create mode 100644 debian/changelog
create mode 100644 debian/compat
create mode 100644 debian/control
create mode 100644 debian/gbp.conf
create mode 100755 debian/rules
create mode 100644 debian/source/format
tag: debian/ros-groovy-rosconsole-bridge_0.2.1-0_oneiric
+ cd . && git tag -f debian/ros-groovy-rosconsole-bridge_0.2.1-0_oneiric -m Debian release 0.2.1
Updated tag 'debian/ros-groovy-rosconsole-bridge_0.2.1-0_oneiric' (was 0000000)
rosconsole_bridge has the following dependencies for ubuntu precise
Run dependencies:
set()
Build dependencies:
set()
source_dir=.
Reading control template from resources/em/control.em
Reading changelog template from resources/em/changelog.em
Reading rules template from resources/em/rules.cmake.em
Reading gbp.conf template from resources/em/gbp.conf.em
+ cd . && git add debian
+ cd . && git commit -m + Creating debian mods for distro: precise, rosdistro: groovy, upstream version: 0.2.1
[debian/groovy/rosconsole_bridge eaba932] + Creating debian mods for distro: precise, rosdistro: groovy, upstream version: 0.2.1
1 file changed, 1 insertion(+), 1 deletion(-)
tag: debian/ros-groovy-rosconsole-bridge_0.2.1-0_precise
+ cd . && git tag -f debian/ros-groovy-rosconsole-bridge_0.2.1-0_precise -m Debian release 0.2.1
Updated tag 'debian/ros-groovy-rosconsole-bridge_0.2.1-0_precise' (was 0000000)
rosconsole_bridge has the following dependencies for ubuntu quantal
Run dependencies:
set()
Build dependencies:
set()
source_dir=.
Reading control template from resources/em/control.em
Reading changelog template from resources/em/changelog.em
Reading rules template from resources/em/rules.cmake.em
Reading gbp.conf template from resources/em/gbp.conf.em
+ cd . && git add debian
+ cd . && git commit -m + Creating debian mods for distro: quantal, rosdistro: groovy, upstream version: 0.2.1
[debian/groovy/rosconsole_bridge 7a5a097] + Creating debian mods for distro: quantal, rosdistro: groovy, upstream version: 0.2.1
1 file changed, 1 insertion(+), 1 deletion(-)
tag: debian/ros-groovy-rosconsole-bridge_0.2.1-0_quantal
+ cd . && git tag -f debian/ros-groovy-rosconsole-bridge_0.2.1-0_quantal -m Debian release 0.2.1
Updated tag 'debian/ros-groovy-rosconsole-bridge_0.2.1-0_quantal' (was 0000000)
[git-bloom-release]: Calling 'git-bloom-generate-debian -t debian/groovy/rosconsole_bridge groovy --debian-revision 0' returned exit code 0
Tip: Check to ensure that the debian tags created have the same version as the upstream version you are releasing.
Everything went as expected, you should check that the new tags match your expectations, and then push to the gbp repo with:
git push --force --all && git push --tags
tfoote@btn:/tmp/rosconsole_bridge-release$ git push --force --all && git push --tags
fatal: remote error:
You can't push to git://github.com/wg-debs/rosconsole_bridge-release.git
Use [email protected]:wg-debs/rosconsole_bridge-release.git
tfoote@btn:/tmp/rosconsole_bridge-release$ git remote set-url origin [email protected]:wg-debs/rosconsole_bridge-release.git
tfoote@btn:/tmp/rosconsole_bridge-release$ git push --force --all && git push --tags
Counting objects: 37, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (27/27), done.
Writing objects: 100% (33/33), 4.30 KiB, done.
Total 33 (delta 10), reused 4 (delta 0)
To [email protected]:wg-debs/rosconsole_bridge-release.git
a902574..d6f654c upstream -> upstream
* [new branch] debian/groovy/rosconsole_bridge -> debian/groovy/rosconsole_bridge
* [new branch] patches/debian/groovy/rosconsole_bridge -> patches/debian/groovy/rosconsole_bridge
* [new branch] patches/release/rosconsole_bridge -> patches/release/rosconsole_bridge
* [new branch] release/rosconsole_bridge -> release/rosconsole_bridge
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 693 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To [email protected]:wg-debs/rosconsole_bridge-release.git
* [new tag] debian/ros-groovy-rosconsole-bridge_0.2.1-0_oneiric -> debian/ros-groovy-rosconsole-bridge_0.2.1-0_oneiric
* [new tag] debian/ros-groovy-rosconsole-bridge_0.2.1-0_precise -> debian/ros-groovy-rosconsole-bridge_0.2.1-0_precise
* [new tag] debian/ros-groovy-rosconsole-bridge_0.2.1-0_quantal -> debian/ros-groovy-rosconsole-bridge_0.2.1-0_quantal
* [new tag] upstream/0.2.1 -> upstream/0.2.1
tfoote@btn:/tmp/rosconsole_bridge-release$ git tag
debian/ros-fuerte-rosconsole-bridge_0.1.0_lucid
debian/ros-fuerte-rosconsole-bridge_0.1.0_oneiric
debian/ros-fuerte-rosconsole-bridge_0.1.0_precise
debian/ros-groovy-rosconsole-bridge_0.1.0_oneiric
debian/ros-groovy-rosconsole-bridge_0.1.0_precise
debian/ros-groovy-rosconsole-bridge_0.1.0_quantal
debian/ros-groovy-rosconsole-bridge_0.2.0_oneiric
debian/ros-groovy-rosconsole-bridge_0.2.0_precise
debian/ros-groovy-rosconsole-bridge_0.2.0_quantal
debian/ros-groovy-rosconsole-bridge_0.2.1-0_oneiric
debian/ros-groovy-rosconsole-bridge_0.2.1-0_precise
debian/ros-groovy-rosconsole-bridge_0.2.1-0_quantal
upstream/0.1.0
upstream/0.2.0
upstream/0.2.1
When the source repository does not have a tag with the version number the message could be better than:
[git-bloom-import-upstream]: Exporting version 1.8.13
WARNING [vcstools] Command failed: 'git archive -o /tmp/bloom_TWfdWB/upstream-1.8.13.tar 1.8.13'
run at: '/tmp/bloom_TWfdWB/upstream'
errcode: 128:
fatal: Not a valid object name
[/vcstools]
[git-bloom-import-upstream]: Failed to export upstream repository.
Also looking for an alternative tag with the name "pkgname-VERSION" would be great.
Since bloom is based on git-buildpackage, it should probably depend on it.
I installed it and it failed due to python-vcstools missing
So that we don't have to use master. And we're cutting Release-Tag support in the stack.xml redesign which enabled this, but from the wrong place.
I'm having trouble releasing a version of rosdoc_lite into fuerte that has a version number smaller than that of the rosdoc_lite instance released into groovy. It seems like a rebase is failing. From a previous ticket, I was under the impression that all I needed to do was change what upstream repo was being pulled from. Am I just missing something here? Do I need to create a separate gbp repo for each distro?
$ git bloom-release rosdebian fuerte
###
### Running 'git bloom-import-upstream --replace'...
###
[git-bloom-import-upstream]: Searching in upstream development branch for the name and version
[git-bloom-import-upstream]: Upstream url: git://github.com/ros-infrastructure/rosdoc_lite.git
[git-bloom-import-upstream]: Upstream type: git
[git-bloom-import-upstream]: Upstream branch: fuerte-devel
[git-bloom-import-upstream]: Checking for package.xml(s)
[git-bloom-import-upstream]: package.xml(s) not found, looking for stack.xml
[git-bloom-import-upstream]: stack.xml found
[git-bloom-import-upstream]: Found upstream with version: 0.1.3
[git-bloom-import-upstream]: Upstream contains a stack called: rosdoc_lite
[git-bloom-import-upstream]: Exporting version 0.1.3
[git-bloom-import-upstream]: The latest upstream tag in the release repository is upstream/0.1.3
[git-bloom-import-upstream]: The upstream version, 0.1.3, is equal to or less than a previous import version.
Removing conflicting tag before continuing because the '--replace' options was specified.
gbp:info: Importing '/tmp/bloom_VMnc8z/upstream-0.1.3.tar.gz' to branch 'upstream'...
gbp:info: Source package is ros-groovy-rosdoc-lite
gbp:info: Upstream version is 0.1.3
gbp:info: Successfully imported version 0.1.3 of /tmp/bloom_VMnc8z/upstream-0.1.3.tar.gz
I'm happy. You should be too.
### Running 'git bloom-import-upstream --replace'... returned (0)
###
### Running 'git bloom-generate -y release --src upstream'...
###
[git-bloom-generate release]: Releasing package: [u'rosdoc_lite']
[git-bloom-generate release]: Releasing package 'rosdoc_lite' to: 'release/rosdoc_lite'
[git-bloom-patch rebase]: 'execute_command' failed to call 'git commit -m "Rebase from 'upstream'" @ version '0.1.3'' which had a return code (1):
[git-bloom-patch rebase]: stderr:
error: pathspec '@' did not match any file(s) known to git.
error: pathspec 'version' did not match any file(s) known to git.
error: pathspec '0.1.3' did not match any file(s) known to git.
[git-bloom-patch rebase]: end stderr
Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/bloom/commands/generate.py", line 98, in try_execute
retcode = func(*args, **kwargs)
File "/usr/lib/pymodules/python2.7/bloom/logging.py", line 122, in decorated
return f(*args, **kwds)
File "/usr/lib/pymodules/python2.7/bloom/commands/patch/rebase_cmd.py", line 167, in rebase_patches
non_git_rebase(config['parent'], directory=directory)
File "/usr/lib/pymodules/python2.7/bloom/commands/patch/rebase_cmd.py", line 87, in non_git_rebase
execute_command(cmd, cwd=directory)
File "/usr/lib/pymodules/python2.7/bloom/util.py", line 302, in execute_command
raise CalledProcessError(cmd=cmd, output=out, returncode=result)
CalledProcessError: Command 'git commit -m "Rebase from 'upstream'" @ version '0.1.3'' returned non-zero exit status 1
[git-bloom-generate release]: Error calling git-bloom-patch rebase: Command 'git commit -m "Rebase from 'upstream'" @ version '0.1.3'' returned non-zero exit status 1
[git-bloom-generate release]: git-bloom-patch rebase returned exit code (1)
### Running 'git bloom-generate -y release --src upstream'... returned (1)
I tried to use bloom on a system which had not had rosdep init called. It failled with this backtrace. This would be good to catch and give an appropriate error.
branch is the upstream branch.
[git-bloom-branch]: Branching eigen_conversions_1.9.15 to debian/groovy/eigen_conversions returned 0
[git-bloom-release]: Calling git-bloom-generate-debian-all -t debian/groovy/eigen_conversions groovy --debian-revision 0
[git-bloom-release]: Updating rosdep
Traceback (most recent call last):
File "/usr/bin/git-bloom-release", line 48, in <module>
sys.exit(release_main())
File "/usr/lib/pymodules/python2.7/bloom/release/main.py", line 98, in release_main
ret = gendeb_all_main(gda_args)
File "/usr/lib/pymodules/python2.7/bloom/generators/debian/main_all.py", line 99, in main
gendeb_main(gen_args)
File "/usr/lib/pymodules/python2.7/bloom/generators/debian/__init__.py", line 579, in main
rosdep2.catkin_support.update_rosdep()
File "/usr/lib/pymodules/python2.7/rosdep2/catkin_support.py", line 90, in update_rosdep
call(('rosdep', 'update'), pipe=PIPE)
File "/usr/lib/pymodules/python2.7/rosdep2/catkin_support.py", line 47, in call
raise CalledProcessError(retcode, command)
CalledProcessError: Command '('rosdep', 'update')' returned non-zero exit status 1
I can't run bloom trunk on my lucid machine now.
Traceback (most recent call last):
File "/home/tfoote/bloom/bin/git-bloom-generate-debian", line 36, in <module>
from bloom.generate_debian import main
File "/home/tfoote/bloom/src/bloom/generate_debian.py", line 49, in <module>
from bloom.util import track_all_git_branches, execute_command, bailout
File "/home/tfoote/bloom/src/bloom/util.py", line 8, in <module>
from subprocess import check_call, check_output, CalledProcessError, PIPE
ImportError: cannot import name check_output
Just like an email for the maintainer is required for the debian changelog, a description is required too ( is now allowed but will have a debian failure later). E.g:
http://jenkins.willowgarage.com:8080/view/GbinP64/job/ros-groovy-image-common_binarydeb_precise_amd64/4/console
No Description field in /var/www/repos/building/tmp/ros-groovy-image-common_1.9.12-0precise-20121005-2130-+0000_amd64.deb's control file!
There have been errors!
Some repos have heavy history and some users have low bandwidth.
use of --depth 1 in git would be nice. Maybe that should be a feature in vcstools ?
I run this command:
'git bloom-import-upstream --explicit-svn-url https://alufr-ros-pkg.googlecode.com/svn/branches/octomap_stacks-groovy-devel/octomap_msgs'
I get this error:
'--explicit-svn-version' must be specified with '--explicit-svn-url'
(I think it is not the case for an error when a package.xml exists at the specified url, which is the case here)
I then specify the suggested argument:
'git bloom-import-upstream --explicit-svn-url https://alufr-ros-pkg.googlecode.com/svn/branches/octomap_stacks-groovy-devel/octomap_msgs --explicit-svn-version 0.2.4'
and I get:
usage: git-bloom-import-upstream [-h] [-i] [-r]
[--upstream-devel UPSTREAM_DEVEL]
[--upstream-tag UPSTREAM_TAG]
[--explicit-svn-url EXPLICIT_SVN_URL]
[--upstream-version UPSTREAM_VERSION] [-d]
[--version]
git-bloom-import-upstream: error: unrecognized arguments: --explicit-svn-version 0.2.4
Using --upstream-version instead of --explicit-svn-version worked, but this is a bit confusing.
This is the error:
.......
[git-bloom-import-upstream]: package.xml(s) found
[git-bloom-import-upstream]: Found upstream with version: 1.5.22
[git-bloom-import-upstream]: Upstream contains package: dynamic_reconfigure
[git-bloom-import-upstream]: Exporting version 1.5.22
[git-bloom-import-upstream]: The latest upstream tag in the release repository is upstream/1.5.21
fatal: ref HEAD is not a symbolic ref
Traceback (most recent call last):
File "/usr/bin/git-import-orig", line 5, in <module>
sys.exit(main(sys.argv))
File "/usr/lib/python2.7/dist-packages/gbp/scripts/import_orig.py", line 254, in main
initial_branch = repo.get_branch()
File "/usr/lib/python2.7/dist-packages/gbp/git/repository.py", line 244, in get_branch
raise GitRepositoryError("Currently not on a branch")
gbp.git.repository.GitRepositoryError: Currently not on a branch
[git-bloom-import-upstream]: 'execute_command' failed to call 'git import-orig /tmp/bloom_q1MtSf/upstream-1.5.22.tar.gz --no-interactive --no-merge' which had a return code (1):
[git-bloom-import-upstream]: git-import-orig failed 'git import-orig /tmp/bloom_q1MtSf/upstream-1.5.22.tar.gz --no-interactive --no-merge'
We've seen a few times spurious failures of packages depending on ros-fuerte-ecto-ros.
I downloaded the debs which were working and the ones which were failing to build downstream packages, and this was the only substantial diff:
--- ecto_ros-config.cmake.bad 2012-07-05 12:01:06.650851796 -0700
+++ ecto_ros-config.cmake.good 2012-07-05 12:01:19.843133063 -0700
@@ -39,34 +39,24 @@
if (ecto_ros_CONFIG_INCLUDED)
- return()
+ return()
endif()
set(ecto_ros_CONFIG_INCLUDED TRUE)
if (NOT "Xinclude" STREQUAL "X")
- set(ecto_ros_INCLUDE_DIRS_ )
- foreach(idir include)
- if(IS_ABSOLUTE ${idir} AND IS_DIRECTORY ${idir})
- set(include ${idir})
- elseif(IS_DIRECTORY /tmp/buildd/ros-fuerte-ecto-ros-0.3.11-0lucid-20120616-0206/${idir})
- set(include /tmp/buildd/ros-fuerte-ecto-ros-0.3.11-0lucid-20120616-0206/${idir})
- else()
- message(FATAL_ERROR "ecto_ros specified ${idir} as an include dir, but I can't find it.
-It does not exist, as an absolute directory or in /tmp/buildd/ros-fuerte-ecto-ros-0.3.11-0lucid-20120616-0206/${idir}
-Tell Vincent Rabaud <[email protected]> to fix it."
- )
- endif()
- list(APPEND ecto_ros_INCLUDE_DIRS_ ${include})
- endforeach()
- set(ecto_ros_INCLUDE_DIRS ${ecto_ros_INCLUDE_DIRS_}
- CACHE FILEPATH "Includes for ecto_ros")
+ set(ecto_ros_INCLUDE_DIRS /opt/ros/fuerte/include) #TODO FIX this.
endif()
foreach(lib )
- if (NOT TARGET ${lib})
- message(FATAL_ERROR "In project ${PROJECT_NAME} I'm looking for ${lib} via find_package. The source for ecto_ros is present in workspace, but ${lib} is not a target. Did you find_package() this thing before the subdirectory containing its code is included?")
+ set(onelib "${lib}-NOTFOUND")
+ find_library(onelib ${lib}
+ PATHS /opt/ros/fuerte/lib
+ NO_DEFAULT_PATH
+ )
+ if(NOT onelib)
+ message(FATAL_ERROR "Library '${lib}' in package ecto_ros is not installed properly")
endif()
- list(APPEND ecto_ros_LIBRARIES ${lib})
+ list(APPEND ecto_ros_LIBRARIES ${onelib})
endforeach()
foreach(dep )
@@ -85,5 +75,5 @@
endif()
foreach(extra ecto_ros-extras.cmake)
- include(/tmp/buildd/ros-fuerte-ecto-ros-0.3.11-0lucid-20120616-0206/obj-x86_64-linux-gnu/cmake/ecto_ros/${extra})
+ include(/opt/ros/fuerte/share/ecto_ros/cmake/${extra})
endforeach()
Though it seems emails are not required for maintainers, they actually are a necessity: git buildpackage needs an email when creating the changelog, otherwise it leads to weird errors on the farm:
http://jenkins.willowgarage.com:8080/view/Gsrc/job/ros-groovy-image-pipeline_sourcedeb/lastFailedBuild/console
(I had typo-ed the email tag for mail)
The last line of the debian/changelog ended up with:
-- Vincent Rabaud Thu, 13 Sep 2012 00:48:42 +0200
which confused debbuild.
Possible solutions:
The first one is obviously the best as people have also been asking for better ways of contacting maintainers. Any thoughts ?
This is not architected to be maintainable, it could leverage rospkg. There's no way to unit test etc
Generate additional "release/VERSION" tag before generating the Debian overlays.
I couldn't find any documentation on the way that you're supposed to use bloom with multiple development branches for a stack.
For example, say I have a stack with branches fuerte-devel and groovy-devel. I'm working on groovy-devel and cherry-pick a change back to fuerte-devel. I want to release a patch release off of fuerte-devel, say 0.1.2, and a minor release off of groovy-devel, say 0.2.0.
Where should I go to find documentation on what to do?
Trying to just change bloom.conf to have a different upstream results in a lot of warnings about version numbers being lower than those that have already been released for me. Led me to be confused as to if that's the right thing to do.
Please add the files in that folder:
./bloom/generators/debian/templates/
Installing bloom fails
Even if you started on the master branch. This is non-intuitive and can lead to improper usage.
@vrabaud reported that when releasing pcl he got:
git bloom-generate rosdebian --prefix release -i8 groovy
No packages found, check your --prefix or --src arguments.
generator handle arguments returned exit code (6)
This seems like there is a problem matching release to the release/pcl branch.
From Christian Dornhege on ros-users
would it be possible to automatically add the list of packages in a
stack that is being released to the .deb description? Just adding a
string like "Contains the following ROS packages: ..." should be enough.
The main reason would be that now it is possible to do:
apt-cache search PACKAGE
and the result should contain the released stacks that contain the
package.
+1 from joq, Felix Endres, Thomas Moulard, and Michael Carroll
When a dependency cannot be resolved, bloom catches the exception and gives an uninformative error. For example, if a dep is not specified for quantal, bloom-generate-debian fails with 'cannot resolve key ....' instead of saying that it did not find the key for quantal (although it did for other distros)
With the new syntax (bloom version 0.1.8-1), I can't seem to import upstream anymore from a SVN repo. It appears to me that bloom-config enforces to import from a URL either ending in "trunk" or "branches/XXX", but not from "tags" or any different repository organization. I see this as a bug, since the tool should not enforce the upstream repository organization by adding parts to the URL.
The upstream URL I need to import is https://octomap.svn.sourceforge.net/svnroot/octomap/tags/v1.4.3/octomap which worked fine with bloom-set-upstram, but not anymore with bloom-config. import-upstream will then try to checkout https://octomap.svn.sourceforge.net/svnroot/octomap/tags/v1.4.3/trunk which does not exists.
Specifics:
This is the output I got:
git bloom-import-upstream --upstream-version 0.2.3 --upstream-tag orocos_kinematics_dynamics-0.2.3
Using specified upstream tag 'orocos_kinematics_dynamics-0.2.3'
Exporting version 0.2.3
WARNING [vcstools] Command failed: 'git archive -o /tmp/bloom_YPeJNh/upstream-0.2.3.tar 0.2.3'
run at: '/tmp/bloom_YPeJNh/upstream_repo'
errcode: 128:
fatal: Not a valid object name
[/vcstools]
tar: /tmp/bloom_YPeJNh/upstream-0.2.3.tar.gz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
gbp:error: tar returned 2
gbp:error: Couldn't unpack "/tmp/bloom_YPeJNh/upstream-0.2.3.tar.gz"
'execute_command' failed to call 'git import-orig /tmp/bloom_YPeJNh/upstream-0.2.3.tar.gz --no-interactive --no-merge' which had a return code (1):
git-import-orig failed 'git import-orig /tmp/bloom_YPeJNh/upstream-0.2.3.tar.gz --no-interactive --no-merge'
Patch will follow
Ruben
FLANN, and g2o are two examples:
https://github.com/mariusmuja/flann
The tag is nice, but specifying the commit hash/SVN rev number instead would help in those cases.
I almost added a meta-package but didn't list it in the gbprepo and it wouldn't have been built into debian packages.
This might be good to display next to the list of packages to be built.
Since the latest master of bloom executing any git-bloom-command results in the following error:
File "/usr/local/lib/python2.7/dist-packages/bloom-0.2.3-py2.7.egg/bloom/util.py", line 178, in handle_global_arguments
if args.version:
AttributeError: 'Namespace' object has no attribute 'version'
Except if you add the --version argument.
Ruben
Right now it only looks in committed source for copyright templates
consider warning/blocking on missing build-time dep to genmsg and langs for packages containing messages
(same tools as for #6)
If there is an upstream tag specified, it is not used everywhere where needed.
Here is a snippet from import_upstream.py (line 356 in 1.1.10):
{{{
if upstream_repo.get_vcs_type_name() == 'svn':
upstream_repo.export_repository('', tarball_path)
else:
upstream_repo.export_repository(version, tarball_path)
}}}
where version is initialized like so:
version = args.upstream_version if args.upstream_version is not None else meta['version']
This makes it such that the upstream version is looked for in the repo tags instead of the specified tag name. To make things work in my local version I added:
tag = args.upstream_tag if args.upstream_tag is not None else version
and pass tag as argument instead of version to:
upstream_repo.export_repository(version, tarball_path)
Summary, @dirk-thomas reported that empty files were not present on the build farm, thinks it might be a bug related to bloom's patching. It is a blocker for @vrabaud.
Transcript from email:
From @dirk-thomas:
Hi William,
it looks like we have a subtle bug in the workflow how bloom currently works.
The get to the result: empty files in multi-package repos disappear.
During the process of moving each packages into the root for its specific branch bloom uses patches.
And patch files do not deal well with empty files (search for "newly created empty file" in http://manpages.ubuntu.com/manpages/maverick/man1/dpkg-source.1.html).
One example is currently in the ros_comm repo.
clients/roscpp/test/msg/TestEmpty.msg is an empty file and exists in ros-groovy-roscpp_1.9.14.orig.tar.gz.
But in ros-groovy-roscpp_1.9.14-0precise.debian.tar.gz under debian/patches/debian-changes-1.9.14-0precise the patch does not contain that file anymore.
So in the end when the buildfarm tries to build it the file is missing (http://jenkins.willowgarage.com:8080/view/GbinP64/job/ros-groovy-roscpp_binarydeb_precise_amd64/3/console).
One temporary workaround is to put a comment or something similar into that specific file.
But I think we need an updated workspace to deal with that cleanly.
- Dirk
From @wjwwood:
> Hi William,
>
> it looks like we have a subtle bug in the workflow how bloom currently works.
> The get to the result: empty files in multi-package repos disappear.
>
> During the process of moving each packages into the root for its specific branch bloom uses patches.
> And patch files do not deal well with empty files (search for "newly created empty file" in http://manpages.ubuntu.com/manpages/maverick/man1/dpkg-source.1.html).
Making a sub dir the root of the repo involves copying the sub dir out
to temp storage, git rm -rf *, copy the sub dir contents back, git add
*, git commit. The patches happen later and do not come into play
unless you actually patch something.
>
> One example is currently in the ros_comm repo.
> clients/roscpp/test/msg/TestEmpty.msg is an empty file and exists in ros-groovy-roscpp_1.9.14.orig.tar.gz.
> But in ros-groovy-roscpp_1.9.14-0precise.debian.tar.gz under debian/patches/debian-changes-1.9.14-0precise the patch does not contain that file anymore.
> So in the end when the buildfarm tries to build it the file is missing (http://jenkins.willowgarage.com:8080/view/GbinP64/job/ros-groovy-roscpp_binarydeb_precise_amd64/3/console).
I'll look into it.
>
> One temporary workaround is to put a comment or something similar into that specific file.
> But I think we need an updated workspace to deal with that cleanly.
I'll also test this work around.
From @dirk-thomas:
I am using that workaround for the two empty message files in rosmaster and roscpp/test.
Both work fine now on the buildfarm.
So no urgency...
From @vrabaud:
May I add that this is actually an extremely urgent issue because a lot of __init__.py are empty and do not get copied ..... (rospy is unusable for example). Thx.
From @wjwwood:
This is my top priority this morning.
Then I will finish testing my workaround for the custom rules file.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.