[05:42] <pitti> Good morning
[08:01] <dholbach> good morning
[14:06] <ogra_> pitti, hmm, so i'm maintaining my cdimage branches on a precise desktop ... it uses python-mock ... and apparently uses tests that use the trusty python-mock, do you plan to SRU this ?
[14:07] <ogra_> (so i can go on testing the branch on an LTS)
[14:07] <pitti> ogra_: err, sorry, context/
[14:07] <pitti> ?
[14:07] <ogra_> http://paste.ubuntu.com/6508783/
[14:07] <pitti> ogra_: i. e. SRU what?
[14:07] <ogra_> thats what i get when running the self tests under precise
[14:07] <ogra_> pitti, python-mock changes
[14:08] <pitti> ogra_: so apparently python-mock 0.7 doesn't yet know this syntax
[14:08] <ogra_> right, thats what i mean
[14:08] <pitti> ogra_: if you want them to work under precise, I suggest you use the 0.7 API (which hopefully is forward compatible)?
[14:08] <ogra_> do you plan to backport such stuff for people developing on the LTS
[14:08] <pitti> ogra_: why me, specifically?
[14:08] <pitti> also, we don't generally SRU new versions
[14:08] <ogra_> isnt python-mock your child ?
[14:08] <pitti> we can certainly ask for a backport
[14:09] <pitti> ogra_: no, it's not; I guess you mean dbusmock :)
[14:09] <ogra_> i know how to work around that, but was wondering about others that use LTS versions for developing tip branches of newer stuff
[14:09] <pitti> ogra_: anyway, python-mock is fairly isolated, so we can build it as backport or put it into a PPA or something if needed
[14:12] <rbasak> ogra_: I've hit the same issue, FWIW. But I didn't think that new features were SRU-able in this way. Annoyingly this means that I can't run tests as part of a package build for a precise target.
[14:12] <ogra_> well, you can run them in a trusty chroot
[14:13] <ogra_> just forces you to maintain two branches or to bind mount it into the chroot or some such
[14:13] <pitti> or just change the tests to split the command into two, and set mymock.return_value explicitlY?
[14:13] <rbasak> I can, but that's no good when the final target is the cloud archive on precise. Though we may be able to backport python-mock there; I'll have to check.
[14:13] <pitti> (that syntax works with older p-mock)
[14:14] <pitti> that seems like the least painful approach
[14:14] <pitti> it's indeed nice to be able to run tests on precise to ensure that all deps are there, and the actual code doesn't use anything from newer pythons, etc.
[14:16] <ogra_> it requires that upstreams have that self discipline though
[14:51] <Saviq> rsalveti, ping
[14:52] <rsalveti> Saviq: pong
[14:52] <Saviq> rsalveti, hey man, I've a .crash with... a LOT of question marks
[14:53] <Saviq> rsalveti, I'm starting to think it's crashing on android side - do you have any pointers on getting some useful data out of there?
[15:01] <mitya57> cjwatson: Can you please check why wxwidgets3.0 still isn't getting auto-synced? The conflicting binary package has been dropped from wxwidgets2.8 in -proposed.
[15:02] <rsalveti> Saviq: sure, https://wiki.ubuntu.com/Touch/Core/UbuntuDebugAndroid
[15:03] <rsalveti> Saviq: easier if you have the android build locally, let me know if you don't, then I can provide the lib with debug symbols
[15:03] <rsalveti> once you check it with maps
[15:03] <Saviq> rsalveti, it's the first time I'm doing it, so no, I don't have anything
[15:04] <rsalveti> Saviq: ok
[15:04] <Saviq> rsalveti, it's unity8... it's going to have everything in its maps...
[15:04] <Saviq> rsalveti, any way to reduce the scope?
[15:05] <rsalveti> Saviq: but checking the stack trace, you should be able to find the first maps that brings the ???
[15:05] <rsalveti> and the related library
[15:06] <Saviq> rsalveti, here's the .crash, what should I be looking at? http://paste.ubuntu.com/6509647/
[15:07] <rsalveti> let me check
[15:07] <xnox> mitya57: i filed a bug about it. basically wx-common binaries need removal, and a sync forced.
[15:07] <xnox> mitya57: cause at the moment wx-common binary has "ubuntuX" suffix version in -release pocket. And wxwidgets2.8 cannot migrate without new wx-common from 3.0, which can't be synced because of the first reason =)
[15:08] <mitya57> I expected the autosyncer to look at -proposed
[15:08] <xnox> mitya57: so someone with archive admin powers needs to stab it =) i hope infinity or cjwatson will get around to doing it.
[15:08] <rsalveti> Saviq: the stack seems to be in the ubuntu side, maybe opening the core dump with gdb to check
[15:09] <mitya57> xnox: OK
[15:09] <ogra_> Saviq, we got a new glib exactly that day the install is from
[15:09] <xnox> mitya57: well it can't, because -proposed is an overlay (e.g. there is no way to tell between wx-common binary dropped in -proposed, vs wx-common is at *ubuntuX version at the moment)
[15:09] <ogra_> well, not exactly ... but its definitely using the new one there
[15:09] <xnox> mitya57: -proposed & -release are merged and then compared.
[15:10] <xnox> mitya57: from archive point of view there "wx-common is fully migrated to release pocket" =)
[15:12] <mitya57> Right.
[15:27] <Saviq> ogra_, shall I try in the previous image then?
[15:28] <ogra_> well, might make sense to do some comparison
[15:28] <ogra_> Saviq, http://people.canonical.com/~ogra/touch-image-stats/20131129.2.changes
[15:28] <Saviq> ogra_, will do, thanks
[15:28] <ogra_> thats the respective change set
[15:30] <Saviq> rsalveti, yeah, there's just no more symbols I can think to install to get anything - it's all ??s
[15:30] <Saviq> rsalveti, in gdb, too
[15:33] <rsalveti> Saviq: have the dump somewhere I can take a look?
[15:40] <hakermania> If I have uploaded an earlier version of my application and thus I had a sponsor for it, should I contact him for a new version of the app and a new library not in the repos which is a dependency of this new version of the application?
[16:01] <xnox> mitya57: interesting I got accept from wxwidgets3.0 source =/ it's now in bin new.
[16:01] <xnox> mitya57: \o/
[16:05] <mitya57> xnox: \o/
[16:31] <zyga> mhall119: do you know who manages irc cloaks for ubuntu members?
[16:31] <mhall119> zyga: #ubuntu-irc if I remember right
[16:59] <zyga> are there any ubuntu developers from ukraine present here?
[17:08] <happyaron> cjwatson: can you have a look at this merge request when you have time? https://code.launchpad.net/~penghuanmail/ubiquity/lp.1197220/+merge/195712
[17:11] <mitya57> zyga: I'm not aware of any Ukrainian Ubuntu developers.
[19:03] <ScottK> balloons: DMB time.
[19:03] <ScottK> Sorry
[19:03] <ScottK> barry: DMB time.
[19:22] <shadeslayer_> doko: I don't suppose you're aware of some sort of porting guide that allows me to port an application from graphviz 2.26 to 2.34
[19:24] <shadeslayer_> doko: currently stuck on http://paste.ubuntu.com/6510818/
[20:15] <ryao> Does Ubuntu place mount and umount into /bin?
[20:24] <ryao> Nevermind. happyaron helped me. Long story short, I am writing an upstream patch and I wanted to be certain that it worked on Ubuntu.
[21:16] <smoser> anyone have an example of a service that does not have an upstart job ?
[21:16] <smoser> ie, sysvinit only ?
[21:22] <JanC> smoser: I think maybe apache & postgres?  (I would have to check the latest packages though)
[21:22] <xnox> smoser: apparmor profiles, x11 common - in the default install.
[21:23] <smoser> JanC, apache2 seems good.
[21:23] <smoser> fwiw, this is https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1257036
[21:45] <smoser> hm..
[21:45] <smoser> so that bug above, i assumed was present
[21:45] <smoser> but it seems that most services clean their own environment
[21:45] <smoser> (tested so far postgress, apache2, postfix)
[21:46] <smoser> if i'm going to make cloud-init install packages by default with libeatmydata
[21:46] <smoser> should i fix this even thought it seems that most packages don't need the help ?
[22:02] <stgraber> cjwatson: I just uploaded a merge of LTSP and a sync for LDM, I think you were technically TIL for those two because of small arm64/d-i fixes, I hope you don't mind (I wrongfully assumed that I was TIL on both ;)).
[22:05] <xnox> smoser: hm, would cloud-init leak LD_PRELOAD to e.g. juju / user logged-in session? ( i guess not, since cloud-init is managed by upstart). If it doesn't leak it, no need to fix "service" command since it's environment is clean.
[22:06] <xnox> invoke-rc.d should be enough.
[22:06] <smoser> xnox, you're right in that service is enough in that case.
[22:07] <smoser>  but fixing service *also* is a more genericly safe path.
[23:14] <kees> slangasek, tyhicks: apparmor 2.8.0-2 uploaded to Debian with multiarch and dh(1).
[23:14] <xnox>  \o/
[23:15] <tyhicks> kees: nice! :)