[00:42] <bcurtiswx> whats the easiest way to get what functions are called when performing an action in a program
[00:42] <bcurtiswx> say i open a new IM window in empathy, how do I find out what functions are called ?
[00:43] <penguin42> bcurtiswx: You trace it back or forward from something that you know must have happened
[00:44] <bcurtiswx> penguin42, so keep strace open, wait for it to stop then perform the action?
[00:44] <penguin42> bcurtiswx: So if it was a menu item that triggered it you'd look for the menu code and what ever registered the action for it; or you could go the other way, you could set a breakpoint at some function in gnome you know must have got called - e.g. whatever opens a new window
[00:44] <penguin42> bcurtiswx: strace is too low level really
[00:45] <penguin42> bcurtiswx: gdb and breakpoint on a function you expect to get called and then do a backtrace
[00:45] <bcurtiswx> OK
[00:45] <bcurtiswx> just 'break' in a c file ?
[00:45] <penguin42> yeh
[07:08] <pitti> Good morning
[07:08] <a3Dman> good morning
[07:08] <TheMuso> Hey pitti.
[07:09] <pitti> hey TheMuso, how are you?
[07:15] <TheMuso> pitti: Well thanks, yourself?
[07:23] <pitti> TheMuso: pretty well, thanks!
[07:27] <dholbach> good morning
[07:44] <didrocks> good morning
[07:46] <dholbach> salut didrocks
[07:46] <didrocks> hey dholbach
[09:31] <geser> pitti: Hi, as you dealt with hal in the past, is disabling the v4l code the right fix for the current hal FTBFS? (http://launchpadlibrarian.net/63796245/buildlog_ubuntu-natty-i386.hal_0.5.14-5_FAILEDTOBUILD.txt.gz)
[09:32] <pitti> geser: I filed bug 716275; if that is easy to do, I'd prefer that
[09:33] <pitti> geser: if not, I'd add a patch upstream to check if it is available and disable it in configure if not, and ask mbiebl to cherrypick it
[09:33] <geser> ok
[09:35] <alkisg> I've attached a debdiff for natty in LP bug #552404, is there anything else I need to do? The https://wiki.ubuntu.com/StableReleaseUpdates wiki page doesn't apply for development releases, right?
[09:37] <alkisg> So I can just re-subscribe ubuntu-sponsors?
[09:39] <persia> alkisg, Yes.  The sponsor will upload, and then the SRU process will resume.  Do you need something for maverick as well?
[09:39] <alkisg> persia: yes, but I don't have a maverick installation available for testing
[09:39] <persia> My understanding of lucid SRU is that there is an expectation of fix in natty and maverick first.
[09:40] <persia> alkisg, It's a chroot bug, right?  Do you have disk space to create a maverick chroot?
[09:41] <RAOF> pitti: /usr/include/linux/videodev.h is the header for the V4L API, which is entirely removed in 2.6.38 - we don't want to ship a header for code that can't work on Natty, do we?
[09:42] <alkisg> persia: I guess I could ask someone over in #ltsp to try it in maverick, to save me the time of creating a maverick chroot, since I won't ever be using maverick...
[09:42] <persia> alkisg, I've requested nomination for each release, which should make it easier to follow the correct status of SRU.  Needs someone to approve the nominations, but the sponsor will probably do that as well.
[09:42] <alkisg> Thank you :)
[09:42] <pitti> RAOF: ah, ok, good to know
[09:43] <persia> alkisg, Good luck!
[09:43] <pitti> RAOF: I'll patch hal upstream then
[09:43] <RAOF> pitti: The correct response is to port to V4L2 or, at a pinch, just disable V4L support.
[09:43] <RAOF> Given hal's tremendous utility, I'd guess disabling V4L support is the winning move :)
[09:44] <persia> Are there no devices that have V4L support, but not V4L2 support?
[09:44] <RAOF> persia: Not anymore, no.
[09:44] <pitti> RAOF: absolutely
[09:44] <persia> Cool!
[09:44] <RAOF> Well, not with 2.6.38, at least, because it doesn't support V4L at all :)
[09:45] <persia> heh.
[09:45] <RAOF> So there might now be some *unsupported* devices, but I don't know of any offhand.
[10:28] <pitti> geser: ok, fixed upstream; I'll talk to Michael now
[10:33] <ev> @pilot in
[10:34]  * dholbach hugs ev
[10:34] <dholbach> :-D
[10:34] <ev> google calendar ftw
[10:38] <apw> cjwatson, have you heard of any plymouth not working issues recently?  for example: bug #718044
[10:46] <cjwatson> apw: nothing new
[10:46] <cjwatson> apw: the last several updates to plymouth weren't mine, though
[10:48] <cjwatson> apw: ask soren
[10:48] <apw> cjwatson, will do thanks
[10:50] <soren> whuh?
[10:50] <soren> Oh, crap.
[10:50] <apw> soren, there is a bug about the latest plymouth affecting some people
[10:51] <apw> actaully ubuntu15 and up
[10:51] <udienz> cjwatson, is see in MoM that adduser need to merge, but an changelog says only undating translations. is aduser will be merge this time?
[10:51] <soren> ubuntu15 was  bit of a bust, but ubuntu16 should be fine.
[10:51] <soren> Darn it.
[10:51] <soren> I'm on it.
[10:51] <pitti> geser: pushed fix to Debian's hal svn; will wait for Michael to review/upload, though
[10:52] <cjwatson> udienz: we're after Debian import freeze, so merges are not a priority.  Is there a particular reason why we should pay attention to this merge?
[10:52] <apw> soren, there seems to be be little in the way of changes from the ubuntu14 which was claimed as working ... odd
[10:52] <cjwatson> udienz: the big merge push is in the first half of the release cycle, i.e. not now
[10:53] <udienz> cjwatson: ah ok.  i think is not, because only updating translation from debian.
[10:53] <lool> Ah
[10:54] <cjwatson> udienz: so just leave it, it'll happen in natty+1
[10:55] <lool> cjwatson: I've just seen util-linux gained armhf support in Debian and decided to merge it; in the merge, I ended up removing a lot of delta that I think we don't need anymore; do you mind these changes at this point?  Maybe it would be best if these got peer reviewed, I've pushed them as UNRELEASED to the UDD branch
[10:55] <lool> armhf support would be trivial to add on top of the Ubuntu package, but heck, I've merged it now  :-)
[10:55] <cjwatson> lool: what sort of things?
[10:56] <lool> cjwatson: upgrade snippets mostly
[10:56] <cjwatson> from pre-lucid?
[10:56] <lool> or diff which didn't add any value to us
[10:56] <lool> cjwatson: yes
[10:56] <cjwatson> I don't really care if we drop pre-lucid upgrade stuff
[10:56] <lool> http://paste.ubuntu.com/566915/
[10:57] <cjwatson> the stuff listed on https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/util-linux/natty seems generally fine
[10:57] <lool> cjwatson: I usually review the full debian -> ubuntu diff when documenting remaining changes; the longer it is, the more painful for me
[10:58] <lool> that's usually why I remove this stuff when I can, or to make maintainer scripts more readable
[10:58] <cjwatson> sure
[10:58] <soren> apw: Yeah. /me investigates
[10:59] <lool> cjwatson: Ok; will give it some testing now, and upload; thanks
[10:59] <apw> soren, the linked internally bug for the kernel seems to be reporting grub2 showing corrupted display ... so there may be a grub2 connection in part
[10:59] <cjwatson> none of that has changed recently
[11:00] <apw> cjwatson, yeah, the description is very hard to understand, i have requested much clarification on the linux bug
[11:00] <cjwatson> certainly not as recently as the plymouth changes mentioned
[11:11] <GunnarHj> ev: Hi Evan, do you have time to sponsor a couple of MPs? Both are linked to from https://launchpad.net/bugs/666565
[11:12] <ev> GunnarHj: I'll have a look
[11:13] <GunnarHj> ev: Great!
[11:20] <sivang> hi all
[11:20] <sivang> what's the relationship between Ubuntu and Linaro?
[11:20] <sivang> (ubuntu-mobile is closed and said to ask here)
[11:21] <persia> sivang: Complex :)
[11:21] <sivang> persia: complex?
[11:21] <sivang> persia: it is for armel yes?
[11:21] <persia> So, a number of folks involved in Linaro are also involved in Ubuntu.
[11:21] <sivang> does it use apt?
[11:22] <persia> Linaro has some goals (see www.linaro.org), and tries to accomplish them within Ubuntu, releasing things based on Ubuntu.
[11:22] <persia> So, from an Ubuntu perspective, Linaro just happens to be another project some folk are involved in.
[11:22] <persia> From a Linaro perspective (I'm guessing), Ubuntu is distribution project that is one of the targets for their efforts.
[11:23] <persia> Ubuntu supports armel, and tends to select the Linaro branches of tools to do so, because those tend to have the best performance on armel.
[11:23] <persia> But I don't believe there exists any single interface, or anything, which is why I say "complex".
[11:24] <sivang> so when I do linaro stuff I work .deb and can use ubuntun repos?
[11:25] <persia> Also, that's *completely* unrelated to ubuntu-mobile.  ubuntu-mobile was part of an effort to make Ubuntu better for highly mobile and embedded uses.  The consensus seemed to be that as the devices got better, it was more interesting to just deliver normal Ubuntu, than to try to make a special software stack.
[11:25] <persia> You'd do better to ask the linaro folk, but I believe so.
[11:26] <soren> apw: I think it
[11:26] <soren> s all me, actually.
[11:26] <soren> apw: I don't understand why at all, though.
[11:28] <soren> apw: the avoid-sigpipe patch causes it.
[11:28] <soren> apw: If I revert that, it works again
[11:28] <sivang> persia: thanks, makes sense.
[11:29] <soren> apw: It just don't understand. write(a,b,c) ought to be the same as send(a,b,c,0), but even that substitution causes it to fail.
[11:35] <cjwatson> soren: is 'a' a socket fd?
[11:37] <soren> cjwatson: Let's pretend the answer is "no".
[11:37] <soren> cjwatson: Just for giggles, let's say it's a pipe.
[11:37] <cjwatson> you can only use send() on sockets
[11:38] <soren> Ah.
[11:38] <soren> man send(2) is rather misleading, then.
[11:38] <soren> Darn it.
[11:38] <cjwatson> depends how you look at it
[11:39] <cjwatson> it does start "send a message on a socket"
[11:39] <soren> cjwatson: Is there any way I can get write() call to not SIGPIPE if the remote end of a pipe is closed?
[11:39] <cjwatson> I think "The only difference between send() and write(2)" is intended to be read as "(for sockets)"
[11:39] <soren> cjwatson: I thought changing it to send and passing MSG_NOSIGNAL would do the trick.
[11:40] <soren> And certainly it did in my tests, but they were using actual sockets :-/
[11:42] <cjwatson> I'm surprised it isn't a socket, actually.  ply_boot_client_connect calls ply_connect_to_unix_socket
[11:42] <soren> Alternatively, some way to reliably determine if an fd is a socket.
[11:42] <soren> I'm sure it is.
[11:43] <soren> It's probably just that other things are using the same routine with non-sockets.
[11:43] <cjwatson> ah
[11:43] <soren> ...which I hadn't expected, tbh.
[11:43] <cjwatson> yes, src/client/plymouth.c calls ply_open_unidirectional_pipe
[11:43] <cjwatson> and there are a couple of other calls
[11:45] <cjwatson> you probably get EBADF from send - you could just check for that and fall back to write
[11:45] <cjwatson> that would be OK
[11:45] <cjwatson> actually, you get ENOTSOCK
[11:45] <cjwatson> which is pretty clear
[11:46] <soren> Heh.
[11:47] <soren> cjwatson: Yeah, that's a good idea. I'll try that.
[11:56] <soren> cjwatson: So if this were a pipe, the only way to avoid being SIGPIPE'd is to flush the fd first and see if it's closed?
[11:57]  * soren reboots to check this new patch
[11:59] <soren> That seems to have done the trick.
[11:59] <cjwatson> soren: I guess so (or to ignore SIGPIPE, of course).  The pipe uses are all internal to plymouth though, so I don't think we need to worry about that
[12:00] <soren> cjwatson: Sure, I was just thinkin more gnerally.
[12:06] <persia> geser, DMB meeting?
[12:21] <PetrHH> Hello
[12:22] <PetrHH> I'm working on packaging my app to deb packages
[12:22] <PetrHH> but have no idea how to create menu entry after install
[12:23] <PetrHH> could anybody send me link to the how to? I'm not so successful with google
[12:23] <PetrHH> thank you
[12:23] <soren> PetrHH: Look at the .desktop files in /usr/share/applications
[12:25] <PetrHH> soren, Thank you!
[12:40] <soren> apw: Plymouth fix uploaded. Thanks for pointing it out. I've been watching the new bugs for plymouth, but it looks this this was filed as "confirmed" from the start.
[12:44] <soren> cjwatson: Thanks for your help on that, by the way.
[12:45] <cjwatson> np
[12:52] <PetrHH> soren, Where should I put application icon, please? I've found a lot of directories where e.g. f-spot.png icon is.
[12:52] <soren> I'm not entirely sure where it truly belongs.
[12:53]  * soren isn't a desktop person, really.
[13:23] <pitti> PetrHH: apps usually ship their "canonical" icons in /usr/share/icons/hicolor/
[13:25] <hallyn> slangasek: kirkland: so, where did we decide qemu-kvm-ppc64 belongs?  qemu-kvm, or qemu-user?
[13:26]  * hallyn objects to 'apt-get instlal tree' apparently having done an implicit 'apt-get dist-upgrade'
[13:27] <cjwatson> apt-get install never does an implicit dist-upgrade, but it may be necessary to upgrade other packages to fulfil dependencies.
[13:27] <cjwatson> I don't see why it would have done so for tree though.
[13:28] <hallyn> cjwatson: it even updated my firefox

[13:31] <hallyn> i dunno, this thing's package mgr must still be ina funky state.  it also refuses to install 2.6.38.  i may just need to reinstall
[13:33] <cjwatson> hallyn: it might have attempted to continue a previously incomplete upgrade
[13:33] <cjwatson> 'apt-get -f install' might be a good idea
[13:35] <hallyn> cjwatson: no, that didn't (and doesn't) seem to say anything other than about autoremove packages
[13:36] <hallyn> guess I'll try another rm -rf /var/cache/apt* and retry without apt-cacher again
[13:38] <kirkland> hallyn: qemu-kvm, as i recall
[13:38] <zyga> mvo, ping
[13:39] <zyga> mvo, do you have 3 minutes for a short brainstorm about dpkg?
[13:39] <hallyn> kirkland: that's what I had thought.
[13:40] <hallyn> kirkland: so should we reclasssify bug 717690 as against qemu-user ?
[13:45] <hallyn> kirkland: hm, so all of the arm-* patches should be removed from qemu-user, right?
[13:45] <hallyn> \o/
[13:47] <pitti> debfx: note that we already have python-gudev in the archive, which just like pyudev is obsolete
[13:47] <zul> @pilot in
[13:48] <kirkland> hallyn: should be fix released now
[13:48] <pitti> debfx: ah, sorry, it's libudev bindings, not libgudev; for the latter we have a GIR now
[13:48] <kirkland> hallyn: my last upload fixes that
[13:48] <pitti> debfx: ok, so ignore me :)
[13:48] <kirkland> hallyn: yes, all of the arm patches can go
[13:48] <hallyn> kirkland: you re-uploaded qemu-user?
[13:48] <kirkland> hallyn: no
[13:48] <kirkland> hallyn: qemu-kvm
[13:49] <kirkland> hallyn: we dropped that manpage from qemu-kvm (slangasek's patch)
[13:49] <hallyn> so you removed qemu-ppc64 from qemu-kvm?
[13:49] <hallyn> oh, it's the manpage!
[13:49] <hallyn> doh
[13:50] <hallyn> kirkland: at this particular moment, I'm down to two patches in qemu-kvm-0.14.0~rc1+noroms :)
[13:50] <kirkland> hallyn: rock
[13:50] <soren> No doko?
[13:50] <hallyn> kirkland: shoudl '~rc1' be in the name like that, btw?
[13:53] <soren> Maybe someone else can help me out.
[13:54] <ScottK> I thought he'd be back today (doko)
[13:56] <soren> ScottK: You might be able to help me with this, actually.
[13:56] <soren> Once upon a time, python-eventlet was built: https://edge.launchpad.net/ubuntu/+source/python-eventlet/0.9.13-0ubuntu1/+buildjob/2031930
[13:57] <ScottK> OK
[13:57] <soren> The build log from amd64 shows that the .deb ended up containing a bunch of things in /usr/lib/python2.7/dist-packages/eventlet/
[13:57] <soren> in addition to the expected stuff in  /usr/share/pyshared/eventlet/
[13:58] <soren> I just built a newer version earlier today that didn't end up with stuff in /usr/lib/python2.7/dist-packages/eventlet/
[13:58] <soren> ..this makes upgrades suck because there are leftover .pyc files in /usr/lib/python2.7/dist-packages/eventlet/.
[13:58] <ScottK> Where's the newer version?
[13:59] <soren> https://edge.launchpad.net/ubuntu/+source/python-eventlet/0.9.14-0ubuntu1/+buildjob/2261008
[13:59] <soren> I tried rebuilding the old source package, and this time I didn't get anything in in /usr/lib/python2.7/dist-packages/eventlet/ so it looks like there was a toolchain problem at some point.
[13:59] <soren> ...and I can't imagine I'm the only one having to deal with this fallout on upgrades.
[14:00] <seb128> soren, seems similar to the pywebkitgtk recent issues
[14:01] <seb128> soren, see the current upload of that one, the changelog has some details
[14:02] <soren> seb128: The one from about two weeks ago?
[14:02] <soren> Yeah, changelog entry sounds similar. Thanks.
[14:02] <seb128> soren, yes
[14:02] <seb128> soren, I think that was due to package rebuilt in natty when part of the python... didn't support 2.7 yet
[14:03] <ScottK> soren: I agree it was a problem with the 0.9.13 upload's toolchain.
[14:03] <seb128> soren, was the "buggy" version uploaded around the time python2.7 landed?
[14:03] <ScottK> Looks like it was.
[14:04] <seb128> soren, it's likely to be a similar issue, rebuilt at a time python2.7 was pulled it but part of the buildchain was not ready
[14:04] <soren> 2010-10-31 17:05:06 CET
[14:04] <ScottK> There was also a period where 2.7 was a supported version, but not all the helper tools had been updated to know about it yet.
[14:04] <soren> ScottK: Now that sounds like trouble.
[14:04] <soren> Uh, wrong timestamp.
[14:05] <seb128> soren, well, just add some code to clean it up on upgrade
[14:05] <soren> Yeah.
[14:05] <seb128> we should likely check what packages got rebuilt around this time
[14:05] <seb128> it's 2 of those which are spotted as broken now
[14:05] <seb128> we might have some other ones
[14:14] <ScottK> soren: I think seb128's suggestion is the right way.
[14:16] <ScottK> soren: Alternatively, I think switching to dh_python2 would also fix this as, IIRC, that's where it puts it's .pyc files.
[14:25] <soren> ScottK: I'll deal with dh_python2 some other day. :)
[14:25] <soren> ScottK, seb128: Thanks, guys!
[14:25] <ScottK> OK.
[14:26] <ScottK> barry: ^^^ It would probably be a good idea for someone to do a methodical search for other misbuilt packages.
[14:44] <mvo> ScottK: misbuild in what way? I may be able to help here (got a VM image with maverick->natty upgraded *python*)
[14:45] <ScottK> mvo: As soren and seb128 were discussing it looks like late Octoberish pysupport was installing files for python2.7 in the wrong place.
[14:47]  * mvo reads scrollback
[14:52]  * barry reads scrollback too
[15:17] <jelmer> zul: Thanks once again for sponsoring :)
[15:17] <zul> jelmer: no worries
[15:20] <kirkland> pitti: hey, are you still around?
[15:20] <pitti> hi kirkland
[15:21] <kirkland> pitti: i'm hoping there's an obvious fix for this ...
[15:21] <kirkland> pitti: been broken for me for 1 month now;  been hoping a magic update would just fix it
[15:21] <kirkland> pitti: i can't alt-tab to switch windows, resize windows, move windows, etc.
[15:21] <kirkland> pitti: this is natty gnome
[15:22] <kirkland> pitti: perhaps i'm missing a package?  or some configuration from day1 natty is not compatible with today?
[15:22] <pitti> kirkland: hm, that doesn't happen for me; seb128, didrocks, did you ever hear about alt+tab/resizing/moving windows being broken in natty?
[15:23] <pitti> kirkland: does it happen for a new user, too?
[15:23] <pitti> kirkland: that's usually the first litmus test whether it's package or config related
[15:23] <seb128> didn't read anything about that
[15:23] <pitti> I didn't see that either
[15:23] <seb128> kirkland, is that under unity or classic GNOME?
[15:23] <seb128> try to unity --reset maybe
[15:23] <pitti> kirkland: ok, so try with new user first, then let's bisect it todwn
[15:23] <pitti> down
[15:24] <pitti> seb128: "classic gnome"
[15:24] <highvoltage> pitti: that sounds like the start of a nercore rap :)
[15:24] <highvoltage> *nerdcore
[15:24] <didrocks> pitti: not really about that, alt + tab can be very slow
[15:25] <geser> kirkland: I got once a problem with alt-tab in unity too, I had to re-add the key shortcut as it was gone
[15:25] <kirkland> pitti: okay, i'll create a new user
[15:25] <kirkland> seb128: classic gnome
[15:25] <didrocks> kirkland: normally, I tried to migrate uncompatible settings, but yeah, --reset is always better :)
[15:25] <seb128> kirkland, try a guest session to start I guess
[15:25] <seb128> didrocks, is there a compiz --reset?
[15:26] <pitti> guest session would start unity, though
[15:26] <didrocks> seb128: not for that, unfortunately…
[15:26] <didrocks> guest session should start the session your are in
[15:26] <didrocks> you*
[15:26] <seb128> pitti, what didrocks said
[15:26] <pitti> didrocks: oh? clever
[15:26] <didrocks> so, classic if you are in gnome-classic, unity if you are in ubuntu desktop… and so on :)
[15:27] <kirkland> weird, unity was not installed
[15:27] <kirkland> i did not uninstall it
[15:27] <didrocks> pitti: I fixed it for alpha1, but didn't retest for alpha2
[15:28] <didrocks> so, in any case, it's in my checking TODO as it's often broken by inadvertance
[15:28] <seb128> didrocks, what?
[15:28] <didrocks> seb128: the "start the corresponding guest session"
[15:28] <seb128> didrocks, that works, at least it starts the classic session for me
[15:29] <didrocks> seb128: ok nice, not broken again yet :)
[15:29] <kirkland> didrocks: seb128: pitti: okay, i installed unity, and then ran unity --reset and I can now move windows and resize them again!
[15:29] <kirkland> i still can't alt-tab, though
[15:29] <pitti> kirkland: that's progress!
[15:29] <pitti> curious, though, as unity shouldn't be involved in classic gnome
[15:30] <didrocks> kirkland: try to hang the alt + tab for few seconds
[15:30] <pitti> ok, need to finish early today, sorry
[15:30] <pitti> kirkland: I'll read backscroll
[15:30] <seb128> pitti, well, unity --reset starts compiz with a fresh profile
[15:30] <pitti> ah
[15:30] <pitti> so, compiz bug
[15:30] <didrocks> kirkland: there is a performance issue with it, so maybe
[15:30] <hallyn> jinkeys - requestsync failed with 'too many concurrent connections' to mx.launchpad.net:25
[15:30] <kirkland> didrocks: nope ... if I'm in the terminal, I get "^[      " in my window
[15:30] <seb128> pitti, "bug" or "config issue"
[15:30] <didrocks> kirkland: staticswitcher in enabled in ccsm?
[15:31] <didrocks> (it should as you just reset the value)
[15:31] <kirkland> didrocks: what is ccsm?
[15:31] <hallyn> kirkland: did you allow the latin keyboard thingie to misconfigure with alt perhaps?
[15:31] <kirkland> hallyn: oh
[15:31] <didrocks> kirkland: compizconfig-setting-manager, a way to change everything in compiz and break it :)
[15:31] <kirkland> hallyn: maybe so
[15:31] <kirkland> didrocks: not installed, installing now
[15:31] <didrocks> kirkland: compizconfig-settings-manager and then, just launch "ccsm"
[15:32] <didrocks> kirkland: you should ensure that the staticswitcher plugin is activated
[15:32] <kirkland> didrocks: was not emabled
[15:32] <didrocks> hum…
[15:32] <didrocks>  /!\ activating/deactivating plugin make compiz crash now
[15:33] <kirkland> didrocks: got it, that works now
[15:33] <kirkland> didrocks: seb128: pitti: thanks so much!
[15:34] <didrocks> kirkland: that's really weird, unity.ini, debian/rules for autogeneration list, and the compiz gconf default are setting it…
[15:34] <didrocks> kirkland: but well, nice that fixed it for you, I'll try again with a new user :)
[15:34] <kirkland> didrocks: seb128: pitti: because of this, i have spent most of the last 4 weeks in tty1, with byobu+w3m+ irssi+mutt :-)
[15:34] <kirkland> (which is actually pretty nice :-)
[15:34] <seb128> kirkland, don't hesitate to ask early when you have a such issue
[15:35] <didrocks> kirkland: well, that's just a way for you to enjoy byobu a little more :)
[15:35] <kirkland> seb128: thanks, will do
[15:36] <tumbleweed> bdrung: ^5 (on ubuntu-sponsoring)
[15:39] <dholbach> bdrung, tumbleweed: are you both looking into the unicode problem right now?
[15:39] <dholbach> I just wanted to take the dog for a walk real quick - I can review whatever you have when I'm back
[15:40] <dholbach> it'd be nice to get the issue resolved :)
[15:40] <tumbleweed> dholbach: at least I am :)
[15:40] <dholbach> thanks muchly
[15:40] <dholbach> I'll let you know when I'm back
[15:46] <bdrung> dholbach: i am cooking
[15:47] <mvo> hey zyga - you pinged me earlier?
[15:47] <zyga> mvo, yes
[15:48] <zyga> mvo, I had this crazy idea of being able to install packages without invoking any scripts, then gathering the required scripts and executing them in sequence during first boot, I was wondering what kind of caveats would you think of in such design
[15:48] <mvo> barry: mind if I upload some rebuilds for python2.7 ? looks like python-oss is a candidate for this, probably more
[15:51] <mvo> zyga: you need to consider that pre-depends requires a package to be installed and configured, so you can only delay those with "regular" dependencies. then you need to run the configure scripts on bootup in the right order (well, dpkg --configure -a should actually handle this for you). and there is the issue that your daemon will not get restarted, so e.g. on security updates of libfoo the old copy keeps running
[16:00] <zyga> mvo, re, sorry about being missing
[16:00] <zyga> mvo, this about building system images "dry", without running the target system (pc->arm)
[16:01] <zyga> mvo, so issues such as running system are not important here
[16:01] <zyga> mvo, in fact we have a slightly easier work to perform, currently linaro has a tarball with the root fs created using lexbuilder/offspring with the regular method (which AFAIR depends on qemu faiking the target system)
[16:02] <zyga> mvo, then when you want to create a bootable media for your device you need to combine this filesystem with a "hardware pack" which is a tarball with extra packages and repository for anything that they might depend on
[16:02] <zyga> mvo, currently the procedure is somewhat complex because we need to install those hardware pack packages in the image we're building, I wanted to simplify that
[16:03] <zyga> mvo,  up to a point that the whole procedure would not depend on anything apart from simple file manipulation tools
[16:17] <ev> GunnarHj: merged both branches and uploaded; great work on these!
[16:30] <ev> @pilot out
[16:31] <seb128> hum
[16:31] <seb128> is launchpad or launchpadlib known to be broken?
[16:31] <seb128> the retracers crash on "NotImplementedError: Can't look up definition in another url (https://api.launchpad.net/1.0/#distributions)"
[16:32] <jpds> seb128: leonardr is talking about this in #launchpad with apw.
[16:33] <james_w> seb128, login_*(name, service_root=EDGE_SERVICE_ROOT) needs to change EDGE_SERVICE_ROOT to "production"
[16:35] <pitti> james_w: thanks
[16:35] <apw> james_w, so login_*(name, service_root="production") ??
[16:35] <james_w> apw, yeah
[16:35] <james_w> if you are on a really old version of launchpadlib that will crash, let me know if so
[16:36] <seb128> james_w, how come they didn't keep it working for compatibility purpose?
[16:36] <seb128> it's breaking retracers and sponsoring queue and versions and...
[16:36] <seb128> like is there any need to force us to do review and fix everything now by breaking it?
[16:37] <james_w> seb128, they wanted to reassign the edge machines to the production, and a redirect broke some other things
[16:38] <james_w> seb128, I disagree with the way they have gone about it
[16:38] <seb128> james_w, ok, thanks
[16:40] <bobg> i am writing a package for my company that supplies the debconf values for ldap-auth-config (so that we can install this package to config a machine to use the company ldap for authentication) what's the best channel to get help for that?
[16:42] <cjwatson> in fairness the edge decommissioning was announced several months ago
[16:44] <pitti> seb128: apport trunk already uses production, so the natty chroot should be okay, and the crash-digger merely needs a bzr pull
[16:44] <pitti> seb128: the only problem is the maverick chroot, we'd need either an SRU or a backport of apport in my PPA; I'll handle that one tomorrow
[16:45] <bdrung> dholbach, tumbleweed: merged
[16:45] <pitti> seb128: ok, branches updated and locks removed; let's see how it goes
[16:45] <seb128> pitti, thanks
[16:46] <pitti> seb128: ah, need to refresh the LP cookie, doing..
[16:51] <pitti> seb128: did it crash right away? it's currently consolidating the dup db, but that already means lots of LP access
[16:51] <seb128> pitti, yes
[16:52] <pitti> ok, cool
[16:52] <seb128> pitti, thanks for the quick fixing
[16:53] <achiang> pitti: do you understand the relationship between udev and usb_modeswitch? i'm playing around with a new modem, which i'm pretty sure needs to be mode-switched. it was not originally listed in /lib/udev/rules.d/40-..., so i stuck an entry in there. yet, when i plug it in, i don't really see udev calling the proper script
[16:53] <achiang> udevadm monitor isn't really showing me anything interesting (or i don't know what i should be looking for)
[16:54] <pitti> achiang: I'm just logging out, can you please mail me?
[16:54] <achiang> pitti: ok, sure
[16:54] <pitti> cheers
[16:54] <achiang> thanks
[16:55] <slangasek> hallyn: I thought the conclusion was that qemu*ppc64 rather belonged in /qemu-linaro/; is that not the plan?
[16:57] <hallyn> kirkland: ^
[16:58] <hallyn> slangasek: that hadn't been what i remembered, and i *think* not what kirkland took away from it either, but waiting for him to confirm
[16:58] <kirkland> slangasek: i thought we were putting any and all kvm-accelerated stuff in qemu-kvm
[16:58] <kirkland> slangasek: where ppc64 is (or will very soon be) kvm-accelerated
[17:03] <dholbach> bdrung, pulled
[17:05] <slangasek> kirkland: well, we said that, yes... we also earlier discussed that powerpc support would be going directly against qemu upstream so it might be just as good to package it via qemu-linaro
[17:05] <slangasek> kirkland: I guess I don't mind either way, but at this point you're missing a Replaces :)
[17:09] <kees> seb128: re 717358: what does that have to do with this goofy menu bar?
[17:10] <seb128> bug #717358
[17:10] <seb128> kees, I guess I didn't understand the issue, it seemed like you have the default config with a gnome-panel at the top of the screen and indicator-appmenu
[17:11] <kees> nope. I have no panel on the top.
[17:11] <kees> you can see in the screenshot that it's a menu bar
[17:11] <seb128> kees, well that could have been the indicator-appmenu applet on a panel weirdly themed as well
[17:11] <kees> and if I select "Help / About" it says nautilus
[17:11] <kirkland> slangasek: hrm, okay;  please commit the Replaces that we need against lp:ubuntu/qemu-kvm
[17:12] <seb128> right, the default appmenu if you have nothing focussed is the nautilus one
[17:12] <kees> I'm using classic desktop.
[17:12] <seb128> kees, do you have a dual screen config?
[17:12] <kees> nope
[17:12] <kirkland> slangasek: the ppc64 patches will be against HEAD, but we're shipping qemu-kvm-0.14 in 11.04, so we're not far off
[17:12] <seb128> kees, well, indicator-appmenu is in the default classic desktop applet list in natty
[17:13] <kees> none of my other menu bar end up there (thank goodness).
[17:13] <kirkland> slangasek: also, it's the server team doing the work and testing against ppc64/kvm, so i think it'll be better for us to work against qemu-kvm (ours) rather than stepping on qemu-linaro (yours)
[17:13] <seb128> kees, ok, dunno then, I just tried in a guest session and move the default gnome-panel which is at the top and I don't get that
[17:14] <seb128> kees, I've switched back the bug to New I will let someone else confirm
[17:14] <kees> seb128: mdeslaur already confirmed it
[17:14] <seb128> kees, nautilus didn't get an upload for a month so it's not likely due to it
[17:14] <slangasek> kirkland: well, I would like less of an ours vs yours here; qemu-linaro is just like any other Ubuntu package and if changes are needed any Ubuntu developer can make them as normal
[17:14]  * kees looks around for tedg
[17:14] <kirkland> slangasek: heh, fair enough
[17:14] <slangasek> kirkland: so from that POV I don't really think that having it in qemu-linaro instead of qemu-kvm should handicap you
[17:15] <seb128> kees, try mterry or kenvandine otherwise ;-)
[17:15] <kirkland> slangasek: okay, but you did tell me qemu-linaro will be 0.13.5, right?
[17:15] <kees> seb128: okay, thanks!
[17:15] <seb128> kees, you're welcome
[17:15] <kees> mterry, kenvandine: hi! :) can you look at 717358? does that relate to work you've done recently?
[17:15] <slangasek> kirkland: qemu-linaro is *currently* at 0.13.50, which is "straight from HEAD plus linaro cleanups"
[17:15] <kirkland> slangasek: we'll be uploading 0.14~rc1 today, so that puts us closer to HEAD (which I think is the main point)
[17:16] <slangasek> from my side I haven't heard that an rc was impending, but the line of communication is a bit long
[17:16] <slangasek> AIUI we're no more than 2 weeks out of date wrt upstream
[17:16] <slangasek> and will be syncing with them again between now and release
[17:17] <mterry> kees, wait, so nautilus is drawing its menu in gnome-panel even without the appmenu being active?
[17:17] <kees> mterry: no, no gnome panel at all up there.
[17:17] <slangasek> kirkland: the other question I have is, is whether it makes sense to install qemu-system-ppc64 for everyone on x86 who installs qemu-kvm
[17:17] <kirkland> slangasek: interesting choice of version, then :-)
[17:17] <kees> mterry: I have only a panel at the bottom of my screen, and I'm running classic desktop so none of the menu-bar stealing should be happening.
[17:17] <slangasek> kirkland: the 0.13.50? It's what was in the upstream git at the time as the label
[17:17] <mterry> kees, oh, weird.  No, not related to my work
[17:18] <kees> mterry: okay
[17:19] <kirkland> slangasek: fair enough;  qemu is weird then :-)
[17:19] <seb128> kees, mterry: ok, I can confirm that, if you don't have an appmenu container set it does that
[17:19] <seb128> kees, mterry: like in a guest session if you remove indicator-appmenu from gnome-panel
[17:19] <mterry> MUST SHOW APPMENU!!! GRR
[17:19] <seb128> ;-)
[17:19] <mterry> seb128, I can look at it
[17:19] <seb128> mterry, if you want to that would be welcome
[17:19] <seb128> otherwise we can ask ted when he's back
[17:20] <kirkland> slangasek: and yes, i think that to be consistent with myself (oh so important, btw!), qemu-kvm should install qemu-system-[i386,x86_64,ppc64]
[17:20] <kirkland> slangasek: and qemu-kvm is the home for "architectures that support kvm-acceleration"
[17:21] <kirkland> slangasek: at least for now
[17:21] <kirkland> slangasek: and then we have another interesting discussion when cortex15 adds VT support for ARM
[17:21] <kirkland> slangasek: hopefully by then, qemu-linaro has merged into qemu
[17:21] <slangasek> kirkland: <smirk>
[17:21] <kirkland> slangasek: but i won't hold my breath on that one
[17:21] <kirkland> slangasek: too many moving parts outside of our control (ARM, QEMU, etc)
[17:22] <ogra> and you cant be sure the VT variant is actually kvm
[17:22] <seb128> re
[17:22] <slangasek> kirkland: qemu-linaro is already the source for upstream qemu in Ubuntu packages, for all intents and purposes - merging isn't the issue
[17:22] <ogra> compatible
[17:22] <seb128> mterry, I was saying that if you want to look to it that would be welcome or we can ask ted
[17:22] <kirkland> slangasek: okay
[17:22] <seb128> laptop crashed on vt switch then
[17:22] <seb128> mterry, that's not an appmenu though but the nautilus menu
[17:23] <mterry> seb128, oh, it's only nautilus?  ah, thought it was everything
[17:23] <seb128> like it doesn't track other menus or anything and go away when you nautilus --quit
[17:23] <seb128> could be the compiz update for the invisible dialogs issue
[17:23] <mterry> seb128, ok, I'll delay looking at that then.  I've got other indicator stuff I can do
[17:25] <seb128> mterry, ok
[17:25] <seb128> it happens in unity as well in fact
[17:25] <seb128> I can see a one pixel grey line below the unity-panel there
[17:25] <seb128> if I switch workspaces I can see the menubar from nautilus during the transition
[17:35] <GunnarHj> ev: Thank you, Evan!
[17:56] <seb128> kees, mdeslaur: do you know when the menu issue started?
[17:58] <mdeslaur> seb128: Unfortunately, not really, since it's being drawn _underneath_ my gnome-panel
[17:59] <geser> seb128: a few days ago, I can check my IRC log when I asked about it #ubuntu-desktop
[17:59] <seb128> geser, you asked on friday morning european time
[17:59] <seb128> geser, I checked
[17:59] <seb128> ok
[17:59] <seb128> let's say it's one of the update on thursday
[18:04] <hyperair> was there a tool that allows you to check the signatures of source packages?
[18:07] <Laney> dscverify
[18:08] <hyperair> aha!
[18:08] <hyperair> thanks
[18:10] <hyperair> i'm uploading gdata-sharp to ubuntu now
[18:10] <Laney> ♥
[18:10] <Laney> sync?
[18:11] <hyperair> yes
[18:12] <hyperair> Laney: we'll need to rebuild gnome-do-plugins
[18:12] <Laney> sure
[18:12] <hyperair> in debian as wel
[18:12] <hyperair> +l
[18:13] <hyperair> well gdata# has been uploaded.
[18:13] <hyperair> next will be banshee
[18:13] <hyperair> but that'll have to wait for directhex to upload it to debian first.
[18:13] <Laney> you can probably make it syncable
[18:13] <hyperair> the one with amended debian/control
[18:13] <Laney> if you take that patch into debian
[18:13] <hyperair> nah, banshee isn't syncable.
[18:13] <Laney> i mean plugins
[18:13] <hyperair> ah
[18:14] <hyperair> i don't know, i didn't work on gnome-do-plugins before
[18:14] <Laney> it's your patch :P (which is already upstream)
[18:14] <hyperair> eh?
[18:14] <hyperair> it's my patch?
[18:14] <hyperair> O_o
[18:14] <Laney> check it out
[18:14]  * hyperair checks
[18:15]  * sebner hugs Laney and hyperair =)
[18:15] <hyperair> oh that one
[18:15] <hyperair> that's oooooooooold
[18:15] <hyperair> and that patch should go into debian, yes
[18:15] <Laney> there you go, an excuse for an upload/sync
[18:15] <Laney> \o/
[18:15] <hyperair> heheh
[18:16] <hyperair> hmm
[18:16] <hyperair> it's still svn? =O
[18:16] <Laney> RAOF was talking about migrating it the other day
[18:16]  * Laney knows not what the plans are
[18:17] <hyperair> i see.
[18:18] <hyperair> it seems that hibernate in gnome-do is broken though.
[18:18] <hyperair> on maverick
[18:18] <hyperair> i haven't had time to poke it to see
[18:19] <hyperair> or maybe it's my weird setup
[18:20]  * sebner goes crying into the corner as he feels slightly ignored
[18:20]  * Laney fluffs sebner
[18:21] <sebner> :D
[18:21]  * iulian hugs sebner.
[18:21] <sebner> \\o/
[18:21]  * Laney fades away
[18:21] <Laney> ttyl
[18:33] <bobg> is it possible to use debconf-set-selections inside a package preinst (or other) script so that it effects another package?
[18:52] <cody-somerville> pitti, Is apport sending a 'Crash report detected' to the notification daemon over and over repeatedly a known issue in Maverick? :P
[19:08] <cody-somerville> wow... I just noticed that apport will open up the web browser running as root. That can't be intentional.
[19:10] <satya> hello
[19:15] <kklimonda> jdstrand: hey, do you have a moment?
[19:16] <kklimonda> actually, anyone from the security team would help :)
[19:19] <jdstrand> kklimonda: whatcha need?
[19:20] <jdstrand> kklimonda: and hi! :)
[19:20] <kklimonda> jdstrand: hey. I have a small problem.
[19:21]  * jdstrand thinks he may know what it is...
[19:21] <kklimonda> jdstrand: Transmission requires a newer version of libevent then the rest of the archive, and we can't do the transition as we get some ftbfs - some of them in tests which indicates that something subtle has changed, and other packages may be affected.
[19:21] <jdstrand> that was not it :)
[19:22] <kklimonda> jdstrand: it leaves me with two choices - keep transmission at 2.13 for natty
[19:22] <kklimonda> which will make it harder on both us and upstream to maintain it.
[19:23] <kklimonda> jdstrand: or rebundle libevent2 in transmission source - it was bundled for a long time, I think we started using a system version only a year ago or so.
[19:23]  * jdstrand cringes a little
[19:23] <jdstrand> let me look at the source
[19:25] <kklimonda> sure - do you want a link to libevent 2.0.10?
[19:25] <jdstrand> looks like 1.73-3 use the system libevent
[19:25] <jdstrand> kklimonda: not really
[19:25] <kklimonda> so it was even earlier? How long have I been around..
[19:26] <jdstrand> so, lucid is supported until 2012-04 and natty is supported until 2012-10
[19:26] <jdstrand> yeah, that was pre-karmic
[19:26] <jdstrand> I'm sorry
[19:26] <jdstrand> lucid is supported until 2013-04
[19:26] <jdstrand> that makes it easier
[19:27] <jdstrand> natty will fall off before lucid is eol
[19:27] <kklimonda> right, how does it help
[19:27] <kklimonda> ?
[19:27] <jdstrand> so I'm not sure the maintenance burden is greatly reduced by having the absolute latest trnasmission
[19:28] <chrisccoulson> we want the latest crack though ;)
[19:28] <jdstrand> kklimonda: so, I'm inclined to say that the recommendation from a security team POV is to keep transmission where it is for now, until the libevent issues are worked out and it can use the system one
[19:29] <jdstrand> chrisccoulson: :P
[19:29] <jdstrand> there might be other factors, but embedded a library is really pretty bad, even more so when we diverge from Debian
[19:29] <jdstrand> s/embedded/embedding/
[19:30] <kklimonda> jdstrand: where can I check the history of security issues in libevent?
[19:30] <jdstrand> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libevent
[19:33] <kklimonda> hmm.. so it's a choice between the latest crack, and ease of maintainance.. bummer, both choices suck ;)
[19:33] <jdstrand> well, what sucks is the timing of the library transition
[19:34] <SpamapS> Is hardy still getting actively updated with non-security SRU's or is it security only?
[19:34] <jdstrand> SpamapS: it will ge tthe occasional SRU
[19:42] <SpamapS> jdstrand: whiel I have your attention, I think that bug #251139 is making an unacceptable SRU request to have apr backport a change to use /dev/urandom instead of /dev/random. Would you concurr?
[19:42] <kklimonda> ok, we are staying with 2.13 in this case, I'm not willing to add burden on others so we can get latest features. thanks jdstrand :)
[19:43] <jdstrand> kklimonda: sure, np. a wise choice if I may say :)
[19:46] <jdstrand> SpamapS: on the face of it, I don't see it as particularly high-risk, but hardy is pretty stable these days. I think you might have a hard time convincing them it is needed. it is a 2.5 year old bug with no one saying it affects them too or duplicates
[19:46] <jdstrand> and by them, I mean ubuntu-sru
[19:46] <SpamapS> Yeah exactly
[19:47] <SpamapS> Entirely possible too that somebody has built a system out there expecting super-high-quality-randomness in apr.
[19:47] <jdstrand> "Won't Fix" is a viable choice. who knows, the user may come back with an important use case to reconsider
[19:47] <SpamapS> Thats what I was going to mark it.
[19:47] <SpamapS> Thanks for taking a look. :)
[19:47] <jdstrand> sure! :)
[19:48]  * SpamapS just loves triaging bugs that are older than his children.
[19:52] <kklimonda> oh, I just made my life harder then it should be - I'm subscribed to ubuntu MLs from my @ubuntu address, but bug mails are sent to my main address. Because of that people CC the email which is not subscribed, and my response ends up in the moderation..
[19:54] <micahg> kklimonda: virtual identity or correct identity for Thunderbird can help with that
[19:54] <kklimonda> thunderbird you say? :)
[19:54] <kklimonda> I guess it's time to give it another shot
[19:56] <SpamapS> Evolution seems to get the reply address mostly right, most of the time.
[22:11] <ScottK> Wow.  A nice comment about Evolution and multiple hours of stunned silence ensue.
[22:11] <maco> haha, especially after that pc world article
[22:14] <charlie-tca> amazing what a single good thing will do, huh?
[22:34] <kees> doko: what're your thoughts on 712662
[22:35] <doko> bug #712662
[22:38] <doko> kees: would it be ok, if such packages use /bin/sh in there scripts only? and if a user is created for these packages, to set the login shell to /bin/sh ?
[22:39] <kees> doko: hrm? the point is to keep any shell from having built-in network redirection
[22:40] <doko> kees: shell or interpreter?
[22:40] <kees> shell.
[22:40] <kees> scripting languages all have networking, even awk
[22:40] <doko> people did file bug reports to enable it
[22:40] <kees> but shells doing networking is odd
[22:40] <kees> yeah.
[22:40] <kees> but it's been off for so long; it's a security feature :)
[22:41] <doko> I did enable it once dash was the default shell
[22:41] <kees> true
[22:41] <kees> jdstrand: what do you think of making the distinction between dash and bash for this? I think it wouldn't work well.
[22:41] <kees> doko: the problem is that most apps (say, firefox) when running subshells are using the users's defined login shell to do the work.
[22:42] <kees> so it's not so simple to separate dash and bash in this case
[22:43] <doko> kees: what would break if we disable the redirects?
[22:43] <jdstrand> kees: I'm not sure I understand the question. your last comment is the problem. eg, things that use /bin/sh get dash in Ubuntu and profiling is no problem. it is things that specifically use bash
[22:43] <kees> doko: nothing I know depends on it
[22:44] <doko> jdstrand: bash is still essential, so it's difficult to determine what depends on bash
[22:45] <jdstrand> forgive me, I have no idea what I am being asked
[22:45] <doko> ask kees ;P
[22:45] <kees> jdstrand: heh, sorry.
[22:45] <jdstrand> I'm coming at it from an apparmor profiling angle
[22:46] <jdstrand> it is very easy to see when profiling an application which is used
[22:46] <kees> jdstrand: right, so how to the abstractions currently deal with dash vs bash?
[22:47] <jdstrand> there is no dash abstraction
[22:47] <jdstrand> things that use dash will use the bash abstraction
[22:47] <jdstrand> and ixr
[22:47] <kees> I'm just trying to use AppArmor as supporting evidence. I don't like shell redirection because it makes remote attacks much easier
[22:47] <jdstrand> the bash abstraction isn't a problem
[22:48] <jdstrand> it is when you pull in networking, and have bash ixr
[22:48] <jdstrand> eg,
[22:48] <jdstrand> #include <abstractions/namneservice>
[22:48] <jdstrand> #include <abstractions/bash>
[22:48] <jdstrand> /bin/bash ixr,
[22:48] <SpamapS> slangasek: around? I think we may need to make a change to upstart-job's handling of the 'restart' command after discussing something w/ Keybuk last week.
[22:49] <jdstrand> ^ with that, networking is implicitly allowed via the nameservice abstraction, and bash has network redireection, so you have a reverse shell
[22:49] <jdstrand> where one would not think one would
[22:49] <doko> kees, jdstrand: offline now, let's continue later this week, but not tomorrow. need to catch up on more things
[22:49] <jdstrand> if networking is not allowing in the profile, then no problem
[22:49] <kees> doko: okay
[22:50] <jdstrand> if dash is used and not bash, then no problem
[22:50] <kees> jdstrand: right
[22:50] <jdstrand> it is the combination of bash, networking in the profile and network redirection
[22:50] <jdstrand> then you have to go through ridiculous hoops to confine bash
[22:50] <jdstrand> (see the bug)
[22:51] <jdstrand> kees: cups suffers from this, as a specific example
[22:51] <jdstrand> ./usr.sbin.cupsd:  #include <abstractions/bash>
[22:51] <jdstrand> ./usr.sbin.cupsd:  /bin/bash ixr,
[23:05] <bdrung> zul: are you still progressing bug #719056?
[23:12] <zul> bdrung: hmm?
[23:13] <bdrung> zul: you gave your ACK, but ubuntu-sponsors is still subscribed, the status is still new, and ubuntu-archive isn't subscribed
[23:13] <zul> yeah i just stepped away for a momment
[23:14] <zul> @pilot out
[23:18] <bdrung> zul: status -> confirmed