rosinstall_generator time machine workflow #2
Comments
|
@ChrisTimperley: literally 5 mins after we discussed my failure I got it to work. I'll probably automate this a bit further (probably an extension to This should already work though. Could I bother you to see whether the above instructions also work for you? |
|
It makes sense to re-use the cache as much as possible when going back even further. Suffixing cache files with the commit they were created for would make this manageable. The fewer cache misses, the fewer times I feel that would be beneficial. |
|
I still have to address the issue of Deep down, |
|
@gavanderhoorn, perhaps you could use GitPython? The documentation isn't great but it's a fairly capable tool. To deal with renaming, I was thinking of having the user supply a mapping between old and new repository URLs -- there's a bit of manual work involved but it shouldn't be too much. |
|
Here's the contents of the |
|
@ChrisTimperley wrote:
yeah, I looked at that already, but some googling suggests it doesn't actually support something like
It would need some more work on the Right now I just ignore them, but if the repositories that vanished are actually needed, a remap might allow us to continue. |
|
re: Nice. Thanks for testing. |
|
This kind of makes sense, to the extent I understand what is going on (as really not a ROS dev). I tried to repeat the same steps for ros/geometry2@1957a44 (switched the date, instead of HEAD~5000, I selected the commit by date) and switched fanuc_driver to geometry2 in the last command. At that point I failed with the following problem:
The rosinstall file created is empty. I gather that tf2 was not released yet at that point (April 2, 2016). should I just clone geometry2 to the working dir, aside rosdistro/, and try to build/test it as if it was a catking workspace? |
|
Perhaps something else is not working as it should? If |
|
While checking distribution.yaml, let me share that I used this line
But is indigo the right distro? |
|
rosdistro/indigo/distribution.yaml has this geometry2:
doc:
type: git
url: https://github.com/ros/geometry2.git
version: indigo-devel
release:
packages:
- geometry_experimental
- tf2
- tf2_bullet
- tf2_eigen
- tf2_geometry_msgs
- tf2_kdl
- tf2_msgs
- tf2_py
- tf2_ros
- tf2_sensor_msgs
- tf2_tools
tags:
release: release/indigo/{package}/{version}
url: https://github.com/ros-gbp/geometry2-release.git
version: 0.5.13-0
source:
test_pull_requests: true
type: git
url: https://github.com/ros/geometry2.git
version: indigo-devel
status: maintained |
|
Ah.
|
|
ok. it appears that my bug is in tf2_ros. Giving it a shot. It worked: so should I just run |
|
Ok, let me know. Btw: you don't need to redo all the steps every time: you should be able to just You'll probably have to reset some changes to your |
|
A possible optimisation could be to reuse the cache that you've created if it's "closer" to your new target commit than the current That should speed up cache generation, as there are less changes between the cache that you already have and the one that would be built for the new But only if you need to regenerate the cache, obviously. If you just want to use |
|
I would do: at this point you have a system (or Docker container, which I would recommend, don't clobber your own system with this) that has all system dependencies (ie: libs, headers) installed for the packages that have been downloaded by
the |
|
Note that the But let's worry about that when we run into it. |
|
I only start to understand now. So the rosinstall file is the only important outcome of the procedure in the original post? This means that I should also install indigo on my machine (if the bug is in indigo?) Otherwise the first source command in #2 (comment) would fail, wouldn't it? |
yes, exactly. After you have the
Well .. not really. The Having ROS installed will make things go faster though, but it's not needed. Technically you shouldn't even need an Ubuntu platform to build the workspace, as long as |
|
For reference: you can compare the workflow documented in #2 (comment) with a regular ROS from-source installation. That also uses See wiki/kinetic/Installation/Source. Edit: you can also take a look at build.sh in this repository. It does about the same thing, but uses a bare But it's not what we'd want I believe: the Docker images are continuously rebuilt, so they're a moving target, and they will contain the newest versions of everything. |
|
Still confused why do I need the indigo distro (source /opt/ros/indigo/setup.bash). Isn't the rosinstall file complete for the package? (BTW. having trouble installing indigo on ubuntu 16.04 - perhaps unrelated; but we would also like to eliminate this trouble for the users). |
|
I've edited my responses to your questions a few times. Have you read those?
The
Indigo is not supported on 16.04, only on Ubuntu 14.04 (and 13.10, but that is EOL). See REP-3.
I don't believe users will have to do any of what we're doing here, right? As @ChrisTimperley suggested: we should provide them with Docker images, completely avoiding any exposure to ROS setup or related tasks. |
|
Yes, I have re-read them several times now, but the source to /opt installation of indigo is still there :) which confuses me. |
The comment does now say optional :) |
|
Hmmm ... I must have messed something up. So I did create the workspace, did NOT source the indigo setup, but did set ROS_DISTRO to be indigo (by default in my environment this is set to kinetic), then catkin_init_workspace and catkin_make. Only made 4% of the build :( This looks like a dependency build, so it seems I do have some problems with the procedure: EDIT: it still seems to pick up some of my kinetic stuff. This is bound to go wrong... |
|
I see You can try and do this in a clean terminal (no |
|
I eventually wanna do this in a docker container. Perhaps I should start there right away. |
|
Did you also remove the To get a clean terminal, just comment the |
|
I think the docker way will need to be. When I remove the kinetic setup, then I no longer have a working catkin that I need to build :(. Is there a standard docker image that we should be starting from? |
there should be one in the source space of your workspace. Check the wiki/kinetic/Installation/Source, section Building the catkin Workspace.
If we don't want to start from a ROS image, we could use the appropriate build.sh shows how you can build an image using a |
|
One thing to consider: we should probably generate As we're looking to build containers with and without the bug present (I assume), having the PUT in the main |
|
@wasowski: I've worked a bit on a It should probably work with any Note: this |
|
Have you had any success in using the |
|
I have use this to go back in time: The time in |
yes, it would.
of course. I never suggested we would do that. |
|
I meant: can you add it? (I don't think I can) |
|
Done. |
|
Another problem so now trying: for a bug 5 years old. When I did this commit fails. Ideas? EDIT: the index.yaml seems to contain references to the distribution yaml files. Can I just list them all explicitly on the command line. Something like: (unfortunately, this crashes) |
|
Ouch. I had not considered going back this far. At that point the ros buildfarm and tools like Theoretically we could use that info -- with either a custom script or an old version of rosdep -- to do what we are now doing with I would have to look into this. I wasn't so into ROS at that point that I have in-depth knowledge of how things work(ed). |
|
OK. I think for the time being, I am just flagging this. Should I create a separate issue track these cases? I will not do L3 for this particular bug then. |
|
Yes. Let's track these cases with issues. Probably want to do that on the bitbucket repo? |
|
Note that this workflow is currently a bit broken as If you already have a |
|
With the publication of rosinstall_generator_time_machine I think we can close this one. That tool essentially automates the steps in the OP. |
The text was updated successfully, but these errors were encountered: