Create our own Debian package archive #54
Comments
jack-oquin
changed the title
|
After reading the links above, my initial approach is to experiment with checkinstall, which looks like the minimal path to creating Debian packages from catkin or CMake source packages. At some point, running our own custom ROS buildfarm instance may make sense, but that seems like overkill for our current needs. Similarly, bloom is a wonderful tool, but it's mainly focused on creating Debian (and other) packages for the ROS buildfarm. |
|
Just as a sidenote, I've been using CPack (https://cmake.org/Wiki/CMake:Packaging_With_CPack) with a regular CMake project quite successfully. If properly set up, you can use a launchpad PPA as a build farm. I haven't given it a try with ROS packages though. I can give it a try on some packages I have to see how well it works. |
|
@rdelfin: that sounds like a good idea. If you want a CMake package to start with, try our fork of libsegwayrmp. If that works, we can do segway_rmp next, a catkin package that depends on that library. |
|
I'll give it a try and let you know how it goes |
|
packpack looks like an interesting option, too. It users docker and is optimized for use with github, Travis CI, and PackageCloud. |
|
A sketch of a way to build a package that will run in That creates an install image in |
|
I currently have a sample of what to do to get cpack working on utexas-bwi/libsegwayrmp#1. I'll be trying packpack and then move onto segway_rmp |
|
That looks great, Ricardo. I'm going to merge it into a separate cpack branch for now. |
|
Checkinstall and packpack are not looking that good to me, so far. Please take a look and form your own opinion. |
|
The current Travis configuration is failing: https://travis-ci.org/utexas-bwi/libsegwayrmp/builds/337782989 |
|
I can't seem to replicate the build issue on my local machine. Looking into it |
|
Regarding checkinstall I agree. Checkinstall seems like it requires more setup than necessary. |
|
You're right, the packpack approach does look good. Maybe there's a way to symlink the CHANGELOG.rst and LICENSE files, instead of copying them. There are bloom modules that automate creating the debian directory. Once we get this working, we can look into making it easier to convert a package. |
|
I think the license is doable, since the format is practically identical, however the Changelog looks like it's a very different format (from what I understand it only contains the current version's Changelog as well as the target distro). Maybe a script that generates one from the other? |
|
Yes, bloom has tools to build the Debian-format change log from the ROS one. But, let's not worry about that for now. |
|
The original Travis test no longer works on Kinetic. |
|
The root cause of the Travis failure for libsegwayrmp seems to be due to copying a header file to a different location in the src tree. I suspect those directories may be read-only in the industrial_ci setup. Unfortunately, the old libsegwayrmp Travis CI config does not work for Kinetic. |
|
My first attempt to build a libsegwayrmp Debian package on my development system failed. Docker errors: Docker problems are hard to debug. 😄 |
|
Right now, the highest priority for packaging is agile_grasp. It takes a long time to build, and seems to be causing Travis failures due to timeout. See: utexas-bwi/bwi_common#106. |
|
Another advantage to using bloom is that it knows how to use rosdep to convert system dependencies into Debian packages for the desired target platform. |
|
This looks promising: https://gist.github.com/awesomebytes/196eab972a94dd8fcdd69adfe3bd1152 |
|
Since agile_grasp is causing problems with build time and probably with Travis CI, it has the highest packaging priority.
There are several ways to generate the Debian source and binary packages from the release repo. I am looking at these: |
|
With git-pbuilder: |
|
Apparently, cowdancer is not in the main Ubuntu Xenial repository. A suggested work-around is adding other Ubuntu components to your |
|
I tried to build, but pbuilder does not resolve the ROS package dependencies: Presumably, I need to login to the chroot and configure the ROS repositories. |
|
I added the ROS repositories like this: |
|
After that, the build runs for a long time, but eventually fails with a compile error: @nickswalker: this looks vaguely familiar. Do you remember what the problem was? Some kind of opencv2 vs. opencv3 difference, maybe? |
|
I suspect the code has been migrated to OpenCV3, but the package dependency still refers to It compiles cleanly on my development system, but that may be because it already has opencv3 installed. Since we can't run Travis on this package, the problem would not have been caught, I guess. Assuming I am right about this, we need to change the dependency to either |
|
I hand-patched the release repository to use That looks like a completely different problem, so the previous fix looks good. I'll commit that update to our agile_grasp fork. |
|
I patched that, and the build completed with lots of warnings, but no errors. |
|
The generated files go in the parent of the build directory. |
|
If I run I can install that .deb in my devel system: After that, I can create a That's a significant step forward. |
|
Of course, that does not prove that the package can be built in a clean environment, so the |
|
It turns out that the |
|
The next step is creating a Personal Package Archive. To start with, I'm trying to use LaunchPad. |
This has become more useful with the
kineticbranch, because it has several significant dependencies that we can't release to the general ROS package repository.The build time has gotten high for the segbot_v2 laptops, and there are problems running Travis CI (#53, utexas-bwi/segbot#98) that might be load-related. Some of that can be addressed by using catkin tools to whitelist or blacklist certain packages for specific purposes. But a custom binary package repository still looks like a good idea.
The text was updated successfully, but these errors were encountered: