[00:02] <mwhudson> thumper: is there a bug report for the fact that i can be requested to review a branch i can't see?
[00:03] <thumper> mwhudson: probably
[00:03] <lifeless> mwhudson: I don't remember one
[00:04] <thumper> it rings a vague bell
[00:06] <mwhudson> yeah, me too
[00:10] <mwhudson> thumper: can't you actually fix https://bugs.edge.launchpad.net/launchpad-code/+bug/624009 now?
[00:10] <_mup_> Bug #624009: Email should not be sent for new WIP merge proposals <code-review> <email> <Launchpad Bazaar Integration:In Progress by thumper> <https://launchpad.net/bugs/624009>
[00:10] <thumper> yeah...
[00:10] <thumper> it is still showing on our kanban board :)
[00:10] <mwhudson> and my bug is there https://bugs.edge.launchpad.net/launchpad-code/+bug/330290
[00:10] <_mup_> Bug #330290: Can request a review from someone who can't see the merge proposal <code-review> <confusing-ui> <privacy> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/330290>
[00:31] <mwhudson> $ time ./bin/py -c pass
[00:31] <mwhudson> real	0m0.610s
[00:31] <mwhudson> that's quite slow...
[00:33] <mwhudson> $ strace ./bin/py -c pass 2>&1 | grep -c stat
[00:33] <mwhudson> 19347
[00:33] <mwhudson> that's quite a lot of stats
[00:33]  * mwhudson wonders if this has regressed again
[00:37] <lifeless> buildout ftw
[00:37] <lifeless> ?
[00:37] <mwhudson> yeah, to some extent certainly
[00:37] <lifeless> (by which I mean pth files, egg lookups etc)
[00:37] <mwhudson> stat()ing /home/mwh/canonical/checkouts/trunk/eggs/RestrictedPython-3.5.1-py2.6.egg three times seems a bit silly
[00:37] <lifeless> that stack needs to be tuned and optimised for everyones sske
[00:39] <mwhudson> there is this pattern of stats for every egg afaics: http://pastebin.ubuntu.com/515317/
[00:44]  * thumper has errands in town, back soonish
[01:00] <wallyworld> lifeless: can you please look at https://pastebin.canonical.com/38714/
[01:00] <wallyworld> do you agree with the approach?
[01:00] <lifeless> mmm
[01:01] <lifeless> a few concerns
[01:02] <lifeless> 'config' is establish as an idiom meaning 'the current config'
[01:02] <lifeless> so overloading that will confuse people
[01:02] <lifeless> lets not do that
[01:02] <wallyworld> so i just don't use the alias?
[01:02] <lifeless> secondly, testrunner-appserver is hopefully deletable
[01:02] <lifeless> see the current thread on the list
[01:02] <lifeless> even if isn't deletable, it won't be usable because its still going to be static
[01:03] <lifeless> that said, I'd expect that individual tests *already* are running in that config, aren't they ?
[01:03] <wallyworld> not sure. i can check.
[01:03] <lifeless> (if not, how are they managing to connect at all ?)
[01:04] <wallyworld> one of the ones i'm looking at to start is lib/canonical/launchpad/doc/launchpadlib.txt
[01:04] <lifeless> if the answer is 'a subprocess is run in that config' then the approach of instantiating a specific config to let us refer to the config the external process is using makes sense, but lets not make it a global
[01:04] <lifeless> for tw oreasons
[01:04] <lifeless> two reasons
[01:05] <lifeless> firstly, I'm this || close to sending in a patch to dynamically generate configs in the test run, so any global like that will be stale
[01:05] <lifeless> secondly we have way too many globals, lets reduce them.
[01:05] <wallyworld> sure, i was trying to fit in with how stuff had been done previously
[01:06] <lifeless> I appreciate that :)
[01:06] <lifeless> and I'm glad -very glad- you're looking at this
[01:06] <wallyworld> i can just create a config instance on the fly: config = CanonicalConfig('testrunner-appserver')
[01:06] <lifeless> something like
[01:06] <lifeless> appserver_config = BaseLayer.getAppserverConfig()
[01:06] <lifeless> is probably whats needed
[01:07] <lifeless> the hard coded string there would be a problem
[01:07] <wallyworld> ok. my exposure to this stuff is still very limited :-)
[01:07] <lifeless> mine too
[01:08] <lifeless> I started looking at the config system code on sunday :)
[01:08] <wallyworld> so the BaseLayer.getAppServerConfig() should return me the correct config instance?
[01:08] <wallyworld> i started 30 minutes ago :-)
[01:08] <lifeless> I think that that will work
[01:08] <wallyworld> ok. thanks. i'll suck it and see
[01:09] <wallyworld> there's quite a few hard coded urls to fix. that's why i wanted to ask first :-)
[01:10] <thumper> wallyworld: want a chat?
[01:10] <lifeless> wallyworld: yeah
[01:10] <lifeless> wallyworld: what I'm suggesting will give us one place to change if we need to change
[01:11] <lifeless> \o/ databasefixture has landed
[01:11] <wallyworld> thumper: ok
[01:12] <wallyworld> lifeless: that's what i was looking for too. i'll let you know how i get on. thanks for the input
[01:33] <thumper> lifeless: compile failed?
[01:34] <lifeless> thumper: did it?
[01:34] <thumper> lifeless: aye
[01:35] <thumper> lifeless: can you parse the error?
[01:36] <lifeless> Could not locate /srv/buildbot/slaves/launchpad/lucid-devel/build/orig_sourcecode/eggs/setuptools-0.6c11-py2.6.egg/setuptools/package_index.py:155: UserWarning: Unbuilt egg for ClientCookie [unknown version] (/usr/lib/python2.6/dist-packages)
[01:36] <lifeless> ops issue i think, machine was being upgraded or some such
[01:37] <spm> hmm?
[01:40] <mwhudson> lifeless: i presume the plan after edge and lpnet are running the same code is to remove the edge.launchpad.net domain?
[01:40] <mwhudson> well, not remove, deprecate & redirect from
[01:40] <thumper> wallyworld: https://dev.launchpad.net/Code/BranchRevisions
[01:43] <lifeless> mwhudson: yes
[01:44] <lifeless> spm: was any maintenance being done on that machine
[01:44] <lifeless> spm: that could cause that crazy output
[01:46] <spm> the lucid-devel slave?
[02:06] <lifeless> spm: yes
[02:07] <lifeless> wallyworld: I'm exposing the config for you as BaseLayer.appserver_config_name
[02:08] <wallyworld> lifeless: ok. i'm just coding everything now. i can make my branch dependent on yours?
[02:08] <lifeless> sure
[02:08] <wallyworld> for now i'll use a string literal in the getAppServerConfig, just to get stuff working
[02:08] <lifeless> sure
[02:10] <wgrant> How often will qastaging's DB be clobbered?
[02:14] <LPCIBot> Project db-devel build (78): STILL FAILING in 4 hr 4 min: https://hudson.wedontsleep.org/job/db-devel/78/
[02:25] <spm> lifeless: is that a moderately recent error? because there hasn't been any work on the slaves in ~ 4 days ish. afaict/find
[02:25] <lifeless> spm: today
[02:25] <lifeless> wgrant: same time stagings is
[02:27] <spm> lifeless<EMAIL_ADDRESS>??
[02:28] <spm> ie. lmgtfy ;-)
[02:28] <lifeless> spm: huh?! *today*
[02:28] <spm> same error
[02:29] <spm> we've seen this beofre. it's funky crap inside the test suite
[02:29] <lifeless> so you're thinkinging dirt in the lp buildbot build area?
[02:29] <spm> no. I'm thinking funky crap inside the test suite(s)
[02:30] <lifeless> spm: the only change was mine, and it passed ec2.
[02:33] <spm> lifeless: not sure. All I can say is that we've seen that error at least once before, back in March. it was weirdness inside the lp code/tests/includes/whatevers. I'd focus there.
[02:33] <thumper> lifeless: what are we doing about the thread garbage in ec2 tests?
[02:39] <wgrant> The current policy seems to be "lalalala I'm going to throw it at the wall until it sticks"...
[02:40] <thumper> :(
[02:40] <wgrant> Although Hudson's incessant whinging has almost convinced me to dig into it.
[02:42] <lifeless> thumper: I'm going to talk with stub again
[02:42] <thumper> ack
[02:42] <lifeless> I was advocating disabling the check last week
[02:43] <lifeless> I think it has to be downgraded to a warning for now, at most.
[02:43] <lifeless> but I need data
[02:43] <wgrant> The remaining failures are just Windmill, aren't they?
[02:48] <lifeless> I think so
[02:57] <rockstar> poolie, hi. Do feature flags also work with the API?
[02:58] <poolie> what do you mean?
[02:58] <poolie> can code called by the api consult flags?
[02:58] <poolie> i think it will work, but you may be the first to do it
[03:08] <rockstar> poolie, I mean the web api.  If I land my work, it's going to show up in the web api, isn't it.
[03:10] <thumper> rockstar: yes, I think so
[03:10] <rockstar> thumper, yeah, that's what I figured.
[03:11] <rockstar> I'm not sure whether or not I care enough to try and fix it.  I mean, merge queues have been available through the API for a while.  :)
[03:11] <rockstar> I guess I'll just need to be quick.
[03:13] <poolie> rockstar: i think it should just work but it depends on to what extent the web api uses the standard publication stuff
[03:14] <poolie> i would really appreciate hearing that either works, crashes, or silently fails
[03:14] <thumper> rockstar: just be quick :)
[03:14] <poolie> ... by way of a bug in the latter two cases
[03:15] <rockstar> poolie, how do you specify in an interface that a property is only accessibly through a feature flag?
[03:15] <wgrant> You can't.
[03:16] <wgrant> You have to check the flag inside the method.
[03:16] <mwhudson> i guess you can make a method error in some meaningful way if a flag is not in effect
[03:16] <mwhudson> a property... dunno
[03:21] <wgrant> (I believe the DistroSeriesDifference API stuff is currently protected by flags)
[03:22] <poolie> right
[03:22] <thumper> lifeless: do you think calls like https://lp-oops.canonical.com/oops.py/?oopsid=1751XMLP32 could block the xmlrpc server for the other calls?
[03:22] <poolie> rockstar: i mean presumably you would get... an AttributeError... if it didn't exist at all?
[03:22] <poolie> you could raise that? or Unauthorized, perhaps?
[03:25] <lifeless> rockstar: you'd need to change the wadl processing to use a flag in that fashion
[03:25] <lifeless> rockstar: as wgrant says, its not designed for static things like that, because it depends on the db
[03:25] <lifeless> I'd just do your things, merge queues are classified as unsupported by thumpers fiat ;)
[03:25] <rockstar> lifeless, yeah.
[03:26] <lifeless> as long as what you land is working at any point, its ok
[03:26] <rockstar> lifeless, yeah, that's the plan.
[03:29] <thumper> lifeless: did you boot buildbot?
[03:30] <lifeless> yes
[03:30] <lifeless> hoping its nonsense
[03:30] <lifeless> which it looks like it was
[03:50] <bac> good morning rockstar + antipodes
[03:50] <wgrant> Afternoon.
[03:54] <bac> wgrant: did you get all three of your branches landed, after the annoying ec2 faliures?
[03:55] <thumper> hi bac
[03:57] <wgrant> bac: And other three after that, yeah.
[03:57] <rockstar> bac, are you in Japan?
[03:57] <wgrant> After a couple of runs.
[03:57] <bac> rockstar: while i am big in japan i'm actually in vietnam
[04:30] <lifeless> wallyworld: rev 11741 in lp:~lifeless/launchpad/uniqueconfig is pushing now
[04:30] <lifeless> wallyworld: I'm not done, but the bits you need are done.
[04:31] <wallyworld> lifeless: thanks. only 100+ more tests to fix :-)
[04:31] <wallyworld> lifeless: i'm just assuming your rev with include the app config name - i've got methods for all the rest i need
[04:32] <wallyworld> s/with/will
[04:32] <rockstar> wallyworld, did you get your windmill issues fixed?
[04:32] <wallyworld> rockstar: no :-( but i talked to adam from the windmill devs and he suggested a windmill proxy issue may be the cause
[04:32] <wallyworld> i'm not 100% sure exactly what that means just yet
[04:33] <wallyworld> all i know is YUI and windmill don't play nicely together
[04:33] <rockstar> wallyworld, yeah.  Here's what I've found.  The same tests fail (relatively) consistently on my machine, but ec2 has failed 6 different runs with different tests failing each time with no changes from me.
[04:34] <rockstar> wallyworld, I don't see how YUI and windmill wouldn't play well together.  windmill doesn't know YUI from Adam.
[04:34] <wallyworld> rockstar: the same general failure mode? ie YUI breaks somehow?
[04:34] <wallyworld> from what adam said, there's some proxying the windmill does
[04:35] <wallyworld> s/the/that
[04:37] <wallyworld> rockstar: adam talked about needing to blacklist a url to prevent windmill proxying it and gave this reference
[04:37] <wallyworld> http://github.com/windmill/windmill/wiki/Preferences-File
[04:37] <rockstar> wallyworld, hm, I was under the impression that the windmill proxy was important.
[04:38] <wallyworld> i'm not sure - i haven't devoted enough brainspace to understanding the windmill architecure at this point
[04:39] <wallyworld> i was hoping it would make more immediate sense to you :-)
[04:41] <rockstar> wallyworld, it doesn't make much sense to me now, but it's also a bit late right now.  Maybe I can make some sense of it tomorrow.
[04:41] <wallyworld> rockstar: ok. we'll talk then. have a good evening
[04:47] <lifeless> wallyworld: it generates unique testrunner-appserver configs in BaseLayer.setUp
[04:47] <lifeless> wallyworld: it doesn't allocate unique ports in the generated config [yet]
[04:47] <lifeless> wallyworld: and really the whole config thing is backwards here, we want to start the server and readback the port as I described on the list
[04:47] <lifeless> EFUTURE
[04:49] <wallyworld> lifeless: np. i'll look at the branch to see what's there. atm, i'm fixing the test logic but the expected results still contain the hardcoded 8085. if the ports are generated, i'll have to come back and deal with that too
[04:50] <lifeless> wallyworld: what do you mean by 'expected results' ?
[04:50] <lifeless> wallyworld: the goal is to use different ports so we can run tests in parallel
[04:50] <wallyworld> lifeless: yeah, i realise that. here's a snippet from on e of the doc tests
[04:51] <wallyworld>     >>> browser.url
[04:51] <wallyworld>     'http://launchpad.dev:8085/~stimpy'
[04:51] <wallyworld> see how the expected url value is hard coded
[04:51] <lifeless> ok
[04:52] <wallyworld> i can deal with that. my first aim is to get the test logic sorted out, then come back around and fix this other stuff
[04:52] <lifeless> ok
[04:52] <lifeless> nuking the darn doctests would be one way ;)
[04:52] <wallyworld> well, the unit tests do the same thing :-)
[04:52] <lifeless> wallyworld: except assertions are easier there
[04:52] <wallyworld> +1
[04:53] <lifeless> perhaps browser could grow some support
[04:53] <lifeless> like
[04:53] <lifeless> vhost : launchpad.dev / bugs.launchpad.dev etc
[04:53] <lifeless> urlpath : /~stimpy
[04:54] <wallyworld> the windmill layer setup does this sort of thing
[04:55] <lifeless> if browser had that
[04:55] <lifeless> then you could write the above as
[04:55] <lifeless>  >>> browser.vhost
[04:55] <lifeless>   launchpad.dev
[04:55] <lifeless>   >>> browser.urlpath
[04:55] <lifeless>   /~stimpy
[04:55] <lifeless> which would probably be easier than converting to unittest in the short term
[04:56] <lifeless> or even have a normalise_url, or something.
[04:56] <wallyworld> yes. doc tests are here for a while yet given how much is in them
[04:58] <wallyworld> what i am playing with now is I have a method called getRootLaunchpadUrl(sitename='mainsite') which delgates to BaseLayer.xxx
[04:58] <wallyworld> so with one line of doc in doc tests i can get the url i needed
[04:58] <wallyworld> but i could look at adding that to the browser as you suggest
[04:58] <lifeless> the main thing for doctests is that you need to be able to write the literal expected value
[04:59] <lifeless> if you can do that, awesome
[04:59] <lifeless> I'm just riffing on the approach is all
[04:59] <wallyworld> np. it's always very good to discuss different ideas
[05:06] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/uniqueconfig/+merge/38689 \o/
[05:06] <lifeless> jml: testtools upgrade broke bizarrely
[05:20] <LPCIBot> Project devel build (124): STILL FAILING in 4 hr 9 min: https://hudson.wedontsleep.org/job/devel/124/
[05:22] <lifeless> is there a config serialiser class ? for writing to the configs ?
[06:25] <wgrant> spm: Around?
[06:25] <spm> wgrant: ish...
[06:25] <wgrant> spm: The reporter of https://bugs.edge.launchpad.net/ubuntu/+source/beryl-core/+bug/109550 needs your magical banhammer.
[06:25] <_mup_> Bug #109550: Black/White/unrendered windows in Beryl  <beryl-core (Ubuntu):Invalid> <https://launchpad.net/bugs/109550>
[06:26] <spm> ahh. a special person eh?
[06:26] <wgrant> Spam of some variety.
[06:26] <wgrant> Only to that bug, that I've seen.
[06:26] <spm> awesome. ta.
[06:33] <wgrant> StevenK: Ohloh seems to be less glacial now... might be done tomorrow.
[06:33] <StevenK> Colour me suprised.
[06:34] <StevenK> http://paste.ubuntu.com/515453/ :-(
[06:35] <wgrant> StevenK: That can mean a missing export_as_webservice_entry()
[06:36] <wgrant> I think.
[06:36] <wgrant> What's your diff?
[06:37] <wgrant> It can also happen if your thing doesn't get imported into canonical.launchpad.interfaces.*
[06:37] <wgrant> But your diff will tell me everything.
[06:38] <StevenK> https://code.edge.launchpad.net/~stevenk/launchpad/db-add-derivedistroseries-api/+merge/38189
[06:38] <StevenK> wgrant: It's messy due to the MP being targetted at db-devel, but now I'm free to land on devel, so read with caution
[06:44] <wgrant> StevenK: What's the real diff?
[06:45] <StevenK> wgrant: The test changes and lib/lp/registry/{interfaces,model}/distroseries.py
[06:45] <StevenK> Addition of deriveDistroSeries()
[06:49] <wgrant> Ah.
[06:50] <wgrant> StevenK: You probably need to patch your 'distribution' argument's interface.
[06:50] <wgrant> Since IDistroSeries.distribution is an Interface for circular import reasons.
[06:50] <spm> wgrant: fyi. account zotted; old comments zotted as well
[06:51] <wgrant> You know about the _schema_circular_imports fun, right?
[06:51] <wgrant> spm: Thanks.
[06:57] <StevenK> wgrant: Oh, right, so I can copy_field, as long as I also deal with circular_imports?
[07:01] <wgrant> I think so.
[07:01] <wgrant> Anyway, I need to run.
[07:28] <lifeless> \o/
[07:28] <lifeless> dynamic db names working.
[07:28] <lifeless> in tests as in.
[07:29] <lifeless> lets see if it works for the librarian too
[07:32] <lifeless> seems too, but something remade the ftest db. Hmm.
[07:53] <lifeless> O M G
[07:53] <lifeless> lp test start reads from dev/random
[07:55] <jpds> lifeless: Does it support sharding?
[07:59] <lifeless> jpds: it must. Its web scale.
[07:59] <lifeless> :!bin/test -vvt test_pgsql --parallel
[07:59] <lifeless> Tests running...
[07:59] <lifeless> Ran 15 tests in 27.225s
[07:59] <lifeless> ^- woo
[08:00] <lifeless> StevenK: hey, what instance size are you using in hudson ?
[08:31] <adeuring> good morning
[08:32] <StevenK> lifeless: The largest
[08:32] <StevenK> lifeless: If you're running out of space on /, fiddle things to use /mnt
[08:33] <lifeless> StevenK: well, its just that I'm curious how many cores it will get
[08:34] <StevenK> lifeless: Oh, right. Lemme check
[08:34] <lifeless> StevenK: largest is ill defined
[08:34] <lifeless> there are ;argest-cpu, largest-memory etc
[08:35] <lifeless> m1.xlarge ?
[08:35] <StevenK> lifeless: Picking on one of the running instances, it has 2GB of RAM and 4 QEMU cores.
[08:35] <lifeless> c1.xlarge would be interesting to try
[08:35] <lifeless> 8 cores
[08:36] <StevenK> That is c1.xlarge
[08:36] <lifeless> surely not
[08:36] <StevenK> Yes
[08:36] <lifeless> http://aws.amazon.com/ec2/instance-types/
[08:36] <StevenK> It isn't using ec2
[08:37] <lifeless> oh
[08:37] <lifeless> thats right
[08:37] <lifeless> it would be nicer if they matched up
[08:37] <StevenK> File a ticket? :-)
[08:37] <StevenK> But I daresay, it's a problem of resource management
[08:37] <lifeless> StevenK: btw
[08:37] <lifeless>  https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[08:38] <lifeless> blames you for needing to QA :)
[08:38] <StevenK> lifeless: Yes, I'm blocked on dogfood, I'm waiting for Julian and Tom.
[08:38] <lifeless> ok
[08:38] <lifeless> please file a bug / RT ticket explaining what we need to change to let this get qa'd on qastaging.
[08:38] <lifeless> we /have/ to fix this pipeline
[08:39]  * wgrant can hear people crying already.
[08:39] <StevenK> lifeless: Shell access
[08:39] <lifeless> StevenK: surely you can come up with a better answer
[08:39] <lifeless> StevenK: like 'this is a shell script, so I can write a test driver for it that the losas can run on request'
[08:40] <StevenK> lifeless: No, I can't. The bits are infrastructure and I need to reach in and rummage around.
[08:40] <lifeless> StevenK: why?
[08:40] <StevenK> lifeless: Because I'd like to confirm things look good at a database level before I kick off a script, etc, etc.
[08:40] <StevenK> I'd like to be perfectly clear the right things are happening
[08:41] <lifeless> StevenK: this sounds automatable
[08:41] <wgrant> (also, most of the archive admin tools still require shell access)
[08:41] <lifeless> but even if its not, we need to be able to qa on qastaging
[08:41] <lifeless> this is a fundamental tenant of being able to do continuous deployment.
[08:41] <persia> (wgrant: most of them can be run by waldo though, by someone else if given the arguments)
[08:42] <lifeless> it needs to be written down
[08:42] <lifeless> handed off to a losa
[08:42] <lifeless> -or something-
[08:42] <StevenK> lifeless: In other news, can you poke at http://people.canonical.com/~stevenk/windmill-thread-debug-r11734.subunit.gz
[08:43] <lifeless> forbidden
[08:43] <lifeless> mail it to me or something
[08:43]  * StevenK curses
[08:43] <StevenK> lifeless: Fixed, please retry
[08:44] <lifeless> so what do you want me to see?
[08:45] <StevenK> lifeless: I added some more debugging to the windmill teardown, there's an oddness with a Timer thread there
[08:46] <lifeless> I'd say thats a threading subclass
[08:46] <StevenK> lifeless: And I also got 'test process died with exit code 2, but no tests failed', which I don't believe.
[08:46] <lifeless> used by windmill
[08:47] <lifeless> I think that test process thing is damage in zope.testing's subunit support, which I put a patch up for months ago
[08:47] <lifeless> benji landed it in the weekend I think
[08:47] <StevenK> Oh, damn it
[08:47] <StevenK> That revision is qa-ok, but Ursinha's script munged it
[08:48] <StevenK> lifeless: When does that page get re-generated?
[08:50] <lifeless> StevenK: 10 minutes or so
[08:50] <lifeless> Ursinha-afk: can you run it any more frequently now?
[08:50] <StevenK> lifeless: As in, 'in ten minutes' or 'every ten minutes' ?
[08:50] <lifeless> StevenK: its in cron, I think its a 10 minute frequency
[08:53] <lifeless> grr wtf OperationalError: FATAL:  database "launchpad_ftest_template" does not exist
[08:55] <StevenK> Right, now that page doesn't blame me, excellent.
[08:56] <wgrant> Does it blame me instead?
[08:56] <StevenK> No, sinzui
[08:56] <lifeless> sinzui
[08:56] <wgrant> Ah.
[08:56] <lifeless> however, anyone can qa
[08:56] <lifeless> in principle
[08:56] <StevenK> wgrant: We can change it so it always blames you
[08:56] <lifeless> Bug 46581 is marked as not-ok.
[08:56] <_mup_> Bug #46581: Change a poll type URL manually crashes <oops> <polls> <qa-needstesting> <Launchpad Registry:Fix Committed by sinzui> <https://launchpad.net/bugs/46581>
[09:01] <lifeless> I gotta say, wtf is dropping the template db
[09:03] <StevenK> Crash dump was written to: erl_crash.dump
[09:03] <StevenK> Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})
[09:03] <StevenK> Wheee, yay for readable logs, rabbitmq
[09:04] <StevenK> -rw-r----- 1 rabbitmq rabbitmq 243K 2010-10-18 08:02 /var/lib/rabbitmq/erl_crash.dump
[09:04]  * StevenK sobs
[09:04] <LPCIBot> Project devel build (125): STILL FAILING in 3 hr 44 min: https://hudson.wedontsleep.org/job/devel/125/
[09:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=henninge,
[09:04] <LPCIBot> sinzui][bug=639703] Correctly report bug tracking status for project
[09:04] <LPCIBot> groups.
[09:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][no-qa] Cleanup some partially-migrated-from\n\ttest support code.
[09:05] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][bug=660843][no-qa] Move the garbo scripts into
[09:05] <LPCIBot> lp.scripts
[09:05] <StevenK> Hm, I think I need to turn that off.
[09:09] <lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/662519 made me cry
[09:09] <_mup_> Bug #662519: lp test startup exhausts dev/random <Launchpad Foundations:New> <https://launchpad.net/bugs/662519>
[09:21] <lifeless> test run should be finished soon.
[09:21] <lifeless> \o/
[09:24] <StevenK> lifeless: I can kill that parallel-test build if you wish
[09:24] <lifeless> nono
[09:24] <lifeless> its nearly done
[09:25] <StevenK> Even with the no _template db errors?
[09:25] <lifeless> need to get the details and debug them
[09:25] <lifeless> most tests are passing
[09:25] <lifeless> its probably the tests that sampledata loading/dumping works, or some such
[09:26] <lifeless> hmm https://hudson.wedontsleep.org/job/parallel-test/4/ took 2 hours
[09:26] <lifeless> so it may have an hour to go
[09:33] <bigjools> wgrant: how much testing have you done on bug 655690?
[09:33] <_mup_> Bug #655690: release_files_needed shouldn't live on FTPArchiveHandler <qa-needstesting> <soyuz-publisher> <tech-debt> <Soyuz:Fix Committed by wgrant> <https://launchpad.net/bugs/655690>
[09:36] <lifeless> Announcing Amazon SNS Management Console looks interesting
[09:42] <wgrant> bigjools: I've tested both a-f and NMAF fairly thoroughly.
[09:42] <wgrant> Plus the tests are a bit better now.
[09:44] <jml> want to see a blast from the past? https://devpad.canonical.com/~jml/mirror-failure.png
[09:45] <lifeless> meep
[09:49] <mwhudson_> jml: wow
[09:49] <jml> lifeless: fwiw, something else weird is going on with your branch. You should definitely not get an email like that for test failures.
[09:51] <lifeless> jml: the long spew of info? i filed a bug, its having a root logging handler installed that uses std*
[09:51] <jml> lifeless: no, not the root logger
[09:52] <jml> lifeless: although that's another problem
[09:52] <jml> lifeless: I changed the email so that it should start with a list of failing tests, and then have only the error info for those tests
[09:52] <jml> lifeless: it sends out the full horrible dump only when something surprisingly bad happens.
[09:53] <jml> but a quick scan of the full log doesn't reveal anything
[09:55] <lifeless> jml: what full horrible dump ?
[09:56] <jml> lifeless: this is what a failing branch email is supposed to look like: Tests started at approximately 2010-10-16 10:04:52.243410
[09:56] <jml> Source: bzr+ssh://bazaar.launchpad.net/~wgrant/launchpad/better-publisher-index-tests r9886
[09:56] <jml> Target: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ r11722
[09:56] <jml> 10565 tests run in 3:58:20.128578, 0 failures, 1 errors
[09:56] <jml> Tests with errors
[09:56] <jml> -----------------
[09:56] <jml>  lp.code.windmill.tests.test_branchmergeproposal_commitmessage.TestQueueStatus.test_inline_queue_status_setting
[09:56] <jml> [09:56] <jml> ERROR: lp.code.windmill.tests.test_branchmergeproposal_commitmessage.TestQueueStatus.test_inline_queue_status_setting (subunit.RemotedTestCase)
[09:56] <jml> ----------------------------------------------------------------------
[09:56] <jml> _StringException: Text attachment: garbage
[09:56] <jml> ------------
[09:56] <jml> [<Thread(Thread-1110, started daemon<PHONE_NUMBER>3392)>]
[09:56] <jml> ------------
[09:56] <jml> **NOT** submitted to PQM:
[09:56] <jml> [r=bac][ui=none][no-qa] Start de-duplicating the apt-ftparchive and native publishing tests, and add more thorough index generation tests.
[09:56] <jml> (See the attached file for the complete log)
[09:56] <jml> sorry
[09:56] <jml> http://paste.ubuntu.com/515540/ ← I meant to paste that
[09:56] <wgrant> Severe chastisement.
[09:57] <lifeless> jml: thats what mine looked like
[09:57] <jml> lifeless: no, it didn't. the testtools -> devel email has stdout in it, for example
[09:57] <lifeless> ah
[09:57] <jml> lifeless: it does not have a list of tests with errors, for another example :)
[09:58] <lifeless> so, I think its because the *submitting tree* is used to control stuff
[09:58] <lifeless> not the target/source branch
[09:58] <jml> I don't follow
[09:59] <lifeless> I can't ec2 submit from my dev environment
[09:59] <jml> oh, you mean it's using remote.py from your branch? yes, that would be it.
[09:59] <jml> your local working tree, in fact
[09:59] <lifeless> I have a very old tree I never touch, because it 'works'
[09:59] <lifeless> its outside my dev vm
[10:00] <lifeless> generally when I touch it, it breaks. so I dont
[10:00] <jml> lifeless: ahh, ok.
[10:00] <jml> lifeless: well the new pretty email is very pretty and helpful.
[10:00] <jml> lifeless: but I can understand not wanting to mess about
[10:01] <lifeless> jml: testr looks after me ;)
[10:26] <jml> lifeless: I've updated run-test-improvements
[10:28] <LPCIBot> Project parallel-test build (5): STILL FAILING in 2 hr 15 min: https://hudson.wedontsleep.org/job/parallel-test/5/
[10:29] <lifeless> jml: how about run_with rather than run_test_with ? just a thought
[10:31] <lifeless> jml: def _run_test_method(self, result):
[10:31] <lifeless> jml: doesn't use result
[10:42] <jml> lifeless: thanks.
[10:42] <jml> lifeless: it never did.
[10:42] <lifeless> jml: interesting
[10:43] <jml> lifeless: also, _run_setup and _run_teardown
[10:59] <bigjools> jml: helleau.  Did you by any chance get to look further at the buildd-manager branch?  I'm about to run it on dogfood again, when DF is working.
[11:00] <jml> bigjools: no, not yet. how about I do that now :)
[11:00] <bigjools> jml: that'd be smashing
[11:03] <lifeless> nightish, all.
[11:03] <wgrant> Night lifeless.
[11:03] <jml> lifeless: g'night
[11:08] <jml> bigjools: you're landing it on devel, I take it?
[11:08] <bigjools> jml: that's the plan
[11:25] <jml> bigjools: you're not doing getFile => deferred as part of this branch, right?
[11:25] <bigjools> jml: no, it's a lot of work
[11:25] <jml> bigjools: ok.
[11:26] <jml> bigjools: have you filed a bug about it?
[11:26] <bigjools> jml: no
[11:26] <jml> bigjools: that might be a good idea. you've noted a few places where it needs to change in this branch.  A bug number will make grepping easier later :)
[11:27] <wgrant> bigjools: Can you think of a good reason to keep the behaviour where we skip publication of series without a lucilleconfig? An uninitialised series can't have any publications, so there's nothing to be published, so it seems pointless.
[11:27] <bigjools> jml: I don't care about grepping, the few XXXes that are there are the tip of the iceberg.  I have a list on my desk of what needs to change on the delightful piece of cardboard that we used :)
[11:27] <wgrant> (plus it's all that's keeping me from dropping the column)
[11:28] <bigjools> wgrant: it was only being skipped to stop the publisher blowing up when it tried to get one that was not there
[11:28] <wgrant> bigjools: That's what I thought, thanks.
[11:28] <jml> bigjools: the bus factor for that is dangerously high
[11:28] <bigjools> jml: I know.
[11:29] <bigjools> jml: but it's not like someone else couldn't do what I did
[11:29] <bigjools> I can add XXXes though
[11:30] <bigjools> BTW I can thoroughly recommend the Finca El Fany from Hasbean.  Apart from having a hilarious name, it tastes delicious.
[11:31] <jml> :D
[11:31] <wgrant> Hmm. What's archivepublisher.root set to in the 'ppa' prod config?
[11:31] <jml> I'm on Sainsbury's coffee until I return from the states
[11:32] <bigjools> wgrant: why?
[11:32] <jml> the slave api needs to change
[11:33] <bigjools> the Sainsbury's ground colombian is very nice
[11:34] <wgrant> bigjools: I believe the code currently uses Ubuntu's lucilleconfig's temp directory (/srv/launchpad.net/ubuntu-archive/ubuntu-temp) for PPAs.
[11:34] <bigjools> wgrant: for doing what for PPAs?
[11:34] <wgrant> bigjools: One of my next few branches switches to ${archivepublisher.root}/ubuntu-temp instead.
[11:34] <wgrant> bigjools: It puts Sources and Packages in there first.
[11:34] <bigjools> oh ok, before the atomic-ish mv
[11:34] <wgrant> Yep.
[11:35] <bigjools> it's set to the directory that contains all the repos
[11:35] <bigjools> there's also a private_root
[11:35] <wgrant> It isn't in my old copy.
[11:35] <wgrant> That's the PPA root.
[11:35] <wgrant> Not archivepublisher.root.
[11:35] <bigjools> oh, meh
[11:36] <wgrant> I could change it, but we probably don't want the temp directory showing up under the Apache-served root...
[11:36] <bigjools> wgrant: ppa does not override the values used in the ubuntu publisher
[11:36] <wgrant> bigjools: Does it inherit from ftpmaster?
[11:36] <bigjools> yes
[11:37] <bigjools> well
[11:37] <wgrant> Ah.
[11:37] <bigjools> no
[11:37] <bigjools> I can't read today
[11:37] <wgrant> My copy of the configs is a year old, and I believe things have changed a bit since then.
[11:37] <wgrant> But by my reading it will inherit schema-lazr.conf's archivepublisher.root, which is /var/tmp/archive, which is probably wrong.
[11:38] <bigjools> yes it will use that
[11:38] <bigjools> even dogfood's config sets it.  Ha.
[11:38] <wgrant> :(
[11:38] <wgrant> Hah, to /srv/launchpad.net/ppa. How odd.
[11:39] <bigjools> not really
[11:39] <wgrant> But the PPA config doesn't set it to that...
[11:39] <bigjools> jml: what's up with the slave api, apart from the fact it's crap?
[11:39] <jml> bigjools: potato programming
[11:39] <jml> sendFile, sendFile, sendFile, sendFile, ...
[11:40] <bigjools> yeah that blows
[11:40] <jml> why not sendFiles?
[11:40] <jml> not only is it slower but it makes the client-side harder to write.
[11:41] <jml> I guess a good thing about this change is that now everything goes through BuilderSlave, so you could change the API for BuilderSlave to look like what you want the XML-RPC API to look like
[11:43] <bigjools> indeed, it's a nice layer of abstraction
[11:43] <wgrant> RecordingSlave is gone?
[11:43] <wgrant> Yay.
[11:43] <bigjools> totally gone
[11:43] <bigjools> the new manager.py is about 30% of the size
[11:43] <wgrant> I meant to read the diff, but it's sort of big.
[11:43] <jml> yeah
[11:44] <jml> wgrant: I'm skimming the diff and then going to look at the new manager.py & test_manager.py – the diffs for those are so big as to be useless
[11:44] <bigjools> jml: there's one more bug I need to fix in the code - the failure counting assumes there's always a job on the builder, but the scan can fail before that happens
[11:45] <bigjools> also I want to make it allow a few more failures on builders before killing them
[11:46] <jml> bigjools: isn't that last one just changing a constant somewhere?
[11:46] <bigjools> no
[11:46] <bigjools> the current code just checks that one is bigger than the other
[11:47] <bigjools> jobs hopping around builders failing need to be culled quickly.  builders  need a bit more leeway
[11:48] <wgrant> I think we need to be more careful about that, though.
[11:48] <wgrant> Since network issues can kill lots of builds that way.
[11:50] <bigjools> yes, I know, which is why builders need more leeway
[12:04] <deryck> Morning, all.
[12:42] <Ursinha> lifeless, running every 5 minutes now
[12:49] <LPCIBot> Project devel build (126): STILL FAILING in 3 hr 44 min: https://hudson.wedontsleep.org/job/devel/126/
[12:49] <LPCIBot> Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=631301] Prune CodeImportEvents.
[12:55] <wgrant> The PQM regex doesn't actually confirm that there's a commit message?
[13:11] <LPCIBot> Project db-devel build (79): STILL FAILING in 4 hr 8 min: https://hudson.wedontsleep.org/job/db-devel/79/
[13:16] <Ursinha> good morning launchpad
[13:22] <jml> done
[13:23] <wgrant> You finished Launchpad?
[13:23] <jml> Yeah, the end boss is tough
[13:24] <jml> actually, I finished reviewing the new buildd-manager code
[13:24] <wgrant> !!
[13:25] <jml> not as thoroughly as I'd review a normal branch, of course, but thoroughly enough.
[13:27] <wgrant> I feel that the branch could have a better name.
[13:27] <wgrant> It's a bit deceptive.
[13:27] <jml> yeah
[13:30] <jml> lazr.config.interfaces.ConfigErrors: ConfigErrors: schema-lazr.conf does not have a initialisedistroseries section.
[13:31] <wgrant> jml: That was fixed in devel r11715
[13:32] <wgrant> 11712, even.
[13:32] <jml> ahh right.
[13:32] <jml> hasn't made it to bigjools' branch then
[13:33] <bigjools> I've not merged devel today
[13:38] <bigjools> jml: pushed a new one up
[13:40] <jml> ta
[13:55] <bigjools> "make check" is still screwed. Grar.
[14:12] <mars> bigjools, 'make check' is deprecated.  We will not be fixing it.
[14:13] <bigjools> mars: wtf?
[14:13] <bigjools> so how do I run tests locally?
[14:13] <mars> bigjools, bin/test is the recommended way.
[14:14] <bigjools> mars: provided running it with no args runs all the tests, then fine.
[14:14] <bigjools> but I am intrigued as to why make check hangs half way through.
[14:15] <mars> bin/test runs everything.  IIRC there was no obvious reason behind the test hang.
[14:16] <mars> especially since bin/test had no issue
[14:17] <bigjools> indeed
[14:21] <jml> mars: why not delete it now?
[14:22] <mars> jml, the make check target?
[14:22] <jml> mars: yes
[14:22] <mars> it is still used by automated systems
[14:22] <bigjools> what does ec2/buildbot use?
[14:22] <mars> same
[14:22] <mars> 'make check'
[14:22] <bigjools> hmmm then I am quite concerned
[14:23] <mars> ?
[14:23] <mars> about what?
[14:23] <bigjools> why does it work for those and not locally, basically
[14:24] <bigjools> jml: I don't understand why you think some of the comments are obsolete in this branch.
[14:25] <jml> bigjools: hmm. gimme a sec and I'll explain why.
[14:26] <mars> jml, I should not have used the word 'deprecated'.  'make check' is not deprecated, but its use is not recommended for developer systems.  It is only intended for automated ones.
[14:26] <jml> bigjools: e.g.
[14:26] <jml> >     def _startCycle(self):
[14:26] <jml> >         # Same as _startCycle but the next cycle is not scheduled.  This
[14:26] <jml> >         # is so tests can initiate a single scan.
[14:26] <bigjools> jml: that one is ok
[14:26] <bigjools> jml: it's the "# Trap known exceptions..." one
[14:27] <bigjools> anyway I like lots of comments.  Comments are rarely bad unless they're misleading.
[14:27] <jml> bigjools: ahh right. What I mean there is that though the words are correct, it's incomplete, and the traceback/no-traceback thing isn't very interesting
[14:27] <bigjools> I think it is :)
[14:28] <bigjools> bitter experience of coming back to my own code 1 year later
[14:28] <jml> bigjools: in that case, fix the grammar :)
[14:29] <jml> bigjools: "Trap all errors. If it's a known error, log it; if it's not known, log it and include a traceback."
[14:29] <jml> bigjools: but the main point of the review comment is that _scanFailed does much more now.
[14:29] <bigjools> I love seeing a well placed semicolon.  I'm still searching. :)
[14:29] <bigjools> indeed, I'll spruce it up
[14:45] <jml> jelmer: is there a PPA somewhere with a version of testr with streaming result support?
[14:46] <jelmer> jml: Not that I'm aware of. Rob has done all of the testrepository packaging so far. AFAIK there are only packages in Debian and Ubuntu's main archive.
[14:47] <jelmer> It might be nice to set up a recipe build for testr.
[15:04] <jml> jelmer: yes
[15:32] <cody-somerville> jml, What you ever used twill? If so, whats your opinion of it?
[15:32] <cody-somerville> err
[15:32] <cody-somerville> *Have
[16:01] <jml> deryck: hello
[16:01] <deryck> hi jml.  on call
[16:01] <jml> deryck: can we have a call sometime this week to talk about UDS?
[16:01] <sinzui> jml, mumble?
[16:02] <jml> sinzui: yep
[16:02] <jml> sinzui: waiting
[16:03] <jml> cody-somerville: never used twill.
[16:04] <jml> sinzui: hello?
[16:06] <gary_poster> deryck: I decided to push bug 659697 back to you.  Maybe I'm being dense about our options, but right now I don't see a clear foundational solution, and even if it were, I think the degree we care about this use case is also an application-level decision.  Tell me what you think when you get around to it. :-)
[16:06] <_mup_> Bug #659697: [Wish] On-the-fly decompression of compressed attachments <Launchpad Bugs:New> <https://launchpad.net/bugs/659697>
[16:23] <deryck> jml, sure, I'd love to chat.  Early as possible this week actually.  Meant to ping already.
[16:24] <deryck> jml, can you calendar me a time that works for you?
[16:24] <deryck> gary_poster, I was wondering at first if it was apache settings to get content-type and content-encoding right so the brower would do the work....
[16:25] <jml> deryck: sure thing
[16:25] <deryck> gary_poster, but having poked briefly at it, I guess the change has to happen in the librarian server itself.
[16:25] <deryck> jml, thanks!
[16:26] <gary_poster> deryck: right, and if I understood correctly, the proposal was to always unzip, and then let the server do gzip encoding if the browser supports it
[16:27] <deryck> gary_poster, right.  As I understand it, too. :)
[16:27] <deryck> gary_poster, so I'm happy for bugs to own it, but like you, I doubt we'll make it a priority anytime soon.
[16:28] <deryck> I didn't know with the librarian being a shared resource who should own it either.
[16:28] <deryck> the whole "own" thing is silly, I know.
[16:28] <gary_poster> which...seems questionable, from the perspective of someone who feels fuzzy about the use cases.  My concerns would be how many browsers don't accept gzip, and how many people would *want* their browsers to display an arbitrarily-sized attachment rather than downloading it...
[16:29] <gary_poster> (sorry, that was a follow on from my first statement)
[16:29] <deryck> right, I agree with that, too.  Maybe we shouldn't do it.
[16:29] <deryck> aribitrary files are much different that static resources of css or js which other sites gzip and decompress on the fly.
[16:30] <gary_poster> right
[16:31] <gary_poster> but so, even if you kicked something off to us for implementation, my concerns were whether we *should* do it from an application/usability perspective.  Which seemed to be Not Me. ;-)
[16:33] <deryck> heh
[16:33] <deryck> gary_poster, I didn't think about the arbitrary size issue before.  You having said that makes me agree.
[16:34] <gary_poster> ok cool deryck :-)
[16:34] <deryck> I'm not even sure the alternate link idea is worth the effort either.  How much trouble is it letting the browser dialog guide you?
[16:39] <LPCIBot> Project devel build (127): STILL FAILING in 3 hr 49 min: https://hudson.wedontsleep.org/job/devel/127/
[16:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=jtv,lifeless][ui=none][bug=652280]
[16:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=None][bug=644196] Allow derivers to create a derived
[16:39] <LPCIBot> distroseries via the API.
[16:39] <gmb> Dear LPCIBot: Please stop setting off my highlight.
[16:47] <jtv> And mine.
[16:52] <maxb> lpcibot sould send notices, not messages
[17:09] <jml> and we should have a landing system that doesn't require reviewer nicks in the first line of the commit message
[17:15] <LPCIBot> Project db-devel build (80): STILL FAILING in 3 hr 44 min: https://hudson.wedontsleep.org/job/db-devel/80/
[17:15] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11735,
[17:15] <LPCIBot> 11736, 11737, 11738 included.
[17:53] <jml> g'night all
[17:56] <bigjools> night from me too
[19:06] <sinzui> jcsackett, how many hours do you estimate it would take you to update that JoinNotAllowed raises a 403 over the API https://bugs.edge.launchpad.net/launchpad-registry/+bug/244527
[19:06] <_mup_> Bug #244527: JoinNotAllowed should cause a 400 response when raised on the API layer <api> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/244527>
[19:10] <jcsackett> sinzui: the exception just needs to be moved into lp.registry.errors and have a webservice code assigned to it.
[19:10] <sinzui> jcsackett, 2 hours?
[19:10] <jcsackett> assuming i don't get into import hell and the tests are easy, probably 1-2, yes.
[19:10] <sinzui> okay. thanks
[19:44] <lifeless> moin
[19:44] <lifeless> Ursinha: awesome
[19:56] <mtaylor> moin lifeless
[20:06] <lifeless> hi mtaylor
[20:14] <LPCIBot> Project devel build (128): STILL FAILING in 3 hr 35 min: https://hudson.wedontsleep.org/job/devel/128/
[20:14] <LPCIBot> * Launchpad Patch Queue Manager: [r=jelmer][ui=none][no-qa] Extract a few refactorings and tests from
[20:14] <LPCIBot> the abandoned check-in-wadl branch.
[20:14] <LPCIBot> * Launchpad Patch Queue Manager: [r=gary][ui=none][no-qa] update lazr.restful to the latest released
[20:14] <LPCIBot> version (0.14.0)
[20:15] <LPCIBot> * Launchpad Patch Queue Manager: [r=michael.nelson, stevenk,
[20:15] <LPCIBot> julian.edwards][ui=none][bug=653720] Commit after changing build
[20:15] <LPCIBot> status in the upload processor.
[20:15] <lifeless> bac: hi
[20:26] <gary_poster> Is this kind of thing expected when you try to view MPs on staging?  If not, is it indicative of staging's librarian having fallen over?  That's my impression of the traceback a skim of the pertinent code: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1752S202
[20:28] <lifeless> mmm
[20:28] <lifeless> no, its a 404
[20:28] <lifeless> it means 'the librarian is running but couldn't get your shit'
[20:29] <lifeless> now the staging librarian is /meant/ to fallback, at least for public stuff, to the main librarian.
[20:31] <gary_poster> oh, just saw reply
[20:56] <jam> abentley: ping
[20:56] <jam> mwhudson: ping about lp-service
[20:57] <abentley> jam: pong
[20:57] <mwhudson> jam: ping
[20:57] <mwhudson> jam: ah crap, i didn't reply in the end did i?
[20:57] <mwhudson> jam: basically i think it looks ok
[20:57] <jam> mwhudson: I updated the test suite, I'm not sure if it is fully tasteful, but the test suite passes for me
[20:58] <jam> abentley: want to skype? I responded to your email, but it may be faster to iterate vocally
[20:58] <mwhudson> jam: using fixed paths to communicate between subprocesses is (sadly) how it's done in lp tests currently
[20:58] <jam> mwhudson: le sigh
[20:58] <abentley> jam, sure.  I don't see your reply yet.
[20:58] <jam> abentley: just sent, may take a couple mins
[20:58] <mwhudson> jam: lifeless is fixing that right now though :-)
[20:59] <jam> yeah, I've been reading the discussion on the parallel running, etc.
[20:59] <mwhudson> jam: he also suggested that you might want to make your helper class subclass Fixture
[20:59] <mwhudson> to make the transition away from layers that smidgeon easier
[21:00] <jam> mwhudson: I'd be happy to if I understood Fixture. Can you give any pointers there?
[21:00] <mwhudson> jam: http://pypi.python.org/pypi/fixtures/0.3.2
[21:01] <flacoste> lifeless: hi
[21:01] <mwhudson> jam: oh yeah, at the atexit calls are a bit crazy
[21:06] <lifeless> flacoste: hi
[21:07] <flacoste> lifeless: skype?
[21:07] <lifeless> yes, its hanging there o connecting
[21:09] <mwhudson> jam: i posted another comment on the mp
[21:57] <wgrant> abentley: The chroot *does not provide security*.
[22:05] <wallyworld_> morning
[22:09] <abentley> wgrant: elmo appears to believe otherwise, because he didn't have a problem with it being possible to run that code inside a chroot on a non-VM machine.
[22:12] <wgrant> elmo: We install build-deps as root. Are the buildd kernels somehow protected from usual chroot escapes?
[22:15] <rockstar> mars, gary_poster, FYI, I've seen your emails, and will make sure you have a reply in the morning.  Is that okay?
[22:15] <gary_poster> rockstar: absolutely.  thank you
[22:16] <gary_poster> rockstar: we're intending to have hands ready to work on this on Wednesday, so you know.
[22:34] <LPCIBot> Project db-devel build (81): STILL FAILING in 4 hr 7 min: https://hudson.wedontsleep.org/job/db-devel/81/
[23:00] <mwhudson> Conflict adding file lib/canonical/launchpad/apidoc.  Moved existing file to lib/canonical/launchpad/apidoc.moved.
[23:00] <mwhudson> what *again*?
[23:02] <benji> mwhudson: that's my fault; a fix will be comitted momentarily
[23:02] <mwhudson> benji: heh, i don't know if it's worth fixing once the deed is done
[23:03] <benji> there are other bits that *are* worth fixing :/
[23:21] <mwhudson> hey guess what
[23:21] <mwhudson> there's a blueprints pagetest that's misnamed and not run by default (i think)
[23:21] <mwhudson> surprise surprise it fails
[23:22] <mwhudson> ah maybe not
[23:27] <thumper> testfix mode :-(
[23:49] <LPCIBot> Project devel build (129): STILL FAILING in 3 hr 34 min: https://hudson.wedontsleep.org/job/devel/129/
[23:49] <LPCIBot> Launchpad Patch Queue Manager: [r=edwin-grubbs][ui=none][bug=612754] remove the trailing whitespace
[23:49] <LPCIBot> as
[23:49] <LPCIBot> part of the newline canonicalization when checking the GPG signature of
[23:49] <LPCIBot> incoming email


[10:42] <xnox> so trying the daily cd. at the end of the install linux-generic is removed & i am left with: initrd.img-3.5.0-17-generic; vmlinuz.efi-3.5.0-17-generic vmlinuz.efi-3.5.0-17-generic.efi.signed
[10:42] <xnox> (under /boot)
[10:42] <xnox> no vmlinuz in /
[10:42] <xnox> and update-grub only looks for "vmlinuz-*"
[10:43] <cjwatson> I thought I fixed that yesterday
[10:43] <cjwatson> Are you trying amd64?
[10:43]  * xnox checks which cd I have.
[10:43] <xnox> yes.
[10:43] <cjwatson> It failed to build today
[10:43] <cjwatson> You could try just upgrading to ubiquity 2.13.3 first
[10:44] <xnox> yeah. let me do that, as it's 2.13.2
[10:44] <cjwatson> I'll be able to rebuild the image after this publisher run has finished
[10:46] <xnox> running the install now =)


