[00:44] <davechen1y> lucky(~/src/github.com/juju/juju) % gb test
[00:44] <davechen1y> FATAL command "test" failed: failed to resolve import path "github.com/juju/juju/api": cannot find package "golang.org/x/net/http2/hpack" in any of:
[00:44] <davechen1y> ^ who added a dependency on the new http2 stuff ?
[00:48] <thumper> axw: yes
[00:48] <thumper> I believe so
[00:48]  * thumper shrugs
[00:49] <thumper> davechen1y: the shrug was for the http2 stuff
[00:50] <axw> davechen1y: "go list" shows no dependency on http2
[00:50] <thumper> perhaps just a test dep?
[00:51] <davechen1y> could be a test dep
[00:51] <davechen1y> still digging
[00:57] <davechen1y> ok
[00:57] <davechen1y> ignore this
[00:58] <davechen1y> short version: it's a go 1.6 thing
[00:58] <davechen1y> ignore it
[01:05] <thumper> :)
[01:08] <mup> Bug #1510333 opened: worker/uniter: converge on a single approach for updating goal state <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1510333>
[01:14] <mup> Bug #1510333 changed: worker/uniter: converge on a single approach for updating goal state <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1510333>
[01:17] <mup> Bug #1510333 opened: worker/uniter: converge on a single approach for updating goal state <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1510333>
[01:29] <davechen1y> http://reviews.vapour.ws/r/3000/
[01:29] <davechen1y> anyone ?
[01:31] <thumper> davechen1y: this is from where?
[01:31] <thumper> was it juju/juju/ssh?
[01:31] <thumper> I was going to suggest we just have juju/ssh rather than juju/utils/ssh
[01:31] <thumper> but then I saw the other deps on the utils package
[01:31] <thumper> and thought "meh"
[01:33] <davechen1y> thumper: the only thing worse than a utils packge is a utils repo
[01:33] <davechen1y> thumper: and the only thing worse than a utils repo is having several
[01:33] <davechen1y> one evil at a time
[01:33] <thumper> :)
[01:33] <thumper> k
[01:36] <thumper> axw: if you are happy with https://github.com/juju/retry/pull/1 I'll merge it :)
[01:36] <axw> thumper: sorry, I keep getting distracted
[01:36] <thumper> axw: I was hoping fwereade would have looked, but I'm prepared to land it now
[01:36] <axw> thumper: lemme take another quick look
[01:36] <thumper> cheers
[01:39] <sinzui> thumper: I have added github.com/juju/retry. We wont know it works until there is a branch to merge. Since there isn't a branch there now, I don't know which packages deps it imports.
[01:39] <thumper> sinzui: https://github.com/juju/retry/pull/1
[01:40] <sinzui> thank youn thumper . I will quickly add the deps I see
[01:40] <thumper> cheers
[01:42] <axw> thumper: reviewed
[01:43] <thumper> axw: ta
[01:51] <thumper> sinzui: I'll try merging now
[01:51] <thumper> sinzui: is it ready?
[01:51] <sinzui> thumper: yep, I am watching to procs now
[01:52] <thumper> sinzui: who handles which repos go to reviewboard?
[01:54] <sinzui> thumper: I don't know the config. I am sure ericsnow knows.
[01:55] <thumper> \o/ landed
[01:55] <sinzui> thumper: I see real go test was really run too
[01:55] <thumper> as opposed to what?
[01:56] <sinzui> thumper: the merge job just sending a success without actually merging the branch and running the tests
[01:56] <thumper> :)
[01:57] <thumper> I must admit, I do find it pleasing to see more tests than code :)
[01:57] <sinzui> :))
[02:53] <davechen1y>                         logger.Debugf("keeping unrecognised existing ssh key %q: %v", key, err)
[02:53] <davechen1y> ERRORS LOGGED AT DEBUGGG!
[02:54] <anastasiamac> "some error are more equal than others"?   What a nightmare.
[03:17] <davechen1y> i fixed it, with a hammer
[03:25] <davechen1y> axw: re ExecuteCommandOnMachine
[03:25] <davechen1y> what if it went to juju/utils/exec
[03:25] <axw> davechen1y: SGTM
[03:25] <axw> davechen1y: oh hum, but htat means utils/exec depends on ssh?
[03:27] <axw> davechen1y: if it's a PITA, don't worry. I'd just like for hte ssh package to be a bit leaner
[03:30] <davechen1y> i think i can fix that
[03:30] <davechen1y> type Client interface {
[03:30] <davechen1y> type Client interface {
[03:30] <davechen1y>  // Client is an interface for SSH clients to implement
[03:30] <davechen1y> type Client interface {
[03:31] <davechen1y> ^ honestly, it should just say "client is an interface"
[03:31] <davechen1y> for all the good that comment does :)
[03:32] <davechen1y> axw, hmm
[03:32] <davechen1y> this is quite tricky
[03:32] <davechen1y> execonmachien requires something that mathces Command(...) *ssh.Cmd
[03:32] <davechen1y> dunno if it can be teased apart easily
[03:33] <axw> davechen1y: yeah, just drop it. maybe it can be refactored later, not worth blocking the move over
[03:34] <davechen1y> mkay
[03:39] <davechen1y> i'm going to loose my shit this week http://juju-ci.vapour.ws:8080/job/github-merge-juju-utils/47/console
[03:39] <davechen1y> ^ anyone want to guess why this broke ?
[03:45] <axw> davechen1y: because it's using go 1.2 I'm guessing
[03:46] <axw> davechen1y: (and we're trying to compile it with that when we should just be downloading it and then checking out the older rev)
[03:54] <davechen1y> axw: i think there might be some sort of conditional compilation going on there
[03:54] <davechen1y> we pin the revision we want in juju/juju
[03:54] <davechen1y> but trying to compile juju/utils, it floats freely
[03:55] <axw> davechen1y: ah hm, cos we don't have a dependencies.tsv there ? :/
[03:55] <davechen1y> i dunno if adding one automatically help
[03:55] <axw> bit of an oversight
[03:55]  * axw shrugs
[03:56] <davechen1y> here's what I propose
[03:56] <davechen1y> 1. i go an have some lunch
[03:56] <davechen1y> 2. it magically fixes itselp
[03:56] <davechen1y> sgtm ?
[03:56] <axw> :)
[03:56] <axw> sounds good. I'll do the same
[03:56] <natefinch> 1. switch to gb
[03:56] <natefinch> 2. ???
[03:56] <natefinch> 3. profit
[09:32] <dimitern> frobware, hey, I'll be a couple of minutes late for our 1:!
[09:32] <dimitern> 1:1
[09:35] <frobware> dimitern, ok
[10:02] <dimitern> jam, fwereade, standup?
[10:36] <axw> fwereade: my latest rev on http://reviews.vapour.ws/r/2935/ is quite substantial, I'd appreciate a look at the last commit when you can
[10:37] <axw> fwereade: there's an unrelated fix mised in there, but it's also up for review as http://reviews.vapour.ws/r/3002/
[10:37] <axw> s/mised/mixed/
[10:47] <fwereade> axw, thanks
[11:13] <fwereade> axw, both reviewed
[12:05] <fwereade> https://github.com/juju/juju/wiki/howto:-implement-effective-config-structs
[12:05] <fwereade> ...if anyone feels like some light reading or arguing
[12:56] <wallyworld> fwereade: did you have time for a chat?
[12:58] <fwereade> wallyworld, just about to have lunch -- what time is it for you?
[12:58] <wallyworld> 23:00, i don't mind waiting
[12:59] <wallyworld> just ping when you're free
[13:07] <mup> Bug #1510533 opened: destroy-environment panics <juju-core:New> <https://launchpad.net/bugs/1510533>
[13:10] <mup> Bug #1510533 changed: destroy-environment panics <juju-core:New> <https://launchpad.net/bugs/1510533>
[13:13] <mup> Bug #1510533 opened: destroy-environment panics <juju-core:New> <https://launchpad.net/bugs/1510533>
[14:02] <katco> ericsnow: wwitzel3: natefinch: please do the standup without me. cats shattered lots of glass on our kitchen floor and my dog ate some
[14:02] <perrito666> katco: ate some cat or glass?
[14:04] <wwitzel3> katco: ok
[14:05] <frobware> dimitern, ping
[14:43] <abentley> sinzui: chat?
[14:44] <sinzui> abentley: sure
[15:26] <mup> Bug #1403689 changed: Server should handle tools of unknown or unsupported series <upgrade-juju> <upload-tools> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Triaged> <juju-core 1.25:Fix Released by wallyworld> <https://launchpad.net/bugs/1403689>
[16:32] <mup> Bug #1510619 opened: Wily: add machine fails using kvm and lxcbr0 <add-machine> <cloud-installer> <kvm> <network> <juju-core:New> <https://launchpad.net/bugs/1510619>
[17:40] <voidspace> mgz_: ping
[17:40] <mgz_> voidspace: wotcha
[17:40] <voidspace> mgz_: hey
[17:41] <voidspace> mgz_: so we have plans to get rid of the need for ignore-addresses on master
[17:41] <mgz_> ace
[17:41] <voidspace> mgz_: but we're going to land the fix and test it with those needing it *before* we actually remove ignore-addresses
[17:41] <voidspace> (I work on the proposed fix next)
[17:41] <voidspace> mgz_: so we'll land the change to ignore-addresses on containers and master first
[17:42] <voidspace> mgz_: because currently containers are broken when you use ignore-machine-addresses
[17:42] <voidspace> mgz_: and next a question...
[17:42] <mgz_> voidspace: sounds fair
[17:42] <voidspace> mgz_: when I attempt to do an upgrade from 120/1.22 to 1.24 but using --upload-tools
[17:42] <voidspace> mgz_: it fails with "unknown series wily"
[17:43] <voidspace> mgz_: dimitern thought you might have encountered this, or similar, when testing upgrades with QA and know a workaround
[17:45] <mgz_> voidspace: yeah, we've had a lot of that in testing,
[17:45] <voidspace> mgz_: did you solve it?
[17:45] <mgz_> not sure if I know a specific workaround when using --upload-tools for upgrade though
[17:45] <voidspace> :-/
[17:46] <voidspace> I'll ask aaron
[17:46] <voidspace> abentley: ping
[17:46] <mgz_> bug  1403689 is part of it
[17:46] <voidspace> bug 1403689
[17:46] <mup> Bug #1403689: Server should handle tools of unknown or unsupported series <upgrade-juju> <upload-tools> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Triaged> <juju-core 1.25:Fix Released by wallyworld> <https://launchpad.net/bugs/1403689>
[17:46] <voidspace> mgz_: ah, I wondered if there was a bug for it
[17:46] <voidspace> mgz_: thanks
[17:47] <voidspace> unassigned for 1.24 currently
[17:47] <mgz_> what CI does is actually use streams, which we then control
[17:47] <voidspace> right
[17:47] <voidspace> I thought as much, and we can't suggest that to IS I don't think
[17:47] <voidspace> we want them to test the new binaries
[17:47] <mgz_> but yeah, bug suggests --upload-tools to 1.25 would work?
[17:48] <voidspace> 1.25 isn't released yet
[17:48] <mgz_> upgrades with --upload-tools are pretty dodgy anyway
[17:48] <voidspace> needed when you have new binaries for a user to test
[17:49] <sinzui> voidspace: your experience mirror's abentley's frustration over the past 48 hours
[17:50] <voidspace> sinzui: heh
[17:50] <voidspace> ouch
[17:50] <sinzui> voidspace: the stupid client makes assumptions about its host to decide what to upload to the series and since 1.20.x doesn't check distro-info-data correctly, it will die because of vivid or wily
[17:51] <voidspace> right :-/
[17:51] <voidspace> sinzui: it makes testing upgrades / fixes for upgrade bugs impossible
[17:51] <voidspace> hopefully the fix is correct, so we never have the issue again
[17:53] <sinzui> voidspace: abentley  might want to bu you beer
[17:53] <voidspace> sinzui: hah
[17:54] <voidspace> sinzui: no, I meant the fix that wallyworld has allegedly committed to 1.25 and master
[17:54] <voidspace> not that I've done it
[17:54] <voidspace> he hasn't committed it to 1.24 though, which is where we need it
[17:54] <sinzui> voidspace: CI tests 1.20 upgrades to the candidate we test. abentley is updating the test to use upload-tools as needed. so your change is exactly what we are looking to test
[17:54] <voidspace> right
[17:54] <voidspace> so we need 1.20 and onwards fixed really
[17:54] <voidspace> might be worth abentley pinging wallyworld about it
[17:55] <sinzui> voidspace: yeah, we can do a 1.20 release if we need to. We just need to make several jobs non-voting before hand to check to deal with unsupported features
[17:56] <voidspace> sinzui: although a 1.20 to 1.22 upgrade works I believe, 1.24 is the problematic version
[17:56] <voidspace> sinzui: so just fixing 1.22 on would suffice
[17:56] <voidspace> which is one less release at least
[17:57] <sinzui> voidspace: we can test/release 1.22 at anytime. we have special PPA setup for its distrubution too
[17:57] <voidspace> cool
[17:58] <voidspace> I've added a comment to the bug
[18:05] <mup> Bug #1510651 opened: Agents are "lost" after terminating a state server in an HA env <juju-core:New> <https://launchpad.net/bugs/1510651>
[18:29] <voidspace> frobware: our proposed fix for getting rid of ignore-machine-addresses can't work
[18:29] <voidspace> frobware: it's effectively what we're already doing
[18:29] <voidspace> frobware: we might need to prefer a provider fallback address over an exact match machine address
[18:29] <voidspace> frobware: I'll discuss it with dimiter tomorrow
[18:30] <voidspace> frobware: meanwhile, the fix for containers has landed on 1.25 and is landing on master
[18:30] <voidspace> frobware: and I've tested on both 1.25 and master
[18:32] <abentley> voidspace: pong
[18:36] <voidspace> abentley: unping
[18:36] <voidspace> abentley: it's about the wily issue and upgrades
[18:36] <voidspace> abentley: see the above conversation if you want... :-)
[18:36] <voidspace> abentley: I'll try and persuade wallyworld that we need the fix for 1.22 & 1.24
[18:39] <abentley> voidspace: I'm not sure whether we need 1.22.  1.24 would be nice, given that we may need to do a 1.24.8 at some point.
[18:40] <voidspace> abentley: well, if you want to test an upgrade *from* 1.22 (as I do as it happens and I thought you needed to) then we need it in 1.22
[18:41] <abentley> voidspace: Mwuh?  You mean he fixed the server instead of the client?
[18:42] <voidspace> abentley: the error message is from the api server
[18:42] <voidspace> not a client issue as far as I know
[18:43] <voidspace> abentley: see bug 1403689
[18:43] <mup> Bug #1403689: Server should handle tools of unknown or unsupported series <upgrade-juju> <upload-tools> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Triaged> <juju-core 1.25:Fix Released by wallyworld> <https://launchpad.net/bugs/1403689>
[18:43] <voidspace> abentley: it's the api server that rejects the upload
[18:46] <abentley> voidspace: The client should not try to upload tools that it knows will be rejected by the server.
[18:47] <natefinch> katco: is your dog ok?
[18:50] <voidspace> abentley: not sure how it was fixed
[18:53] <mup> Bug #1510619 changed: Wily: add machine fails using kvm and lxcbr0 <add-machine> <cloud-installer> <kvm> <network> <juju-core:Invalid> <lxc (Ubuntu):New> <https://launchpad.net/bugs/1510619>
[18:59] <mup> Bug #1510619 opened: Wily: add machine fails using kvm and lxcbr0 <add-machine> <cloud-installer> <kvm> <network> <juju-core:Invalid> <lxc (Ubuntu):New> <https://launchpad.net/bugs/1510619>
[19:05] <mup> Bug #1510619 changed: Wily: add machine fails using kvm and lxcbr0 <add-machine> <cloud-installer> <kvm> <network> <juju-core:Invalid> <lxc (Ubuntu):New> <https://launchpad.net/bugs/1510619>
[19:44] <mup> Bug #1510675 opened: vSphere provider leaves behind virtual machines upon bootstrap failure <bootstrap> <vsphere> <juju-core:New> <https://launchpad.net/bugs/1510675>
[19:47] <mup> Bug #1510675 changed: vSphere provider leaves behind virtual machines upon bootstrap failure <bootstrap> <vsphere> <juju-core:New> <https://launchpad.net/bugs/1510675>
[19:50] <mup> Bug #1510675 opened: vSphere provider leaves behind virtual machines upon bootstrap failure <bootstrap> <vsphere> <juju-core:New> <https://launchpad.net/bugs/1510675>
[20:17] <mup> Bug #1510688 opened: sync-tools tries to upload agents that are not permitted by the state server <sync-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1510688>
[20:17] <mup> Bug #1510689 opened: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <upgrade-juju> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1510689>
[20:20] <mup> Bug #1510688 changed: sync-tools tries to upload agents that are not permitted by the state server <sync-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1510688>
[20:20] <mup> Bug #1510689 changed: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <upgrade-juju> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1510689>
[20:26] <mup> Bug #1510688 opened: sync-tools tries to upload agents that are not permitted by the state server <sync-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1510688>
[20:26] <mup> Bug #1510689 opened: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <upgrade-juju> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1510689>
[21:59] <wallyworld> cmars: running a bit late, can i ping you
[21:59] <cmars> wallyworld, sure, np
[22:07] <alexisb> cmars, that was my fault, that wallyworld was late
[22:08] <cmars> alexisb, heh no worries
[22:08] <wallyworld> cmars: it's always alexisb fault
[22:08] <wallyworld> there now
[22:36] <wallyworld> axw: anastasiamac: perrito666: i have to make an emergency run to the school to drop off some stuff, so will miss standup; i'll talk to you guys when i get back to catch up
[22:41] <anastasiamac> wallyworld: k
[22:49] <perrito666> wallyworld: k


[02:20] <cmaloney> Evening
[13:14] <cmaloney> I have to say, I'm always impressed by LTS upgrades
[13:14] <cmaloney> Went from 18.04 to 20.04 last night on my laptop and most everything is fine


[04:28] <Moonwalker> Hi members of the IRC Council. I wrote to you about the op issues in #ubuntu-cn, but no response yet. Could anybody help?
[04:29] <rww> #ubuntu-irc-council. You missed a bit :P
[04:34] <Moonwalker> hmm, indeed.
[04:34] <Moonwalker> :)


