Bug 452486 (stage)

Summary: Review Request: stage - 2D multiple-robot simulator
Product: [Fedora] Fedora Reporter: Arindam Ghosh <makghosh>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, notting, susi.lehtola, tim
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-31 19:17:11 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 448025    
Bug Blocks: 201449    

Description Arindam Ghosh 2008-06-23 07:48:29 EDT
Spec URL: http://fedorapeople.org/~makghosh/SPECS/stage.spec
SRPM URL: http://fedorapeople.org/~makghosh/SRPMS/stage-2.1.0-1.fc9.src.rpm
Description: Stage simulates a population of mobile robots, sensors and objects
in a two-dimensional bitmapped environment. Stage is designed to
support research into multi-agent autonomous systems, so it provides
fairly simple, computationally cheap models of lots of devices rather
than attempting to emulate any device with great fidelity.

Koji scratch build: waiting for player[https://bugzilla.redhat.com/show_bug.cgi?id=448025] which is a dependency to get into the fedora repository.

Rpmlint: shows no errors in my i386 system build
Comment 1 Joonas Sarajärvi 2008-06-23 14:24:43 EDT
This is just an informal review.

MUST items:
- Rpmlint output clean on the spec file and the source rpm file: ok
- Package name: ok
- Spec file name: ok
- Package license: ok
- Actual license: ok
- License file included: ok
- Spec file legible and in American English: ok
- Included source file matches upstream source: ok
- BuildRequires seem ok.
- No need to use %find_lang. ok
- /sbin/ldconfig called in %post and %postun: ok
- Package not relocatable: ok
- Owns its directories and files: ok
- No duplicate files in %files: ok
- Permissions set correctly with %defattr: ok
- rm -rf $RPM_BUILD_ROOT in %clean: ok
- Consistent macro use with $RPM_BUILD_ROOT: ok
- Package contains code: ok
- No large documentation: ok
- Headers in -devel package: ok
- Static libraries in -static package: ok
- Includes .pc files for pkgconfig, depends on pkgconfig: ok
- %{_libdir}/*.so goes in -devel package, %{_libdir}/*.so.* go in the main
package: ok
- Fully versioned dependency for the -devel subpackage: ok
- No .la files: ok
- rm -rf $RPM_BUILD_ROOT at the beginning of %install: ok
- Filenames are valid UTF-8: ok

- Builds ok; can't test since the dependencies aren't yet in Fedora 9. Building
a modified package without the player-devel dependency works fine.

May need a fix:
- Doesn't contain a .desktop file and doesn't tell why there is no need for one,
even though is a GUI application (uses Gtk).
Comment 2 Arindam Ghosh 2008-06-24 16:28:26 EDT
Thanks for the quick review. Though this is a gtk application, everything in the
PSG (Player/Stage/Gazebo) framework more or less works from CLI. For, normally
stage or rather the libstageplugin is actually invoked by player by loading a
cfg file/simulation environment. And then stage starts off. Interaction occurs
through a client interface. So as obvious, cfg files etc can vary at each run of
player/stage which are required to be provided as options to the binaries. The
binaries provided solely by stage package also have similar application and
depends on .world files as options. The  gui is not yet got to the level of
taking care of all this, so practically there seems no feasible use of .desktop
file for stage. But if at all required something can be done with the example
.cfg files that comes with stage.
Comment 3 Tim Niemueller 2008-08-06 18:07:16 EDT
Hi Arindam. Some comments and questions:

- The plugin shouldn't be versioned. Can we prevent that? For now the Player plugin is at /usr/lib64/libstageplugin.so.1, but if you try to load it Player will only try libstageplugin.so (without .1 in the end). So only if the devel sub-package is installed the plugin can actually be loaded.
- There is a problem with the Player package with the plugin search path. We need to define a Plugin directory like /usr/lib/player which is used to store plugins. I will work on that for the Player package so that we can use it for Stage.
- Have you tried the new 3.0.1? Maybe we want to rename this package to stage2 and package the new version as stage?
Comment 4 Arindam Ghosh 2008-08-27 15:39:32 EDT
(In reply to comment #3)
> - The plugin shouldn't be versioned. Can we prevent that? For now the Player
> plugin is at /usr/lib64/libstageplugin.so.1, but if you try to load it Player
> will only try libstageplugin.so (without .1 in the end). So only if the devel
> sub-package is installed the plugin can actually be loaded.

Well, this may call for merging of -devel branch with the main package. thoughts?

> - There is a problem with the Player package with the plugin search path. We
> need to define a Plugin directory like /usr/lib/player which is used to store
> plugins. I will work on that for the Player package so that we can use it for
> Stage.

yeah, i noticed the search path problems earlier while packaging stage...so what is its' status now? player cvs is up now...haven't got time to check these things..../me badly busy at the final leg of the GSoC project

> - Have you tried the new 3.0.1? Maybe we want to rename this package to stage2
> and package the new version as stage?

the last time i tried to build it failed miserably. they have lot of pending things to put in stage3, so as things become little stable with the upstream, i will update the srpm.
Comment 5 Tim Niemueller 2008-09-02 14:05:35 EDT
(In reply to comment #4)
> Well, this may call for merging of -devel branch with the main package.
> thoughts?
> 
[...]

I'm about to commit a patch (currently testing), which will use %{_libdir}/player as a plugin directory. There is one plugin coming with Player where I move the library file to the desired name in the new Player plugin directory and removed the symlinks. So this would probably what we want to do for now, you agree?

> the last time i tried to build it failed miserably. they have lot of pending
> things to put in stage3, so as things become little stable with the upstream, i
> will update the srpm.

I think that's a good decision. Let it stabilize a bit...
Comment 6 Tim Niemueller 2008-09-03 07:14:40 EDT
Updates for F-8/F-9 have been created. Get the builds from Koji as updates will take some time because of the infrastructure outages and switching to a new signing key.

F-8: http://koji.fedoraproject.org/koji/buildinfo?buildID=61379
F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=61301
Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=61382

Please see the Player spec at http://cvs.fedoraproject.org/viewvc/rpms/player/F-9/player.spec?revision=1.3&view=markup how to copy the plugins (see %install section, mv/rm commands just before the desktop-file-install lines.
Comment 7 Jason Tibbitts 2009-03-24 22:10:01 EDT
It's been over six months now; was there ever an updated package, or should this ticket just be closed?
Comment 8 Jason Tibbitts 2009-03-31 19:17:11 EDT
Closing after another week with no response.
Comment 9 Susi Lehtola 2010-01-18 02:52:39 EST

*** This bug has been marked as a duplicate of bug 556346 ***