[00:02] <ToyKeeper> robru: Any idea what landed in krillin rc-proposed 196?  I'm getting weird power results ever since then.
[00:02] <robru> ToyKeeper: dunno, sorry.
[00:02] <robru> ToyKeeper: sil should have the changelogs somewhere
[00:03] <robru> ToyKeeper: apparently this http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/196.commitlog
[00:05] <ToyKeeper> robru: Thanks.  :)
[00:05] <robru> you're welcome
[00:05] <ToyKeeper> Also, ... it worries me that that seems to be the rev which fixed the dbus UI freezes.
[00:11] <ToyKeeper> I wonder why it's just krillin.
[00:39] <robru> hold on, irc bot ping spam incoming...
[00:43] <michi> robru: I consider myself spammed… :)
[00:43] <robru> oh this is just the start!
[00:43] <robru> actually this isn't half as bad as I'd anticipated
[00:45] <ToyKeeper> That sinking feeling when you realize the top bugfix for this release is probably what caused the issue you're investigating.
[00:47] <robru> :-/
[01:09] <robru> oh, there it is
[07:49] <Mirv> robru: out of interest, why trusty packages in overlay?
[07:49] <Mirv> something train related?
[08:11] <robru> woot, train is now self hosting.
[08:12] <robru> Mirv: oh hey. yeah the train is now self-hosting, so when i want to roll out a train update I have to use the train to do it. those trusty packages are just some backports of packages that are necessary for the train to build in a trusty silo.
[08:13] <veebers> robru: wow you're still up? :-)
[08:13] <robru> Mirv: those packages shouldn't bother anybody as a) they're trusty packages and b) they're not part of any default seed for anything.
[08:13] <robru> veebers: only midnight ;-)
[08:13] <Mirv> robru: thanks, useful to know! and yes they don't bother anybody.
[08:13] <veebers> robru: lol :-P Hey, maybe you can tell me, how do I change the QA signoff status? I would like to publish my silo now that I've fixed and tested it
[08:14] <robru> veebers: if you click edit on your ticket it's a drop-down you can pick a value from
[08:14] <veebers> ah, right. Had to be an easy one :-) Cheers
[08:14] <robru> you're welcome
[08:15] <veebers> robru: awesome, have clicked publish now
[08:15] <robru> veebers: did it work or do you need an ack?
[08:15] <veebers> robru: I don't think it worked /me checks now
[08:16] <veebers> robru: hah "Publish failed: veebers not authorized to upload autopilot", are you able to help me out? :-)
[08:16] <robru> veebers: no can do unfortunately. sil should be around soon... or maybe Mirv can do it if it's just a universe package
[08:16] <robru> Mirv: we now have this hilarious changelog: http://bazaar.launchpad.net/+branch/cupstream2distro/view/head:/debian/changelog
[08:17] <veebers> robru: cheers will ask
[08:17] <veebers> Mirv: are you available to help me out publishing autopilot? :-)
[08:33] <Mirv> veebers: sure
[08:35] <veebers> Mirv: awesome, thanks :-)
[08:35] <Mirv> veebers: publish done
[08:35] <Mirv> no problem
[08:36] <veebers> Mirv: sweet thanks for that. Does that manual acking thing need looked at? I got pitti to ack them in the MP
[08:36] <Mirv> veebers: yes, I looked through it, not much to look (adding python-tz to deps)
[08:36] <veebers> Mirv: awesome, thanks again
[09:29] <sil2100> dbarth, seb128: I briefly looked at the new package in silo 60 (signon-plugin-sasl) and didn't see any obvious issues
[09:30] <seb128> k, I'm going to have a look
[09:30] <sil2100> seb128: could you do a preNEW review of that? Since we don't have a NEW queue in the overlay I would like to know the ubuntu archive opinion earlier than in xenial NEW :)
[09:30] <sil2100> Thanks!
[09:30] <seb128> yw
[09:35] <dbarth> cool, keep us posted
[10:06] <Mirv> sil2100: so just FYI a faulty upload from Kubuntu broke all of KDE autopkgtests so the nice was wasted, pitti has now triggered a rerun of all failed tests after the fix was done... so surprise, more waiting
[10:06] <Mirv> s/nice/night/
[10:07] <Mirv> sil2100: and because of that we don't have up-to-date status on whether everything on all other fronts is good. it looks good from Qt+autopkgtest side from what can be understood, but the poppler transition and s390x are mixed to the same soup
[10:08] <pstolowski> hey trainguards, question, since when do we build on s390x architecture? just got this https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-054/+build/8413690 and i think i've never encountered s390x before...
[10:08] <Mirv> sil2100: I asked if the Kubuntu guys could hold any big KDE landings for a while if possible. if now a new KDE comes we can say goodbye to this whole week and probably next too.
[10:08] <Mirv> pstolowski: since last night as announced on mailing list
[10:08] <sil2100> ;/
[10:09] <sil2100> pstolowski: yeah, slangasek sent out an announcment to the phone ml
[10:09] <pstolowski> Mirv, sil2100 ah, indeed, looking :). thanks
[10:10] <Mirv> pstolowski: surely you'll want the Scopes work on your nearest mainframe, don't you? (in reality s390x can be mostly just ignored for now)
[10:10] <Mirv> IBM System Z - now with scopes!
[10:10] <pstolowski> :)
[10:11] <robru> pstolowski: train should already be smart enough not to block on s390x failures, let me know if anything explodes
[10:12] <pstolowski> robru, cool, thank you
[10:12] <robru> Yw
[10:15] <robru> pstolowski: yeah it reports unity-scopes-shell as successful even with the s390x failure, good
[10:15] <pstolowski> robru, yep
[12:42] <t1mp> is there a problem with CI? On https://jenkins.qa.ubuntu.com/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-vivid-armhf-ci/1321/console I don't see what is going wrong
[12:42] <t1mp> I only see this wrong: /tmp/buildd/ubuntu-ui-toolkit-1.3.1705+16.04.20151120.1bzr1753pkg0vivid1321/tests/unit/tst_units/dpr1/dpr1: error while loading shared libraries: libUbuntuComponents.so: cannot open shared object file: No such file or directory
[12:42] <t1mp> but I don't know the cause
[12:42] <t1mp> cihelp: ^
[12:48] <psivaa> t1mp: let me take a look
[12:48] <t1mp> thanks
[12:52] <psivaa> t1mp: i think the failure is due to what logged below 'dh_auto_test in virtual frame buffer failed...'
[12:53] <psivaa> t1mp: i remember seeing this in one of the i386 builders before, due to some issues on it. let me try to take a look
[13:25] <t1mp> psivaa: ok, thanks for checking it out. Let me know if you find something.
[13:32] <psivaa> t1mp: Looks like there were some 'Xvfb' processes left running and they appeared to have the issue on cyclops-node10
[13:32] <psivaa> I'm running the failed job in another node http://s-jenkins.ubuntu-ci:8080/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-vivid-armhf-ci/1326/console
[13:44] <jibel> Mirv, can we have a silo with the fix for power consumption and without the desktop fix. As I understand it bug 1523975 is desktop only and has no impact at all on the phone, and I don't want to introduce more risk into 8.5
[13:44] <jibel> OTA8.5
[13:45] <Mirv> jibel: ok, creating another silo
[13:45]  * Mirv starts to hold world record for silos
[13:46] <Mirv> jibel: actually, we don't have such a patch directly in existence
[13:46] <sil2100> Desktop regression with OTA-8.5 ?
[13:46] <Mirv> looking if one could be created by interdiffing
[13:49] <jibel> sil2100, you need package from the vivid overlay installed on a vivid desktop
[13:49] <jibel> sil2100, system-settings + qt packages from the overlay
[13:50] <Mirv> jibel: the system-settings crasher fix is just https://launchpadlibrarian.net/229160772/nmbearer-system-settings-fix.diff - do you want that part to be reverted? the whole interdiff between currently landed and the new on - that check, plus removing of code. I think we'd rather need awe's look on the rest of the patch and decide if it's of any use or not (the wifi part is just "potentially fixing")
[13:50] <Mirv> jibel: http://paste.ubuntu.com/13858649/ - I was supposed to link that in the middle
[13:53] <jibel> Mirv, okay, lets wait for Tony's feedback. Meanwhile we are testing the silo as it is.
[15:14] <t1mp> psivaa: did the other job finish running? And should it appear on my MR page? https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/pageHead-sectionsIndex/+merge/279834
[15:14] <t1mp> I don't think I'll get approval to merge that until I have good test results
[15:22] <psivaa> t1mp: i had only triggered the failed downstream job. For the MP to get updated, the whole set needs to be rebuilt.
[15:22] <psivaa> t1mp: i've triggered it here: http://s-jenkins.ubuntu-ci:8080/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-ci/2597/
[16:19] <tvoss|dinner> trainguards, could you show some love to the publisher: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-046/+packages
[16:19] <tvoss|dinner> trainguards, it's taking ages to complete
[16:19] <tvoss|dinner> trainguards, where ages means: longer than usual ;)
[16:20] <sil2100> uh oh ;p
[16:20] <sil2100> tvoss|dinner: I think there's not much we can do here, it's supposed to run periodically, but maybe it's busy with publishing a lot of binaries in the archive
[16:21]  * tvoss|dinner hugs the poor little publisher :)
[16:21] <tvoss|dinner> okay, some more dinner then
[17:03] <psivaa> t1mp: https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/pageHead-sectionsIndex/+merge/279834 is looking good on jenkins now
[17:50] <cjwatson> tvoss|dinner: We applied a Launchpad database schema patch this afternoon, and that requires stopping long-running jobs such as the publisher for a little while.  It's been back for a while now.
[18:17] <ChrisTownsend> trainguards: Are s390x Xenial build failures expected? https://launchpadlibrarian.net/229503357/buildlog_ubuntu-xenial-s390x.libertine_0.99.7%2B16.04.20151209-0ubuntu1_BUILDING.txt.gz
[18:22] <dobey> ChrisTownsend: given https://launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/5.5.1-2ubuntu1/+build/8388169 i'd guess that anything depending on that would also fail to build, yeah :)
[18:22] <ChrisTownsend> dobey: Ah, ok, that explains it.  Thanks
[18:28] <pmcgowan> jibel, dobey has silo 23 ready
[20:48] <t1mp> psivaa: cool, thanks for checking it.


