Needed by 32-bit apps that depend on Qt
*** Bug 503276 has been marked as a duplicate of this bug. ***
From bug 503276: This is needed by net-dns/avahi (and is useful for net-im/skype). @qt: I'm looking at working on a patch, but there's a few deps that need to be converted first
@qt: could you tell me what your preferences on multilib are? New eclass? Explicit 'QT_MULTILIB=yes' switch in ebuilds? Ugly ${PV} based auto-switch?
Can you wait a couple of weeks? I'm implementing some major packaging changes in qt-4.8.6 that are needed before we can get qt5 into the tree. And I believe these changes will also facilitate multilib support.
(In reply to Davide Pesavento from comment #4) > Can you wait a couple of weeks? I'm implementing some major packaging > changes in qt-4.8.6 that are needed before we can get qt5 into the tree. And > I believe these changes will also facilitate multilib support. Could you be a bit more precise? 'Couple of weeks' sounds like a lot :). 2-3 weeks, sure. More than that, I'm not sure since lack of converted qt is stalling some of multilib work. I'm most worried about half-done packages such as avahi or cairo that I'd rather finish soon.
I should be able to commit it masked in ~1 week, then allow 1 or 2 more weeks for testing.
Sounds good. Feel free to contact multilib@ anytime, and we'll be happy to review whatever you've got in multilib perspective. In any case, please try to build the eclass on top of multilib-minimal.
So.. what's the recommended way of dealing with USE flags that don't work on some ABIs? (e.g. USE=jit on x32)
(In reply to Davide Pesavento from comment #8) > So.. what's the recommended way of dealing with USE flags that don't work on > some ABIs? (e.g. USE=jit on x32) package.use.mask in feature profile
Err... how would that work?
(In reply to Davide Pesavento from comment #10) > Err... how would that work? It wouldn't... the current recommendation (so far as I understand it) is to silently (or loudly, if you prefer) disable the unusable flags for just the ABIs they cannot be used with.
(In reply to Jonathan Callen from comment #11) > It wouldn't... the current recommendation (so far as I understand it) is to > silently (or loudly, if you prefer) disable the unusable flags for just the > ABIs they cannot be used with. Yeah I came to the same conclusion. AFAICS that's the only way to do it in the current multilib framework...
oh, right, we're on a bug about multilib. don't mind me, I'm just being dumb.
Yeah, USE=jit sounds like 'use JIT whenever possible'. So, enable it on matching ABIs, disable otherwise. Plus p.u.mask on profiles that can't have it enabled on any ABI.
Also, I don't think any special verbosity would make sense. Missing JIT support on an ABI is not something user could fix, and requesting USE=-jit wouldn't be helpful since user would then lose JIT completely.
qtwebkit needs multilib support in media-libs/gstreamer:0.10 and media-libs/gst-plugins-base:0.10
qtsql needs multilib support in dev-db/firebird, dev-db/freetds, virtual/mysql, dev-db/libiodbc, dev-db/postgresql-base
qtphonon needs media-libs/gstreamer:0.10 and media-plugins/gst-plugins-meta:0.10
qtdemo needs media-libs/phonon (which in turn needs qtcore, qtdbus, qtgui, and designer)
(In reply to Davide Pesavento from comment #16) > qtwebkit needs multilib support in media-libs/gstreamer:0.10 and > media-libs/gst-plugins-base:0.10 As I've already mentioned, I hope to have most of gstreamer done this week. (In reply to Davide Pesavento from comment #17) > qtsql needs multilib support in dev-db/firebird, dev-db/freetds, > virtual/mysql, dev-db/libiodbc, dev-db/postgresql-base I think it would be best to disable most of those in non-native ABIs for now. AFAIK mysql is WiP for some time but others are still waiting for love :).
(In reply to Michał Górny from comment #20) > (In reply to Davide Pesavento from comment #17) > > qtsql needs multilib support in dev-db/firebird, dev-db/freetds, > > virtual/mysql, dev-db/libiodbc, dev-db/postgresql-base > > I think it would be best to disable most of those in non-native ABIs for > now. AFAIK mysql is WiP for some time but others are still waiting for love > :). Agreed. The vast majority of revdeps just needs sqlite anyway.
Is there a bug for media-libs/phonon conversion? (In reply to Michał Górny from comment #20) > (In reply to Davide Pesavento from comment #17) > > qtsql needs multilib support in dev-db/firebird, dev-db/freetds, > > virtual/mysql, dev-db/libiodbc, dev-db/postgresql-base > > I think it would be best to disable most of those in non-native ABIs for > now. AFAIK mysql is WiP for some time but others are still waiting for love > :). What's the recommended way of doing this? multilib_is_native_abi?
(In reply to Davide Pesavento from comment #22) > Is there a bug for media-libs/phonon conversion? I thought it'd be done as part of qt. But if you like, I can convert it straight away :). > (In reply to Michał Górny from comment #20) > > (In reply to Davide Pesavento from comment #17) > > > qtsql needs multilib support in dev-db/firebird, dev-db/freetds, > > > virtual/mysql, dev-db/libiodbc, dev-db/postgresql-base > > > > I think it would be best to disable most of those in non-native ABIs for > > now. AFAIK mysql is WiP for some time but others are still waiting for love > > :). > > What's the recommended way of doing this? multilib_is_native_abi? Yes. Plain dependency (without MULTILIB_USEDEP) + multilib_is_native or one of multilib_native_use*.
(In reply to Michał Górny from comment #23) > (In reply to Davide Pesavento from comment #22) > > Is there a bug for media-libs/phonon conversion? > > I thought it'd be done as part of qt. But if you like, I can convert it > straight away :). > > > (In reply to Michał Górny from comment #20) > > > (In reply to Davide Pesavento from comment #17) > > > > qtsql needs multilib support in dev-db/firebird, dev-db/freetds, > > > > virtual/mysql, dev-db/libiodbc, dev-db/postgresql-base > > > > > > I think it would be best to disable most of those in non-native ABIs for > > > now. AFAIK mysql is WiP for some time but others are still waiting for love > > > :). > > > > What's the recommended way of doing this? multilib_is_native_abi? > > Yes. Plain dependency (without MULTILIB_USEDEP) + multilib_is_native or one > of multilib_native_use*. Given that none of multilib_native_use* are helpful with Qt's ./configure, you may want to create a function in the eclass like: qt_native_use() { multilib_is_native_abi && qt_use "$@" || echo "-no-${2:-$1}" }
(In reply to Michał Górny from comment #23) > (In reply to Davide Pesavento from comment #22) > > Is there a bug for media-libs/phonon conversion? > > I thought it'd be done as part of qt. But if you like, I can convert it > straight away :). > Technically it's maintained by kde (both upstream and the gentoo package), although it doesn't have any kde dependencies. @kensington, would you and the rest of the kde team mind if we carried a multilib-aware version of m-l/phonon in the qt overlay until the conversion is completed?
(In reply to Davide Pesavento from comment #25) > (In reply to Michał Górny from comment #23) > > (In reply to Davide Pesavento from comment #22) > > > Is there a bug for media-libs/phonon conversion? > > > > I thought it'd be done as part of qt. But if you like, I can convert it > > straight away :). > > > > Technically it's maintained by kde (both upstream and the gentoo package), > although it doesn't have any kde dependencies. > > @kensington, would you and the rest of the kde team mind if we carried a > multilib-aware version of m-l/phonon in the qt overlay until the conversion > is completed? Please do. :-)
It would be nice to convert dev-db/libiodbc to multilib, otherwise we'll be forcing everyone to use unixODBC in qtsql
(In reply to Davide Pesavento from comment #27) > It would be nice to convert dev-db/libiodbc to multilib, otherwise we'll be > forcing everyone to use unixODBC in qtsql Sure. Done.
Qt 4.8.6 in tree.
And unmasked on amd64/hppa/x86 (for now). The rest will follow after keywording dev-qt/qtchooser in bug 529196. Closing. Thanks everyone!
Should we reuse this bug for qt5 multilib (needed by Sni-qt via libdbusmenu-qt) or will there be another bug for that?
(In reply to Manuel Rüger from comment #31) > Should we reuse this bug for qt5 multilib (needed by Sni-qt via > libdbusmenu-qt) or will there be another bug for that? I'd prefer if you opened a new bug.
(In reply to Michał Górny from comment #32) > (In reply to Manuel Rüger from comment #31) > > Should we reuse this bug for qt5 multilib (needed by Sni-qt via > > libdbusmenu-qt) or will there be another bug for that? > > I'd prefer if you opened a new bug. +1
