Summary: | dev-java/commons-cli-1.1 fails to emerge on --update | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Willard Dawson <willard.dawson> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | clmason, morten, palglowr, perry, tetromino, uzytkownik2 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 217448 | ||
Bug Blocks: | |||
Attachments: |
Build log
Even more verbose build log, as requested. |
Description
Willard Dawson
2008-04-01 01:24:39 UTC
(In reply to comment #0) > Emerge --update for dev-java/commons-cli produces numerous build errors. > Attach full build.log please. Created attachment 147989 [details]
Build log
Full build log
So are people CCing themselves here because they are seeing this too? I couldn't reproduce and neither could another dev. (In reply to comment #2) > Created an attachment (id=147989) [edit] > Build log > > Full build log > Please attach an even more verbose build log produced with JAVA_PKG_DEBUG=1 emerge -1 commons-cli Created attachment 148153 [details]
Even more verbose build log, as requested.
(In reply to comment #5) Almost identical build log here (the only difference is because I have USE=doc). And I am getting the same failure. Please post output of: ls -la /usr/share/ant-core/lib (In reply to comment #7) > Please post output of: > ls -la /usr/share/ant-core/lib $ ls -la /usr/share/ant-core/lib/ total 1288 drwxr-xr-x 2 root root 83 2007-11-28 16:40 . drwxr-xr-x 4 root root 54 2007-11-28 16:40 .. -rw-r--r-- 1 root root 16357 2007-11-28 16:40 ant-bootstrap.jar -rw-r--r-- 1 root root 1289260 2007-11-28 16:40 ant.jar -rw-r--r-- 1 root root 11719 2007-11-28 16:40 ant-launcher.jar lrwxrwxrwx 1 root root 30 2008-01-30 01:49 junit.jar -> /usr/share/junit/lib/junit.jar Hm seems like current stable junit-3.8.1-r3 really still installs this symlink. Should get the 3.8.2 stable ASAP. Also the problem happens only when mixing arch and ~arch. (In reply to comment #9) > Should get the 3.8.2 stable ASAP. > Also the problem happens only when mixing arch and ~arch. I have junit-3.8.2 (newest is 3.8.2-r1). I am purely ~amd64, not mixing arches. However, if I run 'emerge -pv world --update --deep --tree --with-bdeps=y', the junit upgrade is not in the list. It looks like it was pulled in by some package a year ago, but is no longer depended on by anything. I have to ask, if junit is being used when building commons-cli, why isn't it listed in DEPEND? If junit was in DEPEND, I would have known to upgrade to a working version... (In reply to comment #10) > > I have to ask, if junit is being used when building commons-cli, why isn't it > listed in DEPEND? > The bug happens when the build system detect junit installed on your system and tries to use it. This should not happen with the ~arch version of junit. (In reply to comment #11) > (In reply to comment #10) > > > > I have to ask, if junit is being used when building commons-cli, why isn't it > > listed in DEPEND? > > > > The bug happens when the build system detect junit installed on your system and > tries to use it. This should not happen with the ~arch version of junit. > Which doesn't really answer Alex' question ... and to be sure: "me, too". Actually, when I do emerge -uDN junit I get quite a bunch of updates that haven't been shown when updating world. (In reply to comment #12) > Which doesn't really answer Alex' question ... and to be sure: "me, too". OK so I will answer the question explicitly. (In reply to comment #10) > I have to ask, if junit is being used when building commons-cli, why isn't it > listed in DEPEND? It's not used for building, it's used only for testing (which we don't perform yet anyway, no src_test I think). However the build system tries to be smart and detect junit availability, in which case it starts to build tests. And because detecting uses ant's run classpath, and building uses a different classpath (without junit), detecting succeedes but building fails. The difference with ~arch junit is that it no longer appears on ant's classpath unless the ebuilds want it to be there (which it doesn't). > Actually, when I do emerge -uDN junit I get quite a bunch of updates that > haven't been shown when updating world. Yeah that's how portage works, if nothing in world points (directly or indirectly) to a package, it won't get updated... Sadly this also means that even if we stabilize the ~arch junit, some people will still get this breakage. So either we use the eclass function to sanitize the <available> task, or block on the older junit versions? I droped the 'test' ant target to only compile. src_unpack() { unpack "${A}" sed -e 's/depends="compile,test"/depends="compile"/'\ -i "${S}/build.xml" } For testing, I guess that it is needed adding jars around junit to WORKDIR and write src_test(), right? (In reply to comment #14) This works for me (I using ACCEPT_KEYWORDS="x86 ~x86"). Older versions of junit blocked in commons-cli-1.1 *** Bug 248299 has been marked as a duplicate of this bug. *** |