[06:56] <fling> Is not 5.4.49 compat patch for shiftfs there yet?
[18:15] <Ezro> Hey folks. Can anyone help with a bug I raised (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891062)? It looks like a patch is available in the linux 5.4.y branch that _should_ resolve the bug, but I'm unsure of what steps should be taken next.
[20:37] <tjaalton> Ezro: that commit has been in the distro kernel for a long time already
[20:40] <Ezro> Hm.. I upgraded my BIOS earlier today and performed a clean install but I'm still not able to use my trackpad buttons. Do you have any guidance on what I could / should do to get the buttons working?
[20:43] <sarnold> Ezro: if it doesn't work becaues the kernel doesn't support it correctly, you can file bugs with the kernel folks; I'm not sure if they actually look at it, but it'll at least be a place to report results that might be easier to follow than LKML https://bugzilla.kernel.org/
[20:51] <Ezro> Ah, I see what you're saying. I'll reach out to them. Thanks!


[10:01] <tracker7> Hi
[10:02] <tracker7> I am interested in contributing
[10:02] <tracker7> in QA
[10:02] <tracker7> any one guide me in going around and contribute?
[11:38] <knome> eh, too little time to reply
[11:39] <akxwi-dave> noticed that myself.. :-0 was half way thru one when they loggoed off..
[11:40] <knome> yeah
[11:40] <knome> the first line should always be extremely short to avoid that...
[12:04] <flocculant> like - !qa = don't run - give people time to respond
[12:04] <flocculant> :p
[12:04] <knome> or like
[12:04] <knome> "hi"
[12:05] <flocculant> [10:15:05] < xnox> flocculant, i know, i am working on it.                                                                balloons
[12:05] <flocculant> [10:15:08] < xnox> flocculant, sorry about that!
[12:05] <flocculant> bluesabre: re the upstart indicator bug thingy ^^
[12:06] <flocculant> knome: or that :)
[12:06] <bluesabre> flocculant, nice
[12:07]  * flocculant was scared to update upstart this morning .... debian/upstart-xsessions: remove all but unity8 sessions, thus migrating all sessions to systemd and/or pre-upstart session management.
[12:08] <bluesabre> oh boy
[12:08] <flocculant> rebuilt iso - will make sure that works before I update locally ...
[12:08] <flocculant> bluesabre: just zsyncing now - should get an install done before I wander off again
[12:19] <flocculant> bluesabre: wish me luck ...
[12:23] <flocculant> well that would have been better if I'd updated before rebooting - but it works still second time around
[12:28] <bluesabre> flocculant, that's good at least
[12:28] <flocculant> yup
[12:28] <flocculant> time to run - have a good day :)
[16:11] <flocculant> bluesabre: not sure if you caught what I meant there :p upstart update didn't take 2 goes - I did cos I rebooted without updating :)


