Skip to content
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

transmission_interface ebuild not there due to license issues #567

Closed
pholthaus opened this issue Apr 17, 2018 · 11 comments
Closed

transmission_interface ebuild not there due to license issues #567

pholthaus opened this issue Apr 17, 2018 · 11 comments

Comments

@pholthaus
Copy link
Contributor

When trying to emerge for eample ros-kinetic/cob_gazebo_ros_control, it complains about missing ros-kinetic/transmission_interface. The folder is there containing metadata.xml but nothing else.

When trying superflore, it complains about a non-matchables license:

superflore-gen-ebuilds --dry-run --ros-distro kinetic --only transmission_interface --output-repository-path Source/ros-overlay/
>>>> Creating new branch gentoo-bot-CoWNzbHZqB...
>>>> 
>>>> Regenerating package 'transmission_interface'...
!!!! Could not match license "Modified BSD".
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.5/superflore-gen-ebuilds", line 11, in <module>
    load_entry_point('superflore==0.2.1', 'console_scripts', 'superflore-gen-ebuilds')()
  File "/usr/lib64/python3.5/site-packages/superflore/generators/ebuild/run.py", line 125, in main
    preserve_existing
  File "/usr/lib64/python3.5/site-packages/superflore/generators/ebuild/gen_packages.py", line 85, in regenerate_pkg
    ebuild_text = current.ebuild_text()
  File "/usr/lib64/python3.5/site-packages/superflore/generators/ebuild/gen_packages.py", line 216, in ebuild_text
    return self.ebuild.get_ebuild_text(org, org_license)
  File "/usr/lib64/python3.5/site-packages/superflore/generators/ebuild/ebuild.py", line 174, in get_ebuild_text
    ret += get_license(self.upstream_license[0]) + "\"\n\n"
  File "/usr/lib64/python3.5/site-packages/superflore/utils.py", line 210, in get_license
    raise UnknownLicense('bad license')
superflore.exceptions.UnknownLicense: bad license

