New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ros-lunar/mavros package missing (required by ros-lunar/mavros_extras) #229
Comments
@gemarcano this is likely due to a missing dependency. Ebuilds for this overlay are generated using the python package Currently, I'm adding a You would run as follows:
|
Yeah, seems to be missing dependencies, specifically |
Ugh, this is annoying. EDIT: It also has automagic dependencies :( . At least it's documentation related and not actual code, but still... can't say I'm impressed. |
That's never fun. I have definitely been there. I'll take a look at this once I have a few, but please feel free to file a PR (even in a broken state) so I can get a feel as to what you're trying/how you're doing this.
Those are also pretty great. @Alessandro-Barbieri do you have any advice for us here? |
@gemarcano Any progress here? |
|
Sorry, I haven't had time to work on the ebuild. I may have some Friday. I could take a look at the ebuild in the |
Looking at the ebuild from the |
Great! I look forward to your PR! |
I'm attaching my ebuild for geographiclib. I'm relatively new at making ebuilds, so it's likely I've missed some things or screwed up elsewhere (like with the Python deps). The dependencies are versioned to the version I have on my computer, since the actual build system for geographiclib doesn't seem to have much versioning information (in other words, it's possible the minimum version required for the dependencies is likely lower than what the ebuild currently has). |
After a quick once-over, this seems to be alright to me (with a few minor things). PR this and I'll comment on the small changes I'd like to see. |
Sure. Although, reviewing some of the other ebuilds in the repository, they all come from bloom-generated repositories, correct? I'd have to edit/make the ebuild to point to/use a bloom-generated repository for geographiclib, which I'm not seeing exist currently in ros-gbp. On that point, I tried emerging dev-python/bloom-0.6.1 from ros-overlay, and I got a pretty nasty error message from portage:
Thoughts? |
Yes, bloom is currently broken. :( No idea how to fix it. |
Found the reason why it's broken:
as found in bloom's setup.py isn't enough to prevent setuptools from finding all the test packages being used/made by bloom. I'm looking into how to properly block those directories/packages. I can always hard-code them away, but it would be great if I could do something like |
That does it! I applied a test user-patch using that approach and it worked. Here's the patch: diff --git a/setup.py b/setup.py
index 6e53df1..c7a6a2a 100755
--- a/setup.py
+++ b/setup.py
@@ -23,7 +23,7 @@ if sys.version_info[0] == 2 and sys.version_info[1] <= 6:
setup(
name='bloom',
version='0.6.1',
- packages=find_packages(exclude=['test']),
+ packages=find_packages(exclude=['test', 'test.*']),
package_data={
'bloom.generators.debian': [
'bloom/generators/debian/templates/*', EDIT: This should probably make it upstream, since technically they're polluting site-packages with a bunch of test.* packages. EDIT2: ros-infrastructure/bloom#444 |
@gemarcano Thank you for the patch! It's sitting in the patch folder and working on my machine. |
While working on this a bit more, Specific to this issue, what do you actually need? A large part of the problem is that ROS doesn't have a geographiclib-release package or anything like that, which superflore can use/leverage. If we want to be able to re-generate ebuilds, we need a release repository for this package. If we don't care about rebuilding, I may be able to hack together an ebuild that simply adds the package.xml describing geographiclib and updating the ebuild to use the ros-cmake eclass. |
Hm... Well, I suppose we should force it back into version 2, or help the upstream patch for 3.
I need to have the key resolve within rosdep (this would be a pr into ros/rosdistro that would add in a Gentoo definition for the rosdep key that is missing). At that point, an ebuild can be generated by superflore. Finally, an ebuild for the missing dependency would make this resolved.
We probably shouldn't be regenerating geographiclib, as it's not ROS-specific (at least to my knowledge). So if you can just get a simple ebuild going for it, we'll stick it in the appropriate category folder and we should be good to go. |
@gemarcano Can you give a look at this? |
@Alessandro-Barbieri, I'm not sure that reporting this upstream would accomplish much, since the ros-*/ packages really don't mesh well with the upstream tree. At least not until the ros-*/ packages make it to upstream (if they ever do). I've submitted a patch for bloom-release upstream that should fix the bytes vs. string issue. So, looks that before we can do anything else, we need to PR to ros/rosdistro to add the gentoo definition for geographiclib and geographiclib-tools (yes, there's that other packages I haven't even begun to look at) before we can begin to work on the mavros package. I suppose I'll get the ball rolling on ros/rosdistro. I'll also PR the lunar tree in the overlay with the ebuild for geographiclib (I think I've configured properly for inclusion in the tree, although I may be abusing epatch slightly). |
For ros/rosdistro, is it the rosdep/base.yaml that I should add geographiclib to? EDIT: after reading a bit more, looks like it'll have to be the lunar/distribution.yaml, which looks complicated and wants a repository of some kind. Is there any documentation on the format for this file? I'm guessing there's a PEP for it... |
On the matter of geographiclib-tools, they are included in the building of geographiclib itself, so just compiling and installing geographiclib deals with both of those dependencies. |
ros-lunar/mavros is not in the overlay. There is one for indigo, but not for lunar. Is this an oversight? I'll try to modify the indigo ebuild to install it for lunar.
The text was updated successfully, but these errors were encountered: