Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 205917 - java-osgi.eclass: 'Unable to uncompress correctly the original jar'
Summary: java-osgi.eclass: 'Unable to uncompress correctly the original jar'
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Java team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-15 08:45 UTC by Ruslan Lopatin
Modified: 2008-01-15 11:13 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ruslan Lopatin 2008-01-15 08:45:21 UTC
Unable to emerge packages using java-osgi.eclass.
Every attempt results to 'Unable to uncompress correctly the original jar'.

Reproducible: Always

Steps to Reproduce:
emerge =dev-java/commons-logging-1.1-r4
The same for icu4j-3.6.1.
Actual Results:  
>>> Install commons-logging-1.1-r4 into /var/tmp/portage/dev-java/commons-logging-1.1-r4/image/ category dev-java
java.io.FileNotFoundException:  (No such file or directory)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:106)
        at java.io.FileInputStream.<init>(FileInputStream.java:66)
        at sun.tools.jar.Main.run(Main.java:205)
        at sun.tools.jar.Main.main(Main.java:1022)
 *
 * ERROR: dev-java/commons-logging-1.1-r4 failed.
 * Call stack:
 *               ebuild.sh, line   46:  Called src_install
 *             environment, line 4049:  Called java-osgi_newjar-fromfile 'src_install' 'src_install' 'target/commons-logging-1.1.jar'
 *             environment, line 2252:  Called _java-osgi_makejar-fromfile '/var/portage/dev-java/commons-logging/files/commons-logging-1.1-manifest' 'Apache Commons Logging' 'target/commons-logging-1.1.jar' '/var/portage/dev-java/commons-logging/files/commons-logging-1.1-manifest'
 *             environment, line  424:  Called die
 * The specific snippet of code:
 *       cd "${_OSGI_T}/tmp_jar" && jar xf "${absoluteJarPath}" && cd - > /dev/null || diefunc "$FUNCNAME" "$LINENO" "$?" "Unable to uncompress correctly the original jar";
 *  The die message:
 *   Unable to uncompress correctly the original jar


This happens because _canonicalise() function calls realpath with wrong args:
Instead of
  realpath "${@}"
it should be
  realpath -f "${@}"

Without -f option realpath returns nothing.

The corrected _canonicalise() function works fine and package merged successfully.
Comment 1 Ruslan Lopatin 2008-01-15 08:51:39 UTC
The realpath is a symlink to readlink from sys-apps/coreutils-6.9-r1.
Comment 2 Jean-Noël Rivasseau (RETIRED) gentoo-dev 2008-01-15 10:02:27 UTC
Caster, could you have a look at this as you wrote the canonalise function when you fixed the eclass the first time. I remember that I only used readlink, I did not know about realpath (actually on my system -amd64- I don't even have realpath installed, so for me commons-logging merges fine).

Can't we just use only readlink? What are the reasons you wrote the canonalise function this way?
Comment 3 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2008-01-15 10:04:01 UTC
(In reply to comment #1)
> The realpath is a symlink to readlink from sys-apps/coreutils-6.9-r1.
 
Well that's wrong, realpath != readlink. The "real" realpath (app-admin/realpath or the one that's on bsd systems) does not need -f argument, in fact it reports it as invalid option.
Did you make the symlink yourself? Because AFAIK coreutils does not make it. If you made it yourself then I'd close it as invalid. If something installs it, it needs to be fixed and as a workaround we could check if realpath is symlink to readlink. But I wouldn't add the check just if few users make wrong symlinks :)
Comment 4 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2008-01-15 10:06:52 UTC
(In reply to comment #2)
> Can't we just use only readlink? What are the reasons you wrote the canonalise
> function this way?

It's because of fbsd which doesn't have readlink supporting -f option (which is needed here), but has realpath in the system. Consulted it with Flameeyes, I still hope he will move the function to his portability.eclass one day :)
Comment 5 Ruslan Lopatin 2008-01-15 10:49:57 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > The realpath is a symlink to readlink from sys-apps/coreutils-6.9-r1.
> 
> Well that's wrong, realpath != readlink. The "real" realpath
> (app-admin/realpath or the one that's on bsd systems) does not need -f
> argument, in fact it reports it as invalid option.
> Did you make the symlink yourself? Because AFAIK coreutils does not make it. If
> you made it yourself then I'd close it as invalid. If something installs it, it
> needs to be fixed and as a workaround we could check if realpath is symlink to
> readlink. But I wouldn't add the check just if few users make wrong symlinks :)
> 
I removed realpath symlink and everything works now. It not belongs to any package anyway.

But i am not sure how this symlink appeared. It is creates long time ago (15 May 2005). So, may be it was installed by some package and didn't removed correctly. I don't remember that i created it.