[04:54] <pitti> Good morning
[04:56] <pitti> rbasak: psql version> thanks for confirming
[07:27] <dholbach> good morning
[09:06] <darkxst> seb128, hi
[09:07] <darkxst> I fixed Bug 1228939 if you have time for a review
[09:08] <darkxst> not sure about the on_shell_disapeared crash, though it looks like a use-after-free issue
[09:39] <didrocks> seb128: cjwatson: hey, it seems that lubuntu has ubuntu-system-settings installed by default. That discussion rings a bell to me with something about edubuntu, what was the fix needed?
[09:39] <seb128> Laney, ^
[09:40] <seb128> didrocks, is lubuntu using gnome-control-center?
[09:40] <Laney> http://cdimage.ubuntu.com/lubuntu/daily-live/pending/saucy-desktop-amd64.manifest
[09:40] <seb128> didrocks, some of the indicators recommends u-s-s | g-c-c
[09:40] <Laney> I don't see it there
[09:41] <didrocks> Laney: seed-in-ubuntu says   lubuntu: supported
[09:41] <didrocks> it's not installed then? just supported?
[09:41] <Laney> I don't know how supported is generated
[09:41] <didrocks> (that won't block in the automatic UNAPPROVED queue?)
[09:41] <didrocks> I guess that's our only question ;)
[09:44] <Laney> didrocks: it will
[09:44] <didrocks> ah…
[09:44] <didrocks> I think it's weird that ubuntu-system-settings is supported by lubuntu
[09:44] <didrocks> seb128: does it make sense to you? ^
[09:44] <Laney> It's automatically generated, I just don't know how
[09:45] <Laney> ubuntu-system-settings | ubuntu-system-settings | indicator-bluetooth | Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com> | 833194 | 2125
[09:45] <Laney> from germinate
[09:47] <seb128> oh, indicator-bluetooth Depends on ubuntu-system-settings | gnome-bluetooth
[09:47] <seb128> lubuntu is not using gnome-bluetooth right?
[09:47] <cjwatson> didrocks: The fix for Edubuntu was in livecd-rootfs 2.189; but I don't think that situation applies to Lubuntu.
[09:48] <cjwatson> didrocks: If the standard germinate output lists ubuntu-system-settings, then Lubuntu needs some different fix.
[09:48] <didrocks> cjwatson: ok, so yeah, probably what seb128 just told ;) sorry for mapping the same issue mentally
[09:48] <cjwatson> Yep
[09:48] <didrocks> seb128: I don't see indicator-bluetooth in the manifest
[09:48] <seb128> didrocks, wait, indicator-bluetooth is not listed
[09:48] <seb128> right
[09:49] <seb128> I was coming from what Laney copied
[09:49] <didrocks>   lubuntu: supported
[09:49] <didrocks> though
[09:49] <didrocks> for indicator-bluetooth
[09:50] <seb128> cjwatson, do you know how lubuntu:supported is built?
[09:50] <cjwatson> I expect it's just the usual germinate supported seed
[09:51] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.saucy/supported
[09:51] <seb128> darkxst, hey, thanks for the g-c-c fix, I'm going to have a look. The other segfault could be a callback not disconnect properly or something?
[09:52] <cjwatson> ubuntu-system-settings <- indicator-bluetooth <-(recommends) unity <- libunity-2d-private-dev <- rescued from unity
[09:52] <seb128> hum
[09:52] <cjwatson> That might be fixable with Extra-Exclude
[09:52] <seb128> indicator-bluetooth                     | indicator-bluetooth                    | unity (Recommends)                          | Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com>          |           54158 |             248
[09:52] <Laney> what does rescued from mean?
[09:52] <seb128> why is unity listed on the lubuntu list?
[09:52] <cjwatson> it means it's a binary from a source some other part of which is in main
[09:53] <cjwatson> er, not in main, included in the seed expansion for the seed structure
[09:53] <cjwatson> I could explain or I could fix it :)
[09:54] <Laney> Well, if we manage to understand then we might be able to fix such things in future
[09:55] <cjwatson> So, there's a thing where we try to automatically ensure that *-dev packages are supported
[09:55] <cjwatson> That's done by this entry in supported:
[09:55] <cjwatson>  * Extra-Include: *-dbg *-debug *-dev *-doc *-docs *-gcj gir1.2-* *-examples
[09:56] <cjwatson> Which automatically adds any package matching *-dev (etc.) from any source which produces a binary which is in the expansion of supported or any seed inside it
[09:56] <cjwatson> Sometimes this misfires
[09:56] <cjwatson> Say, if you have a source package that generates foo-data libfoo1 libfoo1-dev and you only care about foo-data and not libfoo1
[09:57] <cjwatson> In such cases you can add Extra-Exclude lines to filter them back out again
[09:59] <cjwatson> In this case what's happening is that ubuntu-defaults-builder depends on unity-common, which is provided by libunity-core-6.0-8; and ubuntu-defaults-builder is seeded in lubuntu.saucy/supported-development-desktop
[10:01] <cjwatson> Just testing a fix now
[10:02] <Laney> I see; the last unity is a source package name and the first is (obviously) a binary
[10:02] <cjwatson> Yes
[10:02] <cjwatson> http://bazaar.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.saucy/revision/277 should fix this
[10:03] <didrocks> thanks cjwatson :)
[10:03] <cjwatson> I don't know how often the seeded-in-ubuntu data is updated
[10:03] <cjwatson> It's quite possible it'll take a day or so
[10:03] <Laney> Forgot how to get into the box
[10:03] <didrocks> ok, meanwhile maybe Laney can fast-process indicabot-bluetooth, ubuntu-system-settings and the qt things if needed I guess
[10:04] <Laney> oh no, here we go
[10:05] <seb128> hum, it's a bit suboptimal that the unity stacks end up in the lubuntu supported set only for a gsettings schemas
[10:05] <cjwatson> seb128: Huh?
[10:05] <cjwatson> seb128: Where are you seeing that?  That's not the path I traced and fixed
[10:05] <seb128> cjwatson, "ubuntu-defaults-builder depends on unity-common, which is provided by libunity-core-6.0-8;"
[10:06] <cjwatson> seb128: And I fixed that ...
[10:06] <seb128> oh, ok
[10:06] <cjwatson> I mean, sure, it still pulls in that one binary
[10:06] <cjwatson> But that doesn't pull in the whole stack
[10:06] <seb128> I see
[10:06] <cjwatson> Just libunity-core-6.0-8 and libunity-protocol-private0
[10:06] <seb128> so it's mostly the unity source, which is ok
[10:07] <seb128> cjwatson, thanks
[10:07] <cjwatson> Well, and unity-services
[10:07] <cjwatson> But yeah, it's not all the indicators and stuff any more
[10:07] <darkxst> seb128, the signal is disconnected slightly after the destroy, however I don't think thats the problem other we would also see on_unity_dissappeared crashes
[10:08] <seb128> darkxst, yeah, I don't really know, I didn't look at the code, it's just a frequently reported issue ... seems to happen for gnome-shell users at logout
[10:10] <darkxst> seb128, yeh, I have seen it hovering quite high on errors.u.c
[10:14] <darkxst> though if its happening at logout its actually quite harmless, and will just disappear once crash reports are disabled
[10:16] <seb128> darkxst, you are still going to get whoopsie, that's never disabled
[10:17] <darkxst> well they dont go to launchpad ;)
[10:17] <darkxst> anyway I will try work out the problem, but I have only seen the crash once here
[10:20] <seb128> darkxst, right, I don't care much about launchpad noise, rather about those users getting the annoying prompt on their screens...
[10:33] <mpt> The most frequent crash in Ubuntu is a bug that was fixed in an update six weeks ago.
[10:45] <ritz> mvo ping
[10:45] <mvo> ritz: pong
[10:45] <ritz> mvo wrt https://code.launchpad.net/~mvo/software-center/lp926763/+merge/187206
[10:48] <mvo> ritz: thanks, give me a minute or two
[10:49] <mardy> seb128: hi! Can you have a look at https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1210866?
[10:49] <ritz> mvo++
[10:49] <mardy> seb128: the next question is: provided that EDS 3.9.5 doesn't bring in new dependencies (which I've yet to verify), do you think we could ship it in saucy?
[10:49] <seb128> mardy, hey, was exactly about it?
[10:50] <seb128> mardy, no, it's too late to take on a new e-d-s serie
[10:50] <seb128> mardy, next cycle
[10:50] <mardy> seb128: OK
[10:51] <seb128> mardy, the goa split was buggy, I have it on my list for this week, I'm just going to undo it
[10:51] <seb128> mardy, not sure what to do about the password prompt issue...
[10:52] <mardy> seb128: you don't think we could update just EDS, if it doesn't bring in new dependencies?
[10:53] <seb128> mardy, I doubt it, it's almost release time, not time to bring such changes in
[10:53] <Laney> It'll be a transition
[10:53] <mardy> seb128: not even post-release, as an update?
[10:53] <seb128> mardy, no, we don't do major updates in SRUs
[10:54] <seb128> Laney, is there soname changes?
[10:54] <Laney> yeah
[10:54] <Laney> well, maybe not for 3.9.5 but certainly for 3.10
[10:55] <Laney> it is e-d-s after all :P
[11:00] <mardy> seb128, Laney: a diff of the configure.ac between the 3.8.4 and 3.9.5 releases shows that the _CURRENT field of some libs was bumped (I don't remember if that counts as a soname bump)
[11:01] <mardy> seb128, Laney: http://paste.ubuntu.com/6175141/
[11:02] <seb128> mardy, the soname is current-age iirc
[11:02] <Laney> It does, that's the major version
[11:03] <Laney> And we couldn't take a random mid-cycle development version anyway
[11:03] <mardy> Laney: OK
[11:03] <Laney> Maybe the individual fix is cherry-pickable, but I'd bet probably not
[11:37] <mardy> Laney: I could have a look at it
[11:41] <mardy> Laney: no, it doesn't seem to be cherry-pickable
[13:16] <labsin> ping mardy
[13:38] <mardy> labsin: pong
[13:39] <labsin> mardy, I'm trying to add a online account provider but I run in errors
[13:40] <labsin> mardy, they told me you could maybe help
[13:44] <mardy> labsin: yep. Do you have the .provider file somewhere online where I can see it?
[13:45] <labsin> mardy, http://pastebin.com/sV0qcwHs
[13:47] <mardy> labsin: where is the mobilevikings OAuth API documented? I can't find it
[13:47] <labsin> mardy, https://mobilevikings.com/api/2.0/doc/
[13:50] <mardy> labsin: right, just found it. Your file seems correct, what error do you get?
[13:52] <labsin> mardy, If I launch gnome-control-center verbose, I get "(gnome-control-center:1194): account-plugin-WARNING **: AuthSession error: GDBus.Error:com.google.code.AccountsSSO.SingleSignOn.Error.OperationFailed: Operation failed."
[13:53] <labsin> http://paste.ubuntu.com/6175651/
[13:53] <mardy> labsin: I need to quit now, could you please send me more logs to e-mail? (set the LoggingLevel to 2 in /etc/signond.conf, and then you'll see more logs in the syslog)
[13:53] <mardy> labsin: alberto.mardegan@canonical.com
[13:53] <labsin> mardy, tnx
[14:05] <pitti> jibel: FYI, I reported bug 1233185 with a simplified test case of what is broken in gdb-multiarch for retracing ARM
[14:09] <jibel> pitti, thanks, subscribed. For the moment, I produce most traces on the phone.
[14:10] <pitti> jibel: it seems precise's gdb-multiarch still works, so I'll run the ARM ones under precise
[14:10] <pitti> jibel: do you happen to have a bug # handy for one which is broken?
[14:13] <pitti> jibel: using bug 1227546
[14:15] <jibel> pitti, ok or bug 1233191 . It's smaller than unity8
[14:35] <jibel> pitti, trace on 1233191 looks a bit better
[14:43] <pitti> re
[14:43] <pitti> jibel: indeed, at least usable
[15:32] <catbus1> Hi, anyone know when the next UDS will be?
[15:33] <smartboyhw> catbus1, approximately October 20 something (I believe)
[15:35] <catbus1> smartboyhw: ok, like right after 13.10 is release.. thanks.
[15:36] <catbus1> s/release/released
[15:38] <dobey> catbus1, smartboyhw: november would be 3 months since the last one
[15:39] <smartboyhw> dobey, so? Aren't we planning for 2 months?
[15:39] <smartboyhw> (Or maybe the Community Team changed it's schedule, dunno)
[15:39] <dobey> smartboyhw: they are supposed to be every 3 months afaik
[15:39] <dobey> and they have been
[15:40] <smartboyhw> I remembered it was one in April, one in June, one in August-.-
[15:40] <stgraber> so far we had early March, mid-May and end of August
[15:40] <dobey> right
[15:40] <dobey> and the march one was the odd one out
[15:41]  * smartboyhw does not exactly like vUDS, anyhow
[15:44] <smoser> stgraber, if you have some time .. https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1231988 would be nice to read that.
[15:52] <stgraber> smoser: might be good to have mdeslaur double check the patch, but a quick look through looks good to me so I guess we can add that to our package
[15:53] <stgraber> smoser: (and you're correct that ISC doesn't have a public bug tracker, as annoying as that's ...)
[15:53] <smoser> stgraber, the real pita is there...
[15:54] <smoser> that we have will then have this is we have to patch the package to deal with the old-working, old-broken, now-working
[15:54] <stgraber> yeah, it's really quite annoying having to watch 3-4 distros to figure out who already found a particular issue and then try and share patches...
[16:47] <smoser> hey...
[16:47] <smoser> anyone have suggestions on this approach.
[16:48] <smoser> for 'python-simplestreams' it contains some function that depends on some openstack libraries (python-glanceclient, python-swiftclient).
[16:48] <smoser> we want python-simplstreams to be installable without those.
[16:49] <smoser> the suggestion that rbasak had was just to add a metapackage 'python-openstack' that had the depdends.
[16:49] <smoser> and drop the depends form python-simpelstreams
[16:49] <smoser> err.. 'python-simplestreams-openstack' above (not 'python-openstack').
[16:57] <smoser> hm... barry maybe ? sorry to call you out by name, but this seems to be a reasonbable solution to me. anyone?
[16:58] <barry> smoser: at quick glance (sorry, very busy atm) that seems reasonable
[17:00] <smoser> thank you. (i fully understand the "very busy" disclaimer)
[18:18] <jtaylor> barry: would you sponsor a new numpy stable release rc for saucy?
[18:19] <jtaylor> final release might not be done for saucy, but many changes are unlikely
[18:21] <barry> jtaylor: i'm slammed right now.  if you can't find anyone else, ping me again in a few hours
[18:21] <jtaylor> not today, generally
[20:19] <robert_ancell> mterry, did you test that make check works with the new --standalone change? I fixed the tests yesterday
[20:20] <robert_ancell> mterry, (I'm pretty sure it will fail with that change)
[20:20] <robert_ancell> mterry, though we can just ditch the standalone now  we have https://code.launchpad.net/~mterry/unity-system-compositor/assume-standalone/+merge/188395 right?
[20:21] <robert_ancell> oh, I see the no-standalone branch now
[20:22] <mterry> robert_ancell, yeah though I should update no-standalone to drop the handling in the test u-s-c
[20:23] <mterry> robert_ancell, OK, updated both branches' test USCs
[20:24] <mterry> robert_ancell, I'm not super pleased with the assume-standalone branch.  I wish Mir's option handling let you specify a default for an option (rather than as an argument to get() each call)
[20:24] <mterry> robert_ancell, and I wish that default showed up in help() automatically
[20:24] <robert_ancell> mterry, yeah, I don't know of any method to do that
[21:28] <brainwash> seb128: can you have a look at bug 1231978 please? it looks like the recent gvfs "bug fix" update is causing some trouble, affecting thunar and pcmanfm users
[21:28] <seb128> brainwash, somebody should report the issue upstream, I didn't do that update
[21:31] <brainwash> seb128: ok, I'll report it upstream after some more testing, thanks :)
[21:31] <seb128> brainwash, yw, thanks for reporting it there
[22:58] <tomreyn> hi
[22:59] <tomreyn> i'm looking for some statistics on how many users there are (or just ISO downloads) on 32 vs 64 bit
[22:59] <tomreyn> any idea where i could find those?
[23:28] <jtaylor> tomreyn: http://popcon.ubuntu.com/
[23:29] <jtaylor> 64 vs 32 debian is interesting too, there 64 overtook 32 a short while ago: http://popcon.debian.org/
[23:32] <tomreyn> jtaylor: thank you!
[23:32] <tomreyn> that's like a year ago
[23:33] <tomreyn> i guess you could consider that a short while based on debian's lifetime
[23:43] <sarnold> tomreyn: don't forget that at least ubuntu.com/download suggests 32 bit and pre-selects 32 bit..
[23:44] <sarnold> tomreyn: depending upon what you're trying to measure (installed architectures vs types of CPUs in use) you might get skewed results one way or another..
[23:52] <tomreyn> sarnold: thanks, i'll keep this in mind. but i'm really after what people use as installed architectures, so i guess i'm fine.
[23:52] <tomreyn> what's the design choice behind defaulting to 32-bit, i never understand this.