[00:21] <ScottK> Quintasan: Can haz diffs for the FFes?
[00:22] <ScottK> rbelem: pong
[00:42] <jjesse> here's an interesting problem just updated my oneric vm today and after an update, rebooting and trying to login i get a white box that says "Could not start D-Bus, Can you call qdbus? and has an Okay button, after clicking the button i am prompted again with the login screen
[00:44] <yofel> jjesse: known issue, should be fixed with the next qt update, for now install qt4-dev-tools
[00:45] <jjesse> thanks yofel
[00:49] <rbelem> ScottK, could you take a look in the ffe? :-)
[01:11] <jjesse> hrmm ok last night i reported a bug i was having w/ kate and it appears to only be happening in an upgraded version of oneric and not a fresh version
[01:11] <jjesse> however i reported it on bugs.kde.org and now can't find it ;(
[01:12] <jjesse> ah found it: https://bugs.kde.org/show_bug.cgi?id=280236
[01:18] <jjesse> email about it send to the kubuntu-devel mailing list
[02:49] <ScottK> rbelem: Which?
[08:03] <bambee> morning
[09:14] <Quintasan> bambee: \o
[09:14] <Quintasan> Good morning as well
[09:14] <bambee> yo :)
[09:15] <Quintasan> ScottK: You can
[09:16] <Quintasan> ScottK: https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/828159
[09:19] <Quintasan> ScottK: https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/827286
[09:20] <Quintasan> ulmlogger: Can I merge kde-runtime-active branch?
[09:21] <Quintasan> WUT
[09:21] <Quintasan> yofel: PINGO
[09:21] <Quintasan> http://bazaar.launchpad.net/~yofel/kubuntu-packaging/kde-runtime-active-4.7/revision/223
[09:22] <Quintasan> Y U NO PATCHES?
[09:22] <ulmlogger> Quintasan: from where?
[09:22]  * yofel yawns
[09:22] <ulmlogger> Quintasan: I acked the stuff rbelem presented
[09:22] <yofel> @_@
[09:22] <ulmlogger> like 3 times or more :P
[09:22] <yofel> sry
[09:23] <Quintasan> ulmlogger: https://code.launchpad.net/~yofel/kubuntu-packaging/kde-runtime-active-4.7
[09:23] <jussi> ulmlogger: PM !!! :D
[09:23] <Quintasan> ulmlogger: I was looking at that branch but I discovered there are no patches :S
[09:23] <CIA-52> [kde-runtime] Philip Muškovac * 224 * debian/patches/ (6 files) Actually add the patches
[09:24] <Quintasan> Now I can merge and link to branch!
[09:25]  * Quintasan testbuilds
[09:26] <Quintasan> http://paste.kde.org/111259
[09:26] <Quintasan> hmmm
[09:26] <Quintasan> --with xine?
[09:26] <Quintasan> Is that some oneeyerick change?
[09:27] <yofel> sure it's oneiric since it's only there since dhmk is used
[09:29]  * Quintasan bzr-buildpackage -S
[09:29] <Quintasan> can't*
[09:30] <Quintasan> I see
[09:31] <Quintasan> TESTBUILDIN
[09:48] <Quintasan> werks
[09:53] <Quintasan> ScottK: https://bugs.launchpad.net/ubuntu/+source/kde-runtime/+bug/827283
[09:54] <Quintasan> ScottK: Then we have FFe for https://bugs.launchpad.net/ubuntu/+bug/828111
[09:54] <Quintasan> https://bugs.launchpad.net/ubuntu/+bug/512319
[09:54] <Quintasan> and https://bugs.launchpad.net/ubuntu/+source/plasma-mobile/+bug/828093
[09:54] <Quintasan> disregard 512319
[09:54] <Quintasan> bambee: file a FFe for touchegg
[09:55] <bambee> ok
[09:55] <bambee> sure
[09:55] <Quintasan> and ping ScottK with it, in bug description link to REVU package which I acke'd
[09:56] <Quintasan> ScottK: I need you to approve and upload FFe's for kde* packages so I can testbuild the rest and see if it works
[09:56] <Quintasan> If something doesn't work then we blame rbelem
[09:56]  * Quintasan goes back to cleaning
[10:10] <rbelem> :-D
[10:10]  * rbelem pokes Quintasan
[10:14]  * rbelem goes to work
[10:15] <bambee> Quintasan: bug 828637
[10:16] <Quintasan> What a beautiful FFe
[10:16] <Quintasan> ScottK: ^^
[10:16] <bambee> ohh... I need a review from another person normally... (It's the MOTU process...)
[10:17] <Quintasan> ulmlogger: I extend my every right to demand that you spare some time and review bambee's package http://revu.ubuntuwire.com/p/touchegg
[10:18] <Quintasan> Not much to review there, and leave an advocating comment
[10:18] <Quintasan> Unless he broke something
[10:18]  * Quintasan hands bambee Mighty Stick of ulmlogger Poking
[10:22]  * ulmlogger puts on some pants
[10:26]  * bambee pokes ulmlogger with his Mighty Stick and waits for "pants ack"
[10:27] <ulmlogger> you can already prepare your shell for fixing
[10:27] <ulmlogger> 2 seconds into the review -> first grave problem
[10:27] <bambee> really? o_O
[10:29]  * jussi steals the stick from bambee
[10:30] <yofel> bambee: this looks fooey
[10:30] <yofel>   3 Maintainer: Kubuntu Developers<EMAIL_ADDRESS>[10:30] <yofel>   4 XSBC-Original-Maintainer: Kubuntu Developers<EMAIL_ADDRESS>[10:31] <bambee> ?
[10:31] <yofel> either put yourself as original maintainer or just drop it
[10:31] <bambee> lintian displays warnings if I drop it
[10:32] <yofel> o.O
[10:32] <bambee> (I'am not sure if it's lintian, but something displays warnings)
[10:32] <bambee> let me check
[10:33] <yofel> ah, dpkg-source
[10:33]  * yofel usually ignores that
[10:34] <bambee> no it's dpkg-source
[10:34] <bambee> dpkg-source: warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field
[10:34] <bambee> well, I ignore it
[10:35] <ulmlogger> bambee: revud
[10:35] <bambee> ulmlogger: thanks
[10:36] <bambee> "upstream tar i tar.gz not xz, do not change upstream tars for no good reason" => the original tarball does not contain the COPYING file
[10:36] <bambee> that's why I've repacked it
[10:36] <yofel> well, then you're missing a +repack in the version
[10:36] <bambee> right
[10:37] <yofel> also, run wrap-and-sort
[10:46] <jussi> ulmlogger: moar PM! :D
[11:40] <Quintasan> bambee: I didn't tell you that you need to add +repack?
[11:40] <Quintasan> silly Quintasan
[12:16] <Quintasan> bambee: Now you got a list of errors from ulmlogger and should fix them
[12:16] <Quintasan> The package should be mostly good afterwards
[12:49] <debfx> ScottK: do you have an idea why ntrack breaks kde again? bug #826969
[12:49] <debfx> or rather how we can fix that
[12:50] <ScottK> debfx: I don't.  I tested the fix that's in 014 and still had problems, which is why it wasn't included in the SRU.
[12:50] <ScottK> I'd ask asac.
[12:51] <ScottK> Presumably someone needs to figure a way to make it consistently do that and strace it or some such.
[12:52] <mfraz74> would someone here be able to help me with a compiling problem?
[13:11] <shadeslayer> mfraz74: is it related to Kubuntu development?
[13:12] <mfraz74> shadeslayer: not really I was trying out the http://developer.ubuntu.com/packaging/html/packaging-from-scratch.html and I'm stuck
[13:13] <shadeslayer> hmm ... #ubuntu-motu or #ubuntu-packaging i'd say
[13:13] <mfraz74> ok thanks
[13:17] <bambee> re
[13:18] <bambee> Quintasan: no you just said me to repack it, BUT I know that I need to add +repack... I just forgot it... silly error
[13:34] <shadeslayer> !find qrcodec.h
[13:44] <ScottK> ulmlogger, debfx, Quintasan, rbelem, etc: Looking at the kde4libs diff, I'm not super happy about the idea of adding experimental headers into kdelibs5-dev.
[13:45]  * ulmlogger complained about that
[13:45]  * ScottK is going to (again) suggest that stuff go into a new kdelibs5-experimental-dev package and ask for arguments why that's not the way we should do it.
[13:45] <ScottK> ulmlogger: ^^^?
[13:46] <ScottK> ulmlogger: Any idea where the new symbols in debian/libnepomukquery4a.symbols come from?  That seems a bit scary too.
[13:46] <ulmlogger> but everything in an experimental package
[13:46] <bambee> Quintasan: http://revu.ubuntuwire.com/p/touchegg
[13:46] <bambee> fixed
[13:47] <ulmlogger> actually, for all I care you could just create one experimental package with libs and headers inside
[13:47] <ScottK> debfx: ^^^ re the symbols - do you know?
[13:47] <ulmlogger> it is not like this thing is supposed to be used by anyone nor will it be existing for > 11.10
[13:47] <shadeslayer> ulmlogger: wait a sec, aren't the experimental libs and headers supposed to be internal ?
[13:47] <ulmlogger> ScottK: what symbols?
[13:47] <ScottK> ulmlogger: Look in the diff.
[13:47] <ulmlogger> define internal
[13:47] <ScottK> https://launchpadlibrarian.net/77504842/371_370.diff
[13:47] <ulmlogger> ScottK: where?
[13:47] <shadeslayer> not public
[13:48] <shadeslayer> not shipped in a seprate package to be precise
[13:48] <ScottK> shadeslayer: Internal to what?
[13:48] <ScottK> Can't very well build plasma-active without them can we?
[13:48] <shadeslayer> ScottK: Internal to KDE i meant
[13:48] <shadeslayer> . . .
[13:48] <ScottK> shadeslayer: Internal to KDE doesn't make any sense.
[13:48] <ulmlogger> ScottK: the new symbols come from new code
[13:48] <debfx> ScottK: I guess from a patch?
[13:48] <ScottK> Sigh.
[13:49] <shadeslayer> i don't know how to put my thoughts into a proper sentence right now
[13:49]  * shadeslayer needs coffee
[13:49] <ulmlogger> ScottK: https://git.reviewboard.kde.org/r/102112/
[13:49] <ScottK> So our experimental patch exposes new symbols that we can't guarantee will be supported?
[13:49]  * ScottK looks
[13:49]  * bambee orders a coffee for shadeslayer
[13:50] <ScottK> ulmlogger: It'd be nice if that'd get committed to the 4.7 branch too since that sounds bug fixish to me.
[13:52] <ScottK> Or not.
[13:52] <debfx> wait what, we are adding a gazillion of patches that are from the 4.7 branch?
[13:53] <debfx> are *not* from
[13:53] <shadeslayer> bambee: oh ... now i have 2 coffee cups ...
[13:54] <ScottK> That's what the FFe we are discussing is about.
[13:54] <bambee> :D
[13:54] <ScottK> So we can build the latest Active/Mobile stuff.
[13:54] <shadeslayer> why can't we put it in a PPA?
[13:54] <ScottK> Then it's rather not part of Kubuntu.
[13:55] <ulmlogger> also
[13:55] <ulmlogger> we
[13:55] <ulmlogger> rather
[13:55] <ulmlogger> need
[13:55] <ulmlogger> arm
[13:56] <ulmlogger> ppa++ for not having arms
[13:56] <shadeslayer> so, its a tradeoff between having a new product vs exposing new symbols?
[13:56] <ulmlogger> \o/ <-- obs, o <-- lunchpad
[13:56] <shadeslayer> heh
[13:56] <ulmlogger> shadeslayer: new product?
[13:56] <ulmlogger> plasma mobile is not new
[13:56] <shadeslayer> ulmlogger: Kubuntu Active
[13:56] <ulmlogger> kubuntu mobile
[13:56] <shadeslayer> are we discussing Active or Mobile?
[13:57] <shadeslayer> because i thought the patches enable you to build Active stuff
[13:59] <ulmlogger> ACTIVE IS MOBILE
[14:02] <shadeslayer> @_@
[14:03]  * Quintasan hits shadeslayer with ACTIVE sign
[14:03] <Quintasan> ScottK: Well, I'm not really happy about doing this after feature freeze :P
[14:03] <shadeslayer> there are like a bazillion names in KDE now
[14:04] <ScottK> Quintasan: Agreed the timing isn't best, but until 4.7.0 was done there really wasn't a way to do it.
[14:04] <shadeslayer> KDE Frameworks/KDE SC/Plasma Active ...
[14:14] <Quintasan> ScottK: So it would be acceptable if we'd ship this experimental stuff in a separate package, right?
[14:16] <ScottK> Quintasan: I think so.
[14:16] <Quintasan> bambee: The changelog needs to mention the cause of repack
[14:16] <ScottK> The patch that adds the symbols looks reasonably safe/maintainable.
[14:17] <ScottK> Quintasan: I would like it though if the nepomukquery patch were updated to correctly reflect the version we added it in our package rather than say 4.8 as the upstream comment does.
[14:18] <Quintasan> ulmlogger: I believe one can pass --dbg-package=touchegg-dbg directly to %
[14:18] <Quintasan> That way whole override on strip becomes useless
[14:19] <ulmlogger> yes you can
[14:19] <ulmlogger> that does not mean it is the best solution :P
[14:19] <Quintasan> In that case?
[14:19] <Quintasan> I'm wondering if we are getting any particular advantage in that case
[14:20] <bambee> less characters... inline command... I like it...
[14:20] <bambee> (we've not a lot of arguments to pass to dh, we've only two...)
[14:20] <Quintasan> bambee: Same here, I did that in other packages for no apparent reason
[14:20] <Quintasan> (override I mean)
[14:20] <Quintasan> ulmlogger: Thoughts?
[14:21] <Quintasan> bambee: There is also nice wrap-and-sort script
[14:21] <Quintasan> You can use it :)
[14:21] <bambee> wtf?
[14:21] <bambee> woo
[14:22] <Quintasan> bambee: add --dbg-package=touchegg-dbg to dh and get rid of the override
[14:22] <bambee> + the changelog
[14:22] <Quintasan> I don't think it will have any impact on THIS package
[14:22] <Quintasan> Yes
[14:23] <Quintasan> And I will advocate
[14:24] <Quintasan> ScottK: What about kde-workspace?
[14:24] <debfx> just to be clear, those patches won't be included in kdelibs 4.7 so we will have to carry them on until we remove kde4libs?
[14:24] <ScottK> The nepomukquery patch will be in 4.8.
[14:25] <ScottK> The rest is (after moving the headers and such into an experimental -dev package) in separate binaries.
[14:25] <ScottK> We can drop them if needed later.
[14:26] <debfx> I thought there will be no kdelibs 4.8
[14:26] <debfx> also some patches touc hplasma.h
[14:26] <ScottK> Hmm.
[14:27] <ScottK> The activitymanager changes in -runtime look a bit scary too.
[14:27] <ScottK> ulmlogger: This all seems rather invasive.
[14:27] <Quintasan> ScottK: Which patch is the nepomukquery one?
[14:27] <ScottK> Quintasan: https://git.reviewboard.kde.org/r/102112/
[14:28] <ScottK> That commit is in our diff.
[14:29] <Quintasan> So you want to get "\since 4.8" replaced with "since 4:4.7.0-0ubuntu3" ?
[14:29] <Quintasan> in the patch
[14:30] <ScottK> Yes.
[14:30] <Quintasan> There is only one instance of that, replacing
[14:30] <ScottK> But I don't want any of it uploaded until we've got through the whole set.
[14:31] <ScottK> Someone convince me why I shouldn't freak out about the scale of the activitymanager changes?
[14:31] <bambee> Quintasan: uploaded
[14:31] <Quintasan> bambee: Awesome
[14:32] <Quintasan> rbelem or ulmlogger may have sufficient explanations for this
[14:32] <Quintasan> ScottK: So new files from debian/kdelibs5-dev.install should land into other experimental package, is naming it kdelibs5-experimental-dev enough?
[14:32] <ScottK> Yes.  I think that's good.
[14:32] <ScottK> ulmlogger: ^^^ ?
[14:33]  * bambee blames "bzr commit" it does not open emacs anymore....
[14:33]  * bambee has a look at "man bzr"
[14:33] <bambee> (just in case)
[14:34] <shadeslayer> bambee: known bug/feature
[14:34] <Quintasan> feature
[14:34] <Quintasan> since vim > emacs
[14:34] <Quintasan> :P
[14:34]  * Quintasan hides
[14:34] <shadeslayer> heh :P
[14:35] <yofel> no, bzr feature
[14:36] <ScottK> Tell Riddell.  He uses emacs, so I'm sure he'd be right on top of fixing it.
[14:36] <bambee> Q_ASSERT(! vim > emacs);
[14:37] <Quintasan> ScottK: Should Depends on that experimental package be the same as kdelibs5-dev or I can just make it depend of kdelibs5-dev so it pulls everything?
[14:37] <Quintasan> s/of/on
[14:37] <ScottK> The latter is fine.
[14:38] <Quintasan> ScottK: http://paste.kde.org/111319 <-- Any other thoughts?
[14:39] <ScottK> Quintasan: It needs some kind of DO NOT USE warning in the description.
[14:40] <ScottK> Totally unstable API/ABI, may break without warning, etc.
[14:40] <yofel> Quintasan: also, IMO i should depend on the experimental lib packages so you can remove them from kdelibs5-dev
[14:40] <yofel> s/i/it/
[14:40] <kubotu> yofel meant: "Quitntasan: also, IMO i should depend on the experimental lib packages so you can remove them from kdelibs5-dev"
[14:40] <yofel> sed fail..
[14:40] <shadeslayer> lol
[14:41] <ScottK> yofel: Good point.
[14:44] <Quintasan> As far as I can see the kdelibs5-dev I merged doesnt depend on them :D
[14:44] <ScottK> Then the experimental one should pull them in.
[14:46] <Quintasan> ScottK: http://paste.kde.org/111325
[14:46] <ScottK> I'd have gone with unstable API rather than production environment.
[14:47] <ScottK> When someone uses this package and later their stuff doesn't build, I want to be able to say "Dude, did you read the package description - what did you think would happen".
[14:48] <Quintasan>  This package contains headers with unstable API and should not be used in production development ?
[14:48]  * Quintasan has no idea how to put that in words
[14:49] <Quintasan> Headers in this package provide unstable API, use at your own risk?
[14:49] <ulmlogger> USE NOT AT ALL
[14:50] <Quintasan> ScottK: ^
[14:50] <ScottK> Quintasan: As ulmlogger says.
[14:50] <yofel> don't use unless you know what you're doing?
[14:50] <ScottK> No.  Don't use.
[14:50] <yofel> k
[14:51] <Quintasan>  Headers in this package provide unstable API, do not use them.
[14:51]  * yofel would drop 'them' but otherwise ok
[14:51] <Quintasan> True
[14:51]  * ScottK is with yofel, but either way.
[14:52] <Quintasan> ScottK: The whole diff -> http://paste.kde.org/111331
[14:52] <ScottK> ulmlogger: Convince me on the activitymanager in -runtime.
[14:52] <Quintasan> ulmlogger: DO EET
[14:53] <ScottK> Could this stuff get shoved in some experimental package that's not installed normally?
[14:53] <ScottK> Quintasan: That looks good for libs.  No someone needs to sell me on runtime.
[14:53]  * Quintasan pushes
[14:55] <Quintasan> ScottK: Can you look at workspace while ulmlogger is looking for arguments? :P
[14:55] <ScottK> What bug is that?
[14:55] <Quintasan> https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/828159
[14:58] <ulmlogger> ScottK: well, yes, we could do a double build
[14:58] <ulmlogger> first without patches, second with
[14:58] <ScottK> ulmlogger: Wouldn't that be less risk?
[14:58] <ulmlogger> sure it would
[14:59] <ulmlogger> also it is a PITA to do :P
[14:59] <ScottK> The libs stuff seemed mostly isolated to new stuff.  -runtime not so much.
[14:59] <ScottK> Fortunately Quintasan is an expert now that he did the kwin-gles stuff.
[14:59] <Quintasan> FFFFFFFF
[14:59] <ulmlogger> win
[14:59]  * ulmlogger needs to shower and stuff
[15:00] <Quintasan> How do you expect the builder to know when to apply some patches and when not to?
[15:00] <Quintasan> building gles was easy since I didn't have to do any magic apart from few overrides
[15:00] <yofel> you run quilt between the builds?
[15:01] <yofel> which would probably be messy though..
[15:01] <Quintasan> !
[15:01] <Quintasan> Can we have a separate series file and pass that over to quilt during the second build?
[15:01] <yofel> you could redefine QUILT_PATCHES though maybe
[15:02] <Quintasan> or
[15:02] <yofel> that would give you a seperate series file too
[15:02] <Quintasan> more dirty
[15:02] <Quintasan> add the patches but remove them from series
[15:02] <Quintasan> do the first build
[15:03] <Quintasan> append new patch names in rules before second build
[15:03] <Quintasan> do a second build
[15:03] <Quintasan> yofel: I don't want to redefine it since we need all the previous patches too
[15:04] <yofel> well, apply patches -> redefine -> apply again
[15:04] <yofel> dpkg-source will apply the default ones anyway
[15:04] <ScottK> Quintasan: I don't understand "+Breaks: kdebase-workspace-bin (<< 4:4.5.80), kde-window-manager (= ${binary:Version})"
[15:05] <yofel> you would need to pop again between the configure and build step though I think
[15:05] <ScottK> Doesn't it break every version of kde-window-manager?
[15:05] <ScottK> Also short description should mention GLES.
[15:06] <ScottK> Same for both packages
[15:07] <ScottK> Other than that it seems OK.
[15:08] <ScottK> I approved the FFe, but please fix that stuff up.
[15:09] <ScottK> Quintasan: ^^^
[15:31] <Quintasan> ScottK: Look at the second diff
[15:31] <Quintasan> ScottK: Those packages cannot be installed at the same time
[15:31] <Quintasan> Because they provide the same files
[15:31] <ScottK> Quintasan: I get that.  Why is the breaks versioned?
[15:32] <Quintasan> It shouldn't be versioned?
[15:32] <Quintasan> Ah
[15:32] <Quintasan> Stupid question, removing
[15:32] <ScottK> Great.
[15:32] <ScottK> Quintasan: That applies to both packages (same issue)
[15:35] <Quintasan> ScottK: kde-window-manager (>= ${source:Version}) | kde-window-manager-gles (>= ${source:Version})
[15:35] <Quintasan> That's Depends on kde-workspace, is this good?
[15:35] <ScottK> That's fine.
[15:35] <Quintasan> Conflicts: kde-window-manager-gles
[15:36] <Quintasan> That's all
[15:36] <Quintasan> I'm not adding Conflicts: kde-window-manager on kde-window-manager-gles
[15:36] <Quintasan> That's pointless unless I'm misunderstanding how dpkg works
[15:36] <Quintasan> If I have installed -gles and try to install non-gles then it will conflict
[15:36] <Quintasan> if I have non-gles installed it will conflict too
[15:37] <Quintasan> right?
[15:37] <ScottK> I don't think conflicts are bi-directional like that, but I'm not sure.
[15:37]  * bambee hugs Quintasan and asks him to advocate touchegg on revu
[15:37] <bambee> :P
[15:37] <Quintasan> bambee: Urgh right, let me do kwin
[15:37] <Quintasan> ScottK: I'll add them back just to be safe
[15:38] <bambee> sure, there's no hurry
[15:38] <Quintasan> It won't hurt anyone
[15:39] <Quintasan> ScottK: http://paste.kde.org/111343
[15:39] <Quintasan> Before I commit
[15:40] <Quintasan> bambee: Advocated
[15:41] <ScottK> Quintasan: Yes.  Similar changes in the other gles binary too.
[15:42] <Quintasan> oh libkwineffects
[15:42] <Quintasan> ScottK: http://paste.kde.org/111349
[15:43] <ScottK> Looks good.
[15:43] <Quintasan> Pushing
[15:43] <ScottK> Before uploading I'd test to make sure those conflicts really do what you want.
[15:44] <bambee> Quintasan: thanks!
[15:46] <Quintasan> bambee: Now convince ScottK to approve FFe
[15:46] <Quintasan> :P
[15:47] <ScottK> What testing has the package had?
[15:48] <Quintasan> ScottK: I testbuilt and installed it. I don't have any hardware to test how it works
[15:48] <ScottK> So who does?
[15:48] <ScottK> Didn't ulmlogger score some hardware?
[15:49] <ScottK> If you can test it, I've no problem with FFe.
[15:49]  * Quintasan looks at ulmlogger
[15:49] <jussi> Has anyone tried installing from the CD/usb recently?
[15:50] <Quintasan> jussi: One-eye-rick?
[15:50] <bambee> ScottK: actually? it's not tested yet, I've not the hardware for that
[15:50] <jussi> Quintasan: yeah
[15:50] <Quintasan> jussi: If you are talking about broken DBus then we know about that :P
[15:50] <ScottK> bambee: So find someone.
[15:50] <jussi> Quintasan: My 15th doesnt install - ubiqity doesnt start
[15:50] <ScottK> Broken dbus is fixed.
[15:50] <Quintasan> I see
[15:51] <ScottK> Sounds about right for broken dbus (time wise)
[15:51] <ulmlogger> ScottK, Quintasan: bulldog98 and I have hardware
[15:51] <ulmlogger> also I am going to do some cursing now
[15:51] <ScottK> jussi: Install from the Alpha 3 images and then upgrade.  Those work.
[15:51] <jussi> and my upgraded version doesnt even boot - hangs with a white blinking cursor
[15:52] <Quintasan> jussi: Did you try upgrading today?
[15:52] <jussi> I can make it boot via recovery, then resume and startx
[15:52] <jussi> Quintasan: no, I upgraded a few days back
[15:52] <Quintasan> As ScottK said, DBus got fix'd
[15:52] <bambee> Could someone test touchegg with the appropriated hardware please?
[15:52] <jussi> ahh, lets see
[15:53] <jussi> ooh, thats lots of upgraded stuff... let me see if it hels
[15:53] <Quintasan> bulldog98 or ulmlogger: pull-revu-sources touchegg, compile and try using that
[15:53] <Quintasan> we need that done SOON (TM)
[15:59] <Quintasan> That's sure stupid, Eject doesnt do umount before trying to eject
[16:01] <jussi> was it libqt4-dbus  that needed to be upgraded or?
[16:03] <ScottK> jussi: Read kubuntu-devel
[16:10] <jussi> ScottK: hrm... qdbus does not seem to exist (Im using archive.ubuntu.com, fully dist upgraded) ?
[16:12] <ScottK> Hmmm.
[16:12] <ScottK> jussi: What version of Qt do you have?
[16:13] <jussi> libqt4-dev is Version: 4:4.7.3-4ubuntu5
[16:13] <ScottK> You don't have the fixed one then.
[16:13] <ScottK> What you want is ubuntu6
[16:14] <ScottK> So you're in the "depending on how long your mirror takes to update" situation.
[16:14] <jussi> isnt archive.ubuntu.com the main mirror that goes first?
[16:14] <ScottK> It is, but it's a mirror nontheless.
[16:15] <ScottK> I'd have expected it there by now, but stuff happens
[16:15] <jussi> oh look at that, apt-get updated and dist upgraded and its getting pulled in now :)
[16:16] <jussi>   libappindicator1 libboost-dev are still being held though
[16:16] <ScottK> Unrelated.
[16:16] <Quintasan> 94%
[16:16] <Quintasan> Oh wait, it's the first build
[16:16] <Quintasan> :/
[16:17] <jussi> also, anyone know what this is: W: libwmf0.2-7 is already removed. It is recommended to run defoma-app purge libwmf0.2-7.
[16:18] <Quintasan> Since it 's a warning you can ignore it :P
[16:19] <jussi> lol
[16:19]  * Quintasan hides
[16:19] <maco> ive had a simlar thing show up before
[16:19] <maco> when i ran defoma-app purge  bleh      it did some stuff and said the same thing during it
[16:19] <jussi> right, lets go see if kubuntu boots now
[16:25] <Quintasan> yofel, ScottK: Can I have a review before I merge? https://code.launchpad.net/~quintasan/kubuntu-packaging/kde-workspace/+merge/72066
[16:26] <ScottK> Quintasan: Depends/Build-depends in your changelog entry.
[16:28] <ScottK> What's Conflicts: kde-window-manager-gles (=< ${binary:Version}) ?
[16:28] <Quintasan> What the...
[16:28] <Quintasan> BRR
[16:29]  * Quintasan deletes that
[16:29] <Quintasan> I pushed wrong stuff
[16:30] <jussi> nope, still no boot :(
[16:31] <Quintasan> Can we have /var/log/Xorg.0.log?
[16:31]  * Quintasan goes playing Harvest Moon
[16:34] <jussi> Quintasan: when it doesnt boot, it doesnt get anywhere, just hangs with a white flashing cursor
[16:34] <Quintasan> Can you boot it in recovery mode?
[16:34] <jussi> yes
[16:34] <jussi> I do that, hit resume, then startx and get into kde like that
[16:34] <Quintasan> :O
[16:35] <jussi> strange thing
[16:35]  * Quintasan has no idea how to debug boot up
[16:37] <shadeslayer> kdeinit4 is consuming a entire core -.-
[16:38] <shadeslayer> jussi: yeah that has happened to me a couple of times
[16:39] <shadeslayer> some random update solved the issue for me
[16:40]  * jussi sighs. its sucky to live in a quiet world...
[16:43] <yofel> well, you could either disable splash, or set gfxplayload to text to get actual boot messages (and disable 'quiet'). If you want even more verbose boot add '--verbose' to the kernel command line
[16:48] <ulmlogger> Quintasan: no worky worky
[16:48] <ulmlogger> already tried that days ago
[16:48] <ulmlogger> there is some problem with touch input
[16:48] <ulmlogger> only once you use two fingers it will actually be detected as input
[16:48] <ulmlogger> so it is a bit of a drag
[16:48] <Quintasan> Is it a problem with the application or the input magic?
[16:48] <ulmlogger> litterally :P
[16:48] <ScottK> ulmlogger: Maybe cnd can help you with that?
[16:48] <ulmlogger> Quintasan: not sure
[16:49] <ulmlogger> probably input magic
[16:49] <ScottK> If it sort of works like that, I'm OK with FFe.
[16:49] <ulmlogger> touchegg is not meant for touch devices
[16:49] <ulmlogger> it is meant for touch pads
[16:49] <ulmlogger> the things on a laptop
[16:49] <ulmlogger> where it works perfectly
[16:50] <ScottK> I see.
[16:51] <ScottK> Someone point me at the FFe bug and I'll approve it.
[16:54] <Quintasan> bambee: ^
[16:56] <bambee> Quintasan: pong
[16:56]  * bambee is opening thunderbird
[16:57] <bambee> bug 828637
[16:57] <bambee> ScottK, Quintasan: ^
[16:58] <ScottK> bambee: Approved.
[16:58] <bambee> woo! thanks! :D
[17:09] <Quintasan> jussi: On my G+ post, I forgot to mention we are doing that after Feature Freeze :DDD
[17:36]  * rgreening wishes he had a G+ invite.
[17:36] <rgreening> ^ Quintasan :)
[17:36] <jjesse> i can give you one
[17:36] <Quintasan> rgreening: email please :)
[17:36] <rgreening> jjesse: cool. would be sweet
[17:36] <jjesse> https://plus.google.com/_/notifications/ngemlink?path=%2F%3Fgpinv%3DYm4x4zDkd94%3AF3ZUHdJh1fQ
[17:36] <rgreening> roderick DOT greening AT gmail.com
[17:37] <Quintasan> Oh jjesse beat it to me
[17:37] <jjesse> click on the link
[17:37] <rgreening> YAY!
[17:39] <rgreening> thanks.
[18:25] <ScottK> Please be fixing http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html#kubuntu
[18:26] <ScottK> I think I got pimlibs and company fixed.
[18:40] <micahg> \o/ packagesets get more eyes :)
[18:58] <afiestas> rbelem today I explained the plans for the places view to ereslibre
[18:58] <afiestas> he loved them :)
[19:04] <rbelem> afiestas, awesome :-D
[19:04] <rbelem> afiestas, i already stated to hack that
[19:04] <rbelem> afiestas, i changed it to threeview
[19:04] <afiestas> already?
[19:04] <afiestas> that was fast
[19:04] <rbelem> afiestas, :-D
[19:05] <rbelem> afiestas, it is a pretty simple
[19:07] <afiestas> rbelem: if there is not a screenshot, it never existed :p
[19:26] <rbelem> afiestas, as soon as i arrive home i will send a screenshot to you :-)
[19:26] <rbelem> Quintasan, ping
[19:52] <markey> konnichiwa me friends, we be doing the hangoutery, and if ye shall desire, ye can join the funy
[20:17] <bcooksley> Hi
[20:18] <bcooksley> is somebody around who feels responsible for the kde-workspace patch "kubuntu_11_fix_root_only_kcms.diff"?
[20:18] <bcooksley> it is terribly broken
[20:18] <ulmlogger> it is a patch imported from fedora actually
[20:18] <ulmlogger> might be that they have an unbroken version
[20:18] <bcooksley> I see
[20:18] <ulmlogger> bcooksley: is there a builtin way to handle this?
[20:18] <bcooksley> kind of
[20:18] <ulmlogger> because I really think that would be a worthwhile feature
[20:19] <ulmlogger> also in terms of 3rd party integration
[20:19] <bcooksley> through the external application feature
[20:19] <ulmlogger> think company wants to expand systemsettings for internal stuff they need
[20:19] <bcooksley> see kde-workspace/systemsettings/examples/external-application.txt
[20:19] <ulmlogger> bcooksley: cheers
[20:19] <bcooksley> they'll show up just like any other module, and have a replacement fill in provided by system settings when clicked
[20:20] <bcooksley> allowing you to relaunch it if you want
[20:20] <bcooksley> if you wanted to reimplement root mode - rather than adjusting the control modules
[20:20] <bcooksley> line 209 of ModuleView.cpp is where it should be implemented
[20:21] <Quintasan> rbelem: pong
[20:21] <bcooksley> the patch causes http://bugs.kde.org/280356
[20:22] <ScottK> ulmlogger: Are you going to fix it then?
[20:22] <ScottK> That might go nicely with Quintasan GLES magic for one big -workspace upload.
[20:22] <ScottK> bcooksley: Thanks for pointing it out.
[20:23] <bcooksley> ScottK: np
[20:23] <ulmlogger> ScottK: if only I figureed out how
[20:25] <bcooksley> if you're talking about system settings, I wrote the code in question (moduleview.cpp) so feel free to ask about that area
[20:26] <rbelem> Quintasan, is there some something that i have to do? :-)
[20:27] <ScottK> ulmlogger: Since the amount of C++ I know would fit into a very small thimble, I think it's up to you.
[20:28] <ulmlogger> well, point being, I just tried to whip the external app stuff into an existing rootonly kcm and everything goes kaput
[20:28] <ulmlogger> ah
[20:28] <ulmlogger> getting somewhere
[20:28] <ulmlogger> or not
[20:29] <bcooksley> updated sycoca?
[20:34] <ulmlogger> bcooksley: there is some stuff weird with it
[20:34] <bcooksley> such as..
[20:35] <ulmlogger> well, with partitonmanager anyway
[20:35] <yofel> great, tomahawk has fooey licensing too ~.~
[20:36] <bcooksley> what does it do ulmlogger?
[20:36] <bcooksley> it is supposed to launch the module when you click the icon
[20:36] <ulmlogger> well, there is an actual partitionmanager kcm, or rather it is a kcm
[20:36] <ulmlogger> no idea why
[20:36] <ulmlogger> bcooksley: yeah, I got the desktop file fixed up
[20:36] <ulmlogger> works now
[20:37] <bcooksley> ok, cool
[20:37] <ulmlogger> it lacks busy indication though, might be my fault I guess
[20:37] <bcooksley> the system settings app itself forks that off
[20:37] <bcooksley> so it is now independent
[20:37] <ulmlogger> right
[20:38] <ulmlogger> gotta talk to fedora about this too
[20:38]  * ulmlogger is a tad drunk right now, so he'll put this on his todo
[20:38] <bcooksley> ok, thanks for taking the lead on this
[20:38] <bcooksley> if they still want compat with existing root modules
[20:38] <bcooksley> then the way to do it is to copy ExternalAppModule, modify that
[20:39] <bcooksley> then tie it in like ExternalAppModule is in ModuleView
[20:40] <ulmlogger> noted, thanks for the info :)
[20:41] <ulmlogger> yofel: markey will be pleased to know
[20:41] <ulmlogger> yofel: send me a mail
[20:41] <ulmlogger> I'll meet with muesli tomorrow
[20:42] <yofel> I can talk to muesli myself on IRC. tomahawk itself is mostly ok, but the thirdparty stuff they ship has some missing copies
[20:45] <ulmlogger> yofel: 3rd party code copies are discouraged in the archive :P
[20:45] <ulmlogger> so that is a no go pretty much really
[20:45] <ulmlogger> especially since one can build tomahawk without that shite
[20:45] <ScottK> If it's just library copies, yes, please get rid of them.
[20:46] <yofel> $ ls thirdparty/
[20:46] <yofel> CMakeLists.txt  jreen  liblastfm2  libportfwd  qtweetlib  qxt  SPMediaKeyTap  winhttp
[20:46] <yofel> haven't checked if anything of that is actually needed
[20:46] <ulmlogger> none
[20:48] <yofel> hm, getting rid of that dir would need some cmake fixes it seems
[21:13] <CIA-52> [kubuntu-tablet-settings] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (24 files in 7 dirs) Initial release
[21:16] <ulmlogger> bulldog98_: https://code.launchpad.net/kubuntu-tablet-settings plz try, mind that you will have to hook it into startkde as of yet
[21:16] <ulmlogger> or deploy an xession file
[21:16] <ulmlogger> ScottK: ^
[21:16] <ulmlogger> Quintasan_: ^
[21:20] <yofel> ulmlogger: well, 2 of those are optional (without archive packages), qxt is in the archive but with different ABI, liblastfm2 would need some cmake find magic and libportfwd is somehow built-in
[21:21] <yofel> SPMediaKeyTap and  winhttp are mac/win
[21:24] <ulmlogger> too drunk
[21:27]  * yofel has a headache and postpones till tomorrow
[22:22] <yofel> hm, now I have a runaway kded process too
[22:24] <ulmlogger> yeah, Mamarok had it too
[22:24] <ulmlogger> though I really do not feel like looking into that shitty code again
[22:24] <yofel> 3 people in +1 have it too
[22:25] <yofel> but I don't get which of the 6 threads gdb sees is broken...
[22:25] <yofel> hm, thread 4 doesn't start with __GI___poll
[22:26] <yofel> #0  0x00007f71988c1913 in select () at ../sysdeps/unix/syscall-template.S:82
[22:26] <yofel> #1  0x00007f7199cb36d1 in QProcessManager::run (this=0x7f719a0055a0) at io/qprocess_unix.cpp:245
[22:26] <yofel> #2  0x00007f7199beaca5 in QThreadPrivate::start (arg=0x7f719a0055a0) at thread/qthread_unix.cpp:320
[22:26] <yofel> #3  0x00007f7196389edc in start_thread (arg=0x7f717f49e700) at pthread_create.c:304
[22:26] <yofel> #4  0x00007f71988c889d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
[22:26] <yofel> #5  0x0000000000000000 in ?? ()
[22:30] <ulmlogger> depper
[22:30] <ulmlogger> deeper
[22:30] <yofel> http://paste.kde.org/111499
[22:30] <yofel> that's all I get
[22:33] <ulmlogger> ok
[22:33] <ulmlogger> yofel: valgrind it
[22:33] <ulmlogger> with --tool=callgrind
[22:33] <ulmlogger> let it run for a bit
[22:33] <yofel> how does one valgrind a running process?
[22:33] <ulmlogger> with a bit of luck it should show what is called too often
[22:33] <ulmlogger> ie what causes the endless loop eating th ecpu
[22:33] <ulmlogger> yofel: google it
[22:33] <yofel> (if that's even possible)
[22:33] <ulmlogger> sorry, I have the command somewhere
[22:34] <ulmlogger> but I am too drunk to look for it
[22:34] <ulmlogger> or actually too tired
[22:34] <yofel> ok, no
[22:34] <ulmlogger> if you do not feel like it I can look for it tomorrow
[22:34] <ulmlogger> actually I think I pasted the command in the cpu usage bug for natty
[22:34] <ulmlogger> or at least I was close to doing so IIRc
[22:35] <yofel> ah wait, callgrind can do that somehow it seems
[22:36] <yofel> hm no
[22:36] <yofel> still needs to be run in valgrind first
[22:38] <yofel> ulmlogger: uh fun
[22:38] <ulmlogger> yofel: callgrind is a tool for valgrind
[22:38] <yofel> trying to run kded by hand gives:
[22:38] <yofel> kded4: symbol lookup error: /usr/lib/ntrack/modules/ntrack-libnl3.so: undefined symbol: ntrack_list_insert_sorted
[22:38] <ulmlogger> oh yeah, you might need the dbgsym package from ddebs
[22:38] <ulmlogger> also FWIW valgrind is essentially just a shell for varous memory analysis tools
[22:38] <ulmlogger> valgrind, callgrind, cachegrind, massif...
[22:39] <yofel> I know what valgrind is, used it a few times, it's just that you can't attach it to running processes since it emulates things
[22:39] <yofel> great, now I have NO kded process anymore
[22:40] <yofel> ulmlogger: ROFLMAO
[22:40] <yofel> last ntrack upload
[22:40] <yofel>   * debian/libntrack0.symbols: add missing ntrack_info_human_banner symbol.
[22:41] <yofel> well, not really
[22:41] <yofel> let's see if this UDD thing actually has a use for once
[22:55] <yofel> ulmlogger: uh... why would a symbol in a library end up as Undefined but still appear in nm?
[22:55] <yofel> $ nm -DC /usr/lib/ntrack/modules/ntrack-libnl3.so | grep ntrack_list_insert_sorted
[22:55] <yofel>                  U ntrack_list_insert_sorted
[22:59]  * ScottK is almost sure ntrack is to blame and whatever it is will turn out to be a problem on Natty as well.
[22:59] <ScottK> Go yofel.  Go.
[23:02] <bambee> Riddell: Riddell: as I am a kubuntu member now, could you subscribe me to kde-packagers please ? (however, there's no hurry)
[23:03] <yofel> +1
[23:04] <yofel> hm, rebuilding ntrack changed nothing
[23:05] <yofel> someone fix debsums...
[23:07] <yofel> ScottK: it doesn't really help that ntrack-libnl3.so has no symbols file in the ntrack package...
[23:08] <ScottK> yofel: You know about the dbgsym repo, right?
[23:09] <yofel> I said symbols file, not debugging symbols
[23:09] <ScottK> Ah.
[23:09] <yofel> I have latter
[23:09] <ScottK> cyphermox: ^^^ You should fix that.
[23:09] <ScottK> Today that would be a requirement to get in Main.
[23:10] <yofel> well, the other files have one, but this lib seems to be a module
[23:10] <yofel> but then it shouldn't make kded fail...
[23:15] <wgrant> ScottK: What's broken?
[23:16] <ScottK> yofel needs symbols for ntrack-libnl3.so to troubleshoot random ntrack causes other processes to consume 100% of CPU.
[23:23] <Riddell> bambee: I think you need to file a bug on bugs.kde.org for sysadmin to subscribe you
[23:23] <bambee> Riddell: oh sure
[23:23] <bambee> np
[23:43] <cyphermox> ScottK: reading backlog
[23:43]  * yofel gives up for today
[23:44] <wgrant> ScottK: That will teach me to read my scrollback while half asleep. Your link to the FTBFS page showed up as a ping, so I thought you were telling me there was something wrong with it.
[23:45] <wgrant> Ahem.
[23:47] <cyphermox> ntrack-libnl3 has no symbols file, yeah, that's possible...


[03:50] <pitti> Good morning
[07:01] <chrisccoulson> good morning everyone
[07:05] <pitti> hey chrisccoulson, how are you?
[07:05] <chrisccoulson> pitti - yeah, not too bad thanks. how are you?
[07:06] <chrisccoulson> i'm battling with a bit of an unreliable connection today :(
[07:06] <pitti> chrisccoulson: je suis bien, merci! j'ai ecrit une test de smb pour gvfs
[07:07] <pitti> actually, un test
[07:07] <chrisccoulson> excellent, good stuff :)
[07:07] <chrisccoulson> i'm going to have to start learning french ;)
[07:09] <pitti> j'apprends le français avec duolingo.com -- c'est bon!
[07:09] <pitti> chrisccoulson: I had thought that seb128 forced everyone to do that now :0
[07:09] <chrisccoulson> heh, i think he'd like to do that ;)
[07:55] <pitti> seb128: bonjour mon ami, ça va?
[07:56] <seb128> hey desktopers
[07:56] <seb128> pitti, salut, ca va bien, et toi ?
[07:56] <pitti> hating compiz! :)
[07:56] <pitti> je suis bien
[07:58] <pitti> I got bug 1042041 again, and it keeps forgetting my keybindings
[07:58] <ubot2`> Launchpad bug 1042041 in compiz "1:0.9.8+bzr3319-0ubuntu1 regression: wrong auto-raise, cannot be disabled" [Undecided,New] https://launchpad.net/bugs/1042041
[07:59] <seb128> pitti, je "vais" bien btw ;-)
[08:00] <pitti> seb128: pardon, d'accord!
[08:01] <seb128> pas de soucis ;-)
[08:02] <seb128> smspilla|z, ^ could you look at this compiz bug when you are around?
[08:03] <seb128> pitti, ctrl-alt-t got fixed in gnome-control-center,gnome-settings-daemon by jbicha this w.e, did you restart your session yesterday?
[08:04] <pitti> seb128: yes, twice; and today three times more
[08:04] <seb128> hum
[08:04] <pitti> fun, this time ctrl+alt+t works, but I get that autoraise misbehaviour
[08:04] <seb128> can you set it in the g-c-c ui?
[08:04] <pitti> I can always set back the keybinding for "lower window behind all others", but it keeps forgetting it
[08:05] <pitti> seb128: g-c-c doesn't allow configuring FFM or autoraise
[08:09] <seb128> pitti, I was speaking about ctrl-alt-t specifically
[08:09] <pitti> seb128: ah, that one always seems to be set
[08:09] <pitti> it forgets about my alt+b binding for "put window to the back" and also show it as disabled in g-c-c, but hte ctrl+alt+t launcher is always shown (but doesn't work often)
[08:10] <pitti> seems there's a weird bug in the gsettings port
[08:11]  * pitti runs gsettings set org.gnome.desktop.wm.preferences auto-raise-delay 10000, which does seem to work
[08:11] <seb128> pitti, do you know what's the name the key for  "put window to the back" ?
[08:12] <pitti> org.gnome.desktop.wm.keybindings lower ['<Alt>b']
[08:13] <seb128> pitti, is your issue only with keys under org.gnome.desktop.wm.keybindings?
[08:13] <seb128> or do you have issues with compiz schemas keys?
[08:13] <pitti> j'ai ecrit un nouveau test de smb:// pour le gvfs
[08:14] <pitti> . o O { is gvfs male or female? }
[08:14] <seb128> "pour gvfs" we would say :p
[08:14] <pitti> seb128: windows+up/down are also broken right now; is that a compiz key?
[08:14] <pitti> seb128: what? no article? :-)
[08:15] <seb128> no, I'm trying to think what the rules is
[08:15] <seb128> like you would say "pour Canonical"
[08:15] <seb128> those things as proper name don't have an article
[08:15] <pitti> le français n'est past facile
[08:15] <seb128> non, il ne l'est pas ;-)
[08:15] <pitti> seb128: ah, merci
[08:18] <seb128> pitti, I'm trying to figure what those actions are
[08:18] <seb128> pitti, that's the maximize,unmaximize,minimize key right?
[08:18] <pitti> right
[08:18] <pitti> org.gnome.desktop.wm.keybindings minimize ['<Control><Primary><Alt>KP_0']
[08:18] <pitti> that looks strange
[08:19] <pitti> org.gnome.desktop.wm.keybindings maximize ['<Control><Primary><Super>Up']
[08:19] <pitti> that too
[08:19] <seb128> pitti, ctrl-super-up,down works here
[08:20] <pitti> but isn't it suposed to be win+up/down?
[08:20] <pitti> at least I configured it that way when they changed the default
[08:20] <pitti> and sometimes it works, and sometimes not
[08:21] <seb128> pitti, where did you configure it?
[08:22] <pitti> in g-c-c
[08:23] <seb128> pitti, what's the name of the action you use?
[08:23] <seb128> pitti, those are the max,restore win?
[08:25] <pitti> seb128: right; they were shown as ctrl+super+up/down in g-c-c, I just reset them back to super+up/down and that works now
[08:25] <pitti> (until I restart once or twice)
[08:25] <seb128> pitti, do you run another session than unity sometimes?
[08:25] <pitti> not for my user
[08:25] <seb128> pitti, those keys are common ones, I wonder if gnome-shell or something change them
[08:25] <seb128> hum, k
[08:25] <seb128> well, if compiz was making wrong use of the keys I would say it's a compiz bug
[08:26] <seb128> but it seems the value of those keys change on disk
[08:26] <seb128> so I'm a bit unsure what's going on
[08:26] <seb128> otherwise, https://launchpad.net/ubuntu/+source/compiz/1:<IP_ADDRESS>-0ubuntu1
[08:26] <seb128>   * debian/patches/ubuntu-config.patch:
[08:26] <seb128>       Ctrl + Super + Cursor up Maximises the current window
[08:26] <seb128>       Ctrl + Super + Cursor down Restores or minimises current window
[08:26] <seb128>
[08:27] <seb128> not sure if that's what we stayed on for precise or if that's one we reverted
[08:27]  * seb128 checks the source
[08:29] <pitti> I think ctrl+super is the current default
[08:29] <seb128> pitti, yeah, we have ctrl-super for those
[08:29] <pitti> so the issues is that sometimes my settings get reverted
[08:29] <seb128> so, something reset your user config sometime, will be fun to figure the something ...
[08:29] <pitti> and that autoraise behaviour is strange, as we do not defualt to autoraise
[08:30] <seb128> which one is that?
[08:30] <pitti> and unlike for the keybindings, the gsettings key for autoraise looks correct
[08:30] <pitti> err
[08:30] <pitti> or so it was yesterday
[08:30] <pitti> org.gnome.desktop.wm.preferences auto-raise true
[08:30] <pitti> org.gnome.desktop.wm.preferences auto-raise-delay 10000
[08:30] <pitti> now it seems it got set to true
[08:30] <pitti> #)*$#
[08:30] <seb128> :-(
[08:30] <seb128> so your bug is basically "something plays with gsettings keys and reset them"
[08:30] <pitti> well, at least that makes it more consistent
[08:31] <pitti> seb128: yes, except for autoraise
[08:31] <seb128> ?
[08:31]  * pitti resets autoraise and a-r-delay now and will check at next login
[08:31] <seb128> I though you just said the key got resetted as well?
[08:31] <pitti> seb128: no, the default for aut-raise is false (as it should be), and something set it to true
[08:32] <smspilla|z> seb128: can you tag is with "gsettings" ?
[08:32] <seb128> smspilla|z, sure
[08:33] <MCR1> pitti: Is it bug 1022743 ?
[08:33] <ubot2`> Launchpad bug 1022743 in unity "Shortcuts in CCSM reset after getting changed." [Low,In progress] https://launchpad.net/bugs/1022743
[08:33] <smspillaz|class> not the same thing no
[08:33] <smspillaz|class> probably a thinko when I ported the integration code :1~
[08:34] <smspillaz|class> pitti: right, compiz is playing with those keys :]
[08:34] <seb128> pitti, auto-raise is false in a guest session for me
[08:34] <smspillaz|class> tag the bug gsettings and 	I'll fix it
[08:34] <pitti> seb128: right
[08:34] <smspillaz|class> I wasn't able to write an autotest suite for the integration code [no time]
[08:34] <seb128> smspillaz|class, why would it write those keys at all if you don't use ccsm?
[08:35] <pitti> seb128: so next time I'll check if it really resets the key bindings, or just sets them to a different value
[08:36] <pitti> seb128: as for the autoraise key, that can't be a reset, it must actually set the key to true (for whatever strange reason)
[08:36] <pitti> could it be that there is some permanent gconf migration going on, and I have some gconf settings somewhere?
[08:36] <seb128> pitti, I get you can edit the schemas and put a weird default value (and run the glib-compile-schemas) helper for that
[08:37] <smspillaz|class> seb128: it just synchronizes keys
[08:37] <seb128> smspillaz|class, synchronize with what?
[08:37] <smspillaz|class> seb128: there are some gnome keys that it synchronizes with each other for non-trivial reasons
[08:37] <smspillaz|class> but let me have a look into it
[08:37] <seb128> ok
[08:38] <smspillaz|class> seb128: anyways, please tag any such regressions with "gsettings"
[08:38] <MCR1> this fix is also key-related and needs approval: https://code.launchpad.net/~mc-return/unity/unity.merge.fix-hardcoded-keys-part1/+merge/121545
[08:38] <pitti> I did use ccsm in the past for some bits (configuring FFM mostly)
[08:38] <pitti> smspillaz|class: I'll tag my bug
[08:38] <smspillaz|class> I expected there might be a few, I had to rush the integration code
[08:38] <seb128> smspillaz|class, done
[08:38] <smspillaz|class> pitti: btw, FFM is not a supported usecase :]
[08:38] <pitti> smspillaz|class: well, but changing key bindings in g-c-c certainly is?
[08:39] <smspillaz|class> sure, just keep that in mind
[08:39] <smspillaz|class> the bug priority will likely be downgraded
[08:39] <pitti> smspillaz|class: FFM is the one thing that never broke during this, just my keybindings and enabling autoraise
[08:39] <smspillaz|class> sure
[08:39] <seb128> pitti, gsettings-data-convert --dry-run --file /usr/lib/compiz/migration/compiz-profile-active-Default.convert
[08:39] <smspillaz|class> just letting you know :1~
[08:39] <smspillaz|class> :]
[08:39] <seb128> pitti, does that work or hit a schemas bug?
[08:40] <seb128> smspillaz|class, btw are the .convert upstream or ubuntu packaging stuff?
[08:40] <pitti> seb128: no error
[08:40] <pitti> seb128: and it seems to get the right values (after I set them in g-c-c)
[08:40] <pitti> Set key 'maximize' to string '<Super>Up'
[08:40] <pitti> Set key 'unmaximize' to string '<Super>Down'
[08:40] <pitti> Set key 'lower' to string '<Alt>b'
[08:41] <seb128> pitti, so it's not likely the migration running over again and screwing your values
[08:41] <seb128> pitti, does that include auto-raise?
[08:42] <pitti> seb128: no, the only hit of "raise" is the 'raise' keybinding
[08:43] <seb128> pitti, ok, in fact auto-raise is migrated by /usr/share/GConf/gsettings/wm-schemas.convert
[08:43] <seb128> which I guess is writen as migrated in .local/share/gsettings-data-convert for you
[08:44] <seb128> e.g has been migrated and will not be again
[08:45] <pitti> confirmed
[08:46]  * pitti loves the word "téléchargement"
[08:46] <seb128> ;-)
[08:46] <seb128> pitti, running your desktop in french?
[08:47] <pitti> oui
[08:47] <pitti> err
[08:47] <pitti> j'aime le mots "téléchargement"
[08:47] <pitti> "le mot"
[09:05] <chrisccoulson> hey seb128, how are you?
[09:08] <seb128> chrisccoulson, hey, good thanks you, how are you? no rain today yet? :p
[09:08] <chrisccoulson> seb128, heh, it's sunny at the moment
[09:08] <seb128> chrisccoulson, can't you use your phone as a modem btw?
[09:08] <chrisccoulson> not sure how long that's going to last though ;)
[09:09] <chrisccoulson> seb128, i tried that too, and that also didn't work
[09:09] <chrisccoulson> it seems everything is regressing in quantal ;)
[09:09] <chrisccoulson> my touchpad doesn't work properly either
[09:09] <chrisccoulson> although, that is bug 1041594
[09:09] <ubot2`> Launchpad bug 1041594 in linux "Edge scrolling on touchpad broken since the upgrade to 3.5.0-11" [Medium,Incomplete] https://launchpad.net/bugs/1041594
[09:11] <seb128> chrisccoulson, boot a precise kernel?
[09:12] <seb128> chrisccoulson, you probably still have it installed since we never clean those :p
[09:14] <chrisccoulson> seb128, i'm currently using the 3.5.0-10 quantal kernel, which works fine
[11:50] <Sweetsha1k> seb128: "13:47 <@pmladek> caolan: 3.6.1 should go out tomorrow if nothing happens; so it is basically done" <- we have a ppa build for that, but I will prepare one for quantal-proposed today, okay?
[11:51] <seb128> Sweetsha1k, works for me
[12:02] <chrisccoulson> awesome, i've got all of the ffox/tb branches all ready for the next set of releases, by lunchtime :)
[12:02] <chrisccoulson> can i haz 6 weeks off now? ;)
[12:02] <ogra_> if you dont need them to upload through your 3G :)
[12:02] <chrisccoulson> ogra_, chinstrap ;)
[12:02] <ogra_> haha
[12:02] <ogra_> cheater !
[12:02] <seb128> chrisccoulson, are you done with your workitems? do we have overlay scrollbars yet? ;-)
[12:03] <chrisccoulson> i've got the next set of releases all ready before we've even got the current one out ;)
[12:03] <chrisccoulson> seb128, hah :)
[12:03] <chrisccoulson> i knew there was something else!"
[12:03] <seb128> ;-)
[12:32] <chrisccoulson> whaaaaaaaaaaaaaaaaaaaaaaa
[12:32] <chrisccoulson> the upgrade wants to remove vim!
[12:32] <seb128> chrisccoulson, welcome to the world of emacs!
[12:32]  * pitti gets the torches ready
[12:33] <chrisccoulson> heh
[12:34] <seb128> chrisccoulson, it's firefox's fault right?
[12:34] <seb128> ;-)
[12:37] <chrisccoulson> heh
[12:37] <chrisccoulson> of course ;)
[12:56] <tkamppeter> seb128, you have sent out the reminder but it seems that you have forgotten to create https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-08-28
[12:57] <chrisccoulson> does http://summit.ubuntu.com/uds-r/sponsorship/review/ work for anyone else?
[12:57] <chrisccoulson> i just keep getting looped back to the login page
[13:00] <tkamppeter> chrisccoulson, same for me.
[13:02] <seb128> chrisccoulson, tkamppeter: it's not supposed to work, jasoncwarner made an error with his email, it's only available to ~uds-organizers
[13:03] <chrisccoulson> aha
[13:03] <seb128> you should tell jasoncwarner_ (or me) if you want somebody added or voted
[13:03] <seb128> tkamppeter, oh yeah, I forgot, seems like kenvandine just did it
[13:03] <kenvandine> ?
[13:03] <seb128> hey kenvandine, mterry, good morning ;-)
[13:04] <kenvandine> create the page?
[13:04] <kenvandine> good morning
[13:04] <seb128> kenvandine, <tkamppeter> seb128, you have sent out the reminder but it seems that you have forgotten to create https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-08-28
[13:04] <kenvandine> :-D
[13:04]  * kenvandine took matters in his own hands
[13:04] <kenvandine> :-p
[13:04] <seb128> thanks man ;-)
[13:04] <kenvandine> np
[13:04] <kenvandine> seb128, i think our bugs are related
[13:04] <seb128> kenvandine, I told you! ;-)
[13:04] <kenvandine> or rather the one you found is causing mine
[13:05] <kenvandine> but i think there is a bug in LMM too :)
[13:05] <seb128> kenvandine, is that xchat being buggy, did you figure out?
[13:05] <kenvandine> so here's what i think is happening
[13:05]  * seb128 listen
[13:05] <kenvandine> when i focus the chat it calls remove_source on one of the indicators
[13:05] <kenvandine> for the one xchat says is focused
[13:05] <kenvandine> at the same time, it is clearing the indicator i clicked on
[13:05] <kenvandine> so removing that one
[13:06] <seb128> oh, that disconnect the signal?
[13:06] <kenvandine> i think the one i am not clicking on, is sometimes not getting removed
[13:06] <kenvandine> or that
[13:06] <kenvandine> that makes more sense though
[13:06] <kenvandine> so i think that is why when we click on the other one
[13:06] <kenvandine> we don't get the callback
[13:06] <kenvandine> because of xchat
[13:06] <kenvandine> i can't figure that part out though
[13:07] <kenvandine> i don't see how that could have anything to do with our code
[13:07] <kenvandine> puzzling
[13:07] <seb128> yeah, me neither
[13:07] <seb128> but you said it was working before those updates?
[13:08] <kenvandine> yes
[13:08] <kenvandine> i checked last night
[13:08] <kenvandine> in precise
[13:08] <tkamppeter> seb128, under the sponsorship applications should be Kai-Uwe Behrmann, one of the two most important people (together with Richard Hughes) for color management under Linux. I would very much like if he gets funded to get to UDS.
[13:08] <kenvandine> i queued up 5 indicators
[13:08] <kenvandine> and went through them
[13:08] <seb128> tkamppeter, ok, thanks
[13:08] <kenvandine> they all worked
[13:08] <tkamppeter> kenvandine, thanks for setting up the page.
[13:08] <kenvandine> bo
[13:08] <kenvandine> np
[13:08] <kenvandine> :-D
[13:11] <seb128> kenvandine, on quantal how often does it not work? does the "not work" only concerns the last "active" channel (e.g the one that xchat consider selected wrongly and which leads to a source being cleared when it should not)?
[13:12] <kenvandine> at least 50%
[13:12] <kenvandine> seb128, but i really can't see why
[13:12] <kenvandine> it's very bazaar
[13:13] <seb128> kenvandine, indeed :-(
[13:13] <seb128> ok, channel, if you feel adventurous:
 https://launchpad.net/~unity-team/+archive/release updated, testing welcome although do note there are already a bunch of known bugs so check for duplicates
[13:14] <seb128>
[13:14] <seb128> that's the ffe unity,compiz-gles candidate stack
[13:14] <seb128> works fine out of minor details for me
[13:14] <kenvandine> and webapps right?
[13:14] <kenvandine> :-D
[13:14] <seb128> but having extra testing would probably be welcome
[13:14] <seb128> kenvandine, you wish :p
[13:16]  * ogra_ would love to help testing if there were any arm packages :/
[13:16] <seb128> ogra_, do you have a non virtual ppa to throw those sources at?
[13:16] <ogra_> especially since i just uploaded the (hopefully) final fix for our driver
[13:17] <ogra_> seb128, oh, indeed i should just be able to copy them to the canonical-arm ppa
[13:17] <seb128> ogra_, you should yes
[13:17] <seb128> ogra_, that would be great if you could try that ;-)
[13:21] <ogra_> seb128, argh
[13:21] <ogra_> if the packager would have actually allowed any arm arches in debian/control this would actually have worked :(
[13:22] <seb128> ogra_, unity you mean?
[13:22]  * ogra_ glares at https://launchpad.net/~canonical-arm-dev/+archive/ppa/+builds?build_state=pending .... nux, unity, compiz and bamf are all waiting for amd64 and i386 builds now
[13:22] <seb128> ogra_, I guess that's part of the workaround that was used by then when gles was not ready yet and nobody wanted to update the compiz patch
[13:22] <ogra_> yep
[13:22] <ogra_> might be
[13:23] <ogra_> or they just got tired of getting failure mails for the meissing arches
[13:23] <ogra_> *missin
[13:23] <ogra_> bah
[13:24] <seb128> ogra_, I'm pretty sure Didier did that before a2 or a3 because he needed to land the updates and nobody wanted to update the gles patch
[13:25] <ogra_> well, cant test then ... at least not without fiddling with the pakages which i dont have time for right now
[13:26] <seb128> ogra_, right, I will get that fixed and ping you for a new ppa copy
[13:27] <ogra_> seb128, great, else i can do it tomorrow myself
[13:27] <ogra_> just not today
[13:31] <seb128> ogra_, ok, let's see how things go
[13:39] <ogra_> oh, fun amd the copied packages actually FTBFS on i368
[13:39] <seb128> ogra_, yeah, their build-depends are not well versioned, you need the new bamf and nux
[13:40] <ogra_> which are in the same PPA (and copied) ... but if they arent versioned it wont o into dep-wait indeed
[13:40] <seb128> right
[13:40] <ogra_> hmpf, somehow my g key doesnt like me on that new kbd
[13:59] <chrisccoulson> hmmm, bugger, just updated my thunderbird nightly and it crashes every time i click on a source in the messaging indicator
[13:59] <chrisccoulson> that didn't happen this morning
[14:02] <seb128> chrisccoulson, :-(
[14:03] <cyphermox> chrisccoulson: btw if you want I can help making your 3G dongle work ;)
[14:03] <chrisccoulson> seb128, this one is going to be an absolute joy to debug: http://paste.ubuntu.com/1171850/
[14:03] <chrisccoulson> crashes deep in the JS engine ;)
[14:03] <seb128> :-(
[14:03] <chrisccoulson> cyphermox, oh, i'm not sure what's going on with that. i've rebooted again in to the 3.5.0-10 kernel, and it worked again :/
[14:03] <chrisccoulson> it seems quite random
[14:04] <cyphermox> ok
[14:04] <cyphermox> did you use a different usb port?
[14:04] <chrisccoulson> cyphermox, it's an internal 3G card
[14:04] <cyphermox> I have at least one dongle that refuses to work unless I use my USB 3.0 port
[14:04] <cyphermox> ah
[14:04] <cyphermox> chrisccoulson: internal 3G from the thinkpads? the Gobi horror?
[14:09] <chrisccoulson> cyphermox, it's one of these: http://search.dell.co.uk/1/2/128267-mobile-broadband-internal-dell-wireless-5540-card-3g-hsdpa-sim-not-included-kit.html
[14:10] <chrisccoulson> oh, man, there is a huge black cloud moving over here
[14:11] <cyphermox> chrisccoulson: do tell, how is fiber supposed to be affected by rain? :)
[14:13] <Mirv> ogra_: what did you discuss about compiz gles on arm? (I only joined after)
[14:13] <chrisccoulson> cyphermox, the bit from the cabinet to my house is still copper ;)
[14:13] <Mirv> ogra_: I'm compiling atm on arm without the patch just to see if the current problem is merely packaging
[14:13] <chrisccoulson> (but the cabinet is pretty much a stone-throw away from the house)
[14:14] <ogra_> Mirv, seb128 called for testers, and i'm just about to be done to have the pandaboard GLES driver ready for quantal ...
[14:14] <ogra_> so i would have tested
[14:14] <cyphermox> chrisccoulson: but it's wires? is it raining directly on the exposed wire?
[14:14] <Mirv> ogra_: ah, ok, so no testing yet. if it compiles for me, I'll update the packaging so that also staging & friends will work again on ARM
[14:14] <ogra_> awesome, thanks
[14:14] <cyphermox> seb128: still looking at pango for the lucid->precise upgrade
[14:15] <seb128> cyphermox, ok
[14:15] <cyphermox> seb128: I think I found the issue, but I'm not sure how to fix it
[14:15] <seb128> what is it?
[14:15] <chrisccoulson> cyphermox, i'm not sure where the rain gets in yet, although the cable that goes from my house across the road to the telegraph pole is probably a good bet :)
[14:16] <cyphermox> seb128: the libpango1.0-0.modules file moves from a non-multiarch dir to a multiarch dir
[14:16] <cyphermox> chrisccoulson: wow :(
[14:17] <cyphermox> seb128: problem is the actual execution; I'll do one more upgrade test to look at what happens to those files and figure out if it could just be a symlink added from /usr/lib/pango to /usr/lib/$arch/pango maybe
[14:20] <pitti> bonne nuit!
[14:20] <seb128> pitti, bonne après-midi
[14:20] <cyphermox> (or copying the new one in /etc/pango/pango.modules maybe) what I don't understand is why nobody noticed or filed a similar bug for another release upgrade between lucid and quantal
[14:20] <seb128> pitti, c'est pas encore la nuit
[14:20] <cyphermox> pitti: bonne nuit!
[14:20] <seb128> pitti, ou "bonne soirée"
[14:21] <seb128> cyphermox, is evolution the only app having that issue? didn't the hook you did to restart the service work?
[14:21] <cyphermox> nah
[14:21] <cyphermox> *any* application started after libpango1.0-0 would be affected
[14:22] <cyphermox> but it also needs to be something that wasn't upgraded yet, or it needs to happen between the time that pango is updated and something else
[14:22] <cyphermox> (or maybe a new dialog from a running app?)
[14:23] <seb128> ok
[14:32] <chrisccoulson> hmmmm, i'm gonna have to get bisecting
[15:06] <mvo> pitti: I addressed the aptdaemon points you raised, would be great if you could have a look at the MP again at some point :)
[15:30] <seb128> kenvandine, chrisccoulson, Ursinha, Laney, mlankhorst, cyphermox, mterry, Sweetshark, tkamppeter, robru: it's meeting time if anyone has a topic (none on the wiki so far), also please update https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-08-28 with things you worked on this week for those who didn't write anything yet
[15:43] <mterry> That was a quick meeting!  :)
[15:45] <seb128> mterry, I was wondering if I was still online, or if anyone was working today
[15:45] <seb128> usually I get at least a bunch of "hey, no topic from me" replies
[15:45] <mterry> hey, no topic from me
[15:45] <robru> seb128, work? nah
[15:46] <seb128> mterry, ;-)
[15:46] <robru> seb128, barry and I are working hard on this port, there's a lot done but also a lot left to do.
[15:46] <seb128> robru, yeah, what is this work thing everybody keeps talking about, right? ;-)
[15:46] <robru> ;-)
[15:48] <Sweetsha1k> seb128: my brother works in climate simulation (in cars, planes etc.). One day his boss called him, he recognized the number and answered the phone with: "$COMPANYNAME, we simulate work!'
[15:48] <robru> lol
[15:48] <Sweetsha1k> le boss was not amused ... and my brother made the perfect trollface.
[15:58] <jbicha> ricotz: you're working on the gdm changelog?
[15:58] <micahg> seb128: are we sticking with glew 1.8 for quantal?
[16:00] <seb128> micahg, I would think so, would you prefer to go for 1.9?
[16:01] <seb128> Sweetsha1k, lol
[16:01] <micahg> seb128: no, no preference, but I won't bother with 1.5, 1.6, and 1.7 rebuilds if we're not sticking with 1.8 :)
[16:01] <seb128> we do plan to stick with 1.8
[16:01] <micahg> ok, sounds good, thanks
[16:02] <jbicha> ricotz: or I could just diff fta's changelog & credit you with what's changed
[16:03] <ricotz> jbicha, i updated the changelog (just drop the file which sneaked in)
[16:03] <ricotz> jbicha, but give is some testing before you consider pushing it
[16:03] <ricotz> *it
[16:05] <jbicha> ricotz: yeah I've been testing it, except for the one major issue with gdm-fallback-mode I emailed you about, things are working well
[16:06] <jbicha> it also took me a bit of effort to even trigger fallback mode, but I'm going to try reporting that bug to GNOME
[16:06] <ricotz> jbicha, you emailed me before i uploaded it, and your patch wasnt right if you used it
[16:08] <jbicha> I've been using your 0827 ricotz0 build this morning
[16:09] <ricotz> jbicha, ok
[16:09] <ricotz> didnt see that issue
[16:13] <seb128> jbicha, did you forgot to push your g-c-c update?
[16:13] <seb128> jbicha, it's UNRELEASED in the vcs
[16:14] <ogra_> quantal is unreleased too :P
[16:14] <jbicha> seb128: done, GNOME wasn't interested in my patch by the way
[16:15] <seb128> jbicha, why not? too technical?
[16:15] <jbicha> they don't want terminal getting special treatment
[16:15] <seb128> ok
[16:15] <seb128> well I'm unsure about the ui bit for it
[16:16] <seb128> it might be enough to have it in g-s-d
[16:30] <Sweetsha1k> seb128: hmmm, the new libreoffice package is just as bad -- if not worse -- wrt unitymenus.
[16:31] <seb128> Sweetsha1k, "new", you got an update? what changed in good or bad?
[16:34] <chrisccoulson> lololololol @ https://twitter.com/paul_irish/status/240479498112475136
[16:35] <Sweetsha1k> seb128: well, afernandez asked be for an updated build. However, I see lots of menus having 'EMPTY STRING' as label now, and bug 1041354 isnt solved at all.
[16:35] <ubot2`> Launchpad bug 1041354 in libreoffice "unity-panel-service since yesterday uses ~100% CPU when libreoffice-gtk is installed and enabled" [High,Confirmed] https://launchpad.net/bugs/1041354
[16:36] <seb128> desrt, travelling I guess?
[16:49] <chrisccoulson> it's typical. when i want it to rain, it stays dry
[16:50] <chrisccoulson> never mind, the forecast for tomorrow is rain for the whole working day
[16:50] <ogra_> want to end your day early eh ?
[16:50] <chrisccoulson> i'd best make sure my 3G is working properly then :)
[16:50] <chrisccoulson> ogra_, no, i want to see if our line actually sounds noisier when it rains. my ISP wants to know ;)
[16:50] <seb128> chrisccoulson, start complaining louder to your ISP
[16:51] <ogra_> pee on it
[16:51] <chrisccoulson> lol
[16:51] <chrisccoulson> "sorry, i won't be working today. i got arrested overnight for indecent exposure after following advice from ogra"
[16:51] <ogra_> *g*
[16:53] <seb128> jbicha, you guys go the opposite direction from us, rather than being conservative you go for git snapshots? ;-)
[16:53] <seb128> gdm (3.5.90+git20120827.b558e179-0ubuntu1) quantal; urgency=low
[16:53] <seb128> "  * TODO: the following Ubuntu patches need to be ported:"
[16:53] <seb128> not cool :-(
[16:53] <jbicha> seb128: just be glad we're not responsible for nautilus
[16:54] <seb128> jbicha, lol
[16:54] <seb128> jbicha, I wouldn't be woried, you couldn't break it over what upstream has done :p
[16:58] <jbicha> guest session really ought to be built into GNOME
[16:58] <Sweetsha1k> oh, nautilus is still such a mess? I remember it from back in the days ...
[16:59] <jbicha> guest session was mentioned this morning as a workaround for https://bugzilla.gnome.org/show_bug.cgi?id=676577
[16:59] <ubot2`> Gnome bug 676577 in general "There is not a place for the user to set Privacy or Security related options" [Enhancement,New]
[17:16] <mterry> kenvandine, I was thinking of rolling a new light-themes (I committed a unity-greeter-specific change there).  Any objection?
[18:02] <kenvandine> mterry, nope
[18:02] <kenvandine> go for it
[18:24] <mterry> kenvandine, done
[18:35] <jbicha> ricotz: did you know that the gdm login screen looks different if you were still using gnome-shell 3.5.4?
[18:35] <jbicha> it also looks like gdm won't load if gnome-shell isn't installed (probably part of why Debian force gdm-fallback-mode)
[18:37] <jbicha> so I'm going to bump gnome-shell to a depends
[18:38] <micahg> that'll be a fun upgrade :), if gdm isn't removed on upgrade from lucid -> precise, when you upgrade to quantal you get gnome-shell
[18:38] <micahg> s/unity-2d/gnome-shell/ :)
[18:39] <jbicha> micahg: yeah I don't think the gdm developers have tried running gdm without gnome-shell :|
[18:41] <chrisccoulson> getting gnome-shell after the upgrade wouldn't be the end of the world ;)
[18:44] <chrisccoulson> seb128, oh, the crash i see is definitely a thunderbird regression (in nightly), and not my addon. so it doesn't affect quantal (yet) ;)
[18:44] <seb128> chrisccoulson, \o/
[18:45] <chrisccoulson> it's taking agest to bisect though because there are so many commits which touch the build system and trigger a full rebuild
[18:45] <chrisccoulson> which is a pain
[18:45] <jbicha> ricotz: it looks like lightdm works with gnome-shell as long as gdm is installed, Switch Session won't work and if you lock your screen you can't unlock it...
[18:45] <jbicha> Switch Session does nothing
[18:45] <seb128> jbicha, you should talk to robert_ancell about getting lightdm to support those
[18:46]  * micahg is happy that his latest round of Firefox/Thunderbird crashes appear to have been due to a bad stick of TAM
[18:46] <micahg> *RAM
[18:46] <seb128> it seems like the GNOME guys are settings for a "GNOME or nothing" which is a bit annoying
[18:46] <seb128> I guess at some point it will be impossible to get GNOME for most distros
[18:49] <dobey> s/GNOME/Fedora/
[18:49] <seb128> yeah, there is a bit of that...
[18:50] <seb128> not sure if that's a good move being done for GNOME as a project and community though
[18:50] <seb128> they move to "let's fix the stack" to "we define the stack and everybody else can go play somewhere else"
[18:50] <dobey> it seems a bit overzealous, ideological, and utopian; the whole "GNOME OS" thing
[18:51] <seb128> things like lock screen or login manager should be a fdo interface
[18:51] <chrisccoulson> gah, ffs @ bug 1042894
[18:51] <ubot2`> Launchpad bug 1042894 in thunderbird "Thunderbird hangs at startup only on laptop" [Undecided,New] https://launchpad.net/bugs/1042894
[18:51] <chrisccoulson> 2 copies of eds being loaded?
[18:51] <seb128> they moved from ... to*
[18:51] <cyphermox> O.o?
[18:52] <seb128> chrisccoulson, aka the pre-upgrade version is still running and user didn't restart?
[18:53] <chrisccoulson> seb128, actually, looking at https://launchpadlibrarian.net/113859523/Extensions.txt, i suspect that the couchdb addon loads an old eds ABI
[18:53] <chrisccoulson> i should just kill that entirely
[18:53] <seb128> it's about time ;-)
[18:55] <chrisccoulson> ah, i bet that's the reason for bug 1040839 too
[18:55] <ubot2`> Launchpad bug 1040839 in evolution-data-server "Thunderbird hangs accessing eds on startup" [Undecided,New] https://launchpad.net/bugs/1040839
[18:58] <chrisccoulson> yay @ the third item on http://www.mozilla.org/en-US/thunderbird/15.0/releasenotes/ ;)
[18:58] <seb128> \o/
[19:09] <Ursinha> bryceh, hello
[19:10] <Ursinha> bryceh, I believe I've been hitting bug 932900, could you enlighten me with ideas on how to figure out if it's the same problem?
[19:10] <ubot2`> Launchpad bug 932900 in mesa "Unity freeze, crashes when trying to restart - intel_do_flush_locked failed: Input/output error" [Undecided,Fix released] https://launchpad.net/bugs/932900
[19:21] <jbicha> kenvandine: how are you deciding which account plugins should be recommends and which should be suggests?
[19:21] <jbicha> will there be a way in the UI for users to install additional plugins?
[19:22] <kenvandine> just with software center i guess
[19:22] <jbicha> ok, should IRC be installed by default?
[19:22] <kenvandine> seb128 and i did a quick brain storm to pick what is there
[19:22] <kenvandine> no, telepathy-idle isn't
[19:23] <seb128> jbicha, @IRC: no
[19:23] <seb128> if users want IRC they are better served getting an IRC client from s-c
[19:23] <seb128> im client doing IRC are poor choices
[19:23] <seb128> mho
[19:23] <seb128> imho
[19:23] <mterry> chrisccoulson, nice re: U1 in thunderbird
[19:24] <jbicha> so connecting to #ubuntu requires installing extra software?
[19:24] <seb128> so far yes, is #ubuntu an user recommended contact point?
[19:24] <seb128> we should maybe figure a way to web proxy there...
[19:25] <jbicha> it's listed at http://www.ubuntu.com/support
[19:25] <seb128> IRC stays a really specialized medium, look at the number of people on IRC compared to e.g forums or askubuntu
[19:25] <seb128> imho we should better direct user to those sites
[19:26] <seb128> (just my opinion
[19:26] <seb128> ups
[19:27]  * micahg would still be using pidgin for IRC if it wasn't for the freenode flood issue I could never track down
[19:28] <bryceh> Ursinha, anything in /sys/kernel/debug/dri/0/i915_error_state attached ?
[19:28] <micahg> there's http://webchat.freenode.net/ also
[19:29] <micahg> seb128: maybe a .desktop file linking to ^^ if #ubuntu is useful
[19:29] <micahg> or whatever the URL with the channel in it would be
[19:30]  * mterry is going afk for a bit
[19:30] <seb128> jbicha as being a documentation team member is probably better placed that me to reply
[19:30] <kenvandine> seb128, where is the packaging branch for unity staging?
[19:30] <seb128> but I don't think IRC is a good end user recommendation
[19:30] <seb128> kenvandine, ~/staging/unity/ubuntu
[19:30] <seb128> kenvandine, :-p
[19:31] <seb128> kenvandine, there is none, what's up?
[19:31] <kenvandine> i am having to patch unity, and want to base it off staging for now
[19:31] <kenvandine> since it has all the previews stuff and all
[19:34] <Ursinha> bryceh, there's nothing in /sys/kernel/debug
[19:34] <Ursinha> (sorry, was answering the door)
[19:35] <bryceh> Ursinha, are you able to reproduce the bug deliberately?
[19:35] <Ursinha> bryceh, whenever I try to unity --replace, it gives me that error message
[19:36] <Ursinha> I'm right now using metacity --replace to be able to talk to you here
[19:36] <bryceh> ok good
[19:37] <bryceh> Ursinha, ssh into your system from another one and then do unity --replace to lock the system up.  Then, from ssh collect /sys/kernel/debug/dri/0/i915_error_state and post to the bug
[19:38] <bryceh> if you have 'IPEHR: 0x7a000002' in that file, then you probably have the same bug
[19:39] <Ursinha> it doesn't exactly lock, it becomes impossible to move windows or use alt-tab
[19:39] <bryceh> Ursinha, ok interesting.  Still, reproduce that failure case and we can verify whether or not it's a gpu lockup
[19:39] <Ursinha> ok, a moment
[19:42] <Ursinha> bryceh, here's the output of unity --replace: http://paste.ubuntu.com/1172430/
[19:43] <Ursinha> there you go, the debug file is there
[19:43] <Ursinha> let me look for the specific thing you said
[19:44] <Ursinha> bryceh, no, I see only 'IPEHR: 0x00000000' in i915_error_state
[19:45] <Ursinha> do you want me to attach it to that same bug, or should I open another?
[19:46] <bryceh> Ursinha, there's several IPEHR's in the debug file; try grep IPEHR /sys/kernel/debug/dri/0/i915_error_state
[19:47] <bryceh> if that still results in just zeros, then yeah let's get a new bug filed about that.
[19:47] <Ursinha> I did that, it returned three, all of them like this one
[19:47] <bryceh> hm, ok
[19:49] <Ursinha> bryceh, ok, so how do I file the perfect bug? :)
[19:58] <Ursinha> bryceh, against which package should I file this bug?
[20:02] <bryceh> Ursinha, for now file it against xorg as usual.  ubuntu-bug xorg.  Include your unity --replace output, the i915_error_state file, and dmesg
[20:03] <Ursinha> I see some stacktraces on dmesg
[20:03] <Ursinha> will do, just a moment
[20:03] <bryceh> ho ho!  that's a good sign
[20:03] <Ursinha> :)
[20:04] <bryceh> Ursinha, fwiw I'm not familiar with the "intel_do_flush_locked failed" error message but it sort of sounds like a generic "I couldn't talk to the gpu" message, in which case that may be misleading you to think you have bug #932900 when it could be something different entirely
[20:04] <ubot2`> Launchpad bug 932900 in mesa "Unity freeze, crashes when trying to restart - intel_do_flush_locked failed: Input/output error" [Undecided,Confirmed] https://launchpad.net/bugs/932900
[20:05] <Ursinha> right
[20:05] <Ursinha> do you know what is that IPEHR value?
[20:07] <bryceh> IPEHR: 0x7******* errors typically indicate a fault in the renderer (mesa)
[20:08] <bryceh> so Giovanni's bug looks to be mesa related.  Yours is sounding more like the kernel, if you're getting traces in dmesg
[20:09] <Ursinha> right, this is cool
[20:11] <bryceh> Ursinha, oh I forgot to ask, what video card you are on?
[20:15] <Ursinha> bryceh, it's an intel generic one, I have a lenovo x220
[20:16]  * Ursinha is looking for specifics
[20:19] <bryceh> Ursinha, ok intel generic's sufficient to know
[20:19] <tjaalton> Ursinha: is this after you resume from suspend?
[20:20] <Ursinha> tjaalton, nope, I was moving windows from one side to another and it happened
[20:20] <Ursinha> I meant, the first crash, the unity --replace issue I can reproduce consistently at this moment
[20:20] <tjaalton> ok, bug 966744 was the one I was after
[20:20] <ubot2`> Launchpad bug 966744 in xserver-xorg-video-intel "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/966744
[20:21] <tjaalton> nevermind then :)
[20:21] <Ursinha> :)
[20:24] <Ursinha> bryceh, maybe it's worth mentioning the first crash happened when I was using an external monitor in a dock?
[20:24] <Ursinha> I'm undocked now
[20:36] <Ursinha> hmm.
[20:36] <Ursinha> bryceh, there are two folders in /sys/kernel/debug/dri/: 0 and 64
[20:37] <Ursinha> I just noticed the i915_error_state in the 0 one is empty
[20:37] <bryceh> Ursinha, 0 is the one to use
[20:38] <Ursinha> the 64 one has the IPEHR info, the other one is empty... do you know why is that?
[20:38] <bryceh> Ursinha, docking is worth mentioning, although hard to say at this point if it's relevant
[20:39] <bryceh> I'm not sure why there is a 64 dir.
[20:41] <Ursinha> these crashes seem rather old. none of these files were touched today, but Aug. 21 -- I've been having these for a while, was lucky to find that bug on a google search
[20:44] <mterry> Rhythmbox seems broken
[20:44] <mterry> due to U1 plugin...
[20:51] <Ursinha> bryceh, bug 1042947
[20:51] <bryceh> thx
[20:51] <Ursinha> thanks for the pointers, bryceh
[20:53] <bryceh> sure
[20:56] <bryceh> Ursinha,  Uname: Linux 3.4.0-030400rc4-generic - do you have a non-standard kernel installed by chance?
[20:57] <Ursinha> bryceh, I installed this a while ago because of another bug that I don't recall right now, it was asked to test with a newer kernel package than the default... will have to dig a bit
[21:01] <bryceh> Ursinha, hmm [575708.158540] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[21:01] <bryceh> [575708.158545] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[21:01] <bryceh> Ursinha, so seems you *are* having a gpu lockup but guess it's resetting the gpu and continuing.
[21:02] <bryceh> the i915_drv.c:398 gen6_gt_check_fifodbg warnings seem pertinent
[21:02] <Ursinha> bryceh, hm. why that error file is empty I don't know
[21:02] <Ursinha> bryceh, is there anything I could do to help debugging the issue?
[21:03] <Ursinha> installing a package, a procedure or something
[21:07] <bryceh> Ursinha, when the gpu is reset, that file is zero'd out
[21:07] <Ursinha> oh, right
[21:07] <bryceh> the kernel will try to reset the gpu when it notices it gets locked, which appears to be what's happening here
[21:08] <bryceh> Ursinha, there is a gpu lockup detector udev rule which is turned off in precise that you could try turning back on
[21:08] <Ursinha> sure
[21:09] <bryceh> SUBSYSTEM=="drm", ACTION=="change", ENV{RESET}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.p
[21:09] <bryceh> y"
[21:09] <bryceh> that's the rule that's needed
[21:10] <bryceh> in xdiagnose-2.5.2/debian/xdiagnose.udev it is commented out
[21:10] <bryceh> grab that package, uncomment the line, rebuild, install, (reboot?) and that should theoretically enable the gpu error collector
[21:12] <Ursinha> all right, will do that now
[21:16] <bryceh> Ursinha, since you're able to repro this fairly easily, another thing I'd like you to try is boot to the current stock precise kernel and repro it with that.
[21:16] <Ursinha> right
[21:16] <bryceh> if this ends up just being a flaw in one of the interim mainline kernels, might not be worth your time to do a lot of debugging on it
[21:16] <Ursinha> makes sense
[21:25] <Ursinha> okay, the rule is there, I'll let you know if anything happens bryceh
[21:25] <Ursinha> thanks again!
[21:25] <bryceh> great, good luck
[21:25] <Ursinha> thanks
[21:54] <rickspencer3> kenvandine, if I have a machine with the webapps PPA, and I distupgrade it to Quantal, I should be fine right? don't need to do anything special first?
[21:56] <seb128> rickspencer3, not sure about quantal, ken said he had unity segfaulting when updating to unity staging the other dya
[21:56] <seb128> day
[21:56] <seb128> rickspencer3, the webapp abi changed slightly between their ppa and the official version that landed apparently
[21:57] <rickspencer3> seb128,well, a dist-upgrade should remove the PPA version and install the one in archives, right?
[21:57] <seb128> rickspencer3, if the archive version are > ppa
[21:57] <rickspencer3> hmmmm
[21:57] <seb128> which usually they are not
[21:57] <seb128> otherwise you couldn't install the ppa packages
[21:57] <rickspencer3> well, at some point the archive will pass the PPA, and I'll be good
[21:58] <seb128> yeah, "some point" ;-)
[21:58] <rickspencer3> well, I'm on Precise on this machine
[21:58] <rickspencer3> I am going to move it to Quantal now
[21:58] <seb128> not sure what's their versioning in thar regard
[21:58] <rickspencer3> I should keep one on Precise, I suppose, but I can't help myself
[21:58] <seb128> but I would recommend to ppa-purge first
[21:58] <rickspencer3> ok
[21:58] <rickspencer3> will do
[21:59] <seb128> keeping a machine on precise is good btw ;-)
[21:59] <seb128> I upgraded recently but I miss my precise :p
[21:59] <rickspencer3> hmmm
[21:59] <rickspencer3> maybe I should just keep this one Precise
[21:59]  * rickspencer3 ponders
[22:52] <jasoncwarner_> morning everyone. bryceh TheMuso RAOF robert_ancell meeting reminder. https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-08-28 please update with your items and add any agenda items you want to talk about.
[22:52] <bryceh>  \o/
[22:54] <robert_ancell> bryceh, you are way too happy about meetings
[22:54] <bryceh> robert_ancell, heh
[22:54] <bryceh> robert_ancell, at least it's a nice break from looking at X crashes and GPU lockups
[22:56] <robert_ancell> bryceh, :)