[05:38] <pitti> Good morning
[07:18] <dholbach> good morning
[07:30] <dholbach> @pilot in
[07:35] <pitti> stgraber: confirming, current lxc is happy again; thanks for the super-fast fix!
[08:48] <BrotherBrick> morning ;)
[08:48] <BrotherBrick> infinity: the new [SRU] Ogre3D package works great on amd64 and i386, thank you
[09:03] <BrotherBrick> Cheers :)
[09:28] <seb128> Laney, mardy: btw, confirmed, uoa/e-d-s calendar integration works great with mbarnes's fix!
[09:28] <Laney> seb128: cool, feel free to upload
[09:28] <seb128> Laney, ok
[09:28] <Laney> oh, /me remembers reading an email about e-d-s
[09:29] <Laney> man, having work email on your phone is a bad idea
[09:29] <Laney> "yeah, I'll reply to that tomorrow" → forget because it's read now
[09:29] <seb128> can't you tag/flag emails from your phone?
[09:29] <Laney> probably
[10:06] <seb128> doko, hey, could you look at the python2.7 autopkgtest?
[10:06] <seb128> doko, one test is failing, see https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python2.7/9/ARCH=amd64,label=adt/console
[10:06] <seb128> doko, that makes the new libffi be blocked in trusty-proposed
[10:26] <ogra_> cjohnston, the germinate output still has recommends in it ... annd i noticed that it does only x86
[10:27] <cjohnston> I'm guessing cjwatson ^
[10:27] <ogra_> oh
[10:27] <ogra_> (sorry)
[10:28]  * Laney hugs cjohnston 
[10:28] <cjohnston> :-)
[10:36] <mitya57> What should I do to let csound migrate to -release? Some binary packages were intentionally renamed/dropped.
[10:43]  * mitya57 didn't notice the rdepends :)
[11:05] <seb128> directhex, hey, seems that banshee/tomboy needs to be built with the new dbus-sharp, is anyone working on making those changes?
[11:06] <directhex> seb128, tomboy is on my TODO but i've been busy. banshee is hyperair's and i've been bullying him into doing it, although he's been busy
[11:06] <seb128> ok
[11:07] <seb128> directhex, I guess that means "being handled", which is good enough for me, thanks ;-)
[11:07] <directhex> seb128, there's a tracker on release.d.o now, so we're aware of it, it just needs finishing
[11:07] <seb128> right, as long as somebody is looking at it I'm happy ;-)
[11:07] <seb128> thanks
[11:08] <directhex> seb128, i've mostly been busy with architecture concerns, of late. armhf packages should be available by xmas, finally
[12:12] <dholbach> @pilot out
[12:17] <cjwatson> ogra_: remind me next week when I'm not on vacation
[12:18] <ogra_> cjwatson, oh, sorry, i didnt know
[12:18] <ogra_> enjoy !
[14:05] <pitti> dholbach: patch pilot report> wow! *hug*
[14:05] <dholbach> pitti, I knew I was going to be a bit busy this Friday, so I got some sponsoring done during the last days
[14:05] <dholbach> but yeah... it's good we're a bit closer to 0 again
[14:07] <seb128> nice to see all those packages going in sync as well
[14:07] <seb128> dholbach, good work ;-)
[14:09] <dholbach> merci beaucoup
[14:19] <pitti> brainwash: finally! bug 1252121
[14:23] <brainwash> pitti: yes, finally :) systemd-shim did cause quite some trouble =S
[14:39] <dobey> cjwatson, infinity: was there agreement to revert dpkg strictness in trusty?
[14:55] <mterry> @pilot in
[15:03] <infinity> zul: Please use dh_autotools-dev instead of patching config.{sub,guess}.  Patching is much harder to maintain, and just breaks for the next port.
[15:03] <zul> infinity:  ack
[15:04] <infinity> zul: I think I'll redo openchange right now, so you can see what I mean.
[15:04] <zul> infinity:  thanks
[15:04] <zul> infinity:  its blocking samba 4.0
[15:05] <infinity> Oh, but there's the ordering confusion that comes in with mixing with dh_autoreconf.  I guess I'll leave this one alone.
[15:05] <infinity> Until I sort out how to get that properly fixed and documented in Debian.
[15:05] <infinity> zul: Nevermind, carry on. :P
[15:15] <mterry> infinity, I'm looking at SRU bug 859600.  xnox uploaded an SRU to precise, but it was rejected.  Was that because we didn't also SRU to quantal yet or for some other reason?
[15:16] <mterry> (I'm assuming you were the one that handled it, just because you're mentioned in the bug)
[15:17] <doko> seb128, python2.7 uploaded to unstable, will sync over the weekend
[15:17] <seb128> doko, thanks
[15:18] <seb128> doko, btw, the libffi fixed the indicators tests stack smash issues, thanks!
[15:19] <infinity> mterry: No idea who rejected it, or when, or why.  The uploader would have gotten an email detailing all those things at the time.
[15:20] <mterry> xnox, ^ ?
[15:20] <mterry> infinity, thanks
[15:20] <xnox> mterry: let me check my mail archive.
[15:20] <xnox> mterry: "Rejected by Chris Halse Rogers: The Breaks/Replaces versioning is wrong; it should contain the most recent version ts, rather than unconditionally breaking any package younger than the most recent build"
[15:21] <mterry> xnox, ah right, it shouldn't have binary:Version or whatever in the Breaks
[15:21] <mterry> xnox, OK, I can prep new Q and P uploads today
[15:21] <stgraber> pitti: np
[15:21] <xnox> mterry: thank you.
[15:22] <xnox> mterry: i guess it's easiest to download the rejected package files and tweak them.
[15:23] <mterry> xnox, ok
[15:23] <infinity> doko: If the eglibc test build in my PPA goes okay, I'll copy it with binaries to a toolchain PPA.
[15:23] <infinity> doko: (if not, I'll fix it :P)
[16:05] <Cas> hi charles, I have a few questions about indicator-bluetooth code
[16:10] <bdmurray> slangasek: looking at bug 708517 and its corresponding error this has not occurred in a release later than 12.04.  I'm thinking about closing it.
[17:24] <slangasek> bdmurray: closing 708517> yes, sounds reasonable to me
[17:31] <tumbleweed> infinity: aww. all that way, and then a non-ported execstack (pypy)
[17:31] <tumbleweed> I wouldn't worry about it on arm64, though. There's no JIT support
[17:34]  * infinity glares at the one test regression on glibc/ppc...
[19:02] <smoser> cjwatson, can I use gpt partition table on a root disk and have only a single partition  and have grub-pc as my loader ?
[19:02]  * smoser realizes that cjwatson has no business being around this time on a friday.
[19:11] <maxb> smoser: I think you need a special 'biosgrub' partition to make that work, into which grub puts the bit of itself it embeds after the MBR on an MBR disk
[19:13] <maxb> 'set <number> bios_grub on' is the parted command for marking a partition as such
[19:14] <smoser> maxb, yeah. hm.. so does that mean for uefi you're minimum is 3 partitions ?
[19:15] <smoser>  1. bios_grub
[19:15] <smoser>  2. /boot
[19:15] <smoser>  3. /root
[19:15] <smoser> ?
[19:16] <maxb> If you're doing UEFI, you'd be using grub-efi instead of grub-pc and could just have a single partition, I would think
[19:16] <maxb> If you're doing booting using grub-pc, then I would think only two partitions would be needed, bios_grub and /
[19:16] <maxb> Though some swap would probably be nice too :-)
[19:23] <infinity> smoser: Not only does he have no business being around, he's actually on VAC.
[19:36] <smoser> thanks maxb
[19:59] <slangasek> maxb: UEFI "single partition"? If you're doing UEFI, you need a UEFI boot partition
[19:59] <maxb> Um, yes, brain skipped over that somehow :-)
[20:00] <slangasek> smoser: as for GPT, as long as the firmware can *address* the root partition to actually find the stage2 bootloader from grub, yes, it's fine to have a single GPT partition
[20:00] <slangasek> (for bios)
[20:00] <slangasek> you don't per se need any special biosgrub partition, since GPT is backwards-compatible with MBR in terms of layout and you have space for the grub stage1 in the usual place
[20:01] <slangasek> but the question is, if you don't set up a special partition for grub stage2, will grub stage1 be able to find stage2 at $random_offset on your disk
[21:13] <Noskcaj> Would we be able to update memtest86+ to 5.01 in ubuntu since debian is going very slowly on this?
[21:21] <slangasek> Noskcaj: how will we validate the new version?
[22:09] <mterry> @pilot out