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

[Ben de Groot (yngwin)]

yngwin      12/07/01 15:28:43

  Added:                qt-project-meeting-20120701.txt
  Log:
  Add today's meeting. Update link to FAQ.

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

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

Index: qt-project-meeting-20120701.txt
===================================================================
Qt project meeting IRC logs 2012-07-01
timestamps are UTC+8

[21:00:38] <yngwin> !herd qt
[21:00:39] <willikins> (qt) abcd, hwoarang, johu, kensington, pesa, spatz, wired, yngwin
[21:00:43] -*- johu here
[21:00:43] <yngwin> time for meeting
[21:01:04] <yngwin> agenda at https://gitorious.org/gentoo-qt/pages/Meeting20120701
[21:01:11] <yngwin> who else is here?
[21:02:08] <yngwin> ABCD?
[21:03:00] <johu> yngwin: lets wait 10-15 mins
[21:03:43] <yngwin> yeah we can wait a little
[21:04:43] <yngwin> i'll fire up mpd
[21:06:46] <johu> mpd?
[21:08:05] <yngwin> media-sound/mpd: The Music Player Daemon
[21:08:31] <yngwin> the best thing since sliced bread
[21:09:40] <johu> will check it out
[21:10:04] <johu> the sliced bread i mean :P
[21:10:09] <yngwin> :p
[21:11:18] <yngwin> maybe kensington is an hour late again :p
[21:12:34] <johu> maybe
[21:13:17] -*- yngwin is listening to OSI - Free
[21:14:33] <yngwin> johu: any comments on anything thats on the agenda?
[21:15:05] <johu> yngwin: yes lets wait for more participants
[21:16:25] <johu> a meeting with 2 guys out of 8 make no sense to me
[21:16:31] <yngwin> no indeed
[21:17:01] <yngwin> i'll see if anyone else turns up by 1400 utc
[21:17:23] <yngwin> otherwise we'll move to email
[21:19:16] <johu> ok about "2. qt4.eclass deprecation", i think there is nothing to discuss
[21:19:27] <johu> wait for the stabilization of the new vlc
[21:19:59] <johu> and announce removal of qt4.eclass afterwards
[21:20:04] <johu> on -dev
[21:20:26] <yngwin> iirc there is a mandated 6 month waiting period
[21:21:12] <johu> yeah follow the rule, no problem by me
[21:21:31] <yngwin> maybe we should ask QA what the exact procedure is
[21:23:11] <yngwin> oh wait, it's in http://devmanual.gentoo.org/eclass-writing/
[21:23:33] <johu> 30 days
[21:23:42] <yngwin> not too bad
[21:23:43] <johu> i was on that page in this moment too
[21:23:54] <yngwin> :)
[21:24:30] <johu> sould be marked @DEAD lready
[21:24:35] <johu> already
[21:25:07] <yngwin> we still have vlc-1.1.3 in stable for minor arches
[21:25:20] <yngwin> .13*
[21:25:41] <yngwin> ... waiting for those slackers again
[21:26:22] <yngwin> maybe we should just mask vlc-1, that seemed to help with qt-4.6 :)
[21:26:37] <johu> hehe
[21:29:51] <yngwin> i pinged the alpha guys
[21:30:06] <yngwin> sparc still doesnt have stable qt, so they cant move on this
[21:42:53] <pesa> here I am
[21:42:57] <pesa> sorry for being late
[21:43:34] <yngwin> at least you told us you were probably not gonna make it
[21:43:55] <yngwin> johu: qt4.eclass already has @DEAD and @DEPRECATED
[21:44:21] <pesa> yngwin: yeah, and I had one more unexpected issue 15 minutes before the meeting :/
[21:44:35] <yngwin> oh?
[21:45:21] <pesa> wrt qt4.eclass, we're waiting for vlc, then we can announce and remove it
[21:45:31] <johu> wait up to 1400 utc maybe kensington is showing up?
[21:45:44] <yngwin> pesa: yeah, waiting for alpha and ppc64
[21:45:55] <kensington> damnit
[21:46:01] <yngwin> ah there he is
[21:46:05] <pesa> :)
[21:46:08] <johu> yngwin: start with roll call
[21:46:09] <johu> :)
[21:46:11] <kensington> sorry guys
[21:46:12] <yngwin> ok, 4 ppl
[21:46:15] <yngwin> we can start
[21:46:28] <pesa> good
[21:46:30] -*- johu is here
[21:46:39] -*- pesa here
[21:46:48] -*- yngwin here
[21:46:53] -*- kensington waves
[21:46:56] <yngwin> 1. Qt5 progress
[21:47:02] <yngwin> already has lots of notes
[21:47:07] <yngwin> anything to add?
[21:47:25] <pesa> I've written something on the agenda, any questions?
[21:47:57] <johu> me hadnt look to the qt5 stuff so far
[21:48:05] <johu> so have no clue at all
[21:48:20] <pesa> one thing to add: I'm considering having 2 different eclasses: qt5-base and qt5-module
[21:48:47] <yngwin> if you think that helps, sure, why not
[21:48:48] <pesa> because the build system for qtbase is somewhat different from the other modules
[21:48:59] <pesa> e.g. only qtbase has configure
[21:49:27] <pesa> and I'm afraid that qt5-build might become a mess if not split
[21:49:35] <yngwin> yeah makes sense then
[21:49:43] <pesa> ok
[21:49:48] <kensington> is qt5 slotted?
[21:49:57] <yngwin> yes
[21:50:00] <pesa> it is
[21:50:05] <johu> hopefully :D
[21:50:16] <kensington> cool, I will build it then
[21:51:05] <yngwin> anything else?
[21:51:39] <yngwin> 2. qt4.eclass deprecation
[21:52:05] <johu> *read above, before roll call*
[21:52:45] <yngwin> as we already said, we're just waiting for the last minor arches to mark vlc-2 stable, then we can progress with the 30 day announcement and removal as per the devmanual
[21:53:04] <pesa> yep
[21:53:09] <kensington> good to finally see it gone :)
[21:53:09] <yngwin> alternatively, we could help them by masking vlc-1
[21:53:59] <yngwin> anyone in favor?
[21:54:11] <pesa> I'm not in a hurry
[21:54:33] <yngwin> ok, let it die slowly then
[21:54:42] <yngwin> 3. qt4-r2.eclass updates
[21:55:32] <yngwin> since cmake also wants something of our translation handling, and possibly other build systems, i am proposing to make a generic translations.eclass
[21:55:32] <pesa> I've seen some discussion on -dev but it quickly faded away
[21:55:39] <yngwin> yeah
[21:55:43] <yngwin> i have some ideas
[21:55:51] <yngwin> just need to find the time to write them out
[21:56:00] <pesa> great
[21:56:00] <kensington> I definitely would like to see this, happy to help
[21:56:40] <johu> if you find a general solution this would be awesome
[21:56:42] <yngwin> basically i want some functions to filter langs / linguas, then provide convenience functions a la for_each_translation_do
[21:57:07] <yngwin> then each build system can do their own final handling
[21:57:25] <pesa> aaaaaah yes! nice solution
[21:57:39] <yngwin> or even ebuilds for really specific things
[21:57:45] <pesa> yes yes
[21:58:16] <pesa> +1 from me
[21:58:19] <yngwin> most of the uglyness is then handled in the eclass
[21:58:38] <kensington> only problem is, for most random applications, they all do it differently
[21:58:59] <johu> thats the major porblem
[21:59:02] <pesa> yes but at least you should be able to remove the loops from those ebuilds
[21:59:18] <yngwin> but the major ugliness is the cross-section of package provided translations and LINGUAS
[22:00:20] <yngwin> we can have some default handling for cmake and qmake in our eclasses, but ebuild specific solutions are also possible with things like for_each_translation_do() 
[22:00:38] <pesa> indeed
[22:01:10] <yngwin> ok, i will whip something up in the coming week
[22:01:23] <johu> nice
[22:01:25] <pesa> thanks
[22:01:27] <yngwin> then we can discuss it and RFC to dev ml
[22:02:03] <yngwin> ok, 3.2 DOCS
[22:02:20] <yngwin> i havent submitted that yet (it wasnt really assigned to anybody)
[22:02:44] <yngwin> but i did suggest to pesa to just refer to base.eclass documentation
[22:02:44] <pesa> you raised a question about eclass-doc iirc
[22:02:50] <pesa> ah yeah
[22:03:24] <yngwin> so with permission i will change the documentation part, and then submit it
[22:03:31] <pesa> sure, go ahead
[22:03:38] <yngwin> alright
[22:04:05] <yngwin> 4. Qt on exotic arches
[22:04:24] <pesa> surprise :)
[22:04:28] <yngwin> quite
[22:05:18] <yngwin> i'm surprised he hasnt moved on sparc yet
[22:05:25] <yngwin> a few days ago he said:
[22:05:28] <yngwin> <armin76> yngwin: seems like qt-4.8 works well on sparc...except webkit
[22:05:28] <yngwin> <armin76> so i may mark it stable as well
[22:05:43] <pesa> webkit is the issue usually
[22:06:01] <pesa> was dropped for alpha too
[22:06:04] <yngwin> yeah
[22:06:19] <yngwin> too bad we cant have many nice things without webkit, but its something
[22:06:57] <pesa> luckily, we can usually add an USE flag to disable webkit-related things in revdeps
[22:07:03] <yngwin> yep
[22:07:12] <yngwin> so we should be ok moving forward
[22:08:08] <yngwin> so i think we should try contacting armin76 directly, if similar things come up in the future
[22:08:25] <yngwin> and otherwise we know that hardmasking might kick someone into action :)
[22:08:36] <pesa> I'm wondering why alpha@ sparc@ ia64@ don't reply to emails
[22:08:49] <kensington> yeah, I noted earlier that the mask seemed to be causing them some disruption :P
[22:08:51] <yngwin> too overwhelmed maybe
[22:09:10] <pesa> mmm probably
[22:09:28] <johu> understuffed
[22:09:35] <pesa> but I believe that he/they could spend a few seconds to drop us a line about their intentions
[22:09:42] <yngwin> i used to have an alpha box, but i think it had faulty ram, i could never get gentoo installed on it
[22:09:56] <pesa> that may save many hours in masking/unmasking later on
[22:10:00] <yngwin> yeah
[22:10:21] <yngwin> i've found contacting them in their own arch irc channel may be the best way
[22:10:33] <pesa> ah, good to know
[22:11:10] <yngwin> pinging in #-dev doesnt have the same effect
[22:11:40] <yngwin> ok. lets move to 5. Open bugs
[22:11:53] <yngwin> bug #277711 dev-python/PyQt4 fails to build on systems with improved multilib support
[22:11:54] <pesa> hard stuff here :P
[22:11:54] <willikins> yngwin: https://bugs.gentoo.org/277711 "dev-python/PyQt4 fails to build on systems with improved multilib support"; Gentoo Linux, Ebuilds; CONF; tommy:qt
[22:12:05] <pesa> I should investigate again
[22:12:21] <pesa> but that bug is currently hidden
[22:12:34] <pesa> i.e. doesn't happen with current versions
[22:12:36] <yngwin> it doesnt look like multilib is going to make it for eapi5, so no hurry
[22:12:48] <pesa> ok
[22:13:26] <yngwin> if it does go forward, then obviously we want to work with tommy to solve this
[22:13:30] <pesa> I still think that the multilib approach to machine-specific headers is a bit too invasive
[22:13:52] <yngwin> maybe they can refine it
[22:13:58] <pesa> but we don't know of different solutions
[22:14:23] <yngwin> personally i dont see why we should spend so much effort on this
[22:14:35] <yngwin> pure x64 is the future, imo
[22:14:36] <pesa> and I must admit moc is quite limited in its preprocessing capabilities
[22:14:56] <pesa> (not something we can fix downstream though)
[22:15:01] <yngwin> yeah
[22:15:24] <yngwin> ok, lets see then, i dont think there is much else to do right now
[22:15:34] <pesa> ++
[22:15:39] <johu> ++
[22:15:42] <yngwin> bug #423085 new ebuild media-video/qemplayer-12.4 – did anyone test this?
[22:15:44] <willikins> yngwin: https://bugs.gentoo.org/423085 "new ebuild media-video/qemplayer-12.4"; Gentoo Linux, Ebuilds; IN_P; wbrana:qt
[22:16:06] <pesa> nope
[22:16:11] <yngwin> this is upstream submitted and he is very willing to work with us
[22:16:29] <pesa> he's a good guy
[22:16:31] <yngwin> maybe we can get him to switch from scons to cmake or something?
[22:16:40] <pesa> heh that would be ideal
[22:17:44] <yngwin> anyway, if someone can test this, then let me know, and we can put it in gx86
[22:18:18] <yngwin> #414241 Qt 4.8.1 stabilization – waiting for ppc{,64}
[22:18:30] <yngwin> !herd ppc
[22:18:32] <willikins> yngwin: (ppc) halcy0n, jer, josejx, lu_zero, nixnut, ranger, volkmar, xarthisius, xmw
[22:18:32] <johu> i pinged JoseJX already, no answer so far
[22:18:57] <johu> he is the guy who did the qt/kde stuff in the past
[22:18:59] <kensington> ranger seems quite active with ppc stabilisations
[22:19:01] <yngwin> ok, lets try jer/rej too
[22:19:15] <yngwin> !herd ppc64
[22:19:16] <willikins> yngwin: (ppc64) halcy0n, josejx, ranger, xarthisius
[22:19:36] <pesa> ranger is the most active in ppc64 I think
[22:20:00] <yngwin> ok, lets try pinging those guys again
[22:20:51] <yngwin> bug #413789 media-sound/qjackctl-0.3.8 fail to compile with error ‘commitData’ is not a member of ‘QApplication’
[22:20:53] <willikins> yngwin: https://bugs.gentoo.org/413789 "media-sound/qjackctl-0.3.8 fail to compile with error 'commitData' is not a member of 'QApplication'"; Gentoo Linux, Ebuilds; CONF; dominique.michel:qt
[22:21:26] <pesa> eh
[22:21:40] <yngwin> this seems to be a strange one
[22:21:54] <pesa> totally
[22:22:14] <pesa> I've "wasted" hours, but still haven't tracked it down
[22:22:16] <yngwin> but two ppl with the same issue
[22:22:32] <pesa> might be a filesystem issue too
[22:23:37] <pesa> I had a lengthy chat with zmedico about locking of ebuild phases in emerge --jobs but that doesn't seem to be the cause
[22:24:08] <pesa> unless those users disabled locking, which they didn't according to emerge --info
[22:26:14] <pesa> any other ideas?
[22:26:16] <yngwin> ok, so it needs more debugging
[22:26:22] <pesa> well
[22:26:25] <yngwin> let them try 0.3.9 too
[22:26:29] <pesa> I don't know *how* to debug it
[22:26:50] <pesa> no, qjackctl isn't the issue
[22:26:55] <pesa> it's a Qt issue
[22:27:09] <yngwin> you said it may be an fs issue?
[22:27:21] <pesa> yes, fs corruption
[22:27:58] <yngwin> ok, lets not waste too much time
[22:28:00] <pesa> but assuming it's a valid ebuild/eclass issue, that it's a Qt issue
[22:28:12] <pesa> s/that/then/
[22:28:15] <yngwin> yeah
[22:28:23] <yngwin> but if only 2 ppl have the issue...
[22:28:51] <johu> is qjackctl a popular app?
[22:28:51] <yngwin> bug #388207 [qt overlay] Allow building qt-webkit from standalone repo – does anyone want to implement this?
[22:28:53] <willikins> yngwin: https://bugs.gentoo.org/388207 "[qt overlay] Allow building qt-webkit from standalone repo"; Gentoo Linux, Ebuilds; CONF; sputnick:qt
[22:29:13] <yngwin> johu: for jack users, yes, but not that many ppl use jack, afaik
[22:29:22] <pesa> johu: it happens to other apps as well
[22:29:28] <johu> ok
[22:29:33] <pesa> we have another bug report iirc
[22:29:43] <pesa> same root cause imo
[22:29:47] <yngwin> ok
[22:30:25] <yngwin> so anyone willing to take on standalone webkit-qt ?
[22:30:46] <kensington> I'll have a go
[22:30:58] <yngwin> alright
[22:31:02] <pesa> we need that for qt5 anyway
[22:31:12] <yngwin> really?
[22:31:18] <pesa> yep
[22:31:32] <yngwin> ok thats better than maintaining two packages
[22:31:34] <pesa> there's no qt-webkit repo for qt5, it's all upstream
[22:31:49] <pesa> (webkit upstream I mean)
[22:31:54] <yngwin> i understand
[22:32:06] <yngwin> then bug #132029 monkeystudio (new ebuild) – can this go to gx86?
[22:32:07] <willikins> yngwin: https://bugs.gentoo.org/132029 "monkeystudio (new ebuild)"; Gentoo Linux, Ebuilds; CONF; feivelda:maintainer-wanted
[22:32:13] <pesa> dunno
[22:32:28] <yngwin> kensington ?
[22:32:53] <kensington> it looked like a nice package when I last touched it, and quite a few other distros carry it
[22:33:16] <yngwin> so lets do it then
[22:33:29] <pesa> is the build in a good shape atm?
[22:33:32] <pesa> *ebuild
[22:33:39] <yngwin> sunrise reviewed
[22:34:11] <pesa> ok
[22:35:06] <yngwin> at first sight it looks decent
[22:35:15] <yngwin> could benefit from translations.eclass
[22:35:45] <pesa> yep, looks good
[22:35:47] <yngwin> alright
[22:35:50] <yngwin> 6. Open floor
[22:35:58] <yngwin> anything else?
[22:36:56] <yngwin> in the past week i moved some more packages from overlay to gx86
[22:37:05] <johu> yngwin++
[22:37:40] <yngwin> and if anyone is bored, i have a wishlist at the bottom of http://wiki.gentoo.org/wiki/Qt/Desktop
[22:37:59] <yngwin> especially vim-qt, but that may be more involved
[22:38:23] <johu> its a qt frontend for vim?
[22:38:28] <yngwin> yes
[22:38:31] <yngwin> real vim
[22:38:34] <johu> nice
[22:38:38] <yngwin> as in equivalent to gvim
[22:38:48] <tampakrap> a trainee created an ebuild for that
[22:39:06] <yngwin> available anywhere?
[22:39:21] <tampakrap> http://git.overlays.gentoo.org/gitweb/?p=user/Armageddon.git;a=tree;f=app-editors/vim-qt;h=caba31db0c4a4a9aa47a3572ff47e208ef193647;hb=HEAD
[22:39:31] <yngwin> tnx
[22:39:33] <johu> tampakrap: i will review it
[22:39:47] <johu> and move it to qt overlay afterwards
[22:40:03] <tampakrap> I didn't review it extensively, as I gave it to him mostly for training
[22:41:33] <yngwin> i also plan to get an arm device for hacking, so i may be able to test ebuilds on arm in the future
[22:42:03] <yngwin> this one specifically: http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/
[22:42:13] <kensington> I was also interested in arm, but I couldn't get a straight answer out of the arch team about what is involved for them
[22:43:31] <kensington> so if you get more info let me know :P
[22:43:36] <yngwin> i will
[22:43:45] -*- johu is out
[22:43:56] <kensington> also ++ on more packages for the tree
[22:43:58] <yngwin> ok, thats it then for this meeting
[22:44:31] <yngwin> over to #gentoo-qt for beers and chat :p