[00:10] <wgrant> Were there insufficient goat sacrifices to make it work, or has it just not been done yet? Natty is suspiciously empty.
[00:14] <lifeless> it wasn't qablessed into prod, so we need a cp
[00:15] <wgrant> The disabled arch i-d-s thing? I thought that was CPd along with my disabled arch indices thing.
[00:18] <lifeless> we're talking different things ;)
[01:11] <thumper> so... any movement on the psychopg problem?
[02:00] <thumper> mwhudson: so... I've been thinking about translatePath again
[02:00] <thumper> mwhudson: I think we can safely ignore any path after a branch if it doesn't start with .bzr
[02:01]  * thumper thinks
[02:01] <mwhudson> thumper: do we care about bzr cat lp:launchpad/README not working?
[02:01] <thumper> oh maybe not
[02:01] <thumper> mwhudson: bzr cat -d lp:launchpad README works
[02:01] <mwhudson> (i'm not sure how related that is, actually)
[02:02] <thumper> I think it may break hitchhiker if we do though
[02:02] <thumper> as hitchhiker sits on the transport
[02:02] <mwhudson> thumper: also at one point http requests to loggerhead went through translatePath
[02:02] <mwhudson> not any more though
[02:02] <lifeless> what are you planning?
[02:02] <poolie> thumper: i was wondering if we should bulk-upgrade all the branches on launchpad sometime
[02:02] <poolie> 2a format came in a long time ago now
[02:02] <thumper> lifeless: I'm trying to get better errors from translatePath
[02:03] <thumper> poolie: perhaps...
[02:03] <lifeless> we should definitely bulk upgrade all the import branches
[02:03] <poolie> that'd be a good starth
[02:03] <poolie> however, some others are stacked on them, so it may get a bit complicated
[02:04] <poolie> hello thumper, lifeless, btw
[02:04] <lifeless> a feature scope using % could do that without overload
[02:04] <lifeless> poolie: yes, thats true. OTOH we have that complexity doing any upgrade.
[02:22] <wgrant> We can't ever bulk-upgrade all of Launchpad.
[02:22] <wgrant> That would break everyone's checkouts.
[02:22] <lifeless> wgrant: why?
[02:23] <wgrant> lifeless: Won't the world end if my non-richroot branch's parent becomes rich?
[02:25] <spiv> Perhaps not quite that bad, but it would cause some grief.  People would need to upgrade their local branches to be able to continue to merge or pull from the upgraded remote branches.
[02:25] <wgrant> Yes. And that's unprecedented.
[02:26] <wgrant> Bazaar's format changes suck enough (although it's pretty good now) without hosting services breaking branches without any action from the project owner.
[02:26] <spiv> Hmm, again I think that's too strong a word.  But I agree it's worth thinking about the impact before doing it.
[02:27] <spiv> (It's not unprecedented because many hosted branches have been upgraded without being able to contact every user of that branch, so people have certainly gone through this before, and the world didn't end ;)
[02:27] <wgrant> A Launchpad change means that my Ubuntu 8.04 LTS systems can no longer access my project's branches.
[02:28] <wgrant> My project was perfectly happy using pack-0.92. Nobody asked for it to be upgraded.
[02:28] <lifeless> wgrant: I think upgrading users branches would be rude
[02:28] <lifeless> wgrant: I'm not, and have never proposed that we do that.
[02:28] <lifeless> wgrant: the branches lp 'owns' though, are different IMNSHO
[02:28] <wgrant> Import branches? Sure.
[02:29] <lifeless> wgrant: and, we can certainly (and should) encourage folk to upgrade
[02:29] <lifeless> and make it easy for them to bulk upgrade
[02:29] <wgrant> Definitely.
[02:29] <wgrant> On all counts.
[02:32] <lifeless> wgrant: however, supporting pack-0.92 etc has serious caveats and consequences (like massive memory bloat) for LP
[02:33] <lifeless> wgrant: so we need to do something about that
[02:35] <poolie> lifeless: could you have a look at https://code.edge.launchpad.net/~mbp/bzr/597791-http-tests/+merge/37941
[02:35] <poolie> you don't need to read it line by line but i would like your thoughts on the general idea
[02:35] <poolie> a line-by-line readthrough would be good
[02:38] <lifeless> line 264 is against PEP8 (vertical WS between class: and the docstring)
[02:44] <poolie> :)
[02:44]  * thumper sighs
[02:45] <lifeless> poolie: the tests are a bit opaque
[02:45] <poolie> it's funny you should mention that, doesn't launchpad insist on having vws there?
[02:45] <poolie> ok
[02:46] <lifeless> I think variations.py would benefit from a module docstring with some overview & pointers in it.
[02:46] <lifeless> poolie: no, LP doesn't.
[02:46] <poolie> true
[02:46] <lifeless> [lp follows PEP8 for its docstring conventiions)
[02:47] <lifeless> one thing I can't tell is whether variations append or multiply
[02:48] <lifeless> that is given two variations that return 2 scenarios each
[02:48] <poolie> multiply
[02:48] <poolie> good point though
[02:48] <lifeless> sorry, 3 variations with 3 scenarios is it 6 or 9.
[02:48] <poolie> heh, were you going to compare 2+2 with 2*2? :)
[02:48] <lifeless> yes :P
[02:48] <thumper> any one else seeing: Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
[02:49] <lifeless> thumper: yes, for ages.
[02:49] <thumper> what is it?
[02:49] <lifeless> there was a discussion/bug about it
[02:49] <poolie> you could have [AppendVariations(VaryByFruit, VaryByVegetable), VaryByCookingMethod]
[02:49] <mwhudson> thumper: i saw it on my arm board, of all places
[02:49] <lifeless> there is a test which deliberately triggers it.
[02:49] <poolie> it's a test for handling this in the pyrex bencode
[02:50] <poolie> lifeless: the example of concatenating them kind of points to the fact that if they were plain list-returning callables, you could more simply use itertools etc there
[02:50] <lifeless> poolie: I think this is nice.
[02:50] <poolie> but on the whole i think objects are better
[02:51] <lifeless> theres a  bit of stylistic stuff like 'their_variations' (and variations which isn't usefully different to scenarios really) that might be tweakable
[02:51] <poolie> thanks :) i'm very happy with it
[02:51] <lifeless> poolie: I think multiplying is fine, it lets you do cross product well.
[02:51] <poolie> (which is not to say it can't be improved)
[02:51] <poolie> doesn't multiplication mean cross product?
[02:51] <lifeless> yes
[02:52] <thumper> I'm slightly concerned that `bzr revno lp:~thumper/launchpad/foo` never seems to complete
[02:52] <poolie> right, the by-hand multiplication in test_http was what finally got me around to this
[02:52] <lifeless> poolie: I'd really consider using __call__ - that is, having the objects be factories.
[02:53] <poolie> rather than .scenarios()?
[02:53] <lifeless> poolie: and rather than variations, perhaps 'scenario_factories'
[02:54] <lifeless> writing that makes me wonder if instead, just a helper function which gets the scenarios would be better
[02:54] <lifeless> scenarios = multiply_scenarios(VaryByHttpClientImplementation(), VaryByHttpProtocolVersion())
[02:55] <poolie> that would be a bit more explicit
[02:55] <poolie> hm
[02:55] <poolie> bit of a question there about just when it's going to be evaluated
[02:55] <poolie> which may matter wrt registries etc
[02:55] <poolie> that is, at module load time vs later
[02:56] <poolie> of course multiply_scenarios could return a lazy multiplier
[02:56] <poolie> https://bugs.edge.launchpad.net/testscenarios/+bug/658044
[02:56] <_mup_> Bug #658044: want declarative per-test-class variations <testscenarios:New> <https://launchpad.net/bugs/658044>
[02:56] <lifeless> poolie: that sounds nice
[02:56] <lifeless> poolie: (lazy evaluator)
[02:57] <poolie> in that case i'd probably name it like an object, rather than something that sounds imperative
[02:57] <lifeless> poolie: I think there would be less code, and one less class attribute (no need for .variations)
[02:57] <lifeless> poolie: agreed (naming)
[02:57] <poolie> MultiplyScenarios(...)
[02:57] <poolie> does it support .scenarios now?
[02:57] <spiv> thumper: FWIW the test that triggers the __subclasscheck__ warning is suppressed in bzr trunk
[02:57] <lifeless> poolie: ues
[02:57] <lifeless> poolie: yes.
[02:58] <poolie> ah ok
[02:58] <lifeless> 'TestWithScenarios'.
[02:58] <spiv> Or rather, the warning is suppressed, the test is still there :)
[02:58] <poolie> i looked for that in bzr but not in testscenarios
[02:58] <poolie> that sounds better then
[02:59] <poolie> perhaps we should depend on that at some point
[03:00] <lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/testcase.py
[03:00] <poolie> ah i see, this is a bit different to bzr
[03:01] <lifeless> this is an optional helper
[03:01] <lifeless> for doing lazy expansion
[03:02] <lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/scenarios.py is the guts
[03:02] <lifeless> http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head:/lib/testscenarios/scenarios.py#L61 specifically.
[03:04] <poolie> so in that code, using generators would perhaps fit more naturally
[03:12] <thumper> spiv: so a daily build soon should fix it?
[03:13] <thumper> spiv or poolie: could one of you skype so I can explain a problem?
[03:13] <spiv> thumper: even a build of 2.3b2 should
[03:13] <thumper> spiv: which is found where?
[03:13] <spiv> I can skype, give me a moment to grab the headset.
[03:15] <thumper> spiv: I have bzr-nightly-ppa and bzr-beta-ppa and no 2.3b2
[03:19]  * spiv wonders why skype is having trouble logging in
[03:19] <spiv> thumper: yeah, I don't think we have anyone spending time to keep the PPAs fully up to date atm.
[03:19] <spiv> Ah, now it's connected.
[03:19] <thumper> spiv: you know we have recipes now right?
[03:21] <thumper> spiv: https://pastebin.canonical.com/38472/
[03:27] <poolie> are you guys ok together?
[03:32] <lifeless> poolie: yes, they have a room

