Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
dev-java/jid3-0.46 USE="doc source test" fails on x86 and amd64. FAILURES!!! Tests run: 96, Failures: 14, Errors: 0 * * ERROR: dev-java/jid3-0.46 failed. * Call stack: * ebuild.sh, line 49: Called src_test * environment, line 3911: Called ejunit 'src_test' 'src_test' '-cp' * environment, line 1005: Called die * The specific snippet of code: * java -cp "${cp}" -Djava.awt.headless=true ${runner} "${@}" || die "Running junit failed" * The die message: * Running junit failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/dev-java:jid3-0.46:20080504-145039.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-java/jid3-0.46/temp/environment'. * !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.05" JAVACFLAGS="-source 1.4 -target 1.4" COMPILER="javac" Portage 2.1.4.4 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24.4 i686) ================================================================= System uname: 2.6.24.4 i686 Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz Timestamp of tree: Sun, 04 May 2008 11:30:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind /var/spool/torque" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" PKGDIR="/mnt/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa apache2 berkdb bluetooth branding bzip2 cairo cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde kerberos ldap libnotify mad midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl ssl startup-notification svg tcpd test tiff truetype unicode vorbis win32codecs x86 xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created an attachment (id=151817) [details] build.log The full build log.
Testing with with all the JDKs I have installed: * These failed tests: ibm-jdk-bin-1.5 ibm-jdk-bin-1.6 jamvm sun-jdk-1.6 sun-jdk-1.7 So 1.4 and 1.5 JDKs from Sun seem to be the only ones to work.
(In reply to comment #2) > Testing with with all the JDKs I have installed: > * These failed tests: ibm-jdk-bin-1.5 ibm-jdk-bin-1.6 jamvm sun-jdk-1.6 > sun-jdk-1.7 > > So 1.4 and 1.5 JDKs from Sun seem to be the only ones to work. > Of above ibm 1.5 and 1.6 fail at only a single test "testVisitor". Jamvm, I didn't test yet. Ibm 1.4 and blackdown 1.4.2 also work.
Created an attachment (id=154305) [details] fix the test failuers The problem is caused by the way bytes are UTF encoded before they are written to the header. The author has used String.getBytes("Unicode"). The problem is that "Unicode" is ambiguous. See the javadoc for java.nio.charset.Charset for the various possibilities. The ID3 tag spec requires the use of UTF-16 with byte-order-marks[1], therefore the appropriate string to pass on to the String.getBytes(charsetName) method is "UTF-16". The next problem is that the tests use hard-coded test strings in little endian order with little-endian byte-order marks. The charset javadoc states: "When decoding, the UTF-16 charset interprets a byte-order mark to indicate the byte order of the stream but defaults to big-endian if there is no byte-order mark; when encoding, it uses big-endian byte order and writes a big-endian byte-order mark." Since jid3 does not set the byte order anywhere, it should default to big endian. This patch addresses these problems. It's only been tested on Sun Java 6. [1]http://www.id3.org/id3v2.3.0#head-1a37d4a15deafc294208ccfde950f77e47000bca
Created an attachment (id=154373) [details] Fix the test failures Quick hack to fix the testVisitor failure as well. This patch obsoletes the previous one. Fixing this correctly is going to require examining the test file (v2_3_0tags.mp3) with some other tag-reading software and comparing the output with the output of test visitor. Test visitor reports the tags found in a highly idiosyncratic way which is not very human-readable, so it's probably going to require re-working the way testVisitor reports results as well.
(In reply to comment #5) > Created an attachment (id=154373) [edit] [details] > Fix the test failures > > Quick hack to fix the testVisitor failure as well. This patch obsoletes the > previous one. > > Fixing this correctly is going to require examining the test file > (v2_3_0tags.mp3) with some other tag-reading software and comparing the output > with the output of test visitor. Test visitor reports the tags found in a > highly idiosyncratic way which is not very human-readable, so it's probably > going to require re-working the way testVisitor reports results as well. > After examining the output of the testVisitor the result string (Which means the visit order) differs (Just another combination of charcters) on IBM too. So there seems to be a no portable way to fix this particular test. Indeed, your patch for testVisitor fixed the test for sun java 1.6 breaking 1.5.
That stinks. It means there's probably another bug somewhere. Does 1.5 give the same characters as 1.6, just in a different order?
(In reply to comment #7) > That stinks. It means there's probably another bug somewhere. Does 1.5 give > the same characters as 1.6, just in a different order? > (In reply to comment #6) > (In reply to comment #5) > > Created an attachment (id=154373) [edit] [details] > > Fix the test failures > > > > Quick hack to fix the testVisitor failure as well. This patch obsoletes the > > previous one. > > > > Fixing this correctly is going to require examining the test file > > (v2_3_0tags.mp3) with some other tag-reading software and comparing the output > > with the output of test visitor. Test visitor reports the tags found in a > > highly idiosyncratic way which is not very human-readable, so it's probably > > going to require re-working the way testVisitor reports results as well. > > blackdown 1.4.2,ibm 1.4, sun 1.5 reports the original string. ibm 1.5 reports 3$M+tuywJ=(U[NI)ETOCDrvBKPzQsRSVWL_6*- ibm 1.6 reports 3NKPLUQ_RSBtuv+OCDEI=Trw[VyJs(zM$W)6*- sun jdk 1.6,1.7 icedtea-6 reports the one in your final patch (Passes the test with your final patch)
Created an attachment (id=154511) [details] Fix the test failures Found this hopefully last problem. The author was expecting iteration over a HashMap to happen in a consistent order. This is explicitly disallowed by the contract of the Map interface. Replaced the HashMap with a TreeMap, which implements SortedMap and thus is guaranteed to iterate consistently. The only open question is whether the code or the test was in error. I've assumed the code was wrong and testing for tags in order was what is expected to be the correct behavior. I'll share this patch with upstream if you're happy with it, and hopefully the author can clarify.
(In reply to comment #9) > Created an attachment (id=154511) [edit] [details] > Fix the test failures > > Found this hopefully last problem. The author was expecting iteration over a > HashMap to happen in a consistent order. This is explicitly disallowed by the > contract of the Map interface. Replaced the HashMap with a TreeMap, which > implements SortedMap and thus is guaranteed to iterate consistently. > > The only open question is whether the code or the test was in error. I've > assumed the code was wrong and testing for tags in order was what is expected > to be the correct behavior. I'll share this patch with upstream if you're > happy with it, and hopefully the author can clarify. > The code is is most probably the source of the problem, since the author expects a definite order (included tests on it) and used an Interface that doesn't guarantee that. Sharing the patch with upstream will be very helpful also. Please provide a link if you submit the patch via an issue tracker or forum.
Submitted upstream. Email address is all I found, so no link.
(In reply to comment #11) > Submitted upstream. Email address is all I found, so no link. > Fixed in -r1. Thanks for the patch. Serkan.
