Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 504808 - media-libs/freetype-2.5.3-r1 has wrong harfbuzz multilib dependencies
Summary: media-libs/freetype-2.5.3-r1 has wrong harfbuzz multilib dependencies
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Ben de Groot (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: CVE-2014-2240
  Show dependency tree
 
Reported: 2014-03-16 14:53 UTC by Alexandre Rostovtsev (RETIRED)
Modified: 2014-03-21 07:48 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-03-16 14:53:19 UTC
Since freetype-2.5.3-r1 is a multilibbed ebuild that configures with $(use_with harfbuzz) on all arches, it needs to depend on harfbuzz[truetype,${MULTILIB_USEDEP}], not just harfbuzz[truetype].

This requires removing most of this package.mask:

# Michał Górny <mgorny@gentoo.org> (28 Feb 2014)
# New multilib conversions for testing, grouped with corresponding
# emul-linux bumps. Please unmask in order, after getting ACK from
# package maintainer.
#
# Notes:
# - yngwin explicitly requested 30 days + 1 version bump for cairo.
# - always unmask in order, with emul-linux of choice and *all* packages
# preceding it
>=dev-libs/libgcrypt-1.6.1-r1
dev-libs/libgcrypt:11
>=dev-libs/lzo-2.06-r1
>=app-emulation/emul-linux-x86-baselibs-20131008-r20
>=dev-libs/libxslt-1.1.28-r2
>=app-emulation/emul-linux-x86-baselibs-20131008-r21
>=x11-libs/cairo-1.12.16-r1
>=app-emulation/emul-linux-x86-gtklibs-20131008-r2
>=x11-libs/gdk-pixbuf-2.30.6-r1
>=app-emulation/emul-linux-x86-gtklibs-20131008-r3
>=media-gfx/graphite2-1.2.4-r1
>=media-libs/harfbuzz-0.9.26-r1
>=media-libs/libass-0.11
>=x11-libs/pango-1.36.2-r1
>=x11-libs/pangox-compat-0.0.2-r1
>=app-emulation/emul-linux-x86-gtklibs-20131008-r4


And for this we need an ack from yngwin (why do you need 30 days to review some simple multilib changes?) and openoffice team (for graphite2).
Comment 1 Tomáš Chvátal (RETIRED) gentoo-dev 2014-03-16 15:16:28 UTC
As I told you multiple times.

Do whatever heck you think is correct as I have no better knowledge of the multilib stuff. Just expect yourself to be CCed on multilib bugs if raise.
Comment 2 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-03-16 15:57:03 UTC
As I've already indicated in bug #504544 multilib-enabled harfbuzz ebuild is still p.masked so we cannot simply add multilib dependency on this package in freetype unless we either

  - mask all multilib freetype ebuilds as well
  - unmask harfbuzz and all other depending ebuilds
Comment 3 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-03-16 16:03:52 UTC
(In reply to Lars Wendler (Polynomial-C) from comment #2)

Unmasking multilib harfbuzz is obviously the right solution. Hence this bug report :)
Comment 4 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-03-16 16:13:32 UTC
By the way, as a data point, I've had one of my ~amd64 systems with ABI_X86="32 64" and everything in this mask unmasked since the beginning of March, and haven't seen any problems with the multilibbing.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-03-17 18:10:40 UTC

*** This bug has been marked as a duplicate of bug 504544 ***
Comment 6 Ben de Groot (RETIRED) gentoo-dev 2014-03-21 05:32:04 UTC
As long as this ebuild is masked, this is not resolved at all. We need 2.5.3-r1 to go stable at once, because of security bug #504088. Multilib should not interfere with that.

If the harfbuzz multilib ebuild isn't ready for that yet, then you need to solve this another way.
Comment 7 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-03-21 05:46:55 UTC
(In reply to Ben de Groot from comment #6)

The multilib ebuild for harfbuzz is ready; and multilib ebuilds for libgcrypt, libxslt, gdk-pixbuf, graphite2, libass, pango, and pangox-compat are also ready.

As far as I can see, the only two parts of the mask that haven't been acked yet are lzo and cairo.
Comment 8 Ben de Groot (RETIRED) gentoo-dev 2014-03-21 06:02:56 UTC
(In reply to Alexandre Rostovtsev from comment #7)
> As far as I can see, the only two parts of the mask that haven't been acked
> yet are lzo and cairo.

Cairo multilib certainly isn't ready to go stable. So once again, this needs to be solved another way. Personally, I'd be happy with package.use.mask'ing the harfbuzz useflag for this.
Comment 9 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-03-21 06:19:34 UTC
(In reply to Ben de Groot from comment #8)
> Cairo multilib certainly isn't ready to go stable.

As far as I can tell, stabilizing cairo multilib is not needed; it only needs to be unmasked in ~arch. That will allow emul-linux-x86-gtklibs-20131008-r4 to be unmasked, which will allow harfbuzz-0.9.26-r1 to be unmasked without causing dependency problems in ~arch, and harfbuzz-0.9.26-r1 and fontconfig-2.5.3-r1 can then be stabilized together without cairo.
Comment 10 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-03-21 06:24:09 UTC
(In reply to Alexandre Rostovtsev from comment #9)

To expand on this: harfbuzz uses cairo only for executables, so it doesn't need cairo multilib directly.

The tie between harfbuzz multilib and cairo multilib arises via emul-linux-x86-gtklibs. And for now, it arises only in ~arch, because abi_x86_32 is package.use.stable.masked for emul-linux-x86-gtklibs on amd64.
Comment 11 Ben de Groot (RETIRED) gentoo-dev 2014-03-21 07:48:13 UTC
(In reply to Ben de Groot from comment #8)
> I'd be happy with package.use.mask'ing the harfbuzz useflag for this.

Which is what I ended up doing.