[01:24] <knosys> sorry i have no extra monitor , just tv and missing a second hdmi cable for reproduce it
[01:25] <knosys> oh that was a while ago :P
[10:10] <sidi> Pwnna, not sure what is extend (am running on Arch). I have no trouble wildly disconnecting my second monitor though. Can try to reproduce xrandr to internal only and then wild disconnect but not sure it'll help. in any case im tempted to say regardless of whether the bug is reproducible, the error handling behaviour in xfsettingsd could be defined better
[10:45] <ali1234> i use nvidia driver and disconnect monitors all the time. i also have no idea what extend means
[10:48] <knosys> Pwnna , ali1234 extend dekstop to 2 monitors, instead of having one different desktop on each monitor
[10:48] <ali1234> i didn't know there was any other way to do it?
[10:48] <knosys> there is other ways
[10:49] <knosys> its different when you extend it
[10:49] <knome> i'd call that mirroring, not extending
[10:49] <knosys> you can have a window in half of both monitor at the same time
[10:49] <knosys> do you know what i mean?
[10:49] <ali1234> yes, i know what you mean
[10:49] <ali1234> this is the default method of doing multimonitor on nvidia, anything else would be pointless
[10:49] <knosys> thats what i understand from "extend monitor"
[10:50] <ali1234> why would you specifically choose not to be able to drag windows across monitors?
[10:51] <knosys> you can duplicate the image
[10:51] <knosys> for example
[10:51] <knosys> or just disable one , and enabling the other..
[11:04]  * ochosi is back after a long weekend
[11:04] <ochosi> anything important i missed?
[11:04] <ochosi> did anyone manage to get a hold of xnox?
[11:05] <knome> nope
[12:39] <ali1234> sidi: i just watched your XDC talk
[12:42] <sidi> ali1234, cool, any feedback/thoughts?
[12:42] <sidi> (especially negative :P)
[12:43] <ali1234> is there any implementation of WSM that works? for example, i can write a program that requests WSM_SCREENSHOT and libwsm will either allow or deny it, but then what happens?
[12:44] <ali1234> i mean, after i get permission to do something, how do i then actually do it?
[12:57] <sidi> We have a prototype that needs to be hooked and implemented by compositor devs who want to try it out
[12:57] <sidi> Martin will make a Weston implementation when he's back from holidays
[12:57] <sidi> the program just uses the normal API and then gets a response based on the policy
[12:57] <sidi> most of the API isnt designed in Wayland actually
[12:58] <sidi> because noone wanted to do it wrong :P
[12:58] <ali1234> what is the "normal" API for eg WSM_SCREENSHOT though?
[12:58] <sidi> so i'm currently designing API
[12:58] <sidi> i dont think there is one yet
[12:58] <sidi> basically getting a framebuffer of the entire screen would be that API
[12:58] <sidi> currently it shouldnt be possible in pure Wayland (dunno about XWayland)
[12:59] <sidi> so basically libwsm tells compositor developers "place a hook in this function, and then get a reply from whatever backend is in use"
[12:59] <sidi> in practice, libwsm is just a draft
[12:59] <sidi> it'll change and improve
[12:59] <sidi> was more meant for KDE/GNOME/E19 and Weston devs to poke around and get their requirements written
[12:59] <sidi> for app developers this is irrelevant
[12:59] <sidi> all they need to do is to tell us what permissions they need
[13:00] <sidi> in a separate file, a bit like a .desktop file
[13:00] <sidi> packagers and distros are then free to modify these permission files if they disagree
[13:00] <ali1234> i see that as a problem
[13:00] <sidi> why?
[13:00] <ali1234> because desktop developers don't need permissions, app developers do
[13:00] <ali1234> if you ask GNOME what permissions they want to export, they'll say "none"
[13:01] <sidi> ali thats not what i meant
[13:01] <sidi> what i mean is, desktop compositor developers are responsible for using the library
[13:01] <sidi> to verify that a specific app has permission
[13:02] <sidi> so, if i implement in an hypothetical wayland xfce compositor a method for taking a screenshot
[13:02] <sidi> i would call libwsm with the wayland socket of the requesting client
[13:02] <sidi> libwsm would find the client, find the backend and policy used on the OS, and would return one of several possible recommendations
[13:02] <sidi> and then compositor must decide what to do with this
[13:03] <sidi> app developers provide a file with their source that tells what their app does, and distros verify it when packaging the app
[13:03] <sidi> (which is what windows, ios, os x and android do, virtually)
[13:03] <ali1234> so my point is, what's the point of a cross-DE permissions system, if there is no cross-DE API for it to protect?
[13:03] <sidi> then everyone is free to provide GUIs of their liking, the API is flexible and so generic and dumb you can do whatever you want with it
[13:03] <sidi> the API is meant to be cross-DE
[13:03] <sidi> Wayland essentially defines an API, but some bits are not done yet
[13:04] <ali1234> that's not what they told me
[13:04] <sidi> for instance Weston has a custom Fullscreen API because people (gnome/weston/kde/tizen) havent standardised it yet
[13:04] <sidi> most API should be X-DE
[13:04] <ali1234> wayland developers told me wayland will never implement these things by design
[13:04] <sidi> otherwise theres no point to doing Wayland
[13:04] <ali1234> well yeah, that's what i said
[13:04] <sidi> well wayland doesnt implement things, it's just a spec
[13:05] <sidi> ali1234, Martin who was working with me just informed me he pushed libwsm into libwayland
[13:05] <sidi> so yeah i would assume that some of the API will be standardised
[13:05] <sidi> i would also assume some of it will not, because only some DEs implement it
[13:05] <sidi> this is very grey area so far, most of this work has yet to be done...
[13:07] <sidi> ali1234, who is it you talked to?
[13:07] <ali1234> jasper mainly
[13:13] <sidi> yeah
[13:14] <sidi> Jasper explicitly stated that he thinks libwsm is stupid and that we dont understand security
[13:14] <ali1234> lol
[13:14] <sidi> he also does not seem keen at all on anything being cross-DE
[13:14] <sidi> so you know..
[13:15] <ali1234> so here's a thing, did you think about this situation? say a compositor has one single API to intercept both keyboard and mouse, which permission does it request? can it requests both at once, or do you get two requests sequentially?
[13:15] <sidi> so, in the case it has a single API it does not mean the calls are not separate dwithin this API
[13:16] <sidi> i fail to see how a client can need within an atomic call to modify both mouse and keyboard
[13:16] <sidi> i've never seen such API in my life
[13:16] <ali1234> well it might be that the compositor just designed the api that way
[13:16] <sidi> in any case if it were to exist, either the compo dev believes this is really a combined use of both APIs, and it requires both permissions
[13:16] <sidi> or the dev believes the semantics dont match and that API has another purpose (and morei mportantly a different attack surface / threat model) and then a new permission can be made
[13:16] <sidi> and integrated into the backend i wrote
[13:17] <sidi> ali1234, move_keyboard_and_mouse_at_the_same_time (...)? :P
[13:17] <ali1234> it was just an example
[13:17] <sidi> well, you're right this situationwill occur
[13:17] <sidi> libwsm is just a prototype, not an injunction
[13:18] <sidi> i think jasper took it as "two idiots who never wrote a compositor are telling me what to do and they have no clue what we actually need". it's partly a fair point and partly the fact that he didnt get a specification or a list of requirements for his security model, yet he is close to feature parity with X
[13:19] <sidi> we've made something dumb and simple and we're essentially asking DEs to identify how this dumb thing fails them, so we can try to develop something that matches requirements for each major DE and has decent flexibility for the future
[13:19] <ali1234> i disagree that any wayland compositor has anywhere near close to feature parity with X
[13:19] <sidi> doesnt GNOME Shell have fullscreen, screenshot, clipboard?
[13:19] <sidi> well they probably still use the old X APIs actually
[13:20] <ali1234> yeah it has them if you are using the GDK X backend
[13:20] <sidi> but they want to switch this to default in Fedora/GNOME asap dont they? which means "we wont change the APIs"
[13:20] <ali1234> in the wayland backend it's all //TODO: implement this
[13:20] <ali1234> and there's no way to implement it
[13:20] <sidi> the problem is the clipboard API especially is broken, it allows too many attacks and even worse it doesnt even allow apps to do basic stuff in a secure way (you cant query the type of data in the clipboard to check if your app supports it without pulling the data)
[13:21] <ali1234> also fullscreen, screenshot, clipboard is nothing like feature parity anyway
[13:21] <sidi> (errata to what i've said before, my friend didnt push libwsm into libwayland-trunk but into a testing branch of libwayland :p)
[13:21] <sidi> fair enough
[13:21] <ali1234> you need things like WSM_RAISE_FOCUS_OTHER, WSM_POSITION_RESIZE(_OTHER)
[13:21] <sidi> good points
[13:21] <ali1234> ability to get information about other clients
[13:23] <ali1234> even maybe ability to draw into other client's surfaces
[13:23] <ali1234> or at least around them :)
[13:23] <sidi> that really should be done via IPC or UI composition
[13:23] <sidi> either the apps collaborate to produce something, or clearly separated UI elements are embedded within one another
[13:24] <sidi> if you have other ideas of capabilities, or issues with the existing ones do ping me ali1234 !
[13:26] <ali1234> also, why is screenshot and screensharing separate?
[13:26] <ali1234> if i get screenshot permission, can't i just keep doing it over and over?
[13:26] <ali1234> you could ask every time, but that is going to get annoying
[13:27] <ali1234> most likely the screenshot tool is just going to be set to "always allow" by the packager
[13:27] <ali1234> in which case they've defacto received screensharng permission to
[13:28] <ali1234> i suppose something like skype you would want it to ask permission every time
[13:30] <ali1234> also worth considering that there are input devices other than keyboard and mouse
[13:31] <ali1234> like joysticks for example, or leap motion, or oculus rift head tracker
[13:31] <ali1234> or other weird haptic things
[13:34] <ali1234> although i suppose the "core pointer" as X calls it is not really tied to any specific hardware, it's an abstraction
[13:37] <ali1234> i should subscribe wayland-devel
[13:57] <ochosi> folks, i won't make tomorrow's meeting, it's unfortunate, but it's a conflict of appointments :/
[13:57] <ochosi> or: another conflict....
[13:59] <knome> that's okay, the meetings are much more pleasant without you whining anyway
[13:59] <knome> oops ;)
[13:59] <knome> no seriously, meh, but maybe you're around and available at other times tomorrow if somebody needs something?
[14:02] <ochosi> heh
[14:02] <ochosi> yeah, i'll try to be
[14:02] <knome> VV is called Vivid Vervet
[14:02] <ochosi> at least during what is my morning
[14:02] <knome> http://www.markshuttleworth.com/archives/1425
[14:02] <ochosi> oh
[14:02] <ochosi> hadnt read that yet
[14:03] <knome> yeah, just accidentally bumped into that when checking the planet
[14:27] <elfy> respins tomorrow
[14:27] <ochosi> hey elfy
[14:27] <elfy> hi ochosi
[14:46] <GridCube> the xfce4-weather-plugin is failing, see https://forum.xfce.org/viewtopic.php?id=9163 , fixed version is 0.8.3-5 apparently, trusty ships -1, and utopic will -2, so it will fail
[16:40] <skellat> I guess we're not going to eat anybody's lunch in 15.04 :-( http://www.markshuttleworth.com/archives/1425
[20:16] <Unit193> "Document es/index.xml does not validate" dangit.
[20:17] <Unit193> migrating-upgrading.xml:315, settings-preferences.xml:373, media-apps.xml:323.
[20:18] <knome> Unit193, oi, fail :)
[21:12] <brainwash_> bluesabre: https://code.launchpad.net/~brunonova/ubuntu/trusty/xubuntu-default-settings/lp1310264/+merge/238935
[21:13] <brainwash_> it's a minor UI change, so the fix has not been backported yet
[21:13] <knome> https://twitter.com/RLUK_Mike/status/517243907193970688
[21:14] <Unit193> knome: Nice.
[21:45] <knosys> who is that? :D
[21:46] <knosys> i should already know right ? xD