[05:46] <davecheney> hey hey
[05:46] <davecheney> the good news, juju can now bootstrap from quantal to precise
[05:46] <davecheney> the bad news, do-release-upgrade on my precise system totally hosed it :(
[07:07] <fwereade> davecheney, heyhey
[07:08] <davecheney> fwereade: hey
[07:09] <fwereade> davecheney, reviewed one, with unhelpful whining about tests, I'm afraid
[07:09] <davecheney> understood
[07:09] <davecheney> it is a non trivial amount of work to add 409 response behavior to s3test
[07:09] <davecheney> i'll man up and do it
[07:10] <fwereade> davecheney, on the other, trying to figure out what the deal is with the arch change in cloudinit_test
[07:11] <fwereade> davecheney, thanks very much :)
[07:11] <fwereade> davecheney, I expect it makes sense somehow, but I just cannot figure out where that i386 came from
[07:14] <davecheney> fwereade: i386 is just to double check that cloudinit isn't amd64 only
[07:15] <fwereade> davecheney, I just can't see what change caused it to use i386 where once it used amd64
[07:15] <davecheney> fwereade: i can remove the i386 thing if it is confusing
[07:15] <davecheney> it isn't testing anything important
[07:16] <fwereade> davecheney, sorry, I have just come to realise I am being stupid
[07:17] <fwereade> davecheney, so that one basically LGTM -- but the description should be fixed if it is now actually intended for submission ;)
[07:18] <davecheney> fwereade: cool
[07:18] <davecheney> that is the one i really care about
[07:19] <davecheney> as i upgraded to quantal today (twice)
[07:21] <fwereade> davecheney, ah, cool
[07:21] <fwereade> davecheney, you have an LGTM with one nitpick
[07:23] <fwereade> bbiab
[07:47] <rogpeppe> fwereade: hiya
[08:09] <fwereade> rogpeppe, heyhey
[08:13] <TheMue> morning
[08:39] <rogpeppe> TheMue: hi
[08:40] <TheMue> rogpeppe: hiya
[08:40] <rogpeppe> fwereade: what's our current position on watchers returning updates for any changes, not just lifecycle? (i'm looking at MachinePrincipalUnitsWatcher here)
[08:43] <rogpeppe> fwereade: it seems a bit silly that when we're told about a unit changing, we fetch its unit doc twice. ISTM that hardly any logic in the client (worker/machiner) would have to change, and we could get rid of a big chink of logic in the watcher
[08:45] <TheMue> rogpeppe: I like the idea of getting notified on any change, but I then like to get the watched entitiy (not only the id) and a useful information what has changed (e.g. the lifecycle state)
[08:46] <fwereade> rogpeppe, I am still undecided tbh
[08:46] <rogpeppe> TheMue: from what i see of the clients, they don't make that much use of that info.
[08:47] <fwereade> rogpeppe, the trouble is that different use cases are different and I think that both behaviours are wanted in different places
[08:47] <TheMue> rogpeppe: The old added/removed separation has been more helpful than today iterating over ids, retrieve the state and compare it.
[08:47] <rogpeppe> fwereade: if we're just sending ids, then i think it makes sense that the client is responsible for doing the refresh and doing the diffs itself
[08:48] <rogpeppe> TheMue: i agree, but since we've moved away from that, i think it makes sense to take advantage of that
[08:48] <fwereade> rogpeppe, this is true, up to a point -- let me read some code a mo
[08:48] <rogpeppe> TheMue: there's no need for both the watcher *and* the client to be independently fetching the doc
[08:48] <TheMue> rogpeppe: That's true
[08:50] <fwereade> rogpeppe, I consider it to be a good thing, though, that the ServiceRelationsWatcher filters out irrelevant changes and only tells me about life changes
[08:50] <rogpeppe> fwereade: how much would your logic need to change if it told you about other changes too?
[08:50] <fwereade> rogpeppe, it could be more efficient -- it only needs to grab 2 fields to do the comparison -- but I think we need to consider the HTTP API here
[08:51] <rogpeppe> fwereade: after all, you need to fetch the doc to find out exactly *what* has changed
[08:51] <fwereade> rogpeppe, I think it *is* worth getting the document twice, because once the watcher is implemented behind the API, right next to the state, it is cheap for it to get a document
[08:52] <fwereade> rogpeppe, and by doing so it can send fewer updates to remote clients on the other side of the API
[08:52] <fwereade> rogpeppe, and those clients, for whom getting a document is expensive, don't have to repeatedly get and inspect the documents to do their own filtering
[08:53] <fwereade> rogpeppe, sane?
[08:53] <rogpeppe> fwereade: hmm
[08:55] <rogpeppe> fwereade: that's a reasonable point
[08:57] <rogpeppe> fwereade: o
[08:57] <rogpeppe> fwereade: darn, i thought we could get rid of large chunks of code
[09:04] <fwereade> rogpeppe, annoying, innit ;)
[09:05]  * rogpeppe grumbles
[09:05] <fwereade> rogpeppe, TheMue: so, given that, I think the answer really is annoyingly situational
[09:05] <fwereade> rogpeppe, TheMue: for the firewaller, it's perfect to get life and ports changes only
[09:06] <fwereade> rogpeppe, service relations we want life only
[09:06] <fwereade> rogpeppe, TheMue: again, for the (?)deployer and/or machiner, life changes only
[09:07] <rogpeppe> fwereade: i'm happy with that now.
[09:07] <fwereade> rogpeppe, cool, sorry :)
[09:07] <TheMue> :D
[10:29] <Aram> morning.
[10:32] <TheMue> Aram: hi
[10:41] <rogpeppe> Aram: you've got a couple of reviews
[10:41] <rogpeppe> Aram, fwereade: what's the story regarding https://codereview.appspot.com/6811091 vs https://codereview.appspot.com/6820112 ?
[10:42] <rogpeppe> looks like there are quite a few conflicts there
[10:42] <Aram> rogpeppe: unfortunate duplication of effort
[10:44] <rogpeppe> Aram: well, yours does more, as it uses WatchUnits rather than WatchPrincipalUnits. maybe fwereade's should go in first.
[11:06] <rogpeppe> hmm, looks like my gmail account has been hacked
[11:07] <TheMue> rogpeppe: Yesterday there also has been a strange twitter message by you.
[11:07] <rogpeppe> TheMue: yeah, that was hacked too. seems a bit strange - they both had different passwords
[11:07] <rogpeppe> TheMue: although, to be fair, both passwords were terribly weak
[11:08] <TheMue> rogpeppe: OK, so maybe just brute force.
[11:08] <rogpeppe> TheMue: i think so
[11:09] <TheMue> rogpeppe: I like the xkcd, where long curious sentences are better than "P4ssw0rd". ;)
[11:09] <rogpeppe> TheMue: yeah, that's the approach i'm using
[11:10] <rogpeppe> TheMue: with a couple of weird chars thrown in for good measure
[11:10] <TheMue> rogpeppe: I've changed it and now have stupid sentences.
[11:12] <TheMue> rogpeppe: But today I had to set one with 8 to 15 chars and no specia characters. Why those constraints? *sigh*
[11:12] <rogpeppe> TheMue: yeah, that's outrageous. don't they know that you can run sha1 in javascript? :-)
[11:13] <TheMue> rogpeppe: Yep ;)
[11:24] <rogpeppe> interesting to see the spam machine in action
[11:24] <rogpeppe> none of the sent messages addressed more than 5 recipients
[11:25] <rogpeppe> and they all sent a different link
[11:27] <TheMue> rogpeppe: Yeah, they do their best to not being catched by spamassassin or postgrey.
[11:29] <rogpeppe> they got as far as "j" in my address book
[11:30] <rogpeppe> 65 spam messages sent in total
[12:38] <rogpeppe> fwereade: ping
[12:44] <Aram> rogpeppe: I want acme integration with codereview.
[12:45] <rogpeppe> Aram: how would you want it to work?
[12:46] <Aram> rogpeppe: somewhat like mail.
[12:46] <Aram> in fact even using that with the email you get now from codereview is almost usable, aparte from the fact that you can't reply.
[12:47] <rogpeppe> Aram: do you still use acme mail?
[12:47] <Aram> no.
[12:47] <rogpeppe> Aram: i used it for years actually, but the lack of threading finally got to me
[12:48] <rogpeppe> Aram: and the benefits aren't so great if you're not running under plan 9
[12:48] <Aram> yeah...
[12:48] <fwereade> rogpeppe, deferred pong
[12:48] <fwereade> rogpeppe, I have to pop out for a while and will be somewhat spottily around this afternoon and evening
[12:48] <Aram> acme mail is not so useful at this point anymore, but I think for specialized things, an acme mail thing would be useful.
[12:48] <fwereade> rogpeppe, I will grab you this pm though
[12:48] <rogpeppe> fwereade: ok. sometime i'd like a chat about some new attributes in config
[12:49] <rogpeppe> fwereade: but i think i've decided on a reasonable approach actually
[12:49] <fwereade> rogpeppe, cool -- I look forward to seeing it :)
[12:49] <fwereade> tytyl
[12:49] <rogpeppe> fwereade: have fun
[12:50] <rogpeppe> Aram: go for it; i'd like to see what you come up with.
[15:13] <rogpeppe> fwereade: i'll just run the config stuff by you to check for crackfullness, if that's ok
[15:13] <fwereade> rogpeppe, sgtm
[15:14] <rogpeppe> fwereade: so, we want to be able to specify a root CA when bootstrapping and when connecting to an environment
[15:14] <fwereade> rogpeppe, ok
[15:15] <rogpeppe> fwereade: when bootstrapping we'll need the private key too, so we can sign a new key/cert pair and hand it off to the first instance
[15:15] <rogpeppe> fwereade: so my thought is to add three new attributes to config
[15:15] <rogpeppe> fwereade: root-cert-path, root-cert and root-private-key
[15:15] <rogpeppe> fwereade: root-cert-path acts a little like authorized-keys-path
[15:16] <rogpeppe> fwereade: that is, if it's set, the cert/key pair is read from that file; otherwise if root-cert isn't set in config, we'll try to read from ~/.juju/rootcert.pem
[15:17] <fwereade> rogpeppe, yep, that makes sense
[15:17] <rogpeppe> fwereade: we verify that the cert parses and that, if given, the key matches the cert.
[15:18] <rogpeppe> fwereade: which prevents going a long way down the road with a bogus cert/key pair
[15:18] <fwereade> rogpeppe, ok, yep
[15:18] <rogpeppe> fwereade: i think that's it, for the time being
[15:19] <rogpeppe> fwereade: i'm just doing the tests
[15:19] <rogpeppe> fwereade: it's a pity that it's yet one more step to getting a juju up and running
[15:20] <rogpeppe> fwereade: i wonder if we might have a juju helper that prompts for the necessary information and does everything else necessary (e.g. generating the key, generating an admin secret, etc) and writes an environments.yaml file.
[15:21] <fwereade> rogpeppe, just one of many, really, we'll get there :)
[15:21] <fwereade> rogpeppe, yeah, new-user experience would be very much helped by that
[15:22] <rogpeppe> fwereade: juju new-environment ?
[15:22] <rogpeppe> fwereade: i'm not sure that we can rewrite environments.yaml losslessly though, sadly
[15:22] <fwereade> rogpeppe, I'm pretty sure we can't
[15:23] <rogpeppe> fwereade: me too. +1 to json :-)
[15:23] <rogpeppe> fwereade: actually, maybe it could just spit out an environments.yaml to stdout
[15:23] <rogpeppe> fwereade: anyway, that's way down the line.
[15:23] <rogpeppe> fwereade: if all that SGTY, i'll carry on
[15:24] <fwereade> rogpeppe, I *think* it does
[15:24] <fwereade> rogpeppe, I am not sure how to handle changing the root cert
[15:24] <fwereade> rogpeppe, or in general how to (or whether we should) change any of those new fields
[15:25] <fwereade> rogpeppe, (I guess root-cert-path is not really a setting, at least, just a sort of input filter)
[15:25] <rogpeppe> fwereade: yeah, changing the root cert is hard
[15:25] <rogpeppe> fwereade: and what about certificate revocation
[15:25] <rogpeppe> ?
[15:26] <fwereade> rogpeppe, quite so
[15:27] <fwereade> rogpeppe, I guess it would be worth trying to think a little way through those questions to ensure we're not closing any future doors, even if we don't support anything like that at this stage
[15:30] <rogpeppe> fwereade: tbh, i think that both with changing the root cert and revocation, what we're building now is a necessary prerequisite. we are always going to need to pass at least one certificate into the cloud.
[15:31] <fwereade> rogpeppe, that does sound solid to me
[15:31] <rogpeppe> fwereade: revocation, i think happens automatically, as long as clients are checking revocation lists appropriately.
[15:33] <rogpeppe> fwereade: changing the root cert we'd probably do by leveraging the existing root cert to produce another cert. you'd probably do it by using a level of indirection and revoking the original certificate but not the original *root* certificate (he says, hand-waving wildly)
[15:35] <fwereade> rogpeppe, I think that's outside the realm of things I can claim to have a reasoned opinion on ;)
[15:52] <fwereade> rogpeppe, incidentally, I was wondering something related... ISTM that the user is already adequately identified with the authorized key, and I'm suddenly unsure what we get out of admin-secret... what am I missing?
[15:53] <Aram> rogpeppe: significantly refined version https://codereview.appspot.com/6820112/ , when you have time
[15:54] <rogpeppe> fwereade: that may well be true in the future. for the time being, i don't know of a way to get mongodb do client authentication
[15:55] <fwereade> rogpeppe, ok, cool, so it's purely for admin auth with mongo?
[15:55] <rogpeppe> fwereade: yes, i *think* so
[15:56] <rogpeppe> Aram: looking
[16:50] <Aram> rogpeppe: also https://codereview.appspot.com/6814108/
[16:51] <rogpeppe> Aram: sorry, i got some way through, then realised i really wanted to propose my CL by the end of the day...
[16:51] <Aram> rogpeppe: don't worry, I'm only pinging you, I don't expect reviews right away.
[16:52] <rogpeppe> Aram: that's find. just letting you know in case you expected one after my "looking"
[16:52] <rogpeppe> s/find/fine/
[18:03] <rogpeppe> fwereade: ping
[18:03] <fwereade> rogpeppe, pong
[18:03] <rogpeppe> fwereade: i've just realised, i think, that i'm slightly askew in my assumptions
[18:03] <fwereade> rogpeppe, oh yes?
[18:04] <rogpeppe> fwereade: i've been assuming that it's mandatory to have a root certificate
[18:04] <rogpeppe> fwereade: but actually, i think we perhaps want the capability to connect to a server without checking
[18:04] <fwereade> rogpeppe, expand please
[18:04] <fwereade> rogpeppe, naively it seems like a good idea
[18:05] <rogpeppe> fwereade: well, say we have a juju environment but we've lost the root cert key
[18:05] <rogpeppe> fwereade: the checking that juju does is, i think, something that should be a choice (the default choice)
[18:05] <rogpeppe> fwereade: 'cos otherwise we can't connect
[18:06] <rogpeppe> fwereade: a bit like the way ssh automatically adds a key if you ask for it
[18:06] <fwereade> rogpeppe, I kinda favour just advising people that "keys are important; don't lose them"
[18:07] <rogpeppe> fwereade: i was just wondering if i really want the root cert to be mandatory in config
[18:07] <rogpeppe> fwereade: (i've just spent the last while putting it everywhere...)
[18:08] <fwereade> rogpeppe, ha, yeah, it is usually at such junctures that I start to question things
[18:08] <fwereade> rogpeppe, hmm
[18:08] <fwereade> rogpeppe, honestly I don;t know what is really meant by "everywhere" so it is hard for me to follow intuitively
[18:09] <rogpeppe> fwereade: i got to environs/ec2, and realised that it uses your actual authorized keys, so i'm wondering whether we want to the same approach for root cert, or if we should generate one on the fly
[18:09] <rogpeppe> fwereade: everywhere we've got a set of attributes for a config
[18:09] <rogpeppe> fwereade: pretty much everywhere we've got an authorized-keys attribute now
[18:10] <rogpeppe> fwereade: i'm thinking that it might be fine just to hard-code a root cert for testing.
[18:11] <rogpeppe> fwereade: there's another thing which is a source of discomfort currently
[18:12] <rogpeppe> fwereade: which is that the cert and key are specified in a single file, but they get two attributes in the config.
[18:12] <fwereade> rogpeppe, yeah, that definitely seems wrong
[18:12] <fwereade> rogpeppe, except hmm
[18:13] <fwereade> rogpeppe, maybe not
[18:13] <rogpeppe> fwereade: there are +s and -s
[18:13] <fwereade> rogpeppe, but, yeah, it doesn't sit quite right
[18:13] <rogpeppe> fwereade: i was trying to avoid having *two* more path attributes in the config.
[18:13] <fwereade> rogpeppe, hmm, just a mo
[18:14] <rogpeppe> fwereade: but perhaps that makes more sense in fact; keep them separate at all times.
[18:14] <fwereade> rogpeppe, if that is as convenient that sgtm
[18:15] <rogpeppe> fwereade: it's not convenient at the moment - i'd have to rewrite some code and lots of tests :-)
[18:15] <fwereade> rogpeppe, ha, indeed
[18:16] <rogpeppe> fwereade: but on balance, i think it's probably a better approach
[18:16] <rogpeppe> fwereade: bugger
[18:16]  * fwereade sympathises
[18:20] <fwereade> rogpeppe, a strawmanny thought
[18:21]  * rogpeppe gets out the wooden axe
[18:22] <fwereade> rogpeppe, how would it be if the administrator who created the environment were to have keys and certificates automatically generated and stored in ~/.juju/environments/<name>?
[18:22] <fwereade> rogpeppe, they could of course be overridden by config settings
[18:23] <rogpeppe> fwereade: i think that's a reasonable thought, and i've thought about something similar myself
[18:23] <rogpeppe> fwereade: but i think it's orthogonal to what i'm doing currently
[18:24] <rogpeppe> fwereade: which enables that, trivially
[18:24] <fwereade> rogpeppe, agreed... maybe a suggestion for the lists, see if it draws popular support, if it does it should indeed be easy to build on top
[18:25] <rogpeppe> fwereade: yeah. actually, i don't think there needs to be a key per environment
[18:25] <rogpeppe> fwereade: i think one root key for all environments is just fine
[18:26] <rogpeppe> fwereade: so the command line tool could generate ~/.juju/rootcert.pem if it doesn't already exist
[18:27] <fwereade> rogpeppe, I dunno, I think one per environment is saner in a multi-admin situation
[18:27] <fwereade> rogpeppe, but I don't feel very strongly about it, haven't really thought it through
[18:27] <rogpeppe> fwereade: if you want one per environment, that's easy to do. but a single name space also makes sense, i think.
[18:28] <rogpeppe> fwereade: it means there's only one public key to distribute, for one
[18:28] <fwereade> rogpeppe, yeah, also sounds reasonable :)
[18:30] <rogpeppe> right, i can't launch into changing all this now; time to stop for the night, i think.
[18:30] <rogpeppe> a pint beckons
[18:31] <rogpeppe> fwereade: have a great weekend, see ya monday
[18:31] <rogpeppe> night all
[18:31] <fwereade> rogpeppe, have fun :)


