libreoffice has been compiled against version 1.49. boost-1.52.0-r1 has been stablized which cases a mess. Please recompile libreoffice-bin emerge --info Portage 2.2.1 (hardened/linux/amd64, gcc-4.6.3, glibc-2.15-r3, 3.9.9-pentoo x86_64) ================================================================= System uname: Linux-3.9.9-pentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_Q_740_@_1.73GHz-with-gentoo-2.2 KiB Mem: 8151756 total, 6885560 free KiB Swap: 4000148 total, 4000148 free Timestamp of tree: Fri, 20 Sep 2013 12:30:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5-r2, 3.2.5-r2 dev-util/cmake: 2.8.10.2-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8::pentoo sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.10.3, 1.13.4 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo pentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA AdobeFlash-11.x Intel-SDP google-chrome" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" 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 xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j4" 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" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/pentoo" USE="X acl alsa amd64 berkdb bzip2 cli consolekit cracklib crypt cups cxx dbus dri gdbm gpm gtk hardened iconv ipv6 jpeg justify libnotify mmx modules mudflap multilib ncurses nls nptl openmp pam pax_kernel pcre png policykit readline samba session sse sse2 ssl startup-notification tcpd thunar tiff truetype udev unicode urandom xcb 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" 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 ubx" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="vesa vga fbdev radeon" 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: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
Additionally, app-text/poppler-0.22.5:0/37 is now stable, while libreoffice-bin is compiled against :0/35.
Yes we know. We will stabilize a new version of libreoffice soon, and afterwards generate a new libreoffice-bin. Expect it in roughly 2 weeks.
*** Bug 485380 has been marked as a duplicate of this bug. ***
(In reply to Andreas K. Hüttel from comment #2) > Yes we know. I want to know that this is NOT cool. Libreoffice is a very important package for many users and many of us not ready to compile it for 3 hours. Is any way to prevent such situations in future?.. Like, can't you build it in advance and stabilize *together* with dependences?..
s/to know/to let you know/
Well we want to be sure the combination really works... and that involves testing. No point in stabilizing libreoffice and generating libreoffice-bin when immediately afterwards something else is broken. Anyway, your libreoffice-bin should still work fine because of such great features as preserved-libs, and noone forces you to upgrade the libraries immediately. See also http://forums.gentoo.org/viewtopic-t-970672.html
(In reply to Andreas K. Hüttel from comment #6) > and noone forces you to upgrade the libraries > immediately. > > See also http://forums.gentoo.org/viewtopic-t-970672.html <offtopic> well, just FYI: It just happened that I'm installing a *new* gentoo desktop for a friend of mine. I explained to him how cool gentoo is, and all that. Now, I need to explain him all these tricks/workarounds - mask libraries, follow up with bug reports, read forums, or compile for 3 hours. Do you think he is getting exciting about Gentoo??? That's a rhetorical question. </offtopic>
(In reply to Andreas K. Hüttel from comment #6) > > See also http://forums.gentoo.org/viewtopic-t-970672.html Thanks for the link. So why not issuing a "news" item whenever something like this might happen? That may simply tell *-bin user to temporarily mask the libs while waiting for a new bin release...
(In reply to sphakka from comment #8) > (In reply to Andreas K. Hüttel from comment #6) > > > > See also http://forums.gentoo.org/viewtopic-t-970672.html > > Thanks for the link. So why not issuing a "news" item whenever something > like this might happen? That may simply tell *-bin user to temporarily mask > the libs while waiting for a new bin release... Because that's not the way how it supposed to be. The proper way is to create a -r1 in *advance* and stabilize the whole set at the same time. That's how it works with xorg* stuff, for example. The stable user suppose to run "emerge -DNu world" smoothly.
(In reply to Andreas K. Hüttel from comment #6) > Anyway, your libreoffice-bin should still work fine because of such great > features as preserved-libs, and noone forces you to upgrade the libraries > immediately. Boost was stabilized for security issue, so, it's some kind of good forcing, i think :-)
And yes, hit this bug too
*** Bug 485874 has been marked as a duplicate of this bug. ***
So, if I choose to do nothing, updates pile up behind this one as they are released into stable, since it blocks world updates entirely. Some of those may or may not be other security updates. Seems a little narrow to say this is a good move overall. :/ Cheers.
(In reply to Andreas K. Hüttel from comment #6) > Well we want to be sure the combination really works... and that involves > testing. No point in stabilizing libreoffice and generating libreoffice-bin > when immediately afterwards something else is broken. > > Anyway, your libreoffice-bin should still work fine because of such great > features as preserved-libs, and noone forces you to upgrade the libraries > immediately. The problem here is that when you `emerge -uaNDv wordl` you will get blockage like dev-libs/boost:0 (dev-libs/boost-1.52.0-r6::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-libs/boost-1.49.0-r2::gentoo, installed) pulled in by dev-libs/boost:0/0= required by (dev-cpp/libcmis-0.3.1::gentoo, installed) dev-libs/boost:0/0= required by (dev-libs/liborcus-0.3.0::gentoo, installed) =dev-libs/boost-1.49* required by (app-office/libreoffice-bin-4.0.4.2::gentoo, installed) and you are screwed.
welp, not entirely screwed. >=dev-libs/boost-1.50 >app-text/poppler-0.22.2-r2 in package.mask did it for me. (In reply to Jesse Adelman from comment #13) > So, if I choose to do nothing, updates pile up behind this one as they are > released into stable, since it blocks world updates entirely. You can mask those temporarily (see above).
May be a more clear solution here would be to bundle libraries in libreoffice-bin? (I mean bundle the latest stable at the moment of compiling) The fact that libraries are not bundled does not improve security here, even worse, it leads to impossibility to update them to allow other packages use newer version in case of security issues.
(In reply to Jauhien Piatlicki from comment #16) > May be a more clear solution here would be to bundle libraries in > libreoffice-bin? (I mean bundle the latest stable at the moment of compiling) > > The fact that libraries are not bundled does not improve security here, even > worse, it leads to impossibility to update them to allow other packages use > newer version in case of security issues. It would probably add the work of 1. bundling the libs. 2.1. monitoring the bundled libs, so users can be informed there are security issues. Which we currently get for free with a little work for the user (adding a few lines to package.mask if you don't care / uninstall or build from source if you do) 2.2. or not having the security issue notification.
So, I couldn't wait anymore for a new compiled version of libreoffice-bin. Actually, I'm glad to say that libreoffice-bin-4.0.4.2 will work just fine with the new versions of boost and poppler without recompiling. If just changed the dependency in the ebuild and now everything is working.
Created attachment 360926 [details] libreoffice-bin-4.0.4.2-r1.ebuild ebuild with modified dependencies to install the stable libreoffice-bin in combination with the latest stable versions of boost and poppler
*** Bug 489020 has been marked as a duplicate of this bug. ***
Libreoffice might be the single most important application on many systems, but it has been broken for over a month now even though a solution has been known for the entire time (and actually was know before it even broke). Please release a fix a.s.a.p.
(In reply to Jeroen Roos from comment #21) > Libreoffice might be the single most important application on many systems, > but it has been broken for over a month now even though a solution has been > known for the entire time (and actually was know before it even broke). > Please release a fix a.s.a.p. Install app-office/libreoffice?
(In reply to Nuno J. Silva from comment #22) > Install app-office/libreoffice? mask app-office/libreoffice-bin or drop the stable keywords.
(In reply to Anton Bolshakov from comment #23) > (In reply to Nuno J. Silva from comment #22) > > Install app-office/libreoffice? > > mask app-office/libreoffice-bin or drop the stable keywords. Totally agree. If that package is in the stable tree, it needs to play well with other stable packages. If there is no manpower to maintain it, let's mask / remove / keyword it, but if it stays there, it really should be fixed. I hope it will get a bump so that people with older hardware can install libreoffice on gentoo without spending days in compilation time. Thanks to whoever is working on this.
(In reply to bartoz from comment #24) > (In reply to Anton Bolshakov from comment #23) > > (In reply to Nuno J. Silva from comment #22) > > > Install app-office/libreoffice? > > > > mask app-office/libreoffice-bin or drop the stable keywords. > > Totally agree. > If that package is in the stable tree, it needs to play well with other > stable packages. > If there is no manpower to maintain it, let's mask / remove / keyword it, > but if it stays there, it really should be fixed. > > I hope it will get a bump so that people with older hardware can install > libreoffice on gentoo without spending days in compilation time. Thanks to > whoever is working on this. Why exactly can't you install the current libreoffice-bin in your system? The current ebuild, the one which is on the tree, plays well with other stable packages, just not with the newest stable versions of some libraries. Please follow the steps in comment #15.
(In reply to Nuno J. Silva from comment #25) > (In reply to bartoz from comment #24) > > (In reply to Anton Bolshakov from comment #23) > > > (In reply to Nuno J. Silva from comment #22) > > > > Install app-office/libreoffice? > > > > > > mask app-office/libreoffice-bin or drop the stable keywords. > > > > Totally agree. > > If that package is in the stable tree, it needs to play well with other > > stable packages. > > If there is no manpower to maintain it, let's mask / remove / keyword it, > > but if it stays there, it really should be fixed. > > > > I hope it will get a bump so that people with older hardware can install > > libreoffice on gentoo without spending days in compilation time. Thanks to > > whoever is working on this. > > Why exactly can't you install the current libreoffice-bin in your system? > The current ebuild, the one which is on the tree, plays well with other > stable packages, just not with the newest stable versions of some libraries. > > Please follow the steps in comment #15. That's exactly what I have now. It just seems wrong that since app-office/libreoffice-4.1.2.3 has been stable for a while, we still do not have app-office/libreoffice-bin-4.1.2.3, which, if I understand correctly, would work well with all the newest stable packages.
(In reply to bartoz from comment #26) > (In reply to Nuno J. Silva from comment #25) > > Why exactly can't you install the current libreoffice-bin in your system? > > The current ebuild, the one which is on the tree, plays well with other > > stable packages, just not with the newest stable versions of some libraries. > > > > Please follow the steps in comment #15. > > That's exactly what I have now. > It just seems wrong that since app-office/libreoffice-4.1.2.3 has been > stable for a while, we still do not have app-office/libreoffice-bin-4.1.2.3, > which, if I understand correctly, would work well with all the newest stable > packages. Ok, I will run an emerge --sync later and see if there is some new conflict, because I *did* install libreoffice-bin with these lines in package.mask, and it is working so far. libreoffice-bin will always be a difficult package. It has to be built and tested on the gentoo side, and I don't even know how does it work so well, given that it uses C++ libraries. I would definitely *not* try the ideas above about removing the dependencies on lower versions of poppler and boost. These dependencies are there for a reason.
(In reply to Nuno J. Silva from comment #27) > (In reply to bartoz from comment #26) > > (In reply to Nuno J. Silva from comment #25) > > > Why exactly can't you install the current libreoffice-bin in your system? > > > The current ebuild, the one which is on the tree, plays well with other > > > stable packages, just not with the newest stable versions of some libraries. > > > > > > Please follow the steps in comment #15. > > > > That's exactly what I have now. > > It just seems wrong that since app-office/libreoffice-4.1.2.3 has been > > stable for a while, we still do not have app-office/libreoffice-bin-4.1.2.3, > > which, if I understand correctly, would work well with all the newest stable > > packages. > > Ok, I will run an emerge --sync later and see if there is some new conflict, > because I *did* install libreoffice-bin with these lines in package.mask, > and it is working so far. Great, thank you. > > libreoffice-bin will always be a difficult package. It has to be built and > tested on the gentoo side, and I don't even know how does it work so well, > given that it uses C++ libraries. Yeah, I see that. On that side, thanks to everyone who helps maintaining that package. I would definitely *not* try the ideas > above about removing the dependencies on lower versions of poppler and > boost. These dependencies are there for a reason. Sure.
(In reply to bartoz from comment #28) > (In reply to Nuno J. Silva from comment #27) > > > > Ok, I will run an emerge --sync later and see if there is some new conflict, > > because I *did* install libreoffice-bin with these lines in package.mask, > > and it is working so far. > > Great, thank you. Portage shows no conflicts, I can generate an emerge -av libreoffice-bin with no blockers or conflicts.
All done. Please remember to remove any mask files again.
[ebuild UD ] app-text/poppler-0.22.5:0/37 [ebuild UD ] dev-libs/icu-51.1:0/51.1
(In reply to Anton Bolshakov from comment #31) > [ebuild UD ] app-text/poppler-0.22.5:0/37 > [ebuild UD ] dev-libs/icu-51.1:0/51.1 Please don't reopen the old bugs. See bug 490114 instead.
the root cause of this bug is not fixed so I'm reopening. I got tired hitting it again and again with each and every new release
Don't reopen this.
