[javac] ^ [javac] 40 errors [javac] 13 warnings BUILD FAILED /var/tmp/portage/dev-java/netty-transport-4.0.32/work/netty-netty-4.0.32.Final/transport/build.xml:48: Compile failed; see the compiler error output for details. Total time: 4 seconds * ERROR: dev-java/netty-transport-4.0.32::gentoo failed (compile phase): * eant failed * $ cat ./info.txt ----------------------------------------------------------------- This is an unstable amd64 chroot image (named amd64-desktop-unstable_20151004-161203) at a hardened host acting as a tinderbox. ----------------------------------------------------------------- Portage 2.2.23 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop, gcc-4.8.5, glibc-2.21-r1, 4.2.3-hardened-r2 x86_64) ================================================================= System uname: Linux-4.2.3-hardened-r2-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 16166720 total, 2544188 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Tue, 13 Oct 2015 13:45:01 +0000 sh bash 4.3_p42 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 ccache version 3.2.4 [disabled] app-shells/bash: 4.3_p42::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.22.0::gentoo dev-lang/python: 2.7.10::gentoo, 3.4.3::gentoo, 3.5.0-r1::gentoo dev-util/ccache: 3.2.4::gentoo dev-util/cmake: 3.3.2-r1::gentoo dev-util/pkgconfig: 0.29::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.18::gentoo sys-apps/sandbox: 2.9::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r1::gentoo sys-devel/automake: 1.9.6-r4::gentoo, 1.10.3-r1::gentoo, 1.11.6-r1::gentoo, 1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.8.5::gentoo, 4.9.3::gentoo sys-devel/gcc-config: 1.8::gentoo sys-devel/libtool: 2.4.6-r1::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.2::gentoo (virtual/os-headers) sys-libs/glibc: 2.21-r1::gentoo Repositories: local location: /usr/local/portage masters: gentoo gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: 9999 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/stunnel/stunnel.conf /usr/lib64/fax /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0 /var/lib/hsqldb /var/spool/fax/etc /var/yp/Makefile" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/var/tmp/distfiles" EMERGE_DEFAULT_OPTS="--color=n --nospinner --tree --quiet-build --accept-properties=-interactive --accept-restrict=-fetch" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo rsync://mirror.netcologne.de/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gor.bytemark.co.uk/gentoo/ rsync://ftp.snt.utwente.nl/gentoo" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" 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="/var/tmp" USE="X a52 aac acl acpi aes-ni alsa amd64 berkdb bindist bluetooth branding bzip2 cairo cdda cdr cgoups clang cli consolekit cracklib crypt cups curl custom-cflags custom-optimization cxx dbus designer dot dri drmkms dts dvd dvdr emboss encode exif extraengine fam ffmpeg firefox flac fortran fpm gdbm gif git glamor gpm gtk hdf5 iconv imap imlib inifile ipv6 javascript jpeg kerberos kvm lcms ldap libnotify libvirtd logrotate mad mbox mmx mmxext mng mod modules mp3 mp4 mpeg mssql multilib multimedia multitarget mysqli ncurses nls nptl obj objc ogg opengl openmp openmpi pam pango pax_kernel pcre pdf pdo png policykit postgres postscript ppds pwquality qemu qml qt3support qt4 readline scrypt sddm sdl seccomp session spell spice sqlite3 sse sse2 ssl ssse3 startup-notification svg system-cairo system-icu system-jpeg tcpd theora thinkpad tiff truetype udev udisks unicode upower usb usbredir uxa v4l v4l2 vorbis webkit wxwidgets x264 xcb xml xv xvfb xvid xvmc 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" 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" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" 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 en_GB" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" 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" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 414508 [details] dev-java:netty-transport-4.0.32:20151013-152241.log
Created attachment 414510 [details] emerge-history.txt
I am not able to reproduce this failure/issue. dev / # emerge -O -pv netty-common netty-buffer netty-codec netty-transport netty-handler These are the packages that would be merged, in order: [ebuild R ] dev-java/netty-common-4.0.32::gentoo USE="-doc -source" 0 KiB [ebuild R ] dev-java/netty-buffer-4.0.32::gentoo USE="-doc -source {-test}" 0 KiB [ebuild R ] dev-java/netty-codec-4.0.32::gentoo USE="-doc -source" 0 KiB [ebuild R ] dev-java/netty-transport-4.0.32::gentoo USE="-doc -source" 0 KiB [ebuild U ] dev-java/netty-handler-4.0.32::gentoo [4.0.19::gentoo] USE="-doc -source {-test}" 0 KiB dev / # emerge -O -qC netty-common netty-buffer netty-codec netty-transport netty-handler dev-java/netty-common: 4.0.32 none none dev-java/netty-buffer: 4.0.32 none none dev-java/netty-codec: 4.0.32 none none dev-java/netty-transport: 4.0.32 none none dev-java/netty-handler: 4.0.19 none none dev / # emerge -O -qv netty-common netty-buffer netty-transport netty-codec netty-handler >>> Verifying ebuild manifests >>> Emerging (1 of 5) dev-java/netty-common-4.0.32::gentoo >>> Installing (1 of 5) dev-java/netty-common-4.0.32::gentoo >>> Emerging (2 of 5) dev-java/netty-buffer-4.0.32::gentoo >>> Installing (2 of 5) dev-java/netty-buffer-4.0.32::gentoo >>> Emerging (3 of 5) dev-java/netty-transport-4.0.32::gentoo >>> Installing (3 of 5) dev-java/netty-transport-4.0.32::gentoo >>> Emerging (4 of 5) dev-java/netty-codec-4.0.32::gentoo >>> Installing (4 of 5) dev-java/netty-codec-4.0.32::gentoo
using this java - right ? tinderbox@tor-relay ~ $ sudo chroot amd64-desktop-unstable_20151004-161203 /bin/bash java -version java version "1.7.0_85" OpenJDK Runtime Environment (IcedTea 2.6.1) (Gentoo icedtea-7.2.6.1) OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode) tinderbox@tor-relay ~ $
(In reply to Toralf Förster from comment #2) > Created attachment 414510 [details] > emerge-history.txt According to this history, dev-java/netty-common-4.0.22 and dev-java/netty-buffer-4.0.22 are installed. Currently ebuilds of netty packages depend on other netty packages only with :0 and with no version specifier. I suggest to enforce matching versions. Example for netty-transport: CDEPEND="~dev-java/${MY_PN}-buffer-${PV}:0 ~dev-java/${MY_PN}-common-${PV}:0"
That is one way to go, but normally someone should be updating their system including dependent packages. The only other way they would run into this is mixing ~arch and arch packages which is bad if on a arch system. I have thought about version dependencies for related things and it might not be a bad idea for many things, netty, tomcat, jetty, etc. Though at this time, I am not sure that is favored. Given most do not like to do the hard work to update all and just update pieces. Which is why netty-handler is still at 4.0.19 as it has many deps not packaged required to update it to latest. I suspect that was the case to update it even to 4.0.22, or others.
I think this should be closed as invalid, as a system update was not done, thus other things were not updated to latest. The ebuilds can be modified to be version specific, which others likely Gentoo devs need to make that call for packages across the board. But the only reason this is coming up is trying to emerge a newer package without updating the others first. A normal world update should do this correctly and build them in order as they do depend on each other. So if one has a newer version, the others should be built after if they depend on it.
I agree with Arfrever, we should not allow people to get into this situation.
Created attachment 414684 [details] info.txt maybe the same here ? ----------------------------------------------------------------- This is an unstable amd64 chroot image (named amd64-desktop-unstable_20151004-161203) at a hardened host acting as a tinderbox. ----------------------------------------------------------------- Portage 2.2.23 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop, gcc-4.8.5, glibc-2.21-r1, 4.2.3-hardened-r3 x86_64)
Created attachment 414686 [details] dev-java:netty-buffer-4.0.32:20151016-060948.log
Created attachment 414688 [details] emerge-history.txt
(In reply to James Le Cuirot from comment #8) > I agree with Arfrever, we should not allow people to get into this situation. You agree with people NOT updating their entire system but select packages? This applies to many more than just this ebuild. I look forward to seeing those changes for many other packages... Not to mention I suggested such for Tomcat, and others like Resin but that has not happened. However that is for different reason, that is so you use what they ship with, as you could use say java-virtual/servlet-api and may use say Tomcat servlet-api with Resin and vice versa. Which if that resulted in a bug I doubt upstream would care since your not using their code but another's. Thus that is a completely different scenario, which requires version specific deps. Quite many other packages are this way, most any in tree. You fix by updating your entire system, all dependent packages. Not by requiring a package to depend on a specific version of another. To prevent individual package updates. Which in this case all that would have done is shown the user they needed to update the other packages. Which should have been done with a system update...
I am really curious how this is even happening in the first place. It seems like dependencies are not being updated. If the entire system is ~arch and doing system updates. They should all be updated, and not have such issues. It really does not make much sense, and I cannot replicate. Can anyone else replicate these issues?
(In reply to Toralf Förster from comment #11) > Created attachment 414688 [details] > emerge-history.txt Not seeing netty-common-4.0.32 just netty-common-4.0.22. Which DOES not make sense what so ever. netty-common is the base netty package. The others depend on that or should. Which NOW I see the real issue no one else has caught.... Missing depends.... netty-buffer/netty-buffer is missing DEPEND on netty-common However that is not the case with netty-transport, it does depend on netty-common. How you are able to merge netty-transport-4.0.32 yet your system is not updating netty-common to 4.0.32 as well does not make sense. Even with the missing depend, and if nothing used it. With netty-common-4.0.22 being installed, which is no longer in tree, and only netty-common-4.0.32 remaining, portage should have updated netty-common to current but it did not. Something is off there. Not only is netty-common not being updated on its own by the system reporting problems, it is updating other netty packages to the latest but not updating their own dependent packages to the latest. That really does not make sense. 2 different ways netty-common should be updated but it is not, on its own, and as a dependency of another package being updated.
(In reply to William L. Thomson Jr. from comment #14) > (In reply to Toralf Förster from comment #11) > > Created attachment 414688 [details] > > emerge-history.txt > > Not seeing netty-common-4.0.32 just netty-common-4.0.22. Which DOES not make > sense what so ever. netty-common is the base netty package. The others > depend on that or should. Which NOW I see the real issue no one else has > caught.... Missing depends.... > > netty-buffer/netty-buffer is missing DEPEND on netty-common Actually incorrect, it does depend on that, missed the CDEPEND. So with that said, back to original and other comments. How does netty-transport get updated from 4.0.22 -> 4.0.32, but not the stuff it depends on. Why is netty-transport being updated but not netty-common? Even if the packages were manually merged, added to world. Portage would still update them in the order of DEPEND. Starting with updating netty-common from from 4.0.22 -> 4.0.32. Does not make sense for the other packages to be updated first.
Fixed in 4.0.36.