[01:27] <gnomefreak> frigging firefox and printing sucks ass
[01:28] <gnomefreak> it skipped a while middle section that didnt fit on page one but didnt print on page 2 :(
[01:36] <asac> printing on trunk build?
[01:37] <asac> or standard`
[01:37] <asac> ?
[01:43] <gnomefreak> standrd
[01:43] <gnomefreak> standard even
[01:43] <gnomefreak> it built :)
[01:44] <gnomefreak> im gonna assume trunk has conflicts <=firefox-2.99....
[01:47] <gnomefreak> this is weird. i built trunk but not sure where the binaries are.
[01:48] <gnomefreak> gnomefreak@FeistyFawn:~/firefox-trunk-gnomefreak$ ls
[01:48] <gnomefreak> build-tree  firefox-2.99+1-3.0a.20070201.tar.bz2
[01:48] <gnomefreak> debian      firefox-2.99+1-3.0a.20070201.tar.bz2.cdbs-config_list
[01:48] <gnomefreak> build-tree and the cdbs-config_list are the only new files/dirs
[01:50] <gnomefreak> maybe i should build it with -b?
[02:01] <asac> you can install trunk in parallel
[02:01] <asac> yes
[02:02] <asac> this is all fine
[02:02] <asac> you should have .debs lying around
[02:02] <asac> in your home
[02:02] <asac> gnomefreak: ^^^
[02:03] <gnomefreak> oh home
[02:04] <asac> as always
[02:04] <gnomefreak> yes i do :)
[02:04] <asac> its in the directory above
[02:04] <asac> new firefox package just has a clean layout
[02:04] <gnomefreak> you can install trunk and standard?
[02:04] <asac> yes
[02:04] <gnomefreak> sweet
[02:04] <asac> you cannot run at the same time
[02:04] <asac> as they share profiles
[02:04] <asac> maybe i will change that at some points
[02:04] <gnomefreak> thats fine. how do i run one over the other?
[02:05] <asac> was not sure if you want too independent profiles or one
[02:05] <gnomefreak> one is fine
[02:05] <asac> you stop one and start the other
[02:05] <asac> should be in gnome menu
[02:05] <gnomefreak> oh cool
[02:05] <gnomefreak> ok let me reboot and ill attempt it
[02:05] <asac> already installed firefox-trunk_*deb ?
[02:08] <asac> already installed firefox-trunk_*deb ?
[02:09] <gnomefreak> no
[02:09] <gnomefreak> kernel update
[02:09] <gnomefreak> brb
[02:09] <asac> ah
[02:21] <gnomefreak> sweet i love it :)
[02:22] <asac> great :) ... so it works ;)
[02:22] <gnomefreak> you named it Gran Paradisco?
[02:22] <gnomefreak> yep works
[02:22] <asac> no ... thats the official unofficial branding
[02:22] <gnomefreak> ah
[02:22] <asac> e.g. random build: "Minefield"
[02:23] <asac> unofficial build (e.g. for beta/alpha: Gran Paradiso)
[02:23] <asac> will change after firefox 3 is out
[02:23] <asac> mozilla said it would be ok to use unofficial branding
[02:23] <gnomefreak> cool
[02:23] <gnomefreak> do you want me to host these so people dont have to build
[02:24] <asac> dunno ... you can if you want  :) ... at some points i will do something automated that builds packages for everything that is bzr hosted
[02:25] <gnomefreak> ok yeah ill do it for now :)
[02:25] <gnomefreak> for the team i think
[02:26] <asac> after feisty package will go to universe ... however i really would like to let team members become familiar with build packages
[02:26] <asac> and applying/testing/checkin-in patches
[02:26] <asac> so since building package is simple atm
[02:27] <asac> we can use that to get others started
[02:27] <gnomefreak> good point
[02:27] <asac> e.g. by providing easy docs
[02:27] <gnomefreak> that works
[02:27] <asac> instead of binary packages
[02:27] <gnomefreak> easy docs :(
[02:27] <asac> ;)
[02:27] <asac> just short instructions
[02:27] <asac> like:
[02:27] <asac> clone repo: blablabla
[02:27] <asac> build package: blablabla :)
[02:28] <asac> update upstream tarball: /this and that and those actions/
[02:28] <asac> i think that would be good enough so everybody can do it
[02:28] <gnomefreak> ok i like that idea
[02:28] <gnomefreak> fairly easy just time consuming
[02:28] <asac> to build?
[02:29] <gnomefreak> yeah
[02:29] <asac> should be a background thing :)
[02:29] <asac> everyday, do your daily build :)
[02:29] <gnomefreak> everyday?
[02:29] <asac> of course only when there are updates in repo
[02:29] <asac> :)
[02:29] <gnomefreak> ah
[02:29] <gnomefreak> ok
[02:30] <gnomefreak> just ping when they are ready :)
[02:30] <asac> thats why daily build :)
[02:30] <asac> try update ... if nothing ...no build
[02:30] <asac> otherwise build :)
[02:30] <asac> of course, this is rather optimal case :)
[02:30] <gnomefreak> how do i update? if its not in repos
[02:31] <gnomefreak> if its in bzr?
[02:31] <asac> you have bzr cloned
[02:31] <asac> in that you can just say
[02:32] <asac> hmm
[02:33] <asac> maybe just bzr merge
[02:33] <asac> what happens if you run that?
[02:33] <asac> please post output :)
[02:34] <gnomefreak> looks good
[02:34] <asac> how?
[02:34] <asac> no changes?
[02:34] <gnomefreak> gnomefreak@FeistyFawn:~/firefox-trunk-gnomefreak$ bzr merge
[02:34] <gnomefreak> Merging from remembered location http://bazaar.launchpad.net/~asac/firefox/trunk/
[02:34] <gnomefreak> Nothing to do.
[02:34] <asac> yes good
[02:34] <asac> thats fine
[02:34] <gnomefreak> you have to be cd'ed into the clone :)
[02:34] <asac> cool
[02:34] <asac> i haven't cloned, thats why i couldn't try :)
[02:35] <asac> yeah ... thats how you see that there are changes
[02:35] <asac> for now there will be changes regularaly
[02:35] <asac> in addition i will setup a similar package for 2.0.0 branch as soon as feisty is shaken out
[02:36] <asac> -trunk package is for the cool factor, while 2.0.0 branch will be used to test new things (e.g. in mozillateam maintained branch) ... and to release (e.g. in ubuntu-core-dev branch)
[02:37] <gnomefreak> asac: each update to bzr update have to rebuild?
[02:37] <asac> gnomefreak: its all voluntary :) ... you can decide on your own if you want to try :) ... anyway, if your question is if its worth to respin, then yes.
[02:37] <asac> I will usually only checkin things that are good for testing
[02:37] <asac> at least i try
[02:38] <gnomefreak> i mean to obtain latest build need to update bzr and respin
[02:38] <asac> yes
[02:38] <asac> its simple like that
[02:38] <gnomefreak> cool :)
[02:38] <asac> patching is done by patches in debian/patches
[02:38] <asac> by we use quilt, so you can easily edit things in built-tree/mozilla
[02:39] <asac> to test and update patches afterwards
[02:39] <asac> its pretty nice :) ... but i think you will only see if you do new patches.
[02:41] <asac> but you might see how minimalistic debian/rules now is
[02:41] <asac> compared to old one
[02:41] <gnomefreak> i will take a look at them in morning its getting late  for you too btw
[02:42] <asac> yes :)
[02:42] <asac> anyway, have all the time in the world :) ... just another milestone hanging over me :-P
[02:43] <asac> tomorrow i have to push security updates :)
[02:44] <asac> e.g. <IP_ADDRESS>
[02:44] <asac> sad that feisty has to wait till friday
[02:44] <asac> at least
[02:44] <gnomefreak> yeah
[02:44] <asac> ok night :)
[02:44] <gnomefreak> new kernel was updated today so they should be all go now
[02:44] <gnomefreak> night
[02:44] <asac> hopefully
[02:44] <asac> want final changes to land :)
[02:45] <gnomefreak> :) they will i hope soon
[02:45] <asac> yes ... but after beta :(
[02:45] <asac> but lets see how many crashes come out in beta
[02:45] <asac> lets hope that we all can retrace then
[02:46] <asac> ok bye
[03:17] <tonyyarusso> asac: waiting on a flippin' tarball...don't know where he went :S
[05:12] -ChanServ(ChanServ@services.)- You do not have channel operator access to [#ubuntu-boot]
[05:12] -ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
[05:12] -ChanServ(ChanServ@services.)- [#ubuntu-ops]  Welcome to #ubuntu-ops - Home of the operators for official K/X/Ed/Ubuntu channels. Questions, requests and complaints about Ubuntu related channels and their people can be filed here"
[10:29] <Admiral_Chicago> working on that ops I see...lol
[10:29] <Admiral_Chicago> time for me to go to bed...
[02:05] <hjmf> :D
[02:44] <gnomefreak> asac: didnt you make the changes to bug 91798 already? or are we waiting for <IP_ADDRESS>/4?
[02:44] <Ubugtu> Malone bug 91798 in firefox "Default Ubuntu home page concealed by Firefox welcome" [High,In progress]  https://launchpad.net/bugs/91798
[02:49] <asac> will be in <IP_ADDRESS>
[02:49] <gnomefreak> asac: also bug 94392
[02:49] <Ubugtu> Malone bug 94392 in firefox "Broken URL in /etc/firefox/firefoxrc" [Undecided,Needs info]  https://launchpad.net/bugs/94392
[03:06] <gnomefreak> asac: does deb http://ftp.us.debian.org/debian sid main look right for sid repos?
[03:07] <gnomefreak> trunk is borked :(
[03:10] <gnomefreak> asac: the google search in the tool bar doesnt work. seems like its missing the search engine totally
[03:16] <gnomefreak> fixed the repos but still search == borked
[03:22] <gnomefreak> (Sid)I have no name!@FeistyFawn:~$
[03:22] <gnomefreak> lol
[03:49] <joejaxx> gnomefreak: that looks right
[03:49] <joejaxx> gnomefreak: :)
[03:50] <gnomefreak> :) i fixed it but i though it was funny it said i have no name :)
[03:50] <joejaxx> :P
[03:54] <gnomefreak> i love this build but i want google to work :(
[03:55] <gnomefreak> joejaxx: you already made the changes to iceape 1.0.8 for fluxbuntu right?
[04:06] <asac> gnomefreak: you have to add a user
[04:06] <asac> in chroot
[04:06] <gnomefreak> i did :)
[04:06] <asac> same name as the one you use in main system
[04:06] <asac> :)
[04:06] <asac> ah
[04:06] <asac> bot reads top-down :)
[04:06] <gnomefreak> yep i skipped all that section by mistake
[04:06] <asac> changes for fluxbuntu?
[04:06] <gnomefreak> for iceape
[04:11] <asac> what kind are those?
[04:11] <gnomefreak> he was gonna customize it for it (home page, things like that)
[04:11] <asac> ah
[04:11] <asac> joejaxx: how will you do this?
[04:11] <asac> want to discuss?
[04:11] <gnomefreak> i have this strange feeling its not gonna be easy for me to do but willing to try
[04:11] <gnomefreak> yay martin got to my apport bugs i think
[04:11] <gnomefreak> well damn
[04:11] <gnomefreak> thats not helpfull at all
[04:12] <gnomefreak> <insert very very bad word here and screem it>
[04:13] <gnomefreak> anyone have a 32 bit fx crash i can borrow for a few?
[04:14] <gnomefreak> asac: see bug 89916 bug 91054 and bug 92739 let me know what you think about them. they are apport bugs
[04:14] <Ubugtu> Malone bug 89916 in apport "[Feisty] apport-retrace fails to retrace bugs." [Low,Needs info]  https://launchpad.net/bugs/89916
[04:14] <Ubugtu> Malone bug 91054 in firefox "[Feisty FireFox crashed [@gtk_style_realize] " [High,Needs info]  https://launchpad.net/bugs/91054
[04:15] <Ubugtu> Malone bug 92739 in apport "[apport]  apport-retrace crashed with error in unpack()" [Medium,Rejected]  https://launchpad.net/bugs/92739
[04:31] <asac> bug 91054 can be closed then
[04:31] <Ubugtu> Malone bug 91054 in firefox "[Feisty FireFox crashed [@gtk_style_realize] " [High,Needs info]  https://launchpad.net/bugs/91054
[04:31] <asac> dunno about last one
[04:57] <gnomefreak> looks like the newest apport in feisty is grabbing alot more -dbgsym than before. it used to only grab a couple <=6 its grabbing >17
[05:07] -ChanServ(ChanServ@services.)- You do not have channel operator access to [#ubuntu-boot]
[05:07] -ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
[05:07] -ChanServ(ChanServ@services.)- [#ubuntu-ops]  Welcome to #ubuntu-ops - Home of the operators for official K/X/Ed/Ubuntu channels. Questions, requests and complaints about Ubuntu related channels and their people can be filed here"
[05:11] <gnomefreak> asac: if you have a feisty report that needs a new retrace on 386 let me know i want to try this out. this bug its doing very very good
[05:18] <gnomefreak> thats weird. i get the dpkg error still but the report came out great. it looks like i will be doing feisty retraces again :)
[05:19] <asac> cool
[05:19] <asac> look at those that apport service did
[05:19] <asac> they are all messed up :)
[05:20] <gnomefreak> i will try. so far one report turned out good :)
[05:20] <gnomefreak> is there a way to search for those?
[05:35] <hjmf> gnomefreak: hi
[05:35] <hjmf> what command?
[05:35] <hjmf>  sed -n '/^Stacktrace:/,/^ThreadStacktrace:/ {s/^Stacktrace:/--- stack trace ---/;s/^ThreadStacktrace:/--- end of stack trace ---/g;p}' retraced.crash > retraced_Stacktrace.txt
[05:36] <hjmf> sed -n '/^ThreadStacktrace:/,$ {p}' retraced.crash > retraced_Thread_Stacktrace.txt
[05:36] <hjmf> ... or the one that uploads them back to launchpad?
[05:37] <hjmf> where retraced.crash is the output from apport-retrace
[05:38] <gnomefreak> ok that is way too much work per bug
[05:42] <hjmf> it is for the first bug, but not for the rest of them
[05:43] <hjmf> anyhow for edgy retraces apport-unpack works the same and generates separated Stacktrace and ThreadStacktrace files
[05:43] <gnomefreak> yeah i was thinking feisty
[05:44] <hjmf> ...ops, then for feistys
[05:44] <hjmf> sed -n '/^--- stack/,/--- thread/ {s/--- thread/--- end of/;p}' retrace.out > retraced_Stacktrace.txt
[05:44] <hjmf> sed -n '/^--- thread/,$ {p}' retrace.out > retraced_Thread_Stacktrace.txt
[05:44] <hjmf> ... it's what I use
[05:45] <hjmf> dirty but works
[05:56] <hjmf> gnomefreak: Ive already retraced bug #94812
[05:56] <Ubugtu> Malone bug 94812 in firefox "Firefox crash after attempt to install flash plugin (dup-of: 72018)" [High,Needs info]  https://launchpad.net/bugs/94812
[05:56] <Ubugtu> Malone bug 72018 in firefox "MASTER Firefox Crash [@gtk_style_realize]  [@nsFilePicker::Show] " [High,In progress]  https://launchpad.net/bugs/72018
[05:57] <gnomefreak> k
[05:57] <gnomefreak> i marked wrong bug i think
[05:58] <hjmf> k
[05:59] <gnomefreak> libgcc1-dbgsym libnspr4-dbgsym libnss3-dbgsym are the packages causing dpkg failure
[06:01] <hjmf> failure?
[06:01] <hjmf> ok
[06:02] <hjmf> ... have you seen my script
[06:02] <hjmf> it forces the installation of those packages
[06:02] <gnomefreak> yeah
[06:04] <gnomefreak> i using new apport atm sinc ei got a great report out of it and seeing if i can still
[06:05] <hjmf> k
[06:05] <hjmf> gnomefreak: ive assigned you bug #94797 for retrace
[06:05] <Ubugtu> Malone bug 94797 in firefox "broken package warning at start up" [High,Needs info]  https://launchpad.net/bugs/94797
[06:05] <gnomefreak> k
[06:05] <hjmf> the reporter has uploaded the crash report
[06:05] <gnomefreak> ty ill look at it
[06:07] <gnomefreak> should have edgy chroot set up today
[06:07] <hjmf> k
[06:46] <gnomefreak> hjmf: can you try to retrace bug 90175 please apport is just hanging not doing nothing
[06:46] <Ubugtu> Malone bug 90175 in xorg "vesa driver used instead of radeon for R300" [Undecided,Needs info]  https://launchpad.net/bugs/90175
[06:46] <gnomefreak> oops
[06:46] <gnomefreak> not that one
[06:46] <gnomefreak> nevermind
[06:54] <gnomefreak> wth is http://packages.ubuntu.com/feisty/python/python-launchpad-bugs
[06:56] <hjmf> its a cool library
[06:56] <AlexLatchford> finally have rebuilt my system
[06:56] <gnomefreak> click on that link it gives you 406
[06:57] <AlexLatchford> gnomefreak: http://www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu/pool/main/b/bughelper/python-launchpad-bugs_0.1.3_all.deb
[06:57] <AlexLatchford> if you want a cop
[07:13] <gnomefreak> i got it already ty though. on the link i gave you have to click one of the html links to get to it
[07:36] <gnomefreak> did everyone build thier firefox3.0 yet?
[07:36] <gnomefreak> :)
[07:41] <gnomefreak> what package includes less?
[07:44] <gnomefreak>  search bleh | less doesnt work but | more does
[07:49] <hjmf> less <- it has its own package
[07:49] <gnomefreak> ah ok
[08:05] <hjmf> Admiral_Chicago: I'm taking bug #91584 for retrace (was assigned to you)
[08:05] <Ubugtu> Malone bug 91584 in firefox "Crashed while opening an eBay link in a new tab" [Undecided,Needs info]  https://launchpad.net/bugs/91584
[08:07] <hjmf> ... done
[08:47] <joejaxx> gnomefreak: i did not :\
[08:48] <gnomefreak> yep i saw
[08:49] <gnomefreak> oops
[08:49] <gnomefreak> joejaxx: did not what?
[08:49] <gnomefreak> change ape?
[08:49] <joejaxx> i did not compile firefox 3.0 yet :P
[08:50] <gnomefreak> ah
[08:51] <gnomefreak> its in a branch and easy to do :)
[08:51] <joejaxx> where is the branch?
[08:51] <joejaxx> i would like to compile it :)
[08:51] <gnomefreak> best part it adds its own menu entry so you can run both not at same time though
[08:51] <gnomefreak> joejaxx: /topic :)
[08:52] <joejaxx> ohh :) lol
[08:52] <gnomefreak> i have instructions on cloning it and building it just havent paged it yet
[08:52] <joejaxx> oh ok
[08:53] <joejaxx> hmm
[08:55] <joejaxx> gnomefreak: it says it is not a branch
[08:55] <gnomefreak> bzr clone http://bazaar.launchpad.net/~asac/firefox/trunk firefox-trunk-gnomefreak  *** To clone BZR branch ***  *HINT* replace gnomefreak with your info
[08:55] <gnomefreak> i just did this last night it better still be a branch
[08:56] <joejaxx> ah
[08:56] <joejaxx> bazaar.lp.net
[08:57] <joejaxx> the topic says code.lp.net
[08:57] <gnomefreak> oh we can fix that in a bit
[08:57] <joejaxx> ok
[08:57] <joejaxx> :)
[09:04] <gnomefreak> than jsut cd into firefox-trunk-* and build it with dpkg-buildpackage :)
[09:06] <gnomefreak> asac: when you get back ping me. pitti asked us to make apport hook on flash.
[09:36] <gnomefreak> hjmf: are you still around?
[09:36] <gnomefreak> oh wait nevermind i think i know what i can do
[09:36] <joejaxx> ok build time
[09:36] <joejaxx> :)
[09:37] <hjmf> gnomefreak: yes?
[09:38] <gnomefreak> i was gonna ask wher eyou got the apport packages but apport-gtk wont help me anyway
[09:39] <hjmf> http://mirror.linux.org.mt/mirror/ubuntu/pool/ its a mirror that stores several version of each package
[09:39] <gnomefreak> ty
[09:40] <hjmf> I'll be afk for a while
[11:08] <joejaxx> gnomefreak: how much space is required to build firefox?