[03:36] <poolie> lifeless: is there cross-product code already in testscenarios?
[03:42] <lifeless> no, there is in bzr and it should be trivially portable
[03:42] <lifeless> or even usable from bzr
[03:42] <poolie> right
[03:42] <poolie> wfm, thanks
[04:00] <thumper> $ bzr revno sftp://bazaar.launchpad.net/~thumper/launchpad/foo
[04:00] <thumper> bzr: ERROR: Not a branch: "sftp://bazaar.launchpad.net/~thumper/launchpad/.bzr/branch/".
[04:00] <spiv> lftp bazaar.launchpad.net:/> cat ~thumper/launchpad/.bzr/branch/location
[04:00] <spiv> cat: Access failed: No such file: u'/.bzr/branch' (~thumper/launchpad/.bzr/branch/location)
[04:28] <thumper> spiv: I'm watching a bzr process take up 2.5 gig of ram
[04:28] <thumper> spm: as a result of that local test
[04:29] <spiv> thumper: congratulations
[04:29] <spiv> thumper: you obviously have a fair bit of ram ;)
[04:29] <thumper> 4 + 8 swap
[04:29] <spiv> thumper: what operation is triggering this?
[04:30] <spm> thumper: ? I assume that was really aimed at sp4 vs sp1000?
[04:30] <thumper> spiv: not sure
[04:30] <thumper> spiv: well, the revno call
[04:31] <thumper> spiv: the BzrDir.open_branchV3
[04:31] <thumper> spiv: call to the server
[04:31] <thumper> spiv: pretty sure it was the 'lp-serve', u'--inet' one that was not stopping
[04:32] <spiv> thumper: related to the recursion them?
[04:32] <spiv> s/them/then/
[04:33] <thumper> yep
[04:35] <thumper> spiv: is there a way to break into the bzr process?
[04:35] <thumper> spiv: I have the pid
[04:35] <thumper> it is in the loop now
[04:35] <thumper> currently at 2.2 gig of ram and growing
[04:35] <spiv> thumper: SIGQUIT is one option, gdb is another
[04:36] <thumper> spiv: what number is siq quit?
[04:36] <spiv> SIGQUIT would be my first choice in this case
[04:36] <spiv> Ctrl-\
[04:36] <spiv> kill -QUIT
[04:36] <spiv> Pick your poison :)
[04:36] <spm> spiv: kill -DIEDIEDIEDIEDIE ?
[04:36] <thumper> in the debugger
[04:37] <thumper> hmm...
[04:37] <thumper> how can I bring the debugger to the foreground?
[04:37] <spiv> spm: that's a lot of "IE DIED" ;)
[04:38] <spiv> thumper: oh, hmm
[04:38] <spiv> With --inet?  That does seem tricky.
[04:38] <spm> spiv: some things need to be stabbed with flaming scissors while running, for extra died.
[04:38] <spiv> Hmm, I bet we can do better there.
[04:39] <thumper> hmm...
[04:39] <thumper> doesn't seem to be in the debugger at all
[04:39] <thumper> still in a tight loop
[04:39] <thumper> seems to be stable around 2.6gig of ram though
[04:39] <thumper> FWIW
[04:40] <thumper> mwhudson: got a minute for some gdb help?
[04:40] <spiv> thumper: I'd resort to gdb at this point
[04:40] <mwhudson> thumper: ok
[04:40] <thumper> mwhudson: I've killed the process, but I can regenerate at will
[04:41] <mwhudson> thumper: run gcore $pid
[04:41] <mwhudson> thumper: then follow the instructions on https://code.edge.launchpad.net/~pygdb-hackers/pygdb/trunk
[04:43] <spiv> I think just 'bt' on maverick system would be a great start in this caes
[04:43] <spiv> gdb on maverick has shiny new python smarts.
[04:43] <thumper> I've not used gdb in years
[04:45] <spiv> thumper: do you have a core file or running process?
[04:45] <spiv> thumper: gdb -c CORE; or gdb -p PID
[04:45] <thumper> $ gcore 1338
[04:45] <thumper> core.6f7KUY:1: Error in sourced command file:
[04:45] <thumper> ptrace: Operation not permitted.
[04:45] <thumper> gcore: failed to create core.1338
[04:45] <spiv> (I usually work with running processes)
[04:45] <spiv> Oh, right, maverick...
[04:46] <thumper> ptrace: Operation not permitted.
[04:46] <thumper> ?
[04:46] <spiv> there's a maverick setting you need to change
[04:46] <spiv> to relax a security setting
[04:46] <spiv> I forget what it is, but if you try to attach e.g. strace to a running process it helpfully reminds you.
[04:47] <spiv> /etc/sysctl.d/10-ptrace.conf I think?
[04:48] <spiv> echo 0 | tee -a /proc/sys/kernel/yama/ptrace_scope
[04:48] <spiv> (the latter will relax it until the next reboot)
[04:49]  * thumper has a core file
[04:50] <spiv> Ok, "gdb -c COREFILE"
[04:50] <spiv> then "bt"
[04:50] <spiv> And pastebin that; that is hopefully enough in this case.
[04:51] <spiv> Otherwise time to play with mwhudson's stuff I guess :)
[04:51] <thumper> spiv: nothing useful at all
[04:52] <thumper> spiv: http://pastebin.ubuntu.com/510610/
[04:52] <spiv> thumper: pastebin?  gdb in maverick ought to be including Python function names automatically now.
[04:53] <spiv> Oh wow, I guess you don't have python2.?-dev installed
[04:53] <spiv> Or, hmm.
[04:53] <spiv> -dbg
[04:53] <thumper> mwhudson: pygdb.mi.GdbError: No symbol table is loaded.  Use the "file" command.
[04:53] <thumper> spiv: I do have python2.6-dev installed
[04:53] <spiv> Yes, python2.6-dbg
[04:53] <spiv> For the debug symbols
[04:53] <thumper> ah
[04:54] <thumper> do I need a new core?
[04:54] <thumper> or just install dbg and try again?
[04:54] <spiv> Yep
[04:54] <spiv> Just install dbg and look at the core file again
[04:54] <thumper> yep to what?
[04:55] <thumper> 52s to go
[04:56] <spiv> Time for Dunedin to get a second wet string to the rest of the internet?
[04:56] <thumper> spiv: no change
[04:57] <thumper> should I have python-gdbm-dbg installed?
[05:00] <spiv> No, unless you really care about getting extra details in tracebacks involving the 'gdbm' module
[05:00] <spiv> (So, no.)
[05:00] <thumper> spiv: I'm not getting anything useful with gdb
[05:00] <spiv> Does gdb say anything about 'loading symbols'?
[05:01] <spiv> Or it is verbatim the same output?
[05:01] <thumper> spiv: same output
[05:01] <mwhudson> then it's not finding the debug symbols somehow
[05:01] <thumper> spiv: perhaps it needs the symbols when generating the core file?
[05:02] <spiv> thumper: no, very much not the case
[05:02] <mwhudson> thumper: when you run gdb /usr/bin/python2.6
[05:02] <mwhudson> do you get a message like:
[05:02] <mwhudson> Reading symbols from /usr/bin/python2.6...Reading symbols from /usr/lib/debug/usr/bin/python2.6...done.
[05:02] <thumper> Reading symbols from /usr/bin/python2.6...Reading symbols from /usr/lib/debug/usr/bin/python2.6...done.
[05:02] <thumper> yes
[05:02] <spiv> Ok
[05:03] <spiv> Now with that gdb process try typing "core core.1338"
[05:03] <thumper> ok
[05:03] <thumper> oh... lots of stuff
[05:04] <spiv> (It seems pretty weird that 'gdb -c CORE' is failing to load debug symbols that gdb normally finds, but so long as we can workaround it I guess we just shrug our shoulders...
[05:04] <spiv> )
[05:04] <thumper> so, can I get the contents of bt to a file?
[05:04] <thumper> there is a lot of stuff there
[05:06] <spiv> Probably, but I'd have to spend too many minutes reading gdb docs to figure it out :/
[05:08] <lifeless> spm: hey
[05:09] <lifeless> spm: do you have any word on where the restrictedlibrarian ticket is up to ?
[05:09] <thumper> spiv: actually, I could paste the first 300 levels of the stack :)
[05:09] <spiv> thumper: sure :)
[05:12] <thumper> spiv: http://pastebin.ubuntu.com/510619/
[05:13] <thumper> spiv: perhaps that makes sense to you :)
[05:16] <spiv> thumper: it's recursing during the str-ification of a NotBranchError
[05:16] <spiv> In a way that tries to open a branch
[05:16] <spiv> And causes another NotBranchError...
[05:16] <spiv> For added confusion, it's happening in a Deferred callback chain.
[05:17]  * thumper facepalms
[05:17] <thumper> spiv: bzr error or lp error?
[05:17] <thumper> spiv: or screwy interaction?
[05:18] <spiv> Screwy interaction, I think :(
[05:18] <spiv> bzr error is definitely part of it.
[05:18] <spiv> NotBranchError(..., detail=None, bzrdir=a_bzrdir) calls a_bzrdir.open_repository during string formatting
[05:19] <thumper> spiv: why?
[05:19] <spiv> Which in this case is presumably triggering a NotBranchError, via a fairly long chain of events.
[05:19] <thumper> to format the error?
[05:19] <spiv> So it can add "location is a repository" to the error message, as a hint to the user
[05:19] <thumper> in this case there is no repository with the bzrdir
[05:19] <spiv> So that someone that tries e.g. 'bzr branch PATH_TO_SHARED_REPO' gets a helpful error
[05:20] <spiv> I'll fix the bzr bug for that right now, it's pretty shallow.
[05:20] <spiv> I'm not sure if LP should do anything differently, actually.
[05:20] <thumper> yeah
[05:20] <thumper> I'm not sure what we would do
[05:21] <thumper> it then seems that python spins somewhat
[05:21] <thumper> when it has hit its limit
[05:21] <spiv> Well, it's doing nasty things
[05:22] <spiv> Like capturing a lightly-strified copy of the entire call stack
[05:22] <spiv> As part of the Twisted callback error handling
[05:23] <thumper> really?
[05:23] <thumper> that sounds kinda icky
[05:23] <spiv> It is a bit :/
[05:23] <thumper> is that twisted?
[05:23] <thumper> or us?
[05:23] <spiv> Hmm
[05:23] <spiv> That's Twisted.
[05:24] <spiv> So I wonder why NotBranchError in the first place.
[05:24] <spiv> And/or, why a_bzrdir.open_repository() would raise NotBranchError
[05:24] <thumper> spiv: could be in the translate path?
[05:24] <thumper> maybe?
[05:25] <spiv> Yeah
[05:25] <spiv> Is it raising NotBranchError itself at any point?
[05:25] <thumper>  self.assertRaises(
[05:25] <thumper>             errors.NotBranchError,
[05:25] <thumper>             BzrDir.open_containing_from_transport, transport)
[05:26] <spiv> Well, that seems fine.
[05:26] <spiv> That's a bzrdir method.
[05:26] <spiv> If a VFS method ever raised it, that would be a problem I think.
[05:27]  * thumper steps out for a minute
[05:27] <spiv> bzrlib's open_repository etc only expect the filesystem to raise filesystem errors, like NoSuchFile and PermissionDenied
[05:27] <spiv> if the filesystem ever raised something like NotBranchError I can understand it getting confused.
[05:34] <thumper> spiv: ok, so should I file a bug for any LP bits?
[05:35] <spiv> thumper: I can't think of anything specific enough
[05:36] <spiv> I did a quick grep and don't see any obvious culprits in the LP code
[05:36] <spiv> The full backtrace, all 1000 frames of it, presumably would tell us.
[05:36] <spiv> If you want to stick "sys.setrecursionlimit(150)" somewhere and regenerate the backtrace, that might be helpful
[05:37] <spiv> Hmm
[05:38] <spiv> If I make a fake bzrdir that raises NotBranchError('path', bzrdir=fake_bzrdir) I get the recursion
[05:39] <spiv> But it copes fairly gracefully
[05:39] <spiv> i.e. stringifying it just gives NotBranchError: <unprintable NotBranchError object>
[05:39] <thumper> hmm..
[05:46] <spiv> Oh, *nice*
[05:46] <spiv> It's Twisted's fault
[05:47] <spiv> Specifically, I think it's the fault of it's "safe_repr" function
[05:48]  * spiv looks more closely
[05:49] <spiv> Oh, no, it's not, phew.  But then why...?
[05:50] <spiv> Ok, so:
[05:50] <spiv>  1) I know that NotBranchError.__str__ can recurse when bzrdir.open_repository raises another NotBranchError
[05:51] <spiv>  2) I don't know why that causes an infinite loop rather than just a recursion error
[05:51] <spiv> I can fix 1)
[05:51] <spiv> But 2) is presumably still an issue in the codehosting server, and will still be lurking to bite us later.
[05:52] <spiv> Unfortunately I think it will take a fair bit of patience to debug 2)
[05:52] <spiv> So I'll fix 1) to avoid recursing
[05:52] <spiv> But it may just change your problem, rather than fix it.
[05:55] <thumper> that's a start
[05:56]  * thumper has dinner on the table
[05:56]  * spiv hmms again.
[05:57] <spiv> Oh, right, it's something like:
[05:57] <spiv> a bad error handler that can infinite loop
[05:57] <spiv> Because str(err) is raising an error
[05:57] <spiv> Which in turn trips the error handler
[05:57] <spiv> which does str(err)
[05:57] <spiv> etc
[05:58] <spiv> The question is "where is the error handler"
[06:00] <spiv> It's not that NotBranchError is particularly special
[06:00] <spiv> Except that it happens to be one of the few errors that can trigger more VFS accesses during formatting.
[06:00] <spiv> The exact error doesn't matter.
[06:13] <spiv> thumper: https://code.edge.launchpad.net/~spiv/bzr/notbrancherror-recursion-2.2/+merge/38094
[06:13] <spiv> thumper: I'd be very interested to know what happens if you apply that patch locally
[06:29] <spm> lifeless: #41379: HA upload configuration for librarian please. ??
[06:29] <_mup_> Bug #41379: partitioning in Polish: explain what K, B and F are <partman-target (Ubuntu):Invalid> <https://launchpad.net/bugs/41379>
[06:53] <lifeless> spm: yes, please do
[06:54] <lifeless> spm: [though perhaps I misunderstand your question :P]
[06:54] <spm> heh, was just identifying if that was it
[06:55] <lifeless> spm: oh, no. thats not the thing I was asking about
[06:55] <lifeless> spm: 41202
[06:57] <spm> ah right. different one. looks like it's been purty much suspended being worked on since the last update at the end of september. which given I've spent maybe 15mins on non ZOMG RT tickets in the past.... month, sounds about right.
[06:58] <lifeless> spm: its zomg in its own way
[06:59] <spm> 90+ is zomg. 89... isn't. :-)
[07:27] <poolie> lifeless: the problem with directly using a generator or similar in .scenarios is the hidden cursor within it will be shared across all the instances...
[07:27] <poolie> perhaps for things that have to be lazy we can just make it a callable that gives back an iterable
[07:28] <poolie> actually->#bzr
[08:36] <poolie> here's an interesting factoid: duplicity backups to s3 are about 5x faster with ssl turned off
[08:36] <poolie> this is pretty much just pumping bulk data intercontinentally
[09:04] <bigjools> morning all
[09:04] <wgrant> Morning.
[09:15] <mrevell> Morning
[10:48] <jml> mrevell: hi
[11:34] <stub> Is the topic out of date, or are we still having test failure issues in stable?
[11:49] <jml> I don't know.
[11:50] <jml> what's wrong with this commit message?
[11:50] <jml> All lines of log output:'Commit message [[release-criticial=bigjools][r=jml][ui=none][bug=574083] Merge fix\n\tfor branch-distro script] does not match commit_re [(?is)^\\s*\\[(?:release-critical=[^\\]]+)\\]\\s*\\[rs?=[^\\]]+\\]]'
[11:51] <jelmer_> jml: criticial?
[11:51] <bigjools> lol
[11:51] <jml> jelmer_: thanks.
[11:51] <bigjools> if I had a penny every time I did that
[13:08] <wgrant> bigjools: \o/ killing partner
[13:38] <maxb> Anyone feel like discussing what I should do in an odd vcs-imports reviewing situation? The problem is that someone asked for a debian packaging branch to be imported rooting the branch inside the "debian" directory -- so I "fixed" it.
[13:38] <maxb> But, then they emailed me saying they needed it otherwise because of bzr-builder infelicities
[13:39] <maxb> I "fixed" it because there is another branch on Launchpad built on the history with it imported the way I fixed it to.
[13:40] <wgrant> Isn't that bzr-builder thing fixed now?
[13:40] <wgrant> Maybe it's not deployed on LP yet.
[13:41] <wgrant> But that may mean that you can just ignore than for four days and then tell them to use the new bzr-builder feature.
[13:41] <wgrant> s/than/them/. what happened there, I wonder...
[13:41] <jelmer> As far as I know the nest-part fix has landed on Launchpad.
[13:42] <maxb> Ah, has it made it out as part of the new qa-blessed frequent rollouts?
[13:43] <wgrant> The UI support may have.
[13:44] <wgrant> But the slave support needs a new bzr-builder in some PPA somewhere.
[13:45] <jml> I discovered the ArchiveAdministration page today
[13:46] <wgrant> Uhoh.
[13:46] <wgrant> Do you like all the workarounds?
[13:46] <jml> well, I haven't read it in detail
[13:47] <jml> but how pleasant to have a list of all the major use cases of an important component of Launchpad
[13:47] <jelmer> maxb: I don't think it can be used in production yet, but it should be in a reasonable period of time.
[13:48] <maxb> I've sent email to the user suggesting the import remain in the form I fixed it to and requesting any followup discussion proceed on launchpad-users
[13:49] <maxb> jelmer: I'd welcome your thoughts on the oldest two vcs-imports in Pending Review state - I've looked at them and put an initial comment in the branch whiteboards
[13:51]  * jelmer takes a quick look before lunch
[13:52] <jelmer> maxb: the iceplayer one appears to've been recreated - did you take a look at it recently?
[13:52] <maxb> 20101011 maxb The origin repository is bizarrely structured. I'm not sure there's a meaningful way to import this as a branch, but it's hard to say for sure given the origin repository only has one revision.
[13:53] <jelmer> maxb: In that case, it doesn't really look all that bizarrely structured to me :-)
[13:53] <jelmer> the version directory directly under trunk is a bit strange, but not too unusual
[13:54] <maxb> jelmer: if you go up a level, and look under /unstable, they have a version directory there too
[13:54] <maxb> If the upstream people continue to do that, the vcs-import would end up being the equivalent of importing multiple versions into one tree
[13:55] <jelmer> maxb: For the jupiter branch, I agree that a root-level import doesn't make sense if we're already importing jupiter-current (apart from any other issues we might have with top-level root directories)
[13:55] <jelmer> maxb: fair enough; it's hard to tell with just one revision though.. can you perhaps one of the lp-code developers?
[13:56] <maxb> perhaps what one of the lp-code developers? :-)
[13:57] <jelmer> maxb: Sorry, I meant /ask/ one of the lp-code developers
[13:57] <maxb> right :-)
[13:57] <jelmer> anyway, lunch!
[15:45] <LPCIBot> Project devel build (102): STILL FAILING in 3 hr 50 min: https://hudson.wedontsleep.org/job/devel/102/
[15:48] <cr3> how can I set someone as administrator of a team when there are no administrator yes/no radio buttons when attempting to modify the person within the team?
[16:13] <jml> bigjools: do you know of any existing diagram kind of like this one: http://people.canonical.com/~jml/soyuz-system-diagram.jpg?
[16:15] <bigjools> jml: there is something, one sec
[16:16] <jml> bigjools: I'm talking to the new Ubuntu release manager, who's keen to understand how all everything fits together
[16:17] <bigjools> I think it's on the old internal wiki
[16:21] <bigjools> jml: and I can't find it :/  I remember cprov doing something
[16:21] <jml> bigjools: what about the thing you did for the 2008 Epic?
[16:21] <bigjools> jml: out of date but might help
[16:22] <jml> bigjools: is that on the net?
[16:22] <bigjools> it's a google doc
[16:22] <bigjools> I'll invite you
[16:28] <bigjools> jml: aha!    the presentation has got cprov's diagram embedded
[16:29] <jml> bigjools: got a link?
[16:29] <jml> oh email
[16:29] <bigjools> jml: you will get email
[16:32] <jelmer> jml: Is it public yet who the new Ubuntu release manager is?
[16:34] <jml> jelmer: Yes. Kate Stewart, aka skaet.
[17:11] <jml> can these bugs be closed now? https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=partner
[17:12] <bigjools> jml: no
[17:13]  * bigjools reminds jelmer to set bugs "in progress" ...
[17:13] <jelmer> bigjools: sorry, I'm on it.
[17:13] <bigjools> jml: I did it for you
[17:13] <bigjools> jelmer:  even
[17:18] <jml> I have to go. See you all tomorrow.
[17:21] <jelmer> Enjoy your evening jml.
[17:54] <bigjools> good night all
[19:22] <lifeless> moin
[19:27] <lifeless>           https://dev.launchpad.net/Getting
[20:03] <maxb> Who is in charge of bzr-buildder in *-cat-lpbuildd ?
[20:04] <lifeless> interesting question
[20:04] <lifeless> cat is the sysadmin archive, so strictly them; but perhaps you mean 'who is responsible for updating it when needed' and that would be, AFAIK, the launchpad team.
[20:05] <maxb> Mainly I'd like to find out why maverick has 0.3.1 but lucid 0.2
[20:07] <lifeless> I'd guess at oversight. I think abentley has been doing a lot in this area recently, he may know.
[20:16] <lifeless> losa ping
[20:16] <lifeless> https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/304/steps/shell_7/logs/summary
[20:16] <lifeless> xvfb startup failures :(
[20:47] <bdmurray> lifeless: there is an issue getting private bug attachments via the API right?
[20:50] <lifeless> theres an intermittent issue that is being intransigent
[20:51] <lifeless> we want to deploy the token based approach asap but we're starved for LOSA time at the moment.
[20:51] <lifeless> if its not intermittent, please comment on the bug how to reproduce reliably.
[20:51] <bdmurray> I've been seeing the following: httplib2.ServerNotFoundError: Unable to find the server at lplibrarian.internal
[20:51] <bdmurray> lifeless: which bug is that?
[20:51] <lifeless> bdmurray: iz in malone somewhere ;P
[20:52] <lifeless> bdmurray: oh, private bug attachments are DC only too, for now.
[20:52] <bdmurray> lifeless: is there a timeline for fixing that?
[20:53] <lifeless> bdmurray: yes, asap. (Its been asap for a month)
[20:53] <lifeless> bdmurray: its the highest equal RT ticket we have open.
[21:07] <lifeless> bdmurray: it has been a very busy month though
[21:19] <lifeless> bbs
[21:20] <mwhudson> morning
[21:24] <bdmurray> lifeless: well sure, I was just wondering if it'd be this week, this month or ...
[21:24] <thumper> morning
[22:00] <thumper> lifeless: how often is https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html updated?
[22:20] <lifeless> thumper: 5 minutes I think
[22:20] <lifeless> thumper: I've asked urshina to run it as often as possible
[22:21] <lifeless> bdmurray: I wish I knew
[22:21] <thumper> lifeless: ok
[22:59] <wallyworld> morning
[23:26] <poolie> thumper: i'm saying, just once, in the code that runs there
[23:26] <poolie> register_transport('lp:///', ....)
[23:26] <poolie> then on the server side, any attempts to access that will be seen as having the right url, but they can be implemented differently
[23:54] <thumper> wallyworld: morning
[23:54] <wallyworld> yello


[00:36] <ralsina> Chipaca: like dobey said, known problem, not gotten around to it yet + freezes + need design input ++++


[00:07] <racarr_> Hmm if I was smart I would have first ported MirSurface and MirScreencast to MirBufferStream in an independent MP before adding the surfaceless buffer stream type....
[00:07] <racarr_> and if I was really smart I would probably do that now even though it involves repeating some work
[00:07] <racarr_> :(
[00:07] <racarr_> lol
[01:04] <racarr_> about EOD...
[01:05] <racarr_> Morning duflu :)
[01:16] <duflu> racarr_: Hmm, already?
[01:16] <duflu> racarr_: Hello!
[02:15] <greyback_> duflu_: hey, since I'm up rather late hacking on multimonitor, I'll definitely miss our catchup later on
[02:16] <duflu_> greyback_: Fair enough. I do have a fun WM branch that is usable but it's not pretty enough to propose yet
[02:16] <duflu_> Started down the slippery slope of "hey it's easy to implement all WM at once" without breaking it up
[02:17] <greyback_> duflu_: ok, well we're still stuck with single surface apps just yet, so we need to fix that
[02:17] <greyback_> and all those surface types need to be connected up in qt/gtk...
[02:18] <duflu> greyback_: I'm working on surface states right now. The types work (parenting?) I have deferred to the rest of the team since my proposals were voted down
[02:18] <greyback_> grand so
[02:18]  * duflu looks up Irish vernacular
[02:19] <greyback_> loosely translates to "fair enough"
[02:19] <duflu> greyback_: grand so
[02:19] <greyback_> :)
[02:20] <duflu> greyback_: There's our catchup done. Go sleep
[02:20] <mikodo> I would like to see Mir be developed with it's own feature of inversing the display.(Independant of X or Xmir with "Xcalib" or by using compositors like Compiz and Kwin).
[02:20] <greyback_> duflu: brain still buzzing
[02:21] <duflu> mikodo: That's actually trivial to do in a fragment shader. Only a little messy right now for Mir to switch shaders on the fly. But we'll improve that
[02:21] <duflu> red = 1 - red; green = 1 - green ...
[02:21] <mikodo> duflu, Thanks. I remain hopefull for iths
[02:22] <duflu> mikodo: Although Unity8 replaces most of that so such features would have to be requested from each shell
[02:23] <mikodo> duflu, Here's hoping for it ... Thanks
[02:24] <duflu> mikodo: When and if I get to implementing dynamic shader switching I'll make that the first test case, for the Mir demo shell at least. You'd have to request it from Unity8 separately
[02:24] <mikodo> duflu, hmm, where
[02:24] <duflu> mikodo: https://bugs.launchpad.net/ubuntu/+source/unity8/+filebug
[02:25] <mikodo> duflu, When should I ask
[02:26] <greyback_> mikodo: right now, so we can keep it in mind, with other a11y features like zoom, high contrast, etc
[02:26] <duflu> mikodo: Whenever you like. Worst case is they will say "never". But ideally it will get logged as an enhancement for future
[02:26] <duflu> mikodo: greyback_ is the Unity8 man
[02:26] <duflu> And needs sleep
[02:26] <mikodo> duflu, Thank you. Alright.
[07:19] <duflu> That's annoying. The only Nvidia low-profile fanless cards that fit in my system are still the old 210's
[07:19] <duflu> Although a 610 with a fan will fit
[10:08] <duflu> alf__: Also software cursor during zoom FTW (Super+mousewheel)
[10:17] <alf__> duflu: indeed
[10:17] <duflu> alf__: Between zoom and rotation it's easy to see the renderer/compositor needs to speak up when software cursors are needed
[15:45] <seb128> hey there
[15:45] <seb128> question for you ;-)
[15:45] <seb128> how work does Mir support multimonitor atm, is there work planned for that already/if so where are the specs/details?
[15:46] <seb128> things like geometry of the monitor, their respective position, having a primary monitor concept, etc
[15:46] <seb128> equivalent to xrandr apis to change those
[15:48] <alan_g> seb128: there is some basic support. See examples/example_display_configuration_policy.h but it is currently left to the shell to implement any logic around it
[15:49] <seb128> alan_g, thanks
[15:50] <seb128> alan_g, that file doesn't have a lot, it suggests that the option are mirror or side-by-side?
[15:51] <seb128> I guess no way to do like in xrandr atm, define position, like one monitor on top of the other one?
[15:52] <kdub> there is... "mirout"
[15:52] <alan_g> seb128: something would have to implement a cleverer policy that the proof-of-concept examples there
[15:52] <seb128> kdub, alan_g, are what is currently supported and what is planned documented somewhere?
[15:52] <seb128> the cleverer policy is mir work? or shell/unity8 one?
[15:55] <alan_g> libmirserver supports mirroring. There's an example that also supports sidebyside and single display to prove other options are possible.
[15:56] <alan_g> We don't have any other options in our "backlog" AFAIK - but...
[15:57] <anpok> alan_g: hm i think seb128 means free placement of outputs and resolution changes per output..
[15:57] <anpok> during runtime ..
[15:57] <kdub> we can do that
[15:57] <kdub> on mesa
[15:59] <seb128> it means that it should be working/we could write a configuration UI for unity8-desktop-next?
[15:59] <seb128> like do the same current desktop do
[15:59] <seb128> allow to move monitors on the left/right/top/bottom, change their resolution, define which one is primary, etc?
[15:59] <seb128> mir supports it and client apis are there?
[16:00] <seb128> kdub, ?
[16:00] <alan_g> kdub: isn't http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga89043c48c15e7a020619fdd80e6a46dc etc session local?
[16:02] <alan_g> I mean  mir_connection_apply_display_config() applies to the current session, not to the desktop env
[16:02] <kdub> alan_g, yes, iirc, it applies to the current session
[16:02] <seb128> what's the difference between current session and desktop env?
[16:03] <alan_g> seb128: the session belongs to a client application
[16:05] <seb128> like unity8?
[16:06] <alan_g> seb128: like camera
[16:06] <seb128> hum, how that works?
[16:06] <seb128> usually you configure your monitor setup as you wish your config to be and stay
[16:07] <seb128> like external 24" on the left, laptop on the right
[16:07] <seb128> and something apply that config on start
[16:07] <seb128> and it stays until something change it
[16:07] <seb128> what would be the client application in that case?
[16:09] <alan_g> seb128: that's why I didn't think what kdub referred to met your need
[16:10] <seb128> k, thanks
[16:10] <seb128> where should I open a bug if I register one about my usecase
[16:10] <kdub> right, I don't think it would either, now that I understand better, although we do have a lot of the plumbing, more modifying the policy
[16:11] <seb128> mir? unity8? something else?
[16:11] <seb128> kdub, willcooke asked me to register bugs for things we need from mir to have a full desktop, trying to do that ;-)
[16:11] <alan_g> kgunn: where does this belong? ^^
[16:12] <kgunn> just a sec, on a hangout...
[16:16] <kgunn> camako: ^ you might read thru as well....
[16:17] <camako> kgunn, I was
[16:17] <kgunn> so i can see on desktop where there may be fixed physical screens with relative position, this makes sense, but with say phone/monitor it doesn't
[16:18] <kgunn> surely we want the feature, question is...where does the logic/tracking reside & where does the policy decide
[16:18] <kgunn> sort of feels like mir should prolly keep track of the positions for any sort of optimizatino or shared FB or some such could happen
[16:19] <kgunn> but then shell would determine policy, e.g. i'm on a desktop or i'm on phone , a-la hypothesis generator from
[16:19] <kgunn> https://docs.google.com/a/canonical.com/presentation/d/1K1oV4vMc-FduKUNYYO62zPUCU5WMb74zjer8KzYzhLg/edit#slide=id.p
[16:20] <kgunn> greyback: mzanetti ^
[16:20] <kgunn> in short, to support relative monitor placements in a converged world...
[16:20] <greyback> sounds like htere's no one answer for all our convergence cases
[16:22] <greyback> I guess some displays could be isolated from others, i.e. phone UI probably should not be part of the entire "virtual desktop", as it doesn't make a huge amount of sense to drag an app to the phone screen with a mouse
[16:22] <kgunn> seb128: so is system-settings a client of mir in any way today ?
[16:23] <seb128> kgunn, well, system settings is a standard app, I expect it to write some configuration on disk but it's not a service so it's not going to apply it, unity8 should probably be the one doing that
[16:23] <greyback> perhaps Mir could tag some displays as being configurable, and some as not - shell could decide which display is and isn't configurable
[16:23] <kgunn> seb128: yep...
[16:24] <kgunn> greyback: when you say "configurable" you mean...can have a relative position to the other display ?
[16:24] <seb128> greyback, well, on "docked phone" it could make sense to be able to turn the screen of the phone on or off, the same way you do it today for a docked laptop
[16:24] <greyback> kgunn: yeah
[16:25] <greyback> seb128: true.
[16:26] <kgunn> it does make sense tho that mir would need to add "output" coordination...to render windows across screens, and mouse trajectory etc
[16:27] <greyback> sounds like we want Mir to support multiple display collections. phone display would be set as member of a single collection, on it's own. Then multiple monitors could all belong to another collection. Displays in a collection can be configured relatively to eachother
[16:27] <greyback> only a single collection can capture a mouse
[16:28] <greyback> windows/applications cannot be shared across collections
[16:30] <seb128> greyback, greyback, I get from that discussion that we don't have a blueprint/bug/googledoc discussing those needs yet?
[16:31] <greyback> seb128: I'm not aware of any docs on the topic
[16:31] <seb128> where should we start? with a bug report against mir?
[16:31] <greyback> bug to start, but really we need to determine what is actually wanted
[16:32] <greyback> scope is kinda big
[16:32] <kgunn> seb128: yeah...and you're early :)
[16:32] <seb128> yeah
[16:32] <seb128> kgunn, well, willcooke asked us to register bugs for things that "desktop is going to need from mir"
[16:32] <seb128> that's one of those
[16:32] <seb128> we need to know what is missing to get a full desktop
[16:32] <seb128> so we need to start listing those
[16:32] <seb128> even if it's early to work on them
[16:32] <kgunn> seb128: absolutely, no worries
[16:33]  * willcooke likes being early
[16:33] <willcooke> but is late to this conversation
[16:33] <willcooke> :)_
[16:33] <seb128> hehe
[16:34] <kgunn> seb128: likely would need a bug on design as well...like, what do we want to do on phone/tablet....
[16:34] <kgunn> e.g. android made a real concrete decision to just mirror
[16:34] <seb128> kgunn, bug on ubuntu-ux/mir/unity8 I guess
[16:34] <kgunn> yeah
[16:35] <seb128> well, android doesn't claim to support developer desktops yet
[16:35] <kgunn> i think we should collectively design a phase 1 tho...
[16:35] <seb128> they might revisit if/when they try to reach there
[16:35] <kgunn> e.g. desktop we want parity, phone should at least mirror
[16:35] <seb128> right
[16:35] <kgunn> i could totally see on phone
[16:35] <kgunn> having a glowing-edge or something where you can flick apps or some such
[16:36] <kgunn> to magically appear on monitor
[16:36] <kgunn> kind of special desktop extend mode...
[16:36] <kgunn> or phone becomes a remote or vcr-button mode
[16:37] <camako> ... yeah a lot more can be done on a phone, though... depending on how much we wanna do
[16:37] <kgunn> camako: yeah...i heard a rumor you once had to work on such stuff :-P
[16:38] <camako> heh.. I heard that rumor too.
[16:38] <kgunn> camako: so i think we just found something for alf and alan to work on in the new year ;)
[16:39] <camako> kgunn, yeah.. this is very murky though, we need arch/design input in terms of how far we want to go
[16:41] <camako> do we want apps to be aware of these displays and change their behaviour, etc.. (the "remote control" use-case requires that)
[16:41] <camako> anyways, let's start with a bug
[16:41] <camako> :-)
[16:43] <kgunn> camako: agree with murky statement, hence i'll take it on me to draft a spec for something like a phase1(desktop parity & reasonable expectations for phone), we can include ideas for future under a phase2
[16:44] <camako> kgunn, sure
[17:06] <racarr_> camako: Did you mean to update your review status on
[17:06] <racarr_> add-more-event-getters?
[17:07] <greyback> can anyone tell me how/where Mir decides to use clone mode for multimonitors?
[17:07] <racarr_> greyback: I think you are looking for the DefaultDisplayConfigurationPolicy
[17:08] <camako> racarr, I was hoping to see something logged for the aborts.
[17:16] <racarr_> camako: oh ok
[17:24] <greyback> racarr_: that's it, thanks
[17:39] <racarr_> hmm wait
[17:39] <racarr_> why have I
[17:39] <racarr_> lol these statements were originally assert
[17:39] <racarr_> and now they are aborts
[17:39] <racarr_> preceded by log strings
[17:39] <racarr_> that contain
[17:39] <racarr_> assertions
[17:39] <racarr_> :/
[17:40] <racarr_> lol I guess they are ok in release builds though
[17:45]  * alan_g would have been happy with #undef NDEBUG
[17:55] <alan_g> camako: could you find time to review this today? https://code.launchpad.net/~alan-griffiths/mir/publish-server-examples-and-docs/+merge/244026
[17:56] <camako> alan_g, yep I was working on it right now as a matter of fact
[17:56] <alan_g> camako: then note that I've just updated it
[17:56] <camako> alan_g, ok, I'll refresh
[18:05] <racarr_> camako: What do you think the log messages should say? I can't think of anything useful
[18:05] <racarr_> the only thing interesting afaics is the calling frame which we obviously dont have
[18:13] <kdub> racarr_, would BlankingHwcControl be a better name?
[18:13]  * kdub agrees that it could be better
[18:13] <kdub> and the 1.4 impl would be PowerModeHwcControl
[18:14] <racarr_> kdub: Yeah I think that does make more sense
[18:15] <bschaefer> greyback, hey, any luck with those pixel formats + sdl?
[19:28] <greyback> bschaefer: not had chance to give it a go yet, sorry
[19:28] <bschaefer> greyback, no worries :), jsut wanted to double check
[21:15] <mibofra> hi guys
[21:15] <mibofra> does someone remeber me xD ?
[21:20] <anpok> how could we forget
[21:41] <mibofra> lol hi anpok
[21:44] <mibofra> anyway, I'm again with utouch in chroot, another setup, on the latest rootfs. Now everything seems to not prompt errors, egl demos too (anyway only render_to_fb continue displays something )
[21:44] <mibofra> but I've started another mir demo server and mir_stress
[21:44] <mibofra> with mir_stress I get this: UMP: ump_arch_open() failed to open UMP device driver
[21:45] <mibofra> (notice that I've /dev/mali and /dev/ump reachable)
[21:49] <anpok> what do you mean by another?
[21:50] <anpok> in parallel to an already running one?
[21:51] <mibofra> anpok, deteled the other one and set up another
[22:00] <anpok> deleted the server?
[22:02] <mibofra> anpok, deteled all the rootfs and unrolled the latest
[22:02] <mibofra> mounted in bind /dev and company
[22:03] <mibofra> chrooted on ubuntu touch
[22:04] <anpok> ah reading correctly helps
[22:12] <anpok> mibofra: i can only guess (and I would start by looking at which operation failed through strace) AlbertA isnt here and kdub might have better ideas
[22:13] <mibofra> anpok, ok
[22:17] <kdub> mibofra, yeah, only one hwc-owning server should run at a time
[22:18] <mibofra> kdub, and I've only one server in background xD
[22:18] <mibofra> *ad noone in foreground
[22:20] <kdub> for a total of 2 running servers in the system?
[22:25] <kdub> also mibofra, does the server and basic clients work?
[22:25] <kdub> if it does, perhaps the stress test is just covering a corner case that we have a problem with (and most usecases would still work)
[22:31] <mibofra> kdub the matter is that now clients and demos run fine, but without displaying something, except form the standalone_render_to_fb
[22:31] <kdub> try running the server with "--disable-overlays true"
[22:55] <mibofra> ok
[23:01] <mibofra> kdub, the same


[00:00] <Ddorda> school tomorrow, must go sleep now, g'night!
[02:59] <jimmygoon> Why do I get sent to #ubuntu-proxy-users when using *Freenodes* own web irc?
[03:00] <Pici> jimmygoon: because thats the way that we've setup our channel. Please follow the directions in the channel and you should be able to join #ubuntu afterwards.
[03:01] <Pici> It allows us to use normal bans insteads of doubling up on all banned webchat users bans, among over things.
[03:01] <jimmygoon> Pici, I see. I guess I just assumed that Freenode would have tweaked their version of CGI IRC (or whatever is powering webchat.freenode.net) to be more integrated into their IRC ban lists.
[03:02] <jimmygoon> Pici, thanks for the info.
[09:55] <miha> is there a way for a local ubuntu channel to get the "ubuntu cloak" ? :D
[10:02] <elky> only the people who are official members of the project
[10:02] <elky> !membership
[10:04] <miha> i see
[10:04] <miha> can we just get ubuntu-si ? :D
[10:04] <miha> or is that a trademark
[10:05]  * miha just asking to get picture :D
[10:08] <elky> you cannot, no.
[10:09] <miha> elky ok no offense :D
[10:09] <miha> didnt know about this one #ubuntu-meta to report difficult support questions.
[10:11] <elky> well you do now :)
[10:12] <miha> thx. i see i need to be more active on ubuntu.si forum. then you can verify my contribution :D
[10:12] <miha> (you can use google translate :D )
[10:13] <miha> take care, sorry for interrupting.
[10:13] <elky> no problem. have a good day
[10:13] <elky> meh
[14:24] <Joeb454> anybody around?
[14:48] <erUSUL> Joeb454: what's up?
[14:53] <Joeb454> erUSUL: I was looking for somebody who can change a factoid in ubottu
[14:53] <Joeb454> not sure who I should be looking for though :)
[14:54] <erUSUL> !usage
[14:54] <erUSUL> Joeb454: you can send the new edit yourself
[14:54] <Joeb454> oh I can? fair enough
[14:54] <erUSUL> Joeb454: /msg ubottu factoid <reply>Your new text here
[14:55] <erUSUL> Joeb454: someone in #ubuntu-ops have to aprove it and actually add it
[14:55] <Joeb454> ah ok, thanks erUSUL
[15:12] <Joeb454> hmm, couldn't seem to get it to work...i'll wait, in fear of flooding the ops channel
[15:12] <erUSUL> Joeb454: as i said --> someone in #ubuntu-ops have to aprove it and actually add it
[15:12] <erUSUL> Joeb454: so just make the edit and wait.
[15:12] <erUSUL> Joeb454: many edits fall through the cracks this days.
[15:13] <erUSUL> Joeb454: try tomorrow. i suspect more ops will be aviable in a work day
[15:22] <jussi01> no edits came through recently...
[15:22] <jussi01> the bot will tell you if it goes through to us.
[15:23] <jussi01> erUSUL: you are missing an "is" in that instruction, which is probably why it dont work
[15:23] <jussi01> this: [16:54:42] <erUSUL> Joeb454: /msg ubottu factoid <reply>Your new text here
[15:23] <jussi01> should be:
[15:23] <jussi01> [16:54:42] <erUSUL> Joeb454: /msg ubottu factoid is <reply>Your new text here
[15:23] <jussi01> Joeb454: ^
[15:24] <Joeb454> jussi01: [15:24] <jussi01> Joeb454: what did you type?
[15:24] <Joeb454> it's a long one, so one second :P
[15:24] <Joeb454> wait
[15:25] <Joeb454> jussi01: do you need the ! at the start, or do it without that?
[15:26] <jussi01> Joeb454: in om with ubottu, do: !factoidword is <reply>your content here
[15:26] <Joeb454> hmm, I did that, I put (sorry for this)
[15:26] <jussi01> just past the line that you used
[15:26] <Joeb454> !ops-#ubuntuforums is <reply>tseliot, sdennie, Sef, overdrank, frodon, Joeb454, Technoviking, forumsmatthew, Brunellus, panickedthumb, PriceChild, aysiu, compiledkernel, dmizer, bapoumba,  bodhi_zazen, PartisanEntity, ArtificialIntelligence, jacob, maco, ugm6hr, PmDematagoda, weiman01, Rocket2DMn, slavik, ibuclaw, forestpiskie, cariboo907, MichaelGodawski, ubuntugeek, KiwiNZ  or jdong - Help!
[15:26] <Joeb454> ubottu: I know! :)
[15:27] <jussi01> well, given that they arent the ops in there...
[15:27] <Joeb454> well that's true, but at the same time, the current list is outdated
[15:27] <jussi01> Joeb454: /msg chanserv access #ubuntuforums list
[15:27] <Joeb454> the above is basically a list of the uf staff
[15:30] <jussi01> Joeb454: I got to go for a few, back soon
[15:32] <Joeb454> jussi01: no problem, I'll try and get it to go through (with the access list
[15:42] <jussi01> Joeb454: Im back for a min
[15:43] <jussi01> Joeb454: the thing is, there is no point calling the ops with a list of people who half of them cannot do anything.
[15:47] <Joeb454> jussi01: good point :)
[15:47] <Joeb454> jussi01: I'll try again using those on the access list
[15:47] <Joeb454> not that it gets used often, but it's better to keep it up-to-date
[15:48] <jussi01> Joeb454: yeah, we are working on a solution that is autmated so we dont have to worry about it.
[15:48] <jussi01> anyway, off agasin
[15:51] <Joeb454> hmm, still no joy
[17:34] <DJones> jpds: Just for info, ubot4 has just fallen off irc, "remote closed the connection
[17:36]  * jussi01 points up one line from DJones's comment :P
[17:37]  * DJones doesn't see that here, joins & parts are switched off
[17:37] <jussi01> ahh
[17:37]  * jussi01 always has joins/parts on.
[17:38] <jussi01> DJones: but thanks for pinging him, its useful :)
[17:38] <DJones> Even in #ubuntu? i couldn't read that with them on
[17:38] <jussi01> DJones: _everywhere_
[17:39] <DJones> saying that, you need them on in channels that you've got access anyway
[17:39] <jussi01> DJones: which for me, is almost everywhere...
[17:39] <DJones> :)
[17:43]  * m4v hides or unhides join/part msgs when needed
[17:51] <DJones> jpds: Can I also suggest you switch ubot4's nick protection on, I've just kicked an impersonator in -uk
[18:58] <nalioth> DJones: when folks do as they should, ( using the nick of the person they're talking to on irc ), there is no need to filter anything
[18:59] <DJones> nalioth: This is true, but it relies on people doing the sensible thing
[19:03] <Tm_T> I hide/ignore nothing (:
[19:06] <nalioth> DJones: which is why those of us who know - educate (instead of hiding data)