Cannot install icedtea-7.2.5.3. Installation always fails after some minutes at the same point: Error: time is more than 10 years from present: 1104530400000 ... Makefile:345: recipe for target '/mnt/storageData/temp/portage/portage/dev-java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build/lib/currency.data' failed Reproducible: Always Steps to Reproduce: 1.emerge dev-java/icedtea -v Actual Results: Error: time is more than 10 years from present: 1104530400000 java.lang.RuntimeException: time is more than 10 years from present: 1104530400000 at build.tools.generatecurrencydata.GenerateCurrencyData.makeSpecialCaseEntry(GenerateCurrencyData.java:285) at build.tools.generatecurrencydata.GenerateCurrencyData.buildMainAndSpecialCaseTables(GenerateCurrencyData.java:225) at build.tools.generatecurrencydata.GenerateCurrencyData.main(GenerateCurrencyData.java:154) Makefile:345: recipe for target '/mnt/storageData/temp/portage/portage/dev-java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build/lib/currency.data' failed gmake[5]: *** [/mnt/storageData/temp/portage/portage/dev-java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build/lib/currency.data] Error 1 gmake[5]: Leaving directory '/mnt/storageData/temp/portage/portage/dev-java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk/jdk/make/java/java' Makefile:63: recipe for target 'all' failed gmake[4]: *** [all] Error 1 gmake[4]: Leaving directory '/mnt/storageData/temp/portage/portage/dev-java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk/jdk/make/java' Makefile:253: recipe for target 'all' failed gmake[3]: *** [all] Error 1 gmake[3]: Leaving directory '/mnt/storageData/temp/portage/portage/dev-java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk/jdk/make' make/jdk-rules.gmk:92: recipe for target 'jdk-build' failed gmake[2]: *** [jdk-build] Error 2 gmake[2]: Leaving directory '/mnt/storageData/temp/portage/portage/dev-java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk' Makefile:251: recipe for target 'build_product_image' failed gmake[1]: *** [build_product_image] Error 2 gmake[1]: Leaving directory '/mnt/storageData/temp/portage/portage/dev-java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk' Makefile:2219: recipe for target 'stamps/icedtea.stamp' failed make: *** [stamps/icedtea.stamp] Error 2 I have tried to compile with MAKEOPTS="-j1" and with USE="-jbootstrap" with exact same error. Output of emerge --info '=dev-java/icedtea-7.2.5.3::gentoo': ================================================================= Portage 2.2.15 (python 2.7.9-final-0, default/linux/amd64/13.0/desktop/kde, gcc-4.8.4, glibc-2.19-r1, 3.18.1-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.18.1-gentoo-x86_64-AMD_E-350_Processor-with-gentoo-2.2 KiB Mem: 7774972 total, 159612 free KiB Swap: 8388600 total, 7650912 free Timestamp of tree: Sat, 27 Dec 2014 20:30:01 +0000 sh bash 4.2_p53 ld GNU ld (Gentoo 2.24 p1.4) 2.24 ccache version 3.1.9 [disabled] app-shells/bash: 4.2_p53 dev-java/java-config: 2.2.0 dev-lang/perl: 5.18.2-r2 dev-lang/python: 2.7.9-r1, 3.3.5-r1, 3.4.1 dev-util/ccache: 3.1.9-r4 dev-util/cmake: 2.8.12.2-r1 dev-util/pkgconfig: 0.28-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.6, 1.13.4 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.7.4, 4.8.4 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.16 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo E350-local-overlay ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA @FSF-APPROVED dlj-1.1 Oracle-BCLA-JavaSE AdobeFlash-10.3 MakeMKV-EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native -mtune=native -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/easy-rsa /usr/share/gnupg/qualified.txt /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -fomit-frame-pointer -march=native -mtune=native -msse3" DISTDIR="/mnt/storageData/temp/portage/distfiles" EMERGE_DEFAULT_OPTS="--jobs --load-average=8 --autounmask=n" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs candy clean-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://[2001:708:310:54::2]/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ http://gentoo.osuosl.org" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1,--sort-common,--enable-new-dtags" MAKEOPTS="-j -l8" PKGDIR="/usr/portage/packages" PORTAGE_BUNZIP2_COMMAND="pbunzip2" PORTAGE_BZIP2_COMMAND="pbzip2" PORTAGE_COMPRESS="pbzip2" PORTAGE_COMPRESS_FLAGS="-9" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/mnt/storageData/temp/portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" USE="3dnowext X a52 aac ac3 acl acpi alsa amd64 apache apache2 apic apng bash-completion berkdb bmp branding bzip2 c++0x cairo caps cdda cdr cli consolekit cracklib crypt cups cxx dbus declarative dri dts dvd dvdr emboss encode exif fam fbcon firefox flac fortran ftp fuse gd gdbm gdu gif glamor gmp gnutls gpm gtk gtk3 gudev hwdb iconv icu idn ipv6 jpeg kde kipi lcms ldap libnotify linux-threads lto lzma lzo mad mmx mmxext mng modules mp3 mp4 mpeg mpi mpi-threads multilib mysql ncurses nls nptl nptlonly ogg openexr opengl openmp optimized-qmake pam pango pch pcre pdf perl phonon php pic plasma png policykit ppds pulseaudio python python3 qt3support qt4 readline samba sdl semantic-desktop session sharedmem smp sound spell sqlite sqlite3 sse sse2 sse3 ssl ssse3 startup-notification svg tcpd theora threads tiff truetype udev udisks unicode upower urandom usb vala vhosts vorbis webkit2 wxwidgets x264 xattr xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd 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 cgi cgid 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" APACHE2_MPMS="event" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CURL_SSL="gnutls" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_US en_GB sv_SE en sv" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php-5.5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3 python3_4" RUBY_TARGETS="ruby20" USERLAND="GNU" VIDEO_CARDS="radeon vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7 3.3 3.4" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_RSYNC_EXTRA_OPTS, SYNC ================================================================= Package Settings ================================================================= dev-java/icedtea-7.2.5.3 was built with the following: USE="X alsa cups jbootstrap nsplugin nss pulseaudio source webstart -cacao -cjk -debug -doc -examples -infinality -jamvm -javascript -kerberos -pax_kernel (-selinux) -smartcard -sunec -test -zero" ABI_X86="64"
Created attachment 392794 [details] build.log Attached full build.log
I guess you have problems with your clock. Try to run e.g.: ntpdate -b time.ien.it
Same problem for me openbsd with openjdk is affected too http://comments.gmane.org/gmane.os.netbsd.devel.pkgsrc.user/20885 Il will try this patch http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/74a70385c21d
(In reply to Agostino Sarubbo from comment #2) > I guess you have problems with your clock. > > Try to run e.g.: ntpdate -b time.ien.it pop quiz: while compiling some huge bloatware it tells you "Error: time is more than 10 years from present." The likely explanation is: a) your clock b) something else My clock is fine, of course, and I am also affected by the reported bug.
Created attachment 392838 [details, diff] turkish-lira-brand-spanking-new.patch Work-around. Patch designed to illustrate from whence the problem comes, more than to fundamentally fix it. A better fix might be to change the check to 20 years or something like that. This is an upstream bug. I have no idea how to interface with -- or even find -- the upstream responsible for this code. At a glance, icedtea people seem to speak as if they themselves are downstream of some other project, to which this code presumably belongs. Maybe some Oracle thing? No clue, here, I don't "j" much these days.
(In reply to Greg Turner from comment #5) > Created attachment 392838 [details, diff] [details, diff] > turkish-lira-brand-spanking-new.patch > > Work-around. Patch designed to illustrate from whence the problem comes, > more than to fundamentally fix it. A better fix might be to change the > check to 20 years or something like that. > > This is an upstream bug. I have no idea how to interface with -- or even > find -- the upstream responsible for this code. At a glance, icedtea people > seem to speak as if they themselves are downstream of some other project, to > which this code presumably belongs. Maybe some Oracle thing? No clue, > here, I don't "j" much these days. Note, the patch is untested but I'm optimistic. I'll rev. if it doesn't do the trick for me.
Not a bad clock, but bad timing for your build, I'm afraid. I also hit this last night when working on IcedTea 6. The currency file has dates of transition for the various currencies, so that the JDK can switch to using the appropriate currency for that country when the changeover happens. The patch in comment #3 also adds new transitions to the Euro for Latvia and Lithuania. The parser that runs during the build has a check on these dates to make sure they aren't crazy. This does so by checking the date is not over ten years ago. The problem you're hitting here is that, on New Year's Eve 2014, one of the dates became over ten years ago, because it seems that Oracle don't maintain this file too well. The patch in comment #3 will fix it and we'll be including it in 2.5.4. This also affects 6 and there's a whole slew of missing currency updates there which I'm bringing over now. I'll look at getting just this patch added to the ebuild in java-overlay early next week, but you're welcome to try applying it yourselves. That's the one in comment #3 from upstream, not the one in comment #5. As to the relationships mentioned in comment #6, IcedTea is upstream of distros but downstream of Oracle's OpenJDK project, and tries to provide a more usual release process and basically be more like a regular FOSS project. OpenJDK don't make maintained releases, so there's no equivalent of a 2.5.3 release upstream. They have a u60 tree (which is 2.5.0) and they have a tree they're working on now (the one linked to in comment #3) which will eventually be u80, but interim security fixes are just added to these trees and no tarballs are ever cut for them. IcedTea provides that service, allowing distros to avoid a lot of hassle and just pick up a new security release, as you would with other projects. OpenJDK are also slow at accepting patches; I've personally had one pending since early October, which was included in 2.5.3 :( So, we also have fixes on top of what they provide, as users report them.
(In reply to Greg Turner from comment #6) > (In reply to Greg Turner from comment #5) > > Created attachment 392838 [details, diff] [details, diff] [details, diff] > > turkish-lira-brand-spanking-new.patch > > > > Work-around. Patch designed to illustrate from whence the problem comes, > > more than to fundamentally fix it. A better fix might be to change the > > check to 20 years or something like that. > > > > This is an upstream bug. I have no idea how to interface with -- or even > > find -- the upstream responsible for this code. At a glance, icedtea people > > seem to speak as if they themselves are downstream of some other project, to > > which this code presumably belongs. Maybe some Oracle thing? No clue, > > here, I don't "j" much these days. > > Note, the patch is untested but I'm optimistic. I'll rev. if it doesn't do > the trick for me. Doesn't work. The constant comes back like a bad penny somehow. I'll need to figure out where shit is hiding and get back to you all.... The problem comes from code that magically appears during the build, somehow. Probably obvious to anyone who knows a damn thing about this... oh well.
(In reply to Andrew John Hughes from comment #7) > Not a bad clock, but bad timing for your build, I'm afraid. I also hit this > last night when working on IcedTea 6. > > The currency file has dates of transition for the various currencies, so > that the JDK can switch to using the appropriate currency for that country > when the changeover happens. The patch in comment #3 also adds new > transitions to the Euro for Latvia and Lithuania. > > The parser that runs during the build has a check on these dates to make > sure they aren't crazy. This does so by checking the date is not over ten > years ago. The problem you're hitting here is that, on New Year's Eve 2014, > one of the dates became over ten years ago, because it seems that Oracle > don't maintain this file too well. > > The patch in comment #3 will fix it and we'll be including it in 2.5.4. This > also affects 6 and there's a whole slew of missing currency updates there > which I'm bringing over now. > > I'll look at getting just this patch added to the ebuild in java-overlay > early next week, but you're welcome to try applying it yourselves. That's > the one in comment #3 from upstream, not the one in comment #5. Already tried that but, it doesn't apply, at least, not in the way I would usually expect it to for an ebuild.... probably an ignorance issue on my end. > As to the relationships mentioned in comment #6, IcedTea is upstream of > distros but downstream of Oracle's OpenJDK project, and tries to provide a > more usual release process and basically be more like a regular FOSS > project. ACK that, sounds like you're on it, so I'll leave this to the experts and do without for now.
Last time I succesfully compiled icedtea was a week ago when I rebuilt world. Today it didn't compile anymore. My clock is of course fine.
Yeah, because a week ago, 2004-12-31-22-00-00 was still less than ten years ago :) If you have an incomplete build, you can just alter openjdk/jdk/src/share/classes/java/util/CurrencyData.properties in your build tree to remove the bad 2004 line and run ebuild ... compile. That should work. The important change is: -TR=TRL;2004-12-31-22-00-00;TRY +TR=TRY Alternatively, as was suggested on IRC, you could temporarily roll your clock back into 2014... As long as the clock is set before New Year's Eve 2014, it will build fine.
Fixed version of 2.5.3 is in java overlay. No bump as it's only an issue with building; if you already have 2.5.3 built, there's no need to re-install. Java overlay can be obtained from: $ git clone git://git.overlays.gentoo.org/proj/java.git or using layman, if you don't already have it.
The overlay fix works for me. Thanks AJH!
The overlay works for me too. I used icedtea-7.2.5.3.ebuild
Would be nice to have something similar for icedtea-6.
The overlay's ebuild fixed the problem for me too.
Comment on attachment 392838 [details, diff] turkish-lira-brand-spanking-new.patch obsoleted because my patch doesn't do the trick
2.5.4 and 1.13.6 will be out soon, both of which have this fixed.
2.5.4 is out and supported in the overlay: http://bitly.com/it20504
(In reply to Andrew John Hughes from comment #19) > 2.5.4 is out and supported in the overlay: > > http://bitly.com/it20504 Is there any chance that icedtea-7.2.5.4 comes soon to the standard portage tree?
I see the same for dev-java/icedtea-6.1.13.5-r1. It would be nice to get that ebuild (or a newer version in the icedtea:6 slot) working again without need for any overlays.
1.13.6 is now released - http://bitly.com/it11306 - and supported in the overlay. I don't have any commit access to the main tree to fix things there. At the present time, I strongly recommend using the overlay to ensure you're using an up-to-date release without known security issues. Micro releases, where only the final number changes (e.g. 1.13.5->1.13.6 or 2.5.3->2.5.4) usually contain security fixes and also bug fixes we think are important enough to fix now rather than waiting for the next minor release (e.g. 2.5.x -> 2.6.0) Looking at the current main tree: icedtea-6.1.12.7.ebuild icedtea-6.1.13.3.ebuild icedtea-6.1.13.4.ebuild icedtea-6.1.13.5.ebuild icedtea-6.1.13.5-r1.ebuild icedtea-7.2.4.3.ebuild icedtea-7.2.4.7.ebuild icedtea-7.2.4.8.ebuild icedtea-7.2.5.3.ebuild all of these have known security issues, and the 2.4.x and 1.12.x releases have not been supported at all for some time (so you won't be able to file upstream bugs against them). I don't know why so many old versions are being kept around, but running any of these is potentially dangerous, especially if you then use it together with the IcedTea-Web browser plugin.
Any idea who the gentoo maintainer for icedtea is? I use Gentoo for its speedy response to security issues. If all in-tree icedtea ebuilds are prone to security issues, then there is a big problem with my assumptions about Gentoo...:-)
I would like to confirm this bug. I actually had to remove the jbootstrap USE to get this far so that I could find this bug. Please most esteemed sirs, update icedtea.
(In reply to R030t1 from comment #24) > I would like to confirm this bug. I actually had to remove the jbootstrap > USE to get this far so that I could find this bug. > > Please most esteemed sirs, update icedtea. Are you talking about the right issue? jbootstrap has no effect on this. Anyway, you can find 2.5.4 in the java overlay.
*** Bug 535752 has been marked as a duplicate of this bug. ***
I hit this bug again. It is now more than seven weeks after the first report of this bug and it seems me that there is already a solution for seven weeks. But the fixed icedtea does not enter the main portage tree. I do not understand why not.
(In reply to devsk from comment #23) > Any idea who the gentoo maintainer for icedtea is? > > I use Gentoo for its speedy response to security issues. If all in-tree > icedtea ebuilds are prone to security issues, then there is a big problem > with my assumptions about Gentoo...:-) Indeed. If there are security issues I would expect them to show up in a glsa-check. Then again, that is also a task for the security team not necessarily the package maintainers. (I came here because of seeing the issue with 7.2.5.3)
Yes, there are security issues with 2.5.3: https://bugs.gentoo.org/show_bug.cgi?id=537940 http://blog.fuseyism.com/index.php/2015/01/23/security-icedtea-2-5-4-for-openjdk-7-released/ 2.5.4 is in the Java overlay: $ emerge -v layman $ layman -a java
(In reply to Andrew John Hughes from comment #29) > Yes, there are security issues with 2.5.3: > > https://bugs.gentoo.org/show_bug.cgi?id=537940 > http://blog.fuseyism.com/index.php/2015/01/23/security-icedtea-2-5-4-for- > openjdk-7-released/ > > 2.5.4 is in the Java overlay: > > $ emerge -v layman > $ layman -a java And why does 2.5.4 not come into the standard portage tree?
new versions are in the tree now
*** Bug 540848 has been marked as a duplicate of this bug. ***
(In reply to jospezial from comment #31) > new versions are in the tree now And they compile fine for me now
This should have been closed. 7.2.5.5 is now in the tree.
(In reply to James Le Cuirot from comment #34) > This should have been closed. 7.2.5.5 is now in the tree. ...yet so is 7.2.4.8, which is affected by the same problem, so package.mask or fix.
2.4.8 is unsupported and insecure, so should be removed.
Give me a chance, guys. Yes, technically this shouldn't have been closed yet but I doubt anyone other than me is going to try building icedtea on arm, ppc or ia64 any time soon. We're on the verge of dropping Java on ia64 entirely and all my efforts are currently being poured into the other two.
Yeah. I think you're being overly nice with this. If someone really wants this on arm or ppc, I'm sure they'd open a bug report to complain it wasn't keyworded. In fact, dropping 2.4.8 seems like a good way to wake up anyone on these platforms who's still using that version.
For arm at least, it's not quite that simple. Their only other VM is Oracle's and that version is vulnerable as hell. Leaving arm without a VM isn't really an option. I would also need to bump IBM's for ppc because that is also ancient and vulnerable when I actually want to get rid of it.
Yeah I get what you're saying, but what this bug report reminds me is that 2.4.8 won't even build now anyway on any architecture, unless the person either hacks the build or owns a time machine that takes them back to 2014 or earlier.
(In reply to James Le Cuirot from comment #37) > Give me a chance, guys. Yes, technically this shouldn't have been closed yet > but I doubt anyone other than me is going to try building icedtea on arm, > ppc or ia64 any time soon. We're on the verge of dropping Java on ia64 > entirely and all my efforts are currently being poured into the other two. Well, rest assured that you're not the only one trying to build Java on ia64 ;-) I was trying that for several months, as Java is required for LibreOffice (that seems to work fine on my ia64 workstation, although not keyworded ia64). Attempt to upgrade from icedtea-7.2.4.7 (no more in portage tree) to 7.2.4.8 was a constant failure though [1]. But now in 2015, I'm hitting the problem reported here :-S [1] https://bugs.gentoo.org/show_bug.cgi?id=526360 Émeric
7.2.4.8 really is removed now.
