[00:19] <LPCIBot> Project windmill-devel build #268: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-devel/268/
[00:28] <wgrant> lifeless: Your LXC guide is vastly superior to the U1 one.
[00:28] <wgrant> LXC looks really nice.
[00:40] <LPCIBot> Project parallel-test build #62: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/parallel-test/62/
[01:05] <LPCIBot> Yippie, build fixed!
[01:05] <LPCIBot> Project db-devel build #657: FIXED in 5 hr 53 min: https://lpci.wedontsleep.org/job/db-devel/657/
[01:10] <wgrant> jelmer: You seem to have removed the custom KDE layout from bzr-svn on the basis that they've moved to git, but I see new svn revs yesterday...
[01:13] <sinzui> wallyworld_, do you have time to mumble
[01:14] <wallyworld_> sinzui: yes, starting mumble now
[01:19] <wgrant> lifeless: Hm, did you run into trouble with needing to run buildout under linux32 when using an i386 container on an amd64 kernel?
[01:26] <LPCIBot> Project windmill-db-devel build #418: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-db-devel/418/
[01:28] <lifeless> wgrant: I'm just fiddling with that now
[01:29] <lifeless> wgrant: yeah the u1 seemed to ignore issues ;)
[01:29]  * StevenK sighs at the topic. Wasn't the critical bug count only 205 yesterday?
[01:32] <lifeless> wgrant: feel free to tweak the page!
[01:32] <lifeless> wgrant: hallyn has a magic lxc build coming to his ppa that will automate the bind mount
[01:32] <wgrant> lifeless: I'm not sharing my ~, but it all seems to work OK as long as make always runs under linux32.
[01:33] <wgrant> Otherwise buildout uses x86_64 meliae :(
[01:33] <lifeless> interesting
[01:33] <wgrant> Surely it doesn't try to parse uname...
[01:33] <wgrant> Still, it is buildout.
[01:33] <lifeless> that could be because arch reports 64bit (which is uname based I wager)
[01:33] <lifeless> wgrant: file a bug ?
[01:33] <wgrant> Maybe/
[01:34] <lifeless> arch claims equivalent to uname -m
[01:34] <wgrant> Now, automated COW-on-tmpfs LXC parallel testing...
[01:35] <lifeless> LVM
[01:35] <wgrant> Slow!
[01:36] <wgrant> But maybe.
[01:36] <lifeless> 'meh'
[01:36] <wgrant> Well, I need a faster disk.
[01:36] <wgrant> And/or SSD.
[01:36] <lifeless> only deltas get written
[01:36] <wgrant> Sure.
[01:36] <lifeless> you may need more bandwidth available
[01:36] <lifeless> how many cores?
[01:36] <wgrant> But I don't care about persistence.
[01:36] <wgrant> 6
[01:37] <lifeless> doit
[01:37] <lifeless> testr --paralell
[01:37] <lifeless> I've been thinking about adding a profile option
[01:37] <lifeless> testr --parallel --profile=lxc
[01:39] <LPCIBot> Project devel build #828: FAILURE in 5 hr 23 min: https://lpci.wedontsleep.org/job/devel/828/
[01:44] <wgrant> lifeless: How does --parallel divide the tests?
[01:44] <lifeless> by time
[01:44] <wgrant> Huh?
[01:44] <lifeless> testr records the runtime of tests
[01:44] <wgrant> How does it know about new tests?
[01:45] <lifeless> they get round robined
[01:45] <wgrant> Right, but how does it know to dispatch them?
[01:45] <lifeless> it runs --list-tests
[01:45] <wgrant> Ahh
[01:45] <wgrant> I see.
[01:46] <lifeless> if you supply a list it could skp that
[01:46] <lifeless> wgrant: linux32 on lxc-start
[01:46] <wgrant> Ahh, that could work.
[01:46] <lifeless> s/could/does
[01:47] <lifeless> its in the wiki page now
[01:48] <lifeless> sudo lxc-start -n lucid-test-lp -d usr/bin/linux32 sbin/init
[01:48] <lifeless> robertc@lifeless-64:~$ ssh <IP_ADDRESS>
[01:48] <lifeless> $ arch
[01:48] <lifeless> i686
[01:48] <lifeless> wgrant: so you're not bind mounting; nfs?
[01:49] <wgrant> lifeless: Nothing at the moment.
[01:49] <wgrant> Since I don't want to break my external environment.
[01:49] <wgrant> Which rebuilding it for i386 will.
[01:49] <lifeless> another reason to use packages for deps
[01:55] <lifeless> wgrant: the eggs are arch specific
[01:55] <lifeless> wgrant: so nothing should break
[01:57] <wgrant> lifeless: It's not just eggs.
[01:57] <wgrant> lifeless: Some of sourcecode/ has some binaries.
[02:00] <wgrant> Oops
[02:01] <lifeless> ?
[02:02] <wgrant> lxc-destroy does not just shut down the container.
[02:02] <lifeless> -stop is what you wanted
[02:02] <wgrant> Yeah, I'm too used to Xen.
[02:02] <lifeless> but its glitching with lucid + arch diff for some reason
[02:03] <wgrant> Also, I ended up running two aufs clones of a container while still running the original container. That doesn't work very well.
[02:10] <lifeless> heh
[02:11] <lifeless> wgrant: the binariies in subverypy etc are also arch guarded paths.
[02:12] <wgrant> https://lpstats.canonical.com/graphs/LPProjectCriticalBurndown/20100624/20110624/ is upsetting.
[02:12] <wgrant> lifeless: IIRC it's pygettextpo or pygpgme
[02:12] <lifeless> ah, yes
[02:12] <lifeless> bad gettextpo
[02:12] <lifeless> urgle, we symlink gettextpo.so ?!? into lib
[02:13] <wgrant> Of course!
[02:13] <lifeless> we should import gettextpo.gettextpo, then we could indirect sensibly
[02:14] <wgrant> Yes, but that wouldn't be ancient and crufty enough.
[02:15] <lifeless> and I think I'm finally setup
[02:15] <lifeless> with a tonne more memory available.
[02:15] <lifeless> and a 32 bit build for leaner tests
[02:24] <lifeless> ugh, something is generating awful spew and breaking testr -- -t codehosting :(
[02:36] <wgrant> :(
[02:43] <lifeless>   File "/home/robertc/source/launchpad/lp-branches/working/lib/canonical/launchpad/scripts/__init__.py", line 62, in execute_zcml_for_scripts
[02:43] <lifeless>     'Setting up Zopeless CA when Zopefull CA is already running'
[02:43] <lifeless> AssertionError: Setting up Zopeless CA when Zopefull CA is already running
[02:44] <wgrant> Yay
[03:13] <lifeless_> that was unexpected
[03:14] <wgrant> Oh?
[03:14] <lifeless> I'm guessing OOM kill got gdm
[03:14] <wgrant> Nice!
[03:14] <StevenK> Haha
[03:15] <StevenK> Certainly fixed the memory pressure, though
[03:15] <lifeless> given I was watching a railsconf video I can't really be sure
[03:52] <jtv> StevenK, wgrant: does either of you have time to show me how to create a sync upload on dogfood?
[04:15] <lifeless> wgrant: 15:11 < hallyn> lifeless: do'h, that was easier than i thought, lxc already does the right thing, you just need 'lxc.arch = i686' in the config file.
[04:40] <wgrant> lifeless: Ah!
[04:40] <wgrant> lifeless: Which channel is that?
[04:40] <wgrant> #ubuntu-virt?
[04:42] <wgrant> Why is my pipe to the DC so terrible :(
[04:42] <lifeless> wgrant: #ubuntu-server
[04:50] <lifeless> also, https://bugs.staging.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats
[05:03] <lifeless> what part of our code would be doing fork in twisted ?
[05:03] <lifeless> Upon execvpe sleep ['sleep', '2'] in environment id 280573852
[05:03] <lifeless> :Traceback (most recent call last):
[05:03] <lifeless>   File "/home/robertc/source/launchpad/lp-sourcedeps/eggs/Twisted-11.0.0-py2.6-linux-i686.egg/twisted/internet/process.py", line 412, in _fork
[05:03] <lifeless>     self._setupChild(**kwargs)
[05:03] <lifeless> ...
[05:03] <lifeless>   File "/home/robertc/source/launchpad/lp-sourcedeps/eggs/Twisted-11.0.0-py2.6-linux-i686.egg/twisted/internet/posixbase.py", line 171, in wakeUp
[05:03] <lifeless>     util.untilConcludes(os.write, self.o, 'x')
[05:03] <lifeless>   File "/home/robertc/source/launchpad/lp-sourcedeps/eggs/Twisted-11.0.0-py2.6-linux-i686.egg/twisted/python/util.py", line 783, in untilConcludes
[05:03] <lifeless>     return f(*a, **kw)
[05:03] <lifeless> OSError: [Errno 9] Bad file descriptor
[05:21] <LPCIBot> Project parallel-test build #63: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/parallel-test/63/
[05:23] <lifeless> anyone around that knows our mm integration ?
[05:24] <wgrant> I know a liiiittle.
[05:24] <wgrant> Enough to debug it mostly.
[05:24] <lifeless> so
[05:24] <lifeless> lib/lp/services/mailman/tests/test_mm_cfg.py
[05:24] <lifeless> runs in FunctionalLayer
[05:24] <lifeless> does FunctionalLayer *start* mailman ? I thought it didn't.
[05:24] <lifeless> thus, I am confused.
[05:25] <lifeless> it wants a /var/tmp/mailman directory
[05:25] <lifeless> this is unsafe for parallel testing
[05:25] <lifeless> I want to make it dynamic
[05:25] <wgrant> Doesn't buildmailman create /var/tmp/mailman?
[05:25] <wgrant> (vomit)
[05:26] <StevenK> Barry wants to kill buildmailman
[05:26] <wgrant> Yeah, I think it does.
[05:26] <StevenK> I fully support this
[05:26] <wgrant> buildmailman configures mailman into /var/tmp/mailman
[05:28] <wgrant> lifeless: So, I think you probably want to run them in a layer that is non-parallelisable.
[05:28] <wgrant> Or just delete mailman.
[05:29] <lifeless> why?
[05:29] <wgrant> Why what?
[05:30] <lifeless> why non-parallelisable (btw that does not exist) or delete (don't we use it?)
[05:30] <wgrant> We use it, but it's crap.
[05:30] <LPCIBot> Project windmill-db-devel build #419: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/419/
[05:30] <wgrant> And it's hard to efficiently parallelise because you'd probably need to rebuild mailman to change the path.
[05:30] <lifeless> breaking lists.launchpad.net would probably be considered a regression
[05:30] <wgrant> Quite possibly.
[05:32] <lifeless> I can't quite tell if you're trolling or not
[05:33] <lifeless> We should be able to setup a transient mailman per test runner fairly directly
[05:33] <wgrant> Directly but slowly.
[05:33] <lifeless> I have a fixture around that creates a python module
[05:34] <lifeless> lib/mailman isn't even importable
[05:34] <lifeless> it shouldn't be under lib
[05:39] <lifeless> 23 seconds
[05:45] <lifeless> anyone got attachments to /var/tmp/mailman ?
[05:45] <lifeless> I'd like to shove it under the source tree
[05:45] <lifeless> e.g. ./var/mailman
[05:46] <StevenK> I'd like to kill it from the tree entirely and move to MM3
[05:52] <lifeless> we'll want a network fake that we can use to make sure we interact with it correctly
[05:53] <lifeless> I'd love to see that done and it move out of tree
[05:53]  * wgrant throws rocks at aufs.
[05:56] <lifeless> I think I need to tweak fixtures a little first
[05:57] <jtv> hey there wgrant!
[05:57] <wgrant> Hi jtv. Did you work out what you needed?
[05:57] <jtv> Nope
[05:57] <wgrant> StevenK possibly knows, or I can work it out.
[05:57] <jtv> Big J said it was easy though
[05:58] <jtv> Haven't heard from him either.
[05:58] <wgrant> But it was a feature introduced by your squad, so you should know :P
[05:58] <lifeless> did he say 'a small matter of programming' ?
[05:58] <StevenK> Unlikely
[05:58] <StevenK> Since he and I wrote the support
[05:59] <jtv> I suppose I can just run "make harness" on dogfood, but it'd be nice if I had a UI way to do it.
[05:59] <wgrant> jtv: the DSD sync thing will create jobs over an FF-configurable threshold, won't it?
[05:59] <wgrant> When the job runs, it will check if it's allowed. If not, it will put itself in the queue.
[05:59] <jtv> No, that's not the case anymore.  It has to do that in all cases now.
[06:00] <jtv> Do we cron DSDJobs now?
[06:00] <jtv> On dogfood, I mean?
[06:01] <wgrant> I'd check the crontab.
[06:04] <jtv> ah — distroseriesdifference_job.py, every 2 minutes
[06:05] <jtv> StevenK, wgrant: mind if I sync some packages on df for a while?
[06:05] <wgrant> jtv: Go ahead.
[06:05] <StevenK> It won't love you, but go ahead
[06:06] <jtv> StevenK: I can't live without love, but I probably can without yours.  :)
[06:06] <wgrant> Well, this seems to be working OK.
[06:06] <jtv> (Hmm the error reporting on +localpackagediffs actually works pretty well for me now… needs a bit more tweaking but it's clear there's an error and it takes up no new space)
[06:07] <wgrant> I have three tmpfs aufs COW LXCs running the test suite.
[06:08] <jtv> want want want!
[06:09] <wgrant> Now I just need to automatically provision them (mkdir, mount, mount, sed, lxc-start does it), and tie it into testr.
[06:09] <jtv> well that's the interesting part, isn't it?
[06:10] <wgrant> Well, aufs is infamous for its flakiness.
[06:10] <jtv> I don't think I know it.
[06:10] <wgrant> We used it at uni for a while and had to give up.
[06:10] <wgrant> It's like unionfs, except less flaky.
[06:10] <wgrant> But still flaky.
[06:10] <wgrant> I believe it's still used for livecds.
[06:10] <lifeless> wgrant: nice
[06:11] <lifeless> wgrant: you'll want to bring one up for --list-tests
[06:11] <jtv> So you're giving each container its own union mount overlayed on the branch setup?
[06:11] <wgrant> jtv: Right, I have the base container with postgres and LP installed.
[06:11] <wgrant> Then I create a tmpfs for each instance.
[06:12] <wgrant> Mount that as an RW overlay over the RO base container for each instance.
[06:12] <lifeless> wgrant: hows the memory pressure ?
[06:12] <wgrant> lifeless: It's i386, so it's nothing.
[06:12]  * jtv underlines "per-directory journaling QoS" on his filesystems wishlist
[06:12] <wgrant> I only have 8GiB of RAM and killed Chromium recently. But I have 3GB free and a couple of GB cached.
[06:12] <lifeless> wgrant: well, when you get to 6 instances, it may be less -nothing- :>
[06:12] <wgrant> True.
[06:12] <wgrant> Let's see what happens if I spin up a few more...
[06:13] <jtv> Wouldn't it be great if you could tell a regular filesystem, "feel free to forget the entire contents of this directory on next mount, if it's more convenient than recovery"?
[06:14] <StevenK> tmpfs?
[06:14] <wgrant> jtv: Indeed.
[06:14] <jtv> StevenK: no, that ties the policy to the mechanism.  And you have to manage it, e.g. unmount it when you no longer need it.  And it causes worries about how it interacts with swap.
[06:15] <StevenK> Meh, they're just pages
[06:15] <jtv> What I want is a /tmp that's still a regular directory on my regular disk, but doesn't waste my time journalling.
[06:15] <StevenK> Then create it as ext2
[06:16] <jtv> *cough*
[06:16] <lifeless> seriously
[06:16] <StevenK> Or use tune2fs to remove the journal
[06:16] <jtv> *cough* *cough*
[06:16] <lifeless> which will btw make it ext2
[06:16] <wgrant> lifeless: 6 running now, hovering at 64% RAM used, all 6 cores >95%
[06:16] <jtv> I do still want journaling _and_ per-file system on my FS by default, thank you.
[06:17] <lifeless> wgrant: schweet
[06:17] <StevenK> lifeless: Sort of. It can be ext3 with other ext3 features and no journal
[06:17] <wgrant> And it's all tmpfs, so no iowait.
[06:17] <jtv> wgrant: and I don't suppose there's any CPU overhead to lxc?
[06:17] <wgrant> Despite my system drive currently being a shitty WD Green.
[06:17] <lifeless> jtv: bugger all
[06:17] <wgrant> jtv: It's just namespacing, basically.
[06:17] <wallyworld_> should i expect that we could add a new (null) column to an existing table "live"? and populate it with a script? and then mark the column as not null
[06:17] <wgrant> jtv: All runs on the system kernel.
[06:17] <jtv> Sweet.
[06:17] <lifeless> jtv: uses built in namespace facilities in the kernel, needs a new userspace library instance etc
[06:18] <lifeless> and you have a bit of networking thunks going on
[06:18] <wgrant> lifeless: The first two runs were on their own. DatabaseLayer took 1:21 to run. The sixth just passed DatabaseLayer, took 1:22
[06:18] <jtv> Is it the trick where the kernel basically just keeps separate pointers for its data structures, so there are no cross-references?
[06:18] <wgrant> lifeless: So it seems to scale rather well.
[06:19]  * jtv is so looking forward to this
[06:19] <lifeless> jtv: https://dev.launchpad.net/Running/LXC
[06:19] <jtv> Thanks
[06:19] <wgrant> It's just a bit lighter-weight than KVM.
[06:19] <lifeless> jtv: thats now debugged to the point that it works; wgrants aufs and sed stuff will sit on top of that basic config
[06:19] <lifeless> its a *tonne* lighter than kvm
[06:19] <jtv> Should be, yes.  No qemu.
[06:20] <jtv> …Right?
[06:20] <wallyworld_> i tried to get lxc working on my box but got errors with the network devices trying to start it up :-(
[06:20] <lifeless> wallyworld_: what errors?
[06:20]  * wallyworld_ looks
[06:20] <lifeless> wallyworld_: were you following my notes or the u1 notes or something else again ?
[06:20] <wallyworld_> lifeless: your notes
[06:20] <wallyworld_> ian@wallyworld:~/projects/lp-branches/devel-sandbox$ sudo lxc-start -n natty-lp
[06:20] <wallyworld_> lxc-start: failed to attach 'vethgHMwnY' to the bridge 'virbr0' : No such device
[06:20] <wallyworld_> lxc-start: failed to create netdev
[06:20] <wallyworld_> lxc-start: failed to create the network
[06:20] <wallyworld_> lxc-start: failed to spawn 'natty-lp'
[06:20] <wallyworld_> lxc-start: No such file or directory - failed to remove cgroup '/sys/fs/cgroup/cpu/natty-lp'
[06:21] <lifeless> wallyworld_: do you have libvirt installed ?
[06:21]  * wallyworld_ checks
[06:21] <lifeless> wallyworld_: if you've used virt-manager you will
[06:21] <lifeless> but if you've not, even if you have used virtualbox, you probably don't.
[06:22] <jtv> By the way, exactly when does test_on_merge.py run?  (I'm assuming this shifted a bit since the script was named)
[06:22] <wallyworld_> lifeless: no libvert installed
[06:22] <lifeless> jtv: it doesn't
[06:22]  * wallyworld_ fires up apt-get
[06:23] <lifeless> wallyworld_: you want libvirt-bin
[06:23] <jtv> lifeless: then we can get rid of it?
[06:23] <lifeless> jtv: no, we may well want it when we do the parallel testing work
[06:23] <jtv> ISTRM getting the near-useless "one huge chunk twice an hour" output.
[06:24] <jtv> The reason I ask is, we have CommandSpawner now which is probably better at processing output from sub-processes.
[06:24] <wallyworld_> lifeless: \o/ thanks!
[06:25] <jtv> I think test_on_merge just waits for a huge fixed-size chunk of output and then dumps the whole thing (even if the chunk ends in the middle of a line, hence the huge chunks)
[06:25] <jtv> Using MF would fix both.
[06:26] <lifeless> jtv: IIRC test on merge did more than just that
[06:26] <jtv> It does do more.
[06:26] <lifeless> jtv: I would be happy to see test on merge ported
[06:26] <wallyworld_> lifeless: so on a 64 bit system (which i have), do i understand correctly that using a 32 bit lxc will use less memory running lp? or did i make that bit up?
[06:26] <lifeless> I wouldn't be happy to have it deleted yet
[06:26] <lifeless> wallyworld_: significantly less
[06:26] <wallyworld_> so i would install postgres etc etc into the vm?
[06:26] <lifeless> wallyworld_: we'll want to run the production tests on 64 bit to catch C bugs, but for devs it should be totally fine to run 32 bit
[06:26] <lifeless> wallyworld_: yes
[06:27] <jtv> The MF would need some extensions, I'm sure, but it's basically a ready-made simple API to managing parallel sub-processes.
[06:27] <wallyworld_> cool. i have 4GB and am constantly up at ~90% usage
[06:27] <lifeless> wallyworld_: I suspect this will help
[06:27] <wallyworld_> awesome. will try it. thanks
[06:27] <lifeless> jtv: MF ?
[06:28] <wallyworld_> may have to set up my ide to do "remote" debugging :-)
[06:28] <jtv> wgrant: I wonder if the unionfs overlay would also make a faster way to restore the test playground db between tests.  :-)
[06:28] <jtv> lifeless: it stands for CommandSpawner.
[06:28] <lifeless> jtv: no, because you'd need to bounce postgresql
[06:28] <jtv> bugger :)
[06:28] <wgrant> Hmm.
[06:29] <wgrant> aufs seems to sometimes interact badly with the hardlink security checks.
[06:29] <wgrant> In particularly when rm -r'ing directories on the underlay.
[06:29] <jtv> lifeless: CommandSpawner was originally conceived as a Mother class that produces and manages child processes, i.e. a Forker.
[06:29] <wgrant> Still, with /var/tmp/bazaar.launchpad.dev gone from the underlay it is happy again.
[06:30] <wallyworld_> jtv: does that make it a Mother Forker? since it manages child processes?
[06:31] <jtv> wallyworld_: shhhh
[06:31] <wgrant> Hmm.
[06:32] <wgrant> I guess the 6 runs don't really compete for cache.
[06:32] <wgrant> Since they are using the same underlying files.
[06:32] <lifeless> yes
[06:32] <lifeless> the writes are the only IO load you should have
[06:33] <wgrant> At least this isn't shared aufs on top of Solaris NFS.
[06:33] <wgrant> That is *fun*.
[06:33] <wgrant> And kernel OOPSish.
[06:33]  * jtv runs in terror
[06:34] <wgrant> Ah, bug #729338
[06:34] <_mup_> Bug #729338: yama hardlink restriction misbehaves under aufs <linux (Ubuntu):Triaged by apw> < https://launchpad.net/bugs/729338 >
[06:34] <wallyworld_> anyone want to do 2 small reviews?
[06:34] <wallyworld_> https://code.launchpad.net/~wallyworld/launchpad/picker-textfield-focus/+merge/65608
[06:34] <wallyworld_> https://code.launchpad.net/~wallyworld/launchpad/admins-can-unsubscribe-bugs/+merge/65615
[06:35] <jtv> I'll take the first.
[06:35] <wallyworld_> thanks
[06:35] <wallyworld_> the 2nd one is only 44 lines
[06:35] <jtv> Damn, picked the wrong one.
[06:36] <wallyworld_> why? javascript?
[06:36] <jtv> No, not 44 lines.
[06:36] <jtv> Oh, wait, this one's 40 lines.  I win!
[06:36] <wallyworld_> :-)
[06:36] <jtv> …as soon as the page will load.
[06:36] <wallyworld_> i did say small
[06:41] <wgrant> Hmm.
[06:41] <wgrant> Some tests are pretty RAM-hungry.
[06:41] <wgrant> Almost OOMed there, because they were in sync.
[06:41] <lifeless> yeah
[06:41] <lifeless> you need the full run to guage the footprint
[06:41] <lifeless> wgrant: you have what, 6G ?
[06:42] <wgrant> test_process_job_sources_cronjob creates heaps of processes.
[06:42] <wgrant> 8G
[06:42] <lifeless> wgrant: on a hex cpu ?
[06:42] <wgrant> Full LP processes :(
[06:42] <wgrant> Yes.
[06:42] <lifeless> wgrant: thats... unusual
[06:42] <wgrant> Oh?
[06:43] <lifeless> AIUI the general thing is to fill 3 banks with identical memory and you get twice the memory bandwidth
[06:44] <lifeless> wgrant: http://www.intel.com/support/motherboards/desktop/sb/CS-011965.htm#triple
[06:44] <wgrant> lifeless: This is an AMD chip.
[06:44] <lifeless> ah
[06:45] <lifeless> ignore me then :)
[06:45] <wgrant> Does Intel have any hex-core chips out yet?
[06:45] <wgrant> (I was just going to go with a cheap AMD quad-core, but the hex-core was only slightly more expensive so I thought why not...)
[06:47] <jtv> wallyworld_: first one's done.
[06:47] <wallyworld_> jtv: thanks!
[06:48] <lifeless> wgrant: http://ark.intel.com/Product.aspx?id=53568&processor=E7-2803&spec-codes=SLC3M
[06:48] <wgrant> lifeless: OK, but Xeons released a month ago don't count.
[06:48] <lifeless> wgrant: is yours 6 cores + ?threadpercor ?
[06:48] <StevenK> Haha
[06:48] <StevenK> Why not?
[06:48] <wallyworld_> jtv: i had the same question about not using 'unseen'. i should have done it as a driveby perhaps
[06:49] <lifeless> wgrant: they've had 6 core xeons for a while, though the 10 core ones look *shiny*
[06:49] <jtv> wallyworld_: I was wondering whether it might be deliberate, e.g. so as not to hinder inclusion in lazr-js.
[06:49] <wallyworld_> maybe. i was going to ask tomorrow
[06:51] <jtv> wgrant: I actually had reason to go with a 2-core not so long ago because it had better single-thread performance…  that wasn't for me though: what you're doing will probably make lots of cores more attractive.  :)
[07:02] <LPCIBot> Project db-devel build #658: FAILURE in 5 hr 57 min: https://lpci.wedontsleep.org/job/db-devel/658/
[07:10] <lifeless> jtv-eat: 2-core 4-threads?
[07:10] <jtv-eat> lifeless: probably, though AMD has realized that SMT is no longer a very good idea.
[07:11]  * jtv-eat logs in halfway across the world to check
[07:11] <lifeless> wgrant: so I was aksing, is yours 6(12) or 6(6)
[07:11] <wgrant> lifeless: Oops, missed that. 6(6).
[07:12] <jtv-eat> Bulldozer?
[07:13] <wgrant> Is Bulldozer out yet?
[07:13] <jtv-eat> dunno
[07:13] <wgrant> Q3, IIRC.
[07:15]  * jtv-eat decides to live up to his name
[07:32] <LPCIBot> Project windmill-devel build #269: STILL FAILING in 3 min 26 sec: https://lpci.wedontsleep.org/job/windmill-devel/269/
[07:34] <wgrant> StevenK: Could you please perma-kill the Windmill builders?
[07:34] <LPCIBot> Yippie, build fixed!
[07:34] <LPCIBot> Project devel build #829: FIXED in 5 hr 54 min: https://lpci.wedontsleep.org/job/devel/829/
[07:34] <StevenK> The jobs themselves or the slaves?
[07:34] <wgrant> 06:59:26 < deryck> Can we please kill those windmill notices?  Windmill is dead to us.
[07:34] <wgrant> 07:08:09 < deryck> abentley, indeed.  we'll move to selenium2/webdriver at the Thunderdome.
[07:34] <wgrant> 07:08:33 < deryck> flacoste, sinzui -- ok, thanks.  StevenK can we kill the Windmill runner?  Not needed now.
[07:35] <StevenK> I missed that
[07:35] <StevenK> wgrant: Delete or disable?
[07:35] <wgrant> StevenK: Disable pls.
[07:36] <wgrant> I don't trust that we'll have anything good by next week.
[07:36] <StevenK> Both done
[07:36] <wgrant> Thankyou sir.
[07:36] <nigelb> Ooooh, selinium instead of windmill. Nice.
[07:40]  * StevenK kills a slave while looking at Jenkins
[07:41] <StevenK> I need to work out why Jenkins is now taking nearly six hours
[07:46] <lifeless> http://arstechnica.com/business/news/2011/06/amd-launches-second-fusion-cpu-gives-glimpse-at-future-of-cpugpu.ars
[07:50] <jtv> StevenK: how could it possibly perform well without Oracle?
[07:50] <jtv> lifeless: el Reg had a nice article about HP's new APU-based laptops IIRC.
[07:52] <StevenK> jtv: Your implant is acting up.
[07:52] <jtv> errrhuh?
[07:53] <jtv> be more Enterprise, Steve!
[07:53] <jtv> (i.e. massively slower at three times the price)
[08:33] <lifeless> allenap: actually I'm redoing your implementation for those bugs - see https://bugs.launchpad.net/testtools/+bug/801031
[08:33] <_mup_> Bug #801031: gather_details evaluates details <testtools:Triaged> < https://launchpad.net/bugs/801031 >
[08:46] <bigjools> good morning
[08:48] <danilos> bigjools, good morning
[09:06] <allenap> lifeless: Cool. I eagerly await the outcome :)
[09:13] <lifeless> allenap: its pushed
[09:14] <lifeless> allenap: along with a new stock fixture and gathering details from child fixtures
[09:14] <allenap> lifeless: Ah, I've just seen it. Neat :)
[09:18] <lifeless> yah, its nearly the inner loop from gather_details
[09:22] <lifeless> and 0.3.6 pushed
[10:01] <huwshimi> mpt: Hi. Did you want to talk about that UI lightning talk today?
[10:03] <mpt> huwshimi, yep, in an hour or so if that's good for you
[10:03] <huwshimi> mpt: Yeah that's fine with me
[10:04] <jelmer> wgrant: still there?
[10:05] <wgrant> jelmer: Indeed.
[10:05] <wgrant> you're well today?
[10:05] <wgrant> Or at least moreso?
[10:05] <jelmer> wgrant: Yeah, feeling much better. Thanks :)
[10:06] <jelmer> wgrant: I was wondering if perhaps the qastaging machine didn't have an existing copy of the imports, causing every import to be a full from-scratch import.
[10:06] <jelmer> (and thus not being able to test the upgrade, no matter what the database says about the current format)
[10:09] <wgrant> jelmer: I thought I used an import that was there. But I suspect I was wrong. When I QA'd it yesterday I made sure a LOSA copied an un-upgraded copy into place first, and it worked fine.
[10:10] <wgrant> jelmer: After copying the staging area across, I called requestMirror() on the branch and confirmed that the externally visible copy was pack-0.92.
[10:10] <wgrant> Then forced an import, and it became 2a.
[10:10] <jelmer> wgrant: ah, cool
[10:10] <jelmer> wgrant: thanks for qa'ing that, btw. I'm looking at QA'ing my other two branches atm
[10:10] <wgrant> jelmer: Thanks. Did you see my KDE question?
[10:11] <wgrant> lifeless: Slightly under 3.5 hours.
[10:11] <wgrant> lifeless: For 6 concurrent runs of the full suite.
[10:11] <lifeless> wgrant: thats awesome
[10:12] <wgrant> About 15 minutes slower than when I ran the test suite locally, but it's probably longer now.
[10:12] <wgrant> And that's with some accidental swapdeath.
[10:12] <wgrant> Hi Thunderbird.
[10:16] <jelmer> wgrant: isn't their plan to migrate everything to Git eventually, or are some branches going to stay in svn?
[10:16] <wgrant> jelmer: I don't know. But this will break SVN now, won't it?
[10:17] <wgrant> Or are existing branches OK?
[10:17] <jelmer> wgrant: the layouts aren't used for anything on the Launchpad side of things, they're used to discover branches if you import an entire repository
[10:18] <jelmer> wgrant: there was also a bug in bzr-svn that prevented it from opening something as a branch if the hard-coded layout (like we had for Apache or KDE) said it wasn't a branch
[10:18] <wgrant> Oh, I thought it was still somehow used to work out the root for consistent fileids and stuff.
[10:18] <wgrant> OK.
[10:20] <wgrant> Tests with failures: lp.services.job.tests.test_runner.TestTwistedJobRunner.test_memory_hog_job (subunit.RemotedTestCase)
[10:20] <wgrant> So the test suite is *deliberately* memory-hungry.
[10:20] <wgrant> Awesome!
[10:21] <jelmer> wgrant: it's actually allocating a lot of memory to test that?
[10:26] <wgrant> Not too much, actually.
[10:26] <wgrant>     def run(self):
[10:26] <wgrant>         self.x = '*' * (10 ** 6)
[10:26] <wgrant> Probably just be a coincidence that it blew up while I was running out of ram.
[10:28] <rvba> wgrant: FYI, bigjools and I decided to refactor the multi parent like this: if the destination archive is empty: use the packagecloner, if not: use the (much safer but slower) packagecopier.
[10:29] <wgrant> rvba: You'll need to optimise intra-archive copies with the cloner too.
[10:29] <wgrant> Or initialising oneiric+1 will take forever²
[10:29] <bigjools> yes
[10:29] <bigjools> did we discuss that case rvba?
[10:30] <bigjools> I *think* we did but my memory sucks todday
[10:30] <bigjools> as does my typing
[10:30] <rvba> I don't think so.
[10:30] <rvba> This case will use the packagecopier.
[10:31] <rvba> wgrant: what kind of optimisation do you have in mind?
[10:31] <wgrant> rvba: Copying within an archive (eg. natty->oneiric) should use the packagecloner.
[10:31] <wgrant> And it should be done first.
[10:31] <wgrant> I think.
[10:32] <wgrant> Or it's going to be slow.
[10:32] <bigjools> rvba: this is the special case of initialising a new distroseries
[10:32]  * wgrant eats.
[10:32] <bigjools> where there's already a series
[10:32] <rvba> bigjools: Yes, the previous_series case.
[10:32] <bigjools> rvba: the packagecopier only needs to be used if there's >1 parent
[10:33] <rvba> bigjools: my understanding was that the packagecopier should be used if the destination archive is not empty.
[10:33] <rvba> To avoid conflicts.
[10:33] <lifeless> wgrant: did rabbitmq start ok in your lxc ?
[10:33] <lifeless> its whinging in mine
[10:34] <rvba> bigjools: ?
[10:35] <bigjools> rvba: there won't be any conflicts in a new distroseries
[10:35] <bigjools> s/new/empty/
[10:35] <bigjools> rvba: so you can refine your case to empty distroseries
[10:35] <bigjools> not empty archive
[10:35] <rvba> bigjools: Understood.
[10:36] <rvba> bigjools: I'll do that in the following branch then (the one that adds support for this init from [previous_series]
[10:36] <rvba> bigjools: wgrant first branch ready to be reviewed: https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676
[10:37] <rvba> This branch adds *only* multi parent backend support.
[10:37] <bigjools> 1394 lines /o\
[10:37] <rvba> Sorry about that.
[10:37] <bigjools> :)
[10:37] <bigjools> I'll look at the last changes
[10:37] <rvba> YEs
[10:38] <rvba> Thanks.
[10:39]  * rvba fixes the conflicts introduced by merging this in the 4 dependent branches.
[10:46] <bigjools> rvba: I don't think you need that duplicate source check any more
[10:46] <bigjools> the packagecopier will take care of that
[10:47] <rvba> bigjools: I think I have removed any duplicate source check ...
[10:47] <bigjools> rvba: ah ok, it was in revno 13190
[10:47] <bigjools> rvba: perhaps you can attach a partial diff that you want reviewed on the MP?
[10:48] <bigjools> just email it with an attachment
[10:48] <bigjools> or is it all in revno 13191?
[10:48] <rvba> bigjools yes: http://bazaar.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/revision/13191
[10:48] <bigjools> ok I'll look at that
[10:48]  * bigjools gets some caffeine in preparation
[10:49] <rvba> Thanks.
[10:49] <wgrant> lifeless: No, that was one of the 5 tests with errors.
[10:49] <wgrant> lifeless: Because my hostname isn't configured.
[10:49] <wgrant> lifeless: I presume.
[10:49] <wgrant> lifeless: (the other tests were all mmcfg stuff relating to aufs)
[10:49] <bigjools> rvba: first comment:
[10:49] <bigjools> def getPublishedSources(name=None, names=() ....
[10:49] <bigjools> rvba: can you make the code accept name as a single item or a list
[10:50] <bigjools> two params is ugly
[10:50] <rvba> bigjools: ok.
[10:50] <bigjools> rvba: the external API should be ok still, you'd just do a type check in the method
[10:50] <rvba> bigjools: Right, I'll do that.
[10:51] <bigjools> Python FTW
[10:51] <rvba> I'm afraid wgrant concerns about duplicated files is still not addressed :(
[10:51] <bigjools> why's that?
[10:51] <bigjools> if you use the packagecopier for subsequent syncs it should be
[10:52] <rvba> but how about the first copy ... the one that will use packagecloner?
[10:52] <bigjools> that can never conflict
[10:52] <bigjools> the series is empty
[10:53] <rvba> oh ... that's right ... sorry, my mind is a mess I must say.
[10:53] <bigjools> understandable :)
[10:53] <bigjools> rvba: well to be more specific, intra-archive to an empty series can't conflict
[10:53] <rvba> Right.
[10:54] <bigjools> inter-archive to an empty series *can* conflict but we prevent that elsewhere
[10:54] <bigjools> brb
[10:56] <wgrant> Right. Intra-archive copies to a new series are always fine. Inter-archive copies to a new archive are always fine.
[10:58] <lifeless> allenap: btw the +0 hack suggests prod has something wrong with it
[10:58] <lifeless> allenap: a root cause affecting other pages
[10:59] <allenap> lifeless: Oh no, another rabbit hole :)
[11:00] <lifeless> :)
[11:01] <lifeless> I don't think you need to dig into it
[11:01] <bigjools> just fall down it
[11:01] <lifeless> but I think you should note in the patch that avoiding the index is a workaround for an undiagnosed issue
[11:01] <allenap> lifeless: Okay, I'll add that to the follow-up branch.
[11:01] <lifeless> it would be nice to diagnose without impacting prod
[11:02] <lifeless> but servers with 128GB of ram and TB's of capacity are not cheap
[11:02] <lifeless> allenap: (and that said, the +0 thing is -much- cleaner than the union)
[11:02] <allenap> lifeless: Agreed, emphatically.
[11:02] <lifeless> allenap: another example of this was the sourcepackagename issue the other day
[11:03] <lifeless> allenap: the query joined with archive is fast (when hot) on qastaging, terrible on prod
[11:04] <allenap> lifeless: Is there a bug about this anywhere? That (archive, status) index probably offers fairly low selectivity on SPPH. I wonder if it exists in staging/qastaging.
[11:07] <lifeless>     "securesourcepackagepublishinghistory__archive__status__idx" btree (archive, status)
[11:07] <lifeless> thats staging
[11:07] <lifeless>     "securesourcepackagepublishinghistory__archive__status__idx" btree (archive, status)
[11:07] <lifeless> allenap: we possible want (status, archive)
[11:07] <lifeless> allenap: -or-
[11:08] <lifeless> (archive, status where status in 1,7,534) [or whatever it is]
[11:08] <bigjools> heh, those look like IDs :)
[11:08] <lifeless> if its a stats problem a partial index will help more than a reversed index I think
[11:08] <allenap> lifeless: Okay, I'll throw this discussion in a bug report.
[11:09] <lifeless> thanks!
[11:13] <bigjools> rvba: why are you doing:
[11:13] <bigjools> for pocket in archive.getPockets():
[11:13] <bigjools> and running do_copy in a loop?
[11:14] <rvba> bigjools: I thought this was the only way to use do_copy because I had to specify the destination pocket in do_copy.
[11:15] <bigjools> hmph
[11:15] <bigjools> ok
[11:15] <rvba> bigjools: It's stupid ... so if you have any idea around that I'm glad to hear about it :).
[11:16] <bigjools> rvba: I was hoping that do_copy would use the same pocket as the source
[11:16] <bigjools> but it appears not
[11:16] <rvba> Me too.
[11:16] <bigjools> rvba: so this is a bit simplistic anyway
[11:16] <bigjools> the pocket should always be RELEASE
[11:16] <bigjools> I think the cloner does that?
[11:16]  * rvba checks
[11:17] <rvba> Indeed.
[11:17] <rvba> Wait ...
[11:18] <rvba> pubrec.sourcepackagerelease.createBuild uses PackagePublishingPocket.RELEASE
[11:19] <rvba> bigjools: no, you're right, initialize_distroseries has the destination pocket hardcoded to RELEASE
[11:19] <bigjools> rvba: that's the only available pocket in an unreleased series
[11:20] <bigjools> so just hard-code it and remove the loop
[11:20] <rvba> bigjools: ok.
[11:44] <huwshimi> mpt: Available anytime. I can come find you if you like or you can come find me... I've moved further around the office
[11:45] <lifeless> hmm, oops
[11:45] <lifeless> I lp-landed rather than ec2.
[11:45] <lifeless> ah well, its only a dep update, and should be sane.
[11:46] <lifeless> buildbot will hate on me if its not.
[11:46] <bigjools> rvba: on line 670 of packagecopier.py, why did you need to add the extra "if len(source.getBuiltBinaries()) != 0:" ?
[11:47] <bigjools> does copyBinariesTo blow up without it?
[11:47] <rvba> bigjools: Yes
[11:48] <bigjools> rvba: I think it would be better to make copyBinariesTo not blow up
[11:48] <rvba> That's a side effect of adding 'strict_binaries'
[11:48] <bigjools> just return Non if binaries is None or empty
[11:48] <bigjools> right
[11:48] <rvba> bigjools: ok.
[11:49] <bigjools> rvba: you need to be wary of multiple calls to getBuiltBinaries() there, it's a crazy query
[11:50] <bigjools> making copyBinariesTo will fix that double call
[11:50] <bigjools> making copyBinariesTo work will fix that double call
[11:50] <rvba> Understood.
[11:50]  * rvba looks at getBuiltBinaries
[11:51] <bigjools> issuing the same query more than once is crack regardless :)
[11:51] <cjwatson> wgrant: any news on that cocoplum downtime for germinate-lubuntu?
[11:52] <cjwatson> wgrant: I'm more or less unblocked on the disk space side now ...
[11:52] <wgrant> cjwatson: I've not seen mrevell this week, and he normally organises downtime. Perhaps I should just arrange it myself...
[11:55] <cjwatson> is there much to organise in this case?  nobody except IS normally notices if I put cocoplum onto manual for a bit :-)
[11:55] <huwshimi> wgrant: He's on leave this week
[12:00] <wgrant> cjwatson: Well, we should restart poppy or it might get a bit angry.
[12:01] <wgrant> cjwatson: And we consider that to be downtime worthy of announcement, historically.
[12:02] <bigjools> you need to restart poppy for a germinate change?
[12:02] <wgrant> We could just cowboy it, but that upsets people.
[12:03] <wgrant> And we've already had one this week :(
[12:03] <wgrant> Plus keeping cocoplum up to date is nice.
[12:05] <bigjools> why does poppy need a restart for a germinate change?  Remember it's a separate tree now.
[12:05] <jml> huwshimi: can I persuade you to join me for an early lunch?
[12:05] <wgrant> bigjools: Not on cocoplum it's not.
[12:05] <wgrant> Unless that changed without anybody telling me.
[12:06] <wgrant> And I'm pretty sure it didn't.
[12:06] <huwshimi> jml: Probably, I was going to have a chat with mpt sometime this morning but I might be able to delay that. Did you want to lunch now?
[12:06] <jml> huwshimi: now would be ideal for me
[12:06] <huwshimi> jml: ok
[12:06] <huwshimi> jml: One sec
[12:07] <huwshimi> mpt: Hey, can we delay until this afternoon or tomorrow sometime?
[12:07] <gmb> allenap: If you've got time, a branch for you to review (diff hasn't generated yet): https://code.launchpad.net/~gmb/launchpad/private-branches-bug-657004/+merge/65639
[12:08] <jml> huwshimi: if you've already got something scheduled then don't break it just because I'm hungry and I want to talk to you :)
[12:08] <jml> huwshimi: we aren't barbarians
[12:08] <gmb> We aren't?
[12:08] <gmb> Damn.
[12:08] <jml> gmb: I can't speak for anyone north of Islington.
[12:08] <huwshimi> mpt: I'm heading out to lunch, so let's figure out a time later
[12:08] <allenap> gmb: Certainly.
[12:09] <mpt> huwshimi, ok, sorry I was held up with this USC stuff
[12:10] <huwshimi> mpt: No totally fine, we didn't schedule a proper time anyway
[12:10] <huwshimi> mpt: I just didn't want you to be sitting around waiting for me
[12:27] <bigjools> wgrant: still there?
[12:28] <wgrant> bigjools: A bit.
[12:28] <bigjools> wgrant: I am trying to work out wtf is going on in the _create_missing_builds method in the cloner
[12:29] <wgrant> bigjools: Bad things.
[12:29] <bigjools> wgrant: can you work out why it needs to call sourcepackagerelease.createBuild after createMissingBuilds doesn't make any builds?
[12:29] <bigjools> the only place that passes always_create is lib/lp/soyuz/scripts/initialize_distroseries.py:
[12:30] <bigjools> and I would have thought that forcing a build is wrong wrong wrong if there is already a build
[12:32] <wgrant> bigjools: I would tend to agree with your assessment.
[12:32] <wgrant> bigjools: What does annotate say?
[12:32] <bigjools> it smells like StevenK
[12:32] <StevenK> It was me, yes
[12:33] <StevenK> For the case of copying only sources
[12:33] <wgrant> cMB should create builds in that case...
[12:33] <bigjools> but createMissingBuilds ...
[12:33] <bigjools> cMB will always DTRT
[12:34]  * bigjools is tempted to rename SPR.createBuild to SPR._createBuild
[12:34] <StevenK> So, the package cloner only calls cMB in specific circumstances ...
[12:35] <bigjools> it looks like it always calls it
[12:38] <lifeless> night all
[12:38] <wgrant> Night lifeless.
[12:38] <bigjools> nn lifeless
[12:38] <bigjools> StevenK: so why does it call it?
[12:39] <StevenK> I'm struggling to remember
[12:40] <LPCIBot> Project db-devel build #659: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/db-devel/659/
[12:47] <bigjools> rvba: given that none of us know why on earth the cloner is doing that extra call, I would just rely on createMissingBuilds in your code.
[12:48] <rvba> bigjools: Got it.
[13:01] <wallyworld_> wgrant: you still there?
[13:07] <wgrant> wallyworld_: Mostly.
[13:08] <wallyworld_> wgrant: just wondering - lxc doesn't support fuse but rocketfuel-setup tries to install it and it fails
[13:08] <wallyworld_> so i've told rocketfuel not to install launchpad-developer-dependencies and am seeing what breaks
[13:09] <wallyworld_> curious if you saw the same problem
[13:09] <wgrant> wallyworld_: I always change rocketfuel-setup to use 'apt-get install -o Apt::Install-Recommends=no'
[13:09] <wgrant> wallyworld_: Which doesn't install fuse.
[13:09] <wallyworld_> ah. will try that. thanks
[13:10] <wallyworld_> if it works, i can update the wiki
[13:17] <LPCIBot> Project parallel-test build #64: STILL FAILING in 1 hr 18 min: https://lpci.wedontsleep.org/job/parallel-test/64/
[13:18] <wgrant> jelmer: How goes the QA?
[13:19] <jelmer> wgrant: confirmed that the classify-exceptions branch is working with a few imports
[13:22] <jml> hey
[13:22] <jml> what version of Python do we run on?
[13:22] <wgrant> jml: 2.6
[13:22] <jml> sweet
[13:35] <jml> if I have a list of bug ids, is there an efficient way to ask Launchpad which of them are closed?
[13:35] <jml> or am I going to do N roundtrips?
[13:43] <bac> hi bigjools, are you familiar with using WebServiceTestCase?  i'm trying to figure out how to test an @collection_default_content
[13:49] <jml> jelmer: wow
[13:49] <jml> jelmer: I just saw your patch
[13:50] <jml> jelmer: out of curiosity, have you had a chat w/ mwhudson about it?
[13:52] <jelmer> jml: not recently, but we chatted about doing this earlier
[13:53] <jelmer> jml: I'm hoping I can get him to do one of the reviews of the branch if it is deemed a good idea
[13:53] <jml> jelmer: ok. it's kind of a big deal. are you planning on going all the way with this?
[13:53] <jml> (otherwise it's a lot of dead code to be adding)
[13:54] <jelmer> jml: yes, I would be happy to take this all the way
[13:56] <jelmer> wgrant: when is the next deployment happening?
[13:56] <wgrant> jelmer: Whenever your QA is done.
[13:57] <jelmer> wgrant: oh :)
[13:57] <jelmer> I'm still waiting for staging to come back
[13:57] <wgrant> Well, someone (probably me) should probably QA timrc's thing first, to get another couple of revs. But once your stuff is done we can at least deploy *something*.
[13:57] <jelmer> (waiting to see if https://code.staging.launchpad.net/~maxb/cvs2svn/svntest succeeded)
[13:57] <bigjools> bac: not massively familiar with that.  It just gives you a "browser" object doesn't it?
[13:58] <wgrant> jelmer: You know we have an importd on qastaging now, right?
[13:58] <jelmer> wgrant: I do now :)
[13:58] <wgrant> rvba, jtv: When you get a chance, could please take care of your outstanding QA items?
[13:58] <wgrant> jelmer: We got it working earlier this week.
[13:59] <wgrant> Because waiting for staging sucks.
[13:59] <jtv> wgrant: I guess that means my branches have deployed somewhere.  :)
[13:59] <bac> bigjools: you get a web service object you can make method calls on.  that's ok if you're not familiar
[13:59] <rvba> wgrant: Sure.
[13:59] <bac> wgrant: you familiar with WebServiceTestCase?
[14:00] <bigjools> bac: right, I hope it's the client side of things so that lplib is exercised
[14:00] <wgrant> bac: You should be able to just use it like launchpadlib.
[14:00] <bac> wgrant: i
[14:01] <rvba> wgrant: The crazy multi parent branch is fixed if you want to have a look at it one more time ;) (https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676)
[14:01] <wgrant> bac: eg. the collection_default_content of IBuilderSet can be checked using something like list(lp.builders)
[14:01] <bac> wgrant: i'm trying to exercise a method marked with @collection_default_content.  in lplib the top level collection object is callable and invokes that method
[14:01] <bac> wgrant: right
[14:01] <jelmer> wgrant: \o/
[14:02] <bac> wgrant: but the ws_object version of it is not callable
[14:02] <wgrant> bac: The collections should not be callable, AFAIK.
[14:02] <bigjools> they are generators aren't they?
[14:03] <wgrant> Something like that.
[14:03] <wgrant> But they're still not callable.
[14:03] <bac> wgrant: perhaps callable is the wrong term
[14:03] <bac> wgrant: but with an ws_object version of builders i cannot do what you showed earlier from lplib
[14:05] <wgrant> bac: I suspect that wsObject only works on Entries :(
[14:05] <wgrant> But self.service.builders looks like it should work.
[14:05] <wgrant> Maybe.
[14:05] <bac> hmm
[14:06] <wgrant> Yes, that should work.
[14:06] <bigjools> I see that people are adding sourcecode eggs but not deleting old ones :(
[14:06] <bac> wgrant: \0/
[14:06] <wgrant> jelmer: Still going...
[14:06] <bac> wgrant: thanks!
[14:06] <wgrant> bac: Does it work?
[14:07] <bac> indeed
[14:07] <wgrant> I'm pretty sure it will, but you never know.
[14:07] <bac> yes, i just demonstrated it
[14:07] <wgrant> Great.
[14:12] <jml> bigjools: well, you have to be careful about deleting old ones.
[14:12] <bigjools> jml: ECONTEXT
 I see that people are adding sourcecode eggs but not deleting old ones :(
[14:13] <wgrant> If you delete them before the next release, I will be very sad.
[14:13] <wgrant> Because we will be unable to deploy.
[14:14] <bigjools> jml: sure, but do people actually check?
[14:15] <jml> bigjools: I honestly don't know how. And if I did, and cared, I'd probably make a post-commit hook or something that did it for me.
[14:16] <bigjools> the reason I care is because a) I hate having my disk filled with crap, and b) I spent ages cleaning it up not so long ago
[14:20] <bigjools> matsubara: how did the exploratory testing go yesterday?
[14:21] <matsubara> bigjools, I'll put the results in the wiki and ping you
[14:21] <bigjools> great thanks
[14:21] <rvba> wgrant: QA done.
[14:22] <wgrant> rvba: Thanks!
[14:22] <rvba> np
[14:22] <matsubara> flacoste, you mentioned an email about some wiki clean up, but I didn't get any. Did you send it? What's the subject?
[14:22] <bigjools> rvba: presumably it worked then? :)
[14:23] <rvba> bigjools: yes, I'm not an admin on DF anymore :)
[14:23] <flacoste> matsubara: QA wiki clean-up
[14:23] <flacoste> jml was cc-ed
[14:23] <flacoste> jml: did you receive your opy?
[14:23] <jml> flacoste: yes, I did. I haven't had the privilege of talking w/ matsubara yet today
[14:24] <matsubara> jml, flacoste: I didn't receive it. could you resend?
[14:24] <flacoste> matsubara: my bad, my addressbook completed to your old async address
[14:25] <matsubara> flacoste, hmm it should have arrived anyway unless the asyncers disabled my old address
[14:26] <flacoste> matsubara: resent
[14:26] <matsubara> thanks flacoste
[14:27] <flacoste> matsubara: they did:     host smtp.async.com.br [<IP_ADDRESS>]: 550 5.1.1<EMAIL_ADDRESS>User unknown
[14:27] <matsubara> :-(
[14:27] <matsubara> flacoste, got the new copy you just resent. I'll take care of that clean up.
[14:28] <jml> the trick is to get all the QA info grouped together, I reckon
[14:28] <jml> flacoste: Millbank 2439
[14:29] <flacoste> jml: ok, will dial in 2 minutes
[14:29] <jml> :)
[14:32] <jelmer> wgrant: ah, staging and qastaging share their import slave?
[14:33] <jelmer> just got a database lock on staging because of my import run on qastaging
[14:33] <jml> reviewer sought: https://code.launchpad.net/~jml/launchpad/xxx-cleanup/+merge/65663
[14:33] <wgrant> jelmer: They do. I would have hoped they wouldn't share locks, though :(
[15:09] <jcsackett> jml: looking now.
[15:09] <jml> jcsackett: thanks!
[15:20] <timrc> wgrant, did you run into any trouble with my commit?
[15:23] <wgrant> timrc: It is just after midnight. I was planning to QA it tomorrow if nobody had done it by then.
[15:25] <timrc> wgrant, gotcha
[15:25] <jcsackett> jml: r=me.
[15:26] <jml> jcsackett: thanks
[15:32] <jml> lib/canonical/launchpad/pagetests/webservice/apidoc.txt fails for me in stable
[15:34] <jml> anyone else have that?
[15:36] <jml> is there a make target I need to build first?
[15:38] <bac> jml: if you actually change API stuff the make file does not rebuild the wadl
[15:38] <bac> jml: you can either
[15:38] <bac> rm -rf lib/canonical/launchpad/apidoc/
[15:39] <bac> or 'make clean build'
[15:39] <jml> bac: thank you
[15:40] <jml> bac: lib/canonical/launchpad/apidoc doesn't exist :\
[15:45] <jml> ahh ok. I think I know what's going on.
[15:45] <jml> bac: thanks for the pointer.
[15:45] <bac> jml: working?
[15:45] <jml> bac: *maybe*. tests take a while :)
[16:04] <timrc> am I suppose to be able to authenticate with staging.launchpad.net via lynx?  I'm able to login in successfully but then it takes me to a page with nothing but the word 'Continue'.  When I submit again, it eventually takes me to the same page :/
[16:04] <timrc> I'm never presented with a page asking me the level of access I want to grant
[16:05] <jml> timrc: I'm not sure. I don't think lynx is one of our supported browsers.
[16:05] <timrc> jml, poop.  okay... off hand do you know which console browser is supported?
[16:06] <jml> timrc: maybe none of them?
[16:06]  * timrc 's frown deepens
[16:06] <jml> timrc: I don't know where our supported browsers list lives.
[16:06] <jml> timrc: but surely we have to have *some* way of authorizing console apps.
[16:06] <timrc> maybe google knows, brb
[16:08] <timrc> jml, ok according to https://help.launchpad.net/API/launchpadlib lynx is supported for > 1.5.5 and I'm using 1.6.1 hm
[16:09] <jml> timrc: ok. quite possibly it's a bug. can you authorize against production?
[16:09] <timrc> jml, I'll attempt to do so
[16:10] <jml> benji: random thought: would it make sense for exported webservice references to allow 'schema' to be a string containing the fully-qualified Python name for an interface?
[16:11] <timrc> jml, same thing using LPNET_SERVICE_ROOT
[16:12] <jml> :(
[16:12] <jml> timrc: looks like a regression then :\
[16:13] <nigelb> er
[16:13] <nigelb> lynx works
[16:13] <jml> timrc: how can I trick Python into opening lynx to do the auth? (so I can try to reproduce locally)
[16:13] <nigelb> I've used it before
[16:13] <jml> nigelb: well, we know it *used* to work :)
[16:13] <nigelb> jml: yes, as of 2 weeks back when I set up tarmac
[16:14] <timrc> jml, I do not know, honestly... it defaults to lynx for Ubuntu server (probably uses sensible-browser to make that determination)
[16:14] <timrc> nigelb, did you have to setup lynx or did you use default params?
[16:14] <jml> hmm. that'll slow down fixing.
[16:14] <timrc> er config
[16:14] <nigelb> timrc: default
[16:14] <nigelb> jml: sudo update-alternatives --config x-www-browser
[16:14] <timrc> nigelb, okay
[16:15] <jml> nigelb: I'm not changing my default browser just to repro a bug
[16:15] <timrc> jml, hehe
[16:15] <nigelb> hehe
[16:15] <nigelb> You can change it and then change it back :)
[16:15] <timrc> jml, I use vm's to prevent having to do that
[16:15] <jml> !
[16:15] <jml> when I was a lad, we had environment variables
[16:15] <jml> and we used them
[16:15] <jml> and were grateful for them!
[16:16] <nigelb> haha
[16:16]  * timrc did not exist in the 1970's
[16:16]  * timrc ducks
[16:16] <nigelb> neither did I
[16:16] <nigelb> :P
[16:16] <nigelb> if you have a vps, try it on that.
[16:16] <nigelb> it should use lynx by default I think.
[16:26] <benji> jml: that might help with the circular reference problems; zope.dottedname would be an obvious implementation (http://pypi.python.org/pypi/zope.dottedname)
[16:29]  * benji wonders how sarcasm could ever not be good.
[16:29]  * benji also wonders if he'll ever figure out how to use multiple irc chans
[16:32] <timrc> nigelb, you must have the magic touch...
[16:36] <nigelb> timrc: did it work? :)
[16:36] <jml> benji: thanks. I, of course, would have reached for the equivalent Twisted code :)
[16:37] <timrc> nigelb, not in my vm... I'm going to attempt natively... maybe bridged networking has something to do with it (completely unsubstantiated theory)
[16:47] <jcsackett> timrc: i've had problems with lynx before. used elinks and had no problems, though.
[16:47] <flacoste> gary_poster: lp2kanban should sort the tags i think, it's flip-flopping
[16:47] <flacoste> Tags: from lp-translations, timeout to timeout, lp-translations
[16:47] <flacoste> Tags: from timeout, lp-translations to lp-translations, timeout
[16:48] <gary_poster> flacoste, heh, ok, I'll put a card up
[16:48] <jcsackett> timrc: IIRC lynx has an issue with a cookie or something that made it not work for me. but obviously, nigelb and our docs run counter to that.
[16:48] <gary_poster> thanks
[16:48] <timrc> jcsackett, interesting
[16:48] <timrc> jcsackett, I'll give elinks a try
[16:49] <jcsackett> timrc: i ended up really liking elinks and set it up as my default for console browsers.
[16:53] <timrc> jml, okay so you can specify BROWSER="/usr/bin/elinks" python foo.py to select the browser launchpadlib will use
[16:53] <jml> timrc: ahh thanks.
[16:59] <timrc> jcsackett, elinks did the trick... thank you very much
[16:59] <nigelb> jml: okay, so environment variables still work lda ;)
[16:59] <nigelb> *lad
[16:59]  * jml has to go
[17:00] <poolie> cheerio jml
[17:06] <huwshimi> poolie: Who did you send that javascript logging email to yesterday? I never got it.
[17:06] <poolie> hrm
[17:07] <poolie> canonical-tech
[17:07] <poolie> are you on it?
[17:07] <poolie> you should join
[17:07] <cr3> poolie: nice reports on velocity, thanks!
[17:07] <poolie> thanks!
[17:10] <cr3> where are all the yui files listed from lazr-js to generate launchpad.js?
[17:18] <poolie> gary_poster: hello?
[17:18] <gary_poster> hey poolie
[17:20] <poolie> hi there
[17:20] <poolie> i ran one of the performance tools mentioned at velocity on some lp pages
[17:20] <poolie> and it points out that we have some etags on files that don't seem to actually need them
[17:20] <poolie> since they hav ethe revision in the name
[17:21] <poolie> this is really separate from the wadl
[17:21] <huwshimi> poolie: I'm not, I'll join
[17:21] <poolie> is this probably a (Low) bug, or is there a reason for it?
[17:21] <gary_poster> poolie, do you mean "beta" and "1.0" and so on?
[17:21] <gary_poster> oh
[17:21] <gary_poster> you said separate from wadl :-P
[17:22] <poolie> yeah
[17:22] <gary_poster> so which pages do you mean, poolie?
[17:22] <huwshimi> poolie: the link you emailed errors on Launchpad
[17:22] <poolie> sorry to mix it in with this bug
[17:22] <poolie> silly launchpad
[17:22] <gary_poster> :-)
[17:22] <poolie> which link, huw?
[17:22] <poolie> gary_poster: let me see if i can find the tool again
[17:22] <gary_poster> k
[17:22] <huwshimi> poolie: https://launchpad.net/~canonical-tech
[17:23] <huwshimi> poolie: I think it's  404, but Launchpad doesn't really tell me
[17:23] <poolie> works for me
[17:23] <poolie> ah
[17:23] <poolie> it's privtae
[17:23] <poolie> how on earth do you join then?
[17:24] <huwshimi> poolie: heh, no idea
[17:25] <allenap> poolie, huwshimi: One of the list admins has to add you.
[17:25] <huwshimi> allenap: Ah
[17:26] <allenap> huwshimi: I'm trying to find one to ask....
[17:26] <huwshimi> allenap: Thank you
[17:26]  * huwshimi wonders why we 404 when we mean permission denied
[17:28] <allenap> huwshimi: Done (by dragnob).
[17:28] <huwshimi> allenap: Thanks
[17:29] <allenap> huwshimi: It's probably to do with disclosure. Permission denied indicates that the resource exists. Of course, it could just be a bug ;)
[17:29] <gary_poster> huwshimi, generally, some "private" things are really private.  We don't want people to know they exist.  The name's existence is a security leak.  Not everything needs that much paranoia, but starting with paranoia and relaxing is easier than the other way around.
[17:29] <gary_poster> yeah :-)
[17:30] <poolie> so dragnob's a good person to ask?
[17:30] <huwshimi> gary_poster: Ah I see
[17:31] <poolie> it might be nice if there was a "contact the admins if this thing exists"
[17:31] <poolie> but perhaps just mail will do
[17:31] <poolie> gary_poster: i can't reproduce the warning in the tool
[17:31] <poolie> i think it was in gogle page speed
[17:31] <poolie> but, "curl -Ov https://code.launchpad.net/+icing/rev13265/lazr/build/lazr/assets/skins/sam/negative.png
[17:32] <poolie> does show the response has an etag
[17:32] <poolie> and that's apparently a bad idea for resources that ought to be immutable
[17:32] <poolie> since it could be set to just never expire
[17:32] <poolie> i don't know if that actually has any performance impact or if it's just a warning
[17:32] <poolie> but since they mentioned it i was curious
[17:33] <cr3> rockstar: what's this about lazr-js being deprecated? has the superseding package made it to launchpad in sourcedeps perhaps?
[17:34] <gary_poster> poolie, ah!  yeah, agree.  It would have an effect if Apache were set to pay attention to inode for ETag generation, but would be innocuous otherwise.
[17:35] <poolie> btw i'm pretty sure that lazr.restful does try to use the etags
[17:35] <poolie> hrm
[17:35] <gary_poster> poolie, I think it is worth a bug for lazr.js icing
[17:35] <poolie> if i had time i would rip out its persistent object cache
[17:35] <poolie> (leaving the wadl cache)
[17:35] <gary_poster> we are not sure if there is a problem
[17:35] <poolie> it seems to cause bugs without ever helping things
[17:35] <poolie> ok, i'll file
[17:35] <gary_poster> but it's worth a bit of a dig into it anyway
[17:35] <gary_poster> thank you
[17:39] <LPCIBot> Project parallel-test build #65: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/parallel-test/65/
[17:39] <poolie> bug 801241
[17:39] <_mup_> Bug #801241: sends etag on immutable icing resources <Launchpad itself:Triaged> < https://launchpad.net/bugs/801241 >
[17:48] <sinzui> abentley, do you have time to mumble about solution to the yui-segfault issue?
[17:55] <abentley> sinzui: Sure, how about in 15 minutes?
[17:56] <bac> jcsackett: can you do a review at your convenience?  https://code.launchpad.net/~bac/launchpad/bug-776437/+merge/65692
[17:56] <jcsackett> bac: i was just looking at that actually. :-)
[17:56] <sinzui> abentley, that is good thanks
[17:56] <rockstar> cr3, you might want to talk to deryck in the context of launchpad itself, but I don't think the long term plan is for anyone to use lazr-js anymore.
[17:56] <jcsackett> i need to finish up one thing, then i'll take a look at it.
[17:56] <bac> jcsackett: wow, you're a machine
[17:56] <jcsackett> or rather, take a longer look at it.
[17:57] <jcsackett> bac: i just keep on eye on the queue on my OCR days. helps me figure out how i'm breaking up my day. :-)
[17:57] <rockstar> cr3, why do you think you need to use lazr-js?
[17:58] <cr3> rockstar: I'm working on a project that aims to use similar technologies, methodologies, etc. as launchpad: http://ec2-50-18-91-92.us-west-1.compute.amazonaws.com/
[17:59] <cr3> rockstar: so, if launchpad jumps off a bridge then I'll jump too
[18:09] <rockstar> cr3, lp:phazr is an re-implemtation of most of the useful things in lazr-js
[18:10] <cr3> rockstar: this is probably a question for deryck but I'd be curious to know when launchpad intends to migrate from lazr-js to that
[18:10] <abentley> sinzui: ready
[18:11] <LPCIBot> Project db-devel build #660: STILL FAILING in 5 hr 30 min: https://lpci.wedontsleep.org/job/db-devel/660/
[18:12] <rockstar> cr3, deryck said he's in the process now, last time I talked to him.
[18:13] <cr3> rockstar: awesome, I'll keep a close eye on that then
[18:13] <cr3> rockstar: I had another question for you but it turned out to be a bug in yui upstream already reported by sidnei, thanks for the info!
[18:21] <jcsackett> bac: r=me.
[18:21] <bac> jcsackett: thanks
[18:21] <abentley> sinzui: Oh, that third option was: start the browser in a subprocess, but then use that browser process to visit all the pages, e.g. using IPC.
[18:22] <abentley> sinzui: So it's a combination of the other two options.
[18:22] <sinzui> abentley, ah right
[18:23] <bac> jcsackett|lunch: i'll look into that idea
[19:22] <LPCIBot> Project devel build #831: FAILURE in 6 hr 0 min: https://lpci.wedontsleep.org/job/devel/831/
[19:43] <lifeless> moin
[20:07] <lifeless> wallyworld_: the lxc setup on that page supports fuse
[20:07] <lifeless> wallyworld_: what didn't work for you?
[20:36] <sinzui> jcsackett, do you have time to mumble?
[20:36] <jcsackett> sinzui: give me five, and sure. :-)
[20:41] <jcsackett> sinzui: http://people.canonical.com/~jc/images/Details%20Mockups/
[21:03] <bac> hi cr3 -- do you need a hand landing https://code.edge.launchpad.net/~cr3/launchpad/hwsubmissionset_search/+merge/63768
[21:04] <cr3> bac: absolutely, thanks for following up on that branch. is there anything I can do?
[21:05] <bac> cr3: i haven't looked at it in detail yet.  do you think it is ready for ec2 and landing?
[21:06] <cr3> bac: yep, it's been reviewed by lifeless and stub, all changes they suggested have been applied so I'm very comfortable... as if I were wearing a belt and suspenders
[21:06] <bac> cr3: ok.  could i get you to write a 'commit message' on the MP?
[21:08] <cr3> bac: not sure I follow, this is my first contribution to LP
[21:09] <bac> cr3: np.  click on the above link to go to the merge proposal.  towards the top is a JS control "set commit message".  that is the brief description of the branch that will be used as the PQM commit message
[21:10] <bac> so just type a sentence that describes the reason for the branch
[21:14] <cr3> bac: done, let me know if you might word anything differently or if I might be missing special notation
[21:15] <bac> cr3: no special PQM notation any more.  the tools take care of it!
[21:15] <bac> cr3: looks good
[21:37] <lifeless> abentley: hi
[21:37] <abentley> lifeless: hi.
[21:37] <lifeless> bug 690021 - will we get an OOPS when a job runs into the memory limit and fails ?
[21:37] <_mup_> Bug #690021: scan_branches terminated for excessive memory abuse <canonical-losa-lp> <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/690021 >
[21:39] <abentley> lifeless: yes.  Python will raise MemoryError.
[21:39] <lifeless> thanks
[21:39] <abentley> lifeless: np
[22:11] <LPCIBot> Project parallel-test build #66: STILL FAILING in 1 hr 12 min: https://lpci.wedontsleep.org/job/parallel-test/66/
[22:13] <abentley> lifeless: Also, I've done the same for sendbranchmail: https://code.launchpad.net/~abentley/launchpad/memlimit-sendbranchmail
[22:14] <lifeless> abentley: cool
[22:14] <lifeless> this is good stuff
[22:16] <abentley> lifeless: yeah, it's good to reduce the consequences of memory-munching, and AIUI, the bzr team have reduced the memory-munching significantly.
[22:16] <lifeless> I'd kindof like to memlimit the appservers too
[22:16] <lifeless> with python hitting swap is never the right thing (gc languages :()
[22:18] <abentley> lifeless: if you do, make sure that only the process the OOMed is affected, and it's probably a good idea to treat that process as dirty.
[22:19] <abentley> lifeless: i.e. the environment is suspect, and it shouldn't be reused for another request.
[22:20] <lifeless> abentley: pythons MemoryError raising should be fairly reliable, no ?
[22:22] <abentley> lifeless: yes, I haven't seen it fail.  Though even with an RLIMIT_AS of 0, I had to allocate 10 ** 6 bytes to trigger it.
[22:23] <lifeless> I'd certain make the current request bail
[22:23] <lifeless> I don't think we'd need to restart the appserver
[22:24] <lifeless> perhaps I'm wrong and it is more fragile?
[22:25] <abentley> lifeless: The issue with the branch scanner was that a previous OOM was causing the following scan to OOM.
[22:25] <lifeless> abentley: I guess because of slab allocators?
[22:26] <abentley> lifeless: I thought it might be actual memory leaks.  I don't know enough about slab allocators.
[22:26] <lifeless> abentley: so python doesn't call malloc() per object
[22:27] <lifeless> it allocates slabs of various sizes which objects can go into; I'd need to go check the source to be more precise than that
[22:27] <abentley> Oh, the 10**6 because of the slab allocators?  Probably.
[22:27] <lifeless> no, the OOM on the next job
[22:27] <lifeless> so a slab can only be released to the OS when all the objects in it have been freed
[22:28] <lifeless> there may also be an implementation issue with the memlimit - if it just looks at setbrk for instance
[22:28] <lifeless> anyhow - thats a good gotcha to know about
[22:29] <abentley> lifeless: the bug for this was 786804
[23:09] <wallyworld_> lifeless: got lp running in a 32 bit lxc container on my 64 bit os. one pita though - the .so files need recompiling so lp can run but then this stuffs up things outside the container requiring the .so files (like ec2 land). what's the cmd to recompile just the c source?
[23:09] <lifeless> wallyworld_: the eggs are fine, but the things doing build_ext i will give grief
[23:10] <lifeless> wallyworld_: make clean && make build should do it
[23:10] <wallyworld_> lifeless: i've done that but it takes too long. i was hoping for a cmd to just redo the so files
[23:11] <lifeless> wallyworld_: I have a separate tree just for ec2 land
[23:11] <lifeless> wallyworld_: make clean & make build in the sourcecode subdir might work
[23:11] <wallyworld_> thanks. i suspect it will. pita though :-(
[23:12] <michaelh1> Hey, what's the best way of getting a faster launchpadlib at the moment?
[23:13] <lifeless> michaelh1: move to London
[23:14] <lifeless> wallyworld_: thats why I have a separate tree :>
[23:14] <lifeless> wallyworld_: I'd like to move ec2 land etc out of the main tree; they have no business being there
[23:14] <wallyworld_> yes agreed :-)
[23:17] <jelmer> mwhudson: hi
[23:17] <mwhudson> jelmer: hello
[23:17] <mwhudson> jelmer: yes i saw your merge proposals :)
[23:18] <jelmer> mwhudson: heh, ok.. wasn't sure if you'd see them through the floods of Launchpad-related emails :)
[23:42] <lifeless> wallyworld_: so, fuse
[23:42] <lifeless> wallyworld_: why do you think lxc doesn't support it ?
[23:43] <wallyworld_> because of the errors and a google search where one of the devs said so :-)
[23:43] <lifeless> what errors?
[23:43] <lifeless> the config I provided supports fuse
[23:43] <LPCIBot> Project db-devel build #661: STILL FAILING in 5 hr 32 min: https://lpci.wedontsleep.org/job/db-devel/661/
[23:44] <lifeless> wallyworld_: can you msg me your /var/lib/lxc/$containername/config file ?
[23:44] <wallyworld_> trying to install launchpad-dependencies (from rocketfuel-setup) - the package post processing said things like "/dev/fuse cannot be accessed" etc. don't have the specifics handy
[23:45] <lifeless> that suggests you didn't have the right devices whitelisted
[23:45] <lifeless> the config I'm asking for will help diagnose this
[23:46] <wallyworld_> lifeless: https://pastebin.canonical.com/48968/
[23:46] <lifeless> yeah
[23:47] <lifeless> you must have made your container before I added fuse support to the wiki page
[23:47] <wallyworld_> ah right
[23:47] <lifeless> #fuse (workaround for Bug:800886)
[23:47] <lifeless> lxc.cgroup.devices.allow = c 10:229 rwm
[23:47] <lifeless> # part of the Bug:798476 workaround -
[23:47] <lifeless> # remove if you are running a 64 bit lxc or
[23:47] <lifeless> # 32 bit on 32-bit base os
[23:48] <lifeless> lxc.arch = i686
[23:48] <lifeless> add that to your config file
[23:48] <wallyworld_> lp still runs up ok for simple smoke testing. i guess codehosting stuff may be broken without fuse
[23:48]  * wallyworld_ fires up vi
[23:49] <wgrant> wallyworld_: Codehosting works fine without fuse.
[23:50] <wallyworld_> so what part of lp needs it?
[23:50] <lifeless> AFAIK nothing
[23:50] <wgrant> wallyworld_: The test suite passed for me except for a rabbit startup failure (probably because I changed the hostname without fixing /etc/hosts) and a few mailman tests that are an aufs bug.
[23:50] <lifeless> however the stack of things for e.g. windmill and so on may well
[23:50] <wgrant> wallyworld_: Nothing. It's just Recommended by one of the LP dependencies.
[23:50] <lifeless> wgrant: you ran w/out fuse?
[23:50] <wgrant> lifeless: Yes.
[23:51] <wallyworld_> as am i since i couldn't instal lit :-)
[23:51] <wgrant> I couldn't either.
[23:51] <lifeless> right
[23:51] <lifeless> we may want to disable recommends in rocketfuel-setup regardless
[23:52] <wallyworld_> would be a lot quicker to run - fae less downloads
[23:52] <wgrant> Indeed.
[23:52] <wgrant> I've wanted to do so for months, but the review overhead always made me think twice.
[23:52] <wallyworld_> i also had to install aptitude by hand since rocketfuel used that by default
[23:52] <wallyworld_> not sure why
[23:53] <wallyworld_> whereas apt-get works just fine
[23:53] <wgrant> It shouldn't any more...
[23:53] <wallyworld_> since when?
[23:53] <wallyworld_> ah, i was likely using an old copy
[23:53] <wgrant> Possibly, if you copied across your original version.
[23:53] <wgrant> It certainly uses apt-get now.
[23:54] <wallyworld_> yeah, my fault
[23:54] <wgrant> lifeless: So, what kind of hardware are pilinut and pigeonpea?
[23:55] <lifeless> FIIK


[01:01] <bryce_> tjaalton: you around?  I have a question on doing the xserver merge, if I need to have an orig.tar.gz for it?
[01:43] <bryce_> tjaalton: nevermind, sorted it out
[07:12] <ziroday> Hi I'm looking at https://bugs.launchpad.net/ubuntu/+source/hal/+bug/277946 and wondering what more information is needed