[00:38] <perrito666> ericsnow: the auto thingisnot workingright?
[01:00] <wallyworld_> sinzui: hey, remind me, did we agree that the simplestream content id for tools should be "com.ubuntu.juju:released:tools" always? even for devel/proposed? the devel/proposed tools like at a different url of course, but are we going to lie in the content ids inside the json?
[01:01] <wallyworld_> the current code in master generates ids like com.ubuntu.juju:proposed:tools or com.ubuntu.juju:devel:tools which don't match what's in the json
[01:04] <sinzui> wallyworld_, I don't like the lie, but we never agreed to remove it
[01:04] <wallyworld_> sinzui: ok. in that case, i'm not sure how 1.21-alpha1 is finding tools
[01:05] <wallyworld_> because the code is generating the wrong ids
[01:05] <sinzui> wallyworld_, right. I think a real change requires a longer transition.
[01:06] <wallyworld_> sinzui: we can make a fix for alpha2 which generates the expected content ids
[01:06] <wallyworld_> sinzui: just to confirm, proposed will live at http://streams.canonical.com/juju/proposed/tools/
[01:06] <sinzui> yes
[01:06] <wallyworld_> devel will live at http://streams.canonical.com/juju/devel/tools/
[01:07] <sinzui> yep
[01:07] <wallyworld_> ok, that's what the code assumes, bt with the wronf content id
[01:07] <wallyworld_> so we'll do a fix
[01:07] <sinzui> wallyworld_, I think we need to teach 1.21 that it will change, but probably not change until 1.22
[01:08] <wallyworld_> sinzui: yeah, i guess it could look for the correct id and fall back to the incorrect one
[01:08] <sinzui> wallyworld_, We never say you can upgrade from devel to devel though. alpha1 might be able to upgrade to alpha2, but we never say it is so
[01:08] <wallyworld_> messy but doable
[01:08] <wallyworld_> i would prefer just to fix the ids for alpha2
[01:09] <wallyworld_> ie have the json generated with com.ubuntu.juju:proposed:tools etc
[01:09] <wallyworld_> but if that's not doable, we will have to code the fallback option
[01:10] <wallyworld_> which will be very messy
[01:13] <wallyworld_> sinzui: let me know your thoughts and we can code the solution to work with what's possible for you
[01:15] <sinzui> wallyworld_, I think we can fix the values in the json, and announce that upgrades from a1 to a3 are not supported...unless sync-tool from alpha2 clients will work
[01:17] <wallyworld_> sinzui: sync-tool should write the correct json, so it *should* work. but +1 to making it all correct now during the alpha release stage before it's too late to fix
[01:18]  * thumper takes a deep breath, and continues with deep refactoring dive
[01:18] <wallyworld_> axw: standup?
[01:20] <axw> oops
[01:20] <axw> brt
[01:35] <davecheney> mercurial hates me
[01:35] <davecheney> $ hg pull -u
[01:35] <davecheney> abort: error: _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[01:35] <davecheney> i know _why_ this stopped working
[01:35] <davecheney> but I don't know _how_ to fix it
[01:39] <perrito666> davecheney: doesn't hg allow you to ignore the cert somehow?
[01:43] <davecheney> perrito666: maybe
[02:38] <davecheney> make: Warning: File `../../Make.dist' has modification time 1.4e+09 s in the future
[02:38] <davecheney> dfc@bauer:~/go/src/cmd/7a$ date
[02:39] <davecheney> Thu Jan  1 01:29:47 EST 1970
[02:39] <davecheney> oh wow
[02:39] <davecheney> i guess that is why https wasn't working
[03:55] <wallyworld_> axw: hi, review baord and 1.20 aren't playing nicely, could you take a look at this for me? https://github.com/juju/juju/pull/929
[04:05] <axw> wallyworld_: will do
[04:05] <wallyworld_> ty
[04:16] <axw> wallyworld_: what part bind-mounts the storage dir?
[04:16] <wallyworld_> axw: container/lxc/lxc.go
[04:17] <wallyworld_> mountHostToolsDir()
[04:17] <axw> why is it doing that? :/
[04:18] <wallyworld_> so the container doesn't have to go to http storage to get tools cause there's a race condition on startup
[04:18] <wallyworld_> containers would sometimes fail to download tools in cloud init
[04:18] <wallyworld_> because the http storage wasn't available
[04:18] <axw> yeah, so we put in retries right?
[04:19] <wallyworld_> i think that was after this fix
[04:19] <axw> the agent will rm -fr /var/lib/juju on destruction, so mounting anything in there is going to be bad
[04:19] <wallyworld_> yes
[04:19] <axw> I guess it's too late for 1.20
[04:19] <wallyworld_> hence this fix
[04:20] <axw> what I mean is, this is working around it - it would be better not to mount it
[04:20] <wallyworld_> the fix mounts it to /tmp instead but i guess now that retries are there the mount is no longer needed
[04:20] <wallyworld_> at lease that assumes the retires will fix the original issue
[04:21] <wallyworld_> i'dhave to re-read the orignal bug
[04:22] <axw> wallyworld_: reviewed
[04:22] <wallyworld_> ty
[04:24] <wallyworld_> axw: ah, i think i remember - some hosts had port 8040 closed
[04:24] <wallyworld_> hence the curl to the http provider failed
[04:25] <wallyworld_> so retries won't help
[04:28] <axw> wallyworld_: ah yeah. anyway, shouldn't be a problem in trunk at least
[04:28] <wallyworld_> yup
[04:54] <wallyworld_> axw: i'm wondering if we should randomise the choice of availability zone when none is explicitly specified and we just iterate over the available zones till we find one where startinstance works
[04:55] <axw> for openstack?
[04:55] <wallyworld_> yeah, but also for ec2
[04:55] <wallyworld_> i'm implementing the choice for openstack
[04:56] <axw> wallyworld_: we could randomise at each level of population
[04:56] <wallyworld_> since it currently always uses the first zone
[04:56] <axw> otherwise it would defeat the algorithm
[04:56] <axw> wallyworld_: it uses the first of the ones with the least population from the group
[04:56] <axw> under the assumption that it wouldn't fail, which obviously was wrong
[04:57] <wallyworld_> ah, right, in that case i might not do any extra
[04:57] <axw> I suggest we just iterate through in ascending order of population
[04:57] <axw> like in ec2
[04:57] <wallyworld_> yup, ok
[04:57] <axw> we could always change the underlying code in provider/common later to randomise if it's valuable
[04:58] <wallyworld_> axw: so in openstack, we do this: zoneInstances, err := availabilityZoneAllocations(e, group)    and then zone-to-use = zoneInstances[0].ZoneName
[04:59] <wallyworld_> i'm just going to iterate over the slice and try start instance on each zone till it succeeds
[04:59] <wallyworld_> like in ec2
[04:59] <wallyworld_> the code in there now matches the bug symptom
[04:59] <wallyworld_> where it always tries just the same zone each tome
[05:12] <axw> wallyworld_: right, I agree with that approach
[05:13] <wallyworld_> coolio
[05:13] <axw> wallyworld_: in ec2 we check for a specific error code, and bail on others
[05:13] <axw> not sure if there's an equivalent on openstack
[05:13] <wallyworld_> axw: yep, openstack returns just a 500 sadly
[05:13] <wallyworld_> so i gotta check the message :-(
[05:13] <axw> wallyworld_: I meant error-code-string in the body
[05:13] <axw> same as aws then
[05:14] <wallyworld_> our goose library will return an UnspecifiedErrorCode I think. the underlying openstack message is "No valid host was found"
[05:15] <wallyworld_> goose gets a http 500 response code
[05:54] <wallyworld_> jam: bug 1383260 is related to scalability - do you have any comments based on your previous work in this area. i fear it will not be something we can easily fix
[05:54] <mup> Bug #1383260: 1.20.10/MAAS 1.5 relations not being 'started' in a large environment <deploy> <maas-provider> <scale-test> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1383260>
[06:12] <jam> wallyworld_: well he did say "it did eventually complete" but was slow and high CPU/memory. I don't have any specific notes on what we could do to fix that, we just need testing and profiling.
[06:12] <jam> wallyworld_: He had ~300+ items and then added a subordinate, which creates 300 new units right away
[06:13] <wallyworld_> jam: yep, i wasn't sure if you had any previous profiling which may have showed that issue
[06:13] <jam> wallyworld_: I was aware that adding a subordinate is painful, but when I did it with 1k nodes, it pretty much just died. And I haven't done it for a long time. I had actually forgotten about it.
[06:13] <wallyworld_> ok, np
[06:14] <wallyworld_> i think the bug shoud be moved off 1.20
[06:14] <wallyworld_> as we won't get to fix it for that release
[06:48]  * fwereade will be off in a few mins, back when I'm in a hotel on the next island, not far but might be a bit of a wait for the boat
[07:48] <voidspace> morning all
[08:01] <wallyworld_> axw: thanks for review. i did
[08:01] <wallyworld_> .
[08:01] <wallyworld_> add a test for that eror path i think
[08:01] <wallyworld_> TestStartInstanceWithUnknownAZError
[08:02] <axw> wallyworld_: yeah I saw it later... sort of tests it indirectly, but that's good enough
[08:02] <wallyworld_> yeah, i thought it would be sufficient
[08:02] <axw> what I meant specifically was in that test, do we get az3 after failing to get az2, or did we go straight to az3
[08:02] <axw> but anyway, don't worry about it
[08:04] <wallyworld_> ah, i see your point
[08:05] <wallyworld_> the other tests sort of prove that we would  hit az2 first
[08:05] <wallyworld_> but yeah, not 100% sufficient
[08:30] <voidspace> wallyworld_: axw: can one of you run this code and tell me what it outputs please
[08:30] <voidspace> http://pastebin.ubuntu.com/8612039/
[08:30] <voidspace> I'm seeing "none", which surprises me
[08:31] <axw> voidspace: hey. sure, one moment
[08:31] <voidspace> it should print the id of the default-vpc for the account
[08:31] <voidspace> axw: thanks
[08:31] <voidspace> no hurry, I'm grabbing coffee
[08:31] <axw> voidspace: I also get "none"
[08:32] <wallyworld_> voidspace: none for me too
[08:32] <voidspace> so either we have no default-vpc for that region, or goamz is buggy, or the amazon api is buggy
[08:32] <voidspace> I tried a couple of different regions and got none for the ones I tried
[08:32] <voidspace> wallyworld_: thanks
[08:32] <voidspace> not just my credentials then
[08:34] <axw> voidspace: "ec2-describe-account-attributes default-vpc" gives me something other than none
[08:34] <axw> so it's not the first case
[08:35] <voidspace> ah, cool
[08:35] <voidspace> well, distinctly uncool
[08:35] <voidspace> but thanks
[08:36] <voidspace> and dimiter is off today of course :-)
[08:45] <axw> voidspace: sorry
[08:45] <axw> I was wrong
[08:45] <axw> I forgot, I changed my default region in my dot file
[08:45] <axw> so ec2-describe-account-attributes was describing ap-southeast-2
[08:46] <axw> voidspace: us-east-1 does return "none" when using that too
[08:46] <voidspace> axw: ah
[08:47] <voidspace> axw: I get "Client.Unauthorized: Not Authorized"
[08:47] <axw> using ec2-describe-account-attributes?
[08:47] <voidspace> yep
[08:47] <voidspace> and the ec2-describe-regions
[08:47] <axw> you sourced your creds?
[08:47] <voidspace> yep :-)
[08:48] <voidspace> if you don't do that then you get a traceback instead
[08:48] <voidspace> and naturally it uses different environment variables to the ones we (and goamz) uses
[08:48] <axw> dunno then - just works for me
[08:48] <voidspace> axw: I'm reading the docs
[08:49] <voidspace> but I'll try ap-southeast from goamz
[08:50] <axw> ah yeah, I should've tried that. yep, works fine
[08:50] <voidspace> axw: for me too
[08:50] <voidspace> code is probably correct
[08:51] <voidspace> I wonder why my command line tools don't work
[09:39] <voidspace> Hmmm... my reviewboard review didn't have a reviewer set
[09:39] <voidspace> Nor does it appear to have a diff
[09:39] <voidspace> http://reviews.vapour.ws/r/211/
[09:39] <voidspace> I'll have to harass ericsnow
[09:40] <voidspace> Ah, known issue but thought fixed...
[10:39] <fwereade> wwitzel3, ping
[10:47] <voidspace> jam: are you around?
[10:47] <jam> voidspace: clicking on the link now
[11:04] <voidspace> jam: http://reviews.vapour.ws/r/211/diff/1/#1
[12:05] <fwereade> if anyone's familiar with the details of what the uniter's trying to do with proxy settings, please let me know
[12:19] <wallyworld_> fwereade: i know a little, what did you want to know?
[12:20] <fwereade> wallyworld_, so, we rewrite the environment with new proxy settings
[12:20] <wallyworld_> it basically allows the user to update the http/ftp/apt proxy settings via an environment config change, and have the hook context reflect those settings when a hook is run
[12:20] <fwereade> wallyworld_, what about the impact on the http package?
[12:21] <fwereade> wallyworld_, is there any? if so, do we depend on it? if so, how do we deal with the implicit races?
[12:21] <wallyworld_> fwereade: well, it sets the HTTP_PROXY env var, so that will affect the http package too
[12:21] <fwereade> wallyworld_, quite so
[12:21] <wallyworld_> if hook tools invoke http calls
[12:21] <fwereade> wallyworld_, that's the source of my concern
[12:21] <fwereade> wallyworld_, it's not just the hooks that invoke http calls
[12:21] <fwereade> wallyworld_, the uniter downloads charms itself
[12:22] <fwereade> wallyworld_, and... hmm, the upgrader doesn't any more, does it?
[12:22] <wallyworld_> sure, but the uniter downloading charms would need to use any http proxy setting the user deemed necessary
[12:23] <fwereade> wallyworld_, that is, it doesn't because the machine agent's upgrader is guaranteed to have coincidentally downloaded everything already
[12:23] <wallyworld_> yes
[12:23] <fwereade> wallyworld_, ok, but what happens when the env setting change races with the charm download?
[12:23] <wallyworld_> how do you mean?
[12:24] <fwereade> wallyworld_, well, we rewrite the env -- and the http package reads the env -- what happens when they collide? can they collide? I may be worrying about nothing
[12:24] <fwereade> wallyworld_, can we get nonsense in the proxy settings if we kick off a charm download at just the wrong time?
[12:25] <fwereade> wallyworld_, are we maybe safe explicitly downloading charms with no proxy? given that they should always come from the local state server
[12:25] <fwereade> wallyworld_, wait scratch that we're not
[12:25] <fwereade> wallyworld_, manual env :/
[12:25] <wallyworld_> i must admit i don't see an issue. when an env i bootstrapped, the user chooses if they want to set the http proxy in their env.yaml. then later, they can change it using a set-env call, which sends the change to the uniters
[12:26] <fwereade> wallyworld_, it's purely about the details of what's happening in-memory
[12:26] <fwereade> wallyworld_, is a change of env vars atomic?
[12:27] <fwereade> wallyworld_, even if it is, does the http package read them atomically, or could it get non-matching HTTP_PROXY and NO_PROXY values?
[12:27] <wallyworld_> not sure. but the seq from a system perspective is: cange hits db -> watcher invoked -> uniter notices -> uniter calls os.SetEnv()
[12:27] <wallyworld_> oh i see what you are asking
[12:27] <fwereade> wallyworld_, yeah, I'm fine with what's going on at a high level
[12:28] <wallyworld_> if the user changes 2 env settings via single set-env call, will that translate into a single EnvironConfig changed event
[12:28] <wallyworld_> i would hope so
[12:28] <fwereade> wallyworld_, even lower level
[12:28] <fwereade> wallyworld_, how does a call to os.SetEnv affect a concurrent http.Get
[12:29] <wallyworld_> no idea
[12:29] <wallyworld_> i would expect that the tcp connection already made will stick
[12:29] <fwereade> wallyworld_, I guess we have the same problem, if it is one, in the machine agent anyway
[12:29] <fwereade> wallyworld_, that's doing the same stuff essentially
[12:29] <wallyworld_> yeah
[12:30] <fwereade> wallyworld_, ok, I will pretend it's not an issue for now
[12:30] <wallyworld_> i can't see a very common use case of http proxy changing after bootstrap
[12:30] <wallyworld_> but i guess it's something to be considered
[12:30] <fwereade> wallyworld_, yeah, my suspicion is that it's a bug but not one anyone will actually hit in practice
[12:30] <wallyworld_> i agree
[12:31] <wallyworld_> but, knowing our luck, someone important will be unlucky
[12:31] <wallyworld_> i hadn't thought about it too much, didn't write that code
[12:31] <fwereade> wallyworld_, so what I should really do is scrap the yucky uniter code, parameterise machineenvironmentworker, and run one of those in the unit agent (that doesn't write to the global location and just hits the os.Env)
[12:31] <fwereade> wallyworld_, no worries
[12:32] <fwereade> hmm
[12:32] <fwereade> I wonder, what's the worst that could happen if I just scrap the code in the uniter, and grab proxy settings for each hook context individually?
[12:34] <fwereade> charm downloads won't use the proxy... but they're (1) almost certainly local and (2) ha, it looks like they're not guaranteed to anyway
[12:34] <fwereade> ffs
[12:35] <wallyworld_> fwereade: charm dowsnloads will soon be via the charn store
[12:35] <wallyworld_> the local charm store
[12:35] <wallyworld_> so it won't matter anyway
[12:35] <fwereade> wallyworld_, yeah
[12:37]  * fwereade just saw a check on provider type inside a worker and experienced a brief moment of apoplectic rage
[12:37]  * fwereade better now
[12:37] <wallyworld_> oh no, which worker?
[12:49] <wwitzel3> fwereade: pong
[12:50] <fwereade> wwitzel3, what's the status of the juju-run-in-relation-context work?
[12:51] <fwereade> dammit I have to break for a moment
[12:51] <fwereade> wwitzel3, would you let me know when I'm back on? hopefully just a few mins
[12:52] <wwitzel3> fwereade: it just needs to be reviewed
[12:55]  * perrito666 just learned what apopletic rage is
[13:04] <fwereade> wwitzel3, back, sorry
[13:04] <wwitzel3> fwereade: np
[13:44] <jcw4> w7z: did you get a chance to review http://reviews.vapour.ws/r/197/ ?
[13:53] <sinzui> natefinch, do you expect golang 1.2 win-amd64 to "just work" when I build 386 juju.exe with goarch=386?
[13:54] <w7z> jcw4: yes, I think we should land, but we also need to coordinate when it happens, as I need to change the landing script at the same time
[13:55] <w7z> jcw4: lets do that
[13:59] <w7z> jcw4: oh yeah, my one question was have you checked calling to the other script still works when the pre-push one is symlinked into .git/blah ?
[14:02] <natefinch> sinzui: yes
[14:02] <sinzui> thank you natefinch
[14:15] <voidspace> TheMue: I updated by PR by the way
[14:15] <voidspace> TheMue: added a const for "none"
[14:18] <TheMue> voidspace: hehe, thanks
[14:19] <TheMue> voidspace: just found in my PR that we always use strings for the provider types, which is convenient but error prone
[14:21] <ericsnow> natefinch: we basically had a 1-on-1 yesterday, but we can go today if you want to
[14:21] <voidspace> TheMue: :-)
[14:22] <sinzui> natefinch, sorry, I am confused by go building. Do I need to run make.bat each time I switch the target architecture?
[14:27] <natefinch> sinzui: just once per architecture... it'll put the binaries in a separate directory, and it'll use the right ones when crosscompiling
[14:27] <natefinch> sinzui: er once per arch/OS
[14:28] <sinzui> natefinch, that is what I hoped. this make.bat seems to think I want gcc :(
[14:33] <natefinch> sinzui: to be honest, I just use Dave Cheney's scripts, it makes it trivial: http://dave.cheney.net/2013/07/09/an-introduction-to-cross-compilation-with-go-1-1
[14:33] <natefinch> ericsnow: let's have a quick 1 on 1 anyway
[14:33] <ericsnow> natefinch: k
[14:34] <sinzui> natefinch, Me too, but in the case of windows, I cannot verify immediately what was built passes a smoke test. We build on windows just like we build our ubuntu packages on the real arch
[14:37] <jcw4> w7z: yeah, sorry did test that - yep.
[14:37] <jcw4> w7z: will wait to push til you're ready
[14:38] <w7z> jcw4: will give you the okay in a sec
[14:38] <jcw4> ta
[14:39] <ericsnow> natefinch: sorry, hangouts died
[14:39] <natefinch> ericsnow: haha ok
[14:39] <natefinch> ericsnow: I was talking and talking and then noticed you weren't moving anymore
[14:51] <w7z> jcw4: okay, go
[14:52] <jcw4> kk
[14:58] <jcw4> sorry.. added x bit
[15:03] <natefinch> I sort of wish the local provider didn't exist.... it confuses people into thinking they should use juju the way they use other deployment systems - i.e. SSH into the machine where you want to deploy stuff and start running juju there.
[15:04] <sinzui> natefinch, me too :(
[15:17] <sinzui> arosales, can you try a bootstrap in azure West US? I can only bootstrap in East US.
[15:18] <arosales> sinzui: sure. I am in a few meetings atm, but should be able to try at the top of the hour.
[17:21] <voidspace> ok all, g'night
[17:32] <w7z> I'm out for a bit, ping me if the landing bot is unhappy should anyone try it later and have issues
[17:35] <natefinch> ericsnow: btw, I made a review and it didn't give me a diff, so I closed the PR, made a new PR and now reviewboard isn't picking up the PR at all.  This is probably an edge case, but wanted you to be aware.
[17:37] <ericsnow> natefinch: this is actually an issue of RB having a unique constraint on the repo revision on each  review request and how discarded review requests hold on to that
[17:37] <natefinch> ericsnow: figured it was something like that.   What's the workaround?  poke my PR with a new commit?
[17:38] <ericsnow> natefinch: that should do it or you could use rbt -u
[17:38] <ericsnow> natefinch: and make sure that old review request is open
[17:39] <natefinch> gah, stupid "File was not found in the repository"
[17:39] <natefinch> probably why there was no diff in the first place
[17:39] <natefinch> this is from a clean master and only fixing a typo (no new files or anything)
[17:40] <ericsnow> it's amazing what happens to your terminal when you run "cat /dev/urandom" :(
[17:41] <ericsnow> natefinch: yeah, I'm looking into several of those right now
[18:10] <perrito666> aghghh import cycle with dummy provider
[18:10] <natefinch> the dummy provider imports stuff?  That seems bad
[18:11] <perrito666> natefinch: import apiserver
[18:13] <natefinch> perrito666: so much for being a dummy :/
[18:13] <perrito666> lol
[18:14] <perrito666> uff, more than 30C outside and I live in a country where drinking individually is seen with bad eyes
[18:14] <perrito666> what a torture
[18:19] <jcw4> perrito666: you need to get a cutout of a drinking buddy
[18:21] <perrito666> jcw4: on the good side, beer is way easier to get in 1l bottles than in individuals
[18:21] <jcw4> perrito666: lol
[18:22] <jcw4> I think they call that a tallboy here
[18:53] <perrito666> anyone knows exactly what is the purpose of the apiServer member of environState struct?
[18:53] <perrito666> seems to be barely used
[18:56] <natefinch> nope
[18:58] <natefinch> perrito666: seems to only get stopped when environState is closed.  that's the only use I see
[18:59] <natefinch> perrito666: it boggles my mind that the dummy provider starts a real apiserver
[19:00] <perrito666> natefinch: I am not sure if its there for some obscure use we dont know of
[19:00] <perrito666> natefinch: yes, beats a bit the dumminess
[19:01] <natefinch> perrito666: so, apiserver.NewServer() has a side effect of running a tls listener
[19:01] <natefinch> perrito666: likely some tests are expecting to be able to actually connect to an API
[19:02] <natefinch> perrito666: but it's probably worth seeing what happens if you just comment it out
[19:28] <perrito666> well the test is killed by sigquit
[19:29] <thumper> morning folks
[19:30] <natefinch> morning thumper
[19:30] <perrito666> thumper: morning
[19:39]  * perrito666 ponders how to fix this without writing a dummy apiserver
[19:42] <natefinch> perrito666: what's the import cycle?
[19:42]  * natefinch thinks that sounds like a bad song from the 90's
[19:43] <perrito666> http://pastebin.ubuntu.com/8618809/
[19:43] <perrito666> natefinch: sounds something you would ask in a star trek episode during an engineering crisis
[19:44] <natefinch> ug
[19:45] <thumper> hmm...
[19:45] <thumper> ericsnow: getting errors with rbt
[19:45] <bodie_> howbazaar = howbazaar on IRC, right?
[19:45] <thumper> error uploading diff
[19:46] <thumper> bodie_: wat?
[19:46] <natefinch> bodie_: howbazaar = thumper you mean
[19:46] <bodie_> oooh
[19:46] <ericsnow> what's the error?
[19:46] <bodie_> okay :)
[19:46] <natefinch> bodie_: and yes
[19:46] <thumper> twitter?
[19:46] <thumper> bodie_: unfortunately thumper was taken
[19:46] <bodie_> thumper, just looking for a ping back on reviewboard 178 when you have a spare minute
[19:46] <natefinch> probably anyone named howbazaar anywhere is thumper :)
[19:46] <thumper> probably
[19:47] <bodie_> sorry -- I'm not too savvy with IRL handles
[19:47] <thumper> surprisingly I'm neither howbazaar nor thumper IRL
[19:47] <natefinch> lol
[19:48] <bodie_> that's Thumper H. Bazaar to you
[19:49] <natefinch> great psuedonym
[19:49] <ericsnow> thumper: what error are you getting?
[19:49] <katco> is there an example of how to stub a machine with a given id for a test anywhere?
[19:50] <natefinch> ericsnow: you took out that "screw you, thumper" easter egg, right?
[19:50] <ericsnow> natefinch: oh, shoot!
[19:50] <thumper> ericsnow: error uploading diff
[19:51] <ericsnow> thumper: no other info?
[19:51] <natefinch> perrito666: so, you're changing peergrouper tests to do something that requires the testing package?
[19:52] <thumper> ericsnow: The file was not found in the repository. (HTTP 400, API Error 207)
[19:52] <thumper> Your review request still exists, but the diff is not attached.
[19:52] <natefinch> thumper: yeah, a bunch of us are getting that
[19:52] <thumper> hmm...
[19:52] <thumper> natefinch: any suggestions?
[19:53] <natefinch> thumper: ericsnow's been looking at it today, but I don't think he's figured it out.  Manual upload of the diff is probably the only workaround right now.
[19:54] <thumper> oh? how do we do that?
[19:54]  * thumper found a link
[19:56] <thumper> got an error uploading diff: The file "api/client.go" (revision b373c16) was not found in the repository
[19:57] <thumper> which is bollocks
[19:58] <natefinch> yeah, I got the same thing for my PR, which was just a 2 character change
[19:59] <thumper> so... anyone up for a 4k review?
[20:00] <thumper> Showing ￼ 36 changed files  with 1,924 additions and 1,237 deletions.
[20:00]  * thumper feels hopeful
[20:00] <natefinch> zoikes
[20:00]  * natefinch is OCR
[20:00] <thumper> natefinch: hey there buddy
[20:00] <natefinch> :D
[20:01] <thumper> natefinch: was reviewed by menno, katco, axw and william already
[20:01] <thumper> I was just following up, tweaking
[20:01] <thumper> lots of new docstrings
[20:01] <natefinch> well shit, I can just rubberstamp, right?
[20:01] <thumper> but now rb is all in a fuss
[20:01] <katco> thumper: sorry about the dupes. menno and i overlapped a bit
[20:01] <thumper> katco: that's fine
[20:01] <thumper> made them easy to address
[20:01] <natefinch> doh, guess it'll have to wait until tomorrow when someone else is OCR...
[20:01] <katco> thumper: we didn't know we were reviewing the same thing. on the plus side, you got a new high score :)
[20:02]  * thumper is winning!
[20:02] <katco> haha
[20:02] <natefinch> thumper: so is there a diff?
[20:03] <natefinch> sinzui: https://bugs.launchpad.net/juju-core/+bug/1370149  is not reproducible for me on trunk.
[20:03] <mup> Bug #1370149: No defined 'state-servers' on environment file after bootstrap, works after run 'juju status' <bootstrap> <cloud-installer> <cts> <juju-core:Triaged> <https://launchpad.net/bugs/1370149>
[20:04] <thumper> natefinch: https://github.com/juju/juju/pull/905/files, or http://paste.ubuntu.com/8618992/
[20:04] <thumper> natefinch: http://reviews.vapour.ws/r/169
[20:05] <davechen1y> thumper: hang on i have to reboot before the hangout
[20:05] <thumper> kk
[20:06] <sinzui> natefinch, Shall we mark it fix committed in 1.21-alpha2?
[20:07] <natefinch> sinzui: seems to be true
[20:08] <sinzui> okay, thank you very much natefinch
[20:09] <perrito666> natefinch: I am not, I actually added restore, which is part of backups which is registered as a facade by apiserver and since dummy env imports apiserver that creates the cycle
[20:10] <natefinch> dang
[20:10] <perrito666> and well dummyserver is used by testing which is used by the peergrouper tests
[20:11] <natefinch> I wonder if we can break the cycle at testing -> dummy
[20:11] <natefinch> unless the peergrouper tests need dummy server, which is possible I guess
[20:11] <natefinch> er dummy provider
[20:13] <perrito666> they dont seem to directly but I have not checked if seccond hand they do, I am guessing they do since when I tweak a bit dummy server to remove apiserver they end up being killed for too much wait
[20:16]  * perrito666 drinks a mate and says ugly things in spanish
[20:28] <natefinch> ericsnow: it looks like the diff upload problem is trickling into existing reviews: http://reviews.vapour.ws/r/212/diff/#
[20:29] <ericsnow> natefinch: k
[20:30]  * perrito666 sees ericsnow twitching
[21:00] <thumper> ericsnow: there also seems to be a big difference in my branch where I've moved some files around
[21:00] <thumper> ericsnow: on github they show as moves with minor edits
[21:00] <thumper> ericsnow: oh rb, it shows as deletes and adds
[21:01] <perrito666> thumper: ouch sorry me commenting on something you where reviewing might have caused you an issue
[21:01] <ericsnow> thumper: yeah, something is out of sync with the base revisions
[21:01] <ericsnow> thumper: I'm looking into the caching the reviewboard does
[21:35] <wallyworld_> sinzui: question - given that 1.21 looks for streams content ids like "com.ubuntu.juju:<stream>:tools", we will either need to teach 1.20 to look for such content ids, or publish metadata using both "release" and <stream> in the proposed and devel streams
[21:37] <wallyworld_> we current use tools-metadata-url to tell 1.20 how to find devel and proposed tools, but once/if we change the content ids, 1.20 won't be able to find any metadata
[21:40] <wallyworld_> and right now, 1.21 can't find proposed/devel metadata due to the different content ids
[21:43] <perrito666> hey wallyworld_ IRQ when you have a sec
[21:43] <wallyworld_> IRQ?
[21:43] <perrito666> I am obviously asking for processor time on you :p
[21:44] <wallyworld_> lol
[21:44] <wallyworld_> is that non maskable
[21:45] <perrito666> I certainly hope so :p I dont feel like being idle waiting
[21:45] <perrito666> I know your time you are completely unfair scheduling :p
[21:46] <perrito666> always handling to those that dont bring problems
[21:47]  * wallyworld_ saves registers and current stack frame
[21:47]  * wallyworld_ processes interrupt
[23:23] <ericsnow> FYI: reviewboard is happier now; rbt works again and I'm fixing the github integration part right now
[23:24] <ericsnow> sorry for the headaches
[23:47] <jcw4> thanks ericsnow :)


[00:00] <asac> thats one of th reasons why we currently think about how to best reorganize stuff
[00:01] <micahg> ok
[00:01] <asac> i want to stop the inflationary team creation... but also inflationary ppa creation
[00:01] <micahg> let me know if I can help
[00:01] <asac> thats why we need to carefully thinka bout the key services we want to provide outside the main archive
[00:01] <asac> and reduce them to a minimum
[00:11] <asac> i think my laptop battery just got a bad hit
[00:11] <asac> jumped down from 65% to 5% and then went off ;)
[00:11] <BUGabundo> ehehehe
[00:26] <WebcamWonder> fta: There?
[00:30] <WebcamWonder> fta: Just an FYI, if it didn't catch your eye, but the thunderbird daily builds are failing b/c of one of the patches no longer directly compatible with the source. And the version currently published is broken in the sense that it doesn't work at all (atleast for me)
[00:45]  * micahg was wondering why FF3.5 was so slow, it turned out my cpu was stuck at 500mHz
[07:38] <micahg> ping asac bug 365965
[07:39] <micahg> Here's the response I wrote: http://pastebin.ubuntu.com/210954/
[10:29] <asac> gnomefreak seems to be back ;)<
[11:14] <asac> gandi: hey
[11:14] <gandi> hi
[11:15] <asac> gandi: do you have some time today or tomorrow to explain to me how the trees in the l10-mozilla repo are structured?
[11:15] <gandi> asac: in a few hours, sure :)
[11:16] <asac> gandi: i tried to look at them to see what needs to be done to fix our export
[11:16] <asac> gandi: but the layour looks rather random to me ;)
[11:16] <asac> gandi: cool
[11:16] <asac> i will ping you this afternoon then ;)
[11:16] <fta2> mozilla 496683
[11:16] <asac> gandi: also, did you talk to the "ro" translators?
[11:16] <asac> gandi: (do you remember what this was about at all or should i send a mail?)
[11:17] <gandi> asac: I did ask them
[11:17] <gandi> but was out of time to have a full chat, I'll do this this week
[11:17] <fta2> asac, http://hg.mozilla.org/comm-central/rev/27b3a0d2aa23
[11:17] <asac> gandi: cool. no hurry.
[11:18] <asac> nice
[11:18] <asac> fta2: does that mean our testsuite works now?
[11:18] <fta2> eh? it's what makes tb3 ftbfs
[11:19] <fta2> it's too big of a change, i don't have time for this right now, feel free to have a look
[11:19] <asac> fta2: oh
[11:19] <asac> fta2: yes. thats on my list for ... _now_ ;)
[11:20] <fta2> several people already reported that ftbfs
[11:21] <gnomefreak> shhhh you dont see me, i can barely see you :)
[11:22] <asac> fta2: ok i updated the -daily PPA description telling them to contact our mailing list or this channel to report issues
[11:22] <asac> https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[11:22] <asac> gandi: hiiiiii
[11:22] <asac> oop
[11:22] <asac> gnomefreak: ^^
[11:22] <asac> ;)
[11:22] <asac> gnomefreak: good to h ave you back
[11:23] <asac> it was just yesterday that i wondered: "hell, didnt gnomefreak say that he will most likely be back in jul - hope all went well"
[11:23] <gnomefreak> :) im here for a bit with one eye closed and screen at some very very big res
[11:23] <gnomefreak> asac: july 27th is next eye
[11:23] <asac> gnomefreak: at least you can _see_ something. did the surgery go well in general?
[11:24] <gnomefreak> asac: yep as expected
[11:24] <gnomefreak> btw tbird-3 is borked
[11:24] <asac> fta2: right
[11:24] <gnomefreak> as is mozilla-devscripts
[11:24] <asac> gnomefreak: right
[11:24] <gnomefreak> ok good known
[11:24] <asac> fta2: so you bumped snapshot on branch already good.
[11:25] <asac> fta2: did you start on the patch?
[11:25] <asac> e.g. is there something i should start with
[11:25] <fta2> asac, no, I just had a look
[11:25] <asac> fta2: any hints, while the orig is downloading ;)?
[11:25] <asac> or just diverged patch for now?
[11:25] <fta2> it seems they are doing what we need now
[11:26] <fta2> maybe our patch is no longer needed
[11:26] <asac> ok i will check that
[11:26]  * gnomefreak smacks self
[11:26] <asac> does anyone else experience severe focus problems?
[11:26] <fta2> (btw, the bot has a feature to bump the changelog)
[11:26] <asac> fta2: you mean, on .head or on .daily?
[11:27]  * gnomefreak didnt put 2 and 2 together last night. m-d is lookijng in old place for upstream. sm moved since it is now synced with tbird
[11:27] <fta2> to update .head from the .daily
[11:27] <gnomefreak> asac: focus? not like i can tell, but what do you mean
[11:30] <asac> fta2: if thats what we want its easy enough to do manually (e.g. merge from .daily)
[11:30] <asac> i think its ok actually
[11:30] <asac> gnomefreak: well if i click somewhere its often not accepted
[11:30] <asac> also sometimes i switch apps and i cannot type until i re-switch apps
[11:31] <asac> etc.
[11:31] <asac> fta2: when does it merge back?
[11:31] <asac> when it fails?
[11:32] <gnomefreak> i havent seen that yet
[11:32] <fta2> asac, what i meant is the changelog bump in .head is not manual. I was tired to have to visit .daily, edit .head, commit and push, just to change a version and a date. So it's automatic now.
[11:33] <fta2> asac, there's no merge back from .daily to .head, .daily is not supposed to contain any change, expect changelog and the tweaked deps in control
[11:34] <gnomefreak> anyone on karmic have a working lower panel in gnome? running apps showing up?
[11:35] <gnomefreak> trash is there but no running apps
[11:35] <fta2> asac, btw, o3d doesn't work here (nvidia x64). the plugin is loaded, but it doesn't render anything (and no error in the console, beside the usual canberra-gtk-module)
[11:37] <asac> hmm
[11:38] <fta2> asac, http://paste.ubuntu.com/211182/ *sigh*
[11:38] <asac> fta2: btw, why dont we build -enable-static for tbird? do you remember the reason?
[11:38] <asac> yeah. looking at that
[11:38] <asac> too
[11:38] <asac> was the idea that we wanted to use the same build way xulrunner uses?
[11:38] <fta2> because we are not building ff statically either
[11:39] <asac> yeah
[11:39] <asac> thats what i thought
[11:39] <fta2> even before the split with xul
[11:39] <asac> but ffox is a xulapp
[11:39] <asac> right i remember
[11:40] <fta2> do as you wany ;)
[11:40] <fta2> want
[11:40] <asac> let me fire off a normal build now after fixing the patches to see where we stand ;)
[11:41] <asac> fta2: its a bit odd. there is no --enable-static/disable-static or --enable-shared, etc. in our rules
[11:43] <asac> hmm. gwibber disappeared again. seems it crashes quite regularly now
[11:45] <fta2> for me, it's better, no crash in a week
[11:45] <asac> hmm
[11:46] <fta2> but i dent less those days (i mean, even less than before), and it always crashed while i was writing
[12:07] <gnomefreak> what is the panel addon called that has the open windows in it? example: open terminal now on lower panel it shows a button for terminal
[12:08] <asac> gwibber seems again crashed
[12:09] <gnomefreak> mines working ok other than a problem with ident
[12:09] <gnomefreak> @firusvg i have given up on !firefox on linux .. my hopes lies with google chrome now
[12:11] <gnomefreak> yay clearing the window works now and not sure what the extra tab is for now
[12:16] <gnomefreak> asac: what version of gwibber?
[12:25] <asac> gnomefreak: latest karmic
[12:27] <gnomefreak> hmmm seems karmic has gotten the latest daily
[12:27] <gnomefreak> 1.2.0~bzr346-0ubuntu1
[12:27] <gnomefreak> it works here no problems other than errrors on indent.ca retrieving
[12:27] <asac> gnomefreak: yes. i uploaded that
[12:28] <asac> but now - a few days later i get more and more crashes ;)
[12:28] <gnomefreak> not sure why you are crashing unless it depends on mopnoi
[12:28] <gnomefreak> mono
[12:28] <gnomefreak> nope doesntr
[12:29] <gnomefreak> doesnt
[12:38] <gnomefreak> g/f thinks im crazy again. she over heard me asking the dog how to fix system
[12:42] <gnomefreak> asac: we should look into getting SM2 into Karmic however im waiting for everything to be finished with eyes and having glasses before i dive into it again. a few patch problems last i looked but it is on b3 (should be finished or atleast very close by release
[12:55] <asac> gnomefreak: sure. do you know whats the current status of sm2?
[12:55] <asac> is it at least at beta?
[12:55] <gnomefreak> asac: b3
[12:56] <gnomefreak> as for state its in eh not sure since i havent fixed the FTBFS in ~a month
[12:56] <gnomefreak> one of our patches was conflickting
[12:58] <asac> ok ;)
[12:58] <gnomefreak> asac: one minute ill get you last failure
[12:58] <asac> currently working on getting tbird 3 fixed
[12:58] <asac> so based on that i might be easy to also fix sm
[12:58] <asac> 2
[12:58] <gnomefreak> last known failure for SM2 http://launchpadlibrarian.net/27243867/buildlog_ubuntu-karmic-i386.seamonkey-2.0_2.0~b1~hg20090528r2718%2Bnobinonly-0ubuntu1.9.10_FAILEDTOBUILD.txt.gz
[12:59] <gnomefreak> tbird bug here is that no boxes are showing up not sure if that is what you are working on or not
[12:59] <asac> ok thanks
[12:59] <gnomefreak> np
[13:00] <asac> gnomefreak: that problem is a minimal nspr/nss version requirement
[13:00] <gnomefreak> asac: have you started on the OO.o patch for mozilla?
[13:00] <asac> e.g. you need to bump the minimal version for using --system-nspr/nss
[13:00] <gnomefreak> asac: than maybe i fixed that in my branch
[13:01] <gnomefreak> i have done that once already IIRC
[13:01]  * gnomefreak checks branch
[13:01] <gnomefreak> https://code.edge.launchpad.net/~gnomefreak/seamonkey/ubuntu-2.x-9.10
[13:02] <gnomefreak> yep needed another bump damnit
[13:02] <asac> gnomefreak: you need nspr dump i guess
[13:03] <asac> >= 4.7.5
[13:03] <gnomefreak> ill update it while your on tbird
[13:03] <gnomefreak> lets see what else is wrong if anything
[13:03] <asac> USE_SYSTEM_NSPR := $(shell pkg-config --exists 'nspr >= 4.7'; a=$$?; if test $$a != 1; then echo 1; fi)
[13:03] <asac> make that 4.7.5
[13:03] <asac> gnomefreak: or even 4.8 now on latest trunk i think
[13:03] <asac> (which we dont even have packaged yet)
[13:04] <asac> nss should be ok now
[13:04] <asac> gnomefreak: try 4.7.5... but if it still fails on current karmic you need 4.8 there
[13:04] <gnomefreak> k
[13:05] <gnomefreak> we should really use the version that is on system instead of naming version
[13:06] <asac> gnomefreak: no ... the version in rules is important
[13:06] <asac> without that you cannot do builds on systems that dont have high enough version
[13:06] <asac> so no backports etc.
[13:06] <asac> just adjust it properly and all is fine and the package does the right thing
[13:06] <gnomefreak> we dont backport most of our apps anyway
[13:06] <asac> e.g. it uses system lib if its good enough
[13:06] <gnomefreak> will do
[13:06] <asac> gnomefreak: we backport everything
[13:06] <asac> e.g. -daily ppa
[13:07] <gnomefreak> ah thats right
[13:07] <asac> has builds from hardy to karmic
[13:07] <asac> based on the same branch
[13:07] <asac> so its important that our packages just build everywhere
[13:07] <gnomefreak> well i just closed a bug on backporting 3.5 for hardy. that is bad idea in system outside of PPA's IMHO
[13:10] <gnomefreak> grrrrr org.freedesktop.devicekit.disks.filesystem-mount-system-internal no
[13:10] <gnomefreak> udev-extras?
[13:11] <gnomefreak> devicekit makes me think that
[13:12] <gnomefreak> although by the sounds of it udev-extras was replaced by udev :(
[13:32] <asac> gnomefreak: right. udev-extras is now gone again (at least libgudev moved to udev)
[13:39] <gnomefreak> well its not mounting usb drives nor ejecting cd/dvds
[13:42] <AnAnt> Hello, isn't firefox-3.5 now final ?
[13:43] <gnomefreak> if m-d uses hg clone http://hg.mozilla.org/comm-central/ mozilla why the hell would SM1 not work
[13:43] <AnAnt> why is Shiretoko codename still being used ?
[13:44] <gnomefreak> looks to be final. are you sure you are not using 3.5.1
[13:44] <gnomefreak> its in umd repo
[13:45] <AnAnt> firefox-3.5 (3.5+nobinonly-0ubuntu<IP_ADDRESS>)
[13:45] <AnAnt> that one still uses Shiretoko
[13:45] <asac> AnAnt: thats ok
[13:46] <asac> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-firefox-3.5
[13:46] <gnomefreak>  i dont have 3.5 installed only .1
[13:46] <asac> in short: we only ship the default browser officially branded
[13:46] <asac> jaunty default is ffox 3.0
[13:46] <AnAnt> ok
[13:46] <asac> karmic is still 3.0, but that will change as soon as the spec above gets implemened
[13:47]  * gnomefreak gone for a month and i miss all kinds of stuff
[13:48] <AnAnt> thanks
[13:49] <asac> AnAnt: i hope i find time to announce how things go on my blog soon
[13:51]  * asac scared: asac@hector:~/ubuntu_bzr/thunderbird-3.0.head$ bzr st
[13:51] <asac> Segmentation fault
[13:55] <gnomefreak> either these changes are massive or m-d doesnt like me anymore
[13:55] <gnomefreak> same place > 1 hour
[13:56] <asac> tbird 3 fixed in branch
[13:56] <asac> fta2: can you kick off a ubuntu2 for yesterdays daily?
[13:56] <asac> tbird 3
[13:57] <asac> just in case they break something new :) ... so we get at least a good build today
[13:57] <gnomefreak> that bug has happened a few times in tbird3 cycle
[13:58] <asac> builders are idle ... so good time to kick this
[13:58] <gnomefreak> at least the one i saw
[13:58] <asac> gnomefreak: thats ok. its a normal to break stuff if new files dont get installed et al
[13:58] <asac> but now we have static build which should be a bit better
[13:58] <gnomefreak> ah it was all due to shared?
[14:00] <gnomefreak> i faintly remember shared/static builds topic with upstream
[14:00] <fta2> asac, done
[14:00] <asac> thx a bunch
[14:03] <gnomefreak> ok something is wrong here :( i dont want 2.1
[14:03] <gnomefreak> i want 2.0b3
[14:03] <gnomefreak> seamonkey-2.0-2.1~a1~hg20090706r3013+nobinonly
[14:04] <gnomefreak> anyone can tell me why m-d grabbed 2.1 instead of recent 2.0
[14:06] <gnomefreak> i dont mind working on 2.1 but would like to fix 2.0 first
[14:10] <gnomefreak> ok so m-d grabs latest testing build for 2.0 fails to grab 1.1.17 and onkly grabs stable calendar
[14:11]  * gnomefreak needs to rest my head
[14:11] <gnomefreak> letting 1.1.x go for a while to see if maybe its not dying
[14:15] <asac> gnomefreak: i think that 2.0 probably moved to its own brtanch
[14:15] <asac> so your md rules pull in 2.1 now
[14:16] <gnomefreak> they should move the newest one to a new branch and leave old ones where they are. makes sense even outside of m-d
[14:17] <gnomefreak> ok 1.1.17 seems to be working at least its connected and pulling in latest
[14:18]  * gnomefreak smoke while i think about how to tackel that or even if i have time before doctors appt.
[14:26] <gnomefreak> ok today im wokring on 1.1.17 if it id done when i get home than i might start on 2.0 d rework
[14:26] <gnomefreak> md even
[14:30] <gnomefreak> mozilla 495057
[14:31] <gnomefreak> asac: any idea why i am denied
[14:31] <gnomefreak> theres no CVE number for this fix for some reason
[14:42] <gnomefreak> ok gone for a while started SM1 build
[14:50] <asac> gnomefreak: the bug is security sensitivbe
[14:51] <asac> no need to check it
[14:51] <asac> what info are you looking for
[14:51] <asac> ?
[14:54] <gnomefreak> i was hoping for a CVE but i used the MFSA 2009-33
[14:56] <gnomefreak> ok its building,, i need to get ready for dr appt. ill see you in a few hours
[14:58] <asac> yeah one MFSA didnt have a CVE
[14:58] <asac> checkout what i documented in icedove upload to debian
[14:58] <asac> i think i left out the CVE for -33
[15:37] <asac>  75 Ns  Jul 06 Martin Pitt               (2.8K) Next karmic gdm upgrade WILL BREAK your system
[15:37] <asac> fta2: gnomefreak: ^^
[15:39] <eagles0513875> asac: seems like a regression in the plasma-widget-network-manager cuz wicd connected just fine for me
[15:40] <asac> eagles0513875: didnt i say that yesterday?
[15:40] <asac> kick plasma .... long live nm-applet
[15:40] <eagles0513875> asac: you wanted me to try and determine if it was a regression or not
[15:41] <eagles0513875> im not even using the nm-applet cuz in hardy that wouldnt even work for me
[15:41] <eagles0513875> im using wicd
[15:41] <asac> eagles0513875: i wanted you to check nm-applet not wicd
[15:41] <eagles0513875> ahhh if you would like ill do that now
[15:41] <asac> or what did i say?
[15:41] <asac> great
[15:41] <asac> we want to know if its plasmas fault alone
[15:41] <asac> i would htink yes
[15:41] <eagles0513875> yes
[15:42] <eagles0513875> and it is a regression cuz an older svn version that is in jaunty works just fine
[15:42] <asac> yeah that would be the case then
[15:42] <asac> eagles0513875: after verifying that nm-applet works fine you could check whether there is newer stuff in svn
[15:42] <eagles0513875> ya but we know that since its working with wicd that the wifi card or kernel arent to blame
[15:42] <asac> also you could try to downgrade to jaunty widget version and see if that helps
[15:43] <asac> eagles0513875: no. testing with wicd is useless
[15:43] <asac> even if wicd works it doesnt mean that kernel isnt broken
[15:43] <eagles0513875> ok whats the exact name of the nm-applet package
[15:43] <asac> wicd uses only the most basic features of the wifi kernel stack
[15:43] <asac> so you cannot compare that
[15:43] <asac> eagles0513875: network-manager-gnome
[15:44] <eagles0513875> whats the difference between network-manager-gnome and just plain old network-manager
[15:44] <asac> eagles0513875: network-manager is the daemon (the actualy manager)
[15:44] <eagles0513875> gotcha
[15:44] <asac> network-manager-gnome is the applet you can use to manage it
[15:44] <asac> similar to what plasma should do if it gets ever finished
[15:44] <asac> but i think that kde will move to lava- before they finish anything ;)
[15:48] <asac> just kidding ;)
[15:48] <asac> its just that kde folks always start new things without fixing the old stuff ;)
[15:48] <asac> but i think thats the case everywhere
[15:53] <eagles0513875> lol asac you cant make it any more obvious your a gnome user lol
[15:54] <asac> i am pretty open minded
[15:54] <asac> but i am suffering quite a lot seeing that knetworkmanager and frieds are always lacking behind
[15:55] <asac> and nobody from the kubuntu team really taking a lead on that ;)
[15:55] <eagles0513875> certain aspects of kde i love
[15:55] <eagles0513875> if i knew programming really well i would
[15:55] <eagles0513875> but im a novice programmer
[15:55] <asac> i dont care about kde and gnome much ;)
[15:55] <asac> just about NM
[15:55] <asac> and FFocx
[15:55] <asac> and other things of course ;)
[15:55] <eagles0513875> let me try the gnoem nm
[15:56] <asac> problem is that i begged so much in the past on kubuntu state of network managing and often got back "we dont really care" ;)
[15:56] <asac> same for ffox integration in kde
[15:56] <asac> i wanted to drive that, but answer i got when asking for info/help was "we dont care much because we have konqueror" ... which imo is dishonest to all users that use ffox
[15:56] <asac> eagles0513875: yeah. ensure that plasma widget is killed
[15:56] <asac> then start nm-applet
[15:57] <asac> from the command line
[15:57] <eagles0513875> i rebooted
[15:57] <eagles0513875> and wicd removed it
[15:57] <eagles0513875> but there is no lil widget or applet for the nm
[15:57] <asac> well yeah. you need to get rid of wicd if you want to use NM anyway
[15:57] <eagles0513875> from what i saw it removed it
[15:57] <asac> well. wicd also removes network-manager
[15:57] <asac> so you dont have network-manger at all now
[15:58] <asac> kick wicd. install network-manager and network-manager-gnome ;)
[15:58] <eagles0513875> i installed network-manager-gnome and as it was installing it it remove wicd
[15:58] <asac> yeah
[15:58] <eagles0513875> i have network-manager-gnome installed according to apt-cache policy
[15:58] <asac> so you need to start nm-applet manually
[15:58] <asac> kde folks forced me to not start applet on log-in if you are on kde
[15:58] <asac> ;)
[15:58] <asac> dont ask me why
[15:58] <eagles0513875> thats strange
[15:58] <asac> i would think that users that install nm-applet want to have it running
[15:59] <eagles0513875> hehe so what do i type in network-manager-gnome
[15:59] <eagles0513875> exactly
[15:59]  * asac considers to change that back and conflict with plasma-widget-network-manager
[15:59] <asac> eagles0513875: nm-applet
[15:59] <asac> thats what you type
[15:59] <eagles0513875> sry for all these questions im so used to the widget working and not having to touch anything
[15:59] <eagles0513875> #well here is a bug
[15:59] <eagles0513875> if i start it from the command line the ctrl+c the applet disappears
[16:00] <eagles0513875> ive seen some programs where i ctrl+c and it stays there
[16:00] <asac> thats ok
[16:00] <asac> ctrl+c is should kill processes
[16:00] <asac> if process prevent that they must have a good reason
[16:00] <eagles0513875> should i background it
[16:01] <asac> eagles0513875: if you want to keep it running you could probably also start it using alt+f2
[16:01] <eagles0513875> coudl as well
[16:01] <asac> e.g. whatever kde facility allows you to start commands
[16:01] <eagles0513875> couldnt i use nm-applet & to bg it
[16:01] <asac> eagles0513875: but for testing you can just keep the terminal open and keep it running there?
[16:01] <asac> try it
[16:01] <eagles0513875> i am
[16:01] <asac> if its working fine. if its not, its not something we care about i guess ;)
[16:02] <asac> usually it gets started on login
[16:02] <eagles0513875> it seems to want me to setup a keyring which i dont want to
[16:02] <asac> only if you want to debug stuff its started from terminal
[16:02] <asac> eagles0513875: you need to in order to test it
[16:02] <asac> you can delete the keyring later
[16:02] <eagles0513875> it shouldnt be required though
[16:02] <asac> eagles0513875: questionable. its a gnome app
[16:02] <asac> you can create a system connection and set the passphrase there
[16:03] <asac> then it wont use the keyring
[16:03] <asac> not sure if NM allows you to get that far though
[16:03] <eagles0513875> it was asking me to create a new keyring
[16:03] <eagles0513875> it connects
[16:04] <asac> good
[16:04] <asac> maybe NM should default to making connections "system connections"
[16:05] <asac> i will think about it and talk to nm developers
[16:05] <asac> imo it would be great if we could make a less-gnome dependent app out of it
[16:05] <asac> though kde folks probably wouldnt want it because its gtk ;)
[16:06] <eagles0513875> i honestly dont care
[16:07] <eagles0513875> kde 4.3 is nice and improving on performance but im impressed how zippy gnome is
[16:08] <asac> yeah. i promissed to try kde ... but it didnt work because compiz/composition still doesnt work here on my GPU
[16:09] <asac> jdstrand: there?
[16:09] <asac> jdstrand: so the -proposed bits are verified and now we wonder whether you wanted us to first copy that to -updates
[16:10] <asac> or directly to -security and from there to -updates
[16:10] <jdstrand> asac: I'll go to security
[16:10] <asac> jdstrand: see -devel
[16:10] <asac> jdstrand: pitti wants to know if you or he will do the roll out ;)
[16:10] <jdstrand> yeah, see -devel
[16:10] <asac> ack
[16:12] <eagles0513875> asac: intel gpu
[16:14] <asac> yeah intel is probably working
[16:14] <eagles0513875> been lucky with nvidia
[16:14] <asac> but my intel system has only a tiny disk ;)
[16:14] <eagles0513875> but that is a nasty bug i must say
[16:14] <asac> i have ati
[16:15] <eagles0513875> hehe why not install kubuntu onto a pen drive
[16:15] <asac> actually one of the chips that i always get told that they work perfect
[16:15] <eagles0513875> and use that as a persistent portable install
[16:15] <asac> until i show them that compositing is still borken ;)
[16:15] <eagles0513875> ati is a nightmare graphics wise
[16:15] <eagles0513875> nvidia ftw
[16:15] <asac> well. ati is not that bad actually
[16:15] <asac> the free driver is improving and rocks on lots of chips nowadays
[16:15] <asac> but not on mine :(
[16:15] <asac> probably because it was a high-tech gamers card once ;)
[16:16] <eagles0513875> man talking about gaming cards lol
[16:16] <eagles0513875> if you want i wont even go there
[16:25] <eagles0513875> asac: ty for your help man
[16:28] <asac> eagles0513875: so you can live with the solution for now? can youplease file a bug against plasma-widget-network-manager so i can make it important and put it on release teams radar?
[16:28] <eagles0513875> file it just on launchpad
[16:28] <eagles0513875> or can you link me to the wpa bug that there was for jaunty
[16:29] <asac> eagles0513875: its a regression in karmic, right?
[16:29] <asac> eagles0513875: we should have a new bug then.
[16:29] <eagles0513875> ya but there was a similar issue that was in jaunty where one couldnt connect to wpa encrypted wifi
[16:34] <asac> yes. most likely
[16:34] <asac> but open a new bug for the karmic problem unless you really thinkits the same still
[16:39] <eagles0513875> i cant find the jaunty one so will open a new bug
[16:43] <micahg> ping asac
[16:44] <eagles0513875> asac: https://bugs.launchpad.net/ubuntu/+source/plasma-widget-network-manager/+bug/396180
[16:46] <asac> micahg: yep?
[16:46] <eagles0513875> hope that bug helps some if any
[16:47] <eagles0513875> asac: is that bug good enough for ya or you need more info
[16:47] <asac> eagles0513875: can you attach the file i asked for (directly after reproducing)
[16:48] <asac> i just aksed
[16:48] <eagles0513875> it never showed up for me over here
[16:48] <micahg> asac: is this response ok: http://pastebin.ubuntu.com/210954/ for bug 365965
[16:48] <micahg> last comment
[16:48] <asac> let me check
[16:48] <asac> didnt i comment on that bug already?`
[16:49] <micahg> wb gnomefreak
[16:49] <asac> micahg: i think its a dejavu bug
[16:50] <asac> the apturl is the problem
[16:50] <asac> but i feel reluctant to remove a recommends
[16:50] <asac> its recommended for ubuntu to have that
[16:50] <micahg> yes, I'm not worried about that part right now
[16:50] <eagles0513875> asac: apologies if you did as im jumping back and forth between a bunch of stuff and soon have to leave
[16:50] <micahg> about the guy's last comment about gtk
[16:50] <micahg> you can deal with eagles0513875 first
[16:50] <asac> eagles0513875: huh? its in the bug isnt it?
[16:50] <micahg> I can check with you later
[16:50] <eagles0513875> ya apologies
[16:51] <eagles0513875> micahg: he can help ya
[16:51] <eagles0513875> asac: will dmesg help with anything cuz thats where we see some light on the issue
[16:52] <asac> micahg: commented. he is talking bullshit ;)
[16:52] <micahg> oh, I was wondering if my proposed response was correct
[16:52] <asac> eagles0513875: usually not. you can also attach it after reproducing in case this goes to the kernel,  but usually syslog is all we need and also has kernel messages in there
[16:53] <eagles0513875> alright
[16:53] <asac> eagles0513875: you might want to attach eventuall error message the plasma widget spits out
[16:53] <micahg> ah, basically you're gonna show him it has GTK in it :)
[16:53] <asac> not sure where they go
[16:53] <eagles0513875> ill attach both
[16:53] <eagles0513875> cuz the 2 messages have a code and im not sure what they mean
[16:53] <asac> eagles0513875: maybe you can kill plasma widget and start it from ccommand line to see what it outputs? otherwise its probably in .xsession-errors, but not sure how kde does things special
[16:53] <asac> k
[16:54] <asac> micahg: yes
[16:54] <eagles0513875> ill post syslog as well as dmesg
[16:54] <asac> micahg: its even easier: ldd /path/to/firefox-bin
[16:54] <asac> will show gtk i am sure
[16:54] <asac> or is it libxul.so?
[16:54] <asac> i guess
[16:55] <asac> so if oyu ahve aa upstream build at hand try to run ldd on both files
[16:56] <eagles0513875> also if you would like then once we have necessary info ill file it upstream for ya
[16:56] <asac> micahg: ^^
[16:56] <asac> eagles0513875: thats even better.
[16:56]  * eagles0513875 zips lips
[16:56] <eagles0513875> dont mean to interrupt you 2
[16:56] <asac> eagles0513875: i wanted to put some kubuntu guy onto guiding the bug, but its best if you can directly talk to upstreams i guess
[16:56] <asac> eagles0513875: thats ok
[16:56] <asac> i usually dont reply if i dont have time or want to finish a separate discussion ;)
[16:56] <eagles0513875> asac: :) i would love to contact the upstream dev directly
[16:57] <micahg> asac: I don't run upstream builds
[17:00] <asac> eagles0513875: first find the svn and see if there are more commits already
[17:00] <asac> maybe its fixed
[17:00] <eagles0513875> k
[17:00] <asac> if its not fixed in latest commit we can file the bug at kde.org
[17:02] <asac> its annoying
[17:02] <asac> i cannot even find the svn for plasma network manager
[17:02] <asac> what a mess
[17:03] <asac> "network manager plasma svn" google
[17:03] <asac> nothing
[17:04] <asac> my incompetency to not find something on the web is one of the few things that really drives me mad ;)
[17:04] <eagles0513875> lol
[17:37] <gnomefreak> ok im eating but it buiolt fine i am going to make a few adjustments push commit and respin for PPA
[17:38] <asac> great
[17:38] <asac> what was it?
[18:00] <gnomefreak> asac: do you have icedove changelog handy?
[18:01] <asac> gnomefreak: now ... its in the branch
[18:01] <asac> gnomefreak: or on packages.qa.debian.org
[18:01] <gnomefreak> asac: nothing was wrong i just need to adjust changelog a little (versioning and such
[18:02] <asac> http://bazaar.launchpad.net/~mozillateam/thunderbird/icedove-2.0.0.x/annotate/head%3A/debian/changelog
[18:02] <asac> gnomefreak: but seamonkey is usually ffox + tbird
[18:02] <asac> as it ships browser and mail
[18:02] <gnomefreak> just that one bug fix the .33
[18:02] <gnomefreak> oh you used the mfsa
[18:02] <gnomefreak> all of them
[18:04] <asac> yeah
[18:05] <gnomefreak> pushing to branch atm
[18:06] <asac> good
[18:06] <asac> is that for karmic?
[18:06] <gnomefreak> yes
[18:07] <gnomefreak> https://code.edge.launchpad.net/~gnomefreak/seamonkey/seamonkey-1.1.x.karmic
[18:07] <gnomefreak> shit
[18:07] <gnomefreak> oh well leave it i guess
[18:09] <asac> so not yet ready?
[18:09] <gnomefreak> asac: do you want me to update the other branches?
[18:09] <gnomefreak> asac: its ready
[18:09] <asac> gnomefreak: are you sure those are all CVEs?
[18:10] <gnomefreak> i forgot to pull the MFSA entry but its done so all i care it can stay
[18:10] <asac> please check security/announce
[18:10] <gnomefreak> asac: i used each link to get CVE
[18:10] <asac> http://www.mozilla.org/security/known-vulnerabilities/seamonkey11.html
[18:10] <asac> gnomefreak: you also need the .16 advisories i think
[18:11] <asac> e.g. previous upload was .15
[18:11] <gnomefreak> asac: you said you added them to 15 instead of pushing a .16
[18:11] <asac> hmm
[18:11] <asac> did i?
[18:11] <gnomefreak> yes
[18:13] <gnomefreak> that is why we didnt release a .16
[18:13] <asac> hmm
[18:13] <asac> seems the changes are on .hardy + .intrepid branch but not on dev
[18:13] <asac> gnomefreak: shit ... i didnt push it ;)
[18:13] <asac> gnomefreak: so restart from .dev again ;)
[18:14] <gnomefreak> why didnt we release a .16 for dev than?
[18:14] <asac> you need to backout the patches i prepatched
[18:14] <asac> gnomefreak: you were correct. i just forgot to push the bzr branch as it seems
[18:14] <asac> so you started on a branch that wasnt up-to-date
[18:14] <asac> gnomefreak: can you start with a new .dev and then add your changelog on top and also drop the two patches i landed in ubuntu2 ?
[18:14] <gnomefreak> ok what is the dev branch link
[18:15] <asac> lp:~mozillateam/seamonkey/seamonkey-1.1.dev
[18:15]  * asac bound the branch so he doesnt forget to commit in future
[18:15] <asac> s/commit/push/
[18:16] <asac> sorry for that mess ;)
[18:16] <asac> guess its not a good present for you coming back ;)
[18:16] <asac> but well. you changed did the changelog, so now you have something more challenging ...e .g. also drop patches
[18:16] <gnomefreak> eh its all good. i should have it ready shortly
[18:16] <asac> consider that a present ;)
[18:17] <gnomefreak> :)
[18:19] <gnomefreak> asac: what is the 3rd patch 90_181_485286_attachment_369457.patch i dont see it in changelog
[18:20] <asac> gnomefreak: third?
[18:20] <gnomefreak> yes
[18:21] <asac>   * CVE-2009-1169: XSL Transformation vulnerability
[18:21] <asac>     - add 90_181_485217_attachment_369357.patch
[18:21] <asac>     - add debian/patches/90_181_485286_attachment_369457.patch
[18:21] <gnomefreak> 90_181_485286_attachment_369457.patch
[18:21] <asac> look ;)
[18:21] <asac> (sorry)
[18:21] <gnomefreak> i know the 2 to remove this is a idfferetn one
[18:22] <asac> 90_181_485286_attachment_369457.patch == add debian/patches/90_181_485286_attachment_369457.patch
[18:22] <asac> or am i wrong?
[18:22] <asac> it belongs to the same CVE
[18:22] <asac> so should be dropped too
[18:23] <gnomefreak> oh ok
[18:31] <gnomefreak> ok pushing changes
[18:33] <gnomefreak> asac: https://code.edge.launchpad.net/~gnomefreak/seamonkey/seamonkey-1.1.x.dev should be loaded soon
[18:33] <gnomefreak> ok so jaunty build needs same work?
[18:33] <gnomefreak> just intrepid/hardy are without the patches
[18:34] <gnomefreak> asac: ok its loaded
[18:37] <asac> k
[18:37] <asac> i will leave soon ... will maybe check later tonight or tomorrow
[18:37] <gnomefreak> k
[18:37] <asac> and upload to karmic etc.
[18:39]  * gnomefreak not here long either
[18:41] <gnomefreak> lol @ next gdm will break system. mines already frigging broke
[18:42] <gnomefreak> what could happen to it now
[20:12] <stefanlsd> Do things built for FF 3.5 need to be built against xulrunner-1.9.1-dev ?
[22:07] <jetsaredim> anyone know anything about gpg + tb3?
[22:09] <asac> hi
[22:10] <jetsaredim> ohai
[22:10] <asac> jetsaredim: needs to be done ;)
[22:10] <asac> needs an owner maybe ;)
[22:10] <jetsaredim> well
[22:10] <asac> its definitly challenging stuff
[22:10] <jetsaredim> it looks like there is built-in support for pkcs12
[22:10] <jetsaredim> which is just another key thingie
[22:11] <asac> in tbird?
[22:11] <asac> yes
[22:11] <jetsaredim> yea
[22:11] <asac> thats that x.501?
[22:11] <asac> or 9?
[22:11] <asac> not sure
[22:11] <jetsaredim> so just need to be able to convert gpg key to pkcs12
[22:11] <asac> thats what they support
[22:11] <jetsaredim> i think
[22:11] <jetsaredim> or are you talking about enigmail?
[22:11] <asac> jetsaredim: i am talking about enigmail
[22:11] <asac> gpg support wont work without it
[22:12] <jetsaredim> i don't even think that the basic extension supports tb2
[22:12] <jetsaredim> err tb3
[22:12] <asac> well i am talking about tbird supporting S-MIME?
[22:12] <asac> jetsaredim: it has tbird 3 support
[22:12] <jetsaredim> orly?
[22:12] <asac> just needs to be packaged
[22:12] <jetsaredim> hmm rly
[22:13] <asac> nightly is available for tbird 3 so yes
[22:13] <asac> http://enigmail.mozdev.org/download/index.php
[22:14] <asac> i already started on making enigmail use the xulrunner build system
[22:14] <asac> but i ended up lacking headers
[22:14] <asac> for mime stuff etc.
[22:14] <jetsaredim> hmm
[22:14] <asac> so those probably need to be exported in a tbird-dev package
[22:14] <jetsaredim> yae
[22:14] <jetsaredim> hrm
[22:14] <asac> like we did for tbird 2
[22:14] <asac> but upstream situation didnt get much better
[22:15] <asac> e.g. make install doesnt install headers i think
[22:15] <asac> at least i think
[22:15] <asac> but i should check
[22:15]  * asac kicks off a tbird package build
[22:15] <jetsaredim> i don't think it would
[22:15] <asac> need to check ;)
[22:15] <jetsaredim> yea
[22:15] <asac> takes about 20-30 minutes
[22:15] <jetsaredim> yea
[22:16] <jetsaredim> no worries - have to run anyway
[22:16] <asac> too bad i cleaned my build area a few hours ago
[22:16] <jetsaredim> kids need to eat, etc. :)
[22:16] <asac> had a proper build there just before
[22:16] <asac> jetsaredim: good. cu around ;)
[22:16] <jetsaredim> figures ;)
[22:16] <asac> kids are obviously more important than enigmail ;)
[22:16] <jetsaredim> i need to make some time later this week to update some moz extensions too
[22:16] <jetsaredim> i've been a bastard about that - work is crazy
[22:17] <asac> our dailies still occupy ppa builders ;)
[22:17] <jetsaredim> but boss is going on vacation wed :)
[22:17] <asac> jetsaredim: i think what would be really helpful would be to help getting a stat about what extensions need to be updated for ffox 3.0
[22:17] <asac> err ffox 3.5
[22:17] <jetsaredim> yea
[22:17] <jetsaredim> well - i think mozgest for one needs to be dumped
[22:17] <asac> like a table with columns: latest upstream version | ffox 3.5 support upstream | ffox 3.5 support in archive
[22:18] <jetsaredim> in favor of firegestures
[22:18] <jetsaredim> yes - that would be helpful :)
[22:18] <asac> ok lets talk about that later ;)
[22:18] <asac> go and do your kids and food ;)
[22:18] <jetsaredim> indeed
[22:18] <jetsaredim> i'll be back around 11P est
[22:18] <jetsaredim> no rest for the weary
[22:19] <jetsaredim> ttyl
[22:58] <asac> stupid me ... cleaned build area again while tbird was still running
[22:58]  * asac hits his brain ;)
[22:58] <fta> asac, what do you think of http://code.google.com/p/chromium/issues/detail?id=13416 ?
[23:05] <asac> fta: mozillas point is that the html5 standard was created to improve the open web
[23:05] <asac> thats why they dont support patent encumbered codecs at all
[23:05] <asac> so more codecs are wrong
[23:05] <asac> otherwise i dont know what to say.
[23:05] <asac> doesnt it work with our ffmpeg libs?
[23:05] <fta> i emphasized *open*
[23:05] <asac> they are stripped a bit, but in general we should have them
[23:06] <asac> yeah but the common makes the impression that this is a cross platform problem
[23:06] <fta> no, ours is from the main branch, ie it's not multi-threaded
[23:06] <asac> which it isnt at all
[23:07] <asac> yeah. then the answer is probably that they either can make use of the not-multithreaded lib
[23:07] <asac> or they include more code in their trunk ;)
[23:07] <asac> i dont see why they wouldnt copy the whole ffmpeg into their tree and link statically to it ;)
[23:07] <micahg> asac: just upgraded to FF3.5 from universe
[23:07] <fta> the libs are loaded on demand
[23:07] <asac> nice ;)
[23:07] <asac> fta: the libs or the codecs?
[23:08] <asac> codecs are often also .so
[23:08] <fta> asac, /usr/lib/chromium-browser/*.so.*
[23:08] <asac> fta: i dont see why they couldnt do that when shipping their .so things in pkglibdir
[23:08] <asac> they must rename the libs anyway if they are a fork
[23:08] <fta> it's not even part of the build, i had to add that
[23:09] <asac> yeah. thats what they should fix. otherwise even their build wont work i guess
[23:09] <asac> or does chrome build work?
[23:09] <fta> no idea, but the 1st message seems to indicate that it doesn't
[23:14] <fta> asac, could you run glxinfo 32 and 64 on your X1900 as tell me if there's a difference?
[23:15] <fta> more precisely, do you have the ARB_vertex_buffer_object and EXT_framebuffer_object extensions?
[23:17] <asac> fta: glxinfo 32?
[23:17] <fta> 32 bit version of glxinfo
[23:17] <asac> is that in ia32-libs?
[23:17] <fta> i don't think so
[23:18] <asac> can i just unpack the package or do i also need more depends?
[23:19] <BUGabundo> guud evening
[23:19] <BUGabundo> hey asac fta
[23:19] <asac> ola
[23:19] <fta> good question, let me know :)
[23:19] <BUGabundo> read john email?
[23:19] <asac> fta: why do you ask me to do such hard things :(
[23:20]  * asac gets mesa-utils 32
[23:20] <asac> so last package with that source is feisty ;)
[23:20] <BUGabundo> asac: didu see gnomefreak request?
[23:20] <asac> ok source is mesa
[23:20] <asac> request?
[23:21] <BUGabundo> asac: to package tb ?
[23:22] <asac> fta: diff -u /tmp/glx32.txt /tmp/glx64.txt | pastebinit
[23:22] <asac> http://paste.ubuntu.com/211567/
[23:22] <asac> BUGabundo: to package tb?
[23:22] <asac> thought we had a package ;)
[23:22] <BUGabundo> err
[23:22] <BUGabundo> asac: please see the email :\
[23:23] <fta> asac, lol, is this box usable at all?
[23:23] <asac> fta: in which sense?
[23:23] <fta> asac, you're soft rendering everything
[23:24] <asac> fta: look at the diff command
[23:24] <asac> 64 bit has direct rendering
[23:24] <asac> -direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
[23:24] <asac> +direct rendering: Yes
[23:24] <asac> the diff is 32 vs. 64
[23:24] <asac> uname -a
[23:24] <asac> Linux hector 2.6.30-10-generic #12-Ubuntu SMP Mon Jun 22 16:30:32 UTC 2009 x86_64 GNU/Linux
[23:25] <asac> so yeah. on .31 its currently unusable ;)
[23:25] <asac> (though i havent tried -2 yet)
[23:25] <BUGabundo> Can you please as Alexander to update
[23:25] <BUGabundo> Seamonkey 1.1.15-1.1.17. I havent made any update to it
[23:25] <BUGabundo> since it hit repos.
[23:25] <fta> so problem with .31 here
[23:25] <asac> BUGabundo: yeah. i think he wants me to review his branch and sponsor the upload
[23:25] <asac> i have that on my list
[23:25] <asac> latest tomorrow morning
[23:26] <asac> fta: huh? s/so/same/?
[23:26] <asac> or are you saying the o3d problems are .30?
[23:26] <fta> s/so/no/
[23:26] <BUGabundo> thanks asac
[23:26] <asac> ah
[23:26] <asac> fta: using fglrx?
[23:26] <fta> no, nvidia and intel
[23:27] <BUGabundo> fta no 3.5 daily ?
[23:27] <asac> builders are burried in work ;)
[23:27] <fta> BUGabundo, I thought you didn't want those?
[23:28] <BUGabundo> eheh I don't!
[23:28] <BUGabundo> just found t strange :)
[23:28] <asac> fta: so stopped 3.5 dailies?
[23:28] <fta> no
[23:28] <asac> or just no commmits?
[23:28] <fta> no commit i guess
[23:29] <asac> good ;)
[23:29] <BUGabundo> right asac. I remember reading it
[23:29] <asac> at least no useless buildd digestions ;)
[23:31] <fta> asac, even on 64bit, you seems to have Slow/None
[23:32] <asac> i have basic 3d thats it
[23:32] <asac> most likely the reason why there is still no compiz for me
[23:32] <asac> even though 5xx are in general ment to work with ati ;)
[23:33] <asac> but i gave up as i couldnt play doom 4 et al since hardy anyway
[23:33] <asac> (before it always worked great with fglrx)
[23:33] <fta> i had a regression like that on my netbook, it was udev-extras missing
[23:33] <fta> bug 384934
[23:34] <asac> hmm. i doubt thats the case for ati
[23:34] <asac> what does udev-extras do for you?
[23:34] <fta> it was missing permissions to access the dri
[23:34] <fta> rules were in udev-extras, not installed in UNR
[23:35] <asac> yeah
[23:35] <asac> but thats ok for me
[23:35] <asac> we already checked that
[23:35] <asac> i also tried to make the permissions bad
[23:35] <asac> and it really got much worse
[23:35] <asac> i think what i have is really the best i can get now
[23:35] <fta> and i can play openarena on my slow netbook
[23:35] <asac> maybe .31 will give another boost
[23:35] <asac> as ati is really progressing fast aftrer they published their raw specs
[23:36] <asac> openarena?
[23:36] <asac> is that similar to quake 4 and ET quakewars?
[23:36] <asac> doom was bullshit ... I was playing quake 4 when hardy broke my setup and never came back ;)
[23:36] <asac> (but i havent tried fglrx in final jaunty i have to admit)
[23:37] <asac> now i have nexuiz ;)
[23:37] <asac> :-P
[23:37] <asac> not as good as unreal I ;) ... but still something to run, jump and shoot
[23:37] <asac> that reminds me that i even have unreal I on this machine if i am not mistaken
[23:38] <asac> enemy-territory/ etqw/            quake4/          ut2004/
[23:38] <asac> so no unreal I ;)
[23:39] <asac> but all those 4 are dead ;)
[23:39] <asac> how much i would love to play et ;)
[23:39] <asac> let me start it ;)
[23:40] <asac> heh
[23:40] <asac> it was fast enough that i managed to navigate my mouse to the Quit button
[23:40] <asac> which wasnt possible in the past ;)
[23:41] <asac> let me check what kernel folks fixed in -2
[23:41] <fta> openarena uses the quake 4 engine, iirc
[23:41] <asac> slow slow launchpad ;)
[23:41] <asac> fta: so its proprietary or did ID release that engine to opensource (couldnt believe it as its still pretty new)
[23:42] <asac> quake 4 engine is pretty decent
[23:42] <fta> it's in universe
[23:42] <asac> Open Arena: a completely free game for the FOSS Quake 3 engine
[23:42] <asac> yeah
[23:42] <asac> so its not 4
[23:42] <asac> (would have been shocking ;))
[23:43] <fta> oh, ok
[23:43] <fta> good enough for me
[23:43] <fta> i can frag as much as i want
[23:43] <asac> quake 4 is pretty good. they invented infinite textures in that engine
[23:43] <asac> hehe
[23:43] <asac> yeah
[23:43] <asac> probably
[23:43] <asac> maybe i should check that too
[23:43] <asac> but i guess it would work even with my bad driver ;)
[23:44] <asac> maybe enemy territory is based on that enigine?
[23:44] <asac> (wolfenstein)
[23:44] <asac> me installs openarena to see how the game play is - which is the most important part i guess
[23:45]  * asac notes: first check .31-2 kernel
[23:45] <asac> second. check openarena ;)
[23:47] <asac> doesnt look like the last two linux uploads changed something for me from changelog
[23:47] <asac> i will try anyway. maybe it was caused by something else now fixed


[09:33] <Odd_Bloke> smoser: harlowja: So that looks like we won't need to move to openstack/, right?
[09:33] <Odd_Bloke> As they are trying to avoid doing moves (rather than remove the string 'stackforge'), moving all the stackforge projects would seem unproductive...
[13:35] <smoser> Odd_Bloke, it seems that the name stackforge is gone.
[13:35] <smoser> we will have to move to openstack/ namespace.
[13:43] <Odd_Bloke> smoser: http://paste.ubuntu.com/12061743/
[13:43] <Odd_Bloke> smoser: That's from #openstack-infra just now.
[13:50] <smoser> well thats nicer than i thought
[13:54] <Odd_Bloke> smoser: Yeah, I think there was an earlier draft which was harsher.
[13:55] <smoser> i thoguht we were at least forced to move namespace nwo rather than "at _some_ undefined point"
[14:01] <claudiupopa> hey guys.
[14:01] <claudiupopa> meeting today?
[14:02] <Odd_Bloke> Yeah, I need to restart browser.
[14:02] <Odd_Bloke> Will be there RSN.
[14:03] <smoser> k
[14:07] <smoser> ok...
[14:07] <smoser> so we'll start cloud-init meeting here now.
[14:07] <claudiupopa> yeah, sorry about that, I don't know what's happening with my mic.
[14:08] <jgrimm> smoser, meeting here? or?
[14:08] <smoser> no worries
[14:08] <smoser> yeah
[14:08] <jgrimm> cool
[14:08] <smoser> let me type an agenda quick
[14:09] <smoser> agenda:
[14:09] <smoser>  * reviews http://bit.ly/cloudinit-reviews-public
[14:09] <smoser>    * https://review.openstack.org/#/c/209520/
[14:09] <smoser>  * reporting / smoser and cloud-init 0.7
[14:09] <smoser>  * main and persisting state
[14:09] <smoser>  * open discussion
[14:09] <smoser> seem reasonable ? if i've missed anything then we can add them in open discussion.
[14:09] <jgrimm> +1
[14:09] <claudiupopa> Sounds good.
[14:10] <Odd_Bloke> +1
[14:10] <smoser> ok.
[14:10] <smoser> so reading claudiupopa's very nice commit message.
[14:11] <smoser> i think looks nice. have to read closer on how the network and local data source woudl work.
[14:12] <smoser> but since many comments addresed in that review i think we're good there.. i'll review that some more after meeting
[14:12] <smoser> reporting / smoser and cloud-init 0.7
[14:12] <Odd_Bloke> Yeah, I need to do a re-review of that as well.
[14:12] <smoser> == reporting / smoser and cloud-init 0.7 ==
[14:12] <Odd_Bloke> But it was great last I looked, so that shouldn't take long.
[14:13] <smoser> i took the reporting code from cloud-init 2.0, and added some things to it and loaded it into 0.7. the things i added were not much, and the intent will be to get them to really just be copied from 2->0.7
[14:13] <smoser> the things discovered in using it that need to be addressed:
[14:13] <smoser>  a.) exceptions should not leak through reporting.
[14:13] <smoser>    the handlers should log errors but exceptions shoudlnt be allowed to bubble up.
[14:14] <claudiupopa> You mean errors inside the handlers?
[14:14] <smoser> yeah.
[14:14] <Odd_Bloke> claudiupopa: Yes.
[14:15] <smoser> ie, posting error to http://foo should not cause cloud-init to stacktrace
[14:15] <smoser> log failure, go on with life.
[14:15] <smoser>  b.) the webhook ideally woudl buffer messages until it has network connection and thne start. non-trivial to decide when it should try to reach an endpoint though.
[14:16] <Odd_Bloke> That sounds like a nice-to-have to me; do we have a concrete use case for something needing to know what happened before network comes up?
[14:16] <smoser> other than that i'd like to have that information collected...
[14:17] <smoser> if we add timestamp of events to the event, then it makes logging boot time very easy.
[14:17] <smoser>  c.) blocking... its not really a problem yet, but it'd seem that blocking on a webhook could be problematic to boot performance.
[14:18] <smoser> if we're just expecting things to log errors rather than raise exception seems reasonable to somehow not block the rest of the code.
[14:18] <smoser> make sense ?
[14:19] <Odd_Bloke> Could we achieve (b) by writing structured data to the filesystem (i.e. a separate reporter) and then a separate job could Require/After cloud-init-with-networking and push that data out somewhere?
[14:19] <claudiupopa> Why not storing them in memory?
[14:19] <claudiupopa> Seems redundant to cache them on the filesystem.
[14:20] <claudiupopa> And that's additional disk access that we don't need.
[14:20] <Odd_Bloke> Because we don't know when we're going to get networking, and systemd is good at ordered dependencies. :p
[14:20] <Odd_Bloke> I mean, this sounds like a very specific use-case.
[14:20] <Odd_Bloke> I'm thinking of a way that someone who wanted it could achieve it.
[14:21] <claudiupopa> Since I'm not very familiar with it..what systemd has to do with this? :-)
[14:21] <smoser> systemd would start a job for us when networkign was all up.
[14:21] <smoser> just like our next topic. we'll have stages in boot, for local datasource and applying networking config
[14:22] <smoser> and then a stage that runs when networking config has come up
[14:22] <smoser> in cloud-init 0.7 that is 2 separate processes, so need disk to persist and replay.
[14:23] <smoser> i agree that it is a bit of a specific use case
[14:23] <claudiupopa> I think I got it. I'm wondering if we could customize the stages or if they are hardcoded, since ideally on windows, we'll have only two of them.
[14:24] <smoser> how so?
[14:24] <claudiupopa> basically on windows we're doing everything in almost one run of cloudbaseinit. Except the fact that setting a hostname requires a restart and we have that splitted into another initial run.
[14:25] <claudiupopa> that's why we actually don't need persistence on disk for windows.
[14:25] <smoser> have to think some on it.
[14:25] <smoser> i think we're kind of moved on to topic 2
[14:25] <smoser> we've bled over.
[14:26] <Odd_Bloke> Yeah, I think there's a fairly fundamental design decision to be made here.
[14:26] <claudiupopa> yeah, regarding topic 1, I'm +1 on not crashing cloudinit when a reporting hook fails.
[14:26] <Odd_Bloke> Which is going to affect how we implement a whole bunch of things.
[14:26] <Odd_Bloke> And, yeah, we shouldn't crash out, and we should be able to do reporting in the background.
[14:26] <Odd_Bloke> We'll obviously need to ensure that the payload contains a timestamp if we're doing it in the background.
[14:27] <claudiupopa> in the background meaning a thread?
[14:27] <Odd_Bloke> I'm not fussy. :p
[14:27] <Odd_Bloke> It's all IO/networking, so the GIL won't be a problem.
[14:29] <smoser> so ..
[14:29] <smoser> https://review.openstack.org/#/c/202743/7/cloudinit/shell.py
[14:29] <smoser> the first 4 are "stages" that are largely what we have in cloud-init.
[14:29] <smoser> basically you have:
[14:29] <smoser> basically you have:
[14:30] <smoser>   search local datasources (and apply netowrking if possible) . this stage blocks networkign from coming up
[14:30] <smoser>  search network datasources and run "init" modules (in 0.7 talk)
[14:30] <smoser>  then config-final.
[14:31] <smoser>   which is really just supposed to be "rc.local like timeframe"
[14:31] <smoser> realize that i dont know that i wrote those well, but those are the general stages.
[14:31] <claudiupopa> got it
[14:31] <smoser> in 0.7 we have 3 config stages: init, config, and rc.local. i'm not sure if we need both 'init' and 'config'.
[14:31] <claudiupopa> so you're relying on the OS to call these 4 stages for you?
[14:32] <smoser> right.  but whether it calls me or not... they're still tasks we want to accomplish
[14:32] <smoser> and also offer as places to "hook" into boot
[14:32] <smoser> as the earlier you can do something, the less re-work you might have to do .. ie, ideally you can write config for a service before the service would normally start.
[14:33] <smoser> (so rc.local isn't ideal).
[14:33] <smoser> anywa..
[14:33] <claudiupopa> just to be clear on this, why the need of multiple stages in cloud-init? What does it solve from one single stage?
[14:33] <smoser> because running all "really early" might mean network isnt up.
[14:33] <smoser> and running all "really late" means you've lost your chance to make a change without restarting a service or possibly other negative side affects.
[14:34] <claudiupopa> so basically each run is a granular list of tasks to do, of config modules to execute?
[14:34] <smoser> in 0.7, yes.
[14:35] <smoser> in 2.0 we'd like this to be more dynamic, but still maintain that idea.
[14:35] <claudiupopa> yeah, what would be ideal is to have a workflow that doesn't require multiple runs on windows and works with more stages on other platforms.
[14:36] <claudiupopa> how about having a stage that chains all the other ones together?
[14:36] <smoser> well, that is what 'all' is.
[14:36] <claudiupopa> probably windows will be the only platform that will use it.
[14:37] <smoser> and its useful for a user wanting to re-try something.
[14:37] <claudiupopa> oh, there is one already.
[14:37] <smoser> i think you kind of still have 2 stages there though.
[14:37] <smoser> one before your networkign is up, that configures networkign, and sets hostname (and reboots)
[14:38] <smoser> and then one that runs after that in the new boot
[14:38] <claudiupopa> yeah, currently hostname and network config are separated.
[14:38] <smoser> ok.
[14:38] <claudiupopa> Don't know why, but I'm guessing because in the first phase we don't have networking info available.
[14:38] <claudiupopa> But I have to check it out.
[14:38] <claudiupopa> So two of them are definitely what we need.
[14:39] <claudiupopa> this means that there should be a way to customize what a stage is.
[14:39] <smoser> yeah, we can probably work things out.
[14:40] <smoser> so when Odd_Bloke went looking at this he came to the problem where the 'network' stage (locate and apply networking configuration')
[14:40] <smoser> would crawl a datasource and that datasource had a one-time read-only password in it.
[14:40] <smoser> the network stage, would only apply networking information ideally, so then he'd have to store that password somewhere so that the 'config' stage could apply it.
[14:41] <claudiupopa> yep, I understand know why persistance was into discussion.
[14:41] <smoser> at risk of being called an idiot.. i dont think its all that big of a deal.
[14:41] <smoser> i'd write the data to a file and read it back later.
[14:42] <smoser> if its a root owned file, you risk that password being read off the disk by a root user at some future point or having that data found otherwise.
[14:42] <smoser> i dont advocate storing passwords in plaintext on a disk, but i also dont advocate setting root passwords
[14:42] <smoser> Odd_Bloke, ? thoughts?
[14:43] <Odd_Bloke> Hold on, pulled in to another call.
[14:43] <smoser> claudiupopa, thoguths ?
[14:44] <claudiupopa> yeah, I'm not into security, but storing a file with potential private data doesn't strike me as being a very good practice.
[14:44] <smoser> on linux we could encrypt it for inclusion to shadow, so thats better than plaintext.
[14:45] <claudiupopa> also, if we'll have the ability to customize stages, then in that case on windows we will probably don't activate the persistance.
[14:45] <claudiupopa> If that makes sense.
[14:45] <claudiupopa> Since the password is probably not used by the network module.
[14:45] <smoser> and we can also attempt to "shred" the file on disk, but i'm not sure how affective shred is on non-local and spinning disks. (http://superuser.com/questions/22238/how-to-securely-delete-files-stored-on-a-ssd)
[14:46] <smoser> claudiupopa, i think we can come up with some solution there , yeah.
[14:46] <smoser> you'll have to drive that :)
[14:46] <claudiupopa> yeah.
[14:46] <claudiupopa> Okay.
[14:46] <claudiupopa> :-)
[14:47] <Odd_Bloke> Right, back./
[14:48] <Odd_Bloke> smoser: claudiupopa: So I had an idea: we could make the persistence invisible to consumers and only happen at the last possible moment.
[14:48] <Odd_Bloke> That way, if we decide to run in stages, we persist the data.
[14:48] <Odd_Bloke> But if we decide to run all at once, we don't.
[14:48] <Odd_Bloke> (Or we only persist things that haven't been scrubbed out of the data)
[14:49] <smoser> i think that sounds reasonable.
[14:49] <claudiupopa> makes sense
[14:51] <smoser> the registry could do that
[14:51] <smoser> you coudl register 'persistent' items, some with a 'secure' or something.
[14:51] <smoser> adn then on exit write it out
[14:52] <Odd_Bloke> I think we'd always need to write out everything if we were writing out.
[14:52] <Odd_Bloke> And then consumers of secure data would have a way of expunging it.
[14:52] <smoser> right.
[14:53] <Odd_Bloke> Which would remove it from memory and, if it had been persisted, remove it from disk as well.
[14:54] <claudiupopa> what's a consumer in this case? Another endpoint or?
[14:54] <smoser> config that consumes password
[14:54] <claudiupopa> aa.
[14:56] <Odd_Bloke> A potential future enhancement would be to allow you to configure cloud-init to never persist "secure" information.
[14:56] <Odd_Bloke> But that would require a way of specifying what was "secure" data, and so is probably too much to bite off at this point.
[14:58] <larsks> If I want to add a single item to cloud_final_modules, shouldn't I be able to do that with a cloud-config file that has a merge_how directive?
[15:00] <smoser> larsks, is the module available somwhere already ?
[15:03] <larsks> Yeah, it's one of the standard config modules. I just want to enable it (without needing to re-specify evertyhing that's in the system cloud.cfg)
[15:04] <larsks> I thought something like this might work: http://chunk.io/f/f36e3fad696f4e23bf0b3a3e7eb26182
[15:04] <larsks> ...but that seems to be *replacing* the cloud_final_modules: key.
[15:10] <Odd_Bloke> smoser: claudiupopa: So I think I have enough to start on implementing that configuration stuff (and therefore beginning on main work).
[15:10] <Odd_Bloke> smoser: claudiupopa: Do we have any open discussion topics?
[15:11] <claudiupopa> I don't think so. You mean working on stages?
[15:12] <Odd_Bloke> Yeah.
[15:12] <claudiupopa> one requirement I would like to have is the ability to customize them, we'll probably use something different on windows.
[15:12] <Odd_Bloke> So the current stubs include 'all' which runs all the stages.
[15:13] <Odd_Bloke> We could either add an 'all-on-windows', or make the stages that 'all' runs customisable using /etc/cloud.cfg (or the Windows equivalent).
[15:13] <Odd_Bloke> But getting 'all' working is probably further down the line anyway.
[15:13] <Odd_Bloke> So we can hash it out then. :)
[15:13] <claudiupopa> Okay. :-)
[15:15] <smoser> ok. i think we're done for today.
[15:15] <Odd_Bloke> Cool.
[15:15] <Odd_Bloke> I'm going to try to get the meeting I have half an hour after this meeting starts rescheduled.
[15:15] <claudiupopa> okay, guys.
[15:16] <claudiupopa> I'll be waiting a review on the data source api. ;-)
[15:16] <Odd_Bloke> So that I don't have to disappear just when we're getting to the juicy stuff. :p
[15:16] <Odd_Bloke> claudiupopa: Well I'm backporting stuff for cloud-init 0.7.x on Azure, which means I regularly have time to do other things while waiting for Azure.
[15:16] <Odd_Bloke> So hopefully I'll get to that this afternoon.
[15:18] <larsks> Odd_Bloke: smoser: any thoughts on the merging-vs-replacing question?
[15:18] <Odd_Bloke> larsks: I've never touched the merging stuff, so I have no idea, I'm afraid. :)
[15:20] <smoser> larsks, sorry.. reading
[15:20] <smoser> larsks, that actuallyu looks like it *should* work
[15:20] <smoser> you can also use cloud-config-jsonp to do somethig similar
[15:23] <larsks> smoser: yeah, that's what I thought, too :/.  I'm looking for jsonp examples right now; if you have one handy that would be awesome...
[15:24] <larsks> I found https://bugs.launchpad.net/cloud-init/+bug/1316323.  Let me git it a shot.
[15:50] <larsks> smoser: do you have a minute to take a gander at my cloud-config-jsonp attempt?
[15:51] <smoser> larsks, yea. sorry. give me a minute.
[15:52] <larsks> no rush.  Here are the details: https://gist.github.com/larsks/8e0848d4e81c9e7cb066
[15:52] <larsks> At the bottom is the jsonp file, based on the examples from the lp bug.  Above that  is the system cloud.cfg, and at the top is the error that cloud-init is throwing...
[15:53] <larsks> The error suggests that it is applying my patch against an empty configuration.
[15:58] <smoser> larsks, ok... so
[15:58] <smoser> from trunk, there is a tool : ./tools/ccfg-merge-debug
[16:00] <larsks> Okay.  I'll take a look at that in a second.  Did the jsonp in my gist look reasonable?
[16:02] <smoser> http://paste.ubuntu.com/12062712/
[16:03] <smoser> so it seems to work for me...
[16:03] <smoser> maybe you dont have a stock config ?
[16:03] <smoser> in which case maybe you have to create the entry first ?
[16:03] <smoser> hm..
[16:03] <larsks> No, there's definitely a stock config there.
[16:03] <smoser> yeah
[16:03] <smoser> odd
[16:19] <larsks> If it matters, I'm working with 0.7.5, because that's what centos has.
[16:34] <smoser> do you see any WARN in config  ?
[17:18] <larsks> smoser:  there are no warning messages in the log.  Using that merge config just replaces cloud_final_modules.  I can get the same behavior by booting with no user-data, and then running "cloud-init --file config-with-merge.yml modules --final"
[17:22] <smoser> larsks, i'm sorry, i'm not following
[17:22] <larsks> (a) there are no warnings (b) as we have seen, any use of that merge configuration actually *replaces* cloud_final_modules rather than appending, and (c) I can reproduce that behavior on demand just by passing the merge config to cloud-init using --file.
[17:24] <larsks> That makes me sad, because I am trying to avoid spinning a new cloud-init rpm every time someone says, "we should enable config module <foo> in the default configuration".
[17:24] <larsks> I'm going to see if maybe this is a version-related issue and maybe a more recent cloud-init will work correctly.
[17:25] <smoser> look at /etc/cloud/cloud.cfg.d/05_logging.cfg
[17:25] <smoser> andcomment out
[17:25] <smoser>  - [ *log_base, *log_syslog ]
[17:26] <smoser> so it doesnt go to /dev/log (im not sure where that goes)
[17:26] <larsks> /dev/log ends up in the system journal.
[17:26] <larsks> (on these systems)
[17:27] <larsks> Let me try this with 0.7.6 first, because if that makes the problem go away I think we're actually in okay shape.
[17:50] <smoser> larsks, it seems like maybe its a matter of unicode
[17:50] <larsks> Interesting. In what way?  Fwiw, 0.7.6 exhibits the same behavior...
[17:53] <smoser> nah. its nto that.
[17:53] <smoser> :-I(
[17:54] <smoser> it appears that you cant patch builtin config
[17:54] <larsks> Ahhhhhhhhh, poop.
[17:54] <smoser> yeah, crappy
[17:55] <smoser> you can re-define the whole list though
[17:55] <larsks> Yeah. Thanks for lookin'!


[12:26] <Ubugtu> New bug: #34568 in xserver-xorg-video-s3 (main) "old s3 videocards never properly configured (dup-of: 33504)" [Medium,Confirmed]  https://launchpad.net/bugs/34568
[12:31] <Ubugtu> New bug: #17613 in xserver-xorg-video-s3 (main) "[s3]  mode validation more strict than xfree86 version" [Medium,Rejected]  https://launchpad.net/bugs/17613
[12:36] <Ubugtu> New bug: #40560 in xserver-xorg-video-s3 (main) "GDM session does not start (dup-of: 33504)" [Medium,Unconfirmed]  https://launchpad.net/bugs/40560
[12:41] <Ubugtu> New bug: #35068 in xserver-xorg-video-s3virge (main) "Ubuntu hangs at logon screen" [Medium,Rejected]  https://launchpad.net/bugs/35068
[01:15] <Ubugtu> New bug: #38846 in xserver-xorg-video-savage (main) "[ProSavage8]  slow and jerky, high CPU usage (dup-of: 39647)" [Medium,Needs info]  https://launchpad.net/bugs/38846
[02:06] <Ubugtu> New bug: #82164 in Ubuntu "xorg.conf wrong default FontPaths (dup-of: 63408)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82164
[05:40] <Ubugtu> New bug: #32415 in bluez-utils "Bluetooth Mouse and Keyboard Broken in Dapper/Edgy/Feisty" [Medium,Needs info]  https://launchpad.net/bugs/32415
[11:54] <Ubugtu> New bug: #80611 in xorg (main) "Intel i965 doesn't have an appropriate driver " [Medium,Unconfirmed]  https://launchpad.net/bugs/80611
[04:45] <Ubugtu> New bug: #80262 in xorg (main) "X does not start with SAM2 Abit NF-M2S NVidia 6100" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80262
[07:50] <Ubugtu> New bug: #82320 in xorg (main) "Dell Latitude X200 display dpi detected incorrectly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82320
[10:21] <Ubugtu> New bug: #56892 in linux-restricted-modules-2.6.15 (restricted) "Wireless on MacBook not activated easily..." [Medium,Unconfirmed]  https://launchpad.net/bugs/56892
[11:30] <Ubugtu> New bug: #82372 in xserver-xorg-video-sis (main) "Problem with XVideo on sis 620 (530)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82372
[12:00] <Ubugtu> New bug: #38555 in Ubuntu "usb mouse not properly initialized" [Medium,Fix released]  https://launchpad.net/bugs/38555