[21:04:00] <ayoy> guys, sorry but I'll have to leave in around 45 mins
[21:04:30] <wired> meh :)
[21:04:39] *** Joins: chiiph (~chiiph@gentoo/developer/chiiph)
[21:05:03] <tampakrap> pesa-r2: per your mail, i am available next week, but keep in mind (in case you don't do a review session with me) that your ebuild quiz also needs a final look
[21:05:19] <pesa-r2> tampakrap: yes of course
[21:06:41] <wired> great
[21:06:52] <wired> lets get started
[21:06:58] <pesa-r2> sure
[21:07:28] <wired> https://gitorious.org/gentoo-qt/pages/Meeting20110407
[21:07:39] <wired> 1. qgtkstyle
[21:07:54] <wired> so, I put the style back into qt-gui
[21:08:10] <wired> this means we have a circular dep
[21:08:32] <wired> but now the damn thing works properly again and builds even if cairo[qt4] is present
[21:08:57] <wired> the split made some apps segfault in certain conditions
[21:09:24] <pesa-r2> yeah... really nasty issue
[21:09:59] <wired> im wondering whether we should sed out the -l/usr/include/qt4/QtGui as well
[21:10:03] <wired> bug #361277
[21:10:05] <willikins> wired: https://bugs.gentoo.org/361277 "x11-libs/qt-gui-4.7.2: takes -I/usr/include/qt4/QtGui but shouldn't"; Gentoo Linux, Ebuilds; NEW; strufkin:qt
[21:10:16] <pesa-r2> i think so
[21:10:36] <wired> it could be the reason bug #360433 exists as well
[21:10:39] <willikins> wired: https://bugs.gentoo.org/360433 "x11-libs/qt-gui-4.7.2 fails to compile with GCC 4.5.2 and 4.4.5"; Gentoo Linux, Library; NEW; jules.mandalay:qt
[21:10:39] <pesa-r2> there are old headers there
[21:10:43] <wired> yeah
[21:11:28] <tampakrap> sure
[21:11:55] <wired> so we'll sed it out unconditionally
[21:12:00] <tampakrap> seems reasonable
[21:12:05] <wired> great
[21:12:06] <pesa-r2> yep
[21:12:15] <chiiph> fine with me, yes
[21:12:44] <wired> ok.
[21:12:46] <wired> i'll do it
[21:13:21] <wired> if anyone thinks of a better idea to handle this (and the circular dep), shout :P
[21:13:44] <wired> 2. 4.7 stabilization
[21:13:46] <pesa-r2> well we don't have any solutions for the circular dep, do we?
[21:13:59] <wired> pesa-r2: not unless we find a way to split it again
[21:14:08] <pesa-r2> or split cairo?
[21:14:11] <wired> or that
[21:14:15] <wired> haven't looked into that
[21:14:45] <pesa-r2> is this a high priority thing?
[21:15:11] <tampakrap> for new installations yes
[21:15:14] <wired> it is important
[21:15:15] <pesa-r2> i'm wondering if users are able to manage and workaround circular deps
[21:15:40] <wired> i don't think it is a showstopper, we've had circular deps before, but it's definately annoying
[21:15:50] <wired> one idea i've had was to rename the gtk use in qt-gui
[21:15:53] <wired> to gtkstyle
[21:15:55] <tampakrap> circular deps are considered a bug
[21:16:03] <pesa-r2> i see
[21:16:16] <wired> that way most first installations won't hit the circular dep (at least initially)
[21:16:19] <pesa-r2> wired: mmm that's nice
[21:17:06] <tampakrap> well, i don't think i like that rename
[21:17:08] <pesa-r2> it'll affect a much lower number of users
[21:17:42] <wired> tampakrap: it will help because as soon as you have cairo installed, you're safe to enable it
[21:17:56] <wired> also users *will* notice that this useflag is making portage complain
[21:18:10] <wired> while +gtk isn't that obvious (cause you enable it globally)
[21:19:03] <wired> also, gtkstyle sounds better than gtk, the use flag enables support for a style, it doesn't make qt gtk :P
[21:19:11] <chiiph> imo, we should go for the rename until someone comes up with a better solution
[21:19:20] <tampakrap> fair enough
[21:19:50] <ayoy> +1 on that
[21:19:58] <wired> excellent
[21:20:11] <wired> I'll do that as well
[21:20:11] <ayoy> gtk useflag doesn't mean anything most of the time..
[21:20:18] * wired notes it down
[21:20:27] <pesa-r2> ok
[21:20:57] <wired> onwards to 2. 4.7 stabilization
[21:21:04] <wired> i think 4.7.2 is a fine target
[21:21:28] <tampakrap> yes please we need it for kde as well
[21:21:48] <tampakrap> if you guys don't mind i'd like the stabilization to happen along with kde, plus a bunch of kde/qt misc apps
[21:22:06] <wired> tampakrap: current stable kde not working ok with qt 47?
[21:22:21] <tampakrap> no idea
[21:22:27] <tampakrap> i don't want to risk it though
[21:22:38] <chiiph> tampakrap: when will this happen?
[21:22:49] <tampakrap> 30 days from today
[21:22:59] <chiiph> then fine with me :)
[21:23:26] <wired> im not 100% sure its a good idea to stable everything together
[21:23:43] <ayoy> plus, does kde really have issues with qt-4.7?
[21:23:55] <ayoy> I'd say they're developing it using 4.7
[21:23:57] <ayoy> that's for sure :)
[21:24:24] <tampakrap> they developed >kde-4.5 with qt 4.7
[21:24:29] <tampakrap> current stable is 4.4
[21:24:39] <ayoy> ah
[21:24:43] <pesa-r2> quite old indeed
[21:25:28] <tampakrap> plus, noone in our team (and maybe noone in the earth) tested kde 4.4 with qt 4.7
[21:25:30] <pesa-r2> probably no one has ever tested it with qt 4.7
[21:25:34] <tampakrap> plus the apps
[21:25:38] <wired> ic
[21:25:44] <wired> ok then
[21:26:04] <tampakrap> either way, for kde stabilization we have a large list
[21:26:10] <tampakrap> *already
[21:26:38] <wired> do we need a tracker for 4.7 stabilization?
[21:26:40] <tampakrap> ok, thank you guys, i'll handle that and keep you up-to-date
[21:26:52] <tampakrap> yes we do, and fast
[21:27:04] <tampakrap> if someone could do that for me would be great
[21:27:20] <tampakrap> i'm spending all my gentoo time in kde recently due to the big stabilization
[21:27:58] <pesa-r2> we have bug #325589 already
[21:28:00] <willikins> pesa-r2: https://bugs.gentoo.org/325589 "[TRACKER] Qt-4.7 Regressions"; Gentoo Linux, Library; NEW; hwoarang:qt
[21:28:31] <wired> indeed, with only two bugs open
[21:28:36] <wired> ironically, one is kde 4.4 related
[21:28:37] <wired> ;p
[21:29:02] <tampakrap> yeah, do we have a tracker for the qt itself though?
[21:29:11] <wired> and the other one is just a use flag dep short of being fixed
[21:30:00] <tampakrap> (and ignore the plasma-workspace bug from that tracker)
[21:30:02] <wired> tampakrap: I don't see any showstopper bugs, assuming bug 360433 is going to be fixed by fixing bug 361277
[21:30:04] <willikins> wired: https://bugs.gentoo.org/360433 "x11-libs/qt-gui-4.7.2 fails to compile with GCC 4.5.2 and 4.4.5"; Gentoo Linux, Library; NEW; jules.mandalay:qt
[21:30:20] <tampakrap> ok then
[21:31:12] <pesa-r2> and what about bug #362189 ?
[21:31:13] <willikins> pesa-r2: https://bugs.gentoo.org/362189 "[QA] x11-libs/qt-declarative install some libs into /usr/imports"; Gentoo Linux, Ebuilds; NEW; alexxy:qt
[21:31:24] <pesa-r2> it's qml stuff
[21:31:44] <tampakrap> with a quick look i see a few bugs that could be fixed beofre the stabilization though
[21:32:10] <wired> tampakrap: true, there are some bugs that could be fixed, I was referring to showstoppers :)
[21:32:22] <tampakrap> yeah no blocker
[21:32:24] <tampakrap> *s
[21:32:33] <wired> pesa-r2: pft, why is that going there :P
[21:32:44] <pesa-r2> upstream default
[21:33:47] <ayoy> fail
[21:34:26] <wired> I wonder how easy it would be to move them to a better place
[21:34:43] <pesa-r2> IIRC there's a variable for that
[21:34:53] <pesa-r2> QT_IMPORT_DIR or something like that
[21:35:00] <ayoy> yeah
[21:35:08] <wired> pesa-r2: wanna take a look at it then? :)
[21:35:21] <pesa-r2> sure ;)
[21:35:25] <wired> great, thanks
[21:35:43] <wired> so, perhaps we can create a tracker for things we'd *like* to get fixed in the next 30 days before stabilization
[21:35:53] <wired> anyone want to do that?
[21:35:58] <chiiph> ugh, I have to run... sorry guys, I'll read the backlog when I come back :S
[21:36:12] <wired> chiiph: meh^2 :P ok, cya, thanks :)
[21:36:18] <pesa-r2> see you chiiph 
[21:36:26] <wired> maybe we'll have chiiph make the tracker
[21:36:30] <wired> as punishment for leaving
[21:36:30] <wired> :P
[21:36:34] <pesa-r2> lol
[21:36:40] <ayoy> btw
[21:36:41] <ayoy> QT_INSTALL_IMPORTS:/usr/imports
[21:36:45] <ayoy> qmake -query
[21:36:55] <wired> :)
[21:36:56] <ayoy> set on compile time I guess
[21:36:59] <pesa-r2> yeah that one
[21:37:10] *** mschiff_ is now known as mschiff
[21:37:47] <pesa-r2> we have a dedicated function in qt4-build.eclass to set those vars
[21:37:59] <ayoy> yup, right
[21:38:42] <wired> ok
[21:38:49] <wired> we can continue and fix this in the bug
[21:38:59] <pesa-r2> ok great
[21:39:14] <wired> so who wants to create the tracker?
[21:39:48] <ayoy> :)
[21:40:10] <wired> ayoy: that meant "me, please", right? :P
[21:40:28] <ayoy> I'd say it that way I suppose :P
[21:40:28] <scarabeus> wired: you are lead, DELEGATE
[21:40:33] <scarabeus> :D
[21:40:40] <wired> scarabeus: rotfl
[21:40:51] <ayoy> scarabeus: outta here :P
[21:41:12] <ayoy> no, but seriously, I don't feel knowledgeable enough
[21:41:13] <wired> scarabeus: you have to play it smart, make them think they chose it themselves
[21:41:17] <ayoy> regarding latest issues
[21:41:49] <tampakrap> ok, but please adjust severity in each bug, especially blockers
[21:42:47] <wired> ayoy: create the bug and we'll all help
[21:42:56] <ayoy> yeah
[21:42:57] <ayoy> :P
[21:43:00] <wired> ayoy: we'll talk about some bugs today too anyway
[21:43:07] <wired> k lets get going
[21:43:13] <ayoy> sure, just keep the backlog
[21:43:22] <ayoy> as I'm leaving about now
[21:43:25] <ayoy> just before I leave
[21:43:32] <ayoy> there's one bug I'd like to say a word about
[21:43:35] <wired> shoot
[21:43:57] <ayoy> bug 347868
[21:43:58] <willikins> ayoy: https://bugs.gentoo.org/347868 "x11-libs/qt-core installs useless(?) env.d file"; Gentoo Linux, Library; NEW; davidepesa:qt
[21:44:06] <ayoy> we already tried to do this once upon a time :)
[21:44:11] <ayoy> and we failed like shit
[21:44:27] <pesa-r2> ah
[21:44:28] <ayoy> don't know if anything changed since then (a year ago?)
[21:44:37] <pesa-r2> only a year ago?
[21:44:42] <pesa-r2> i don't remember
[21:44:47] <ayoy> me neither
[21:44:55] <ayoy> but I was removing 44at4 :)
[21:44:58] <ayoy> *44qt4
[21:44:59] <ayoy> :)
[21:45:09] <ayoy> and wired was putting it back iirc :)
[21:45:31] <pesa-r2> i'll look at the commit messages
[21:45:50] <pesa-r2> do you remember why we failed?
[21:46:06] <pesa-r2> i.e. why was it still needed?
[21:46:09] <ayoy> no idea actually
[21:46:14] <wired> i can't remember either
[21:46:31] <ayoy> it would seem like some installations didn't respect rpath
[21:46:31] <ayoy> o_O
[21:46:56] <ayoy> ok, have to go now
[21:47:02] <ayoy> see you guys
[21:47:13] *** Quits: ayoy (~ayoy@gentoo/developer/ayoy) (Read error: Connection reset by peer)
[21:47:16] <wired> ok thanks ayoy. leave a comment in the bug if you have anything
[21:47:17] <wired> meh
[21:47:17] <pesa-r2> ok thanks ayoy! see you!
[21:47:22] <wired> heh
[21:48:10] <wired> okie
[21:48:34] <wired> tampakrap: whats the state of the live ebuilds?
[21:48:53] <tampakrap> same, never found time to deal with them
[21:49:17] <wired> are you planning to?
[21:49:52] <tampakrap> yes, i have a build server in my basement that need to fire up
[21:49:56] <tampakrap> going to do it soon
[21:50:09] <wired> ok, thanks
[21:50:12] <pesa-r2> wow
[21:50:18] <pesa-r2> :D
[21:50:55] <wired> 4. qting-edge location
[21:51:14] <wired> now that tampakrap is in infra, he wants to assimilate our overlay
[21:51:15] <wired> :P
[21:51:28] <tampakrap> exactly
[21:51:44] <tampakrap> i find it embarrasing that it is still hosted in !gentoo-infra
[21:51:49] <wired> well
[21:52:56] <wired> qting-edge is on gitorious (and github) because when yngwin created it he didn't want to rely on infra
[21:53:56] <wired> I don't really care where the overlay is
[21:54:29] <tampakrap> thanks, i'll handle it
[21:54:30] <wired> tampakrap: we could start by dropping github and double-pushing to gitorious and gogo for a while
[21:54:33] <tampakrap> and announce it
[21:54:39] <tampakrap> sure
[21:54:52] <tampakrap> and please drop the kde overlay github clone as well
[21:54:57] <wired> sure
[21:55:58] <wired> ok, thats settled
[21:57:19] <wired> bug 352778
[21:57:21] <willikins> wired: https://bugs.gentoo.org/352778 "x11-libs/qt-core: mkspecs/common/g++.conf overrides upstream QMAKE_CFLAGS_RELEASE"; Gentoo Linux, Development; NEW; realnc:qt
[21:57:38] <pesa-r2> meh
[21:59:09] <tampakrap> yeah, why?
[21:59:12] <tampakrap> interesting bug
[21:59:18] <pesa-r2> no, it's not
[21:59:23] <pesa-r2> i'm tired
[21:59:44] <wired> heh
[21:59:49] * tampakrap scratches head
[21:59:50] <pesa-r2> we change that some time ago because of some users requested it
[21:59:52] <tampakrap> i'm missing something
[22:00:03] <pesa-r2> now other users want the old behaviour back
[22:01:35] <pesa-r2> i've always been unsure about that issue
[22:02:26] <wired> so qt specifies -O2 by default
[22:02:34] <pesa-r2> yes
[22:02:40] <wired> and we strip that to allow users to decide
[22:02:47] <pesa-r2> correct again
[22:02:51] <wired> since bug 312689
[22:02:55] <willikins> wired: https://bugs.gentoo.org/312689 "x11-libs/qt-core forces additional CFLAGS and CXXFLAGS for dev-python/PyQt4"; Gentoo Linux, Development; RESO, FIXE; Martin.vGagern:qt
[22:03:23] <wired> I say we stick to that
[22:03:31] <wired> if users want -O2 in out-of-portage builds
[22:03:36] <wired> they should specify it
[22:04:03] <wired> unless there's a way to strip the default -O2 only in portage builds
[22:04:08] <tampakrap> ok i read the old bug and now i get it
[22:05:11] <pesa-r2> well, i changed my mind a few times on this, and now i think we should keep upstream defaults in mkspecs, i.e. vanilla mkspecs
[22:05:46] <pesa-r2> at the same time we must respect users' CXXFLAGS from make.conf for portage builds
[22:06:10] <pesa-r2> stripping mkspecs wasn't the right solution
[22:06:48] <wired> sounds like we should be ignoring mkspecs in portage
[22:06:51] <tampakrap> may i ask why nokia specifies -O2 by default?
[22:06:54] <pesa-r2> actually packages using eqmake4 are already totally safe
[22:07:06] <tampakrap> if nokia is wrong, we could file a bug to digia?
[22:07:26] <wired> pesa-r2: what about PyQt then?
[22:07:34] <pesa-r2> that's because of sip
[22:07:38] <pesa-r2> sip is horribly broken
[22:07:44] <pesa-r2> and upstream doesn't care
[22:07:54] <pesa-r2> i told Phil multiple times already
[22:08:10] <wired> can't we patch sip instead of stripping mkspecs for one package?
[22:08:26] <pesa-r2> yes, that would be a better solution
[22:09:21] <wired> can you have a look at this? :)
[22:09:44] <pesa-r2> i already spent many hours on these things...many months ago
[22:09:49] <pesa-r2> i don't remember the details
[22:10:15] <pesa-r2> i for sure want to fix it properly, but i don't have enough time right now
[22:11:00] <wired> ok. i'll try to give this a look, check it out as well if you get the time
[22:11:11] <pesa-r2> patching sip won't be trivial
[22:11:32] <pesa-r2> imho it's low priority though
[22:11:43] <wired> indeed
[22:11:50] <pesa-r2> we have more important bugs to fix
[22:12:40] <pesa-r2> does cmake look at mkspecs btw?
[22:13:02] <tampakrap> scarabeus: ^^
[22:13:27] <scarabeus> what where
[22:13:51] <scarabeus> it can do whatever they write into the cmakelists
[22:13:58] <scarabeus> but i have no clue what pykde does
[22:14:04] <scarabeus> i gracefully ignore kdebindings
[22:14:10] <pesa-r2> i'd like to know if cmake extracts CXXFLAGS from mkspecs
[22:14:39] <pesa-r2> well kdelibs is the same i guess
[22:15:46] <pesa-r2> anyway, we can discuss later about this
[22:16:58] <wired> okie
[22:17:14] <wired> bug 361303
[22:17:16] <willikins> wired: https://bugs.gentoo.org/361303 "CFLAGS="-pipe" is added arbitrarily when eqmake4 is called by qt4-r2.eclass"; Gentoo Linux, Eclasses and Profiles; NEW; ago:qt
[22:18:00] <pesa-r2> mkspecs again
[22:18:09] <pesa-r2> no wait
[22:18:33] <pesa-r2> mmm...
[22:18:51] <pesa-r2> well i dunno
[22:19:43] <pesa-r2> he does not say why he thinks that -pipe is injected by eqmake4 -.-
[22:20:16] <wired> well, i just reproduced this with qbittorrent
[22:20:18] <wired> fun
[22:21:05] <pesa-r2> yes i guess it's easy to reproduce
[22:21:27] <pesa-r2> can you reproduce also using plain qmake?
[22:22:36] <tampakrap> and how about another app? qtwitter for example?
[22:24:37] <wired> replaced eqmake4 with qmake4, same thing
[22:25:04] <pesa-r2> you mean in the ebuild?
[22:26:26] <wired> also tried building it manually from source, -pipe is there
[22:26:37] <pesa-r2> wtf
[22:27:07] <pesa-r2> now the question is: -pipe is added because it's hardcoded somewhere, or because you compiled qt (or something else) using -pipe and it propagates everywhere?
[22:30:18] * wired searching
[22:32:36] <wired> pesa-r2: it's in the mkspecs
[22:33:15] <pesa-r2> o_O
[22:33:28] <pesa-r2> yeah but eqmake4 should override those flags
[22:33:40] <wired> it doesn't
[22:33:46] <wired> I just commented it out and it went away
[22:33:53] <pesa-r2> mmm
[22:34:15] <pesa-r2> this might be a behavior change in 4.7
[22:34:45] <pesa-r2> or even in 4.6 and no one noticed before
[22:34:57] <pesa-r2> i'm sure it was working when i wrote eqmake4
[22:36:52] <wired> meh
[22:37:00] <pesa-r2> wired: can you leave a short comment about mkspecs in the bug so we don't forget? thanks :)
[22:37:08] <wired> yeah, I will :)
[22:37:12] <pesa-r2> ty
[22:37:35] <wired> final bug in the list: bug 359391
[22:37:37] <willikins> wired: https://bugs.gentoo.org/359391 "qt4-build.eclass should check for --buildpkgonly before downgrade sanity check"; Gentoo Linux, Eclasses and Profiles; NEW; konovalov.alexey:qt
[22:38:25] <wired> not sure how this would help, in the end he may be able to build qt-core, but not the rest
[22:43:37] <pesa-r2> well, if he uses only binpkgs on that host... he doesn't care about building
[22:44:08] <pesa-r2> it's a valid use case 
[22:45:53] <wired> pesa-r2: still, how is he going to build qt-gui-4.6.3 for example if qt-core-4.6.3 is not installed?
[22:46:39] <pesa-r2> he builds the packages on another machine
[22:46:53] <wired> he's complaining about --buildpkgonly
[22:47:08] <pesa-r2> ops sorry
[22:47:36] <pesa-r2> :P
[22:47:40] <wired> :P
[22:48:44] <wired> see my point now? :p
[22:50:02] <pesa-r2> yes, i was thinking about another scenario, sorry
[22:50:43] <wired> so, the bug is valid in a sense
[22:50:44] <wired> but moot
[22:50:45] <wired> ;p
[22:51:03] <pesa-r2> indeed
[22:51:43] <pesa-r2> maybe he thinks that e.g. qt-gui-4.6.x binpkg can be built against qt-core-4.7.x
[22:52:07] <wired> or just doesn't understand that qt-gui-4.6 would fail against 4.7
[22:52:08] <wired> ;p
[22:52:34] <pesa-r2> it would fail of course
[22:53:10] <wired> i guess we should wontfix with an explanation
[22:53:16] <pesa-r2> or maybe he just needs qt-core O_o
[22:54:28] <wired> doubtful
[22:54:56] <wired> i'll ask him what his intentions are
[22:55:00] <wired> and we'll go from there
[22:55:09] <pesa-r2> yeah
[22:55:25] <wired> great
[22:55:28] <wired> that sums it up
[22:55:57] <pesa-r2> wait
[22:56:04] <pesa-r2> bug 359081
[22:56:07] <willikins> pesa-r2: https://bugs.gentoo.org/359081 "x11-libs/qt-sql-4.7.2 fails to build with --param in flags"; Gentoo Linux, Library; NEW; bircoph:qt
[22:56:07] <wired> any bugs you want to talk about?
[22:56:33] <pesa-r2> the reporter is clearly a ricer :P
[22:57:21] <pesa-r2> he says that CFLAGS are used at link-time
[22:57:46] <wired> what the heck
[22:57:47] <pesa-r2> but i think that's true only for a very limited subset of flags
[22:57:59] <pesa-r2> e.g. -flto
[22:58:13] <pesa-r2> LTO == link time optimization
[22:59:27] <pesa-r2> anyway, the qmake bug might be valid
[22:59:36] <pesa-r2> but it should be fixed upstream imho
[23:00:54] <wired> hmm
[23:01:10] <wired> we could ask him to report it :P
[23:01:19] <pesa-r2> yep
[23:03:44] <wired> ok
[23:03:46] <wired> any other bugs?
[23:04:06] <wired> oh, btw, x11-libs/qt is x11-libs/qt-meta now
[23:04:24] <pesa-r2> cool
[23:04:35] <wired> and I wanted to ask you guys, can you think of any reasons why we shouldn't ditch old 4.7 ebuilds?
[23:05:24] <wired> tampakrap: you once asked me to wait, any reason why I should keep waiting? :)
[23:05:38] <tampakrap> to wait what?
[23:06:01] <wired> im talking about removing old 4.7.x versions
[23:06:11] <tampakrap> ah
[23:06:13] <tampakrap> yes go on
[23:06:24] <wired> last time we talked about it you wanted to keep them for kde testing or something
[23:06:27] <wired> kk
[23:06:32] <tampakrap> yeah
[23:06:58] <wired> great
[23:07:43] <wired> if noone wants to add anything, summary will be available soon-ish - I'll also send an email to arrange another meeting before the stabilization
[23:07:47] <wired> thank you for being here
[23:08:11] <pesa-r2> thank you! :D
[23:10:01] *** wired changes topic to 'Gentoo meetings | nothing at the moment :)'