[gentoo-commits] gentoo commit in xml/htdocs/proj/en/desktop/qt/logs: qt-project-meeting-20100624.txt

[Alex Alexander (wired)]

wired       10/06/24 21:13:16

  Added:                qt-project-meeting-20100624.txt
  Log:
  Qt Project meeting 2010/06/24

Revision  Changes    Path
1.1                  xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100624.txt

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100624.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100624.txt?rev=1.1&content-type=text/plain

Index: qt-project-meeting-20100624.txt
===================================================================
[21:01:14] <wired> !herd qt
[21:01:14] <willikins> (qt) abcd, ayoy, chiiph, hwoarang, spatz, tampakrap, wired
[21:01:34] <wired> who's here?
[21:01:41] * ABCD is
[21:02:01] *** Joins: pesa (~Pesa@×××××××××××××××××××××××××××××××××××××××××××××××.it)
[21:02:03] * ayoy is
[21:02:08] <pesa> i'm here
[21:02:13] <chiiph> I'm here
[21:02:16] * hwoarang around
[21:02:19] <wired> nice
[21:02:23] <wired> ABCD: ?
[21:02:31] <wired> tampakrap told me he won't be here
[21:02:35] <hwoarang> ok
[21:02:35] <ABCD> <wired> who's here?
[21:02:35] <ABCD> * ABCD is
[21:02:45] <wired> perfect
[21:02:55] <wired> http://gitorious.org/gentoo-qt/pages/Meeting20100624
[21:02:58] <hwoarang> who is logging
[21:03:02] <wired> i am ofc
[21:03:05] <wired> =]
[21:03:22] * wired over 3 mil freenode log lines :p
[21:03:32] <hwoarang> ok lets start
[21:03:35] <wired> so
[21:03:39] <hwoarang> wired^^ lead=chairman
[21:03:40] <wired> 1. qt4-42
[21:03:44] <wired> 1. qt4-r2
[21:03:47] <wired> meh today
[21:04:01] <wired> ok we still have 130 ebuilds using the old eclass
[21:04:10] <pesa> :(
[21:04:13] <wired> I am working on a repoman check
[21:04:17] <hwoarang> indeed we do
[21:04:31] <wired> i have it ready actually
[21:04:32] <chiiph> we can do like Arferer and ping everyone everyday
[21:04:40] <hwoarang> wont work
[21:04:49] <wired> http://paste.pocoo.org/show/229453/
[21:04:51] <hwoarang> i can claim my QA membership and fix them myself
[21:05:01] <hwoarang> without asking
[21:05:02] <wired> this is my repoman patch
[21:05:12] <wired> (results)
[21:05:15] <chiiph> nice
[21:05:17] <hwoarang> wired: excellent
[21:05:26] <wired> i made it generic
[21:05:38] <pesa> great
[21:05:38] <wired> so other people will be able to mark eclasses as deprecated and have repoman warn ppl
[21:05:49] <hwoarang> great job
[21:05:58] <wired> i recommend
[21:06:06] <wired> leaving this warning for July
[21:06:14] <wired> then making repoman fail instead of warn
[21:06:27] <hwoarang> more like August
[21:07:01] <wired> one *extra* month should be enough imo, then in August we make it fail and actively help ppl migrate whats left
[21:07:08] <hwoarang> can i see the code?
[21:07:14] <hwoarang> can we add the deadline on eclass?
[21:07:15] <wired> ofc ppl can still repoman --force, but anyway
[21:07:20] <hwoarang> @DEADLINE: bla bla
[21:07:27] <hwoarang> so repoman can display that as well?
[21:07:45] *** Joins: pesa__ (~Pesa@××××××××××××××××××××××××××××××××××××××××××××××××.it)
[21:07:53] <wired> hmm i'd rather not bloat it (yes, you'll see the code after i make some final changes and create a patch/bug)
[21:08:04] <hwoarang> ok
[21:08:14] <wired> in any case\
[21:08:19] <hwoarang> people wont remember they have 1month to fix it
[21:08:24] <wired> even as a warning this will be annoying
[21:08:33] <hwoarang> bug/patch + announcment
[21:08:36] <wired> and after 1 month they can still commit with --force
[21:08:38] <hwoarang> ok
[21:08:49] <wired> in emergencies :p
[21:09:17] <wired> ok, anyone want to add anything to 1.?
[21:09:27] <chiiph> nope
[21:09:47] * wired waits 1 minute
[21:10:16] <wired> alright then. 2. bugZ!
[21:10:28] <wired> bug #301476
[21:10:31] <willikins> wired: https://bugs.gentoo.org/301476 "QSvgWidget produce segfaults : x11-libs/qt-svg"; Gentoo Linux, Library; ASSI; antonmx@×××××.com:qt@g.o
[21:10:46] <hwoarang> oh my...
[21:10:56] *** Quits: pesa (~Pesa@×××××××××××××××××××××××××××××××××××××××××××××××.it) (Ping timeout: 276 seconds)
[21:11:06] <ayoy> :)
[21:11:09] <wired> we're still nowhere with this
[21:11:22] <hwoarang> indeed
[21:11:36] <wired> a nice idea was thrown on the table, a 1-2 hour hack session to try and kill this
[21:11:41] *** Joins: pesa (~Pesa@×××××××××××××××××××××××××××××××××××××××××××××××××.it)
[21:11:45] <wired> anyone feel like it?
[21:11:51] <hwoarang> i do
[21:11:52] <wired> 21:11:17 (wired) a nice idea was thrown on the table, a 1-2 hour hack session to try and kill this
[21:11:55] <wired> pesa^
[21:11:55] *** Quits: pesa__ (~Pesa@××××××××××××××××××××××××××××××××××××××××××××××××.it) (Disconnected by services)
[21:11:58] <hwoarang> i wonder if it is doable though
[21:12:07] <ayoy> hwoarang: the session or the bug?
[21:12:07] <pesa> my usual network problems :s
[21:12:10] <hwoarang> the bug
[21:12:23] <ayoy> hm, there must be some hack :D
[21:12:33] <wired> tbh i haven't looked at it at all after our last talk
[21:12:46] <ayoy> I've just tested it on my box, and nothing special
[21:12:47] <pesa> wired: ok for me
[21:12:49] <ayoy> fails from time to time
[21:13:00] <wired> you guys want a weekday or in the weekend?
[21:13:03] <wired> =]
[21:13:06] <hwoarang> i kinda did. Seems like there there is a symbol collision for QWidgetPrivate class
[21:13:40] <ayoy> hwoarang: how do you know this?
[21:13:54] <ayoy> because I've investigated Qt libs on Debian with nm
[21:14:09] <ayoy> and QtSvg also defines QWidgetPrivate there
[21:14:16] <hwoarang> i cant reproduce it anymore with latest qt-svg-4.7.9999
[21:14:23] <hwoarang> o_0
[21:14:31] <hwoarang> hwoarang@Mystical ~/svg-issue $ ./a.out 
[21:14:31] <hwoarang> hwoarang@Mystical ~/svg-issue $ 
[21:14:40] <wired> run it like 10 times
[21:14:44] <wired> or 50
[21:14:44] <ayoy> yeah :)
[21:15:19] <pesa> well, nm output means that QWidgetPrivate is needed by libQtSvg, it doesn't mean that it's actually defined there
[21:15:34] <hwoarang> i run it 100 times. It failed 4
[21:15:34] <pesa> the symbol should be resolved at runtime by ld.so
[21:15:36] <ayoy> :) that explains a lot
[21:16:05] <pesa> and it is correctly resolved as far as I could test
[21:16:30] <ayoy> correctly? all the time?
[21:17:02] <pesa> it seemed so when i tried
[21:17:12] <hwoarang> can you paste a test case with nm ?
[21:17:30] <ayoy> hwoarang: it's not valid actually
[21:17:33] <ayoy> nm doesn't help us
[21:17:42] <hwoarang> what about valgrid
[21:17:47] <hwoarang> *valgrind
[21:17:57] <pesa> there's a debug flag for the dynamic linker, i dont remember which now
[21:18:13] <pesa> hwoarang: unfortunately i cannot reproduce at all under valgrind
[21:18:16] <ayoy> hwoarang: for the record, 'nm -D /usr/lib/qt4/libQtSvg.so'
[21:18:31] <wired> it seems a hacking session would really help
[21:18:38] <pesa> yep
[21:18:43] <hwoarang> ok so 
[21:18:44] <hwoarang> when :)
[21:18:45] <ayoy> yeah, and we'll learn something from that for sure
[21:18:47] <wired> so, lets not turn the meeting into that. when do you guys want to?
[21:18:53] <ayoy> weekday plz
[21:18:57] <hwoarang> ok
[21:18:59] <wired> monday?
[21:19:03] <wired> same time?
[21:19:11] <pesa> it depends on when
[21:19:15] <hwoarang> a bit later cause i have soccer training
[21:19:24] <hwoarang> otherwise on thusday
[21:19:25] <pesa> later would be nice for me too
[21:19:25] <wired> i meant this monday
[21:19:26] <ayoy> 19 UTC?
[21:19:32] <hwoarang> more like 20
[21:19:46] <wired> 20UTC monday: fine here
[21:19:50] <ayoy> okay with me
[21:19:58] <hwoarang> wired: thats 23:00 for us right?
[21:20:01] <wired> yeah
[21:20:03] <hwoarang> ok
[21:20:05] <chiiph> may be I'll learn something from the session... i don't think I'll be of much use though... but, yes, any time monday is ok with me...
[21:20:09] <wired> pesa?
[21:20:13] <pesa> ok 
[21:20:14] <hwoarang> fine by me
[21:20:16] <wired> great
[21:20:20] <pesa> it's 22 here i guess
[21:20:26] <ayoy> pesa: right
[21:20:31] <wired> ok thats done
[21:20:37] <hwoarang> i should change the topic on #gentoo-qt so we wont forget
[21:20:40] <wired> i'll send you all a reminder email
[21:20:46] <wired> and add it to google calendar
[21:20:47] <wired> =]
[21:20:50] <pesa> good :)
[21:20:59] <hwoarang> right
[21:21:00] <wired> next bug
[21:21:03] <wired> bug #304971
[21:21:04] <willikins> wired: https://bugs.gentoo.org/304971 "qt-core stores machine-specific information in /usr/share/qt4/mkspecs"; Gentoo Linux, Library; ASSI; ohnobinki@××××××××××××××.net:qt@g.o
[21:21:10] <pesa> next two
[21:21:17] <pesa> thy're related
[21:21:20] <pesa> *they
[21:21:20] <hwoarang> what are we gonna do with these
[21:21:21] <hwoarang> yes
[21:21:24] <ayoy> 304971, shouldn't it be fixed now?
[21:21:24] <wired> right
[21:21:27] <wired> bug #312689
[21:21:30] <willikins> wired: https://bugs.gentoo.org/312689 "x11-libs/qt-core forces additional CFLAGS and CXXFLAGS for dev-python/PyQt4"; Gentoo Linux, Development; NEW; Martin.vGagern@×××.net:qt@g.o
[21:21:38] <hwoarang> ayoy: is it?
[21:21:46] <ayoy> no idea :/
[21:21:51] <pesa> uh?
[21:21:51] <ayoy> those changes I made to qt4-build
[21:21:58] <ayoy> should fix the issue
[21:22:00] <pesa> in portage?
[21:22:09] * hwoarang confused
[21:22:15] <pesa> me too
[21:22:17] <ayoy> good question
[21:22:29] <ayoy> I haven't committed anything to the tree
[21:22:35] <hwoarang> please do :p
[21:22:43] <ayoy> but I made changes to qt4-build and placed it in qting-edge branch
[21:22:43] <pesa> yes please
[21:22:50] <ayoy> then I ported the changes to qt4-build-edge
[21:22:58] <ayoy> for testing with .9999 Qt
[21:23:01] <wired> ayoy: your eclass changes work fine iirc
[21:23:08] <ayoy> I tested it with 4.6.2 as well
[21:23:17] <ayoy> cool, then I'll commit the changes to portage
[21:23:18] <wired> we should push them and finally close the bug :p
[21:23:20] <ayoy> and we're done
[21:23:20] <pesa> at least 312689 must be fixed
[21:23:23] <ayoy> yeah
[21:23:40] <pesa> 304971 is more general though
[21:23:55] <hwoarang> i dont see how can we fix QMAKE_LIBDIR_QT
[21:23:58] <pesa> it's about "machine-specific info"
[21:24:22] <hwoarang> i wonder if we can fix it on qt4-r2 + eqmake4
[21:24:22] <pesa> hwoarang: i dunno if it's even doable
[21:24:27] <hwoarang> to pase this on eqmake4 
[21:24:32] <hwoarang> and erase it from mkspecs
[21:24:37] <pesa> yes
[21:24:44] <pesa> but what about developers?
[21:24:54] <hwoarang> that use pure qmake ?
[21:25:00] <pesa> heh
[21:25:03] <hwoarang> mmmm
[21:25:16] <hwoarang> sneaky
[21:25:17] <pesa> they shouldn't be forced to specify LIBDIR
[21:25:27] <hwoarang> indeed
[21:25:30] <pesa> they'll hate us
[21:25:36] <ayoy> no way
[21:25:48] <ayoy> I think, 1st let's keep the system healthy
[21:26:01] <ayoy> then we can think of formalities, like machine-specific info in share dir
[21:26:10] <pesa> we cannot diverge too much from upstream
[21:26:21] <hwoarang> ayoy: how that would work
[21:26:28] <ayoy> QMAKE_LIBDIR_QT ins not diverging
[21:26:30] <ayoy> *is
[21:26:44] <wired> this looks more like something that upstream should have to change, not us
[21:26:47] <ayoy> I mean, what we need to change, we should change
[21:26:56] <ayoy> it's a normal process of SW integration
[21:27:19] <hwoarang> silly question but why anybody would want /usr/lib32/qt4 on 64bit system
[21:27:19] <pesa> but we dont _need_ to change that
[21:27:33] <pesa> do we?
[21:27:38] <ayoy> so what's the problem with it at all?
[21:27:43] * ayoy is confused now :(
[21:27:43] <pesa> multilib is screwed anyway
[21:27:55] <pesa> their handling of headers is flawed IMHO
[21:27:56] <hwoarang> QMAKE_LIBDIR_QT is set in such a way that compiling 32-bit Qt apps is
[21:27:56] <hwoarang> hard.
[21:28:06] <hwoarang> comment #1
[21:28:19] <hwoarang> compiling 32-bit Qt apps?why?
[21:28:21] <pesa> mmm
[21:28:25] <ayoy> hwoarang++
[21:28:32] <hwoarang> i dont follow
[21:28:45] <pesa> anyway
[21:28:46] <wired> multilib portage maybe
[21:28:56] <hwoarang> furthermore, isnt that what the emul-qt* libs are supposed to do ?
[21:29:04] <wired> thats the... stupid way
[21:29:10] <pesa> the problem is not gentoo-specific
[21:29:22] <hwoarang> well
[21:29:27] <hwoarang> i hardly see a problem here
[21:29:28] <ayoy> isn't it exactly multilib-specific?
[21:29:33] <wired> yeah
[21:29:37] <hwoarang> more like a "feature request"
[21:29:38] <ayoy> you compile Qt on 64-bit, you have lib64
[21:29:52] <ayoy> quite sane :)
[21:29:52] <hwoarang> so you want a Qt compiled in 64bit to compile 32bit apps
[21:29:58] <hwoarang> are you stupid or something?
[21:29:59] <hwoarang> :)
[21:30:13] <ayoy> I'd like to hear from someone that needs it
[21:30:23] <wired> if any :p
[21:30:25] <pesa> i guess debian has the same problems...?
[21:30:30] <ayoy> and if he does, he for sure knows what he does
[21:30:32] <pesa> or other distros
[21:30:41] <ayoy> and he knows how to change QMAKE_LIBDIR_QT to suit him
[21:30:48] <ayoy> that's my point of view...
[21:30:49] <pesa> i mean that the issue should be fixed upstream
[21:30:51] <hwoarang> ok i will ask for clarification why anybody would want a non-default QMAKE_LIBDIR_QT
[21:31:17] <hwoarang> pesa: even upstream wont be able to fix it :)
[21:31:28] <hwoarang> there is no point in using 64bit qmake to build 32bit apps
[21:31:39] <wired> alright, lets see if we can find any real valid reasons to talk about this again
[21:31:41] <hwoarang> build Qt in your home dir and develop you app there 
[21:32:15] <wired> great
[21:32:27] <wired> any other bugs you'd like to talk about not in the agenda?
[21:32:50] <ayoy> not really :P
[21:32:55] <pesa> i'd like to talk about Nokia Qt SDK
[21:33:05] <ayoy> oh
[21:33:14] <chiiph> pesa: is that the "windows installer" like app?
[21:33:18] <pesa> and all that new stuff
[21:33:34] <pesa> it's a lot of things actually
[21:34:01] <pesa> the SDK includes qt-4.6.3, qt-creator, madde, qt-simulator, qt-mobility, ... anything else?
[21:34:19] <hwoarang> like a metapackage :P
[21:34:28] <pesa> yes
[21:35:02] <hwoarang> pesa: is there a source code for that?
[21:35:03] <wired> pesa: go on
[21:35:09] <pesa> but maybe it's more than than, maybe it installs some stuff to glue everything together
[21:35:24] <wired> pesa: are you planning to have a look?
[21:35:31] <pesa> yes definitely
[21:35:38] <wired> great
[21:35:41] <pesa> my question is how should we handle it?
[21:35:49] <hwoarang> what do you suggest
[21:35:49] <ayoy> I wouldn't say that there are sources for the SDK
[21:35:56] <hwoarang> ayoy: yes
[21:36:00] <hwoarang> no sources as I can see
[21:36:05] <pesa> everything is at gitorious
[21:36:07] <ayoy> instead, it's a set of apps and libs put together to ease up working with it
[21:36:12] <ayoy> probably installed to /opt
[21:36:26] <ayoy> pesa: but separate, ain't it?
[21:36:32] <pesa> yes
[21:36:32] <ayoy> I mean, no Nokia Qt SDK repo :)
[21:36:40] <hwoarang> pesa: couldn't we just put the binary in /obt/bin ?
[21:36:41] <chiiph> ayoy: afaik, it installs it in your home dir...
[21:36:43] <hwoarang> :p
[21:36:47] <ayoy> chiiph: lool
[21:36:53] <ayoy> awesome :P
[21:37:02] <wired> lol
[21:37:04] <pesa> i don't mean we should provide an ebuild for it, but something which is equivalent
[21:37:11] <chiiph> ayoy: I downloaded it a while ago, when the beta came out, and that really freaked me out...
[21:37:13] <pesa> something == a set of ebuilds
[21:37:14] <hwoarang> http://qt.nokia.com/downloads/sdk-linux-x11-64bit-cpp -> binary
[21:37:21] <hwoarang> pesa: right
[21:37:29] <hwoarang> we can use a metapackage that pulls them together
[21:37:29] <hwoarang> :)
[21:37:37] <ayoy> ah I see
[21:37:44] <hwoarang> we already have qt/qt-creator/qt-mobility
[21:37:46] <ayoy> but then we shouldn't call it Nokia Qt SDK
[21:37:48] <pesa> we dont have an ebuild for e.g. qt-simulator
[21:38:20] <pesa> only qt-sdk?
[21:38:34] <ayoy> gentoo-qt-sdk(TM) :D
[21:38:35] <chiiph> is qt-mobility in? hmm.. I wonder how much time has passed since I've sync'ed everything...
[21:38:51] <pesa> chiiph: qting-edge only
[21:39:08] <pesa> it still needs some work
[21:39:17] <pesa> and 1.0.1 was released
[21:39:18] <hwoarang> we can have both
[21:39:20] <hwoarang> qt-sdk
[21:39:22] <hwoarang> qt-sdk-bin
[21:39:28] <pesa> hwoarang: sure
[21:39:32] <wired> who wants to work on it?
[21:39:52] <hwoarang> pesa: which packages are missing?
[21:39:54] <hwoarang> qt-simulator?
[21:39:55] <pesa> ah there's another potential issue: i think the nokia sdk has an arm cross-compiler
[21:40:06] <pesa> how should we handle that?
[21:40:07] <ayoy> true
[21:40:19] <hwoarang> :/
[21:40:29] <pesa> can we instruct the meta-ebuild to emerge one using crossdev?
[21:40:31] <ayoy> you see, this is something developers install themselves...
[21:40:39] <ayoy> especially if it wants to install in $HOME :)
[21:40:50] <pesa> ayoy: that's why i asked, im not sure how to proceed
[21:40:53] <ayoy> pesa: this is not the same
[21:40:57] <chiiph> is there a real reason to discuss this sdk? I mean...
[21:40:58] <ayoy> I mean crossdev
[21:41:13] <chiiph> I think we should provide everything separatedly
[21:41:20] <ayoy> IMHO, I see two options
[21:41:25] <chiiph> and everyone manage their setup
[21:41:27] <ayoy> either we install it to /opt
[21:41:31] <ayoy> or leave it alone
[21:41:32] <pesa> chiiph: separate whould be fine IMHO
[21:41:33] <hwoarang> the binary?
[21:41:54] <pesa> the binary SDK i guess
[21:41:58] <ayoy> (concerning this magnificient Nokia Qt SDK)
[21:42:01] <pesa> :)
[21:42:04] <hwoarang> separate ebuilds will require a lot of work and they wont make much sense as separate package
[21:42:19] <hwoarang> who would want  symbian packags installed on a gentoo system
[21:42:27] <hwoarang> a Qt developer. So use the whole SDK suite
[21:42:32] <ayoy> think of Maemo
[21:42:33] <chiiph> hwoarang: but a meta package for _everything_ will be too much
[21:42:55] <ayoy> or this arm compiler is for Symbian?....
[21:42:58] <chiiph> hwoarang: besides, we can reflect that with useflag deps...
[21:43:04] <hwoarang> chiiph: thats what i am sayng. I think a qt-sdk-bin would be better
[21:43:13] <pesa> ayoy: for maemo i think
[21:43:20] <hwoarang> chiiph: nobody would want them installed in his system
[21:43:24] <ayoy> yeah, that's what I thought
[21:43:33] <hwoarang> if I was a developer i would created a ~/qt-develop folder on my home
[21:43:37] <hwoarang> and do the stuff in there
[21:43:42] <hwoarang> no spamming my system with crap
[21:43:44] <pesa> you still need windows to develop for symbian
[21:43:45] <chiiph> hwoarang: yes, but wouldn't it be a contradiction to have a binary but not the separate modules?
[21:43:45] <ayoy> that's what I'm saying all the time!
[21:44:05] <hwoarang> the binary comes with all the modules embedded
[21:44:19] <hwoarang> why do you want the modules separated since they only make sense when you have the actual binary
[21:44:42] <pesa> well, qt-creator makes a lot of sense on its own :)
[21:44:49] <hwoarang> that one yes
[21:44:56] <chiiph> why? can't I  develop with these modules with vim+console?
[21:44:57] <hwoarang> now i assume the binary is just an installed
[21:45:07] <hwoarang> that will fuck up the whole Qt/qt-creator installation :)
[21:45:08] <wired> lets package whatever we don't have available already and leave the binary
[21:45:10] <hwoarang> *installer
[21:45:20] <pesa> hwoarang: basically you should be right
[21:45:26] <hwoarang> gosh
[21:45:53] <pesa> are we approaching a consensus?
[21:46:00] <hwoarang> do we? :P
[21:46:08] <pesa> we can discuss the matter later
[21:46:15] <pesa> no hurry
[21:46:17] <chiiph> wired++
[21:46:49] <pesa> i'm fine with wired's proposal
[21:47:02] <hwoarang> ok
[21:47:11] <wired> if anyone comes up with a reason we should make an ebuild for the binary
[21:47:15] <wired> we can talk about it again :)
[21:47:17] <pesa> wired: and what about the arm cross-compiler?
[21:47:42] <hwoarang> crossdev
[21:47:51] <wired> pesa: if we can make an ebuild for it, it might be worth it
[21:47:57] <wired> but that needs more research
[21:48:00] <pesa> indeed
[21:48:08] <ayoy> I can dig into it, probably
[21:48:14] <hwoarang> instruct the user to do it 
[21:48:20] <ayoy> I'm doing something around this stuff at work
[21:48:20] <hwoarang> via an elog message on pkg_postinst
[21:48:27] <wired> crossdev is the other solution, but theirs might be... eg more optimized for maemo
[21:48:29] <ayoy> but there we're still using scratchbox
[21:48:46] <ayoy> wired: it is exactly like that
[21:48:59] <wired> then an ebuild would be nice
[21:49:02] <wired> if possible
[21:49:06] <ayoy> or at least Nokia has put their fingers on it
[21:49:11] <ayoy> :)
[21:49:14] <hwoarang> errr
[21:49:20] <hwoarang> shall we use another repo for that?
[21:49:27] <ayoy> I don't think so
[21:49:33] <wired> nah, its nokia stuff
[21:49:37] <wired> Qt stuff ;p
[21:49:41] <ayoy> ;)
[21:49:51] <hwoarang> no i mean so we wont work directly on qting-edge
[21:50:02] <hwoarang> an when we do have a working set of ebuilds we can push them on qting-edge
[21:50:15] <wired> well if you have something totally broken
[21:50:17] <pesa> well, it's an overlay
[21:50:18] <wired> mask it or use a branch
[21:50:20] <ayoy> qting-edge is still kind of a playground, isn't it?
[21:50:22] <ayoy> yeah
[21:50:23] <chiiph> hwoarang: but there are a couple of ebuilds already in qting-edge...
[21:50:30] <hwoarang> ok
[21:50:38] <wired> if users unmask broken ebuilds in an overlay
[21:50:41] <wired> what can we do? ;)
[21:50:42] * hwoarang has to read the git branch manual again
[21:50:44] <pesa> heh :)
[21:50:49] <pesa> ok, i'll finish my ebuild for qt-mobility for now :)
[21:50:59] <wired> great
[21:51:07] <hwoarang> pesa: could you please stop working on qt-mobility and do your quizessssSS???
[21:51:09] <hwoarang> thanks
[21:51:10] <wired> lol
[21:51:11] <pesa> ops
[21:51:12] *** Joins: spatz (~spatz@gentoo/developer/spatz)
[21:51:15] <ayoy> lol
[21:51:15] <pesa> lol
[21:51:15] <ayoy> ;D
[21:51:34] <ayoy> hi spatz :D
[21:51:36] <wired> spatz =]
[21:51:36] <spatz> crap, I forgot (I was studying for an exam I have tomorrow)
[21:51:39] <pesa> hey spatz
[21:51:41] <wired> heh
[21:51:50] <ayoy> gl then :)
[21:51:55] <wired> yeah! go get em
[21:51:58] <spatz> thanks :]
[21:52:00] <wired> lets move to the last point
[21:52:07] <chiiph> I can take a look at qt-simulator... I don't know if anyone else is already with that...
[21:52:10] <pesa> oh good luck spatz!
[21:52:15] <wired> chiiph: please do
[21:52:16] <hwoarang> chiiph: go ahead
[21:52:17] <hwoarang> hi spatz
[21:52:17] <wired> ;)
[21:52:24] <hwoarang> moving on?
[21:52:25] <chiiph> oks...
[21:52:29] <wired> 3. Re-distribute Qt4 live packages among the members
[21:52:32] <hwoarang> ppl
[21:52:33] <wired> im not sure
[21:52:39] <wired> re-distribute is the right word
[21:52:46] <hwoarang> you get the point :P
[21:53:03] <hwoarang> more members should start testing these versions
[21:53:09] <hwoarang> cause I wont be able to do it in 2 months
[21:53:15] <wired> well
[21:53:17] <hwoarang> so they will be abandoned
[21:53:25] <wired> who's using live ebuilds now?
[21:53:28] <hwoarang> i do!
[21:53:29] <wired> besides hwoarang ?
[21:53:33] <wired> :D
[21:53:38] <ayoy> fail :)
[21:53:41] <hwoarang> why ppl dont use them
[21:53:43] <wired> nice
[21:53:45] <hwoarang> they are rock stable
[21:53:48] <hwoarang> and Sput
[21:53:48] <wired> ok
[21:53:50] <chiiph> I could use them...
[21:53:51] <ayoy> yeah, I have to start
[21:53:55] <hwoarang> an a couple of user in forums
[21:53:56] <wired> we have sput and a few other -kde users that do the testing for us
[21:54:02] <ayoy> I need a stable machine for work
[21:54:09] <hwoarang> ayoy: qt.4.7.9999 is stable
[21:54:09] <ayoy> well, somewhat stable ofc :)
[21:54:11] <hwoarang> 4.6.9999 too
[21:54:12] <hwoarang> :P
[21:54:20] <ayoy> hwoarang: I know, I know
[21:54:28] <ayoy> I'm about to switch to 4.7.9999 soonish
[21:54:32] <hwoarang> people dont have to test stable-branch
[21:54:33] <hwoarang> it is old
[21:54:34] <ayoy> and I can stay there
[21:54:36] <wired> i might switch one of my chroots
[21:54:40] <hwoarang> can who cares about it anyway
[21:54:46] <wired> to live ebuilds
[21:55:13] <wired> that reminds me
[21:55:20] <wired> hwoarang: since stable-branch is like relic-branch
[21:55:27] <wired> hwoarang: lets make -stable-branch the default
[21:55:35] <hwoarang> ok
[21:56:02] <wired> alright
[21:56:16] <wired> if i start using any live ebuilds
[21:56:22] <wired> i'll let you guys know
[21:56:29] <hwoarang> please update the page
[21:56:30] <wired> in any case, i try to fix bugs for live ebuilds when reported
[21:56:35] <wired> hwoarang: (yeah)
[21:56:46] <hwoarang> http://gitorious.org/gentoo-qt/pages/Qt4%20live%20ebuilds
[21:57:02] <hwoarang> plus
[21:57:07] <hwoarang> there is this tracker
[21:57:07] <hwoarang> http://bugs.gentoo.org/show_bug.cgi?id=313619
[21:57:10] <hwoarang> for live ebuilds
[21:57:14] <hwoarang> thats all
[21:57:25] <hwoarang> and this page
[21:57:26] <hwoarang> http://dev.gentoo.org/~hwoarang/qt/qt4-live-status
[21:57:29] <hwoarang> for the status of live ebuilds
[21:57:32] <hwoarang> we are done !
[21:57:33] <wired> great
[21:57:35] <wired> i think thats all
[21:57:42] <wired> thank you all :)
[21:57:46] <wired> --- meeting done ---