rcssserver3d Review Request

[Hedayat Vatankhah]

Hi all,

I've just submitted my review request for rcssserver3d package:

https://bugzilla.redhat.com/show_bug.cgi?id=450409

This is my first package in Fedora! :)

Thanks,

Hedayat

[Tim Niemueller]

Hedayat Vatankhah schrieb:
> Hi all,
>
> I've just submitted my review request for rcssserver3d package:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=450409

Great! I've compiled the package and got some errors:

- Unpackaged file /usr/bin/rcssmonitor3D-lite, after adding this to the
%files section I could build it.

- The devel packages triggers rpmlint warnings which have to be fixed:
# rpmlint rcssserver3d-devel-0.5.9-1.fc9.x86_64.rpm
rcssserver3d-devel.x86_64: W: no-documentation
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
/usr/lib64/rcssserver3d/libsalt.so libsalt.so.0.3.1
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
/usr/lib64/rcssserver3d/libspark.so libspark.so.0.0.0
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
/usr/lib64/rcssserver3d/librcssmonitor3D.so librcssmonitor3D.so.1.1.0
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
/usr/lib64/rcssserver3d/liboxygen.so liboxygen.so.3.2.3
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
/usr/lib64/rcssserver3d/libkerosin.so libkerosin.so.1.0.1
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
/usr/lib64/rcssserver3d/libzeitgeist.so libzeitgeist.so.3.0.1
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
/usr/lib64/rcssserver3d/libtinyxml.so libtinyxml.so.0.0.0
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
/usr/lib64/rcssserver3d/librcssnet3D.so librcssnet3D.so.0.0.0
rcssserver3d-devel.x86_64: E: only-non-binary-in-usr-lib

- You should consider splitting the patch in one GCC4.3 and one rpath patch

- You are a rcssserver3d committer, right? So why not commit the fixes
and build a package from SVN?

- The patches seem to contain changes besides fixing rpath and GCC 4.3,
are these changes necessary? Should be a separate patch then.

- The explicit requires on the libraries shouldn't be necessary,
rpmbuild should be able to figure them out automatically

- What do you mean by comment 4, the "included some so files". What are
these .so files? If these libraries are part of rcssserver3d they should
be added! I don't really understand what you mean I think.

I haven't done any runtime tests.

