[02:29] <Daskreech> Someone is asking in #kubuntu if a full KDE upgrade was pushed to 10.04
[02:32] <Daskreech> Was anything done for 10.04 recently?
[02:35] <Darkwing> daskreech, check the news on the site... I'm mobile but, nothing is ringing
[02:36] <Daskreech> Did already. Nothing there
[02:37] <Darkwing> it would be there if we did... who was it in kubuntu?
[02:37] <Riddell> http://www.ubuntu.com/usn/usn-1276-1/  kdeutils was updated
[02:38] <Daskreech> says that they have 66 packages being updated
[02:38] <Daskreech> Hmm that would cover a fair number 
[02:38] <Daskreech> Thanks Riddell
[02:38] <Riddell> that includes kde4libs too
[02:39] <Darkwing> her rid
[02:39] <Darkwing> hi Riddell
[02:39] <Darkwing> tab fail
[02:40] <Darkwing> need to bug quassrldroid
[02:40] <Riddell> bonsoir
[02:48] <micahg> sounds about right
[09:04] <tsdgeos> do i read correctly from http://www.kubuntu.org/news/kde-sc-473 that 4.7.3 will eventually end up in 11.10 "regular" repos?
[09:04] <tsdgeos> instead of having to use the ppa?
[09:13] <apachelogger> tsdgeos: that is the workflow since last year or so
[09:14] <tsdgeos> ok
[09:14] <apachelogger> stable release updates first get into PPA -> testing -> upload to official -proposed archive -> more testing -> if all goes well move to official -updates archive
[09:14] <tsdgeos> i've been out of the kubuntu scene for a while
[09:15] <apachelogger> :)
[09:15] <apachelogger> tsdgeos: btw, Riddell has the rekonq translations issue on his todo
[09:16] <tsdgeos> nice
[09:48] <agateau> hey fellow ninjas! I am working on the massif-visualizer package, I set the "Maintainer" field to "Kubuntu Developers <kubuntu-devel@lists.ubuntu.com>", is it correct to set the "XSBC-Original-Maintainer" to myself until the package has been accepted in Debian?
[09:56] <apachelogger> agateau: yes
[09:56] <agateau> apachelogger: ok, thanks
[10:04] <debfx> Riddell: something is wrong with the qtwebkit merge. libqtwebkit4 grew by +1728 kB
[11:58] <Riddell> debfx: also symbols failure on ARM :(
[12:31] <agateau> mmm, wanted to propose my massif-visualizer package to Debian, but kgraphviewer is Ubuntu only :/
[12:31] <agateau> any chance kgraphviewer can go into Debian?
[12:40] <Riddell> you'd need to ask Debian people but kgraphviewer says "Original-Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
[12:40] <Riddell> which suggests it comes from there
[12:40] <Riddell> there might be a reason it hasn't been uploaded
[12:42] <agateau> ok
[12:44] <Riddell> debian's channel is #debian-qt-kde on oftc
[12:46] <agateau> damn, yet another irc network
[12:47] <Riddell> yeah
[12:47] <Riddell> agateau: are you going to upload massif-visualizer to revu?
[12:48] <agateau> Riddell: I was planning to get it in Debian and then ask for it to be synced, what would be the best approach?
[12:48] <Riddell> agateau: depends on how much time you want to spend on it, going through debian will be slower
[12:49] <agateau> Riddell: I guess it doesn't hurt to upload to revu first, then
[12:51] <Riddell> personally I'd just e-mail debian and if they want it they can take it
[12:51] <agateau> I filed an ITP for the package, so I'd better carry on with this now
[12:57] <Riddell> I have a patch for Qt, I wonder how long it'll take to work out how to submit it
[13:10] <agateau> :)
[13:14] <Riddell> agateau: any idea what this means? "Qt 4: Add a git remote called "gerrit" in your cloned repository, which points to the Qt 4 project on codereview.qt-project.org."
[13:14] <Riddell> there's nothingabout git remote on qt-project's git page
[13:14] <agateau> Riddell: git remote is a standard git command
[13:14] <agateau> you run git remote add gerrit the-correct-url-for-this remote
[13:15] <agateau> then you can do things like git pull gerrit
[13:15] <agateau> it's as if you were configuring the lp: part of bzr
[13:15] <Riddell> ah ok
[13:35] <agateau> Riddell: just pushed to revu, but it tells me we can't upload to precise, is that normal?
[13:38] <Riddell> agateau: probably revu is just out of date
[13:38] <Riddell> did it reject it or just give a warning?
[13:38] <agateau> Riddell: it says there is a common error
[13:38] <agateau> http://revu.ubuntuwire.com/p/massif-visualizer
[13:39] <Riddell> yeah it's just out of date
[13:39] <agateau> so I can just ignore that?
[13:39] <Riddell> yes
[13:40] <agateau> so next step is to bribe you to accept it?
[13:40] <agateau> :)
[13:41] <Riddell> ah well that's a mixed blessing, if I review it and upload it from revu then I can't review it as part of New queue
[13:42] <agateau> wow, too much burocracy! I am switching to Arch! ;)
[13:45] <Riddell> weird e-mail du jour, they get weirder each jour I'm sure http://paste.kde.org/149480/
[13:47] <agateau> Riddell: I guess she downloaded the iso and don't know what to do with it
[13:47] <Riddell> I guess so, usually when I get e-mails with that sort of subject line they are spam
[13:49] <agateau> this is the next generation of spam, filled with faked sensible content
[13:58] <Riddell> agateau: do you know what I'm doing wrong here? http://paste.kde.org/149492/
[13:59] <agateau> Riddell: any error message?
[14:01] <Riddell> ssh: Could not resolve hostname gerrit: Name or service not known
[14:03] <agateau> Riddell: I find the "git push gerrit:refs/for/master" line suspicious
[14:04] <agateau> I would have expected something like "git push gerrit master:master"
[14:04] <Riddell> me too, it says "push you changes to remote "gerrit" to the branch refs/for/master, if master is the branch you are targeting. " at http://wiki.qt-project.org/Qt_Contribution_Guidelines
[14:05] <agateau> then it should be "git push gerrit master:refs/for/master"
[14:05] <agateau> note the space (not colon) after "gerrit"
[14:06] <agateau> but the "refs/for/master" part looks weird
[14:06] <agateau> you have to understand the syntax for git push is "git push $remote $localbranch:$remotebranch"
[14:08] <Riddell> hmm well I can't even get it to connect to that ssh server
[14:08] <Riddell> maybe I should give up and just file a bug instead
[14:16] <agateau> Riddell: where did you get the info about ssh://codereview.qt-project.org:29418/ ?
[14:19] <Riddell> agateau: educated guess from http://codereview.qt-project.org/#admin,projects and http://codereview.qt-project.org/#settings,ssh-keys (which lists known_hosts as [codereview.qt-project.org]:29418)
[14:20] <agateau> Riddell: makes sense, but your remote is not complete, it should point to a git repository not just an host
[14:21] <Riddell> been trying  git push gerrit master:refs/for/master/no-format-arguments   and git push gerrit HEAD:refs/for/master/no-format-arguments
[14:21] <Riddell> but now I have an ssh problem
[14:21] <Riddell> it doesn't accept my key
[14:22] <Riddell> so meh, I'll just file a bug
[14:22] <agateau> I mean, the definition of your remote should not be just ssh://codereview.qt-project.org:29418/ it's like saying you push to launchpad.net without specifying a project
[14:23] <agateau> but I am having trouble finding the name of the qt4 project
[14:23] <tsdgeos> there's no qt4 project yet
[14:23] <agateau> ah, that would be the reason
[14:23] <tsdgeos> some people told me there won't be one some others told me it will be there after release
[14:23] <tsdgeos> there's a gerrit list projects command
[14:24] <agateau> tsdgeos: so qt4 patches should still go to gitorious?
[14:24] <tsdgeos> no idea really
[14:24] <agateau> maybe Frederik knows a bit more?
[14:24] <tsdgeos> ssh -p PORT URL gerrit ls-projects
[14:24] <agateau> fregl: hi, any idea ^
[14:24] <tsdgeos> will give you the list of porjects
[14:25] <tsdgeos> last i checked qt4 wasn't there
[14:25] <agateau> oh nice
[14:25] <Riddell> hmm, so when qt-project's documentation says "Qt 4: Add a git remote called "gerrit" in your cloned repository" what is means is "don't use gerrit at all"
[14:25] <fregl> agateau: qt4 is not yet there :( people are working on it
[14:26] <agateau> Riddell: seems like you are right :/
[14:26] <agateau> fregl: hey, while you are there, I am working on this a11y bug on Oneiric...
[14:27] <fregl> agateau: refs/for/master is just the convention to tell gerrit that this is a patch for the master branch. refs/for/foobar/baz would mean the baz patchset in foobar branch
[14:27]  * fregl hides ;)
[14:27] <agateau> fregl: I was thinking of doing something like that qputenv("QT_ACCESSIBILITY", "1"); QApplication app(...); unsetenv("QT_ACCESSIBILITY")
[14:27] <agateau> fregl: any chance this will work?
[14:28] <agateau> fregl: I guess the question should be: is it enough to have the env var set only while QApplication is constructed
[14:28]  * agateau wonders if he gave fregl enough context to understand his question
[14:29] <fregl> agateau: can't we just put the plugin somewhere out of the normal plugin path and let unity load it specifically? I hate the whole env var thing and I'm not really sure how the env is passed around
[14:29] <fregl> I understand the question I think :)
[14:29] <agateau> fregl: I like this approach as well
[14:30] <agateau> fregl: mmm, but then we need to patch the plugin not to care about the env var
[14:30] <fregl> agateau: that is the goal anyway - the patch is removing one line
[14:30] <agateau> fregl: I am not sure distro people will like me for moving .so to non-standard places
[14:31] <fregl> ah, the patch would be in Qt itself of course...
[14:31]  * Riddell adds grumpy note to qt-project's wiki so others don't end up spending time on a process which doesn't exist
[14:31] <fregl> setting QT_ACCESSIBILITY=0 works also if unset is not working
[14:32] <fregl> Riddell: thanks
[14:33] <agateau> fregl: I think unset will work, I was just asking this because unity-2d is made of several binaries but they use an internal shared library, and they all call a method called earlySetup at the begining, so I was looking into a way to do the env var dance in only one place in the code
[14:34]  * fregl checks the qt code
[14:35] <fregl> agateau: the code only checks once upon startup and loads the plugin and then sets a bool to true and never checks again
[14:36] <fregl> agateau: so your approach sounds promising. and users could still manually run apps with the env var set
[14:36] <agateau> fregl: yes, I saw that, the only question is: is the plugin loaded while qapp is constructed
[14:36] <fregl> agateau: it is loaded when the a11y frameworks is used the first time - so when an event is fired - eg focus change
[14:36] <fregl> I think
[14:37] <agateau> fregl: ok
[14:37] <fregl> Riddell: https://bugreports.qt.nokia.com/browse/QTQAINFRA-393 - latest I hear it is going to be after 4.8.0 is released, but I'm not sure if that is what is going to happen
[14:38] <agateau> actually I think there is also a single code place which is responsible for starting all apps, so I am just going to patch there
[14:38] <fregl> agateau: I think worst case you send one bogus a11y event and it should load the plugin then
[14:38] <agateau> fregl: ok, good to know
[14:41] <fregl> agateau: I think you can use QAccessible::queryAccessibleInterface(0); to make sure it's started
[14:41] <agateau> nice
[14:43] <agateau> fregl: mmm, the code has an early check for object != 0
[14:43] <fregl> agateau: yes, but you need the bool accessibility_active = true;
[14:44] <agateau> fregl: that's the only needed thing?
[14:44] <fregl> agateau: ah, maybe better "delete QAccessible::queryAccessibleInterface(qApp)" then, you are right
[14:45] <agateau> fregl: ok. I am testing some env. var based code right now, but will look into that if it doesn't work
[14:45] <fregl> great, thanks
[15:42] <Riddell> agateau: do you have libdbusmenu-qt merge on your todo?
[15:42] <agateau> Riddell: nope
[15:42] <agateau> Riddell: I am in a meeting atm
[16:04] <Riddell> agateau: to put it another way, as the most recent uploaded that merge should be on your todo list or you should ask for someone else to do it :)
[16:33] <agateau> Riddell: not sure what you mean
[16:34] <agateau> (meeting done)
[16:35] <Riddell> agateau: generaly policy is most recent uploader is responsible for doing the start of cycle merge, if you don't want to do it put a note next to it on merges.ubuntu.com
[16:36] <Riddell> yay, valorie is an elite e.v. member!
[16:37]  * agateau has never heard about this site => reads
[16:37] <Riddell> agateau: at the start of each cycle we merge our packages with debian to keep the changes at a minimum
[16:38] <Riddell> that site lists the needed merges (and gives some diffs between packages although I've never found them very useful compared to just doing it by hand)
[18:21] <bambee> evening all
[18:21] <Riddell> bonsoir bambee 
[21:35] <Quintasan> yofel, You do not happen to have a webserver capable of running Tracks instance, do you?
[21:38] <yofel> Quintasan: Tracs in... "trac" from the archive?
[21:47] <Quintasan> yofel, nah, as in Ruby on Rails based todo manager
[21:51] <valorie> woooooooooooooooo!
[21:52] <yofel> Quintasan: first time I hear of it, so I at least have nothing running right now
[21:52] <yofel> looks interesting though
[21:55] <valorie> good thing I have IRC, because I have never time to read email anymore
[21:55] <valorie> off to see my daddy again.....
[21:57] <Quintasan> yofel, Do tell if you fancy running one, I'd like to give it a try in an environment where one can rm -rf the install dir and be sure their data is gone :P
[21:58] <yofel> aks me again on friday, don't have time before that
[21:58] <yofel> *ask
[21:58] <Quintasan> However I do not really fancy digging through documentation on setting up a RoR-able server
[23:25] <apachelogger> Quintasan: you good sir have better things to do