[04:12] <pitti> doko_: ./configure has an --enable-numpy option, so it looks like it just relies on p-numpy-dbg already depending on p-numpy
[04:12] <pitti> Good morning
[06:58] <dholbach> good morning
[07:31] <didrocks> cjwatson: FYI, killed the cache on lillypilly
[07:46] <didrocks> slangasek: FYI, settings with system update published, in -proposed right now
[07:46] <slangasek> didrocks: sw33t \o/
[07:50]  * ogra_ hopes we'll soon get Mir and lightdm so we can finally switch to ti 
[07:50] <ogra_> *it
[07:51] <ogra_> (it = system updates)
[07:52] <slangasek> ogra_: how are Mir+lightdm related to this?
[07:52] <ogra_> slangasek, missing logind blocks a lot of features
[07:52] <slangasek> ogra_: "a lot of features" but not image-based updates AFAIK
[07:52] <ogra_> and logind integration will only come with lightdm ... which sill only come with Mir
[07:53] <ogra_> slangasek, no, but properly working click packages without hacks :)
[07:53] <slangasek> ah, fair
[07:53] <ogra_> if we woould just switch we would have to ship with developer mode enabled by default .... which defeats the purpose
[07:54] <ogra_> it is MIr+lightdm -> system images  -> system partitions .... DONE :)
[07:59] <slangasek> ogra_: it doesn't defeat the purpose; it still improves code consolidation even if we're not able to turn it on by default yet
[07:59] <slangasek> we won't block delivering system updates on Mir+lightdm
[07:59] <ogra_> hmm
[08:00] <mpt> ev, had you noticed the error rate graph has gone blank?
[08:05] <ev> mpt: yes. We're had to suspend the existing database and move to a new one. We'll merge the two once everything is settled, but until then the only data on errors.u.c is from Thursday onward
[08:05] <ev> I'll send out an annoucement to ~error-tracker-access
[08:13] <mpt> ev, how long will the merging take?
[08:14] <ev> mpt: I don't have an accurate estimate for that. We're not out of the woods on fixing the old database.
[08:14] <mpt> ev, in that case, maybe put a notice on the front page itself, not just on a mailing list
[08:15] <ev> will do
[08:15] <mpt> :)
[09:32] <ev> seb128, Laney: if either of you have time for a small merge: https://code.launchpad.net/~ev/ubuntu-system-settings/automatic-error-reporting/+merge/177348
[09:58] <Laney> ev: sure
[09:58] <Laney> ev: did you do anything about polkit prompting in 0.9?
[10:29] <ev> Laney: it's on my todo list for today
[10:29] <Laney> cool
[11:40] <ev> Could I have the eyes of another core dev on this one: https://code.launchpad.net/~ev/ubuntu-seeds/ubuntu-touch.saucy-error-reporting/+merge/177363 (adds whoopsie and apport to Touch)
[11:44] <xnox> ev: what is /etc/apport/autoreport a config-file, a conf-file, or a stamp?
[11:45] <ev> xnox: stamp
[11:45] <xnox> ev: syntatically the merge proposal looks correct =)
[11:45] <ev> whoop :)
[11:51] <infinity> I'm trying to decide if we want the new shiny dpkg or if the changeset scares the crap out of me and I should wait for a week or so for it to cook in Debian.
[11:52] <jpds> infinity: Both.
[11:52] <infinity> Heh.
[11:52] <infinity> Yeah, there are definitely things in here we want (potentially even need), but I think I'll let it simmer a bit.
[11:52] <ogra_> infinity, the future is click anyway, just leave it idle :P
[11:53] <cjwatson> Click doesn't replace dpkg </knee-jerk>
[11:53]  * mitya57 wants xz compression by default (new dpkg has it)
[11:53] <xnox> infinity: i wanted xz by default since Maverick =)
[11:54] <infinity> Heh, yeah, I know a few people are waiting for that. :P
[11:54] <infinity> I'm also happy about the dpkg-shlibdeps/LD_LIBRARY_PATH changes, though that won't be useful until debhelper changes to match.
[11:58] <Mirv> "On the upload and publication side, we made upload processing run every
[11:58] <Mirv> minute rather than every five minutes" - hurray!
[11:59] <infinity> It's always the little things that make people happy. :)
[12:24] <pitti> jibel: ah, the new libgphoto breaks umockdev's autopkgtest; the reason why this wasn't caught in -proposed is that umockdev doesn't directly depend on libgphoto2, but on gphoto2 which then depends on libgphoto2, right?
[12:24] <pitti> jibel: i. e. we only consider direct dependencies, not transitive ones?
[12:30] <cjwatson> pitti: it's true that we only currently consider direct dependencies
[12:30] <pitti> cjwatson: ok, thanks for confirming
[12:30] <pitti> it's not a biggie in this case, I just want to understand what's going oin
[12:30] <pitti> on
[12:31] <infinity> Do we plan at some point to do away with the public/private mess on excuses and actually give people without Canonical QA VPN access the ability to see tests in progress?
[12:31] <infinity> I'm always suspicious that "running" actually means "broken".
[12:32] <infinity> Especially in the case of things like the linux test that's been running all weekend. :P
[12:32] <infinity> pitti, jibel, cjwatson: ^
[12:33] <cjwatson> I'd love to but don't have the power.
[12:33] <pitti> infinity: I'm afraid I don't know; that's a question for retoaded and the lab admins
[12:33] <infinity> Sure, I was more curious if you knew of such a plan, not if you were going to execute it. :)
[12:33] <cjwatson> And yes, that does appear to mean "broken".
[12:33] <cjwatson> ld: final link failed: No space left on device
[12:33] <pitti> infinity: we should at least allow everyone in Canonical (especially the release team) VPN access
[12:33] <infinity> Okay, same failure as always.
[12:34] <infinity> cjwatson: I've hinted past that one, as I always do.
[12:34] <cjwatson> But you can see that on the public instance too.
[12:34] <cjwatson> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-linux/ARCH=amd64,label=adt/70/console
[12:34] <infinity> cjwatson: Wondering if the "running" eglibc and quagga ones are equally broken.
[12:34] <pitti> and I don't think it's particularly restricted, it's mostly just asking for it AFAIK
[12:34] <cjwatson> infinity: eglibc appears to be genuinely in its test suite.
[12:34] <pitti> there is not currently a running quagga test
[12:34] <pitti> there *is* a running eglibc test
[12:35] <infinity> cjwatson: Kay, so eglibc is just slow.  Check. :P
[12:35] <cjwatson> quagga finished fairly recently so maybe it'll catch up next run.
[12:35] <cjwatson> Though, an hour ago
[12:35] <rickspencer3> hey hey
[12:35] <rickspencer3> starting again
[12:35] <cjwatson> infinity: I think there are still some bugs in adt-britney collect.  They're hard for me to interpret
[12:35] <rickspencer3> oops, wrong channel ;)
[12:35] <pitti> hey rickspencer3
[12:35] <rickspencer3> hi pitti
[12:36] <infinity> Sure, no rush, this is conveniently all slotting into the time while armhf is building, as engineered.
[12:36] <infinity> rickspencer3: Guten Tag und Schtuff.
[12:36] <rickspencer3> hi infinity
[12:36] <rickspencer3> I'm actually on the IoM atm
[12:36] <rickspencer3> but, yeah
[12:36] <rickspencer3> das is dein sprint
[12:37] <infinity> I don't speak Manx, you'll have to suffer with faux German.
[12:37] <pitti> hm, the failing autopkgtest is actually right -- gphoto2 --auto-detect indeed does pollute stderr with tons of libusbx output
[12:37] <pitti> why do we have libusb debugging on by default now?
[12:37]  * pitti digs
[12:38] <infinity> cjwatson: I was, frankly, pretty shocked to see only 19 tests spin out of the eglibc upload anyway.  Either our test coverage is awful, or we're not doing a good job finding rdeps.
[12:39] <infinity> cjwatson: (Well, I know our coverage is awful, but I didn't think it was THAT bad)
[12:40] <pitti> infinity: I guess that might again be due to not doing transitive deps?
[12:40] <infinity> pitti: Transitive shouldn't really matter here.  Everything and its dog depends on libc6.
[12:41] <cjwatson> infinity: Does seem a bit low.
[12:41] <infinity> pitti: (At least, every C and C++ project, that is)
[12:41] <infinity> Maybe all our tests are in python projects. :P
[12:42] <pitti> we do have a lot of GI and python stuff, but we should have way more than 19 C-ish tests
[12:42] <cjwatson> Certainly a lot of them are
[12:56] <pitti> infinity: "Jenkins Fixed - saucy-adt-eglibc 42"
[12:56] <pitti> infinity: thanks!
[12:59] <infinity> pitti: \o/
[13:00] <infinity> pitti: I was holding my breath, waiting for it to pass.
[13:02] <infinity> cjwatson: Yeah, I think the collection on quagga is "stuck".  eglibc went from running to passed, but quagga's still running.
[13:08] <cjwatson> infinity: I think it sometimes gets confused when different architectures' results come in at enough-different times, but I'm not sure
[13:08] <cjwatson> Hoping jibel can investigate
[13:16] <pitti> didrocks: as oneconf is one of the two broken tests that currently block pygobject: are you still interested in this in the least, or should I just drop the XS-Testsuite: for the time being?
[13:17] <jibel> last run of quagga 0.99.22.1-1ubuntu1 passed, I haven't yet investigated why it is still marked running
[13:56] <smoser> hey.. http://paste.ubuntu.com/5925348/
[13:56] <smoser> anyone have a better way to get "time that /sbin/init was started"
[13:56] <smoser> as that pastebin doens't make any sense to me. it seems like static-network-up-emitted was created before init was started
[13:57] <smoser> by .15 seconds.
[13:57] <stgraber> smoser: static-network-up is emitted right after ifupdown returns which usually means right after ntpdate was called and updated the system time
[13:57] <smoser> bah
[13:58] <smoser> so if i have ntpdate installed
[13:58] <smoser> i can't trust timestmaps on files
[13:58] <slangasek> smoser: "time that /sbin/init was started" - do what ps does when walking /proc?
[13:58] <stgraber> you can trust them after ntpdate ran, but anything before that may have an incaccurate timestamp
[13:59] <smoser> funny. but you can't realistically know when ntpdate ran.
[13:59] <stgraber> (unless you look at the kernel log buffer which uses ms since kernel startup as timestamp)
[13:59] <smoser> yeah, but the info i'm interested in isnt there.
[14:00] <smoser> slangasek, what time in ps were you talking aobut?
[14:01] <pitti> jibel, cjwatson: hm, so my libgphoto2 fix is now held by the failing gvfs, but the Debian sync that broke it in the first place went through even though gvfs was already failing at that time
[14:01] <smoser> duh. start_time.
[14:01] <smoser> hah.
[14:01] <pitti> jibel: do we perhaps not cover all rdepends sometimes?
[14:01] <pitti> or was that overwritten by u-release somehow?
[14:02] <slangasek> smoser: yep :)  I don't see offhand where in /proc that comes from, but the ps source would say
[14:03] <smoser> oh well.
[14:03] <smoser> so maybe i'll explain problem and see if others could give better way to solve.
[14:04] <smoser> i'm looking to  just print a report of certain events and when they occurred. and then ideally map that to a utc timestamp, and want at least millisecond level granularity.
[14:04] <smoser> the events i'm looking for are at least "kernel load time", "init executed", "network up", and then some from cloud-init. cloud-init log has timestamps that i can get at.
[14:06] <slangasek> smoser: you could also examine what bootchart does; it knows when we switch from initramfs to rootfs, etc
[14:07] <kirkland> smoser: you could cross reference with dmesg, which has microsecond granularity since boot;  find a couple of common events and then map/reduce those together
[14:07] <smoser> but not if those events are not in dmesg.
[14:09] <smoser> hm.. so nothing "easy". well, thanks for thoughts.
[14:33] <mterry> slangasek, regarding the MIR email, if there are multiple teams subscribed to a bug, how does errors.ubuntu.com know which is the "owning" team?  (you intimated it has such a concept)
[14:54] <roaksoax> mterry: o/! So to speed up things, we do have WI's to write dep8 tests for all the cluster stuff, and will definitely work on enabling the crmsh ones, but it is not something I'm can take care of right now
[14:57] <mterry> roaksoax, are the WIs for 13.10 timeframe?
[14:57] <roaksoax> mterry: yes
[14:58] <mterry> roaksoax, k
[15:03] <infinity> gdb Depends: gdbserver seems suboptimal...
[15:03] <slangasek> mterry: shared ownership, which is valid and allowed :)
[15:04] <slangasek> mterry: so it shows up on the list for earch team
[15:04] <mterry> roaksoax, I created a bug for tracking purposes, and assigned you.  Feel free to reassign
[15:04] <slangasek> each
[15:04] <mterry> slangasek, ah OK.  :)
[15:04] <roaksoax> mterry: awesome! thanks!
[15:06] <doko> TheMuso, ping about #1196967
[15:26] <jbicha> Riddell: could we get a rebuild of kdeplasma-addons for the ibus transition?
[15:40] <Riddell> jbicha: yeah can do
[15:40] <infinity> Riddell: I was just about to commit and upload, don't sweat it.
[15:41] <Riddell> infinity: thanks
[15:42] <infinity> (Well, after a test build)
[15:51] <smoser> i'd like someone's thoughts on https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1206164
[16:41] <ev> uhm, is it intentional that the running application in Touch consumes all the input, regardless of its state? If launch the gallery app, then do a kill -STOP $(pidof gallery-app), I have no way out (until I kill with -CONT)
[16:41] <ev> taking this to the appropriate channel
[16:42] <didrocks> pitti: barry introduced those tests as AP tests, it seems they never passed, I don't have the time to fix them TBH so dropping seems good
[16:44] <didrocks> pitti: I should find why this new ugettext crash though…
[16:53] <barry> pitti, didrocks which tests?
[16:53] <didrocks> barry: the oneconf autopkg tests, pitti told they never passed
[16:54] <barry> didrocks: darn
[16:55] <barry> didrocks, pitti let me try that locally
[16:56] <didrocks> barry: thanks!
[19:04] <mhall119> kenvandine: want to package Poppler 0.24 for me?
[19:05] <mhall119> pretty please?
[19:05] <seb128> mhall119, I'm doing poppler packaging, why do you need it?
[19:05] <mhall119> seb128: the docviewer core apps wants to start using it for PDFs
[19:06] <seb128> mhall119, they need the new version?
[19:06] <mhall119> seb128: didn't want to ping you, since it's after-hours
[19:06] <mhall119> seb128: yeah, because it has the Qt5 support
[19:06] <seb128> mhall119, nice!
[19:06] <seb128> mhall119, oh, they turned that serie stable, yeah, no problem to update
[19:07] <mhall119> cool
[19:07] <seb128> mhall119, I can look at that tomorrow
[19:07] <mhall119> thanks seb128!
[19:07] <seb128> yw
[19:07] <Laney> transition time? :-)
[19:08] <infinity> Oh joy, I just *love* poppler transitions.
[19:09] <kenvandine> seb128, thanks... glad you can do that for mhall119 :)
[19:09] <Laney> That's why they gave you the +1-maint crown. :P
[19:10] <seb128> Laney, looks like another of those ;-)
[19:10]  * kenvandine has compiled this plugin soooo many times on the phone... this time has to be the one!
[19:12] <infinity> kenvandine: I think you just jinxed it.
[19:12] <kenvandine> hehe
[19:13] <infinity> kenvandine: This is the build where you phone bursts into song, starts twirling around on your desk, and then sets itself on fire.
[19:13] <infinity> s/you/your/
[19:13] <kenvandine> nope, it worked :)
[19:13] <infinity> Yeah, or that.
[19:13] <infinity> I always get those two outcomes mixed up.
[19:13] <kenvandine> seb128, i have it displaying those services from the SIM :)
[19:13] <kenvandine> infinity, hehe :)
[19:13] <seb128> kenvandine, \o/
[19:14]  * kenvandine should have never tried exposing the QMap to QML... that is a disaster
[19:14] <seb128> kenvandine, did you end up wrapping the qt api?
[19:14] <kenvandine> yeah
[19:14] <ogra_> oh oh ... all your secrets exposed
[19:14] <seb128> kenvandine, do you add that to qtsystems?
[19:14] <Laney> the SIM services stuff in phone?
[19:14] <seb128> Laney, yes
[19:14] <Laney> that's exciting
[19:14] <kenvandine> seb128, no...
[19:14] <Laney> I didn't know we had some API for that already
[19:14] <kenvandine> private plugin in system-settings
[19:14] <seb128> Laney, ofono has one and qt bindings
[19:15] <kenvandine> Laney, ofono-qt has it
[19:15] <Laney> nice
[19:15] <Laney> go go settings which work
[19:15] <seb128> kenvandine, that wfm, but ideally we would add it to qtsystems, since they already have a ofono wrapper and that's where we get the imei etc
[19:16] <seb128> Laney, speaking of which I've moved the ringtone etc settings to the shared schemas, if you approve the mr today I can make system settings and phone app use those keys tomorrow
[19:16] <seb128> hint hint hint ;-)
[19:16] <Laney> seb128: OK, I can do a schema one but not qml stuff now
[19:16] <kenvandine> seb128, are we already patching qtsystems?
[19:16] <Laney> upstream it?
[19:16] <kenvandine> Laney, of course :)
[19:17] <Laney> :P
[19:17] <kenvandine> but i am wondering what our current delta is
[19:18] <seb128> kenvandine, we don't have one, but loicm is assigned work to a platform backend for Ubuntu afaik
[19:18] <seb128> kenvandine, check with pat maybe
[19:19] <seb128> or Mirv might know
[19:21] <kenvandine> seb128, oh, qtsystems5 wraps the ofono dbus API
[19:21] <kenvandine> not libofono-qt
[19:21] <kenvandine> that seems suboptimal
[19:22] <kenvandine> ls
[19:22] <Laney> . ..
[19:22] <kenvandine> whoops :)
[19:40] <seb128> kenvandine, yeah, well it works... ;-)
[19:47] <chiluk> Daviey jdstrand   can I get some SRU love on  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1179781 ?
[19:48] <chiluk> comments #4 and #5 have debdiffs waiting for upload.
[19:49] <Daviey> chiluk: if nobody beats me, i'll take a look tomorrow morning.  Too tired to look now.
[19:49] <chiluk> awesome thanks..
[19:50] <chiluk> Daviey you were the patch pilot for today right?
[19:50] <chiluk> I'll add you on copy just in case
[21:26] <smoser> anyone python3 friendly have ideas ?
[21:26] <smoser> http://paste.ubuntu.com/5926783/
[23:03] <cjwatson> smoser: You haven't set func to anything - no set_defaults calls
[23:04] <cjwatson> Perhaps that's relevant?
[23:06] <Snow-Man> argh.  ipv6 down *again*? :(
[23:07] <cjwatson> Snow-Man: If this is about a Canonical service, I doubt most people in this channel will have a clue how to help.  #canonical-sysadmin is more likely to stand a chance.