[04:43] <hallyn> sarnold: jdstrand: fwiw I spent a week trying to reproduce on my server specifically on ext3...  but tha tdoesn't mean ext3 isn't involved of course
[04:43] <hallyn> down to 104M.  that's impressive
[04:43] <hallyn> call it a feature and call it a day :)
[04:45] <sarnold> hallyn,jdstrand, did you ever have any luck recreating the problem on your server?
[05:32] <hallyn> sarnold: I never did.  not once
[05:32] <hallyn> now there is a bug i was sru'ing today which made reference to qcow2 corruption due to try_fiemap(), but i dont' think it's related
[05:33] <hallyn> infinity: bug 139209, a straight sync looks sane to me.  since you last touched it, just wanted to make sure you didn't have any objections
[05:54] <hallyn> well, seems fine.  few more test-builds
[06:09] <darkxst> slangasek, could you take a look at bug 1391102 its been sitting in unapproved for nearly two weeks now
[07:26] <didrocks> diwic: hey! not sure if you noted, but cyphermox uploaded bluez5 to the ppa, if you can upload a snapshot of pulseaudio soon, that would help us knowing if bluez5 support works (as it's one of the first use-case to test)
[07:27] <diwic> didrocks, cool, thanks for the heads up
[07:27] <didrocks> yw!
[08:22] <dholbach> good morning
[08:27] <LocutusOfBorg1> hi dholbach :)
[08:29] <dholbach> hi LocutusOfBorg1
[08:42] <seb128> @pilot in
[08:45] <tjaalton> gpg-agent doesn't seem to start on utopic, and there's no logfile created either.. anyone else seeing this?
[08:49] <seb128> tjaalton, gnome-keyring is the defautl gpg agent
[08:50] <tjaalton> well gpg-agent worked fine on trusty, and it has an upstart session job too
[08:50] <tjaalton> gnome-keyring doesn't know about my key, seems to be running though
[08:50] <tjaalton> how to configure it?
[08:54] <seb128> tjaalton, could be a fallover from https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1271591
[08:54] <seb128> see recent comments
[08:54] <tjaalton> ah
[08:54] <tjaalton> thanks
[09:07] <seb128> xnox, hey, is https://code.launchpad.net/~xnox/ubuntu-seeds/platform-init/+merge/225850 still a thing?
[09:07] <seb128> slangasek, ^ you could maybe review that one? it's the sponsoring queue since july
[09:18] <seb128> cjwatson, hey, do you have an opinion on https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222 ? It's in the sponsoring queue since august, would be nice to have it out one way or another :-)
[10:18] <Laney> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768600 ← could we apply similar to ureadahead in Ubuntu?
[10:18]  * Laney just got a trigger cycle
[10:53] <seb128> @pilot out
[11:37] <mardy> greyback: hi! Can you please join #ubuntu-touch?
[11:43] <xnox> Laney: yes.
[12:06] <Laney> xnox: ya, uploading
[12:07]  * Laney finds the triggers documentation hard to grok
[12:11] <xnox> Laney: yes, currently the policy maintainers are looking for reviewers to review the triggers implementation to review the triggers policy patch for sanity.
[12:11] <xnox> Laney: no takers yet....
[12:11] <Laney> interesting - I didn't look in policy
[12:11] <xnox> Laney: well, it's not /in/ policy yet =) because it's too cryptic to find reviewers to +1 it.
[12:12]  * xnox set off world rebuilds and now off for lunch.
[12:55] <infinity> hallyn: I feel like that bug number was probably missing a digit...
[12:59] <mdeslaur> Riddell: FYI, I'm still working on your updates, it's taking a while because I have to rebuild a bunch of dependencies in the -security pocket
[13:38] <hallyn> infinity: doh
[13:39] <hallyn> infinity: bug 1392095
[13:39] <hallyn> basically, sync libcap2.  seems to work.  built fine, let me still build qemu/lxc at lest.
[13:41] <hallyn> mdeslaur: is there any part of qrt that would exercise libcap2?
[13:47] <infinity> hallyn: Seems fine to me, go for it.
[13:47] <hallyn> thanks, will do.
[13:58] <mdeslaur> hallyn: not sure, maybe test-kernel-security.py
[14:11] <hallyn> mdeslaur: ooh, nice.  maybe i should find time to move some of the old ltp tests into there
[14:24] <caribou> seb128: thanks for sponsoring libnss-ldap, though there were concerns expressed around the changelog descriptions
[14:24] <seb128> caribou, those concerns should have been expressed on the bug then I guess?
[14:25] <caribou> seb128: agree
[14:25] <seb128> caribou, well now it's done, sorry about that
[14:26] <caribou> seb128: you don't have to be sorry, I should have done better & remove the debdiff
[14:27] <caribou> seb128: that's the problem with doing merges w/o upload rights, it is mostly useless
[14:28] <seb128> caribou, it's not useless
[14:28] <seb128> well depending of how complex the merge is and how much you are trusted
[14:29] <seb128> caribou, but it's at least useful in the sense you get sponsoring and experience which puts you on the way to ask for upload rights ;-)
[14:30] <caribou> seb128: yeah right, but in that case, it leaves the merge bugs in situation prone to errors
[14:30] <seb128> well, my fault as a sponsor for not spotting the error
[14:30] <seb128> it's also not of the best taste to have somebody reviewing it/having comments and not writing those on the bugs to avoid duplications or errors
[14:32] <caribou> seb128: tbh, I prefer to have it uploaded in that state (missing a more explicit changelog description & one useless Build-Dep) than the opposite
[14:32] <caribou> currently, all of the libnss-ldap package in the archive will generate Segfaults and unbootable systems if they're rebuilt
[14:33] <seb128> urg
[14:33] <seb128> that merge was also overdue
[14:33] <seb128> so thanks for putting efforts on it, it was non trivial
[14:33] <caribou> seb128: good learning experience I must say. Anything I should do to complete ?
[14:34] <caribou> seb128: like propose a debdiff with the missing bits in a new version ?
[14:34] <seb128> caribou, if you want to do a followup upload with some extra fixes/changes feel free yes
[14:34] <caribou> seb128: missing bits == more descriptive debdiff & remove po-debconf from the Build-dep
[14:34] <caribou> seb128: ok, will do. I have it ready but got dragged into other things
[14:35] <seb128> caribou, thanks
[14:35] <jdstrand> sarnold: I don't have a server. I was talking to them yesterday and they said it would be useful to have both the pre-corrupted image and then the corrupted image, so they could compare the qcow2 data structures for before and after
[14:35] <jdstrand> sarnold: so I was able to do that for them
[14:51] <mwhudson> mitya57: are you awake still?
[14:54] <mitya57> yes I am
[14:58] <mwhudson> mitya57: i commented on bug 1393583, i'm a bit confused as to what happened though
[15:00] <mitya57> mwhudson: the patch headers are correct, I just ran quilt refresh locally to remove some noise from there.
[15:00] <mitya57> (to be more precise, I have QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" in my .quiltrc)
[15:00] <mwhudson> mitya57: then why does applying the patch fail to add the last two lines of the file?
[15:01] <mitya57> And the reason for it FTBFS is probably some change between utopic and vivid.
[15:01] <mwhudson> no
[15:01] <mwhudson> (i do really need to get around to setting up quilt properly)
[15:02] <mitya57> Hmm indeed the last two lines are missing.
[15:02] <mwhudson> quilt bug?!
[15:03] <mitya57> maybe it is, my gccgo-stdlib-ignore ends with
[15:03] <mitya57> +       "unicode":             true,
[15:03] <mitya57> +       "unicode/utf16":       true,
[15:03] <mitya57> +       "unicode/utf8":        true,
[15:03] <mitya57> +       "unsafe":              true,
[15:03] <mitya57> +}
[15:03] <mwhudson> the difference i see between the patch i uploaded and the one quilt made for you is that mine says @@ 1,143
[15:03] <mwhudson> and yours says @@ 1,141
[15:04] <mitya57> I see, it's probably my fault
[15:04] <mitya57> Sorry, and let me fix it
[15:04] <mwhudson> np
[15:04] <mwhudson> and let me finally set up a .quiltrc
[15:05] <mitya57> $ cat ~/.quiltrc
[15:05] <mitya57> QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
[15:05] <mitya57> QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
[15:06] <mwhudson> mitya57: thanks
[15:09] <mitya57> mwhudson: uploaded
[15:11] <mwhudson> mitya57: yay thanks
[15:15] <mitya57> no need to thank me, it was my fault after all :)
[15:16] <mitya57> (and it built this time)
[15:16] <mwhudson> mitya57: well thanks for looking at my patch at all :)
[15:17]  * mwhudson reads about SRUs
[15:18] <mwhudson> (this bug breaks lxd when compiled with gccgo)
[15:19] <ogra_> you could fix it in lxe then
[15:22] <caribou> seb128: new debdiff is ready for LP: #1389152
[15:23] <caribou> seb128: the debdiff is over the .ubuntu1 version that you uploaded recently, not over the orig debian pkg
[16:15] <seb128_> caribou, great, thanks, going to review that in a bit
[18:40] <teward> has anyone noticed that the time it takes apport to actually generate error report data for the user to see has drastically increased since 10.04 all the way up to 14.04?  It takes, sometimes, 20 minutes to get data from the apport 'report error' window when xorg crashes, even in 14.04...
[19:11] <sarnold> jdstrand: heh, I hjadn't considered that a before-and-after might be more useful than just the "after" -- but it makes a lot of sense. nice work grabbing one :)
[19:14] <jdstrand> sarnold: thanks! though the idea to compare was rharper's. it makes a lot of sense