[03:31] <pitti> Good morning
[03:32] <pitti> doko_: verbose systemd build> can do
[03:46] <pitti> infinity: err, how is https://launchpad.net/ubuntu/+source/libgphoto2/2.5.2-0ubuntu5/+build/4964722 a "failed to build"?
[03:46] <pitti> infinity: the build log got debs and ends with "built successfully" !?
[03:47] <infinity> pitti: Yeah, and then my lp-buildd hack failed it hard due to segvs in the ringbuffer.
[03:47] <infinity> pitti: I admit that I didn't make that overly verbose.
[03:47] <pitti> ah
[03:47] <infinity> pitti: But it's a temp hack until we get some more stable buildds going.
[03:48] <pitti> what does that grep for?
[03:48]  * pitti has some trouble actually finding a segfault in the log
[03:48] <infinity> pitti: It's right at the end.
[03:48] <infinity> conftest[6966]: unhandled level 2 translation fault (11) at 0x00000008, esr 0x92000006
[03:49] <infinity> conftest[10403]: unhandled level 2 translation fault (11) at 0x00000008, esr 0x92000006
[03:49] <infinity> pitti: Nothing you can do about it, don't worry.  We're working on it.
[03:49] <pitti> ah, I thought something during the tests or so crashed, but apparently not
[03:49] <pitti> infinity: ack, thanks
[03:50] <infinity> Those conftests are collateral damage from the segv checker not being able to be smart.
[03:50] <infinity> Turns out that's actually a subtle glibc bug, and those segv on all arches. :P
[03:50] <infinity> I'm testing an upload for that right now.
[05:04] <wgrant> infinity: Well, the test doesn't exactly segv on all arches... it just accidentally fails to build on most/all of the other archs :)
[05:05] <infinity> wgrant: Potayto, puhchicken.
[05:24] <pitti> infinity, ogra_: https://android.googlesource.com/kernel/msm/+/57195292 sounds promising for the "uevents for vsync" madness?
[05:25] <infinity> pitti: Yeahp, shame it's for the wrong driver.
[05:25] <infinity> (But hopefully this is a trend)
[05:46] <infinity> pitti: Does umockdev-testbed/script_replay_socket_stream rely on a specific kernel feature that might not be enabled on my arm64 buildds?
[05:47] <pitti> infinity: well, I surely do hope that we have unix sockets there
[05:47] <pitti> otherwise, nothing I can think of
[06:17] <pitti> infinity: do we have a porter box for arm64 to investigate this?
[06:23] <pitti> doko_: done now; OOI, why do you need this? (it built fine on arm64)
[06:23] <pitti> doko_: (done in git, not uploaded yet)
[06:28] <infinity> pitti: No, we don't officially have any of the hardware we have. :P
[06:52] <dholbach> good morning
[07:28] <Noskcaj> Are we still aiming to make 14.04 only ship python3?
[07:33] <cjwatson> Noskcaj: on images, yes if possible, in the archive, that's a pipe dream and isn't going to happen
[07:34] <cjwatson> not that it's a bad idea to port things, just might as well have realistic expectations
[07:34] <Noskcaj> cjwatson, I mean on the images. Is the spreadsheet to-do list still current?
[07:34] <cjwatson> I doubt anyone's looked at the spreadsheet for some time
[07:35] <cjwatson> wow, there's still a lot on the images :-/
[07:35] <cjwatson> I guess the bulk of that is U1 (<- twisted)
[07:35] <Noskcaj> I'll see if i can port testdrive one the gtk3 transition for it is finished. Although i really need one of the old devs to help with that
[07:36] <Noskcaj> kirkland, speaking of which, is there any chance you'll ever have the time to help with gtk3 and python3?
[07:41] <ogra_> pitti, i added a comment with the link to bug 1234743 ... thanks
[07:49] <xnox> slangasek: yeah, I believe it's the bug report from the same person who was contacting me in private. Will investigate.
[07:53] <ogra_> WHEEE !
[07:53] <ogra_> http://review.cyanogenmod.org/#/c/28068/
[07:53]  * ogra_ dances
[07:57] <tvoss> ogra_, ;)
[07:58] <ogra_> xnox, looks like we can drop the uevent filtering again if the above works
[08:00] <xnox> ogra_: wow =)
[08:00] <xnox> that's nice!
[08:02] <xnox> ogra_: is that how the rest of platforms work?
[08:04] <ogra_> xnox, dunno, and i'm not sure yet it will help us ... its not for a maguro kernel and i dont know if our PVR driver will get along with that change
[08:05] <ogra_> only trying it out will revel that ... i'll do that later today
[08:05] <infinity> That's not the only driver that's seen that change, so there's some comfort in that.
[08:11] <Laney> @pilot in
[08:24] <pitti> ogra_: oh, that looks promising!
[08:27] <Riddell> how do I do a three way conditional in make?  I want to set something different for armhf in this http://paste.ubuntu.com/6217149/
[08:28] <cjwatson> else ifeq
[08:29] <cjwatson> Riddell: though watch out for backwards conditional syntax there as the first branch is currently "all architectures other than powerpc"
[08:30] <cjwatson> and should really be written as $(filter powerpc,$(DEB_HOST_ARCH)) rather than $(filter $(DEB_HOST_ARCH),powerpc), otherwise it's a trap for anyone trying to extend that
[08:30] <cjwatson> actually maybe it's OK either way
[08:38] <Riddell> cjwatson: why do we use that backwards syntax with filter, why not just ifeq ($(DEB_HOST_ARCH),amd64) ?
[08:39] <pitti> Riddell: I guess the idea is if you want to extend matching to other architectures
[08:39] <pitti> Riddell: i. e. "powerpc ppc64" or similar
[08:40] <henrix> @pilot in
[08:41] <cjwatson> Riddell: what he said
[08:41] <cjwatson> Riddell: but a plain ifeq is fine too if you don't expect that *shrug*.  However it's not especially unlikely that we'll have a ppc64el port at some point soonish
[08:44] <ev> chrisccoulson: hi. Are you familiar with apparmor and lxc? We're having some trouble talking to dbus when lxc confined: http://paste.ubuntu.com/6217202/
[09:21] <xnox> bdmurray: can I or you somehow search all ubiquity bugs and check if "GET/HEAD requests should not include body." is in the syslog ?
[09:42] <xnox> bdmurray: i think i am managing with ubuntu-bugpatterns. Wrote my first pattern and the search is running.
[10:19] <ev> pitti: thanks for clarifying the apport-retrace stuff!
[10:19] <pitti> ev: yw :)
[11:06] <doko> pitti, postgres ping?
[11:11] <pitti> doko: waiting for the upstream release announcement (folks are in the US)
[11:33] <jtaylor> can one get a list of package versions installed during adt tests?
[11:33] <jtaylor> I wondering about the scipy failure, the only change which falls in this 3 hour timeframe is glibc update
[11:34] <jtaylor> but I can't imagine how that could cause this type of failure
[11:35] <jtaylor> but I have no idea if it ran with ubuntu2 or ubuntu3
[11:49] <infinity> jtaylor: Seems more likely that it's a sketchy non-deterministic test, rather than glibc breaking it.
[11:51] <jtaylor> might be, but it worked reliably for a long time
[11:52] <infinity> jtaylor: It ran against the latest glibc.
[11:52] <infinity> jtaylor: https://jenkins.qa.ubuntu.com/job/saucy-adt-python-scipy/ARCH=i386,label=adt/50/console
[11:53] <infinity> jtaylor: Click "full log" at the top of the log.
[11:53] <infinity> jtaylor: Then you can see it doing some upgrading and installing bits.
[11:53] <jtaylor> thx
[11:53] <infinity> pitti: Erm, the adt systems are qemu right, not xen?
[11:53] <pitti> infinity: yes
[11:54] <infinity> pitti: Then why do the i386 VMs have libc6-xen installed?
[12:00] <Laney> @pilot out
[12:26] <pitti> infinity: (re from dinner) err -- they certainly aren't supposed to; checking
[12:27] <ogra_> pitti, the omapbf patch is a no go ... seems something actually makes use of the uevents on the other side
[12:27] <ogra_> *omapfb
[12:27] <ogra_> *sniff*
[12:27] <pitti> infinity: ah, it's in the cloud images already: http://cloud-images.ubuntu.com/saucy/current/saucy-server-cloudimg-i386.manifest
[12:28] <infinity> pitti: Kay.  Theoretically shouldn't do any harm (or, indeed, load at all) on a non-xen system, but it looked odd.
[12:28] <pitti> infinity: that seems a bit questionable indeed; but we can certainly purge that from the auto-package-testing VMs as we know they won't run on xen
[12:28] <pitti> infinity: is that causing some test failure troubles?
[12:28] <infinity> pitti: It shouldn't be.  If it is, it's my bug. :P
[12:29] <pitti> infinity: heh, ok
[12:29] <infinity> pitti: It was more just something I noticed in passing, looking at an i386 log.
[12:41] <Riddell> pitti: are you still incharge of langpacks?
[12:41] <pitti> Riddell: yes
[12:42] <Riddell> pitti: could it be possible to include kubuntu-patched-l10n in language-pack-xx ?
[12:43] <mvo> hi, I keep getting firefox crashes on my saucy box "g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting." - is this a known saucy issue? http://paste.ubuntu.com/6217833/ - I have it in gdb
[12:43] <Riddell> pitti: we use upstream translations for almost everything but there is a couple of patches with i18n which get extracted into kubuntu-patched-l10n only nothing then installs the kubuntu-patched-l10n .po file
[12:43] <xnox> mvo: do you have matching latest kernel & apparmor  in saucy?
[12:44] <xnox> mvo: if not fully dist-upgrade and reboot.
[12:44] <pitti> Riddell: you mean that package installs its own translation domain?
[12:44] <pitti> Riddell: and we should install that into the langpacks? or you need this package as a dependency? (which would be harder, and I think you should just seed it)
[12:44] <mvo> xnox: I think so, I upgraded yesterday or so and restarted since
[12:45]  * mvo double checks
[12:45] <Riddell> pitti: it includes kubuntu-patched-l10n.pot in the source and that gets put into launchpad where nothing else happens with it
[12:45] <pitti> Riddell: ah
[12:46] <pitti> Riddell: yeah, no problem
[12:46] <zyga> slangasek: hey
[12:46] <zyga> slangasek: looking at mountall 2.52 now
[12:46] <pitti> WARNING: unknown translation domain: kubuntu-patched-l10n
[12:46] <pitti> Riddell: ^ ack
[12:47] <pitti> Riddell: added to overrides and rolled out
[12:47] <Riddell> pitti: that warning seems scary but it means everything is ok?
[12:47] <pitti> Riddell: as it happens I'm waiting for LP to give me a full new export, for building the saucy final langpacks; should happen this evening or tomorrow morning
[12:48] <pitti> Riddell: it meant that the po files are in the tarball, just that langpack-o-matic previously didn't know what to do with it
[12:48] <pitti> as it isn't appearing in any binary package
[12:49] <zyga> slangasek: do I need debhelper 9.20120410 or can I keep using the old one from precise?
[12:53] <zyga> slangasek: ok, apparently standards version and debhelper weren't that relevant, rebooting to check
[12:54] <zyga> slangasek: success on first try, this looks promising
[13:03] <henrix> @pilot out
[13:13] <apw> tvoss, hey, would you be a good person to ask about location-service and platform-api.  if i am reading this right, they seem to have developed a mutual build dependancy preventing them building on powerpc
[13:13] <cjwatson> I wouldn't expect that stack to build on powerpc
[13:13] <tvoss> apw, powerpc?
[13:14] <ogra_> aww, bad, so no map apps on powerpc phones then
[13:14] <cjwatson> don't they end up at qtdeclarative sooner or later?
[13:14] <cjwatson> mir isn't built on powerpc, various other things in that stack probably aren't either
[13:14] <cjwatson> apw: I'd pick something else ;-)
[13:14] <tvoss> cjwatson, that's my understanding, too
[13:15] <apw> tvoss, they seem to have Architecture: any in 'em but hey
[13:15] <cjwatson> tvoss: circular build dependencies are bad news in general, though; they're a pain when bootstrapping new ports
[13:15] <apw> cjwatson, will do
[13:15] <cjwatson> apw: A bunch of things are Architecture: any when they aren't intrinsically restricted themselves
[13:15] <tvoss> cjwatson, I can break that package up post freeze
[13:15] <cjwatson> This is generally fine
[13:15] <tvoss> apw, would that be fine for you?
[13:15] <cjwatson> tvoss: (The new port we're bootstrapping right now, I confidently predict you will care about it rather soon)
[13:16] <apw> tvoss, i will poke something else, it sounds like you have it on your radar
[13:16] <tvoss> cjwatson, as long as it is after this week, I'm happy to care about it :)
[13:18] <cjwatson> apw: missing powerpc builds are only a problem if the same package used to build so it's blocking proposed-migration
[13:18] <mdeslaur> ogra_: oh darn, and here I was building my own powerpc phone! I managed to get it down to 8 kg
[13:18] <apw> cjwatson, ack
[13:40] <cjwatson> ev: would you mind fixing https://launchpadlibrarian.net/153264198/buildlog_ubuntu-saucy-arm64.libtimezonemap_0.4.0.1_FAILEDTOBUILD.txt.gz ?  I don't have commit access to the branch ... basically the problem here is a general one exposed by the particular setup of our arm64 builders at the moment; you can see the real problem if you search for "segmentation fault" in the log
[13:40] <cjwatson> it looks like the test either needs to tolerate not being able to open that file, or it needs to take an argument to let it read that file from the build tree during tests, possibly both
[13:41] <ev> we have tests?!
[13:41]  * ev looks
[13:42] <cjwatson> well, sort of a test
[13:47] <ev> cjwatson: still making sense of the code, but I'll take care of it
[13:48] <cjwatson> ta
[14:03] <ev> cjwatson: how's that http://paste.ubuntu.com/6218121/
[14:10] <cjwatson> ev: LGTM aside from indentation, thanks
[14:15] <ev> oh man
[14:15] <bdmurray> xnox: for future reference I have a local collection of ubiquity bug attachments and descriptions for quick searching
[14:15] <ev> WHO USES TABS ANYMORE
[14:16]  * apw for one
[14:16] <xnox> ev: https://plus.google.com/109160032876474505377/posts/2K7iAEALrSH
[14:16] <ev> HAHAHAHA
[14:16] <xnox> bdmurray: ah, I see. I think my bugpatter sucked, can you still do a search for that string?
[14:17] <bdmurray> xnox: yes, and they are already consolidated
[14:17] <xnox> bdmurray: ah, cool. thanks a lot.
[14:26] <ogra_> mdeslaur, hey, thats still lighter than my sparc phone ;)
[14:31] <jdstrand> ev: looking at http://paste.ubuntu.com/6217202/-- lightdm is running in the container?
[14:32] <ev> jdstrand: I'm not sure, but stgraber followed up with Mirv: https://pastebin.canonical.com/98867/
[14:32] <jdstrand> ok
[14:32] <jdstrand> thanks
[14:35] <jdstrand> tyhicks: curious: https://pastebin.canonical.com/98867/. it seems odd to me that lxc would all of a sudden start seeing this-- is that because AF_UNIX wasn't mediated it was just being passed though with no dbus mediation, but now that it is, dbus is getting mediated? that seems odd to me
[14:36] <jdstrand> tyhicks: I don't think it requires a lot of time to investigate since lxc was updated-- I just find it weird since we have had dbus mediation since august but lxc only saw it after the recent kernel/dbus uploads
[14:36] <jdstrand> tyhicks: s/only saw/seemingly only saw/
[14:38] <tvoss> ogra_, remind me, who was looking into the upstart memory issues?
[14:39] <ogra_> tvoss, several people
[14:39] <ogra_> (in a mtg, more details later)
[14:40] <tvoss> ogra_, ack
[14:56] <ogra_> tvoss, so cking was originally looking at the kernel side of this bug, i did too today (to find we cant fix it there) ... jodh fixes the "§upstart doesnt free memory on dbus disconnect", xnox did already add a filter for the uevent to upstart-udev-bridge to avoid upstart picking up all the uevents and he is now looking into a netlink filter to do the same for udevd (since that still consumes 5-10% CPU while the screen is on thanlks to t
[14:56] <ogra_> he event spam)
[14:57] <ogra_> tvoss, so with xnox finishing that the bug should be worked around enough to be fine for release (we should re-visit the kernel part in T)
[14:58] <cking> that sounds most fine
[14:58] <xnox> yeap. Not sure if i will have the udev fix today or not.
[14:58] <ogra_> cking, well, i would like to get rid of the event rather sooner than later or hide it on a lower level at least
[14:59] <cking> indeed
[14:59] <ogra_> filtering on all levels wont stop the traffic
[14:59] <ogra_> and i strongly assume thats what kills our performance on maguro
[15:06] <doko> mterry, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207 why committed and not fixed? it's promoted
[15:06] <mterry> doko, oh right, it was pre-promoted
[15:07] <mterry> doko, changed
[15:14] <tvoss> ogra_, okay, trying to understand this ... why do we accumulate memory somewhere in userspace?
[15:15] <ogra_> tvoss, bug 1234743 causes 60 uevents per second (one for each vsync) ... upstart-udev-bridge picks it up
[15:15] <ogra_> tvoss, due to bug 1235649 each of the uevents gets accumulated in ram by the session upstart
[15:16] <ogra_> tvoss, additionally udevd gets some load due to processing all these udevents
[15:16] <ogra_> *uevents
[15:17] <tvoss> ogra_, in my perfect little world, fixing 1235649 would help
[15:17] <tvoss> ogra_, modulo udevd being quite busy
[15:18] <ogra_> tvoss, the fix for 1235649 means that upstart just frees the ram on disconnect ... there is no proper way to prevent it from collecting valid uevents
[15:18] <ogra_> tvoss, we added an improper filtering mechanism for this, but the real fix would be to fix 1234743
[15:18] <tvoss> ogra_, sure, agreed
[15:18] <ogra_> tvoss, we only work on hiding the fallout
[15:19] <ogra_> the traffic is still happening and will eat performance
[16:05] <zyga> stgraber: ping
[16:05] <zyga> stgraber: is it safe to use _lxc from ubuntu-precise with a updated version of python-lxc from trunk?
[16:06] <zyga> slangasek: hey, it works, did a dozen reboots, no hangs anymore
[16:06] <slangasek> zyga: spiff
[16:07] <zyga> slangasek: will this come to ubuntu precise?
[16:08] <stgraber> zyga: we build and usually support current LXC on all supported releases starting with precise, so yes, running current LXC on precise should be fine
[16:08] <zyga> stgraber: I mean -- just the pure python bits while the _lxc module comes from 12.04 stock (0.8 IIRC)
[16:09] <slangasek> zyga: dunno, I would need to age it a bit to watch for further regressions and by then it might be too late to be worth it
[16:09] <stgraber> zyga: stock precise doesn't have python3-lxc
[16:09] <stgraber> zyga: and doesn't have the liblxc0 library you need for that either
[16:10] <tyhicks> jdstrand: No, the dbus message sending/receiving mediation point is completely separate from the AF_UNIX connect() mediation point
[16:10] <zyga> stgraber: it has here?
[16:11] <stgraber> zyga: that's because you're pulling it from the precise-backports ;)
[16:11] <tyhicks> jdstrand: adding in the AF_UNIX connect() mediation point wouldn't suddenly cause dbus message send/receive denials
[16:11] <zyga> ah, it's from backports
[16:11] <zyga> :)
[16:13] <zyga> slangasek: hmm, so precise is going to stay broken?
[16:13] <zyga> slangasek: don't our customers hit that or anything? I mean the next LTS is 6 months away
[16:13] <slangasek> zyga: clearly they don't, since you're the first person to report this issue
[16:14] <zyga> slangasek: wow, nobody uses nfs nowadays :)
[16:14] <zyga> slangasek: is the bug specific to nfs btw?
[16:17] <slangasek> zyga: it probably affects all network filesystem types
[16:17] <zyga> slangasek: ceph?
[16:17] <slangasek> if mounted at boot time via /etc/fstab, I don't see why it wouldn't be affected
[16:18] <slangasek> but it's not as simple as "if you have network filesystems, you hit this bug"
[16:18] <slangasek> I have network filesystems mounted at boot, since before precise, and never hit this bug
[16:18] <zyga> slangasek: ah, so it was caused by that nested mount point?
[16:18] <zyga> stgraber: lxc-create hangs on flock -x 200, any idea why that may happen?
[16:18] <zyga> stgraber: works on my desktop, hangs on my server (both 12.04)
[16:19] <slangasek> zyga: honestly, there were so many things that were just slightly wrong that I'm not going to try to untangle that right now and tell you what the root cause was
[16:19] <cjwatson> slangasek: reviewing your grub branch for bug 1236625
[16:19] <slangasek> cjwatson: what'd I do wrong? :)
[16:19] <cjwatson> slangasek: I'm not convinced that --target=efi_hints always outputs a single drive name suitable for use in $root
[16:19] <slangasek> right, I didn't know if it did either
[16:19] <cjwatson> slangasek: in fact it seems to explicitly output delimiter-separated names
[16:19] <zyga> slangasek: fair enough :)
[16:20] <slangasek> cjwatson: cut -f1 ?
[16:20] <cjwatson> possibly but I wonder if there's a better way
[16:20] <zyga> slangasek: but IIRC after dropping all exotic cases it was still hanging with just a bunch of mount points
[16:20] <cjwatson> just reading through that code closely now
[16:21] <slangasek> zyga: well, one of the issues we did find in your case was "names resolvable before the network is up"
[16:21] <zyga> slangasek: ah, right
[16:23] <cjwatson> slangasek: you know, I'd almost be more comfortable using the search.fs_uuid path anyway
[16:23] <cjwatson> (if it works)
[16:23] <cjwatson> slangasek: the hints mean that it shouldn't be inefficient - it'll try the hinted locations first
[16:24] <slangasek> cjwatson: yeah, it will work
[16:24] <cjwatson> slangasek: you could even reduce a lot of the complex duplicated code, then
[16:25] <slangasek> could you?
[16:25] <cjwatson> Could the test on line 641 just become "if no abstraction || (efi && uefi_secure_boot && -e efi_signed)"?
[16:25] <slangasek> let me check
[16:26] <slangasek> yeah, seems plausible; want me to test that here?
[16:27] <cjwatson> yes please :)
[16:27] <cjwatson> that avoids having to copy the horrible regex and stuff
[16:27]  * slangasek nods
[16:29] <slangasek> cjwatson: well, efi_signed is only set at line 837
[16:30] <cjwatson> yeah, you'll need to hoist that up, but that'e asy
[16:30] <cjwatson> *that's easy
[16:30] <cjwatson> $source_dir and $efi_suffix are already defined
[16:31] <cjwatson> by the if block ending line 512 at the latest
[16:34] <slangasek> cjwatson: yeah, it found its brain on reboot.  Want me to update the patch?
[16:34] <cjwatson> please, then I'll be happy to merge
[16:34] <cjwatson> sorry for the delay, the copied code entirely melted my brain before I realised it was copied :)
[16:35] <slangasek> ah :-)
[16:36] <zyga> brb
[16:45] <slangasek> cjwatson: branch updated
[16:57] <infinity> pitti: Can you upload your fixed umockdev?
[17:00] <bdmurray> cjwatson: is the v-done tag in bug 1234705 for every release?
[17:01] <cjwatson> bdmurray: Yes
[17:03] <cjwatson> slangasek: You meant to include MokManager bits in that latest version?
[17:04] <slangasek> cjwatson: hnngh no, sorry
[17:04] <cjwatson> (should I anyway?  but if so it should be a separate patch)
[17:04] <slangasek> cjwatson: there's a separate mp for that open
[17:05] <cjwatson> whoops, better look at that too then :)
[17:05] <cjwatson> I think it will be just after final freeze though :(
[17:06] <slangasek> cjwatson: cruft removed, repushed
[17:06] <cjwatson> (but I'll go for an exception, I think it's reasonable)
[17:08] <cjwatson> slangasek: any chance you could quickly refactor https://code.launchpad.net/~vorlon/ubuntu/saucy/grub2/mokmanager-support/+merge/187148 to make the mokmanager changes be a separate ubuntu_* patch on top?  I might coalesce when I merge into Debian, but I find that having changes to the Debian patches not be in separate patches is a recipe for me getting confused
[17:11] <slangasek> cjwatson: looking
[17:16] <cjwatson> slangasek: ok, got to EOD now as I'm already late, but I can merge this later tonight
[17:16] <cjwatson> slangasek: (already merged your first branch)
[17:17] <slangasek> cjwatson: thanks - and mokmanager branch re-pushed now
[17:23] <cjwatson> slangasek: thanks
[17:25] <cjwatson> slangasek: ok, you're in luck, uploaded, but somebody else will have to tend grub2-signed
[17:25] <cjwatson> uploading anyway
[17:25] <slangasek> cjwatson: ack, thanks :)
[18:01] <mdeslaur> ev: might want to check out 1238139 to make sure
[18:05] <hallyn> this is odd - i'm on a precise system, doing 'apt-get build-dep qemu-kvm'.  it says it can't find source package.  apt-cache show qemu-kvm indeed doesn't show the source pkg name (which is qemu-kvm)
[18:05] <sarnold> hallyn: deb-src lines in your sources.list ?
[18:06] <hallyn> yup
[18:07] <hallyn> oh well, using dpkg-checkbuilddeps by hand...  i seem to have messed something up earlier
[18:08] <ev> mdeslaur: that code hasn't changed in literally years. I'd be quite surprised if this were true. I'll endeavour to look at it tomorrow
[18:08]  * ev home
[18:08] <mdeslaur> ev: yeah, I have the same feeling
[18:15] <dobey> hallyn: "apt-cache show" doesn't show the "Source:" entry for packages where source name == binary name
[18:16] <sarnold> I wish it did, that'd make grep ^Source a lot more useful..
[18:18] <hallyn> dobey: interesting.  like sarnold i wish it did :)
[18:18] <hallyn> thx
[18:23] <stgraber> hallyn: just do apt-cache showsrc <binary package name>
[18:23] <stgraber> and grep ^Package on that one
[18:25] <dobey> yeah
[18:38] <slangasek> bdmurray: do you have a reproducer for bug #1024590?
[18:38] <bdmurray> slangasek: unfortunately, no
[18:42] <slangasek> bdmurray: ok.  looking at the code, I'm not sure why this is valid in the first place... this is a subclass of Gtk.Treeview, which http://www.pygtk.org/docs/pygtk/class-gtktreeview.html says is a subclass of Container, and http://www.pygtk.org/docs/pygtk/class-gtkadjustment.html says gtk.Adjustment applies to various things but not to GtkContainer.
[18:54] <mino> hi :) how does dhclient get called? Where is the script that parses the network config? I have a problem that dhclient is not listening on a second dhcp interface if i use vlans
[19:25] <ekarlso> is there a way to create a "bootstrapped" / initial debian folder inside a source folder ?
[19:29] <lifeless> ekarlso: make-dpkg or something like that exists, I forget the name
[19:53] <lenios> ekarlso, dh-make ?
[20:31] <bdmurray> pitti: Do you have any opinion on the SRU of bug 1215911?
[21:34] <ricardobarbosams> hi
[21:34] <ricardobarbosams> i try deploy router proxy-arp
[21:34] <ricardobarbosams> but not working
[21:34] <ricardobarbosams> i set /proc/sys/net/ipv4/all/proxy_arp
[21:35] <ricardobarbosams> exists any module for kernel for working?
[21:35] <ricardobarbosams> my version ubuntu 13.04
[21:39] <sarnold> ricardobarbosams: does "sysctl -a | grep proxy_arp" show you anything interesting or unexpected?
[21:40] <ricardobarbosams> root@ubuntuDELL:~# sysctl -p | grep proxy_arp
[21:40] <ricardobarbosams> net.ipv4.conf.eth0.proxy_arp = 1
[21:40] <ricardobarbosams> net.ipv4.conf.eth1.proxy_arp = 1
[21:40] <ricardobarbosams> root@ubuntuDELL:~#
[21:41] <ricardobarbosams> in tcpdump displaying the request arp, but not response
[21:41] <ricardobarbosams> 17:41:15.262145 ARP, Request who-has 172.16.200.3 tell 172.16.200.2, length 46
[21:41] <ricardobarbosams> 17:41:16.262597 ARP, Request who-has 172.16.200.3 tell 172.16.200.2, length 46
[21:50] <CyclicFlux> Good day all. I have a bit of a prob, and had a question or two.
[21:50] <CyclicFlux> While upgrading from 12.04, to 12.10, my electricity went out causing my system to lose power. Recovery appears to work
[21:51] <CyclicFlux> could I do a chroot, and then continue the upgrade process?? Or is it best to do it with a Ubuntu 12.10 alternative install Disk.
[22:11] <slangasek> CyclicFlux: define "recovery"?  If the system boots, you may as well try 'dpkg --configure -a && apt-get -f install && apt-get dist-upgrade'.  Worst case is that you lose the time it takes trying to run, and have to resort to a reinstall; best case is that it completes successfully