Jeff, can I do the review and you sponsor him or do you need to do the
review then as well (I can't sponsor).

Tim

[Hedayat Vatankhah]

Hi Tim,
Thank you a lot for your fast response and detailed answer. It is great.

On Mon, Jun 9, 2008 at 3:40 PM, Tim Niemueller  wrote:
> ...
> Great! I've compiled the package and got some errors:
> Unpackaged file /usr/bin/rcssmonitor3D-lite, after adding this to the
>
> %files section I could build it.

Oh, Thanks! Since I don't have freeglut-devel installed, this file wasn't
produced on my system. This file isn't useful now and I'll remove it in the
%install section.
> The devel packages triggers rpmlint warnings which have to be fixed:
>
> # rpmlint rcssserver3d-devel-0.5.9-1.fc9.x86_64.rpm
> rcssserver3d-devel.x86_64: W: no-documentation
> ...
> /usr/lib64/rcssserver3d/libtinyxml.so libtinyxml.so.0.0.0
> rcssserver3d-devel.x86_64: W: dangling-relative-symlink
> ...
> rcssserver3d-devel.x86_64: E: only-non-binary-in-usr-lib

Would you please help me a little:
1. There are some documentation for developers, but since they're a little
big, I prefer to package them in a separate package. (They will double the
package size). However there are some HTML pages which I can put here as
documentation (I wanted to put them in the doc package). Is it necessary to
have some doc files?!

2. What should I do with dangling-relative-symlink warning? The symlinks are
valid, but the targets are in the main package. I don't know what should I
do to prevent these warnings :( What can I do?

3. I should go home and check it again, but I think there are only some
symlinks in /usr/lib. What's the problem? I don't know what else should be
in this directory as other files should be in the main package.
> You should consider splitting the patch in one GCC4.3 and one rpath patch
>
> You are a rcssserver3d committer, right? So why not commit the fixes
>
> and build a package from SVN?
> The patches seem to contain changes besides fixing rpath and GCC 4.3,
>
> are these changes necessary? Should be a separate patch then.

In fact, I first committed these change to rcssserver3d's CVS and then
created the patches using that. This is why all of the patches are in a
single file.
Yes, I personally prefer to create a package from CVS, but since one of the
review requirement was to compare the package's sources MD5 with upstream
release, I thought that I can't build a package from CVS. What should I
include in my review request if I build a package from the CVS code?

- The explicit requires on the libraries shouldn't be necessary,
> rpmbuild should be able to figure them out automatically

I was forced to add them for SUSE Build Service. Is there any need to remove
them?

- What do you mean by comment 4, the "included some so files". What are
> these .so files? If these libraries are part of rcssserver3d they should
> be added! I don't really understand what you mean I think.

Sorry for this ambiguity. It is stated in Fedora packaging guidelines that
when a package includes versioned .so files, the .so symlinks must go in the
-devel package. But I can't do that since the server's binary looks for
these .so files. This is why only a few of .so files are in the -devel
package.

I haven't done any runtime tests.

At least, they work on my system.

Thanks again,
Hedayat
> Jeff, can I do the review and you sponsor him or do you need to do the
> review then as well (I can't sponsor).
>    Tim
>
> --
>    Tim Niemueller       www.niemueller.de
> =================================================================
>  Imagination is more important than knowledge. (Albert Einstein)
>
> Fedora-robotics-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-robotics-list

[Tim Niemueller]

Hedayat Vatankhah schrieb:
> Hi Tim,
> Thank you a lot for your fast response and detailed answer. It is great.

That's what this SIG is meant to be good for :-)
> On Mon, Jun 9, 2008 at 3:40 PM, Tim Niemueller <[e-mail]
> > wrote:
> ...
>
> Great! I've compiled the package and got some errors:
>
> - Unpackaged file /usr/bin/rcssmonitor3D-lite, after adding this to the
> %files section I could build it.
>
> Oh, Thanks! Since I don't have freeglut-devel installed, this file
> wasn't produced on my system. This file isn't useful now and I'll remove
> it in the %install section.

OK.
> - The devel packages triggers rpmlint warnings which have to be fixed:
> # rpmlint rcssserver3d-devel-0.5.9-1.fc9.x86_64.rpm
> rcssserver3d-devel.x86_64: W: no-documentation
> ...
> /usr/lib64/rcssserver3d/libtinyxml.so libtinyxml.so.0.0.0
> rcssserver3d-devel.x86_64: W: dangling-relative-symlink
> ...
> rcssserver3d-devel.x86_64: E: only-non-binary-in-usr-lib
>
> Would you please help me a little:
> There are some documentation for developers, but since they're a
>
> little big, I prefer to package them in a separate package. (They will
> double the package size). However there are some HTML pages which I can
> put here as documentation (I wanted to put them in the doc package). Is
> it necessary to have some doc files?!

The main package should have README, AUTHORS, LICENSE files etc., the
verbose documentation is well-placed in the -doc subpackage. You can
ignore the no-documentation warning in that case for the other packages.
> What should I do with dangling-relative-symlink warning? The symlinks
>
> are valid, but the targets are in the main package. I don't know what
> should I do to prevent these warnings :( What can I do?

The link should probably point to the full path, not just the file. Give
it a try, I'm not absolutely sure on this one.
> I should go home and check it again, but I think there are only some
>
> symlinks in /usr/lib. What's the problem? I don't know what else should
> be in this directory as other files should be in the main package.

You mean for the very same problem?
> - You should consider splitting the patch in one GCC4.3 and one
> rpath patch
>
> - You are a rcssserver3d committer, right? So why not commit the fixes
> and build a package from SVN?
>
> - The patches seem to contain changes besides fixing rpath and GCC 4.3,
> are these changes necessary? Should be a separate patch then.
>
>
> In fact, I first committed these change to rcssserver3d's CVS and then
> created the patches using that. This is why all of the patches are in a
> single file.
> Yes, I personally prefer to create a package from CVS, but since one of
> the review requirement was to compare the package's sources MD5 with
> upstream release, I thought that I can't build a package from CVS. What
> should I include in my review request if I build a package from the CVS
> code?

Just a short explanation like "CVS contains fixes needed for proper
Fedora packaging". You need then a special release number like
0.5.10-0.1.cvs20080610. Note the release number of 0.1. This is required
to allow for proper upgrading when the final 0.5.10 is released.
> - The explicit requires on the libraries shouldn't be necessary,
> rpmbuild should be able to figure them out automatically
>
> I was forced to add them for SUSE Build Service. Is there any need to
> remove them?

It's a recommendation in the guidelines to *not* have these explicit
requires if not really necessary. You can just leave it out in the
Fedora block.
> - What do you mean by comment 4, the "included some so files". What are
> these .so files? If these libraries are part of rcssserver3d they should
> be added! I don't really understand what you mean I think.
>
> Sorry for this ambiguity. It is stated in Fedora packaging guidelines
> that when a package includes versioned .so files, the .so symlinks must
> go in the -devel package. But I can't do that since the server's binary
> looks for these .so files. This is why only a few of .so files are in
> the -devel package.

Does it explicitly dlopen these files? Auto-linking at runtime should
catch this otherwise. If it dlopens the files these could account as
"plugins" or so, and in that case I think it is fine to have these in
the main package.
> I haven't done any runtime tests.
>
> At least, they work on my system.

Good.

Tim

[Hedayat Vatankhah]

/*Tim Niemueller */ wrote on 06/10/2008 08:31:25 PM:
> Hedayat Vatankhah schrieb:
>
> ...
> > - The devel packages triggers rpmlint warnings which have to be fixed:
> > # rpmlint rcssserver3d-devel-0.5.9-1.fc9.x86_64.rpm
> > rcssserver3d-devel.x86_64: W: no-documentation
> > ...
> > /usr/lib64/rcssserver3d/libtinyxml.so libtinyxml.so.0.0.0
> > rcssserver3d-devel.x86_64: W: dangling-relative-symlink
> > ...
> > rcssserver3d-devel.x86_64: E: only-non-binary-in-usr-lib
> >
> > ...
>
> The main package should have README, AUTHORS, LICENSE files etc., the
> verbose documentation is well-placed in the -doc subpackage. You can
> ignore the no-documentation warning in that case for the other packages.

OK, so I'll ignore this warning and will create -doc package. The main 
package has the mentioned files.
> > What should I do with dangling-relative-symlink warning? The symlinks
> >
> > are valid, but the targets are in the main package. I don't know what
> > should I do to prevent these warnings :( What can I do?
>
> The link should probably point to the full path, not just the file. Give
> it a try, I'm not absolutely sure on this one.

OK, I'll check it
> > I should go home and check it again, but I think there are only some
> >
> > symlinks in /usr/lib. What's the problem? I don't know what else should
> > be in this directory as other files should be in the main package.
>
> You mean for the very same problem?

Oh sorry, I was talking about this error:

E: only-non-binary-in-usr-lib
> > ...
>
> Just a short explanation like "CVS contains fixes needed for proper
> Fedora packaging". You need then a special release number like
> 0.5.10-0.1.cvs20080610. Note the release number of 0.1. This is required
> to allow for proper upgrading when the final 0.5.10 is released.

OK, thanks.
> > - The explicit requires on the libraries shouldn't be necessary,
> > rpmbuild should be able to figure them out automatically
> >
> > I was forced to add them for SUSE Build Service. Is there any need to
> > remove them?
>
> It's a recommendation in the guidelines to *not* have these explicit
> requires if not really necessary. You can just leave it out in the
> Fedora block.

OK!
> > - What do you mean by comment 4, the "included some so files". What are
> > these .so files? If these libraries are part of rcssserver3d they should
> > be added! I don't really understand what you mean I think.
> >
> > Sorry for this ambiguity. It is stated in Fedora packaging guidelines
> > that when a package includes versioned .so files, the .so symlinks must
> > go in the -devel package. But I can't do that since the server's binary
> > looks for these .so files. This is why only a few of .so files are in
> > the -devel package.
>
> Does it explicitly dlopen these files? Auto-linking at runtime should
> catch this otherwise. If it dlopens the files these could account as
> "plugins" or so, and in that case I think it is fine to have these in
> the main package.

Yes, they ARE plugins.

OK, thank you very much. I'll fix my .spec file and will create a new 
SRPM using CVS version of the server.

Good luck,
Hedayat
> > I haven't done any runtime tests.
> >
> > At least, they work on my system.
>
> Good.
>
> Tim

[Hedayat Vatankhah]

Hi!
I've uploaded new SRPM and SPEC files. It would be nice if you or 
anybody else could have another look.

Thanks
Hedayat

/*Tim Niemueller */ wrote on 06/10/2008 08:31:25 PM:
> Hedayat Vatankhah schrieb:
> > Hi Tim,
> > Thank you a lot for your fast response and detailed answer. It is great.
>
> That's what this SIG is meant to be good for :-)
> > On Mon, Jun 9, 2008 at 3:40 PM, Tim Niemueller <[e-mail]
> > > wrote:
> > ...
> >
> > Great! I've compiled the package and got some errors:
> >
> > - Unpackaged file /usr/bin/rcssmonitor3D-lite, after adding this to the
> > %files section I could build it.
> >
> > Oh, Thanks! Since I don't have freeglut-devel installed, this file
> > wasn't produced on my system. This file isn't useful now and I'll remove
> > it in the %install section.
>
> OK.
> > - The devel packages triggers rpmlint warnings which have to be fixed:
> > # rpmlint rcssserver3d-devel-0.5.9-1.fc9.x86_64.rpm
> > rcssserver3d-devel.x86_64: W: no-documentation
> > ...
> > /usr/lib64/rcssserver3d/libtinyxml.so libtinyxml.so.0.0.0
> > rcssserver3d-devel.x86_64: W: dangling-relative-symlink
> > ...
> > rcssserver3d-devel.x86_64: E: only-non-binary-in-usr-lib
> >
> > Would you please help me a little:
> > There are some documentation for developers, but since they're a
> >
> > little big, I prefer to package them in a separate package. (They will
> > double the package size). However there are some HTML pages which I can
> > put here as documentation (I wanted to put them in the doc package). Is
> > it necessary to have some doc files?!
>
> The main package should have README, AUTHORS, LICENSE files etc., the
> verbose documentation is well-placed in the -doc subpackage. You can
> ignore the no-documentation warning in that case for the other packages.
> > What should I do with dangling-relative-symlink warning? The symlinks
> >
> > are valid, but the targets are in the main package. I don't know what
> > should I do to prevent these warnings :( What can I do?
>
> The link should probably point to the full path, not just the file. Give
> it a try, I'm not absolutely sure on this one.
> > I should go home and check it again, but I think there are only some
> >
> > symlinks in /usr/lib. What's the problem? I don't know what else should
> > be in this directory as other files should be in the main package.
>
> You mean for the very same problem?
> > - You should consider splitting the patch in one GCC4.3 and one
> > rpath patch
> >
> > - You are a rcssserver3d committer, right? So why not commit the fixes
> > and build a package from SVN?
> >
> > - The patches seem to contain changes besides fixing rpath and GCC 4.3,
> > are these changes necessary? Should be a separate patch then.
> >
> >
> > In fact, I first committed these change to rcssserver3d's CVS and then
> > created the patches using that. This is why all of the patches are in a
> > single file.
> > Yes, I personally prefer to create a package from CVS, but since one of
> > the review requirement was to compare the package's sources MD5 with
> > upstream release, I thought that I can't build a package from CVS. What
> > should I include in my review request if I build a package from the CVS
> > code?
>
> Just a short explanation like "CVS contains fixes needed for proper
> Fedora packaging". You need then a special release number like
> 0.5.10-0.1.cvs20080610. Note the release number of 0.1. This is required
> to allow for proper upgrading when the final 0.5.10 is released.
> > - The explicit requires on the libraries shouldn't be necessary,
> > rpmbuild should be able to figure them out automatically
> >
> > I was forced to add them for SUSE Build Service. Is there any need to
> > remove them?
>
> It's a recommendation in the guidelines to *not* have these explicit
> requires if not really necessary. You can just leave it out in the
> Fedora block.
> > - What do you mean by comment 4, the "included some so files". What are
> > these .so files? If these libraries are part of rcssserver3d they should
> > be added! I don't really understand what you mean I think.
> >
> > Sorry for this ambiguity. It is stated in Fedora packaging guidelines
> > that when a package includes versioned .so files, the .so symlinks must
> > go in the -devel package. But I can't do that since the server's binary
> > looks for these .so files. This is why only a few of .so files are in
> > the -devel package.
>
> Does it explicitly dlopen these files? Auto-linking at runtime should
> catch this otherwise. If it dlopens the files these could account as
> "plugins" or so, and in that case I think it is fine to have these in
> the main package.
> > I haven't done any runtime tests.
> >
> > At least, they work on my system.
>
> Good.
>
> Tim