[01:15] <RAOF> robert_ancell: Good morning!
[02:23] <robert_ancell> RAOF, yo
[02:23] <RAOF> Hey, ho!
[02:24] <RAOF> Got the compositor up and running?
[02:26] <robert_ancell> RAOF, not yet, but just updated
[02:27] <RAOF> As I said, you'll need to remove vesa and fbdev; they aren't compatible with xwayland, but get autoloaded and then the “this module can't work” code isn't quite right.
[02:27] <robert_ancell> ok
[02:28] <robert_ancell> RAOF, we need a list of blocker bugs that need to be fixed to make it to release, e.g. picking the wrong video card, certain video drivers not working
[02:29] <RAOF> Yup.
[02:35] <RAOF> robert_ancell: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1022423 filed and linked to the blueprint.
[02:35] <ubot2> Ubuntu bug 1022423 in xorg-server "VESA and fbdev drivers get loaded and break the server under XWayland" [High,Triaged]
[02:36] <robert_ancell> RAOF, is there one for picking the wrong video card, or is that a udev issue?
[02:39] <RAOF> There's not yet one for picking the wrong card; I'll file that, too.
[02:48] <RAOF> robert_ancell: It's now bug #1022424
[02:48] <ubot2> Launchpad bug 1022424 in weston "Can pick wrong DRM device" [Undecided,New] https://launchpad.net/bugs/1022424
[03:17] <robert_ancell> RAOF, hey, are you able to update the debian colord package easily? http://paste.ubuntu.com/1082169/
[03:18] <robert_ancell> or even http://paste.ubuntu.com/1082170/ (without an accidental whitespace change)
[03:18] <RAOF> robert_ancell: Yup, can do. Although I'll be getting around to colord 0.1.22 shortly.
[03:18] <robert_ancell> cool flick that change in then
[03:24] <RAOF> robert_ancell: Hey, you've used google docs recently, right? How do I embed a drawing that I foolishly made separately into a document?
[03:25] <robert_ancell> RAOF, i.e. copy and paste from one document to another?
[03:25] <RAOF> Yeah, I guess so.
[03:26] <robert_ancell> I don't know if I managed that, but I do remember finding limitations like that
[03:28] <RAOF> Ah. And apparently insert->picture is a filthy lie.
[03:38] <pitti> Good morning
[03:42] <pitti> robert_ancell: hey Robert, how are you?
[03:42] <robert_ancell> pitti, hello, good
[03:44] <pitti> robert_ancell: did you recently use simple-scan to scan more than some 5 pages for a document? it's painfully crashy for me these days
[03:44] <pitti> i. e. I scan 5 or 8 pages, then it crashes, and I have to do it all over again
[03:45] <robert_ancell> pitti, no, but there have been some crashers reported
[03:45] <pitti> I had to resort to my old CLI script
[03:45] <pitti> yes, I reported the ones I got as well
[03:45] <pitti> no> you can't reproduce, or you didn't try to scan several pages?
[03:45] <pitti> bug 1022040
[03:45] <ubot2> Launchpad bug 1022040 in simple-scan "simple-scan crashed with SIGSEGV in pixman_op()" [Medium,New] https://launchpad.net/bugs/1022040
[03:46] <pitti> might just as well be a GTK bug, I'm not sure
[03:46] <pitti> crash in gtk_widget_set_sensitive(), could be that it crashes when it disables the "Scan" button when I press Ctrl+1 ?
[03:46] <pitti> i. e. not related to the actual SANE part at all?
[03:47] <robert_ancell> I haven't reproduced, but I do know of at least one reproducable crasher
[03:48] <robert_ancell> pitti, can you reproduce by running 'simple-scan test'?
[03:48] <robert_ancell> I'm mashing the ctrl+1 key here and not reproducing
[03:48] <pitti> oh, what does that do?
[03:48] <pitti> a fake scanner?
[03:48] <robert_ancell> pitti, uses the 'test' sane driver
[03:48] <robert_ancell> so yes
[03:49] <pitti> hm, it doesn't actually disable the "scan" button while the scan is in progress
[03:49] <pitti> which widget does it try to make insensitive?
[03:49] <robert_ancell> pitti, no, it should queue a new page
[03:49] <pitti> oh, the stop button perhaps
[03:50] <robert_ancell> if you start a new document with a number of queued pages it crashes when the next page comes
[03:50] <pitti> hm, threading issue perhaps
[03:50] <robert_ancell> likely
[03:51] <pitti> I don't seem to get it with "test", or I'm just being lucky this morning
[03:52] <pitti> robert_ancell: how hard would it be to save the current deck of scanned pages to a temporary file and reload it on next startup?
[03:52] <robert_ancell> pitti, there is a patch for that using sqlite but I haven't got it to work
[03:52] <pitti> uhh, sqlite?
[03:53] <robert_ancell> bug #897469
[03:53] <ubot2> Launchpad bug 897469 in simple-scan "Simple Scan crashes result in preventable data loss" [High,In progress] https://launchpad.net/bugs/897469
[03:53] <pitti> I had expected just saving the individual PNGs or JPGs
[03:53] <robert_ancell> pitti, you need the metadata too really
[03:53] <pitti> ah, for rotation and clipping?
[03:53] <robert_ancell> yeah, stuff like that
[03:54] <robert_ancell> color profiles etc
[05:42] <robert_ancell> RAOF - http://paste.ubuntu.com/1082274/ still no luck it seems
[05:42] <rickspencer3> hi robert_ancell, RAOF, jasoncwarner_, TheMuso and other .au folks :)
[05:43] <RAOF> robert_ancell: ‘wl_display_create failed’ suggests that it's not finding the... oh.
[05:43] <RAOF> rickspencer3: Yo!
[05:43] <jasoncwarner_> hey rickspencer3
[05:44] <RAOF> test: ‘wl_display_create failed’ suggests that it's not finding the wayland socket.
[05:44] <pitti> hey rickspencer3, ca va?
[05:44] <rickspencer3> oops, looks like I interupted some xorg debugging ;)
[05:44] <rickspencer3> bonhour piti, ça va :)
[05:44] <RAOF> robert_ancell: Because the segfault is in the failure path. (Yay!)
[05:45] <robert_ancell> RAOF, at least we're getting good test coverage then :)
[05:45] <RAOF> robert_ancell: :)
[05:45] <RAOF> The rest of the francophone contingent arrives!
[05:45] <didrocks> good morning :)
[05:45] <didrocks> hey RAOF ;)
[05:46] <RAOF> Good morning :)
[05:46] <didrocks> how was your week-end?
[05:47] <RAOF> Pretty good. Almost cleared enough of my office to move a sofa in there from the bedroom so I can assemble the cot ;)
[05:47] <RAOF> My office looks a *lot* bigger without a bunch of boxes in it!
[05:47] <robert_ancell> RAOF, so sudo weston works.  Does that suggest I've done something wrong and it's just X failing to tell me nicely?
[05:48] <RAOF> robert_ancell: You mean, running X under ‘sudo weston’ works, but running it under weston-as-user dies in this fashion?
[05:49] <robert_ancell> RAOF, oh duh, that doesn't run X at all..
[05:49] <RAOF> X *is* telling you nicely (before it segfaults ☺) - it says [   418.249] (EE) intel(0): Failed to initialize xwayland.
[05:49] <robert_ancell> is there an easy way to do that?
[05:49] <RAOF> robert_ancell: weston --xserver
[05:49] <RAOF> Then start an X app, and it'll transparently start an xwayland server for you.
[05:50] <robert_ancell> RAOF, yep, that worked
[05:50] <robert_ancell> OK, so I'll assume it's in my code then
[05:51] <RAOF> I'll check again that simple-display-manager actually starts an X server, but it's probably your code, yes.e
[05:52] <robert_ancell> RAOF, gtg, thanks for that.
[07:21] <RAOF> Bah. So much for escaping the cold Sam's recovering from... :(
[07:37] <seb128> hey
[07:39] <mlankhorst> morning seb128 :)
[07:39] <pitti> bonjour seb128
[07:39] <seb128> hey mlankhorst, pitti, how are you?
[07:40] <pitti> seb128: I'm great, thanks! how about you?
[07:40] <seb128> I'm good thanks!
[07:40] <pitti> we had a really nice weekend, spending a lot of time gardening and enjoying the sun
[07:40] <pitti> for a change, no travel and no guests :)
[07:40] <mlankhorst> im good, weekend was terrible and rainy :)
[07:41] <didrocks> guten morgen pitti, mlankhorst :)
[07:41] <pitti> bonjour didrocks, ca va?
[07:42] <seb128> pitti, saturday was nice weather here, yesterday a bit rainy but since that was wimbledon finals' day that was ok ;-)
[07:42] <didrocks> pitti: ça va bien! good week-end here as well :)
[07:42] <didrocks> no rain, quite warm weather :)
[07:42] <mlankhorst> but visited a friends place so I had fun, f-zero and super smash brother doesn't need good weather
[07:43] <pitti> seb128: I have a fix ready for bug 972436; but current apport SRU still has 4/5 unverified, so it's blocked :(
[07:43] <ubot2> Launchpad bug 972436 in apport "backend_helper.py crashed with UnicodeEncodeError in apport_excepthook(): 'ascii' codec can't encode character u'\xe8' in position 166: ordinal not in range(128)" [High,Confirmed] https://launchpad.net/bugs/972436
[07:43] <pitti> mlankhorst: these sound like games?
[07:45] <mlankhorst> pitti: f-zero is a game from the gamecube working on wii, ssb is a series with a wii version
[07:45] <mlankhorst> I'm probably going to buy the wii-u just for that game
[07:45] <didrocks> f-zero is a snes game in fact :p
[07:46] <didrocks> in its first form
[07:46] <mlankhorst> ah could be
[07:46] <didrocks> "could be", it's when didrocks starts to feel old :)
[07:46] <didrocks> http://www.youtube.com/watch?v=2T5u9nD_I0I
[07:47] <didrocks> impressive speed sensation at the time using the snes mod 7 ;)
[07:47] <seb128> pitti, hum, k, let's try to get that SRU verified this week then
[07:47] <mlankhorst> sigh, the vfs tree I need to avoid deadlocks doesn't boot
[07:49] <pitti> seb128: I'll work on improving the D-BUS exception support in the meantime, perhaps we can fold that into the next SRU as well
[07:49] <seb128> pitti, that would be great! would make didrocks happy as well, his top bug on oneconf is one of those ;-)
[07:50] <didrocks> \o/
[07:50] <didrocks> juts for that, I'll fix the latest issue introduced recently by python-distutils-extra :)
[07:51] <Laney> g'morning
[07:52] <seb128> Laney, hey, how are you?
[07:52] <didrocks> hey Laney
[07:52] <Laney> hey, yeah good
[07:53] <Laney> nice weekend of cycling and trying to return to climbing after injury :-)
[07:53] <seb128> Laney, injury during climbing?
[07:53] <seb128> or just an injury that made you stop climbing for a while?
[07:54] <Laney> well, both. I injured the "pulleys" on some of my fingers
[07:54] <Laney> still not completely healed but I think I can start gently again to help it recover
[07:55] <seb128> ok
[07:58] <tkamppeter> pitti, hi
[07:59] <pitti> hello tkamppeter
[08:00] <tkamppeter> pitti, can you have a look at bug 763867, comment #7 and comment #8?
[08:00] <ubot2> Launchpad bug 763867 in cups "Canon binary 32-bit drivers can not be installed on Ubuntu 12.04" [Undecided,Confirmed] https://launchpad.net/bugs/763867
[08:05] <pitti> tkamppeter: replied
[08:06] <didrocks> pitti: so the .decode('UTF-8') in http://launchpadlibrarian.net/107350300/python-distutils-extra_2.32-5_2.33-1.diff.gz brought some new warning on precise and quantal with Quickly
[08:06] <didrocks> pitti: basically the file contains already the magic "I'm an utf-8 encoded file"
[08:06] <didrocks> then .decode tells:
[08:06] <didrocks> WARNING: syntax errors in foo/FooWindow.py: encoding declaration in Unicode string (FooWindow.py, line 0)
[08:07] <pitti> le huh?
[08:07] <didrocks> seems this should be silent, no?
[08:07] <pitti> I'm afraid I don't understand
[08:07] <didrocks> ok, so, the files in Quickly all contains: # -*- Mode: Python; coding: utf-8; indent-tabs-mode: nil; tab-width: 4 -*-
[08:07] <pitti> 2.33-1 changed the open() call to be binary and decodes from UTF-8 itself
[08:07] <pitti> as otherwise it depends on the system locale
[08:08] <pitti> didrocks: sure, and they'll have to if they contain non-ASCII characters with python2
[08:08] <didrocks> indeed
[08:08] <pitti> that patch wouldn't have changed that behaviour at all
[08:08] <didrocks> seems that if you call .decode('UTF-8') on such a binary flow, you get the above warning
[08:08] <didrocks> pitti: I tried by commenting the .decode() call, and indeed, no more warning
[08:09] <pitti> then you call ast with bytes, not a string
[08:09] <didrocks> yeah
[08:09] <pitti> that seems wrong, though
[08:09] <didrocks> but even the previous revision didn't get any warning, when you opened the file as string
[08:09] <didrocks> (I tried to revert the stenza)
[08:09] <didrocks> I would have thought this was equivalent to what you are doing now
[08:10] <pitti> ah, I guess in python2 open(.., 'r') still returned bytes
[08:10] <didrocks> oh right, it's python 2 :)
[08:10] <didrocks> so ast has no issue to accept bytes
[08:10] <pitti> did you try with py3?
[08:10] <didrocks> but I agree it's not the trendline to move everything with string :)
[08:11] <didrocks> no, I didn't
[08:11] <didrocks> but not sure we want to change to py3 on precise :)
[08:11] <pitti> sure, but I didn't upload that to precise, only to quantal
[08:11] <didrocks> pitti: it's in precise-proposed
[08:11] <pitti> so, that seems easy enough to reproduce in a test case
[08:12] <didrocks> https://launchpad.net/ubuntu/+source/python-distutils-extra/2.33-0ubuntu0.1
[08:12] <pitti> oh, someone backported the whole new version
[08:13] <pitti> didrocks: so yeah, can you please report a bug for this? we should add a test case with an utf-8 marker
[08:13] <pitti> then the py2 run should fail
[08:13] <pitti> and we can either toss bytes to ast or do a sys.version_info.major test
[08:13] <tkamppeter> pitti, thanks.
[08:13] <didrocks> pitti: I can report a bug, but not sure what's the best strategy to really fix it?
[08:14] <pitti> didrocks: see my previous line :)
[08:15] <didrocks> pitti: is it the best fix? seems to be .decode('UTF-8') shouldn't bail if the decoded associated binary is specifying UTF-8
[08:15] <pitti> didrocks: it's not the .decode() that generates the warning; it's ast
[08:15] <pitti> didrocks: you hand an unicode object to ast in python2, and ast encounters an encoding line in the source; that's what's generating the warning
[08:16] <pitti> all of that madness went away in py3 (source is required to be UTF-8 encoded, and no tag is necessary any more)
[08:16] <pitti> but at least in python2 we need to feed bytes to ast apparently
[08:17] <didrocks> pitti: ah, because ast in that case think that if there is an encoding line in the object passed to it, it should be binary?
[08:17] <pitti> apparently
[08:17] <didrocks> ok, got it now, will file a bug, test case and a fix :)
[08:17] <pitti> cheers!
[08:17] <didrocks> thanks pitti :)
[08:17] <pitti> didrocks: so this p-d-e should be verification-failed then
[08:18]  * pitti hugs didrocks, merci
[08:18] <didrocks> indeed :)
[08:18]  * didrocks hugs pitti
[08:26] <didrocks> confirmed in an ipython
[08:26] <Laney> seb128: did you get anywhere on that gsd patch?
[08:26] <Laney> if not then I'll look at it now
[08:27] <seb128> not yet, feel free to look at it
[08:28] <Laney> k
[09:09] <didrocks> pitti: when you get some time: https://code.launchpad.net/~didrocks/python-distutils-extra/fix-warning-using-python2/+merge/113928
[09:12] <pitti> didrocks: merged, thanks!
[09:12] <didrocks> pitti: do you mind if I do a release? I want to backport that to precise-proposed and if the fix is not in quantal, the SRU team doesn't allow it anymore even if it's in trunk
[09:13] <didrocks> pitti: thanks for the review :)
[09:13] <didrocks> (or if you have time and want to do it…)
[09:13] <pitti> didrocks: I'm currently at it
[09:13] <didrocks> excellent!
[09:13] <pitti> to Debian as well
[09:13] <didrocks> perfect ;)
[09:13] <didrocks> doing the backport to precise-proposed meanwhile
[09:14] <thumper> hi pitti, didrocks
[09:14] <pitti> hello thumper, how are you?
[09:14] <thumper> pitti: mostly good
[09:14] <thumper> frustrated by a gdb bug ☹
[09:14] <didrocks> hey thumper
[09:14] <thumper> but happy I've learned more Alt-Gr codes ☺
[09:15] <pitti> ♥
[09:15] <mlankhorst> thumper: want to swap? I'm frustrated by a kernel deadlock :-)
[09:15] <thumper> haven't yet found the cuppa or scissors
[09:15] <thumper> mlankhorst: ah... pass
[09:16] <pitti> thumper: like ✂ ?
[09:16] <thumper> pitti: yeah...
[09:16] <thumper> pitti: how plz?
[09:16] <pitti> thumper: ctrl+u 2707
[09:16] <pitti> err, 2702
[09:17] <thumper> pitti: doesn't work in quassel :(
[09:17] <pitti> ah, Ctrl+U is GTK's way of entering an Unicode char; Qt might have a different one
[09:17] <mlankhorst> control-shift-u ?
[09:18] <pitti> mlankhorst: ah, indeed, sorry
[09:18] <pitti> thumper: ^
[09:18] <mlankhorst> ✇
[09:18] <pitti> ♪ rocking ♩ !
[09:18]  * thumper feels unicode incapable
[09:19] <pitti> I only know some 4 by heart; I use gucharmap or vim digraphs for the others
[09:19] <thumper> I
[09:20] <pitti> didrocks: there, have an upstream/Debian/Quantal 2.34 release
[09:20] <thumper> happy to be able to say 28°C
[09:20] <thumper> but it isn't :(
[09:20] <thumper> 'tis winter
[09:20]  * didrocks hugs pitti, thanks!
[09:20] <thumper> pitti: I was wanting a short cut to say ✂☹
[09:22] <pitti> too bad that DEAD and BEEF are not nice unicode chars :)
[09:22] <thumper> :)
[09:22] <pitti> well, 뻯 might very well mean "beef" in whatever script that is
[09:23]  * didrocks loves when the package is built on soyuz before launchpad computes the diff
[09:29] <Laney> seb128: hm, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=b6e011ad16311e2985aa523cf9bceef74168f95e makes this quite complicated
[09:36] <seb128> Laney, yeah, I was planning to revert that commit
[09:36] <seb128> Laney, to be able to do at least the current updates
[09:36] <Laney> hm
[09:36] <Laney> that would probably get harder and harder to maintain
[09:36] <seb128> Laney, it's going to be problematic for further updates but that should unblock the first round
[09:37] <seb128> Laney, yeah, well, no regression and having a proper keyboard indicator or a status icon back to patch is going to take a while
[09:38] <Laney> seb128: alright, i'll try it
[09:38] <seb128> Laney, thanks
[09:39] <seb128> Laney, I'm still not convinced of the best way out, we could stay on 3.4 for g-s-d and g-c-c this cycle but I'm not convinced it's a win situation
[09:40] <Laney> indeed. and we'll still have to do the work in some future cycle
[09:40] <seb128> the new version have some nice improvement, tweaks design wanted, support for enterprise logins, etc
[10:04] <pitti> seb128, didrocks: I wrote some test cases for bug 1020572: http://paste.ubuntu.com/1082499/
[10:04] <ubot2> Launchpad bug 1020572 in apport "Deal better with DbusException errors" [Medium,Triaged] https://launchpad.net/bugs/1020572
[10:05] <pitti> seb128, didrocks: look at the "DbusErrorAnalysis" checks; does that seem appropriate to you? anything which this should check in addition?
[10:05] <pitti> it's still missing a service which crashes during a method call, which should also cause a NoReply, but with no running service
[10:06] <pitti> that'll be somewhat more tricky to set up, but I'll work on it; but I'm interested in the general feedback
[10:08] <didrocks> pitti: looks nice, I didn't know there was two possibility, like process running on different bus and that can be detected :)
[10:08] <didrocks> pitti: yeah, the naming seems appropriate to me
[10:08] <pitti> Instead of prose, it could also contain some tag-like fields
[10:09] <pitti> but I'd like to include the detected paths and process names as well
[10:09] <didrocks> pitti: test_dbus_service_timeout isn't about a service not responding?
[10:09] <didrocks> pitti: which is the same than crash at startup, isn't it?
[10:09] <pitti> didrocks: it is
[10:09] <pitti> didrocks: but it's a hanging process, not a crashed one
[10:09] <pitti> didrocks: i. e. the service is running and you get a NoReply
[10:09] <pitti> didrocks: if the backend is crashing during a call, it will not be running
[10:09] <pitti> (that's the missing case, still above)
[10:09] <pitti> err, "see" above
[10:11] <didrocks> pitti: ah ok, in the additional metadata, you are telling that it's still running though
[10:11] <didrocks> got it :)
[10:11] <didrocks> well, I think you will need a mock service which will crash at startup for your tests
[10:12] <didrocks> when called on a particular dbus method
[10:15] <pitti> right, I'll add that
[10:57] <seb128> pitti, looks fine to me!
[12:30]  * desrt mumbles something about monday and coffee
[12:31] <didrocks> hey desrt ;)
[12:32] <desrt> damn you and your timezone
[12:33] <didrocks> heh, happy monday morning!
[12:34] <pitti> hey desrt
[12:37] <desrt> good morning to both of you
[12:37]  * desrt has a bad day ahead
[12:37] <seb128> hey desrt
[12:38] <desrt> i finally did some real runtime testing of my dconf reorganisation last night
[12:38] <desrt> works great
[12:38] <desrt> except for the fact that every time you write a setting it deletes all of the other ones
[12:39] <seb128> desrt, small bug...
[12:39] <desrt> ya
[12:39] <desrt> i was thinking i should release it anyway
[12:39] <desrt> seb128: SRU, perhaps?
[12:40] <seb128> let's see if some user notice
[12:40] <didrocks> at least, if they get it we can say "yep, but at least, we knew it before you" :)
[12:40] <seb128> desrt, that would be lot of "fun" ;-)
[12:41] <desrt> "we do not consider the feature of retaining old settings to be important.  why do you feel the need to customise more than one option?"
[12:41] <desrt> ^ new GNOME attitude :D
[12:41] <seb128> ;-)
[13:16] <seb128> mvo, hey, how are you?
[13:17] <mvo> hey seb128 - I'm sure you want to nag me about aptdaemon! and you are right for doing it
[13:17] <seb128> mvo, ahah, how did you guess ;-)
[13:19] <didrocks> seb128: I was feeling as well that this "how are you" was too nice on a Monday ;)
[13:19] <seb128> didrocks, :-p
[13:20] <mvo> ;)
[13:20] <desrt> seb128: you need to try it my way
[13:20] <seb128> didrocks, don't worry, I'm going to nag you about the unity SRU soon ;-)
[13:20] <desrt> seb128: then nobody suspects a thing
[13:20] <didrocks> seb128: well, let's popey's team doing a unity release first :)
[13:20] <seb128> desrt, "can you review this patch: URL"?
[13:20] <didrocks> seb128: I did some p-d-e and quickly sru today, did my precise part :p
[13:20] <seb128> didrocks, will that happen before the end of year? ;-)
[13:20] <didrocks> seb128: but the sru team is really behind it seems
[13:20] <popey> :p
[13:20] <didrocks> seb128: let's see ;)
[13:21] <seb128> popey, half ":p", we are on a tight schedule for the LTS .1...
[13:21] <desrt> seb128: no.  you have to complain about it being monday and mumble something about coffee
[13:21] <desrt> seb128: then, when they're not expecting, you go in for the kill
[13:22] <seb128> desrt, lol
[13:22] <didrocks> desrt: you didn't ask anything to us, pitti and I, trapped fish! :)
[13:22] <desrt> didrocks: today was the control
[13:22] <didrocks> ahah
[13:23] <desrt> i catch you and release you, so you feel safe
[13:23] <dobey> mvo: hey. any news on the sso gtk+ moving?
[13:23] <desrt> didrocks: but now that you mention it...
[13:23] <desrt> didrocks: just a friendly poke about the status of the dconf profile work :)
[13:23]  * didrocks is not there
[13:23] <mvo> dobey: its in trunk in s-c now, once I know the parameter I need to pass to the dbus call to call my own custom sso binary I think its done
[13:24] <didrocks> desrt: you know it's far from being a priority for me, isn't it? ;)
[13:24] <desrt> didrocks: i expect you will tell me "i was busy on other stuff" and that's fine :)
[13:24] <desrt> just wanted to let you know that i still care :)
[13:25] <dobey> mvo: to the sso regiser and login calls, one of the arguments is a dict; you just add "'ui_executable': 'name-of-the-binary'" to that dict
[13:25] <pitti> didrocks, seb128: I implemented the analysis stuff for ServiceUnknown now, all tests pass now
[13:25] <didrocks> desrt: I think it's a good idea, but I will try to do some experiment with it this cycle, but I think if we are going to switch to that, we need a proper blueprint and planning to chance all the override stuff to profiles
[13:26] <didrocks> pitti: woooow \o/
[13:26] <pitti> let's see how far it gets us
[13:26] <didrocks> desrt: like the guadec hacking seesions will be a good time IMHO :)
[13:26] <desrt> didrocks: sounds great
[13:26] <mvo> dobey: cool, I add that now, thanks
[13:26] <pitti> didrocks, seb128: NB that NoReply is still blacklisted, as we cannot squeeze anything useful out of it right now
[13:26] <desrt> didrocks: i have a substantially lessened obligation to board duties this year, so i can actually have some hacking time :)
[13:27] <desrt> pitti: testing!! it's fun!!
[13:27] <pitti> desrt: it really is!
[13:27] <didrocks> desrt: yeah, you will see the guadec this year and not be locked in a room for a week ;)
[13:27] <didrocks> pitti: ok
[13:27] <desrt> pitti: lcov is like ... amazing
[13:27] <desrt> it turns testing into a game
[13:27] <desrt> gotta get a high score!
[13:27] <desrt> (100%, ideally)
[13:27] <seb128> pitti, ok, let's see how that goes, have some of cases handled is a good start ;-)
[13:27] <pitti> desrt: yeah, found the same with python-coverage back then :)
[13:28] <seb128> kenvandine, Sweetshark, kenvandine: hey
[13:28] <kenvandine> hey seb128
[13:28] <desrt> kenvandine: are you going to say hi a second time?
[13:28] <pitti> seb128: as soon as we convince the NoReply exception message to reveal which method/dbus name it tried to talk to, we can cover it, too
[13:28] <seb128> kenvandine, Sweetshark, kenvandine: so it seems like the libreoffice 3.5.4 SRU got set verification-failed by micahg due to lo-menubar issues
[13:28] <seb128> ups
[13:28] <seb128> sorry
[13:28] <seb128> kenvandine, Sweetshark, micahg: ^
[13:28] <kenvandine> indeed
[13:29] <kenvandine> i couldn't reproduce it on quantal
[13:29] <seb128> what's the deal there?
[13:29] <seb128> did you try with lo 3.5.4?
[13:29] <micahg> kenvandine: quantal doesn't have 3.5.4 yet
[13:29] <kenvandine> oh... i assumed it did
[13:29] <kenvandine> isn't that the rule? gotta upload to devel before SRU?
[13:29] <kenvandine> that would be interesting to test
[13:30] <kenvandine> i do have plasma-desktop installed still
[13:30] <kenvandine> Sweetshark, is LO 3.5.4 in a PPA or somewhere yet?
[13:31] <seb128> kenvandine, it's not an hard rule, we didn't want to block the SRU on sorting quantal toolchain issues
[13:32] <kenvandine> i see
[13:32] <seb128> kenvandine, and we aim at uploading lo 3.6 beta and not 3.5.n to quantal
[13:32] <seb128> kenvandine, you can probably install the precise-proposed version on quantal
[13:32] <kenvandine> can someone on precise test lo-menubar 1.1 with the older LO?
[13:32] <kenvandine> and plasma-desktop
[13:34] <micahg> by Sat night I was thinking that there was indeed no breakage in -updates, and that it was contained in -proposed with the lo3.5.4/lo-menubar 0.1.1 combo
[13:34] <micahg> but I didn't get a chance to confirm it
[13:35] <seb128> micahg, btw I don't care much about the menubars to be broken, the current precise version segfaults libreoffice in some cases and make you loose work wheny ou want to print
[13:35] <seb128> micahg, I like better breaking menubars than having the segfault
[13:35] <seb128> especially that they are from universe
[13:35] <seb128> i.e not supported
[13:35] <micahg> seb128: well, -updates is 0 regressions from what I've been told, you can't trade breakage in an SRU
[13:36] <seb128> the menubars also don't seem like worth failing the libreoffice SRU
[13:36] <seb128> micahg, well, that's a non supported universe package
[13:36] <micahg> seb128: but IANA SRU team member, didn't want it auto-migrated without this issue being looked at
[13:37] <micahg> seb128: I think that's irrelevant as far as breakage goes
[13:37] <seb128> it was migrated
[13:37] <kenvandine> the bug says it makes plasma-desktop crash
[13:37] <seb128> somebody rolled it back out to proposed
[13:37] <kenvandine> but it doesn't include a crash report
[13:37] <micahg> seb128: no, I meant libreoffice
[13:37] <mvo> dobey: just to double check, support for the ui_executable is not in quantal yet, correct? i.e. in testing I will see the default -gtk client come up?
[13:37] <seb128> micahg, would you be happy if we make libreoffice Conflicts lo-menubar and just document to not install those?
[13:37]  * kenvandine would be in favor of that
[13:38] <micahg> seb128: if that's the agreement you come to with the SRU team, that's up to you
[13:38] <kenvandine> lo-menubar in general has been buggy
[13:38] <seb128> micahg, well, you are the one who failed that SRU
[13:38] <kenvandine> and it isn't part of the default experience
[13:38] <seb128> micahg, not the SRU team
[13:38] <dobey> mvo: support is there already, yes; it's in precise too
[13:38] <micahg> seb128: only to get review before promotion
[13:38] <seb128> micahg, that's why I'm asking you
[13:38] <dobey> mvo: so once you have it installed, it should work
[13:38] <seb128> micahg, well you also got the menubar update reverted from -updates
[13:39] <dobey> mvo: it will look exactly the same as the current -gtk client, so you'll have to check the process list to see which one it is, really
[13:39] <micahg> seb128: yeah, which I think might have been not necessary, but it's easy enough to push lo-menubar back to updates if the issue is confirmed to be limited to lo 3.5.4
[13:40] <micahg> EOD Friday is not an opportune time to discover these things
[13:40] <seb128> right
[13:40] <seb128> kenvandine, Sweetshark: can you sort it you with the SRU team to know what they want exactly?
[13:41] <kenvandine> i think i would be in favor of adding the conflicts for lo-menubar, it is still buggy... but the -proposed version is less crashy
[13:41] <kenvandine> but the reality is it doesn't work well
[13:42] <dobey> mvo: if you need me to review a branch to add that arg, let me know. or let me know when you land it, and i'll work on getting the removal of the current -gtk landed
[13:42] <kenvandine> better to get the LO update and remove the buggy lo-menubar
[13:42] <seb128> kenvandine, the issue is that I don't want a LO upload for that :-(
[13:42] <seb128> kenvandine, because it means one day of buildds busy and resetting the SRU count
[13:42] <kenvandine> oh
[13:44] <micahg> seb128: the other issue is, I don't think update-manager will allow libreoffice to be updated on systems with lo-menubar installed if there's a conflicts
[13:44] <seb128> right
[13:45] <seb128> micahg, what's the problem,blocker with the current proposed combo?
[13:45] <seb128> micahg, out of menubars which stopped being exported for some users
[13:45] <micahg> seb128: I think so, if that's confirmed, lo-menubar can be pushed back to -updates
[13:45] <kenvandine> the bug said it caused plasma-desktop to crash
[13:45] <kenvandine> bug 1021946
[13:45] <ubot2> Launchpad bug 1021946 in lo-menubar "lo-menubar 0.1.1 from updates repositories makes plasma-desktop to crash" [High,Invalid] https://launchpad.net/bugs/1021946
[13:45] <micahg> right, it causes the crash and then is useless in plasma desktop
[13:45] <seb128> that would be a bug in plasma-desktop...
[13:46] <micahg> well, it was working before apparently :)
[13:46] <kenvandine> i would like someone to see if plasma-desktop crashes with lo-menubar and the older LO
[13:47] <kenvandine> in precise
[13:47] <seb128> micahg, working but making libreoffice segfault on print...
[13:47] <micahg> you can't break other software with an SRU either, even if the bug is there AIUI
[13:47] <seb128> doh
[13:47] <micahg> seb128: right, but that goes back to not breaking some users at the expense of others
[13:47] <seb128> installing plasma-desktop wants to install an hundred binaries, no thanks
[13:48] <micahg> seb128: again, this is what I was told by ScottK, you can discuss with the SRU team, I just didn't want stuff auto-migrated which is why I added the block
[13:48] <mvo> dobey: thanks, working on it right now to get a full end-to-end test
[13:48] <seb128> micahg, lo-menubar is not supported, can we just go a wipe the package content? ;-)
[13:48] <micahg> seb128: it might be an option, would probably depend on how broken
[13:49] <seb128> micahg, ok, so let's step back a bit
[13:50] <seb128> what happens with libreoffice 3.5.4 on precise-updates?
[13:50] <seb128> like what would happen if we throw away the lo-menubar SRU but keep the lo one?
[13:50] <micahg> good question, someone would need to test that use case with the old lo and lo-menubar
[13:51] <micahg> err...new lo and old lo-menubar
[13:51] <micahg> if it's limited to the SRU, you could do the lo SRU without the menubar one
[13:52] <seb128> that would be good
[13:52] <seb128> if only I could reproduce one of those issues :-(
[13:52] <micahg> sorry for not being clear, E_NOCAFFEINEYET
[13:52] <seb128> I guess we will need help from somebody having the issue on the bug
[13:52] <micahg> I managed to reproduce the crasher in a guest account with precise-proposed enabled
[13:53] <micahg> on precise that is
[13:53] <seb128> doing what?
[13:53] <micahg> loading libreoffice and adding the plasma-widget-menubar widget
[13:53] <micahg> in KDE
[13:54] <seb128> I guess I need to install KDE for that...
[13:54] <kenvandine> micahg, great... then remove lo-menubar and see if you still get the crash
[13:54] <seb128> let me try that
[13:55] <micahg> kenvandine: well, that's one test, the other would be if the old lo-menubar has the same issue (which IIRC it did not)
[13:55] <kenvandine> indeed
[13:55] <kenvandine> but it is easier to remove lo-menubar than LO
[13:56] <micahg> right, but if it's limited to new lo and new lo-menubar, you can choose which SRU you want more
[14:01] <seb128> kenvandine, micahg: do you know if I can run the plasma menubar stuff under unity and how?
[14:03] <micahg> seb128: that won't help, the bug is that it crashes the plasma desktop (well, it could show another bug I guess)
[14:03] <seb128> micahg, what do I need to install to get a plasma desktop?
[14:03] <seb128> let's install plasma-desktop
[14:04] <seb128> over 100 depends :-(
[14:04] <micahg> seb128: idk, I happen to have kubuntu-desktop installed
[14:04] <seb128> that's where I was trying to avoid getting at
[14:04]  * micahg wonders if it would work in a VM
[14:05] <micahg> probably should
[14:05] <Sweetshark> kenvandine: https://launchpad.net/~libreoffice/+archive/ppa?field.series_filter=precise <- 3.5.5 rc2
[14:43] <dobey> mlankhorst: hey. added more info to bug #1021924 over the weekend, though not sure how useful it is
[14:43] <ubot2> Launchpad bug 1021924 in xorg "Multiple Displays not working on Core i7 3770S + Intel DQ77MK motherboard" [Wishlist,New] https://launchpad.net/bugs/1021924
[14:56] <seb128> xclaesse, there?
[14:56] <xclaesse> <-- there
[14:56] <seb128> xclaesse,
[14:56] <seb128> http://cgit.freedesktop.org/wocky/commit/?id=d065b5ccf63b3a02a132cee370407a8a115fc444
[14:56] <seb128> http://cgit.freedesktop.org/telepathy/telepathy-gabble/commit/?h=telepathy-gabble-0.16&id=9abf25885dd71047746ea496ea3bdaff7f3499e7
[14:56] <seb128> xclaesse, are those enough for the msn issue?
[14:56] <seb128> xclaesse, I will rather backport the minimal patch first to help getting that SRU in and do the full update later when there is time to argue about the other code cleanup commits
[15:00] <xclaesse> seb128, let me verufy :)
[15:05] <xclaesse> seb128, that's correct
[15:05] <seb128> xclaesse, great, thanks for confirming
[15:05] <xclaesse> seb128, I would take wocky 3012a34361e6ca61e897d9e74079752b00c28ede as well though
[15:05] <seb128> is that the ipv6 port stuff?
[15:05] <seb128> yeah
[15:06] <seb128> I was pondering doing that, I will take it as well
[15:06] <xclaesse> that fix in case MS tells us to connect to an ipv6, but it also fix in case MS tells us to connect to a specific port
[15:07] <xclaesse> atm they say "foo.live.com" so we append ":5222", but if they start doing "foo.live.com:1234" without the patch we'll try to connect to "foo.live.com:1234:5222"
[15:07] <xclaesse> which will fail
[15:07] <seb128> right
[15:07] <xclaesse> so as they do atm, that patch isn't needed, but I would recommend taking it to be safer on the long term :)
[15:08] <xclaesse> seb128, thanks for taking care of this :)
[15:09] <seb128> yw! sorry for being a bit slow on it
[15:22] <kenvandine> chrisccoulson, where did all the headers that was in firefox-dev on precise go on quantal?
[15:27] <Laney> I wouldn't expect chrisccoulson to reply for a while ;-)
[15:27] <micahg> kenvandine: they shouldn't be needed as nothing was left using xul integration, only the NPAPI headers
[15:27]  * Laney wipes brow
[15:27] <Laney> got that patch "ported"
[15:27] <Laney> gsd builds once more
[15:28] <kenvandine> i have something that needs xpcom-config.h
[15:28] <micahg> kenvandine: nope, why does it need it
[15:28] <kenvandine> dunno... just stopped building
[15:28] <kenvandine> i'll talk to upstream
[15:29] <micahg> well, anything besides using the NPAPI headers is prone to breakage with future releases
[15:29] <micahg> well, that or the addon SDK
[15:30] <dobey> xpcom is a significant required feature for netscape plug-ins
[15:30] <kenvandine> it is for an extension
[15:30] <dobey> it's also used by many plug-ins
[15:30] <dobey> i know totem was using it at least
[15:30] <micahg> well, it's one way of interaction which has been discouraged upstream
[15:30] <micahg> totem was using NPAPI I thought
[15:31] <dobey> yes, but some features of NPAPI expose xpcom to the plug-in for doing certain things
[15:32] <micahg> well, if it's abstracted away in the NPAPI headers, you still wouldn't need the xpcom headers
[15:38] <dobey> looks like totem might not actually use xpcom any more though
[15:40] <dobey> i'm sure some people still do though
[15:40] <dobey> vlc might
[15:41] <dobey> i think one or more of the java plug-ins used to as well
[15:41] <micahg> nope, vlc uses NPAPI
[15:41] <mlankhorst> woops nothing to add
[15:42] <micahg> actually, the vlc thing is in its own source, but I'm pretty sure it's just NPAPI at this point
[15:46] <dobey> micahg: don't confuse people using NPAPI as not also using xpcom. totem used to also use xpcom, to do some scripting stuff.
[15:46] <dobey> anyway, need to get some lunch. bbiab
[15:46] <micahg> pure NPAPI
[17:11] <chrisccoulson> kenvandine, it's been my plan to remove those headers for a long time. eventually, the whole firefox-dev package will disappear
[17:12] <kenvandine> chrisccoulson, congrats! you shouldn't be at work
[17:12] <chrisccoulson> kenvandine, i'm not ;)
[17:12] <chrisccoulson> i just opened my laptop for a few moments whilst i sat down :)
[17:12] <chrisccoulson> and thanks :)
[17:15] <didrocks> congrats chrisccoulson ;)
[17:16] <chrisccoulson> thanks didrocks :)
[17:17] <micahg> congrats chrisccoulson
[17:17] <chrisccoulson> thanks :)
[17:17] <seb128> chrisccoulson, congrats ;-)
[17:17] <chrisccoulson> thanks :)
[17:17] <seb128> chrisccoulson, how are you all doing?
[17:18] <chrisccoulson> seb128, yeah, pretty good thanks. a bit tired though. we didn't get any sleep over the weekend (literally)
[17:18] <chrisccoulson> we were in hospital overnight on saturday
[17:19] <seb128> chrisccoulson, hehe, I guess you can catch up a bit of sleep now that the baby is here though ;-)
[17:19] <chrisccoulson> lol
[17:19] <seb128> chrisccoulson, well, only for a few days
[17:19] <seb128> before years of not sleeping a full night again :p
[17:19] <chrisccoulson> i'm not sure that's going to happen. it's looking like she's nocturnal ;)
[17:19] <seb128> she's already back home?
[17:19] <chrisccoulson> she's slept all day today, but was awake all night last night
[17:19] <chrisccoulson> yeah, she came home this afternoon
[17:20] <mdeslaur> chrisccoulson: congrats!
[17:21] <seb128> chrisccoulson, oh ok, I though they usually keep the mother & baby a couple of days ... no sleep for you then ;-)
[17:22] <chrisccoulson> mdeslaur, thanks :)
[17:22] <chrisccoulson> seb128, yeah, it depends on when they are born and if there are any complications
[17:23] <chrisccoulson> if everything is ok, they're discharged after a doctor has checked the baby and it's had a hearing test
[17:23] <chrisccoulson> which sometimes takes a while ;)
[17:29]  * Laney high fives chrisccoulson 
[17:30] <Laney> pushed g-s-d and g-c-c updates to lp
[17:30] <Laney> they still need work though, sadly
[17:34] <Laney> but at least all of the patches, including that monster one, are in a somewhat updated state :-)
[17:44] <seb128> Laney, does it build? does it run? ;-)
[17:45] <Laney> yes and ... somewhat :-)
[17:47] <Laney> might be good enough for the PPA, but hopefully I can get someone to take a second look at it all :P
[17:47]  * Laney goes to make some food
[17:48] <seb128> Laney, I will try to have a look ;-)
[17:48] <seb128> Laney, where are those? in the team vcs? or on your own branches ?
[17:49] <seb128> Laney, I guess you still don't have access to the packaging vcs?
[17:49] <Laney> I'm not in the team, so they are in my branches
[17:49] <Laney> I linked them from the bugs, as well as listing the issues I found
[17:49] <seb128> ok
[17:49] <seb128> you could apply to the team
[17:49] <seb128> but coredev will give you those rights as well
[17:49] <Laney> how does that work?
[17:49] <seb128> since you applied for that I figured it would not be needed
[17:49] <Laney> I thought it was nomination
[17:50] <seb128> basically email the desktop list asking to join the team and get 2 (or 3, I'm not sure now) people to +1 you
[17:50] <Laney> "At least three existing members have to confirm that they have worked enough with you to judge your skills and that you meet the criteria above. Usually these three people are your sponsors."
[17:50] <seb128> right
[17:50] <seb128> it should be easy to get those
[17:50] <seb128> you got at least 3 desktopers writing on your wiki IIRC
[17:50] <Laney> well, the next DMB meeting is looking a bit shaky for quorum so I might as well
[17:51] <seb128> yeah, easy enough
[17:52] <seb128> just drop an email on the list ;-)
[17:52] <Laney> doing right now
[17:54] <Laney> there we go
[18:04]  * didrocks waves good evening
[20:49] <ceti311_> #join #compiz-dev
[21:02] <dobey> hrmm. are people actually using quantal on intel hardware? or is everyone using nvidia/amd/ati?
[21:14] <desrt> dobey: if you're talking about unity, then there's a good chance nobody is running it on intel :)
[21:15] <dobey> desrt: i don't know about unity, but i just booted the amd64 live image from today on my dell duo, and all i got was a black screen when it got to where X should have been
[21:21] <desrt> dobey: talk to robert_ancell or RAOF
[21:22] <dobey> desrt: what did you mean about unity? is it horribly broken on intel right now?
[21:23] <desrt> dobey: i don't know that it is
[21:23] <desrt> dobey: but the unity developers, as a group, have a tendency to run on priorietary graphics
[21:23] <desrt> *proprietary
[21:23]  * thumper has intel
[21:24] <desrt> thumper: you're a developer? :)
[21:24] <thumper> was...
[21:24] <thumper> :P
[21:24] <thumper> I still compile and run trunk
[21:56] <thumper> dobey: I think I found your problem...
[21:56] <thumper> dobey: this is on quantal?
[21:56] <thumper> dobey: there is a missing dependency causing unity to not be installed
[21:57] <dobey> thumper: well, this is on the quantal daily live image
[21:57] <thumper> dobey: right, currently unity isn't installable on quantal due to a bad dep
[21:57] <thumper> thomi is emailing appropriate people :)
[21:58] <thomi> ...
[21:58] <thumper> thomi: same issue as AP
[21:58] <thomi> yes
[21:58] <dobey> thumper: so the daily image is totally screwed? i mean, even if unity itself was broken, i'd expect more than a black screen. like, maybe getting shoved to a VT, or X working but displaying everything except the unity bits
[21:59] <dobey> the install/try dialog doesn't show or anything
[21:59] <thumper> dobey: well, I'd also expect more than a blank screen
[21:59] <thumper> not sure about that
[21:59] <thumper> but symptoms sound familiar
[21:59] <thomi> thumper: it could be the PPA we're using, rather than quantal main itself.
[21:59] <dobey> and i can't switch to a vt with keyboard either
[21:59] <thumper> hmm...
[21:59]  * thomi runs some tests
[21:59] <thumper> could be something else then
[21:59] <dobey> like, X tries to init the driver and locks up hard or something.
[22:00] <dobey> so maybe it's not just my i7 that it's happening on, if this Atom has similar issue
[22:00] <dobey> my i7 workstation has been having similar issues with quantal daily image for about a week or so
[22:01] <dobey> anyway, i'm not really here now (/away) so i should actually go :)
[22:01] <dobey> later
[22:06] <thumper> actually, thomi has confirmed our issue is just with our staging PPA
[22:06] <thumper> so a different problem to you
[22:06] <thumper> sorry
[22:46] <robert_ancell> desrt, hey