Summary: | sci-electronics/stage: Virtual world simulator for robots and sensors. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | brian gerkey <gerkey> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | gentoo-bugs, jean-francois, miknix, sci-electronics |
Priority: | Normal | Keywords: | EBUILD, InOverlay |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://rtv.github.io/Stage/ | ||
Whiteboard: | Science overlay | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 185298, 260383 | ||
Attachments: |
player-1.4_rc1.ebuild (New package)
sci-electronics/player-1.6.5 ebuild sci-electronics/stage-1.6.2 ebuild player-2.0.4.ebuild The 2.1.1 ebuild Patch that fixes compilation with gcc-4.3 zlib-1.2.6.patch |
Description
brian gerkey
2003-08-10 21:28:52 UTC
Created attachment 15878 [details]
player-1.4_rc1.ebuild (New package)
I submitted this ebuild 14 months ago, and it was last touched almost 12 months ago. Should I assume that it's been rejected? brian. Not at all. It is just that the science team has over a hundred requests pending! With so much work to do, we tend to focus on more popular packages and those we are already familiar with. Also, all packages must be tested to ensure they work before inclusion in Portage, and I frankly have no idea how to test a robot device server since I have no such hardware. Ok, that makes sense; thanks for the feedback. I'd really like to get this ebuild into portage. As for popularity, we're doing very well as far as robotics software goes: http://sourceforge.net/project/stats/?group_id=42445 But it's a specialized market, and there's no reason to have even heard of our software if you don't work in robotics or AI. As for testing, you really can't test Player beyond compilation and installation unless you have some robot hardware on hand. Now, we also maintain two robot simulators, Stage and Gazebo, to which Player is the interface. You could test Player + Stage and/or Player + Gazebo without any special hardware. Would it help if we submitted ebuilds for Stage and Gazebo? > As for popularity, we're doing very well as far as robotics software goes No offense meant. I was thinking in terms of how specialised this software is. > Now, we also maintain two robot simulators, Stage and Gazebo, to which Player > is the interface. You could test Player + Stage and/or Player + Gazebo > without any special hardware. Would it help if we submitted ebuilds for > Stage and Gazebo? That sounds like a good solution. player compiled and installed OK here. (Documentation will need to be installed in "/usr/share/doc/player-${player-version}" rather than "/usr/share/doc" to comply with Gentoo standards, though. I can make this change.) If you can submit working ebuilds for robot simulators, along with some instructions on how to test them, I will try them out and eventually add both packages to Portage. I also noticed there is a number of missing dependencies in your ebuild, such as Python, tcl/tk, gtk, libraw1394, jpeglib and libRTK. Also, the videodev2 headers from the Linux kernel could not be found by the configure script, altough they are present on my system. These issues will need to be fixed. Since you are probably familiar with the libRTK package, I suppose you could also submit an ebuild for this package. Sounds great. We're planning to make new releases of pretty much everything (librtk, stage, gazebo, and player) in early November, so we'll submit ebuilds for the new versions after that, hopefully addressing all the problems you've noted. If I may ask your advice, what's the best way to handle optional dependencies? Player contains many "drivers" that provide access to various bits of hardware, software, and simulators. Each driver may have some dependencies (e.g., OpenCV, GSL, FFTW, libraw1394), but none of the drivers is actually required to build Player. We check for all dependencies during configuration, so that the build succeeds on any reasonably POSIX platform. It seems like a shame to strictly require all of the optional dependencies, when Player will happily build without them (albeit with fewer drivers and thus less functionality). At the other extreme, we could add USE flags for everything on which Player depends (including our other packages librtk, stage, and gazeo), but I'm hesitant to pollute the USE namespace with a lot of new flags. In between these two options, we could not require any optional dependencies, but just build support for whatever the user has installed. So if the user wants to use a driver that requires the GSL, then it's his responsibility to install the GSL before installing Player. And maybe there are other options I haven't thought of. What do you recommend? Optional dependencies are always managed using "USE" flags. Since it is possible to add local "USE" flags to an ebuild, there is no "USE" pollution to fear. Usually, the best course of action is to strictly require the packages which are necessary for the basic and most common fonctionnalities, and to use flags for the optional components that are more exotic, or that some users are likely not to require. Compiling "just for what is installed" should be avoided as much as possible for two reasons. First, we do not want the users to do dependency tracking themselves; Portage should do it for them whenever possible, and should give them all the information they require to configure the package. Second, it could get very hard to fix bugs if the same package built on different machines using the same compiler, "USE" flags and "CFLAGS" had different functionnalities. Attached are app-sci/player-1.6.5 and app-sci/stage-1.6.2 ebuilds. As for the various lib dependencies that Mr Gerkey refers to (Comment #7), I am not aware of each and every driver... If I could have a list of the drivers that require some other libraries, I could certainly have the ebuild to disable/enable them with a USE flag. Created attachment 75621 [details]
sci-electronics/player-1.6.5 ebuild
Created attachment 75622 [details]
sci-electronics/stage-1.6.2 ebuild
Hi there. I searched on bugzilla for a player ebuild and I found Zero Bugs. So I submitted a player ebuild. Today, when submitting the last ebuild (gazebo) I tried to find player ebuild (the one I submited before) and I came across with this thread. Strange I didn't find this bug in the first time : \ - - Anyway.. Since player goes now in its 2.0.4 version and Gazebo project born, I hope my efforts would be useful to you guys. See ebuilds: player: #185116 stage: #185298 gazebo: #185470 Greetings, Angelo *** Bug 185116 has been marked as a duplicate of this bug. *** Created attachment 136785 [details]
player-2.0.4.ebuild
Angelo's ebuild now in science overlay. Thanks all. Report problems here. @sci-electronics: feel free to merge this into the main tree. (In reply to comment #15) > @sci-electronics: feel free to merge this into the main tree. You talkin' to me ? ;o) I certainly will have a look at this. In the meantime I'm reassigning this to sci-electronics, because if I don't it's not on my radar (and that's the reason why I hadn't seen this before). Denis. Bump? Player 2.1.1 is out. The 2.0.4 ebuild seems to work ok, but there are some compilation problems with gcc-4.3. The attached ebuild and patch work perfectly here. Created attachment 169320 [details]
The 2.1.1 ebuild
Created attachment 169322 [details, diff]
Patch that fixes compilation with gcc-4.3
Doesn't build anymore: mkdir .libs x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../libplayercore -I../../../client_libs/libplayerc++ -Wall -I../../.. -MT garminnmea.lo -MD -MP -MF .deps/garminnmea.Tpo -c garminnmea.cc -fPIC -DPIC -o .libs/garminnmea.o garminnmea.cc: In function ‘void GarminNMEA_Register(DriverTable*)’: garminnmea.cc:255: warning: deprecated conversion from string constant to ‘char*’ garminnmea.cc: In member function ‘int GarminNMEA::ReadSentence(char*, size_t)’: garminnmea.cc:618: error: invalid conversion from ‘const char*’ to ‘char*’ garminnmea.cc:632: error: invalid conversion from ‘const char*’ to ‘char*’ garminnmea.cc:677: error: invalid conversion from ‘const char*’ to ‘char*’ garminnmea.cc: In member function ‘char* GarminNMEA::GetNextField(char*, size_t, const char*)’: garminnmea.cc:806: error: invalid conversion from ‘const char*’ to ‘char*’ make[4]: *** [garminnmea.lo] Error 1 make[4]: Leaving directory `/var/tmp/portage/sc And there is a version bump to 3.0.2 Under construction. I have the same buid error Created attachment 312891 [details]
zlib-1.2.6.patch
fixes compilation for player-3.0.2 with >=zlib-1.2.6
per up stream @ http://playerstage.sourceforge.net/ this project has moved to github and was renamed from player to stage. new home @ https://github.com/rtv/Stage upstream github source has not seen much activity since Jan-2012 with version 4.1.1 Please let us know if you (or anyone else) has continued interest in this project. Tom D Recent versions are in the tree: sci-electronics/Stage |