[02:40] <rawkasaur> Does anyone know where the config for devicekit/synaptics touchpads are stored?
[03:10] <psusi> hrm..... the man page for mke2fs says that -E lazy_itable_init defaults to 1 if not specified, but it doesn't....
[03:11] <psusi> it also doesn't seem to set the lazy_bg flag when enabled, which it should...
[03:39] <skydrome> can you echo $? of the 2nd to last command?
[03:49] <ebroder> Hmm...if I want to get the new release of openafs into Lucid, how hard do I have to work to convince myself that it's just bugfixes?
[03:56] <lifeless> very
[03:56] <ebroder> :(
[03:57] <ebroder> In all honesty, new openafs releases tend to do a *lot* for stability, so it would definitely be nice to have. I guess I'll see if I can pull an FFe together
[03:57] <lifeless> well
[03:57] <lifeless> start with the ffe
[03:58] <lifeless> and make the case in that
[04:16] <jdong> "I *swear* they're just bugfixes"
[04:16] <jdong> someone needs to invent a launchpad tag for that :)
[04:21] <micahg> jdong: it's called regression-update ;)
[04:25] <RAOF> micahg: Any joy on gjs? :(
[04:25] <micahg> RAOF: ugh, that's what I wanted to do this weekend....
[04:26] <micahg> RAOF: I'll take a look tonight
[04:26] <micahg> RAOF: I think I know what it is, the question is how easy will it be to fix
[04:28] <micahg> RAOF: know anything about gnome-chemistry-utils?
[04:28] <RAOF> If you don't have time, feel free to hand that potato on to someone else :)
[04:28] <RAOF> I know nothing about gnome-chemistry-utils.
[04:29] <RAOF> I don't even know what sort of chemical utils gnome *could* provide :)
[04:30] <micahg> RAOF: I'm having trouble with it trying to verify a DTD on sourceforge at build time
[04:30] <lifeless> micahg: you can'ty
[04:30] <lifeless> micahg: no internets when building
[04:30] <micahg> lifeless: I know that :)  Somehow it wasn't doing it before with the same code
[04:30] <micahg> now it wants to
[04:31] <lifeless> ah
[04:32] <RAOF> I've seen that happen to a number of packages, but I can't remember the fix.
[04:33] <lifeless> generally a mismatch
[04:33] <lifeless> there is a local dtd
[04:33] <lifeless> in the dtd path
[04:34] <lifeless> but the package upgrades to a newer dtd
[04:34] <lifeless> which isn't yet available locally for reference
[04:34] <micahg> lifeless: does that mean I have to have the DTDs updated?
[04:35] <lifeless> assuming my memory is right
[04:35] <lifeless> check the diff between the last time the package built and your problem copy
[04:35] <lifeless> if it doesn't change the xml ref anywhere, then check the packages it depends on
[04:36] <micahg> lifeless: would you know offhand which package: http://pastebin.ubuntu.com/405453/
[04:38] <lifeless> if its a docbook DTD docbook-xml looks promising
[04:40] <lifeless> otherwise - no idea
[04:40] <micahg> lifeless: k, I'll take a look, thanks
[04:40] <lifeless> I'm going from 10 year old memories of working with xml stuff in cygwin
[07:03] <pitti> Good morning
[07:03] <RAOF> pitti: Good afternoon :)
[07:11] <micahg> good late night :)
[07:52] <xnox> Good early Morning =)
[08:28] <dholbach> good morning
[08:29] <cjwatson> skydrome: no, the shell only stores one; but you can assign $? to some other variable and check that later
[09:46] <mdz> cjwatson, was it you who confirmed you had seen the thrashing during apparmor upgrades as well?
[09:48] <ion> I have been encountering the problem, too, in case you need information about it.
[09:50] <ion> mdz: Looking at IRC logs, he seems to have encountered bug #458299 indeed.
[09:50] <mdz> ion, thanks!
[09:50] <mdz> I've never seen that error, but if it's using up a lot of kernel memory, it could very well have the same root cause
[09:56] <cjwatson> mdz: yes
[09:57] <t3rm1n4l> hi
[09:57] <t3rm1n4l> how to download from lp using bzr
[09:57] <t3rm1n4l> from this link
[09:57] <t3rm1n4l> https://launchpad.net/~apachelogger/+archive/ubuntuone-kde
[10:00] <t3rm1n4l> is ubuntuone client source code open ?
[10:00] <mdz> t3rm1n4l, I think that corresponds to https://code.edge.launchpad.net/ubuntuone-client-kde but I'm only guessing
[10:01] <t3rm1n4l> no its just a connector
[10:01] <t3rm1n4l> actual dbus service and daemon is some other package
[10:04] <mdz> t3rm1n4l, ask apachelogger, I guess
[10:07] <t3rm1n4l> okay
[10:07] <t3rm1n4l> i got the repo
[10:07] <t3rm1n4l> lp:ubuntuone-client
[10:14] <directhex> i wonder how brave i feel over upgrading this office PC to lucid. everything's always so much more painful on the mac than the other systems when it comes to upgrades.
[10:26] <xnox> directhex, my Macbook refuses to upgrade to Snow Leopard. It tells me "can't install on this volume"
[10:26] <xnox> silly thing =)
[10:26]  * xnox is to lazy to back up Lucid & reinstall just to upgrade to Snow Leopard
[10:28] <directhex> i can't expense an upgrade to macos, and never boot the thing into fringe OSes anyway
[10:36] <xnox> directhex, well thanks to MacOS I was introduced to UNIX for the first time =) and that's why it now runs lucid and I have @ubuntu.com email address ;-) so can't complain it was a saviour for me =)
[10:38] <pitti> james_w, lifeless: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstream doesn't really say how to do a new upstream release; is that the correct command to use: bzr mu --version 1.6.0 -v ../gvfs_1.6.0.orig.tar.gz ? Will that do pristine-tar etc.?
[10:43] <pitti> it seems to work fine, anyway; I'll add that to the wiki page once I get your "that's ok"
[11:07] <pitti> superm1: nautilus-cd-burner has been obsolete for quite some time; would you mind dropping the recommends from dell-recovery?
[11:07] <pitti> superm1: (should be brasero)
[11:07] <pitti> seb128: ^ FYI
[11:09] <seb128> pitti, thanks
[11:23] <directhex> oh, looks like i can't upgrade... hash sum mismatch
[11:24] <directhex> naughty repo.
[12:33] <juliank> mvo: I just attached a merge directive to bug #548623 - feel free to pull it in the ubuntu branch & upload it.
[12:34] <directhex> hm, weird upgrade failure today: keyboard/mouse have stopped responding
[12:38] <davmor2> directhex: you mean you're not using psychic links like the rest of use ;)
[12:38] <directhex> davmor2, wireless mice use psychic power, right?
[12:39] <directhex> sigh, i wish xorg.0.log was timestamped
[12:39] <davmor2> directhex: no that would be psycho power, similar but slightly more dangerous :D
[12:41] <mvo> juliank: thanks
[12:41] <mvo> juliank: much appreciated!
[12:43] <juliank> mvo: Did you base aptdaemon 0.11+bzr342-0ubuntu1 on the 0.2.x branch?
[12:45] <mvo> juliank: yes
[12:45] <mvo> juliank: it should probably be a 0.20.x branch ideally
[12:46] <mvo> juliank: because we use 0.11 currently
[12:51] <lamont> http://paste.ubuntu.com/405960/ <-- against what do I file that bug?
[12:52] <lamont> boring repetition that / has errors
[12:52] <lamont> 'twould be nice to get a shell so I could, you know, do what it tells me to.
[13:00] <lamont> would that be mountall, or something else?
[13:18] <directhex> that was actually less painful an upgrade than i expected. loss of input devices notwithstanding
[13:39] <juliank> mvo: Just ported aptdaemon to the new API.
[13:41] <pitti> lamont: mountall seems not entirely wrong at least
[13:42] <mvo> juliank: cool! trunk/ ? glatzor will love this
[13:42] <juliank> mvo: 0.2.X.
[13:44]  * mvo nods
[13:48] <mvo> juliank: python-apt uploaded
[13:48] <lamont> pitti: ta
[13:48] <juliank> mvo: Great.
[13:59] <directhex> 0% [Working]*** glibc detected *** aptitude: free(): invalid pointer: 0x0000000001fd8dc0 ***
[13:59] <directhex> meep
[14:04] <mvo> directhex: bug #517797 maybe?
[14:04] <mvo> directhex: eh, sorry
[14:04] <mvo> directhex: wrong bug number
[14:04] <directhex> i guessed
[14:04] <directhex> annoyingly, apport won't report it
[14:16] <sladen> zul: those bugs are with vmbuilder in lucid and with the branches on Launchpad
[14:16] <sladen> zul: vmbuilder is completely shagged
[14:16] <zul> sladen: k...ill let soren now
[14:23] <sladen> zul: any idea what timezone soren is on?
[14:23] <zul> sladen: central european
[14:59] <james_w> pitti: yeah, that wiki page is misnamed, I intend to move the existing one to "NewPackage" or something and explain how to merge a new upstream on there. You got it right though.
[14:59] <pitti> james_w: ah, thanks for confirming
[15:01] <Riddell> tedg: ping
[15:01] <tedg> Good morning Riddell
[15:02] <Riddell> tedg: I have a patch from agateau to update the namespace for status notifiers from org.freedesktop to org.kde, I believe this need coordinated with you
[15:02] <tedg> Riddell: Yeah, I think we've already released it on the GNOME side.  So it should be good.
[15:03] <Riddell> groovy, I'll do that with kde 4.4.2 then
[15:03] <tedg> Riddell: Great!  Thanks.
[15:04] <superm1> pitti, i had left it as an alternative so the deb could be installed on old versions of ubuntu and still functional.  will it cause archive problems to leave it in place?
[15:09] <pitti> superm1: oh, I see; no, that's fine
[15:09] <pitti> thanks
[15:10] <caeee> hi, where can I find the patch from ubuntu packages linux-source-2.6.24-26 to linux-source.2.6.24-27
[15:20] <qense> pitti: You're maintaining the work-item overviews, right?
[15:20] <pitti> qense: yes
[15:20] <qense> pitti: I think I have found a bug in the QA one.
[15:21] <qense> pitti: http://people.canonical.com/~pitti/workitems/canonical-qa.html says that jeremyfoshee has two open tasks and no closed, but on https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling you can see he has DONE three.
[15:23] <pitti> qense: "canonical-qa" reports are obsolete
[15:23] <pitti> we use canonical-platform-qa now
[15:23] <qense> pitti: ah, that explains
[15:23] <pitti> http://people.canonical.com/~pitti/workitems/canonical-platform-qa.html
[15:23] <qense> pitti: thanks
[15:23] <pitti> but I was asked to keep the canonical-qa ones around for a while
[15:24] <qense> ok
[15:44] <nigelb> so is there something that keeps ALL developers busy after release and before UDS?  I'm planning for a patch review day then
[15:44] <nigelb> expected date is May 5th, but if its bound to be a busy day, I'll have to make adjustments, so can people let me know your comments?
[15:45] <LaserJock> I thought that was "party 'til you're so drunk you rm -rf / yourself" time :-)
[15:45] <micahg> nigelb: core devs are usually trying to get the toolchain for next release in I think...
[15:46] <nigelb> LaserJock, can't do that in ubuntu anymore, its patched (test at your own risk though)
[15:46] <nigelb> :D
[15:46] <nigelb> micahg, oww
[15:46] <nigelb> micahg, but well, the targets are mostly MOTU plus hoping-to-be-MOTU
[15:47] <nigelb> if core-devs can give 1 hour of their time, I'd be happy :)
[15:54] <juliank> mvo: I Just filed Bug #550934 with a merge directive
[15:57] <juliank> There are no new features in it; so it should probably be OK.
[15:58] <james_w> doko__: can you confirm binary or source in bug 549320 please?
[15:58] <james_w> it sounds like the title is wrong
[16:23] <jdstrand> kirkland: fyi, the md/ext4 bug we talked about is bug #543617
[16:30] <doko__> james_w: binary package only
[16:30] <kirkland> jdstrand: thx
[16:31] <pitti> sbeattie: any chance you could give the karmic-proposed devicekit-disks a try? (bug 445852); that's pretty urgent, to avoid even more HD damage
[16:31] <pitti> sbeattie: i. e. the disk utility shouldn't show smart data any more, but automount etc. should still work
[16:32] <james_w> doko__: eh? If the binary is built from dlr-languages we don't need to remove it
[16:32] <sbeattie> pitti: reading.
[16:33] <doko__> james_w: hmm, yes, I meant source :/ don't trust me, do the right thing ...
[16:33] <james_w> doko__: ok, great, thanks
[16:33] <pitti> sbeattie: don't bother reading the entire bug, though :) I'm happy to give you a summary if you need one
[16:33] <sbeattie> pitti: note that I don't have any ssds
[16:34] <pitti> sbeattie: you don't need one; I think the main point of verification here is that the package still by and large works
[16:34] <pitti> sbeattie: if you get an usb stick automounted, that should be sufficient
[16:34] <pitti> sbeattie: the only change is disabling the smart prober in the udev rules (a text format), no code changes
[16:34] <pitti> sbeattie: so we just need a quick check for "misbuilt/toolchain bug" etc.
[16:34] <sbeattie> pitti: okay. I'll get it done today.
[16:35] <pitti> sbeattie: I. e. this is a quick stopgap workaround until we have a real fix
[16:36] <bigon> james_w: for bug 549234 I have upload rights to universe actually
[16:36] <pitti> sbeattie: thanks, appreciated
[16:36] <james_w> bigon: well you didn't state that it should be synced so I missed it
[16:37] <bigon> oh I only changed the subject
[16:37] <geser> james_w: bug #550262 updated
[16:39] <james_w> thanks genii
[16:39] <james_w> geser
[16:43] <barry> does anybody know if it's possible to get more information out of the installer when a step like grub-install fails?
[16:44] <james_w> barry: there's /var/log/installer IIRC that might help
[16:48] <barry> james_w: ah, i found /var/log/syslog
[16:49] <free> pitti: ping
[16:51] <jussi01> pitti: ping
[16:51] <jussi01> free: hehe, he's a wanted man :)
[16:52] <free> jussi01: yeah.. :)
[16:52] <pitti> free, jussi01: contentless pong (please just ask the question, don't ping)
[16:52] <free> pitti: oh fine
[16:52] <jussi01> pitti:  could you take a look at the ircc thing here: https://blueprints.launchpad.net/ubuntu/+spec/irc-council-lucid-plans and let me know where we went wrong that it says 0% here: http://people.canonical.com/~pitti/workitems/canonical-community.html ?
[16:53] <free> pitti: so, upgrading from hardy to lucid doesn't seem to restart the old dbus service, so applications relying on dbus won't quite work before rebooting
[16:53] <free> pitti: is that expected or is it a bug?
[16:54] <pitti> free: after an upgrade, pretty much nothing will work
[16:54] <pitti> you absolutely need to reboot after an upgrade
[16:54] <free> pitti: I've tried to manually kill the old dbus and start the new and it worked though
[16:54] <pitti> it's expected, yes; we can't restart the system d-bus easily, and even less so the session ones
[16:54] <free> pitti: I see
[16:55] <free> pitti: the problem is that with the landscape-client we'd need a working dbus enviroment before and after the dist-upgrade
[16:56] <free> pitti: so I guess it would be very bad if we implemented some hackish workaround like the manual one above (killing the old dbus and starting the new one)
[16:56] <pitti> jussi01: ah, the problem is that you arne't in the canonical community team, so your WIs won't appear there
[16:56] <pitti> free: that's the system d-bus, right?
[16:56] <free> pitti: rright
[16:56] <pitti> free: so, until hardy, stopping the system dbus would tear down your entire system
[16:57] <pitti> free: it doesn't do that any more in lucid, since we switched X.org from hal to udev
[16:57] <free> pitti: so that means the desktop would crash?
[16:57] <pitti> so I guess the desktop would survive it
[16:57] <free> pitti: anyway you wouldn't recommend it at all?
[16:57] <pitti> but it's still not been tested at all, and changing that at this point of the release cycle is too brittle IMHO
[16:57] <free> pitti: agreed
[16:58] <pitti> free: no, I wouldn't; there's much more than this which doesn't work after a system upgrade, I'm afraid; you do need a reboot
[16:58] <james_w> free: what about dbus doesn't work after the upgrade?
[16:58] <james_w> free: it should still be working, just the old version
[16:58] <pitti> free: but what does actually break?
[16:58] <free> pitti: alright, thannks for explaining
[16:59] <free> pitti, james_w: https://pastebin.canonical.com/29788/
[16:59] <pitti> jussi01: http://people.canonical.com/~pitti/workitems/all.html#jussi01 has your's, FYI
[16:59] <free> I'm not very familiar with the dbus internals, but starting the newly installed dbus from lucid makes it work
[17:00] <free> note that we're starting a different process
[17:00] <free> not the old one which was connected to dbus *before* the ugprade
[17:00] <james_w> well, "Failed: Success" is odd to start with
[17:00] <free> james_w: yeah :/
[17:00] <pitti> free: right, that moved to /lib/dbus-1.0/dbus-daemon-launch-helper
[17:01] <pitti> but the old d-bus would still try the old path
[17:01] <pitti> as a workaround we could ship a symlink in lucid (which we could drop in lucid+1)
[17:01] <free> james_w: I believe that comes from d-bus itself though, it's the exception text
[17:01] <james_w> yes, it's calling strerror(0) apparently
[17:02] <jussi01> pitti: ok, but why the 0% on there on the one I mentioned?
[17:02] <free> pitti: I'm gonna try to put the symlink manually as a start
[17:03] <pitti> jussi01: it's just counting the WIs for people in that team
[17:03] <pitti> free: testing with the symlink is highly appreciated; if that works, I'm fine with adding that as an upgrade workaround
[17:03] <pitti> free: thanks for catching!
[17:03]  * pitti -> dinner, bbl
[17:03] <free> pitti: and thanks for the hint!
[17:05] <jussi01> pitti: ahh, thanks
[17:10] <ejat> anyone know why this happen http://paste.ubuntu.com/406057/ ?
[17:11] <chrisccoulson> ejat, your file system has gone read only
[17:37]  * barry -> lunch
[18:22] <pecisk> kenvandine, ping?
[18:22] <kenvandine> pecisk, pong
[18:22] <pecisk> kenvandine, take a change on patch? :)
[18:22] <kenvandine> pecisk, i haven't had a chance to try it yet... sorry
[18:23] <kenvandine> been chasing a pretty nasty bug in gwibber :/
[18:25] <cnd> cjwatson: do you know how the initramfs is generated?
[18:26] <amitk> cnd: hehe, that's like asking Darwin if he knew about Biology
[18:27] <cnd> amitk: just checking
[18:27] <pecisk> kenvandine, will take a look later today? :)
[18:27] <cnd> I need to figure out how to get a script into the initramfs
[18:27] <kenvandine> pecisk, yeah, will do :)
[18:28] <pecisk> kenvandine, thanks. Keep rocking :)
[18:28] <amitk> cnd: putting it in /etc/initramfs-tools/scripts doesn't help?
[18:28] <amitk> and regenerating the initramfs, ofcourse
[18:28] <cnd> amitk: I think the proper place is in /etc/initramfs-tools/hooks
[18:29] <cnd> but I can't seem to get stuff to get put in the initramfs when I invoke update-initramfs -k `uname -r` -u
[18:30] <amitk> cnd: then I'm out of ideas
[19:17] <lamont> asac/ogra: buttercup/cushaw/gourd are online now, the remainder are probably post-8 april.  turning down kandis/korlan to start the migration
[19:57] <cjwatson> cnd: if you're producing a package, the script that actually runs in the initramfs goes somewhere under /usr/share/initramfs-tools/scripts/ depending on when it should run, and you normally also want a script in /usr/share/initramfs-tools/hooks/ that copies the relevant files in
[19:58] <cnd> cjwatson: I figured my issue out, and I realized I didn't need to muck with changing anything in the initramfs
[19:58] <cnd> thanks though
[19:58] <cnd> cjwatson: however, I do have another issue if you have some time to help?
[19:59] <cjwatson> cnd: I'm about to get pulled away to watch TV with the family, but you can leave a message and either somebody will beat me to it or I'll answer when I get back
[20:00] <cnd> cjwatson: simple non-kernel package maintenance: We need to add a special modprobe.d file and script to be run when vga16fb tries to load
[20:00] <cnd> I figured I'd stuff it into module-init-tools, since that's where the other modprobe.d stuff is
[20:01] <cjwatson> cnd: I strongly, strongly advise discussing it with Keybuk first
[20:01] <cnd> I'm not too familiar with the dev process outside of the ubuntu kernel, so I wanted to confirm that I should check the source out from lp, and then upload my changes to my own branch, and create a review for the branches?
[20:01] <cjwatson> that stuff is all very delicate and it's easy to compromise boot time
[20:01] <cnd> cjwatson: agreed, though I'm trying to figure out the best way to show what I'm thinking
[20:02] <cjwatson> sure, the process you describe is reasonable; the best branch to use depends on the circumstances of course
[20:02] <cnd> yeah, ok
[20:02] <cnd> cjwatson: thanks
[20:02] <cjwatson> (it's also perfectly fine to send ordinary patches if you want, though of course branches have the opportunity to be merged more smoothly)
[20:03] <cnd> cjwatson: I'm partially curious to know how the foundations team usually works
[20:03] <cnd> is it through lp branches and merge requests?
[20:03] <cnd> or through patches?
[20:09] <cjwatson> cnd: we're flexible
[20:10] <cnd> cjwatson: cool
[20:10] <cjwatson> cnd: the growing preference is to use bzr; we're not quite there yet across the board
[20:10] <cnd> I think I prefer bzr+lp too
[20:13] <cjwatson> cnd: mostly it's a question of having bzr imports of all the packages we work on, which is a big job - mostly there but not quite
[20:14] <cnd> yeah
[20:21] <arand> cjwatson: What is the status of swap-onf-file atm? https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-karmic-swapfile is old, still valid? Is hibernation-to-file the current blocker?
[20:31] <zyga> hello
[20:47] <jdstrand> mvo: hi! so, I am running into bug #502641 (or a variant of it) but I have an up to date apt (0.7.25.3ubuntu4)
[20:49] <mvo> jdstrand: thanks, could you add some details to the bugreport or create a new one? with sources.list and what exactly you run?
[20:49] <jdstrand> mvo: ok, I tried to file a bug and there were a bunch that looked the same, so I thought I'd ask. I'll file a new one and give it to you. thanks
[20:54] <mvo> jdstrand: thanks, I know that its still not 100% where it was, but I would appreciate a good report to reproduce it
[21:05] <cjwatson> arand: I think the status is documented in the spec; I don't know any more than that.  It's still valid though and I'd like us to do it at some point, so please don't close it out or anything like that
[21:07] <arand> cjwatson: Ah, cool, I was just wondering if there were any news in general, or a new bp or so.
[21:09] <jdstrand> mvo: bug #551178
[21:10] <jdstrand> mvo: I attached both kees' sources.list and mine (we both are seeing this)
[21:12] <mvo> jdstrand: thanks, that looks good, I hope I can reproduce it, you use file:// urls that I don't have access to
[21:12] <jdstrand> mvo: well, kees uses file://. I use a local debmirror
[21:13] <jdstrand> mvo: via http
[21:13] <mvo> jdstrand: ok
[21:14] <jdstrand> mvo: I also use sources.list.d, and I put all mine in a tar.gz
[21:14] <jdstrand> (as an attachment in the bug)
[21:16] <mvo> jdstrand: thanks, I milestoned it
[21:16] <jdstrand> mvo: thanks! :)
[21:18] <mvo> jdstrand: thanks for reporting :)
[21:18] <jdstrand> sure thing :)
[21:35] <cjwatson> jbebel: you were right about it being partman-base's fault, but I was right that it was coincident with moving to parted 2.x rather than due to the alignment change. :-)
[21:35] <Laney> cjwatson: hey, the ubuntu-mono ML was deleted from the other team now, should be good to go
[21:36] <cjwatson> Laney: excellent, that worked, pending confirmation
[21:36] <Laney> cool
[21:37] <Laney> cjwatson: done it. Could you run that script now to subscribe the team to all of the packages? (do you want a link again?)
[21:38] <cjwatson> Laney: link me please, yes
[21:39] <Laney> ok, one sec
[21:40] <amanda1> http://www.mdhjakten.se/dela/?id=dti2d6s
[21:40] <amanda1> nice svhool
[21:40] <Laney> cjwatson: http://pastebin.com/NuNw7qGm
[21:56] <dutchie> hey folks, just looking at fixing bug 523822 in the "right" way. ought I use something in debian/patches, or should I just change the file in the main bit. (I've branched lp:ubuntu/<package>)
[21:56] <dutchie> where <package> = aptdaemon
[21:59] <dutchie> hmm, looks like it may make more sense to file a bug on aptdaemon
[22:01] <cjwatson> dutchie: use whatever patching method is already in use in the package you're working on
[22:03] <jbebel> cjwatson, Good to know.  I'm glad you were able to reproduce it.
[22:05] <dutchie> cjwatson: it seems to be fixed in upstream aptdaemon
[22:05] <dutchie> also, I'm enormously unfamiliar with patching systems
[22:05] <cjwatson> jbebel: I actually didn't directly, but I'm close to certain that my fix will cover it given what I now understand of the problem
[22:06] <cjwatson> jbebel: also, I've just done a successful end-to-end test of automatic LVM+encryption partitioning with my change
[22:06] <jbebel> Excellent.  I look forward to testing it as well.
[22:08] <cjwatson> well, successful modulo some text being spat out at boot time that shouldn't be, but I'm going to declare that Not My Problem for today
[22:08]  * cjwatson wonders if we should silence the LVM fd leak warnings for lucid release
[22:10] <jbebel> It would make it less frightening.
[22:11] <cjwatson> Laney: done, seemed to work: http://paste.ubuntu.com/406184/
[22:12] <Laney> cjwatson: thanks a lot, +packagebugs looks good now
[22:12] <Laney> that script might be useful for you in the future for other similar teams
[22:12] <cjwatson> yeah, I'll keep it lying around
[22:14] <sebner> Laney: cjwatson : \o/
[22:17] <cjwatson> slangasek: cryptsetup's passphrase prompt is displayed as "Enter passphrase: :********" in the plymouth details plugin, which isn't too pretty.  Is that a bug in cryptsetup or plymouth or both?
[22:17] <slangasek> cjwatson: I thought those LVM fd leak warnings *were* silenced once upon a time, and have since regressed
[22:17] <slangasek> cjwatson: "isn't too pretty" - the double colon?
[22:17] <cjwatson> yes
[22:18] <cjwatson> well, I fixed the fd leak warning induced by cryptsetup, at any rate
[22:18] <slangasek> I think that's a plymouth bug
[22:18] <cjwatson> so the interface is meant to involve passing a string terminated by ": "?
[22:19] <slangasek> IMHO the presence or absence of a trailing colon should be up to the caller
[22:19] <slangasek> and in this case, certainly, I think it's a bug to have :*** with no space after the colon that details.so is appending
[22:19] <dutchie> does "bzr push lp:~jshholland/ubuntu/aptdaemon/fix-beginn" look right for pushing a fix to lp:ubuntu/aptdaemon?
[22:19] <cjwatson> slangasek: well, yes ...
[22:19] <cjwatson> dutchie: lp:~jshholland/ubuntu/lucid/aptdaemon/fix-beginn
[22:19] <dutchie> ok, thanks
[22:20] <slangasek> cjwatson: for comparison, the ubuntu-logo theme does not append a colon there, and I think we still want it
[22:20] <slangasek> cjwatson: but I'm happy to be persuaded that I have no sense of aesthetics instead :)
[22:20] <cjwatson> note that lp:ubuntu/aptdaemon is an alias for lp:~ubuntu-branches/ubuntu/lucid/aptdaemon/lucid - the fully-qualified pattern is lp:~OWNER/DISTRIBUTION/SERIES/PACKAGE/BRANCHNAME
[22:20] <cjwatson> slangasek: I don't care either way
[22:21] <dutchie> OK, pushed. Will it end up being reviewed, or do I need to subscribe someone or do a merge request?
[22:21] <cjwatson> dutchie: you'll need to file a merge request if you want anyone to see it; nobody is automatically told about new branches
[22:21] <dutchie> alrighty
[22:21] <Laney> do you need to subscribe sponsors to merge requests?
[22:22]  * Laney has never done it from that side
[22:22] <Laney> ah, you request a review from them
[22:22] <cjwatson> the merge request UI asks you for a reviewer
[22:23] <dutchie> is this even if I committed with --fixes?
[22:23] <Laney> that just links it to the bug report
[22:23] <Laney> you need to ask for sponsorship too
[22:23] <cjwatson> linking it to the bug report will cause mail to be sent
[22:24] <cjwatson> so explicitly asking isn't quite so required, but it doesn't hurt to get your change onto the organised sponsorship list anyway
[22:24] <dutchie> so file a merge request?
[22:25] <Laney> I guess it depends who will read that mail
[22:25] <Laney> but yes, that's safe
[22:37] <sebner> Laney: you uploaded mono yourself?
[22:37] <Laney> yes
[22:39] <sebner> Laney: cool :)
[22:40] <Laney> hopefully we can sync again soon
[22:40] <Laney> would have done this time, but with ries (ftpmaster) being down, ...
[22:41] <sebner> Laney: yeah, I heard it might be back tomorrow
[22:41] <Laney> starts getting close to freeze time
[22:42] <slangasek> Laney: yay, thanks for the mismatch-cleaning upload :)
[22:42] <Laney> no worries
[23:11] <jdstrand> kees: fyi, the hard lockup when doing lvm snapshotting bug is bug #551264
[23:12] <kees> jdstrand: okay, cool.
[23:34] <cjwatson> marjo: any chance http://people.canonical.com/~marjomercado/isotestingbugs.html could be updated?