Same thing with ros-indigo. I also suspect (but didn't check) other packages to fail the same way.

@allenh1
Copy link
Contributor

allenh1 commented Apr 17, 2018

Ya, that is one I've not been able to match.

# ls /usr/portage/licenses/ | grep BSD
BSD
BSD-1
BSD-2
BSD-4
BSD-with-attribution
Clear-BSD
Ruby-BSD
UCAR-BSD

Those are the BSD licenses available. Looks like BSD 3 Clause license is what it should be. I'm not sure why they just wrote "Modified BSD" in the license field, but you might raise that with the maintainer.

I'm not really sure what to do about this, to be completely honest. I don't think I should generally map "Modified BSD" to anything. License identification is just a bad time.

You can see the code for that here.

@tfoote recommended a library to do it in ros-infrastructure/superflore#75, but I never really got around to looking at it. If you want to explore that, that would be more than awesome. But, for now, I think the most reasonable thing would be to talk to the maintainers and let them know that their license string is blocking Gentoo ebuilds from being created.

@tfoote
Copy link
Member

tfoote commented Apr 18, 2018

If it's modified you can't group it into a standard, because it's unknown how it's modified. It could be modified trivially. Or it could be modified to have a completely different meaning. I'd definitely suggest contacting the maintainer/author.

@pholthaus
Copy link
Contributor Author

pholthaus commented Apr 18, 2018

When looking at https://github.com/ros-controls/ros_control/blob/kinetic-devel/LICENSE
it seems be a pretty standard license, though.

See https://opensource.org/licenses/BSD-3-Clause

Edit: Strangely, it can't be found in /usr/portage/licenses
Edit2: BSD-3-Clause (aka revised or modified BSD license) apparently is the standard BSD license, so modified actually is not refering so some random modification.

Also see (same as above):
https://gitweb.gentoo.org/repo/gentoo.git/plain/licenses/BSD

@pholthaus
Copy link
Contributor Author

Upstream is currently fixing this. In the mean time, can I generate the package from a different branch somehow?

@pholthaus
Copy link
Contributor Author

Upstream has now fixed this in their kinetic-devel and melodic-devel branches. Any chance to create the package from these branches using superflore @allenh1?

@awesomebytes
Copy link
Collaborator

+1

@awesomebytes
Copy link
Collaborator

awesomebytes commented Apr 26, 2018

@pholthau A new release of ros_control is on its way thanks to @bmagyar, when the rosdistro repo has the update merged the next superflore re-generation will put everything in place (hopefully).

Meanwhile I generated in a tricky way the ebuild and it's manifest in case it's useful for you too (I was just checking that the actual package and it's dependences compile).

ros-overlay/ros-kinetic/transmission_interface/transmission_interface-0.13.2.ebuild

# Copyright 2018 Open Source Robotics Foundation
# Distributed under the terms of the BSD license

EAPI=6
PYTHON_COMPAT=( python{2_7,3_5} )

inherit ros-cmake

DESCRIPTION="Transmission Interface."
HOMEPAGE="https://wiki.ros.org"
SRC_URI="https://github.com/ros-gbp/ros_control-release/archive/release/kinetic/${PN}/0.13.2-0.tar.gz -> ${PN}-kinetic-release-${PV}.tar.gz"

LICENSE="BSD"

KEYWORDS="~x86 ~amd64 ~arm ~arm64"
IUSE="test"
RDEPEND="
	ros-kinetic/pluginlib
	ros-kinetic/roscpp
	test? ( ros-kinetic/resource_retriever )
	dev-libs/tinyxml
"
DEPEND="${RDEPEND}
	ros-kinetic/catkin
	ros-kinetic/cmake_modules
	ros-kinetic/hardware_interface
"

SLOT="0"
ROS_DISTRO="kinetic"
ROS_PREFIX="opt/ros/${ROS_DISTRO}"

ros-overlay/ros-kinetic/transmission_interface/Manifest

DIST transmission_interface-kinetic-release-0.13.2.tar.gz 238050 BLAKE2B 4c72cfa79b48b9ce2a272d5aa031e553217209e7fc566e19013258e123cc9d6df70a21ca15f576dc934d997603feaef23db9bcad7a9704473f3506de80b28f96 SHA512 4061b9d942119ddb6169a3308793575257e34c557bed9e998ceb529bcf2046153100ba78486d7fe1b2fa8f1cd7f21b7d818204a68ce8662b571e9ec73167fdfc
EBUILD transmission_interface-0.13.2.ebuild 715 BLAKE2B 5cc09afa1964cfcffa18d1ae3f250b9ce7fa626e8bd1957d081ea55e6e44b2b7df572e9500dfb647f94445e9ca32ac66d6acd005f73a20bbeb0cdf420c44dc28 SHA512 c1fae2598ebe0c23e91dbf0f9f199deff6f2e38ba82589a68c7856a5a1ac2fc705c1b206eba57613303ff517ac640f39f38b93bf950b47910219589b87604b19
MISC metadata.xml 583 BLAKE2B 9f449e597d7c6d867d7c978ce86dcc6515abf527e7db070528f3d9b2641d1b1d0ae713b44c1352ec749640faf86dbaca67b674c0c16dbd8575bd8a4ca83eb0ab SHA512 b0bfbce464aedf757a91ba8881cdee9a5b101a3683bbcd1f26194f37fbf4878175552f1c0f40d00a9a83d880e20eb359631ab213c7c2532f6d811b86a99fd94a

@awesomebytes
Copy link
Collaborator

The PR is there ros/rosdistro#17635 just a matter of time.

@pholthaus
Copy link
Contributor Author

Perfect, thanks to all of you!

@allenh1
Copy link
Contributor

allenh1 commented Apr 27, 2018

@pholthau so is this ready to be closed?

Perfect, thanks to all of you!

you are very welcome! Always happy to get these things working.

@pholthaus
Copy link
Contributor Author

@allenh1 Upstream has released 0.13.3 which contains the fixes. As that will probably be picked up by rosdistro, this issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants