[00:10] <menn0> thumper, axw or wallyworld: review pls  http://reviews.vapour.ws/r/3073/
[00:11] <menn0> this makes a feature test i'm writing a lot cleaner
[00:13] <thumper> menn0: done
[00:13]  * thumper goes to walk the dog in the sun
[00:13] <menn0> thumper: thanks
[00:40] <davecheney> OH WOW
[00:40] <davecheney> the maas provider demands yaml.v2
[00:41] <davecheney> but also calls a utilty function with requires yaml.v1
[01:35] <davecheney> mgz_: thumper http://reviews.vapour.ws/r/3074/
[01:35] <davecheney> please view
[01:35] <davecheney> should break the arguments about which version of yaml.v2 juju/utils can use
[01:36] <davecheney> also, spot the WTF in that pach
[01:36] <davecheney> also, spot the WTF in that patch
[01:56] <natefinch> davecheney: heh, looks familiar: https://github.com/natefinch/atomic/blob/master/atomic.go#L17
[01:57] <natefinch> davecheney:  looks like I should steal some safeguards from yours, though.
[01:58] <perrito666> mm, the chmod wont work in windows, but since it is not tested it wont break anything either
[01:58] <natefinch> perrito666: chmod is just a noop on winows
[01:58] <perrito666> natefinch: not entirely
[01:58] <perrito666> there is an implementation in go that does something stupid
[01:59] <perrito666> it changes fs properties for the file but these are ignored by windows
[01:59] <natefinch> effectively a noop :)
[02:00] <perrito666> natefinch: well the fact that those things can be changed means that something is using them
[02:00] <perrito666> I have no clue what that is
[02:00] <perrito666> most likely windows 3 :p
[02:02] <thumper> menn0, davecheney, axw: team meeting
[02:07] <natefinch> davecheney: seems like this must be a bug: http://reviews.vapour.ws/r/3074/#comment19133
[02:33] <davecheney> coming
[02:33] <davecheney> oh
[02:33] <davecheney> i'm 33 mins late
[02:36] <davecheney> natefinch: thanks for your comments
[02:37] <davecheney> PTAL
[02:37] <natefinch> davecheney: we're still talking on the hangout btw
[02:37] <davecheney> ok, coming
[02:49] <natefinch> davecheney: tests?
[02:52] <natefinch> thumper: Looking at that retry package, seems like it would be useful to be able to encapsulate call args into a value, and then be able to call value.Call(somefunc) .... so you could use the same retry semantics with any number of different functions.  Also it then doesn't hide the function you're retrying inside a huge list of args.
[02:53] <natefinch> thumper: also you should call the package sisyphus
[02:56] <davecheney> natefinch: this is only temporary
[02:56] <davecheney> once everyone is at yaml.v2 i'll be deleting those forks
[02:56] <davecheney> my goal is not to move code from other packages into juju
[02:56] <davecheney> in fact the opposite
[02:56] <davecheney> but this yaml.v2 dep keeps fucking that plan up
[03:08] <cherylj> what's the difference between stateaddresses and apiaddresses in agent.conf?
[03:10] <cherylj> thumper, menn0 ^^ ?
[03:11] <menn0> cherylj: iirc stateaddresses has the mongodb server addresses and apiaddresses is the API server addresses
[03:12]  * menn0 checks something
[03:13] <thumper> natefinch: interesting idea
[03:13] <menn0> cherylj: yep, that's right
[03:13] <thumper> natefinch: and pretty easy to implement
[03:14] <menn0> cherylj: really stateaddresses shouldn't be there except on the state/controller servers, but it is
[03:14] <cherylj> ok, thanks, menn0
[03:14] <menn0> cherylj: it's probably a historical vestiage - non state agents used to connect directly to mongo for some things
[03:15] <thumper> menn0: could I get you to cast your eyes over http://reviews.vapour.ws/r/3072/ ?
[03:15] <thumper> cherylj: menn0 is right in his musings :)
[03:18] <menn0> cherylj: related tidbit: a lot of (probably older) code uses "state" to mean "the mongodb server". not at all confusing.
[03:18] <menn0> thumper: looking
[03:18] <cherylj> ha, ok :)
[03:25] <natefinch> thumper: also, if you're going to make retry a standalone package, you gotta move clock into a standalone package
[03:26] <thumper> natefinch: axw is moving the clock out in his one
[03:26] <natefinch> thumper: awesome
[03:26] <thumper> natefinch, axw: although perhaps we should have a common top level one...
[03:26] <thumper> axw: perhaps juju/clock ...
[03:26] <axw> natefinch: FYI, this is the branch talked about on the call: https://github.com/axw/juju-time
[03:26] <axw> thumper: I was thinking juju/time/clock, but *shrug*
[03:27] <natefinch> thumper: yeah. thats what I meant, just juju/clock
[03:27] <thumper> axw: I was thinking more to have a common parent for the scheduler one too, rather that the clock with the scheduler
[03:28] <axw> thumper: yes, definitely not in the one package
[03:28] <axw> we have enough utils already :)
[03:28] <thumper> I was thinking not in the same repo
[03:28] <thumper> agreed
[03:34] <natefinch> thumper: btw, I think the error handling in your retry code could be improved by following davecheney's advice to assert behavior: http://dave.cheney.net/2014/12/24/inspecting-errors   .. so like have a 'Last() error' method on the error types, etc.
[03:35]  * thumper looks
[03:35] <menn0> thumper: well that sucked. review done. lots of stuff missed.
[03:35] <thumper> menn0: :(
[03:35] <menn0> thumper: the review process sucked... not the PR
[03:35] <thumper> menn0: it isn't complete...
[03:35] <thumper> geez
[03:35] <thumper> there is another one following...
[03:35] <thumper> I think
[03:35] <thumper> at least
[03:35]  * thumper looks
[03:36] <menn0> thumper: there's lots of test names that still say System and bits of help text missed and a few other things
[03:36] <thumper> ok
[03:37] <menn0> thumper: I basically just did a search in my browser for "system" looked to see if it came up on the right side of the diff :)
[03:37] <menn0> thumper: also "server" comes up a bit
[03:37]  * thumper sighs
[03:37] <menn0> not sure if you're fixing those
[03:37] <thumper> so much stuff to change
[03:42] <natefinch> I can't believe we're spending so much time just to change the names of things, instead of, like, implementing features.
[03:44] <natefinch> oh yeah, hey, I had a 1.26-alpha1.1 server running, and tried to interact with it via a client built from master, and was getting this error message printing out with a lot of my commands: 2015/11/04 21:27:00 warning: discarding cookies in invalid format (error: json: cannot unmarshal object into Go value of type []cookiejar.entry)
[03:47] <natefinch> davecheney: what's wrong with this picture? https://github.com/juju/persistent-cookiejar/blob/master/jar.go#L10
[03:50] <davecheney> natefinch: the type isn't public ?
[03:50] <natefinch> davecheney: repo name is "persistent-cookiejar" :/
[03:50] <natefinch> package name is "cookiejar
[03:50] <davecheney> oh for fucks sake
[03:51]  * davecheney throws something
[03:51] <natefinch> also, using that package seems to break client-server compatibility
[03:51] <natefinch> I saw this:
[03:51] <natefinch> $ juju destroy-environment local -y
[03:51] <natefinch> ERROR cannot connect to API: cannot load cookies: json: cannot unmarshal object into Go value of type []cookiejar.entry
[03:52] <natefinch> whewn my client was a different version than my server... presumably one of them was using the old cookiejar and one the new
[03:52]  * davecheney bursts into tears
[03:53] <davecheney> natefinch: i'm convencined we've passed more than 100% technical debt to gdp
[03:53] <natefinch> davecheney: time to rewrite juju in rust
[03:55] <davecheney> that wasn't the exact point I was trying to make ...
[03:57] <natefinch> davecheney: well, we're working on tech debt at oakland, right?  One week should just about do it.
[04:05] <davecheney> i'll be late
[04:07]  * natefinch calls it a night to go read his new Go programming book
[04:28] <thumper> davecheney: https://github.com/howbazaar/clock-proposed
[04:28] <thumper> davecheney: I know you like non-util named packages :)
[04:28] <thumper> davecheney: to become github.com/juju/clock
[04:28] <thumper> axw: ^^
[04:28] <thumper> added in the testing clock from juju/juju/testing/clock.go
[04:29] <thumper> and added a few tests
[04:29] <thumper> and type assertions in the test file
[04:32] <axw> thumper: LGTM, but I'd like it if you renamed clock/testing to clock/clocktest
[04:33] <axw> thumper: saves aliasing everywhere
[04:33] <thumper> clock/testclock?
[04:33] <axw> thumper: I was thinking clocktest as in testing things related to the clock package, not as in a package that contains a TestClock
[04:33] <thumper> I agree with renaming it
[04:34] <axw> thumper: much like net/http/httptest
[04:34] <thumper> ah.. ok
[04:34] <thumper> happy to follow precident
[04:36] <axw> thumper: still not really sure about having a whole repo to its own. we're goingto want other time-related things which would be nice to group together
[04:36] <axw> thumper: e.g. delay functions for retry/scheduler/backoff thing that bogdan is working
[04:37] <thumper> axw: let's ask fwereade, given tech-lead hat :)
[04:37] <axw> thumper: I'm thinking they'd live in juju/time/delays or something like that... and then having clock over by itself feels a bit odd
[04:37] <axw> thumper: SGTM
[04:43] <davecheney> \o/ all praise the clock
[04:43] <davecheney> 15:32 < axw> thumper: LGTM, but I'd like it if you renamed clock/testing to clock/clocktest
[04:43] <davecheney> ^ yes, a million times, yes
[04:44] <thumper> I'm just asking our architect and TLs about guidance around separate repo for clock, or one for time that includes the scheduler that axw has
[04:44] <thumper> davecheney: the clock-proposed repo now has that package renamed
[04:44] <davecheney> thumper: also if it's going to be a juju project, it needs a cute name
[04:44] <davecheney> what about clocky ? https://upload.wikimedia.org/wikipedia/commons/4/4b/Clocky_almond_panorama1680.jpg
[04:45] <thumper> :)
[04:46] <thumper> axw: got the link to your time proposed repo?
[04:46] <thumper> axw: I'll include it in the email
[04:46] <axw> thumper: https://github.com/axw/juju-time
[04:46] <thumper> ta
[04:47] <menn0> thumper: here's juju-dumplogs. I'm just doing the /usr/local/bin symlink now.
[04:47] <menn0> http://reviews.vapour.ws/r/3075/
[04:50] <thumper> menn0: I'll continue reviewing shortly, got to go and drop of kids to guides/show
[04:50] <thumper> bbs
[04:51] <menn0> thumper: np
[07:54] <jam> morning all
[09:13] <dimitern> dooferlad, hey, can you check if you open http://imgur.com/a/ky3cl please?
[09:13] <fwereade> dimitern, nice
[09:14] <dooferlad> dimitern: yep
[09:14] <dimitern> fwereade, dooferlad, thanks :)
[09:14] <dimitern> wasn't sure I need to actually sign up for imgur to "public" the album - never used it, and their UI is confusing
[09:20] <dooferlad> dimitern: I have an environment in EC2 that has had its agent-state-info stuck in "Request limit exceeded" since last night.
[09:20] <dooferlad> dimitern: any thoughts?
[09:21] <dimitern> dooferlad, hmm - is it the shared account?
[09:21] <dooferlad> dimitern: https://console.aws.amazon.com/trustedadvisor/home?#/dashboard says I am below the service limits
[09:22] <dooferlad> so I expect this is a cached response :-|
[09:23] <dimitern> dooferlad, if it's the shared account, I can have a look
[09:23] <dooferlad> dimitern: it is shared, in eu-central
[09:23] <dimitern> dooferlad, ok, looking
[09:24] <dooferlad> dimitern: and, the fun part is, I only have 3 machines running after I did an ensure-availability -n 3 and had a charm on machine 1.
[09:25] <dooferlad> dimitern: so it looks like Juju tried to add another machine then gave up
[09:25] <dooferlad> dimitern: http://pastebin.ubuntu.com/13111330/
[09:27] <dimitern> dooferlad, that smells like the instancepoller getting overexcited
[09:27] <dimitern> and polling more often than needed
[09:27] <dooferlad> dimitern: even though we are, at the moment, under limit?
[09:28] <dooferlad> dimitern: ignore that comment, I was looking at service limits, not request limits
[09:33] <dooferlad> dimitern: we definitely need exponential backoff in our EC2 API with automatic retries. Is it supposed to have it already?
[09:33] <dimitern> dooferlad, IIRC we already have that
[09:33] <dimitern> dooferlad, or maybe it was just for the instancepoller
[09:35] <dooferlad> dimitern: it shouldn't be related to the bug I am looking at anyway since the customer is using MAAS.
[09:35] <dimitern> dooferlad, yeah
[09:37] <dimitern> dooferlad, can you try destroy-machine --force on those with the error and add new ones?
[09:38] <dooferlad> dimitern: possibly, but it isn't important right now. Was just wondering about a quick fix.
[09:38] <dooferlad> dimitern: just seemed odd
[09:39] <dimitern> dooferlad, indeed - before destroying the env, it might be useful to get the machine-0.log for some insight
[10:37] <jam> frobware: sorry I missed standup. Was still meeting with Mark. are you guys still chatting?
[10:38] <frobware> jam: yep
[10:38] <frobware> jam: into topics "catacomb and rate limiting"
[10:39] <jam> k. using the restroom and I'll be right there
[11:06] <fwereade> jam, it's a `.Kill(nil)`, so that's even easier :)
[11:10]  * perrito666 applies for a visa for the first time in around 20 years
[11:10] <perrito666> axw: you have a pretty strict migration policy :p
[12:31] <lazypower> dimitern - Help me out for a sec. Whats the name of your juju-core team?
[12:31] <rick_h__> lazypower: sapphire
[12:31] <lazypower> ah! thank you
[12:31] <lazypower> is there a chart/roster somewhere?
[12:32] <lazypower> It'll help when blogging and pointing credit arrows :D
[12:32] <rick_h__> lazypower: honestly I use the canonical directory
[12:32] <lazypower> Ah, allright
[12:32] <rick_h__> lazypower: if you look up dimiter it shows "Juju Core - Sapphire" as his team
[12:32] <rick_h__> lazypower: I'm sure there's others but just what I tend to use when I forget.
[12:33] <dimitern> lazypower, hey :)
[12:33] <perrito666> it would be really nice to have an api for the directory so I can write a plugin for my irc client
[12:34] <rick_h__> perrito666: come on, web scrapers ftw! :P
[12:34] <lazypower> perrito666 - automate away the pain. Embedded profiles for IRC
[12:40] <jam> perrito666: do you know about mup?
[13:31] <perrito666> jam: I do I would like my client to show me faces on hover though :)
[13:32] <jam> perrito666: would be good
[13:48] <cherylj> frankban: I see that you're reverting your update for crypto.  Was it updated originally for a particular reason?
[13:50] <mup> Bug #1513466 opened: Different behavior on ServiceDeploy with Config/ConfigYAML <juju-core:New> <https://launchpad.net/bugs/1513466>
[13:51] <mup> Bug #1513468 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <testing> <wily> <juju-core:New> <juju-core 1.25:Fix Released> <https://launchpad.net/bugs/1513468>
[14:05] <frankban> cherylj: I don;t remember specific reasons, probably just ended up there because it was updated in my GOPATH by some other project
[14:05] <cherylj> frankban: ok, thanks!
[14:06] <frankban> cherylj: should I merge it?
[14:06] <cherylj> frankban: did your local tests pass?
[14:07] <frankban> cherylj: I alway have some intermittent failures locally, but they seems not related to the downgrade, CI will tell us I guess
[14:07]  * cherylj curses intermittent failures
[14:07] <cherylj> frankban: yes, please merge
[14:08] <frankban> cherylj: done, how do we know if this fixes armhf?
[14:09] <cherylj> frankban: I don't think we have any way to test that without requesting images be built for 1.26-alpha 1
[14:10] <frankban> cherylj: ok, does merging this automatically unblock master?
[14:10] <cherylj> frankban: no, we'll need to verify that the fix worked first
[14:11] <perrito666> someone gave more machine to CI? curses are coming faster
[14:11] <frankban> cherylj: Does not match ['fixes-1513236'], I wrote fixes-1513236 in the pr comment, what else should I do?
[14:11] <perrito666> frankban: $$fixes-1513236$$ should do the trick
[14:11] <cherylj> frankban:  use "$$fixes-1513236$$"
[14:11] <cherylj> rather than $$merge$$
[14:12] <frankban> ok done
[14:14] <cherylj> thanks, frankban!
[14:40] <abentley> frankban: If master is blessed, your bug will automatically be marked fix-released.  If there are no other blockers, that will unblock master.
[14:40] <frankban> abentley: sounds good
[14:45] <frankban> cherylj: downgrade branch landed
[14:47] <abentley> frankban: master bec300366 now testing.
[15:00] <mup> Bug #1513492 opened: add-machine with vsphere triggers machine-0: panic: juju home hasn't been initialized <add-machine> <panic> <vsphere> <juju-core:Triaged> <https://launchpad.net/bugs/1513492>
[15:00] <cory_fu> With the release of Juju 1.25, we seem to be seeing shorter idle times on the agent-state, possibly due to update-status hook being called more frequently.  Was there a specific change related to that in 1.25?
[15:01] <perrito666> bbl lunch
[15:01] <perrito666> cory_fu: update status hook will call before entering idle status
[15:01] <perrito666> but the added time there might make idle time shorter as a consequence
[15:01] <perrito666> fwereade: correct me if that changed
[15:02] <perrito666> now yes, bbl
[15:03] <fwereade> perrito666, cory_fu: yes, I wouldn't expect a non-errored agent to be idle for longer than 5 mins (I think that's the update-status period)
[15:03] <fwereade> cory_fu, but if it never gets close to that there might be something up
[15:04] <cory_fu> I'm not sure if I understand.  The issue I'm running up against is that I'm waiting for a 30s idle period and am not seeing it within a 30min window.  This seems to mostly happen on Azure
[15:05] <cory_fu> Which is notoriously slow for these deploys, so that may be a factor.
[15:05] <tvansteenburgh> cory_fu: i have examples on other clouds too
[15:05] <cory_fu> tvansteenburgh: But it's not 100% consistent on other clouds?
[15:06] <tvansteenburgh> cory_fu: azure is notable b/c it hasn't passed on 1.25 at all. hp on the other hand, has passed at least twice :P
[15:07] <katco> wwitzel3: standup?
[15:08] <wwitzel3> katco: trying .. :/
[15:25] <tvansteenburgh> fwereade, cory_fu: seems to me that agent-status.since should not be updated unless the value of agent-status.current actually changes
[15:25] <fwereade> tvansteenburgh, right, but it executes a hook every 5 minutes
[15:25] <fwereade> tvansteenburgh, is workload-status also shortened?
[15:26] <fwereade> tvansteenburgh, I would expect ~5mins of idle, separated by (likely) sub-second blips of executing
[15:27] <tvansteenburgh> fwereade: no, in our examples, wordload-status.since is much older - 8 to 15 minutes older in the one i'm looking at
[15:27] <fwereade> tvansteenburgh, cool, I think that's what I'd expect
[15:27] <fwereade> tvansteenburgh, is it unhelpful to you?
[15:30] <tvansteenburgh> fwereade: i'm not sure. we've been using agent-status.since to determine when an environment had "settled" - all agents idle for 30 seconds. that worked well prior to 1.25, but now we see most deployments never reaching that settled state. trying to figure out what changed
[15:30] <frankban> cherylj, abentley: bec30036 failed, errors don't seem related though
[15:31] <fwereade> tvansteenburgh, well, the update-status thing is the clear proximate cause, but ultimately I think it's incorrect to depend on agent status as a proxy for environment stability
[15:32] <fwereade> tvansteenburgh, that should be what workload-status is for -- assuming the charm implements it
[15:32] <abentley> frankban: no, but it does seem like a legit failure.  The same test failed for the last test of master.
[15:34] <tvansteenburgh> fwereade: yeah, fair enough. we were trying to accommodate the charms that don't, but i see your point
[15:35] <fwereade> tvansteenburgh, cool -- forwarded you a mail where I go into a bit more detail, in case it's relevant :)
[15:35] <tvansteenburgh> fwereade: thanks!
[15:36] <frankban> abentley: how do we check that https://bugs.launchpad.net/juju-core/+bug/1513236 is fixed?
[15:36] <mup> Bug #1513236: Cannot build trusty armhf with go1.2 on from master <armhf> <blocker> <go1.2> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513236>
[15:36] <katco> davecheney: did you have a golang issue or something to justify unblocking master for bug 1513236 ?
[15:37] <katco> davecheney: (just now seeing your message) i'd like to update that bug with justification before untagging it as a blocker
[15:37] <abentley> frankban: Regardless of whether that bug is fixed, we don't want to unblock until we get a bless.
[15:38] <frankban> abentley: I don't question that
[15:40] <abentley> frankban: That's tricky, because we don't build armhf as part of testing, because we don't have suitable hardware to test with.  I'd talk to sinzui.
[15:41] <sinzui> abentley: mgz: I beleive we could crossbuild it, which would catch the error.
[15:41] <natefinch> abentley, frankban, sinzui : note that davecheney said that this was very likely an upstream go 1.2 bug that is not likely to be fixed anytime soon, possibly ever
[15:42] <sinzui> abentley: mgz: I was also thinking of asking for armhf hardware, but mgz might be able to prove the cae for us with this chromebook
[15:42] <sinzui> natefinch: yeah, Go has moved on to newer versions
[15:50] <cherylj> hey dimitern, is there any update on bug 1483879?  I know the fix isn't trivial, but the bug was brought up in the cross team call and I wanted to make sure it was still in progress...
[15:50] <mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider> <sts> <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1483879>
[15:52] <dimitern> cherylj, it still is - I'm close to proposing 1.24 fix (needed to fix my maas setup to test it properly, which I finished a couple of hours ago)
[15:52] <cherylj> dimitern: great, thanks!  I'll put an update in the bug that it's close for 1.24.
[15:52] <cherylj> dimitern: will it be difficult to forward port?
[15:53] <dimitern> cherylj, the 1.24 fix is the most difficult, as it needs some cherry-picking from 1.25
[15:53] <cherylj> ah, ok
[15:53] <dimitern> cherylj, the 1.25 and master forward ports  should be much simpler
[15:58] <natefinch> wwitzel3, ericsnow: fyi, a few tests failed on the lxd build tags merge, I can fix easily, but just letting you know.
[15:58] <ericsnow> natefinch: k
[15:59] <wwitzel3> natefinch: ty
[16:01] <natefinch> alexisb, katco:  I notice the "roomie" thing on the oakland spreadsheet says N/A for everyone.  Does that mean we all get our own rooms?
[16:02] <katco> natefinch: that is my understanding
[16:02] <natefinch> katco: awesome :)
[16:02] <katco> natefinch: yes, as an introvert that makes me extremely happy
[16:03] <katco> natefinch: i.e. i'll actually have a place i can recharge
[16:03]  * dooferlad is a happy introvert as well at this news
[16:03] <natefinch> katco: yeah, totally understand that
[16:04] <natefinch> katco: I'm generally fine with sharing a room... right up until the actual sleeping part... then I really just want my own room, thankyouverymuch.
[16:05] <katco> natefinch: it's pretty disastrous for me as i feel like i have to be "on" for 24/7 for an entire week
[16:07] <wwitzel3> I usually wake up at 7am and don't go to bed until 3am during sprints .. they should really do a timeshare thing, probably save money
[16:07] <katco> wwitzel3: 1:1?
[16:08] <wwitzel3> I also feed off the engery of introverts, so that helps
[16:08] <natefinch> wwitzel3: rofl
[16:08] <katco> haha
[16:16] <lazypower> > I feed off he energy of introverts
[16:16] <lazypower> strange place to join the conversation, but knowing wwitzel3 i'm not surprised...
[16:21] <wwitzel3> lazypower: :)
[16:22] <natefinch> no wonder wwitzel3 likes programming so much... neverending supply of food.
[16:31] <frobware> cherylj, would you have time to try a fix for https://bugs.launchpad.net/juju-core/+bug/1412621
[16:31] <mup> Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <adoption> <bootstrap> <bug-squad> <charmers> <cpec> <cpp> <maas-provider> <mongodb> <oil> <juju-core:Triaged by frobware> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1412621>
[16:36] <natefinch> man, prices for flights went up like 25% from yesterday afternoon :/
[16:36] <perrito666> natefinch: nearing christmas
[16:37] <natefinch> perrito666: I think we just crossed the "30 days from flight day" mark
[16:37] <perrito666> ah, ok, that makes me panic
[16:38] <perrito666> my before trip todo is especially long
[17:03] <ericsnow> natefinch: I found a couple typos in your build constraints patch (left a review)
[17:06] <natefinch> ericsnow: thanks!
[17:06] <ericsnow> natefinch: np
[17:06] <ericsnow> natefinch: found it while rebasing my patches on yours :)
[17:08] <natefinch> ericsnow: "how did this compile before?"  exactly my question
[17:08] <ericsnow> natefinch: I don't think it did :/
[17:10] <natefinch> ericsnow: there were two compiler errors before I even changed anything.  My guess is that they were because of a merge/rebase
[17:10] <ericsnow> natefinch: yep
[17:10] <natefinch> ericsnow: fixed those spots btw
[17:11] <ericsnow> natefinch: thanks
[17:11] <natefinch> ericsnow: the only thing left is some provisioner tests that are failing
[17:12] <ericsnow> natefinch: weird
[17:12] <ericsnow> natefinch: look for instance.LXD in those tests
[17:12] <mup> Bug #1513552 opened: master cannot deploy charms <blocker> <charm> <ci> <deploy> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513552>
[17:12] <natefinch> the letters lxd don't even exist in files in this directory :/
[17:15] <natefinch> ericsnow: it's suspicious because it's in container_initialisation_test.go .. which implies it is our fault (maybe we're being punished for the UK spelling in the filename)
[17:39] <perrito666> bbll
[17:40]  * perrito666 goes to curse ha screaming and will be back later
[17:41] <cherylj> natefinch: can you take a look at bug 1513552?  It looks like some of your recent commits are causing widespread CI failures
[17:41] <mup> Bug #1513552: master cannot deploy charms <blocker> <charm> <ci> <deploy> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513552>
[17:48] <ericsnow> alexisb: sorry, zillow killed my browser
[17:48] <alexisb> lol
[17:48] <alexisb> :)
[18:11] <cherylj> could anyone tell me when we would see SECURE_STATESERVER_CONNECTION: "false" in agent.conf rather than "true"?
[18:38] <natefinch> cherylj: ok looking
[19:12] <natefinch> hmm... many of those failures mention deployer... seems suspicious
[19:13] <natefinch> sinzui: I wonder if deployer is doing something different than juju-core... because I can deploy charms just fine with juju deploy
[19:13] <natefinch> sinzui: re: that "cannot assign unit" problem
[19:14] <natefinch> katco: FYI, spending some non-trivial time looking into bug 1513552
[19:14] <mup> Bug #1513552: master cannot deploy charms <blocker> <charm> <ci> <deploy> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513552>
[19:15] <sinzui> natefinch: the deployer jobs that stand up openstack report the same problem
[19:15] <katco> natefinch: yep thx for the heads-up
[19:15] <sinzui> natefinch: eg: http://reports.vapour.ws/releases/3270/job/OS-deployer/attempt/502
[19:16] <sinzui> natefinch: the quickstart error is also the same (though reported differently) http://reports.vapour.ws/releases/3270/job/aws-quickstart-bundle/attempt/1282
[19:17] <sinzui> ^ landscape bundle
[19:17] <natefinch> sinzui: do we have tests that just use juju deploy?
[19:18] <natefinch> (not being snarky, real question... want to make sure I'm right in thinking it's deployer etc)
[19:18] <sinzui> natefinch: to deploy a bundle? not yet
[19:19] <natefinch> sinzui: no, to deploy a charm
[19:20] <sinzui> natefinch: many tens of tests deploy a charm
[19:20] <natefinch> sinzui: and those all pass?  So it's just deployer and quickstart?
[19:21] <sinzui> natefinch: no. http://reports.vapour.ws/releases/3270 clearly shows "deploy", "deployer", and "quickstart" are broken on all substrates, all series, all archs
[19:21] <sinzui> natefinch: this shows every test that failed in the two revs that were tested http://reports.vapour.ws/releases/issue/563b902c749a563ed218b6cf
[19:26] <sinzui> natefinch: I think I see the issue :)
[19:26] <sinzui> natefinch: nm, I am looking at stale data
[19:27] <cherylj> aww, I had gotten my hopes up
[19:48] <natefinch> man I wish we didn't redact the API parameters
[19:55] <ericsnow> fwereade: isn't it gloomy in the catacombs?
[19:55] <ericsnow> fwereade: I suppose they have a certain charm :)
[19:55] <fwereade> ericsnow, terribly glum, yeah :)
[20:00] <thumper> menn0: test failure: [LOG] 0:00.206 ERROR juju.apiserver debug-log handler error: tailer stopped: tailable cursor requested on non capped collection
[20:00] <wwitzel3> katco ericsnow natefinch ping
[20:02] <katco> wwitzel3: brt
[20:10] <natefinch> sinzui: I bet this is a race condition where the script is calling expose or something before the unit has a machine assigned, and that's causing us to go down a codepath we didn't previously go down, because unit creation and assignment happened in lock step.
[20:10] <natefinch> sinzui: because a simple deploy definitely still works
[20:13] <sinzui> natefinch: maybe. the deploy_stack.py copies a lot of deployment where expose is called immediately after deploy and add-relation. I thnk deployer though deferred that operation until relations were added, and relations were deffered until all units were up
[20:15] <sinzui> natefinch: http://reports.vapour.ws/releases/3270/job/aws-deploy-trusty-amd64/attempt/2476 does show that deploy, add-relation, and export were all called withing seconds of each other
[20:17] <katco> wwitzel3: ericsnow natefinch sorry, almost there
[20:23] <natefinch> sinzui: definitely looks like expose and/or add-relation is the problem, I can repro if I do juju deploy wordpress && juju add-relation wordpress mysql && juju expose wordpress
[20:23] <thumper> fwereade: ping
[20:23] <fwereade> thumper, pong
[20:23] <thumper> fwereade: can we chat in about 10min?
[20:24] <fwereade> thumper, sure
[20:24] <fwereade> natefinch, I think you're right
[20:25] <fwereade> natefinch, is that the firewaller falling over?
[20:30] <natefinch> fwereade: sorry, in a meeting
[20:32] <fwereade> natefinch, np
[20:37] <thumper> fwereade: https://plus.google.com/hangouts/_/canonical.com/chat?authuser=1
[21:26] <cherylj> wallyworld: you around?
[21:27] <wallyworld> cherylj: sorta
[21:27] <cherylj> wallyworld: could you ping me when you get a few minutes?  I need some help with a bug
[21:27] <wallyworld> sure, give me 10 mins
[21:27] <cherylj> sounds good, thanks
[21:37] <wallyworld> cherylj: which bug?
[21:37] <cherylj> https://bugs.launchpad.net/juju-core/+bug/1512782
[21:37] <mup> Bug #1512782: wget cert issues causing failure to create containers <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1512782>
[21:38] <cherylj> They're doing some weird stuff with their lxcbr0 and nested kvm / lxc
[21:39] <wallyworld> cherylj: give me a minute to read bug info; that's wget/lxc stuff hasn't changed in ages so it's likely to be specific to their setup
[21:40] <cherylj> The last update is probably the most useful
[21:41] <cherylj> wallyworld: this line in the machine-0.log also looks really weird to me:  DEBUG juju.worker.certupdater certupdater.go:191 new addresses [localhost juju-apiserver juju-mongodb anything <IP_ADDRESS>]
[21:42] <wallyworld> cherylj: that's normal - we use those hard coded names plus machine IP addresses in the CA cert SAN
[21:42] <cherylj> ok
[21:43] <wallyworld> cherylj: what may be the issue though is that we add the IP address of juju managed maches to the cert SAN - that I address has to be the source of where the wget comes from
[21:43] <wallyworld> if they are using some weird network setup the cert addresses won't match
[21:43] <cherylj> wallyworld: I think that's the case
[21:44] <wallyworld> hmmm
[21:44] <wallyworld> off hand i'm not sure how to solve that
[21:44] <cherylj> the logs for the lxc-create show they're getting the image through <IP_ADDRESS>, but the only ip in the certupdater is the <IP_ADDRESS>
[21:44] <wallyworld> yup
[21:44] <menn0> thumper: wrt to that the juju-run/juju-dumplogs symlink issue, I've had a better idea
[21:44] <wallyworld> the cert updater wroks off listening to the addresses juju records for the machines
[21:44] <thumper> menn0: yeah?
[21:45] <menn0> thumper: make the symlinks relative to the cmd.Context's Dir
[21:45] <thumper> will that always work?
[21:45] <wallyworld> cherylj: so we need to look at the address updater worker to see how to make it recognise and report the correct addresses
[21:45] <menn0> thumper: in production this will be "/", but in tests (when using testing.RunCommand) it'll be a temp directory
[21:45] <wallyworld> cherylj: off hand, i'd need to look into how all that works
[21:46] <thumper> menn0: have you checked that production it is "/" ?
[21:46] <menn0> thumper: yep, I just checked that
[21:46] <thumper> menn0: also consider the current local provider
[21:46] <menn0> thumper: what's different with the local provider?
[21:46] <thumper> menn0: it is just "special"
[21:46] <thumper> datadir is ~/.juju/<env-name>/
[21:47] <wallyworld> cherylj: actrually, looking at the logs, that <IP_ADDRESS> address is the state server address
[21:47] <menn0> thumper: yep, that's not related to this. the source of the symlink doesn't change. it's just where the symlink gets put.
[21:47] <wallyworld> i'm talking about the machine on which the container is being created
[21:47] <thumper> menn0: k
[21:47] <cherylj> wallyworld: yeah...
[21:47] <menn0> thumper: i'll make the change now as a separate PR so you can have a look
[21:48] <wallyworld> cherylj: so we need to ensure the CA cert records in its SAN list the IP addresses of all worker machines, the addresses from which wget requests originate
[21:49] <wallyworld> that means we need juju to record the correct thing in the machine address field
[21:50] <wallyworld> so we need the machine agent (i think it's the agent) to report the correct addresses
[21:50] <wallyworld> not sure how smart this all is with different nrtwork setups
[21:51] <cherylj> wallyworld: I see that it picks up <IP_ADDRESS> as a machine address.  Not sure why the certupdater didn't include that one
[21:51] <wallyworld> cherylj: that's the state server address
[21:51] <wallyworld> we need to record the machine address from which the wget originates
[21:52] <wallyworld> cherylj: so we need each machine to correctly report to juju its address
[21:52] <wallyworld> or addresses
[21:52] <wallyworld> those are stored in the machine addresses field in state
[21:53] <wallyworld> that's what the cert updater listens to
[21:53] <wallyworld> i think its the machine agent on each machine which reports those addresses
[21:53] <cherylj> wallyworld:  you mean like this?  INFO juju.worker.machiner machiner.go:100 setting addresses for machine-0 to ["local-machine:<IP_ADDRESS>" "local-cloud:<IP_ADDRESS>" "local-cloud:<IP_ADDRESS>" "local-machine:::1"]
[21:53] <wallyworld> so my guess from memory is that we need to look at how the machine agent queries its host addresses
[21:54] <wallyworld> cherylj: are they running the lxc containers on machine 0?
[21:55] <wallyworld> i was assuming there'd be a machine 1 or 2 or whatever
[21:56] <cherylj> wallyworld: no, I think they're doing it on machine-1
[21:56] <wallyworld> i think you said they were nesting lxc inside kvm?
[21:56] <wallyworld> cherylj: right ok. so whatever the source IP address of the wget request is has to be recorded in the SAN list
[21:57] <wallyworld> cherylj: that source address is the machine hosting the lxc containers
[21:57] <wallyworld> which is typically machine 1's address. or it needs to be the kvm address if lxc inside kvm
[21:58] <wallyworld> cherylj: so there needs to be a line in the logs like the above but which says setting addresses for machine-1 ....
[21:58] <cherylj> wallyworld: okay, I see what you mean now
[21:59] <wallyworld> cherylj: i have to relocate, will be afk for 20 minutes
[21:59] <cherylj> wallyworld: sure, np
[22:24] <ericsnow> natefinch: check out http://reviews.vapour.ws/r/3080/
[22:26] <menn0> thumper: this approach is working out pretty nicely
[22:26] <thumper> menn0: awesome
[22:26] <thumper> menn0: did the no tail bit land in master?
[22:26] <thumper> menn0: it may help me fix this problem :)
[22:27] <menn0> thumper: yep, that's landed
[22:29] <menn0> man there's lots of tests that use cmd.DefaultContext that should probably be using cmdtesting.Context
[22:29]  * menn0 ignores for now
[22:32] <perrito666> and then you froze
[22:32] <perrito666> wwitzel3:
[22:32] <perrito666> I meant wallyworld
[22:58] <axw_> perrito666: what do you need a visa for?
[22:59] <perrito666> axw_: enter australia
[22:59] <axw_> perrito666: just for meetings? :/
[23:02] <perrito666> axw_: I got an e-visa
[23:16] <wallyworld> perrito666: we're here now
[23:27] <davechen1y> https://github.com/docker/docker/pull/17700
[23:27] <davechen1y> ^ docker have removed support for lxc
[23:31] <mup> Bug #1513659 opened: 1.24.6 fails to bootstrap with "ERROR juju.cmd supercommand.go:430 upgrade in progress - Juju functionality is limited" <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1513659>
[23:37] <mup> Bug #1513659 changed: 1.24.6 fails to bootstrap with "ERROR juju.cmd supercommand.go:430 upgrade in progress - Juju functionality is limited" <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1513659>
[23:40] <mup> Bug #1513659 opened: 1.24.6 fails to bootstrap with "ERROR juju.cmd supercommand.go:430 upgrade in progress - Juju functionality is limited" <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1513659>
[23:44] <davechen1y> mwhudson: ding ding ding.
[23:45]  * mwhudson vibrates tunefully
[23:45] <mwhudson> davechen1y: eh?
[23:47] <davechen1y> your ppc64 observation
[23:48] <ericsnow> katco: am I okay landing my fix of natefinch's patch?  http://reviews.vapour.ws/r/3080/
[23:48] <mwhudson> davechen1y: ah heh
[23:49] <ericsnow> katco: I'd like to land those LXD patches today
[23:49] <mwhudson> davechen1y: can you re-run test_shared on arm64 pls?
[23:49] <mwhudson> davechen1y: that was pretty mystically debugging from russ
[23:50] <davechen1y> he is the master to psychic debugging
[23:50] <davechen1y> mwhudson: arm64 -- will do
[23:51] <mwhudson> ta


[01:44] <snadge> i have updated 4 systems to precise now.. :D
[01:44] <snadge> including my work pc
[01:44] <snadge> work pc, home pc, htpc and netbook
[01:44] <jtaylor> have fun with the X update coming soon then :)
[01:45] <snadge> thanks for the heads up.. what kind of X update?
[01:45] <jtaylor> 1.11 with input stack from 1.12
[01:45] <snadge> oh ye of little faith.. she'll be right mate, as they say here in australia ;)
[01:45] <jtaylor> you update so many pcs but don't read -devel-announce? :O
[01:46] <snadge> well i did them one at a time
[01:46] <snadge> but no, i didnt even know about devel-announce
[01:46] <snadge> i did read the warning about "do not do this on production systems"
[01:47] <snadge> but its not the end of the world if they dont work
[01:47] <snadge> id rather help test and fix bugs on as many different types of systems as possible.. to hopefully have a more smooth time with 12.04.. thats my logic anyway
[01:48] <snadge> especially since im capable of actually doing that
[01:49] <snadge> fglrx seems to have an issue with compiz/unity for example .. where window focus doesnt appear to update properly
[01:49] <snadge> radeon does not have this issue
[02:04] <Fudge> anyone noticed in sound input tab, if you set your mic to be rear mic instead of default front. when you reboot it is back to front. have not found how to save this setting or a reason why it reverts
[04:00] <snadge> why does precise set <IP_ADDRESS> for the dns
[04:00] <snadge> wtf
[06:20] <snadge> sigh.. i just updated a system from 11.10 to 12.04
[06:20] <snadge> and lightdm isnt starting
[06:21] <snadge> if i manually start it with service lightdm start .. it does
[06:21] <snadge> im unfamiliar with upstart.. but if i use initctl status lightdm
[06:21] <snadge> it returns: lightdm stop/waiting
[06:23] <snadge> boot screen seems to be hung on Stopping read required files in advance
[06:33] <urlin2u> snadge, this your only OS?
[06:37] <snadge> i have windows on the same machine but its my only ubuntu os yes
[06:37] <snadge> if i start lightdm manually.. i can log in and use the machine as expected
[06:37] <snadge> ive worked out that its not ureadahead
[06:38] <snadge> because i removed it
[06:39] <Fudge> lightdm doesnt start automatically for me either
[06:39] <snadge> hmm.. maybe something just broke very recently then.. because it works fine on my other two systems
[06:40] <snadge> Fudge: are you using fglrx?
[06:40] <Fudge> just removed and made defaults with update-rc.d, think coudl prob safely ignore this error
[06:40] <Fudge> update-rc.d: warning: /etc/init.d/lightdm missing LSB information
[06:41] <Fudge> dont believe I am
[06:41] <snadge> what does update-rc.d if you dont mind my ignorance? (im just taking a crash course in upstart now.. ergh)
[06:41] <Fudge> handles the runlevel init scripts
[06:41] <snadge> so it will recreate them?
[06:41] <Fudge> e.g update-rc.d -f lightdm remove
[06:41] <Fudge> update-rc.d lightdm defaults
[06:42] <Fudge> reboot see if it works
[06:42] <snadge> did you dist upgrade from an 11.10 system before seeing this problem?
[06:42] <snadge> or just installed an update
[06:45] <Fudge> snadge  this install is from precise alpha 1
[06:46] <snadge> ok rebooting it now after doing the above
[06:50] <snadge> nope that didnt help
[06:50] <snadge> in fact now i get another error
[06:50] <snadge> that S20lightdm isnt the way to invoke lightdm
[06:51] <snadge> i guess the next question is.. how to i completely purge upstart
[06:52] <Fudge> maybe there is somethign wrong with the init script
[06:54] <snadge> i think so.. im losing patience with it.. i could probably just reinstall from scratch
[06:54] <snadge> maybe i should try to at least figure out what went wrong
[06:55] <Fudge> well u can start by looking at /var/log/lightdm/
[06:58] <Fudge> mine look fine
[06:58] <Fudge> check for bug reports
[06:58] <snadge> mine look broken
[06:59] <snadge> [+1096.25s] WARNING: unity-greeter: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
[06:59] <snadge> hmm.. and in x-0.log
[06:59] <snadge> [-     XMM_GLX] [I ]glesxXvInit Configureable RGBOutputColorRange
[06:59] <snadge>  ddxSigGiveUp: Closing log
[07:00] <snadge> could be an issue with fglrx
[07:00] <snadge> but if i manually start it.. it starts ok
[07:01] <Fudge> isnt fglrx a driver
[07:01] <snadge> yeah
[07:01] <snadge> thats in x-0-greeter.log and x-0.log
[07:01] <Fudge> nothing wrong there
[07:03] <snadge> ok on a machine with a working lightdm
[07:03] <snadge> therse only 3 seconds worth of log in lightdm.log
[07:04] <snadge> on the broken system.. it goes up to 6200 seconds
[07:12] <snadge> this is distressing me :/
[07:14] <snadge> starting it manually with service lightdm start.. works fine
[07:19] <urlin2u> snadge, you have a backup image of 11.10?
[07:19] <snadge> nah.. of course not ;)
[07:20] <urlin2u> to bad your best insurance.
[07:20] <urlin2u> :D
[07:21] <snadge> im just going to start heavily drinking and ignore it hehe
[07:22] <snadge> im half tempted to try apt-get --purge remove upstart
[07:22] <snadge> but it tells me it wants to remove 388 packages
[07:22] <snadge> tempting
[07:23] <snadge> and wants me to type "yes, i really want to do this"
[07:27] <snadge> dont worry i've saved a list of the packages its removing.. and im just going to try installing ubuntu-desktop.. and manually install anything its missing
[07:27] <snadge> failing that i'll boot off a live usb, copy off my data.. and format it with extreme prejudice
[09:54] <snadge> <--- glutton for punishment
[10:15] <Ian_Corne> is there any way to get the file transfor window back after it's hidden?
[10:20] <jokerdino> click on nautilus icon
[10:21] <Ian_Corne> i tried that
[10:21] <Ian_Corne> doesn't show it
[10:21] <jokerdino> hmm
[11:50] <megamaced> hi, with the recent update to lightdm in precise, the "other" user option has been removed so I can no longer log in using an active directory account via likewise-open. Does anyone know how I can bring back the "other" user option?
[11:51] <megamaced> i have temporarily switched to using GDM in the meantime
[12:43] <BluesKaj> Hey folks
[15:34] <chmac> libreoffice upgrades broken for you?
[15:35] <jokerdino> chmac: mine is working fine.
[15:35] <chmac> When did you last pull in updates?
[15:35] <jokerdino> today
[15:35] <jokerdino> around 12 hours before
[15:36] <chmac> jokerdino: Hmm
[15:36] <chmac> I'm seeing all kinds of dependency clashes
[15:36] <jokerdino> oh hm
[15:36] <jokerdino> what error message?
[15:38] <chmac> jokerdino: If I select all updates except ia32-libs (which I hacked in from oneiric) it wants to remove my entire desktop :-)
[15:38] <jokerdino> wooo
[15:38] <chmac> python2.7 is showing as an available update, which wants to rip out a load of stuff based on python
[15:38] <Daekdroom> Why did you get ia32-libs from oneiric?
[15:38] <chmac> Daekdroom: To get skype running, it was a week or two ago
[15:41] <chmac> I'm guessing this is a temporary issue. I had similar problems before because syncevolution wasn't updated, it was fixed in time
[16:59] <Ian_Corne> libreoffice hasnt worked for me for a while now
[16:59] <Ian_Corne> since my "fix" :p
[17:00] <Daekdroom> I never noticed it stop working in PP
[17:00] <Daekdroom> and I'm wondering why it still does not integrate well with GTK
[17:09] <Ian_Corne> ffmpeg update is also broken
[17:25] <thechef> What do you think? If I take the Unigine Benchmark and test using Unity and using Unity2D with nvidia card. Can I detect a difference? or does Compiz automatically deactive Compositing on fullscreen?
[17:38] <Daekdroom> thechef, Possibly yes, and I don't think it deactivates compositing.
[17:38] <Daekdroom> Because I've seen benchmarks regarding that.
[17:39] <Daekdroom> (the impact of compositing in performance)
[18:41] <thechef> Daekdroom, so if I want max out gaming performance I'm forced to use Unity2D or Gnome Classic, is it planned to let compiz detect a GL-context covering exactly or more than the entire screen and in this case deactivate compositing temporarily, or do you know if compositing overhead can be reduced to exactly 0 in circumstances where the opengl context covers the whole screen and now other effects are idle.
[18:45] <Daekdroom> thechef, despite having a performance impact, that does not necessarily for the worst. And I haven't read about any way to reduce composite impact on gaming.
[18:47] <Daekdroom> thechef, this is not recent enough to draw a comparison for 12.04, but check it out: http://www.phoronix.com/scan.php?page=article&item=linux_desktop_managers1&num=1
[18:51] <penguin42> Daekdroom: The first result on there is odd - I'm surprised Gnome2+Metacity gets a noticably lower score than the 3d based ones
[18:53] <Daekdroom> penguin42, it surprises me too.
[18:54] <penguin42> Daekdroom: The order with the open ones seems more beliavable - although I wonder why KDE is coming out so high
[18:55] <penguin42> Daekdroom: Oddly on Nvidia, KDE is coming out the fastest - but what surprises me is that with what I assume are full screen games that the window manager makes any difference
[18:56]  * penguin42 would have thought for full screen the window manager would just get the heck out of the way
[19:06] <thechef> I think my guess that Unity makes window movement slower in frame rate was wrong. I just didn't expect a 6-7 year old intel centrino laptop to be faster than a atom nettop I bought last year.
[19:06] <thechef> and the laptop still had 10.04 installed
[19:07] <Ian_Corne> atom is really.. ugh
[19:08] <thechef> and now I'm about to install 12.04, jumping from release to release and 11.10 is slightly slower, but I know that 12.04 is faster so I think it will be exactly as fast.
[19:11] <thechef> I had fears that Unity would make Ubuntu the second best operating system in the world, but I'm sure I was wrong :)
[19:11] <aguitel> in last upgrade i see this error :sh: 1: /usr/bin/gdbus: not found
[19:11] <aguitel> ,what is this ?
[19:17] <ts2> it means something was looking for /usr/bin/gdbus, and it wasn't found
[19:17] <ts2> !find usr/bin/gdbus precise
[19:19] <aguitel> ts2, need to install this files?
[19:20] <ts2> well, the error is saying it was looking for /usr/bin/gdbus, and that program is in the libglib2.0-bin package
[19:22] <aguitel> ts2, solved
[19:22] <aguitel> ts2, to make upgrade in 12.04 what is best to use,apt-get or aptitude ?
[19:22] <Daekdroom> aguitel, apt-get
[19:23] <Daekdroom> aptitude has a hard time dealing with multiarch
[19:23] <Daekdroom> (which you'd only need if you're on x64)
[19:23] <ts2> use do-release-upgrade
[19:23] <aguitel> i am in x64
[19:23] <Daekdroom> Wait, are you talking about upgrading to 12.04, or upgrade in 12.04?
[19:23] <aguitel> upgrade in 12.04
[19:24] <ts2> oh, apt-get will do then
[19:24] <Daekdroom> I spent about two weeks trying to install wine1.3 through aptitude until I realized apt-get was the only one that could do it.
[19:25] <ts2> aptitude sometimes tries a little _too_ hard
[19:26] <aguitel> see that if i try to use aptitude:http://paste.pocoo.org/show/538366/
[19:26] <Daekdroom> Bug #831768
[19:33] <aguitel> !find /usr/bin/gdbus


[19:12] -SwissBot:#ubuntu-news- ::Softpedia:: Windows 10 Will Let You Access Linux Files Using File Explorer @ https://news.softpedia.com/news/windows-10-will-let-you-access-linux-files-using-file-explorer-524977.shtml (by Bogdan Popa, Microsoft News Editor)
[20:15] -SwissBot:#ubuntu-news- ::Softpedia:: Debian GNU/Linux 9.8 Released with over 180 Security Updates and Bug Fixes @ https://news.softpedia.com/news/debian-gnu-linux-9-8-released-with-over-180-security-updates-and-bug-fixes-524979.shtml (by Marius Nestor)
[21:24] <Gerowen> Joined
[21:25] <Bashing-om> Gerowen: Due to spammers, we have had to implement access rights to Gdoc and the WIKI.
[21:26] <Gerowen> Bashing-om: Alright that's no biggie.  I was just curious.
[21:27] <Gerowen> Most of the stuff I wrote was things like "How to record system sound with audacity" and simple walkthroughs that I wasn't able to find elsewhere on the site.  Some of it probably isn't even relevant any more, :-)
[21:27] <Bashing-om> Gerowen: We are in sad shape for help ! .. Please join us !
[21:28] <guiverc> Gerowen, you can always get an existing editor to proof read what you have created/want modified, and if they're agree/happy they can make the change for you (will likely credit you in the change commentary...)
[21:29] <guiverc> sorry my wording s/agree/agreement/
[21:29] <Gerowen> Bashing-om: Sure I can do that.  I'm not really the best in terms of staying on top of the latest events, but if there's something specific that isn't documented on the wiki I can contribute.
[21:29] <Gerowen> guiverc: It's fine, I just hadn't looked at it in ages and stopped by today purely out of curiosity.
[21:31] <Bashing-om> Gerowen: Working UWN is one way to contribute to the ubuntu effort . As to the effect of UWN - I am curious to find out.
[21:33] <guiverc> it's also a valid way to become a wiki editor; how I become one..
[21:36] <Gerowen> I found the new "Community" website and the UWN wiki page, I'll do some reading and check it out, :-)
[21:37] <Gerowen> Could one of you guys do me a favor though since you're still current editors?
[21:38] <Gerowen> I noticed way back when that some of the more active community members were making profile pages, so I made one.  Could you either delete this page altogether, or at the very least delete my age and PGP keys?  That information is no longer accurate.
[21:38] <Gerowen> https://wiki.ubuntu.com/gerowen
[21:40] <Bashing-om> Gerowen: Gerowen Loading your page ATT - how would you like age and key to read ?
[21:40] <guiverc> yeah I'm looking too.. he's a fellow citizen of your country Bashing-om ..
[21:41] <Gerowen> Bashing-om: Just delete the keys altogether, I've got a completely different machine right now than I did back then and don't have any PGP keys published.
[21:41] <Bashing-om> Gerowen: guiverc Loaded up and waiting :)
[21:42] <guiverc> i'm happy to remove; but i'd like you to email me using the listed gmail to confirm it's your page - but Bashing-om is likely to be willing too...  (I will provide my email)
[21:42] <Gerowen> Age is 31 now.
[21:42] <Gerowen> No biggie, just tell me what to send it to.
[21:42] <guiverc> Bashing-om, are you happy to make changes without email (it's 'no biggie' i concur)
[21:43] <Bashing-om> guiverc: Ouch ! Good point to confirm :)
[21:43] <guiverc> :)
[21:44] <Gerowen> Which address should I send the email to?
[21:44] <guiverc> my email is<EMAIL_ADDRESS>[21:44] <Bashing-om> guiverc: I am 98% sure .. I think that is above the credibility limit :)
[21:45] <guiverc> yeah i concur, but I usually get some sort of confirmation of 'who' before I change wiki on requests...
[21:45] <Gerowen> Should be arriving shortly.
[21:46] -SwissBot:#ubuntu-news- ::Planet:: Sam Hewitt: Basic Linux Virtualization with KVM @ https://samuelhewitt.com/blog/2019-02-16-basic-linux-server-virtualization-with-kvm
[21:46] <guiverc> thanks Marcus.
[21:49] <Bashing-om> smoke break !
[21:49] <guiverc> Gerowen, look at your page, and would you like any other info deleted  (eg. location, etc) - but if you have requests, you now have my email anyway (a contact of a wiki-editor)
[21:50] <guiverc> (as long as it's not a bush-fire smoke break ; wild fire's I think you call em)
[21:51] <Gerowen> guiverc: Nope looks good for now, if I need any major changes made to anything, what I may do is actually write it up and then just e-mail you with my username and the relevant wiki page link, thanks for helping, :-)
[21:51] <Bashing-om> guiverc: By the way - Gdoc - I done some bit of work on it this AM .. and added a couple of new items .. Hope we get all done tonight .. soon as Mike has an opportunity to agree to the edits .
[21:51] <Gerowen> Well, and the text of the requested changes.
[21:54] <guiverc> I'll look later Bashing-om , I'll go shooting if possible, and look when I return (unless I don't go)
[21:57] <guiverc> thanks Gerowen for offer of writing/aiding with wiki - really appreciated.  It helps the whole Ubuntu community.
[22:00] <Bashing-om> Gerowen: Another set of eyes on " WorK In Progress" will not offend us in the least :)


[05:20] <TheMuso> Trevinho: Re the new shutdown/restart dialog in raring thats rendered by unity... Can that be disabled with a gsettings key?
[07:22] <mmrazik> didrocks: regarding https://code.launchpad.net/~private-ps-quality-team/cupstream2distro-config/ubuntu-phone-coreapps/+merge/152757
[07:22] <mmrazik> didrocks: it is not about the phablet stuff we talked about yesterday
[07:22] <mmrazik> didrocks: those are community driven projects running on separate jenkins: http://<IP_ADDRESS>:8080/
[07:22] <didrocks> mmrazik: they are still not in ubuntu and rely on the phablet infra?
[07:23] <didrocks> mmrazik: for me, they are part of the same "set" of things to land
[07:23] <mmrazik> didrocks: ok. I wanted to have them a bit separated so somebody doesn't deploy them on wrong jenkins by accident
[07:23] <mmrazik> but we can workaround that, I guess
[07:24] <didrocks> mmrazik: yeah, I think it will be good to keep them in a separate stack
[07:24] <didrocks> but still part of the "phablet" project
[07:24] <didrocks> until we move to head
[07:24] <didrocks> which is still unsure for raring
[07:24] <mmrazik> didrocks: ok
[07:25] <mmrazik> didrocks: btw. phablet dir already exists
[07:25] <mmrazik> created it this morning
[07:25] <didrocks> mmrazik: oh excellent! :-)
[07:25] <mmrazik> the project names are still different, though (unity-phablet)
[07:25] <didrocks> mmrazik: no worry for you if we move the stack name in the near future?
[07:26] <didrocks> mmrazik: yeah, that's someting I can help you (but only next week) to fix
[07:27] <mmrazik> didrocks: re. renaming the stacks -- I don't mind. Just let me know. I will need to fix the job which is triggering the ci/autolanding jobs (right I'm not triggering all stacks as not all are migrated to cupstream2distro-config)
[07:27] <didrocks> ok
[08:48] <didrocks> davidcalle: salut!
[08:48] <didrocks> ça va?
[08:49] <davidcalle> didrocks, hey, bien et toi ?
[08:49] <didrocks> ça va :)
[13:04] <cyphermox> good morning!
[13:04] <didrocks> hey cyphermox
[13:04] <cyphermox> didrocks: so if I understand well, publish indicators+misc, rerun/with ppa oif, then publisch that too?
[13:05] <cyphermox> actually, assuming all is well re: feature freeze
[13:05] <didrocks> cyphermox: why rerunning oif?
[13:05] <didrocks> cyphermox: assuming -> you know from the MP ;)
[13:05] <cyphermox> yeah that's what I mean
[13:06] <cyphermox> still it's not obvious from the dashboard
[13:06] <cyphermox> oif> 2013-03-13 02:02:54,219 WARNING qa (head) failed to publish. Possible cause are:
[13:06] <cyphermox> just being thorough
[13:06] <cyphermox> looks like it was timing
[13:06] <didrocks> cyphermox: oif is telling that the qa tooling failed. But the test results are good
[13:06] <didrocks> cyphermox: no, the qa failed because of the "prepare" yesterday
[13:06] <didrocks> then I reran with the fix the qa stack this morning
[13:06] <didrocks> just didn't rerun oif
[13:06] <cyphermox> that's what I mean
[13:06] <didrocks> cyphermox: you can rerun oif if you want, but it's not mandatory
[13:07] <cyphermox> nah
[13:07] <didrocks> we know we can publish for sure
[13:07] <didrocks> in that case
[13:07] <didrocks> (because it's qa which failed, not a really important rdepends)
[13:07] <didrocks> makes sense?
[13:07] <cyphermox> oh yeah, I was just saying, before noticing it's actually a "timing" issue, that it possibly could just be re-tested
[13:08] <didrocks> cyphermox: as you prefer :)
[13:32] <mmrazik> didrocks: I have a problem with project names :-/ Consider this: http://pastebin.ubuntu.com/5610669/
[13:32] <mmrazik> there are a lot of phablet-extras/$something branches
[13:32] <mmrazik> so all the projects should be called phablet-extras
[13:32] <mmrazik> which is not going to work
[13:32] <mmrazik> (I agree that the project setup is just wrong but thats what we have)
[13:33] <didrocks> mmrazik: on those, I don't care about the mapping, they are transiant components that will be removed
[13:33] <didrocks> mmrazik: and project name for me doesn't necessarily map with the launchpad project (but they should)
[13:34] <mmrazik> didrocks: ok.. I'll just go with the names I have there now
[13:34] <didrocks> yep
[13:43]  * davidcalle wonders if the ctrl, c and v keys on didrocks keyboard will still work tonight. :P
[14:37] <didrocks> davidcalle: it's crazy! I'm blaming you :)
[14:37] <didrocks> davidcalle: we should really prepare in advance those kinds of features from start
[14:37] <didrocks> davidcalle: btw, a lot of tests are failing when building the scopes
[14:37] <didrocks> I'll make the list and fw it to thomas
[14:39] <davidcalle> didrocks, hmm, if you are building without libunity7, they should fail, but if you are, that's worrying...
[14:39] <didrocks> davidcalle: no, I'm with libunity7
[14:39] <didrocks> davidcalle: some keyerror
[14:39] <didrocks> or wrong diff (in case of launchpad)
[14:40] <didrocks> davidcalle: seeing how much the packaging was working, you never used bzr bd, isn't it?
[14:40] <didrocks> davidcalle: like the missing svg files ;)
[14:41] <davidcalle> didrocks, I don't have a system wide libunity7, a first package was made by someone experimented I won't name and it was all copied from here ;)
[14:42] <didrocks> davidcalle: I don't mention libunity7, but the scopes ;)
[14:42] <davidcalle> didrocks, missing svgs are totally my fault, by dismissing the fact, in templates, that scopes using local sources wouldn't have these icons.
[14:42] <didrocks> davidcalle: yeah, so nobody used the package (like bzr bd) to build it?
[14:42] <didrocks> davidcalle: you will have a look at the tests?
[14:42] <didrocks> on my list of failing, I have:
[14:42] <mterry> cyphermox, it looks like you've manually published indicators and misc.   what about the oif stack?  is that yours?
[14:43] <cyphermox> yeah
[14:43] <didrocks> calculator, zotero, github, yelp, launchpad, tomboy, weather
[14:43] <didrocks> davidcalle: ^
[14:43] <cyphermox> didn't seem to me to have anything to publish though
[14:43] <cyphermox> (ie. no changes files in the directory on magners)
[14:44] <davidcalle> didrocks, thanks. I see what the issue is with a few of these, but not all. Looking  at it.
[14:44] <mterry> cyphermox, oh, OK.  So I'll publish unity then
[14:57] <mterry> w000, reduced unity stack's allowed-failure threshold to 16 from 20.  We'll get to zero eventually
[15:15] <seb128> davidcalle, hey
[15:16] <seb128> davidcalle, is unity-scope-musique supposed to replace the music lens or is that a different service?
[15:16] <davidcalle> hey seb128
[15:16] <davidcalle> seb128, it's the "Musique" music player.
[15:17] <seb128> oh, ok
[15:17] <seb128> I didn't know there was a player named musique :p
[15:18] <davidcalle> seb128, me neither, this is a niche scope :p
[15:18] <seb128> davidcalle, quite some of those new lenses fail to build on broken tests, I guess that's a known issue? (some miss the .svg in their vcs as well which breaks install)
[15:19] <davidcalle> seb128, calculator, zotero, github, yelp, launchpad, tomboy, openweathermap? Do you have the same broken tests list?
[15:20] <didrocks> davidcalle: my broken one is merged from mine and seb128's one :)
[15:20] <davidcalle> seb128, missing svgs are my fault: scopes relying on local services don't have one, and I forgot that while doing the setup/packaging script.
[15:20] <seb128> davidcalle, yes ;-)
[15:22] <seb128> davidcalle, oh, manpages as well
[15:22] <seb128> for the failing tests
[15:23] <davidcalle> seb128, didrocks: I'm on it, from what I can see, errors go from a simple missing depend to no mock data at all for the test, or even crazy things. eg, for Openweathermap, I'm realizing that the passing of the test depends on the time of the day :)
[15:24] <seb128> yeah, the weather one is fun :p
[15:26] <didrocks> davidcalle: for missing depends, normally we check them
[15:27] <didrocks> davidcalle: but if we missed some, ensure the dep is in main please :)
[15:29] <seb128> davidcalle, those (at least) have the missing icon issue: zotero tomboy texdoc music
[15:31] <davidcalle> didrocks, I know that at least one dep is still in universe ( python3-feedparser), but that's not an issue, right mterry? :)
[15:32] <didrocks> no, it's not, python-feedparser is in main
[15:32] <mterry> davidcalle, probably not...  it looks like python-feedparser is in main already
[15:33] <davidcalle> seb128, thanks. Commenting it out like you did is probably the way to go for these. I'll ping Design for more icons (eg zotero). Sorry again about that.
[15:33] <davidcalle> mterry, thanks
[15:34] <seb128> davidcalle, no worry, thanks
[15:34] <seb128> davidcalle, mterry: right, python3-feedparser is a binary promotion, no MIR needed
[15:55] <seb128> davidcalle, googlenews tests fail in a pbuilder
[15:55] <seb128>     LOC = locale.getlocale(locale.LC_MESSAGES)[0].split(".")[0].lower()
[15:55] <seb128> AttributeError: 'NoneType' object has no attribute 'split'
[15:55] <seb128> LC_MESSAGES is not defined there
[15:56] <davidcalle> seb128, ok. I'll make it optional in a moment.
[15:57] <seb128> davidcalle, no hurry, just pointed issues I cross ... I can open bugs if there is a bug tracker and that's the preferred way
[16:23] <didrocks> mterry: reverting my WI? :/
[16:26] <mterry> didrocks, oh crap, what did I do?
[16:27] <mterry> did I forget to refresh the page?  darn it
[16:27] <mterry> it should intercept such things
[16:27] <didrocks> mterry: seems so :)
[16:27] <mterry> didrocks, I'll fix, sorry
[16:27] <didrocks> mterry: I'm sure you are just mean and it's on purpose!
[16:27] <didrocks> thanks mterry :-)
[16:41] <Esokrates> is there a special reason the maximal number of arrows displayed in the launchers is set to 3?
[16:43] <Esokrates> there would be place for more, without producing clutter ...
[16:44] <Esokrates> is it for the "readability"? I have thought the average human is capable of seeing the number of at least 7 objects in a row without counting at one glance?
[16:46] <Esokrates> it is obvious that there has to be a maximum, but I doubt that 3 is the optimum
[17:32] <didrocks> tedg: do you mind just making your changes
[17:32] <didrocks> tedg: and save once?
[17:32] <didrocks> getting 20 emails just because you save the blueprint after each character :/
[17:32] <tedg> didrocks, No, we're working together in a room so that we can all see it.
[17:33] <didrocks> tedg: I don't see why it's preventing you using gedit :)
[17:33] <didrocks> or etherpad
[17:33] <tedg> didrocks, No one has rewritten it in QML yet.
[17:33] <tedg> :-)
[17:33] <didrocks> pfffff :p
[17:33] <didrocks> come on, you have the guys for that
[17:33] <didrocks> :)
[17:35] <tedg> didrocks, Yes, the problem is that they're French, so on strike today :-)
[17:35] <didrocks> tedg: well, London is a nice city to be on strike, thinking about it :)
[17:36] <tedg> didrocks, Heh, it actually just started snowing pretty good.
[17:36] <didrocks> mmrazik: hey! so the 100scopes experimental should be good for deploying upstream merger
[17:36] <didrocks> davidcalle: mhr3: pstolowski: ^
[17:36] <didrocks> tedg: oh, lovely, enjoy :) (well, you will enjoy that less on Saturday)
[17:38] <mmrazik> didrocks: is it fine if I deploy tomorrow?
[17:38] <mmrazik> didrocks: also... right now we don't allow non-canonical people to run stuff on jenkins (unless its approved by somebody from canonical)
[17:38] <mmrazik> and there are couple non-canonical people
[17:38] <didrocks> mmrazik: I guess tomorrow is fine
[17:38] <mmrazik> so it might happen that a MP will be ignored
[17:38] <davidcalle> didrocks, awesome! Does it mean, we are now on mandatory mp for each scope branch? (not that it's not already the case *cough*)
[17:38] <mmrazik> (e.g. if created and approved by non-canonical people)
[17:39] <mmrazik> davidcalle: the system doesn't enforce it, but yes
[17:39] <didrocks> mmrazik: well, I think davidcalle will know who to bribe :)
[17:39] <didrocks> davidcalle: yeah ;)
[17:39] <didrocks> now that the packaging is set
[17:39] <didrocks> daily release to a ppa starts
[17:39] <didrocks> and upstream merging on the way :)
[17:40] <Esokrates>  is there a special reason the maximal number of arrows displayed in the launchers is set to 3?
[17:43] <davidcalle> Thanks didrocks, mmrazik. I have tiny fixes (install paths and broken tests) for a large number of branches. I'll try to have everything mp asap, but on which team should I put this review load? :)
[17:43] <didrocks> davidcalle: just ping directly mhr3, pstolowski  I guess
[17:44] <mmrazik> let me deploy the upstream merger then...
[17:44] <didrocks> or bregma, maybe you can help ^
[17:44] <mmrazik> I just don't like to do this sort of stuff at the end of my day when I have no chance to fix things :)
[17:44] <mmrazik> didrocks: oh...
[17:44] <mmrazik> didrocks: project names is a problem in that config
[17:44] <mmrazik> didrocks: we have a conclusion with fginther on how to do it but not implemented yet
[17:45] <mmrazik> postponing the deployment to tomorrow...
[17:46] <davidcalle> mmrazik, does it mean I can push some of these directly tonight and it won't affect the merging process?
[17:46] <didrocks> mmrazik: sure, I think that can wait tomorrow :)
[17:46] <mmrazik> davidcalle: ack
[17:46] <mmrazik> davidcalle: in matter of fact you can push directly even after this stuff is deployed. its just strongly discouraged :)
[17:48] <davidcalle> mmrazik, sure, but we are two on the project, both non canonical. I'm happy to have these changes reviewed, but I don't want anything to be blocked on changing an install path.
[17:49] <mmrazik> davidcalle: ack
[19:38] <sil2100> mterry: hi! I'm still doing some experiments regarding #1141079
[19:38] <sil2100> mterry: but if tomorrow evening I won't have it working, I'll try reverting the fix then


[04:52] <zeroprog> hey guys anybody know if theres something wrong with openssl's md5 functions?
[04:55] <zeroprog> it seems to produce the hash with one character missing
[05:14] <zeroprog> can somebody tell me why this is producing the wrong hash http://pastebin.com/d3d8753c1
[09:58] <mr_claus> hmm, should the abi file be generated automatically while building the kernel image? i'm wondering why some modules compiled but not in the abi modules list
[10:01] <amitk> mr_claus: yes, abi is generated after the build
[10:01] <mr_claus> amitk: there are missing some modules in flavour.modules file and i don't know why
[10:02] <amitk> mr_claus: what are you compiling, how and what are the changes you made?
[10:02] <mr_claus> amitk: i started to compile 2.6.30 from the jeremy git (xen-patches)
[10:03] <mr_claus> amitk: i used the build system from 2.6.28 and fit the files to 2.6.30
[10:04] <mr_claus> i changed changelog of course, control.d/vars.xen (created)
[10:04] <mr_claus> and config/amd64/config.xen
[10:05] <mr_claus> but ... i didn't change config/amd64/config until now
[10:06] <amitk> mr_claus: and the build is complaining about missing modules?
[10:06] <mr_claus> after a "find . -name 'sata_sil*' i get
[10:06] <mr_claus> ./build/build-xen/drivers/ata/sata_sil.o
[10:06] <mr_claus> ./build/build-xen/drivers/ata/sata_sil24.o
[10:06] <mr_claus> but the two modules are not in the .deb
[10:07] <mr_claus> and not in the xen.modules
[10:07] <alex_joni> mr_claus: did .ko's get built?
[10:07] <mr_claus> alex_joni: no
[10:09] <amitk> mr_claus: and the module is enabled in the configs? 'debian/rules editconfigs' to edit them interactively
[10:14] <mr_claus> amitk: with editconfigs the files in config/amd64/config.* will be modified, right?
[10:15] <mr_claus> amitk: in config/amd64/config there are SATA_SIL and SATA_SIL24 set to "y"
[10:17] <mr_claus> amitk: but the interesting is, if i run editconfigs it looks different
[10:17] <mr_claus> amitk: are there some docs how that is working?
[10:18] <mr_claus> amitk: no, it doesn't look different, the modules are configured
[10:21] <amitk> mr_claus: after exiting from all editconfigs, updateconfigs will be run automatically. Make sure the modules are still there after that.
[10:23] <mr_claus> amitk: still there mean inside of config/amd64/config?
[10:23] <mr_claus> i checked .config inside of of build dir debian/build/build-xen/
[10:23] <mr_claus> the modules are set to "y" too
[10:24] <mr_claus> and in config/amd64/config the modules set to "y"
[10:25] <mr_claus> ahh, sry, my fault
[10:25] <mr_claus> i'm blind, y means inside of kernel
[10:26] <mr_claus> seems the night was to long and my brain was afk
[10:29] <amitk> mr_claus: heh. Good catch. :)
[12:27] <lamalex> Hi- is there a ppa for 2.6.30 that has the ubuntu sauce patches?
[12:28] <alex_joni> lamalex: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/ ?
[12:29] <lamalex> that's not just upstream?
[12:30] <alex_joni> might be, just googled it
[12:30] <lamalex> yeah i thought it was upstream
[12:30] <lamalex> figured someone here would actually know
[12:34] <alex_joni> lamalex: there is a package for lpia
[12:34] <alex_joni> https://launchpad.net/ubuntu/karmic/lpia/linux-source-2.6.30/2.6.30-8.9
[13:19] <amitk> apw: how are the splitconfig patches looking?
[13:19] <apw> they look ok in general, there is some purley cosmetic stuff in there which i don't know if you intended
[13:19] <apw> also the rename is going to cause me pain.  still have to actually test them, got sidetracked on some kms kernels
[13:20] <apw> and writing up your new blueprint :)
[13:23] <amitk> apw: cosmetic changes such as getting rid of commented lines, etc.?
[13:23] <apw> i saw a couple of what must be pure white space changes in there
[13:24] <apw> the one which sticks in my mind was in the rename patch which has a couple i think
[13:24] <apw> i need to review them agian once i've tested them
[13:25] <amitk> apw: there were a few space to tab conversions that I threw in there as I ran across them.
[13:25] <apw> probabally waht they are then
[13:28] <rtg> amitk: I'll be taking a look at them shortly. I'm also gonna start working on the flavour changes
[13:50] <rtg> apw: uploading linux_2.6.30-9.10
[13:50] <apw> rtg reached my upload email then :)