[Bug 191014] Review Request: ganymed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: ganymed


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


tibbs@xxxxxxxxxxx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|bugzilla-sink@xxxxxxxxxxxxx |tibbs@xxxxxxxxxxx
OtherBugsDependingO|163776                      |163778
              nThis|                            |




------- Additional Comments From tibbs@xxxxxxxxxxx  2006-06-14 10:47 EST -------
------- Additional Comments From tibbs@xxxxxxxxxxx  2006-06-11 01:56 EST -------
I was able to fix the debuginfo generation by adding the following to the end of
the %build section:

# Move source files to fix -debuginfo generation.
mv src/* .

It seems the file locations stored in the debug information didn't match the
actual locations of the files, so I just moved them so that they'd be found. 
There are still some errors lile:

cpio: ganymed-ssh2-build209/ch/ethz/ssh2/Connection$1$TimeoutState.java: No such
file or directory

Each of the errors mentions a file with a dollar sign; no such files exist in
the source.

One other thing to note: the page http://fedoraproject.org/wiki/NativeJava,
which I'm taking as the packaging guidelines here, mentions that the %post and
%postun scripts should look like:

if [ -x %{_bindir}/rebuild-gcj-db ]
then
  %{_bindir}/rebuild-gcj-db
fi

I don't really see the difference if the package that provides rebuild-gcj-db is
explicitly kept in with Require(post) and Require(postun), and the way this
package does things is simpler and matches what the core eclipse packages do.

So really the only issues I see are the documentation and the changelog revision
format.

------- Additional Comments From ville.skytta@xxxxxx  2006-06-11 02:10 EST -------
(In reply to comment #7)
> [...] end of the %build section:
> 
> # Move source files to fix -debuginfo generation.
> mv src/* .

That sounds like something that is very likely to break --short-circuit builds.
 cp -pR would sound better than mv (but that's not a real fix either).

------- Additional Comments From tibbs@xxxxxxxxxxx  2006-06-11 02:38 EST -------
Good point.  Unfortunately I really have no idea what's really going on here; I
guess find-debuginfo.sh is extracting the full set of debug symbols from the
single .so file and trying to copy any referenced files into the -debuginfo
package.  But it's assuming some link between those filenames and the actual
pathnames in the build directory that it probably shoudn't be.  It doesn't break
for all packages, but it seems like it should break on any package that puts the
source tree in a subdirectory.

This seems on point:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153247

The fix there is nastier, and exists but is commented out in the current Eclipse
-devel spec.

In any case, this seems simpler, doesn't copy the whole source tree and
shouldn't break short-circuit builds:

# Link source files to fix -debuginfo generation.
rm -f ch
ln -s src/ch

------- Additional Comments From bkonrath@xxxxxxxxxx  2006-06-11 14:31 EST -------
(In reply to comment #9)
> # Link source files to fix -debuginfo generation.
> rm -f ch
> ln -s src/ch

Yeah that should work. find-debuginfo.sh seems to be broken for java packages
right now. It's on my list of things to investigate for FC6 but if someone wants
to help out here that would be great.

------- Additional Comments From robert@xxxxxxxxxxxxxxxxx  2006-06-11 19:03 EST
-------
updated

http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/ganymed.spec
http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/ganymed-209-3.src.rpm

I applied the debuginfo workaround, (there are still warnings for the java inner
classes, maybe find-debuginfo.sh must ignore class with $ in their names)

Checked rpmlint warnings, the only no fixed warnings are
"wrong-file-end-of-line-encoding" for HTML files.

------- Additional Comments From tibbs@xxxxxxxxxxx  2006-06-13 00:26 EST -------
Generally we fix the line endings of HTML files as well.  You can just add it to
your sed call.

There is one issue I'd like to discuss, which is the package name.  Upstream
calls this "ganymed-ssh2", and their web site implies that they are actually
developing a software project entitled "ganymed".  I have no idea whether this
will be released to the public or whether we'd eventually package it, but I am
concerned that perhaps it would be a good idea to just name this package
"ganymed-ssh2" and avoid the potentential for confusion and future conflicts.

A full review turned up a couple more minor issues:

This package places files in %libdir/gcj/ganymed but doesn't own it.

You use the %{__sed} macro, but don't use %{__rm}, %{__ln_s}, or %{__install}. 
Consistency is important, so you should either switch to plain "sed" or
macrotize the rest of the spec.

* package meets naming and packaging guidelines.
X specfile is properly named and is cleanly written but does not use macros
consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible.  License text included in package.
* source files match upstream:
   b0ee2f0feeb5f4ae02c2d5269fe6e1e0  ganymed-ssh2-build209.zip
* latest version is being packaged.
* BuildRequires are proper.
* package builds in mock (development, x86_64).
X rpmlint complains (eol encoding for faq/FAQ.html)
* final provides and requires are sane:
  ganymed-209-3.fc6.x86_64.rpm
   ganymed-209.jar.so()(64bit)
   ganymed = 209-3.fc6
  =
   /usr/bin/rebuild-gcj-db
   java-gcj-compat >= 1.0.33
   libgcj.so.7()(64bit)
   libz.so.1()(64bit)
* no shared libraries are present.
* package is not relocatable.
X owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is not present; no test suite upstream.
* scriptlets present and are OK.
* code, not content.
* documentation is relatively small (30% of the package), so no -docs subpackage
is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.



-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-package-review

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]