[00:15] <hatch> huwshimi ready for a final review/qa on #95?
[00:15] <huwshimi> hatch: That'd be great!
[00:16] <hatch> ok I'm going to take a little break then I'll get on it
[00:17] <huwshimi> hatch: Thankyou!
[00:21] <hatch> huwshimi trivial typo on the code review....ok now I'm really going to take a break before qa :)
[00:28] <huwshimi> hatch: "typeo: maximized" hilarious.
[00:33] <hatch> haha :)
[01:33] <gary_poster> https://github.com/juju/juju-gui/pull/101 ready for review, and now I run :-)
[01:57] <hatch> huwshimi fyi we use a z instead of s in maximized :)
[02:00] <huwshimi> hatch: Do we?
[02:01] <hatch> huwshimi I don't know what version of English we use :)
[02:02] <huwshimi> hatch: Well, our writing style guides are for British English (we're a British company). Not sure if we have additional rules for our code comments.
[02:03] <hatch> qa ok!
[02:04] <hatch> huwshimi before you merge it in can you rebase it?
[02:05] <huwshimi> Sure!
[10:11] <frankban> morning hazmat: re: bug 1252301 do you already have a plan, can I help in some way?
[10:11] <_mup_> Bug #1252301: guiserver reports second bundle as failing after the first fails <juju-deployer:New> <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1252301>
[11:23] <hazmat> frankban, i'm at sprint and then on vacation till roughly feb 17th, and then multi-tasking for partner/customer deadlines.
[11:23] <hazmat> frankban, if you have time that would be great.. the simple thing is just to have wait for units  methods, take flag, and pass the flag in via config.. i think.. i haven't thought about it while looking at the code.
[11:25] <frankban> hazmat: ack. there is already an ignore_error flag passed to that function
[11:25] <frankban> hazmat: I'll take a better look at it
[11:27] <hazmat> frankban, thanks
[13:17] <gary_poster> frankban: +1 on GUI login text PR 103
[13:26] <frankban> gary_poster: thanks!
[13:30] <gary_poster> rick_h_: qa bad on your demo icon branch.  To see problem, go to https://manage.jujucharms.com/api/3/charm/~web-brandon/precise/my-site-1/file/icon.svg?demo=true .  Maybe "demo" is not the expected name in charmworld for this functionality?
[13:30] <gary_poster> welcome
[13:38] <bac> hi benji, would you have a moment for some makefile advice?
[13:38] <benji> bac: sure
[13:42] <hatch> gary_poster can we cancel the merge of huws branch or is it too late? It wasn't rebased
[13:43] <gary_poster> hatch, I don't know how, sorry
[13:43]  * gary_poster kinda hates the rebase thing.
[13:43]  * gary_poster kinda thinks bzr shoulda won
[13:43] <hatch> yeah I don't know how to cancel it either :) without the rebase bisecting is kind of a pita of unfortunately....having a bunch of broken commits
[13:44] <hatch> yeah this part bzr clearly wins
[13:44] <gary_poster> hatch I think I might have canceled it
[13:45] <rick_h_> gary_poster: bah, sorry. I assumed charmworld would ignore it. I tried to work on the charmworld side of the branch but the ppa's for charmworld aren't available for trusty
[13:47] <gary_poster> hatch: ok it is cancelled,pretty sure.  I aborted build
[13:47] <gary_poster> hatch one of us should do the rebase
[13:47] <gary_poster> hatch I can try to delete it later
[13:47] <gary_poster> I mean rebase it :-P which may mean deleting huw's PR
[13:48] <gary_poster> (closing)
[13:48] <gary_poster> rick_h_: np.
[13:48] <rick_h_> gary_poster: will leave that on hold for the moment and will try to get an older release lxc setup to update charmworld first then
[13:49] <rick_h_> gary_poster: thanks for the review/qa catch
[13:49] <gary_poster> cool rick_h_ .  OTOH If you want to land it with a "it's feature-flagged" approach that's fine with me too
[13:49] <rick_h_> gary_poster: will see what time I get. If it'll be a bit I'll add a FF on it
[13:49] <hatch> I wonder if we can write an intelligent rebase script so it could act like bzr
[13:50] <rick_h_> maybe should anyway since in order to land it would need a charmworld release :/ good call
[13:50] <gary_poster> rick_h_: IMO it is already "feature flagged": you have to opt in on the console
[13:50] <rick_h_> gary_poster: oh yea even better :)
[13:51] <rick_h_> hatch: ugh yea. I need to see if I can update the process to handle this. What we need is a clear process for "update from develop" that doesn't break the feature branch history like it does now
[13:51] <rick_h_> hatch: if you get a chance, I wonder if we could add a "how to sync with trunk" that's testing out using git rebase develop vs git merge/pull develop
[13:51] <rick_h_> hatch: and if that helps out
[13:52] <hatch> yeah...I'm just wondering why rebasing merges into your commits shows up in the diffs
[13:52] <hatch> that stuff 'should' already be in develop so why is it considering it 'new'
[13:52] <gary_poster> rick_h_: gave a +1 to the branch with that understanding.  Onlty had small text suggestion
[13:52] <rick_h_> hatch: I think that's the diff between merge/pull/rebase. You can sync all three ways but they each act different and need to think through it
[13:52] <rick_h_> gary_poster: rgr, will update it.
[13:53] <hatch> I wonder what others do, I can't imagine that this isn't a asolved problem
[13:53] <hatch> people can't have a ton of broken commits in their trunk
[13:53] <hatch> ....well....shouldn't :)
[13:54] <hatch> gary_poster did you see that your font branch failed CI?
[13:55] <gary_poster> hatch, yeah thanks.  Weird: it failed on IE in sandbox.PyJujuAPI tests!
[13:55] <gary_poster> No idea why.
[13:55] <hatch> ok that's odd
[13:55] <gary_poster> Want to try and dupe locally
[13:56] <rick_h_> there is a transiet error that happens in CI very rarely
[13:56] <gary_poster> oh!  was wondering about that
[13:56] <rick_h_> gary_poster: if it's a really odd error I'd try to run it again
[13:56]  * rick_h_ goes to find the branch/build
[13:57] <gary_poster> https://github.com/juju/juju-gui/pull/101
[13:58] <gary_poster> rick_h_: ^^^ is there a way to trigger a build without pushing another branch?
[14:00] <hatch> delete the message from CI
[14:00] <hatch> the 'status: merge request accepted' one
[14:00] <hatch> then it'll re-run
[14:00] <gary_poster> hatch, no this is the initial run
[14:01] <hatch> oh woops, sorry no idea
[14:03] <frankban> gary_poster: starting the process to release the GUI charm if you agree
[14:04] <gary_poster> frankban: +1 thank you
[14:12] <rick_h_> gary_poster: yes, got pulled away https://github.com/juju/juju-gui/blob/develop/docs/continuous-integration.rst#manually-running-a-build
[14:13] <gary_poster> perfect thanks rick_h_
[14:26] <rick_h_> gary_poster: so http://ci.jujugui.org:8080/job/juju-gui/327/ looks like it went ok?
[14:26] <rick_h_> not sure why it didn't trigger a pass in github
[14:27] <gary_poster> cool, and awesome! thanks rick_h_.  Tweaking branch now.  Gives me rebase practice. :-)
[14:28] <rick_h_> gary_poster: cool
[14:42] <hatch> gary_poster was the test failure the long line?
[14:42] <hatch> or was that just a driveby
[14:42] <gary_poster> hatch, no, that was a driveby
[14:43] <gary_poster> hatch, the next test run passed without changes
[14:43] <hatch> oh :)
[14:43] <rick_h_> yea, it's a really odd and rare failure. I guess I should file a bug on it. Only hit it a couple of times
[14:43]  * hatch sings blame rick_h_  to the tune of 'Blame Canada' from South Park
[14:43] <rick_h_> but it does happen
[14:43] <gary_poster> lol
[14:43] <rick_h_> :P
[14:43] <gary_poster> I don't think rick_h_ can take any blame for those tests
[14:44] <hatch> maybe not, but it can be assigned
[14:44] <hatch> :P
[14:44] <rick_h_> hatch: I just got out of a meeting with Mark S and he wants you to build Jaas by yourself by the end of the month. GO! :P
[14:44] <gary_poster> :-)
[14:44] <gary_poster> heh
[14:44] <hatch> rick_h_ lol, wouldn't be the craziest request I've gotten haha
[14:44] <gary_poster> We won't tell you what it is, but if you get it wrong, you're fired ;-)
[14:45] <hatch> hahaha
[14:45] <hatch> that's pretty close to some of the requests I've received
[14:45] <benji> one month of paid job-hunting; sounds like a good deal to me a
[14:45] <hatch> "can you build us an app for our startup....but we can't tell you what we do now..."
[14:45] <gary_poster> heh
[14:46] <hatch> benji lol
[14:46] <benji> gary_poster: AWS expenses incoming
[14:46] <gary_poster> cool benji, I'll catch 'em
[14:47] <hatch> juju-core can be up/downgraded nicely
[14:47] <gary_poster> done.
[14:47] <hatch> at least it appears to not be barfing all over the place
[14:48] <hatch> seems to be considerably slower though....
[14:50] <hatch> I just enjoy using the GUI when using Juju....guess that means we did a good job :)
[14:51] <gary_poster> :-)
[14:51] <gary_poster> +1
[14:53] <gary_poster> you know...
[14:53] <gary_poster> if you look at the jenkins test console (http://ci.jujugui.org:8080/job/juju-gui/331/console)...
[14:53] <gary_poster> a *lot* of the time is spent on 304 requests
[14:54] <gary_poster> a *whole bunch*
[14:55] <hatch> you bet
[14:55] <hatch> rick_h_ and I have both been wanting to write a cache layer for those json requests
[14:55] <gary_poster> cache headers would be dagerous
[14:55] <gary_poster> it's no just json fwiw
[14:55] <gary_poster> svg and yaml too
[14:55] <hatch> I was thinking something in the app
[14:55] <rick_h_> gary_poster: right, but all of those are through the "loadxxx" helper that needs to just send back the data
[14:56] <hatch> yeah that
[14:56] <gary_poster> so the app itself would cache?
[14:56] <gary_poster> in a util?
[14:56] <rick_h_> so it's just a matter of faking the cache in the test util helper
[14:56] <rick_h_> no the app, it's in the tests only
[14:56] <hatch> 'just' famous last words lol
[14:56] <gary_poster> that might be an 80/20, yeah
[14:56] <rick_h_> hatch: :P come on. It's easy. You could do it in an hour.
[14:57] <gary_poster> heh
[14:57] <hatch> rick_h_ lol shush
[14:57]  * rick_h_ downloads hatch's ghost zip
[14:57] <gary_poster> ok hatch or someone else in jujugui, https://github.com/juju/juju-gui/pull/104 has passing tests and is ready for review (hopefully easy) and qa (more annoying)
[14:58]  * hatch needs someone to actually use the ghost charm so I can get motivated to keep working on it
[14:58] <gary_poster> do demos count? ;-)
[14:58] <hatch> haha, well it works for demos now. 'lowest viable product' :P
[14:58] <gary_poster> :-)
[15:01] <rick_h_> hatch: Failed to load resource: the server responded with a status of 405 (Method Not Allowed)
[15:01] <rick_h_> :(
[15:01] <hatch> rick_h_ are you using the latest charm and juju 1.17.1+
[15:01] <rick_h_> 1.17.3-trusty-amd64
[15:01] <rick_h_> cs:precise/juju-gui-82
[15:02] <rick_h_> I got juju from trunk with the go get juju...
[15:02] <rick_h_> and I changed the juju-gui-source to the develop branch
[15:02] <rick_h_> in the charm
[15:03] <hatch> hmm something is messed up with charmworld.....juju-gui latest is revno 83, but it's deploying 82
[15:04] <frankban> hatch: cs:precise/juju-gui-82 is revno 83
[15:04] <hatch> ohh ok, so then it 'should' be working
[15:04] <hatch> frankban I thought the numbers on the end matched the revno
[15:04] <hatch> :)
[15:05] <hatch> rick_h_ can you view the guiserver logs in the charm?
[15:05] <rick_h_> hatch: looking
[15:05] <frankban> hatch: I used to know the meaning of the number after the last dash, but I keep forgetting that and I ended up just considering it an obscure auto-incrementing mystical number
[15:06] <hatch> haha sounds good
[15:07] <rick_h_> hatch: which log? nothing in /var/log/juju/juju-gui.log
[15:08] <hatch> guiserver.log
[15:08] <hatch> it's in...
[15:08] <hatch>  /var/log/upstart
[15:08] <rick_h_> ah right uin upstart
[15:08] <hatch> yeah this is the actual 'server' logs
[15:08] <rick_h_> [W 140204 15:07:13 web:1635] 405 POST /juju-core/charms?series=precise (<IP_ADDRESS>) 7.48ms
[15:09] <hatch> that's it hey?
[15:09] <hatch> frankban any ideas?
[15:09] <rick_h_> yep
[15:09] <rick_h_> all I get in there
[15:10] <hatch> frankban 83 supports the local charm stuff right?
[15:12] <rick_h_> gary_poster: bac comingsoon has a merge conflict issue
[15:12] <bac> rick_h_: ok
[15:12] <frankban> jujugui: https://jujucharms.com/sidebar/search/bundle/~abentley/wiki-bundle/1/wiki/?text=bundle#bws-code is an official bundle that we cannot deploy. since the bundle includes local charms (those with "branch:") the fake backend fails. this is related to bug 1276107 , but I didn't know those kind of bundles were exposed in the GUI
[15:12] <_mup_> Bug #1276107: gui fails to deploy a bundle due to "Invalid charm id: undefined" <juju-gui:Incomplete> <https://launchpad.net/bugs/1276107>
[15:12] <bac> rick_h_: will check it out
[15:12] <frankban> hatch: revno 83 does not
[15:12] <hatch> rick_h_ doesn't look like the 83 supports it
[15:12] <gary_poster> thanks bac
[15:12] <hatch> sorry
[15:12] <rick_h_> frankban: so that is an old old bundle that sohuld be deprecated and removed
[15:12] <hatch> https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk
[15:13] <rick_h_> frankban: as we update the rules and proof we don't go back and clear old things out
[15:13] <rick_h_> frankban: maybe we should do that
[15:13] <frankban> hatch: I am in the middle of the charm release. hopefully the new charm with putcharm enabled will be released in 30 mins
[15:13] <rick_h_> hatch: oh sorry, thought it as there
[15:13] <rick_h_> frankban: ah ok cool. I'll retry setting up the demo later tonight then
[15:13] <gary_poster> rick_h_: was using local charms for demo
[15:13] <rick_h_> thanks for the heads up
[15:14] <rick_h_> yea, it's friday. I got the juju-core part working so that's a good bit. If the charm gets updated then should be all ready for the demo well in time
[15:14] <frankban> rick_h_: I'll ping everyone once the charm is released
[15:14] <rick_h_> frankban: ty
[15:14] <gary_poster> rick_h_: re frankban's comment about the failing bundle, any ideas how that made it through proof?
[15:14] <rick_h_> gary_poster: it was pre-proof checking things
[15:14] <gary_poster> rick_h_: I thought we had a re-import though
[15:15] <rick_h_> it's one of the first bundles we ever put in to test/prove charmworld could test them.
[15:15] <rick_h_> I think it goes into an error state, and we don't repull it but I don't think we clear it out. Am I mistaken on that bac ?
[15:15] <rick_h_> gary_poster: in theory we're treating it like a bad revision if I recall correctly.
[15:16] <frankban> rick_h_: unfortunately that's also the first bundle result if you search for "bundle" on the side bar
[15:16] <gary_poster> :-(
[15:16] <rick_h_> frankban: hah, ok. We should yank it. Maybe benji can try out his charm remover on the bundle?
[15:16] <gary_poster> yeah was thinking the same thing
[15:17] <hatch> hulk smash!
[15:17] <bac> rick_h_: comingsoon should be happier.
[15:17] <rick_h_> bac: thanks
[15:18]  * rick_h_ puts a note to look at adding a monitoring thing on our azure account. See if we can get a notice if it fails to load
[15:18] <bac> jujugui: remember to QA on coming soon if you muck with config.js  (but we always forget)
[15:18] <abentley> I'm happy to delete the branch if you want.
[15:19] <gary_poster> ah I have one of those comingsoon config fun things coming up too, maybe
[15:20] <bac> gary_poster: do more better!
[15:20] <gary_poster> thanks abentley.  That sounds like a good idea to me.  We still need to delete it in charmworld.
[15:20] <gary_poster> :-)
[15:21] <gary_poster> hatch you looking at https://github.com/juju/juju-gui/pull/104 or planning to, or should I beg someone else?
[15:22] <abentley> gary_poster: btw, the URL after "bzr branch" is a bit weird.  You never need /files after a Launchpad branch URL.
[15:31] <gary_poster> thanks abentley, yes.  Fixed in trunk (http://comingsoon.jujucharms.com/sidebar/search/bundle/~abentley/wiki-bundle/1/wiki/?text=bundle#code) and even in recent GUI releases.  jujucharms hasn't had an update because we are blocked on switching to juju core.
[15:31] <abentley> gary_poster: cool.
[15:32] <gary_poster> http://comingsoon.jujucharms.com/~dweaver/complex-webapp-and-management-bundle/8/complex-webapp/ could look better :-/
[15:32] <gary_poster> sorry
[15:32] <gary_poster> correct link:
[15:32] <gary_poster> http://comingsoon.jujucharms.com/sidebar/bundle/~dweaver/complex-webapp-and-management-bundle/8/complex-webapp/
[15:34] <hatch> gary_poster yeah I'll be looking at it
[15:34] <gary_poster> thank you
[15:34] <hatch> my env is a little messed up right now because of testing for old juju versions and the like
[15:34] <gary_poster> gotcha
[15:39] <hatch> jujugui do we know the version of juju in the GUI now? I remember hearing some discussion on the matter but wasn't sure the outcome
[15:40] <frankban> hatch: no we don't
[15:40] <hatch> ooooo kaaaayyyyyy
[15:40] <hatch> little unfortunate
[15:41] <frankban> hatch: what do you need that for?
[15:41] <hatch> frankban when the user tries to upload a charm and it's not supported I was going to say "Your version of Juju ({version}) does not support local charm uploads, please use at least 1.18.0"
[15:41] <hatch> so I'll just drop out their version for now
[15:43] <frankban> hatch: ack not too bad
[15:44] <hatch> nope
[15:50] <gary_poster> jujugui call in 10
[15:52] <benji> hatch: I can't reproduce bug 1271986
[15:52] <_mup_> Bug #1271986: Destroying service leaves inspector open <juju-gui:Triaged> <https://launchpad.net/bugs/1271986>
[15:52] <hatch> benji looking
[15:52] <hatch> benji it was intermittent
[15:52] <hatch> maybe try a couple times?
[15:53] <benji> hatch: I did.  I'll try some more.  How long were you letting it be in pending before destroying it?
[15:53] <hatch> benji 30s or so I think
[15:53] <benji> k
[15:53] <hatch> frankban the error returned from the charm when trying to use local charm upload is:
[15:54] <hatch> Internal server error:
[15:54] <hatch> error fetching data from https://<IP_ADDRESS>:17070/charms?series=precise: HTTP 599: Unknown
[15:54] <hatch> do we want to expose that url?
[15:55] <frankban> hatch: is this the error with old juju-core versions?
[15:55] <hatch> frankban yes, the ~juju-gui charm and juju 1.16.x
[15:56] <hatch> it should really be returning a 405 imho instead of a 500
[15:56] <hatch> shall I file a bug on the charm?
[15:58] <bac> jujugui call in 1?  2?
[15:58] <gary_poster> jujugui cvall in 2
[15:59]  * gary_poster has a broken clock on Ubuntu :-P
[15:59] <bac> ha, i beat you and spelled it right!  :)
[15:59] <gary_poster> heh
[16:28]  * gary_poster tries restarting Ubuntu after a software update to see if he gets his clock & cal back
[16:31] <gary_poster> Makyo: fwiw, software update + reboot = clock.  yay!
[16:32] <gary_poster> 'course, now chrome crashes :-/
[16:36] <hatch> price of using beta software I suppose :(
[16:37] <frankban> gary_poster, rick_h_: gui sandbox mode is broken (my putcharm branch introduced an error in the GUI server when here is no API URL). made an urgent card and starting to work on the (easy) fix. this will delay the charm release to tomorrow, is that a problem? (anyway: yay functional tests!)
[16:37] <gary_poster> frankban: :-) no problem IMO
[16:38] <frankban> cool
[16:46] <hatch> jujugui lf a review and qa https://github.com/juju/juju-gui/pull/105 plz and thanks
[16:47] <gary_poster> hatch, on it
[16:48] <hatch> thanks
[16:48] <hatch> and now I can do the qa on your branch
[17:02] <hatch> jujugui can someone on Ubuntu check if the drag and drop works in Firefox?
[17:02] <hatch> It's not working in OSX Firefox
[17:04] <frankban> hatch: drag'n'drop of what?
[17:04] <hatch> the charms/bundles
[17:04] <frankban> local charms?
[17:04] <hatch> sorry
[17:04] <hatch> from the browser
[17:04] <frankban> hatch: oh, from the sidebar
[17:05] <hatch> yeah
[17:05] <gary_poster> hatch, qa bad.  I'm using 1.16.5-saucy-amd64 .  I have two problems.  First, e.target.responseText is simply 'badMessage'.  You try to parse that as JSON (line 152 of local-charm-import-helpers) and the JSON parser is unhappy and falls over.  Second, even if that were fixed, the server responds with a status of 405 (Method Not Allowed) not 500 or 599 or anything else.  That second one wuld be solved easily by
[17:05] <gary_poster> reporting an error when the status >= 400, as I suggested already in the review.
[17:05] <hatch> gary_poster are you using the ~juju-gui charm?
[17:05] <gary_poster> hatch yes
[17:05] <gary_poster> trunk
[17:05] <hatch> weird...it returns 500 for me
[17:05] <hatch> hmm
[17:06] <frankban> hatch: dragging charms from the jujucharms.com sidebar works for me using ff
[17:06] <hatch> ok must be OSX only FF
[17:06] <gary_poster> :-/
[17:07] <gary_poster> hatch do you want any more info from me on the qa?  hangout?
[17:07] <gary_poster> whatever helps
[17:08] <hatch> well no I'm going to have to switch back and deploy a new env and give it another go
[17:08] <gary_poster> ok
[17:09] <frankban> hatch: I confirm charms drag and drop is broken on OSX Firefox
[17:09] <hatch> gary_poster juju-gui-103 is the charm that's deployed?
[17:10] <gary_poster> hatch, no, charm trunk--the charm Francesco is releasing now.
[17:11] <hatch> hmm I thought that's what I was running...ok tearing down and starting a new env
[17:12] <frankban> hatch: trunk is cs:~juju-gui/precise/juju-gui-151
[17:12] <hatch> oh shoot I'm working on frankban's branch
[17:12] <hatch> ....
[17:13] <hatch> WELL THEN!
[17:13] <gary_poster> :-)
[17:13] <gary_poster> Yay QA? :-)
[17:13] <hatch> well it takes considerably longer to be able to test than to actually write the code hah
[17:14] <gary_poster> hatch, pretty fast if you use a local charm, a local environment, and a release created via `BRANCH_IS_GOOD=1 make distfile`, as I keep saying
[17:14] <hatch> oh right, but I had already spun up another env on 1.17.2
[17:15] <hatch> bzr may do rebase nicely but man does it not do lightweight checkouts well
[17:38]  * gary_poster lunches
[17:38] <hatch> gary_poster I can't get anything other than a 500 :/
[17:39] <hatch> juju status shows juju-gui-104 charm as deployed
[17:39] <hatch> which was a fresh trunk checkout
[17:41] <hatch> bzr revno is 159
[17:42] <frankban> gary_poster: when you have time could you please take a look at https://codereview.appspot.com/57690051 ? no rush and thanks!
[17:52] <Makyo> hatch, gary_poster re: huw's branch. I rebased and pushed to a branch on my fork.  Want me to use the merge tool (create a PR with my branch, immediately :shipit:) or manually merge huw's branch into develop (will mean having a non-jujugui user in merge history)
[17:57] <Makyo> ^^^ + anyone else who cares (jujugui)
[17:58] <hatch> Makyo I'd probably prefer to use the CI system
[17:58] <bac> Makyo: doing the latter will give huw credit.  i'd go that route, even if he isn't in jujugui
[17:58] <bac> so, flip a coin!
[17:58] <hatch> haha
[17:59] <Makyo> bac, I think it'll give me credit, actually, since the push will come from my user.
[17:59] <bac> Makyo: then go CI
[17:59] <Makyo> Though the rebased commit is in his name.
[17:59] <Makyo> Okay.
[17:59] <Makyo> Bit of email spam coming up, then.  Disregard!
[18:14] <hatch> gary_poster here is the output from the guiserver.log file when I try and upload a charm https://gist.github.com/hatched/69720b483da125bf951c does yours look similar but with a 405?
[18:18] <gary_poster> hatch,
[18:18] <gary_poster> [W 140204 16:59:11 web:1635] 405 POST /juju-core/charms?series=precise (<IP_ADDRESS>
[18:18] <gary_poster> ) 97.51ms
[18:18] <hatch> that's the error you get with an old version of the charm....are you SUUUUUUURE you're not using an old one? :)
[18:19] <gary_poster> hatch,
[18:19] <gary_poster> gary@gud:~/dev/guicharm/trunk$ bzr revno
[18:19] <gary_poster> 159
[18:19] <hatch> well now I'm right confused
[18:19] <hatch> and juju status shows juju-gui-104?
[18:19] <gary_poster> and from bzr info:
[18:19] <gary_poster> parent branch: bzr+ssh://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/
[18:20] <gary_poster> from juju status:
[18:20] <gary_poster> charm: local:precise/juju-gui-104
[18:20] <hatch> so somehow we are running the same code but getting two different responses from the server
[18:21] <hatch> hmm
[18:21] <hatch> 1.16.5-precise-amd64
[18:21] <hatch> yup we are running all of the same code
[18:21] <hatch> and getting two different results
[18:21] <gary_poster> no we are not
[18:21] <gary_poster> 1.16.5-saucy-amd64
[18:21] <gary_poster> should not make a diff
[18:22] <gary_poster> but that's the only one we see so far
[18:22] <hatch> see the issue with your log is that it doesn't show that it's trying to make a request to Juju
[18:22] <hatch> if you use an old charm that's the same response
[18:22]  * hatch puts thinking cap on
[18:23] <gary_poster> I can redo everything with you on screenshare?
[18:23] <hatch> well it's not like I don't believe you haha
[18:24] <gary_poster> sure, but maybe I'm forgetting something or you will think of something else to check
[18:24] <gary_poster> hatch I have this as first line of my guiserver.log:
[18:24] <gary_poster> [I 140204 16:56:51 manage:144] starting Juju GUI server v0.3.0
[18:24] <gary_poster> 0.3.0 old?
[18:25] <hatch> yeah we can give it a try
[18:25] <hatch> umm checking mine
[18:25] <hatch> ^[[32m[I 140204 17:34:06 manage:144]^[[0;10m starting Juju GUI server v0.3.0
[18:25] <gary_poster> :-/
[18:25] <hatch> so same
[18:26] <gary_poster> hatch did you deploy with make deploy?
[18:27] <hatch> I did it the old fashioned way now to make sure it's all good
[18:27] <hatch> https://plus.google.com/hangouts/_/72cpibkk7s99ntjs8svf322nk4?authuser=1&hl=en
[18:27] <hatch> ^ gary_poster
[18:50] <hatch> this doesn't really effect us much but there has been a huge improvement to the loaders resolve speed https://github.com/yui/yui3/pull/1606
[18:51] <gary_poster> so, startup time?
[18:51] <hatch> nah we don't use the loader at all in our client side app
[18:51] <gary_poster> ah right
[18:51] <hatch> the only thing this could speed up is the resolving of the 'make' step
[18:51] <hatch> the funny thing is that the loader totally breaks the speedy improvements
[18:52] <hatch> :)
[18:52] <gary_poster> why does it break the speedy improvements?
[18:53] <hatch> because it rolls everything up into only a few requests whereas with speedy those requests should be determined by the server and it's the servers job to send the data down the available pipes
[18:53] <hatch> so instead of only 3 requests, speedy could open 8
[18:53] <hatch> and actually make it faster
[18:54] <hatch> the issue of course is that someone needs to write a speedy capable yui server
[18:54] <gary_poster> ah
[18:54] <gary_poster> I see
[18:55] <hatch> I don't totally understand all of speedy but in theory it should make the web way faster for web sites
[19:01] <hatch> gary_poster I totally blew everything away, and I still get a 500
[19:01] <hatch> *sigh* haha
[19:02] <gary_poster> hatch <shrug> try a saucy vm? :-)
[19:03] <hatch> the issue now is trying to determine what the error message should say
[19:04] <hatch> if status == 405 or 500:
[19:04] <hatch> hah
[19:04] <gary_poster> >= 400!
[19:04] <gary_poster> IMO
[19:04] <hatch> right but then I have to put a try catch around the json parse
[19:04] <hatch> and I don't like those.....for no reason
[19:04] <gary_poster> :-)
[19:05] <hatch> I'm spinning up an instance to qa your branch btw
[19:05] <gary_poster> cool ty
[19:06] <hatch> so far all osx browsers are good, just trying with ie now
[19:11] <gary_poster> cool
[19:39] <gary_poster> bac, juju-gui trying to do comingsoon surgery
[19:39] <gary_poster> in prep for my config change coming down the pike
[19:39] <gary_poster> and while I'm at it
[19:39] <bac> gary_poster: ok
[19:40] <gary_poster> juju-gui you may want to make clean next time after you `git pull juju develop`
[19:40] <bac> gary_poster: the branch we're using is now juju-gui (again)
[19:40] <gary_poster> bac you mean /opt/uistage/juju-gui?
[19:40] <bac> gary_poster: you may want to get rid of the others since they are no long needed
[19:40] <bac> gary_poster: yes
[19:40] <gary_poster> ok thanks
[19:40] <gary_poster> git stash is not working
[19:40] <gary_poster> going to try and be more manual about it
[19:40] <bac> gary_poster: really?
[19:41] <gary_poster> bac http://pastebin.ubuntu.com/6874821/
[19:42] <bac> gary_poster: oh.  is that a by-product of the conflicts?  or i wonder if it hasn't been working for a while
[19:42] <gary_poster> ah no I think it was a git add?
[19:43] <gary_poster> yeagh
[19:43] <gary_poster> I just had to `git reset HEAD app/config-prod.js`
[19:44] <gary_poster> that kept the changes but moved them out of staging
[19:44] <gary_poster> then I could stash
[19:44] <bac> abentley: do you have management permission on the ~ce-orangesquad/experimental PPA?  if so, could you make elasticsearch-java to build for trusty?
[19:44] <gary_poster> pull
[19:44] <gary_poster> and pop
[19:44] <gary_poster> ^^ bac
[19:44] <bac> s/to build/build/
[19:44] <bac> pull and poop
[19:45] <gary_poster> :-)
[19:46] <gary_poster> bac, comingsoon surgery complete.  patient apparently in recovery.
[19:47] <bac> for now.  relapse predicted.
[19:47] <gary_poster> too true
[19:47] <bac> gary_poster: so did the script change or did you just do it by hand and all is well again?
[19:48] <gary_poster> bac, what script, he said nervously?
[19:48] <gary_poster> I did it by hand
[19:48] <bac> gary_poster: is abentley in SA?
[19:48] <bac> gary_poster: uistage/bin/update...
[19:48] <gary_poster> I don't think aaron is in SA, no
[19:49] <bac> jcsackett: you around?
[19:49] <jcsackett> bac: yup.
[19:49] <bac> jcsackett: do you have management permission on the ~ce-orangesquad/experimental PPA?  if so, could you make elasticsearch-java build for trusty?
[19:50] <gary_poster> bac, did not use script, and I don't think a change is necessary as long as no-one `git add`s the config-prod changes
[19:50] <bac> jcsackett: i've been using the saucy PPA on trusty for a while so there is no source change
[19:50] <bac> gary_poster: ok, so the next run of cron with the next commit should work
[19:50] <jcsackett> bac: i think i have permission. one sec.
[19:50] <gary_poster> I believe that to be true
[19:50] <bac> gary_poster: i didn't 'git add' the config change if that's what you suspect.
[19:50] <bac> i just edited out the conflicts
[19:51] <gary_poster> bac, no idea, it just...was/
[19:51] <bac> perhaps we did the last time it blew up...
[20:04] <abentley> bac: Not in SA, just late lunching.
[20:04] <bac> abentley: cool.  turns out i'm a member of ce-orange and didn't know it.
[20:05] <abentley> bac: Heh.
[20:10] <hatch> gary_poster I'm just running the tests for my branch locally again, would you be able to test it on your machine because clearly mine is broken :)
[20:10] <hatch> I should have it pushed up in a minute or so
[20:10] <gary_poster> hatch heh sure.  Just getting a MP ready and then will be free
[20:15] <hatch> Makyo need a review?
[20:16] <Makyo> hatch, sure, if you're willing!
[20:16] <Makyo> Forgot QA instructions, will add.
[20:16] <hatch> sounds good
[20:17] <hatch> gary_poster FYI, i switched from your branch to my branch using the typical git branch... and it broke the yui doc stuff looking for the fonts - I had to make clean to fix
[20:17] <Makyo> Boo test failure.
[20:17] <Makyo> Looking.
[20:18] <gary_poster> sorry hatch, yeah
[20:19] <rick_h_> gary_poster: so I'll try to catch frankban, but saw his message on the charm. Looks like the dmeo is Thurs and not Friday so if we cant' get the charm up tomorrow it'll be helpful to know.
[20:19] <rick_h_> but should be ok if the release is tomorrow
[20:20] <gary_poster> rick_h_: cool.  If you are using your computer then you can use the local charm and we can instructions for that either way
[20:20] <hatch> gary_poster ok branch updated https://github.com/juju/juju-gui/pull/105 whenever you're available
[20:20] <gary_poster> cool hatch will be there soon
[20:21] <rick_h_> gary_poster: rgr, yea. I'll have the env pre-setup.
[20:23] <Makyo> Unrelated, checking if merging trunk helps.
[20:25] <rick_h_> Makyo: hmm, the first failure is  from your recent relatoins stuff though?
[20:25] <Makyo> rick_h_, yeah, though I don't get it locally.
[20:26] <gary_poster> small Python charm review request (bac, benji, Makyo?): https://codereview.appspot.com/60130043 .  review should be very easy, & QA slightly more annoying but hopefully not too bad.
[20:27] <bac> gary_poster: sure
[20:27] <gary_poster> thank you bac
[20:28] <rick_h_> Makyo: oh hmm, looking at the full log it seems like something went boom
[20:28] <rick_h_> Error loading resource http://<IP_ADDRESS>:8888/path/to/charm/[object Object] (203).
[20:28] <Makyo> rick_h_, Oh!  Didn't see the link at the top.
[20:29] <bac> gary_poster: i love how we have all three spellings: cachedFonts, cached-fonts, and cached_fonts.
[20:29] <gary_poster> bac, I know :-/
[20:29] <gary_poster> traveling between worlds
[20:36] <hatch> I especially like the Go API responses in js that are capitalized which we then rename to be camelCased :)
[20:36] <gary_poster> :-)
[20:37] <hatch> gary_poster I read your description with your charm branch as "...verify in your browser's interceptor network tab..."
[20:37] <hatch> I read it three time and was like wtf that doesn't make any sense
[20:37] <hatch> haha
[20:38] <gary_poster> hatch: lol
[20:39] <gary_poster> hatch fwiw started qa 5 or 10 minutes ago.  will try both 1.16 and trunk
[20:39] <hatch> great thanks
[20:39]  * hatch crosses fingers
[20:41] <gary_poster> hatch, looking good on 1.16.5.  Switching to 1.17.3
[20:42] <hatch> gary_poster have you seen any additional correspondence from UI about the 'select a series' dialogue? I remember in the discussion they liked the inspector idea but I haven't seen any mockups
[20:42] <hatch> yussss
[20:42] <rick_h_> hatch: I think the idea is cool for now. It sounds like there will be changes to have the series in the charm and the environment will eventually go to an empty value for default series
[20:42] <rick_h_> hatch: but that'll be down the road.
[20:43] <rick_h_> hatch: I can verify with UX tomorrow, but I don't think there's a lot to it to pop up the inspector with the dialog/selection
[20:43] <hatch> oh so juju needs to extract the charm before it even knows what instance to spin up? interesting...
[20:44] <rick_h_> hatch: yea, I was talking with Mark R about it toinght
[20:44] <hatch> I like that you don't need the crazy folder structure then
[20:44] <gary_poster> hatch, no, I haven't.  If you think it would be pretty easy, and Rick confirms the general approach, then I'd suggest making a stab at it and hoping they give small feedback.  Yes to everythin rick is saying...
[20:44] <rick_h_> hatch: the first stab at an idea is to unzip in the guiserver perhaps (or use a zip lib)
[20:44] <rick_h_> hatch: but we've got some time to talk on it. Still only Tues :)
[20:45] <hatch> haha, I'm just trying to decide what to do next....fakebackend, drag and drop of folder or series selector...
[20:45]  * hatch flips three sided coin
[20:46] <rick_h_> I'd think series selector is first in getting it ready to go? folder is bonus?
[20:46] <gary_poster> +1
[20:46] <rick_h_> but party party
[20:46] <gary_poster> if we think that the approach has general UX buy in
[20:46] <gary_poster> which I do
[20:46] <hatch> yeah my thoughts as well
[20:47] <rick_h_> yay we all agree! that means it's time for bed
[20:47]  * rick_h_ runs away
[20:48] <hatch> hah
[20:51] <gary_poster> hatch QA good!  Blessed the PR
[20:51] <hatch> YUSSSSSS
[20:52]  * hatch merges before it changes it's mind
[20:52] <gary_poster> :-)
[20:54] <bac> gary_poster: i'm trying to do your QA and use the distfile trick.  i get http://paste.ubuntu.com/6875204/
[20:54] <bac> gary_poster: do i need BRANCH_IS_GOOD?
[20:54] <bac> s/D/D=1/
[20:54] <gary_poster> bac, yup
[20:54] <gary_poster> sorry if I forgot that part
[20:54] <bac> gary_poster: cool
[21:11] <bac> gary_poster: i'm having troubles doing QA.  lxc issues.  take 3.
[21:12] <gary_poster> ack bac, and thank you.  I know this is past EoD
[21:12] <gary_poster> if you need to pass it to someone else I understand
[21:13] <bac> agent-state-info: '(error: symlink /var/lib/lxc/bac-local-machine-1/config /etc/lxc/auto/bac-local-machine-1.conf:
[21:13] <bac>       file exists)'
[21:14] <gary_poster> ah that looks familiar
[21:14] <gary_poster> I had to lxc-destroy and do various other purging bits
[21:17] <bac> yeah, lxc should be smarter.  "the link i'm about to make already exists exactly like i want.  panic!"
[21:17] <hatch> https://github.com/juju/juju-gui/commits/develop this is a little confusing, it shows the individual commits and the merge commit and they aren't always in order either
[21:26] <bac> gary_poster: worked fine!
[21:26] <gary_poster> awesome, thanks bac!
[21:30] <gary_poster> Hey Makyo, did you send email to Huw?
[21:32] <gary_poster> queue is not FIFO. :-/  https://launchpad.net/ubuntu/trusty/+queue
[21:34] <Makyo> gary_poster, working on it now.
[21:34] <gary_poster> cool thanks Makyo
[21:38] <hatch> Makyo let me know when your branch passes CI and then I can review/qa
[21:38] <Makyo> hatch, failed again, need to finish email first.
[21:41] <hatch> yeah np
[22:04] <huwshimi> Morning
[22:10] <hatch> gooooood morning huwshimi
[22:10] <hatch> Makyo rebased and landed your branch
[22:11] <Makyo> What?
[22:11] <Makyo> Oh, to huwshimi sorry.
[22:13] <huwshimi> hatch: Yeah, I realised I hadn't ever done that process for us and was going to get you to walk me through it. That stuff is missing from our docs.
[22:13] <hatch> :)
[22:13] <huwshimi> I mean, it's kinda there, but doesn't really explain it for a noob
[22:13] <hatch> ohh ok yeah in that case, good thing you didn't go all cowboy, it's one of those hulk smash sort of things :)
[22:14] <hatch> next branch I, or someone else, can give you a run through of it
[22:15] <huwshimi> hatch: Thanks!
[22:17] <gary_poster> huwshimi: dirty secret: the rebase can get pretty nasty IMO, or at least I don't know how to do it well either :-)
[22:17]  * gary_poster running
[22:17] <gary_poster> have a nice rest of day everyone!
[22:38] <hatch> ctrl+1 has to be one of the most awkward key combinations
[23:05] <hatch> unfortunately the viewletManager has had the databinding engine become part of it
[23:05] <hatch> :/


[01:42] <bazhang> flare183 is a unity developer?
[01:45] <IdleOne> bazhang: I would imagine a dev would know the proper channel name for the dev team
[01:46] <Flannel> wow, failed attempt at a DCC
[01:47] <bazhang> heh
[01:47] <bazhang> IdleOne, good point
[02:10] <IdleOne> hello praveen
[02:13] <praveen> hello
[02:14] <IdleOne> Anything we can help you with?
[02:14] <bazhang> he was sent here by the bot I'd imagine
[02:56] <Juest> hello, now i really apologize, and i reconsider to being unmuted, rules REALLY CARES!
[02:57] <Juest> where's LjL?
[02:57] <Juest> hello?
[02:59] <Juest> bazhang: are you afk?
[03:00] <Juest> hello?
[03:00] <Juest> anybody is alive or else?
[03:00] <IdleOne> Juest: give me a moment please
[03:01] <Juest> yeah, are everybody ilde?
[03:01] <IdleOne> Juest: Please be patient for one minute
[03:01] <Juest> IdleOne are you really idle? lol
[03:02] <IdleOne> Juest: why did you get banned, do you recall?
[03:02] <Juest> well, can you get the log of about two days ago
[03:03] <Juest> last log that mention me
[03:03] <Juest> and one log at 4am gmt -3
[03:03] <IdleOne> Juest: I removed the mute
[03:03] <IdleOne> !guidelines > Juest
[03:03] <IdleOne> Please read the guidelines so you don't get muted again. thank you.
[03:04] <Juest> thanks :)
[03:04] <Juest> thank you :)
[03:04] <IdleOne> Welcome, please part this channel now.
[03:04]  * Juest has already read guidelines, but he will read it one more time :)
[04:05] <Juest> ok, bye
[09:56] <bazhang> p57906E6E.dip.t-dialin.net cockkk must be larstorben
[12:45] <bazhang> !no gps is <reply> Street mapping and GPS navigation software available for Ubuntu includes Navit, MoNav (http://code.google.com/p/monav/), Gosmore (free vector maps from OSM), GpsDrive (GTK, raster maps, free), !GoogleEarth (Qt, proprietary vector maps, proprietary)
[12:45] <bazhang> !gps
[12:46] <LjL> xiexie
[12:46] <bazhang> prego
[12:55] <bazhang> not really an ubuntu question ; he's the centos user
[13:02] <LjL> totem is a nice guy, if only he didn't like to troll so much =)
[13:03] <bazhang> I was referring to loseweight in #ubuntu ^
[13:03] <LjL> i know, i was just saying
[13:22] <bazhang> thisnameiscool has already been warned and removed once for asking centos questions
[13:26] <bazhang> BHXSpecter, how can we help you
[13:29] <BHXSpecter> hold checking something
[13:44] <BHXSpecter> yesterday I updated my router frimware and changed too port 8001 and passed the test yesterday but I'm still getting told I'm banned from #ubuntu
[13:44] <LjL> BHXSpecter: let me check
[13:44] <LjL> BHXSpecter: try asking for a test now please
[13:45] <LjL> BHXSpecter: you should be able to join now
[13:46] <BHXSpecter> ok thanks :) don't know what happened yesterday
[13:46] <LjL> no idea either
[13:46] <LjL> the bots didn't realize you were banned, for some reason
[13:47] <BHXSpecter> thanks again
[13:50] <bazhang> LjL, any idea how he got around the ban?
[13:51] <LjL> bazhang: IP he's using doesn't seem banned - but also, webchat users can *join* even if their IP is banned. they just can't speak.
[13:52] <LjL> that has to happen since we got rid of #Ubuntu-proxy-users
[13:52] <bazhang> LjL, okay so he's muted then
[13:53] <bazhang> well prior to my ban of that particular gateway
[13:53] <LjL> bazhang: basically. webchat is muted by default, then people who join get a +e, unless they are banned, in which case they don't
[13:54] <bazhang> LjL, okay, well I said floodbot saying banned user could not join, but the he joined nonetheless
[13:54] <bazhang> and removing him a second time, the floodbot did not ban as customary
[13:54] <LjL> hmm i will change that message to explain better what's going on now
[13:54] <LjL> well i didn't see their IP on the banlist but maybe the floodbot looked better
[13:55] <bazhang> at this rate the banlist will be filled by tomorrow
[13:58] <bazhang> LjL, thanks
[13:58] <LjL> removing floodbot-set bans to make space
[14:17] <bazhang> [LALALALA__] ban evading in -ot for the nth time
[14:36] <ikonia> gone
[14:43] <ikonia> what's the deal with waxrose_ ?
[14:43] <bazhang> testing nerves
[14:43] <ikonia> why ?
[14:43] <bazhang> who knows
[14:47] <ikonia> LALALALA__ pm'ing me telling me he's lars partner, and he's going to a lawer to get Lars unbanned as he did nothing wrong
[14:49] <Tm_T> you mean lawyer?
[14:50] <ikonia> I did
[15:55] <IdleOne> better get your best suit pressed.
[16:12] <mneptok> especially if they're going to press a suit.
[18:43] <LjL> @mark #ubuntu rgr Often gives people generic Google queries for help, at least three people have already complained about the way he offers help
[18:47] <IdleOne> LjL: How do you suggest we address the issue with him?
[18:48] <LjL> i suggest doing nothing for now
[18:48] <IdleOne> but looking at scroll back I did see him basically tell people to google it a few times
[18:49] <LjL> but he was told not to do it by several people, and i pointed how to him and maybe they're right, he hasn't replied. let's see if he does it again, and to what extent (i do agree with him that giving google keywords might be reasonable in some cases... about unmounting a partition, though, meh, much easier for everyone to say "sudo umount /blah")
[18:51] <IdleOne> Well if he was giving a link that he googled to the user and told them to read that info I wouldn't mind so much. but telling people to search for term xyz is not always intuitive to the user.
[18:51] <jrib> brilliant (in #ubuntu)
[18:51] <IdleOne> least it was hugs
[18:51] <IdleOne> :/
[18:53] <LjL> IdleOne: in the instance i saw he did give a link. problem is, that link was to "unmount drive from cli ubuntu" (or something like that), and the top links weren't really very informative at all. compare to my link to "encrypt partitions site:help.ubuntu.com" i gave yesterday
[18:54]  * LjL gives jrib one of his cookies, waits for medical signs before eating them himself
[18:55]  * jrib eats cookie anyway
[18:55] <LjL> daring
[19:07] <ikonia> not for me
[19:07] <IdleOne> not for you?
[19:08] <ikonia> that link
[19:08] <IdleOne> oh
[19:09] <IdleOne> wouldn't bootchart in the repos do the same thing?
[19:12] <ikonia> I guess so
[19:15] <ckw> I'm not a fan of this new "don't let people join if they might have the dcc exploit" policy
[19:15] <ikonia> it's not new
[19:15] <ckw> I'm on a shaky connection, and it gets triggered whenever the connection happens to drop and I reconnect
[19:15] <ckw> Even though my settings are fine
[19:16] <ckw> How long has it been around? I've only had it affecting me recently
[19:16] <ikonia> quite a long time, over a year
[19:16] <IdleOne> ckw: least 3 years that I can remember
[19:16] <IdleOne> maybe I am remembering wrong but quite a long time
[19:17] <ckw> Hrm... That's really strange then
[19:17] <IdleOne> ckw: I believe yesterday was the last time someone used that dcc exploit in #ubuntu you probably got caught by it
[19:17] <ckw> I'd like to say nothing has changed on my end (besides my connection + update to 11.04) so it is a problem with your bot/freenode, but I'm not so sure
[19:18] <ckw> Thanks
[19:20] <IdleOne> ckw: you went to the link provided in #ubuntu-read-topic and had the bot test you
[19:20] <gord> ikonia?
[19:21] <ikonia> gord: was going to test something but messed it up
[19:21] <IdleOne> lol
[19:21] <IdleOne> no problem
[19:21] <gord> plz to no dcc rpms :)
[19:21] <ikonia> it's good......install it......trust me
[19:21] <IdleOne> sure
[19:21]  * IdleOne blindly installs anything ikonia tells me
[19:22] <IdleOne> :P
[19:22] <ikonia> good
[19:22] <IdleOne> I got dcc set to refuse all file offers
[19:22] <Daviey> ikonia: wtf, 19:19 [freenode] DCC SEND from ikonia [<IP_ADDRESS> port 60381]: irssi-0.8.10a-4.el5.rf.x86_64.rpm [1MB bytes] requested in channel #ubuntu-ops ?
[19:22] <jrib> heh
[19:22] <ikonia> Daviey: sorry about that see above
[19:22] <IdleOne> hahaha you dcc'ed the entire channel
[19:22] <jrib> it's special ikonia-enhanced version
[19:22] <ikonia> jrib: maybe....
[19:22] <Daviey> ahh, !blamegord.
[19:26] <IdleOne> !blamegord
[19:26] <IdleOne> :(
[19:27] <IdleOne> I imagine that factoid would not be CoC compliant anyway
[19:36] <ohsix> hi, rgr on #ubuntu is being constantly offtopic and badgering people, generally not offering any assistance at all for all the lines he seems to have in my buffer; and is beligerent about it as well
[19:36] <IdleOne> ohsix: Thanks for the heads up. We will keep an eye open. If you see any more issues please let us know :)
[19:37] <ohsix> it's been 2 days now,  but i'll keep that in mind
[19:37] <ohsix> thanks
[20:08] <LjL> eh, ohsix now being over the top trying to bash rgr... sighs
[20:08] <ikonia> rgr has been a pain for a few days, I've spoke to him a few times and cut him a lot of slack
[20:09] <IdleOne> I think ohsix has caught rgr making a couple of mistakes
[20:09] <IdleOne> in regards to answers being correct
[20:10] <LjL> mistakes are human, and also while i haven't caught up with the scrollback entirely, it seems that saying "try lxr, then if you don't like it there's other possibilities if you google 'linux source code'"... well, that's not too bad
[20:10] <LjL> well mistakes are not human, just making them is
[20:10] <LjL> except for me, i'm a human mistake
[20:11] <ikonia> I don't mind the mistakes
[20:13] <IdleOne> hah I read that as I don't make mistakes the first time
[20:31]  * LjL rolls eyes at rgr&ohsix
[20:36] <LjL> queried ohsix, told him to slow down on the picking on rgr, that we're keeping an eye on him but he shouldn't bash him for every single thing he does
[20:38] <ikonia> rgr is not helping himself
[20:38] <LjL> neither is actionparsnip now
[20:39] <ikonia> I know
[20:39] <IdleOne> This is tiresome
[20:39] <ikonia> it's going to end now
[20:52] <ikonia> 52 -!- agasdsadsasaaaaa<EMAIL_ADDRESS>has left
[20:52] <ActionParsnip> yo
[20:53] <ohsix> do i have to accept the terms of service of this channel to comply with your request? the onjoin says i do
[20:53]  * LjL checks the onjoin
[20:53] <IdleOne> ohsix: the terms are the same as using #ubuntu
[20:53] <ohsix> IdleOne: ok
[20:53] <IdleOne> you already have accepted :)
[20:53] <LjL> oh yeah ohsix those terms of service are for all ubuntu channels :P
[20:53] <ohsix> well, those agreements are unenforcable but not worth digressing
[20:54] <ohsix> at least in legal terms ;] ops can enforce them
[20:54] <LjL> ohsix: yeah it's a bit silly in my opinion but i think the canonical legal team advised us to have them, or something
[20:54] <ohsix> right
[20:54] <ohsix> onto the larting
[20:54] <ohsix> i think it's notable rgr chose not to join us fwiw
[20:54] <LjL> i'm not going to lart anyone, i'd just like to clear up the "support" definition
[20:54] <LjL> yeah well...
[20:54] <ohsix> he set the flames
[20:55] <LjL> "supported" does mean a few different things depending on context, i think
[20:55]  * ActionParsnip listens
[20:55] <LjL> something may be "supported" by upstream, "supported" by Canonical, "supported" by the Ubuntu community or "supported" by #ubuntu
[20:55] <LjL> those often overlap but in general they may easily not
[20:55] <ohsix> on the irc channel i "support" anything in the repos, and often things that are not, and configurations users aren't expected to touch, when i used the term support to refer to the packages i meant who maintained them, who handles bugs for them; and the importance of the package
[20:55] <LjL> so obviously both Chromium (or perhaps rather Chrome) and Firefox are supported by upstream
[20:55] <LjL> Firefox is supported by Canonical, Chromium is not
[20:56] <LjL> Chromium is supported by the community, by being in universe
[20:56] <ActionParsnip> but the chromim-browser is in the official repos
[20:56] <LjL> and both are supported by #ubuntu, because we support packages in main and in universe
[20:56] <ohsix> even if they didn't support it by it being in main, firefox is more supported directly by the primary maintainers of the software, it's not a third party build of something else
[20:56] <ActionParsnip> so the irc channel supports it, right?
[20:56] <LjL> other parts of the Ubuntu community, however, might possibly not support Chromium
[20:56] <LjL> ActionParsnip: i'd say so
[20:56] <LjL> ohsix: oh it is a third party build
[20:56] <ActionParsnip> and firfox is in on the same servers and is supported by the irc channel, right?
[20:56] <LjL> ohsix: the .deb package is not the same binary the Mozilla provides
[20:56] <ohsix> i weigh the abilities for the maintainer to be able to handle my bug reports or elevate them and have them considered
[20:57] <LjL> ActionParsnip: yes
[20:57] <ohsix> LjL: i know, and about the trademark covenent, i just meant it's not someone taking firefox; and a handful of people providing an alternate build, they largely won't handle bugs given to them and might not even be taken seriously by the people they're cribbing from
[20:57] <ActionParsnip> ljl: so both aresupported equally by the irc channel as both are packages installable by users by adding no PPAs, they are BOTH canonical certified
[20:57] <ActionParsnip> ljl: that's what I'm saying
[20:57] <ohsix> and i'm talking about a lot more than chromium, so don't take it as a dig against its legitimacy
[20:58] <LjL> ohsix, thing is we don't really care in #ubuntu what the upstream supports or doesn't, unless we decide to deprecate it ourselves. we still assume someone is doing their best to support it *in the channel*
[20:58] <LjL> ActionParsnip: wait no, i don't think you can call chromium "canonical certified"... but otherwise, yes
[20:58] <ActionParsnip> !info chromium-browser
[20:59] <ActionParsnip> 10.0.648.205~r81283-0ubuntu1 0
[20:59] <ActionParsnip>         500 http://gb.archive.ubuntu.com/ubuntu/ natty/universe i386 Packages
[20:59] <ActionParsnip> andy@D
[20:59] <LjL> ActionParsnip: now i don't have my original /etc/apt/sources.list handy, but i do believe there is a comment explaining that it's "not supported"
[20:59] <tonyyarusso> ikonia: ?
[20:59] <ActionParsnip> so unles someone hacked in and added the package, it has been added by the package team / canonical
[20:59] <IdleOne> ActionParsnip: they way I see it any package that is in either main,multiverse,universe are supported in #ubuntu. as for certification by canonical that is a different story.
[21:00] <ActionParsnip> IdleOne: exactly
[21:00] <LjL> ActionParsnip: well package team (MOTU) is not Canonical, that's what i'm saying
[21:00] <LjL> Canonical doesn't certify packages in Universe
[21:00] <ohsix> LjL: i'm elaborating on my use of the word "supported" to clear up the apparent confusion, i still "Support" in the sense of #ubuntu, that it's in the repos, it is still "less supported" with regards to the points that i take into account when making that latter judgement
[21:00] <ActionParsnip> ljl: sure, but its still equally supported i #ubuntu, which is what I'm saying
[21:01] <IdleOne> not supported in the sources.list refers to Canonical not providing any support for those packages but they are maintained by the community.
[21:01] <IdleOne> I have to run. later gators
[21:01] <ohsix> LjL: re: not supported in sources.list, you're correct; most people don't see that though, they see software-properties-(gtk|kde), and the mouseover tooltip does say something to that effect, but most people are just enabling it because they are told to, and don't read either
[21:03] <ActionParsnip> if its on the ubuntu repos (not a ppa) it gets equal love in #ubuntu
[21:04] <ohsix> not by me
[21:04] <ohsix> i will support a package less in universe if i don't know personally that the maintainer will be receptive, or that my bugs won't be a waste of time
[21:04] <ohsix> it often doesn't come to that, but it is where it's different in my calculations
[21:04] <ActionParsnip> ohsix: shame
[21:05] <ohsix> who are you to cast aspersions? my position is very reasonable
[21:05] <ohsix> and i've even said what my reasons were
[21:05] <ohsix> i still "support" users that use software anywhere in the repos
[21:05] <ActionParsnip> ohsix: chromium is anywhere in the repos....
[21:06] <ikonia> guys, simple solution, if you want to support a package/problem, do it, if not, don't
[21:06] <LjL> ohsix, of course it's fine if you don't want to support something
[21:06] <ohsix> ActionParsnip: i'm beginning to believe you're willingly misinterpreting what i've explained
[21:06] <LjL> ohsix: the line is when someone starts saying "no, you can't ask about this, it is not supported"
[21:06] <ohsix> LjL: something that i did not say,  but noted
[21:06] <LjL> ohsix: no, just saying
[21:06] <ohsix> and would not say, i might add
[21:07] <ActionParsnip> ohsix: any package i any of the repos is ontopic for the channel, so is "supported"
[21:07] <ohsix> "will not support" is often my opinion, and only at the limits of what i can, regardless of if it's in the repos
[21:07] <ohsix> ActionParsnip: that is what i said
[21:07] <LjL> ActionParsnip: oh is saying that they will "support" a user's system if the user has installed Chromium (as opposed to installing something from a random PPA), but will not support Chromium *itself*, i think
[21:07] <ohsix> ActionParsnip: i did not say it was offtopic, i talked about relative support, not channel & user support
[21:07] <LjL> ActionParsnip: it is "supported", yes, that doesn't mean ohsix *has* to support it
[21:07] <ActionParsnip> ohsix: so one isn't less supported as they are both ontopic
[21:07] <ohsix> it does not mean i can either
[21:08] <ActionParsnip> LjL: oh totally, nobody has to support anything
[21:08] <ohsix> ActionParsnip: one is less supported, indeed; you are confusing the two uses of the sense of the word in play here
[21:08] <ActionParsnip> ohsix: true, its your free will
[21:08] <ohsix> ActionParsnip: i explained both senses of my use of the word above, please try and read and understand it
[21:08] <ActionParsnip> ohsix: i mean simply what is ontopic and offtopic, if that makes it clearer
[21:08] <LjL> meanwhile, in #ubuntu
[21:08] <LjL> rgr is up with sgxfi or however it's spelled again
[21:09] <ohsix> ActionParsnip: i didn't say it was offtopic, merely less supported in my use of the term; and not officially endorsed in rgr's sense of delivering his opinion
[21:09] <LjL> well
[21:09] <LjL> if rgr had come here, i'd have told you that it's much better not to say that anything is "recommended" until, well, it is
[21:10] <ActionParsnip> ohsix: i'm keeping it to the term and what is ontopic in the channel, that is what is key
[21:10] <LjL> "it is my opinion that..." is one thing, "recommended" is another
[21:10] <LjL> s/you/him/
[21:10] <ohsix> ActionParsnip: what's on topic doesn't even come into play
[21:11] <ohsix> ActionParsnip: rgr constantly offering his opinion as fact and no assistance is what is offtopic
[21:11] <ActionParsnip> ohsix: sure it does, that  channel cannot support 3rd party apps not on the ubuntu servers
[21:11] <ohsix> but that's neither here nor there
[21:11] <ohsix> ActionParsnip: they can't? i have
[21:11] <ActionParsnip> ohsix: true
[21:11] <ActionParsnip> ohsix: then thats fine but they are technically offtopic as they are 3rd party
[21:11] <ActionParsnip> gotta go washup kids, bbl :)
[21:11] <LjL> see you
[21:12] <LjL> ActionParsnip: please part here if you're leaving, you know how it works
[21:12] <ohsix> don't conflate "can't" with your personal inability to do so, if i can and am willing i sometimes will, but i take that as my responsibility, and if it comes to an impasse i tell them that nobody else in #ubuntu can be expected to offer further assistance
[21:12] <LjL> ommon sense is the key
[21:12] <LjL> key-ommon sense
[21:12] <ohsix> it is afterall linux, as long as someone isn't doing something that trashes all their package manager tracked files, or they've already done it without any help of mine; i'll help them
[21:13] <ohsix> ugh i hate the term "common sense", it's a cliche for "think like i do"
[21:13] <ohsix> people think differently and those differences can be explained, no need to wash over it with "common sense", unless lowest common denominator where nobody really knows anything is adequate
[21:13] <LjL> ok
[21:13] <LjL> then forget about common sense
[21:14] <LjL> just think like i do :)
[21:15] <ohsix> i appreciate that given time you'd have the ability to articulate your point more clearly; it's just a pet peeve of mine, people use it too easily and communicate poorly
[21:15] <LjL> ohsix: in my view "common sense" means not everything you do has to be justified by a rule
[21:15] <LjL> there's not an exact rule saying you can support off-repo software, and neither there is one that says you can't
[21:16] <LjL> so it's basically up to you and if someone doesn't like what you're doing you need to deal with it yourself in some way, without resorting to the rules
[21:16] <ohsix> oh ok, that's a good point to just make, as it's being understood
[21:16] <LjL> that's what "common sense" means to me
[21:16] <ohsix> *misunderstood
[21:20] <LjL> now to the part i don't like - namely if we're finished here for now, i have to ask you to leave the channel because it's how this channel works :\
[21:21] <ohsix> no u that's offtopic omg
[21:21] <LjL> heh
[21:21] <ohsix> ActionParsnip: if we have a meta disagreement that stems from our differening perspective, we should speak with eachother not the channel
[21:22] <LjL> ^
[21:40] <LjL> [22:39:56] --> nbf has joined this channel (~tmccrary@unaffiliated/noobfukaire). <--- old troll, i believe, i have them on violet hilight ;)
[21:44] <LjL> gee i will really have to try out this Multiply thing if i want to be any use in #ubuntu these days
[21:52] <LjL> from now on i'll start throwing mutes, seriously
[21:54] <LjL> jrib: i want my cookie back
[21:54] <jrib> :(
[21:54] <jrib> I'm not sure you'd like it very much in its current state
[21:55] <jrib> "Multiply"?
[21:55] <LjL> jrib: yeah Unify, whatever it's called, i can't remember!
[21:55] <LjL> maybe Dividity
[21:55] <jrib> oh
[22:16] <LjL> meh
[22:33] <bazhang> divinity
[22:36] <Jordan_U> A product of divide intervention?
[22:51] <Corey> ikonia: Time for me to DCC you a badger.
[22:53] <ikonia> please do
[23:13] <bazhang> Juest is being trying
[23:15] <Jordan_U> Not that he would be any less trying if it were, but is lilo even supported in Ubuntu? It's in main so I guess it must be...
[23:15] <bazhang> he wants grub and lilo? and for gnome to be fixed?
[23:16] <ikonia> ??
[23:17] <Jordan_U> bazhang: The asking about the grub config was a retorical question meant as a complaint, as far as I can tell.
[23:18] <bazhang> Jordan_U, hard to fathom that, as he is asking very precise questions about where grub stores things. he's all over the map with requests
[23:30] <guntbert> can someone have a good look at juest in #ubuntu? he seems to be trolling.  Jumping from topic to topic, never giving straight answers,...
[23:31] <Jordan_U> He's now added "how to use sysv"...
[23:31] <ikonia> yes
[23:31] <Jordan_U> This seems to match the pattern of another troll that has been banned, can't remember the nick though.
[23:31] <guntbert> please - he is sucking up a good portion of support forces atm
[23:32] <bazhang> juest was muted before
[23:32] <ikonia> I agree
[23:32] <ikonia> it will stop
[23:32] <guntbert> thx
[23:32] <bazhang> time for a ban imo
[23:32] <guntbert> bye
[23:32] <ikonia> let him respond, but his comments will stop unless he can actually formulate a support request
[23:33] <bazhang> I just PM'd Juest
[23:33] <ikonia> he "uninstalled" lilo - it doesn't just get removed from the mbr, so I don't believe what he's saying
[23:33] <LjL> probably my fault he's unbanned in the first place
[23:33] <LjL> i removed the bans set by floodbots earlier
[23:33] <LjL> because the list was getting full
[23:34] <ikonia> shame on you
[23:34] <LjL> and since he's using a gateway (or at least was, haven't checked now), the ban was by the floodbots
[23:36] <bazhang> LjL, no
[23:36] <bazhang> he was quieted by me, and that was it.
[23:36] <LjL> he had very nice words for you
[23:37] <ikonia> ?
[23:37] <LjL> http://ubottu.com/bans.cgi?log=39491
[23:37] <Jordan_U> The behavior seems awefully familiar to me. I'm sure there have been multiple bans of a single person for this MO.
[23:42] <Jordan_U> ikonia: Is there more history behind that kick?
[23:42] <ikonia> Jordan_U: no, it was a bad decision based on a jumbled response, I've already pm'd him to explain
[23:42] <Jordan_U> OK.
[23:53] <bazhang> okay, Juest knows 100% clearly about how to clarify, stay on topic etc.
[23:54] <bazhang> just had a lengthy PM with him (he's -ar btw)


[16:21] <nigelb> bdmurray: There is a new tag to be added to the script suggested by seb 'patch-needsinput' when the patch is awaiting input from something else to be integrated in
[17:15] <BlackZ> nigelb: in the bug #544910 I have unsubscribed ~ubuntu-reviewers since ~ubuntu-sponsors is subscribed, you subscribed it
[17:15] <ubot4> Launchpad bug 544910 in aiccu (Debian) (and 1 other project) "Upgrade to 10.04 beta1 blocked by aiccu (affects: 4) (heat: 28)" [Unknown,New] https://launchpad.net/bugs/544910
[17:16] <nigelb> BlackZ: its a script and yeah, something is wrong with it.  I'm working on it
[17:16] <BlackZ> nigelb: just for info :)
[17:17] <nigelb> The script was *not* supposed to do that.  I wonder why :x
[17:17] <BlackZ> heh
[17:17] <BlackZ> nigelb: can you show me the code?
[17:18] <nigelb> hold on
[17:18] <nigelb> http://bazaar.launchpad.net/~nigelbabu/ubuntu-review-overview/trunk/annotate/head:/clean-sweep.py
[17:18] <nigelb> if you find something wrong, poke me or branch and request merge.
[17:19] <BlackZ> sure, I will
[17:19] <BlackZ> nigelb: actually, what's wrong with it?
[17:19] <nigelb> well, it works perfectly
[17:19] <nigelb> only its failing for some bugs.  I'm trying to find the error log.
[17:20] <nigelb> It takes a whole 12 hours to run, main problme
[17:21] <vish> nigelb: that tag was not why seb suggested it , and it does not solve what we wanted!
[17:21] <vish> bdmurray: too ^
[17:22] <nigelb> vish: what the... I thought this was sorted out
[17:23] <vish> nigelb: hrm? when?
[17:23] <vish> nigelb: you have been coding till now ;p
[17:23] <BlackZ> nigelb: OK, I will take a look at it later :)
[17:23] <nigelb> vish: yeah, reportbug + python is crazy
[17:23] <nigelb> I was up till 4 last night
[17:23] <nigelb> or today morning rather
[17:28] <nigelb> vish: ok, so about the tag.  seb proposed patch-needsinput where its awaiting input from someone else, in this case he particularly talked about design.  I extended that to any issue where its blocked on something else.  What exactly is the problem with that?
[17:31] <vish> nigelb: for design bugs needing input , patch is already present , how does a design advocate get to the bug? [there is a design advocates being formed to do such work]
[17:31] <vish> nigelb: the reviewer has to tag them
[17:32] <nigelb> vish: there is going to be a team of people who will be taking decisions?
[17:33] <vish> nigelb: yes
[17:33] <vish> nigelb: there is going to be design advocates , who will be looking into such bugs
[17:34] <nigelb> vish: easy then, subscribe then to the bug and then can look for the tag patch-needsinput
[17:34] <vish> nigelb: who is going to subscribe them?
[17:34] <vish> reviewer again ;)
[17:34] <nigelb> not really
[17:34] <nigelb> oh yeah, right
[17:34] <nigelb> thats's fine by me
[17:35] <nigelb> just let me know when there is such a team and we can add that to the workflow
[17:35] <vish> nigelb: there is no lp team being formed , [unofficial is the ayatan UX team for now]
[17:36] <nigelb> well, then we'll just subscribe that team
[17:36] <vish> nigelb: hence tag the design bugs now , and later we can get the team subscribed
[17:36] <nigelb> I can do a design tag separately for bugs that are design related but that can't be done by reviewers
[17:36] <nigelb> ayatana would have to do that
[17:37] <vish> nigelb: how will ayatan know of the bugs with patches?
[17:37] <vish> that are waiting design review
[17:37] <nigelb> who else will know?
[17:37] <vish> nigelb: the reviewer!
[17:37] <nigelb> that is my problem.  how does a reviewer know something is awaiting design review
[17:38] <vish> nigelb: add a new button , add new icon , those are the kind of bugs
[17:38] <nigelb> See the whole thing is for ubuntu-speific packages which is not our main focus.  In fact, I'm trying to get those packages out of patch review.
[17:39] <nigelb> Our whole effort is to give the patches in LP to the right upstream so they can make a call on it
[17:39] <vish> nigelb: well , you have subscribed the reviewers lot of those bugs
[17:39] <vish> nigelb: i told persia this and he insisted they need to be in the review team's perview
[17:39] <nigelb> I know.  I have to write up the blacklist procedure, which I've not even started - real life is a bit hectic
[17:39] <nigelb> Just give me a few days -  one at a time
[17:40] <nigelb> right now I'm focusing on something else.  The patch subscription script that I'm running is failining on some bugs and I have to figure out why
[17:40]  * nigelb ==> dinner
[19:19] <vish> nigelb: talk to persia before you waste time on a blacklist... he specifically didnt want packages blacklisted
[19:20] <nigelb> vish: actually we both came up with it
[19:21] <vish> nigelb: better to check again. i doubt he would have mentioned excluding packages ;)
[19:22] <vish> nigelb: anyway ubuntu specific packages are several , SC , synaptic , Update-manager and there are design patches there too..
[19:22] <nigelb> vish: It ws discussed at uds too
[19:22] <nigelb> actually one of my WIs
[19:25] <vish> nigelb: thats a weird decision , so we are to exclude all ubuntu specific patches now?
[19:25] <vish> rather packages*
[19:26] <vish> what happens to those patches , and who checks those?
[19:29] <nigelb> nope
[19:29] <nigelb> we *dont* exclude anything arbitarily
[19:30] <nigelb> we give developers/maintainers an *option* to exclude their packages from review
[19:31] <vish> nigelb: hmm , right but if the maintainer has not excluded their packages and prefers the review team. again we are still left with the design bugs those will need tags :s
[19:32] <nigelb> yes, people who notice that something is design related has to tag it design
[19:32] <nigelb> we'll tag everything that needs input as patch-needsinput
[19:33] <vish> nigelb: again , you are not solving the problem the tag was requested for.  that design tag will have to be tagged by the reviewer
[19:33] <vish> nigelb: who else would know about the tags?
[19:34] <nigelb> vish: I do *NOT* want a tag for design input, one for kernel input, one for server input
[19:35] <vish> nigelb: what you suggest is patch-needsinput + a design tag , which works for me
[19:35] <nigelb> yep
[19:35] <vish> nigelb: what i mention is that the "design" tagging should be part of the reviewers work flow
[19:35] <nigelb> Also, I can't have everyone know that something requires design input, so the ayatana team might want to take of it
[19:36] <nigelb> how is a reviewer expected to know that?
[19:36] <vish> nigelb: how will the ayatana team know of the bug's existance?
[19:36] <vish> nigelb: if a reviewer is tagging needsinput , without knowing it is a design input , what is he requesting input for?
[19:36] <nigelb> well, aren't you folks subscribed to everything design related?
[19:37] <nigelb> vish: you see it would be a reviewer tagging it that way
[19:37] <nigelb> thats where you're confused
[19:37] <nigelb> most of the time its dx that will do that needsinput tagging
[19:38] <vish> nigelb: nope , the dx need to be notified about the bug and patch
[19:38] <nigelb> vish: The thing is, the reviewer *won't* know why it is not in.  Its not our call when something makes it in
[19:38] <nigelb> the review only says "this works"
[19:39] <vish> nigelb: right , then why would he tag it "needsinput"?
[19:39] <nigelb> to remove it from the review queue
[19:40] <nigelb> that is why seb proposed the tag, because even though the patch works, only thing its not it because of the needsinput
[19:40] <nigelb> only thing its not *in* is because its needs input
[19:40] <vish> nigelb: you are not getting the point , if he thinks it works , he should just request upload , why would he think about inout?
[19:40] <vish> input*
[19:41] <nigelb> er, you seem to be lost
[19:41] <nigelb> We have a bug A
[19:41] <nigelb> ther is a patch to add a button to do foo
[19:41] <nigelb> patch works, no regressions
[19:42] <nigelb> but it needs a design decision, so its marked as needsinput because it doesn't need review anymore
[19:42] <vish> nigelb: yes , so it is the reviewer thinking it needs design input, right?
[19:42] <nigelb> I was hoping the maintainer marked as such
[19:43] <nigelb> for example, if its software center, mvo has to mark it as needsinput
[19:43] <vish> just to be clear .. who is marking it as "needsinput"  ?
[19:46] <nigelb> I'm not clear.  I wwant to talk to seb on monday.
[19:46] <nigelb> Hence not added to wiki or script if you noticed.
[19:47] <vish> nigelb: right , the the reviewers dont even have to bother about the needsinput tag.. we leave it to the maintainer  , but have it in the script
[19:47] <vish> then the*
[19:47] <nigelb> yup. Need to do that.
[19:48] <nigelb> Like I said, busy doing postmortem on the script for cleansweep project
[19:49] <vish> nigelb: yup , hence left it .. but since you mentioned it for inclusion to the script had to make it clear it is not solid yet
[19:49] <vish> ;)
[19:50] <vish> the ping to bd_murray ^
[19:51] <nigelb> I'm trying to get it to a process where I dont' have to ping him.  Like putting it to a branch and his branch getting updated every 24 hours
[19:51] <nigelb> his local copy rather


[12:42] <asac> joejaxx: about 3g i guess
[12:43] <asac> gnomefreak: lets talk tomorrow about the pitti thing. Not sure what he wants us to do from reading the log :)
[12:45] <tonyyarusso> There was a "thing"?
[12:47] <asac> thing?
[12:47] <asac> ah :)
[12:47] <asac> yeah in log ... gnomefreak toled me that pitti wanted us to do something ... so I called it "thing"
[12:50] <Admiral_Chicago> are we in trouble :(
[12:50] <Admiral_Chicago> lol
[12:50] <tonyyarusso> gotcha
[12:51] <asac> i have no troubles :) ... just tired.
[12:52] <asac> ok night all
[12:52] <Admiral_Chicago> night
[12:55] <Admiral_Chicago> who is the one that can help me with retraces in Feisty?
[12:55] <Admiral_Chicago> gnomefreak: can you ?
[01:18] <gnomefreak> Admiral_Chicago: i can but hjmf is better than me at them
[01:19] <gnomefreak> no me and asac are in trouble everyone else is safe :(
[01:20] <Admiral_Chicago> oh nose....
[01:20] <Admiral_Chicago> what happened
[01:20] <gnomefreak> Admiral_Chicago: its a flash and apport thing
[01:20] <gnomefreak> gonne work on a hook for it
[01:20] <Admiral_Chicago> actually, speaking of which, I think I made sebastian bacher mad at me
[01:20] <Admiral_Chicago> triaging incorrectly...
[01:21] <Admiral_Chicago> a lot of bugs.
[01:21] <Admiral_Chicago> a lot.
[01:21] <gnomefreak> eh
[01:21] <Admiral_Chicago> gnomefreak: am i wrong on this Bug #85763
[01:21] <Ubugtu> Malone bug 85763 in metacity "[apport]  metacity crashed with SIGSEGV" [Medium,Needs info]  https://launchpad.net/bugs/85763
[01:21] <Admiral_Chicago> i think I may be (and probably am wrong)
[01:22] <gnomefreak> looking and hes most likely not mad but he gets agrevated sometimes
[01:23] <Admiral_Chicago> yea i know, i just want to make sure I'm triaging correctly
[01:23] <Admiral_Chicago> i'd rather learn i'm doing it wrong and learn to do it correctly
[01:25] <gnomefreak> i think what he means is the coredump is giving wrong values (not unusable) in the sense me nad yuo would think. i wouldnt worry too much about it right now. metacity and other things are nothing like firefox so you kind of have to get used to them.
[01:26] <Admiral_Chicago> blah okay
[01:26] <Admiral_Chicago> i thought that with a new kernel in Feisty, a new crash report would be useable
[01:38] <gnomefreak> it would be if he thinks he can do something with that one thats fine
[01:39] <gnomefreak> s/be if/ be, but if
[01:40] <gnomefreak> bug 1
[01:40] <Ubugtu> Malone bug 1 in ichthux "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
[01:40] <gnomefreak> hmmmmmm
[01:47] <gnomefreak> Admiral_Chicago: easiest way to retrace feisty "sudo apport-retrace -v -d 88888 2>&1 | tee retrace.log" replace 88888 with just the number of the bug. and make sure you have everything you would need to retrace it. you normally wont know until you try it once the warnings will tell you what your missing. ignore the /var/cache/flashplugin-nonfree/libflash.so --ignore. you wont get dbg or dbgsym packages for that. but you need to h
[01:49] <gnomefreak> Admiral_Chicago: also depends on version of apport and how the bug is laid out. is everything seperate on bug or 1 totel crash file
[01:49] <Admiral_Chicago> right. i'm thinking of looking at that wiki again, i got lost at one point of it
[01:50] <Admiral_Chicago> bbl
[01:50] <gnomefreak> Admiral_Chicago: dont use the wiki for feisty it has changed too much
[01:50] <gnomefreak> i havent figured out the easiest best way
[02:01] <gnomefreak> night
[04:28] <poningru> https://lists.ubuntu.com/archives/feisty-changes/2007-March/006546.html
[04:35] <poningru> [23:33:59]  <Lucy> <khc> I mean when the font "sans-serif" is requested, how does firefox pick which font to use
[04:35] <poningru> [23:33:59]  <Lucy> <khc> which font in that family
[04:35] <poningru> [23:33:59]  <Lucy> <khc> It doesn't seem to use the ordering in fontconfig
[04:36] <poningru> anyone?
[04:37] <tonyyarusso> poningru: I think it's defined within FF
[04:38] <tonyyarusso> maybe not, nvm
[04:40] <poningru> do you know?
[04:40] <poningru> asac: ping
[07:39] <gnomefreak> grrrrrr
[07:46] <Admiral_Chicago> whats the issue?
[07:50] <gnomefreak> im still awake
[07:51] <gnomefreak> its almost 3am
[07:55] <Admiral_Chicago> same here
[07:55] <Admiral_Chicago> i'm going to hang out
[07:55] <Admiral_Chicago> see ya
[09:53] <gnomefreak> asac: pitti > gnomefreak: I just committed support for  "UnsupportableReason: <text>" to apport
[09:54] <gnomefreak> asac: Fujitsu > pitti: Where does that go?
[09:54] <gnomefreak> 04:00 <           pitti > Fujitsu: into the crash report file in /var/crash;  intended to be set in a package hook
[09:54] <gnomefreak> 04:00 <         Fujitsu > Ah.
[09:54] <gnomefreak> 04:01 <           pitti > Fujitsu: the idea is: check report['ProcMaps']  for  libflashplugin.so, and if so, set  report['UnsupportableReason']  = _('Flash is b0rked  blabla')
[09:54] <gnomefreak> so im assuming he did it for us so we dont have to?
[09:54] <asac> hmm
[09:54] <asac> can't tell
[09:54] <asac> better go to sleep gnomefreak  :)
[09:54] <asac> i will find out ;)
[09:55] <gnomefreak> ok ty. i havent slept yet but i will in the next hour or so
[10:28] <gnomefreak> asac: bug 88730 looks like colorzilla can you please confirm that when you get a chance?
[10:28] <Ubugtu> Malone bug 88730 in firefox "[feisty]  Firefox Crashed " [High,Needs info]  https://launchpad.net/bugs/88730
[10:30] <gnomefreak> i hate to say it but it looks like newest apport is doing good on feisty ones thats 2 that ive gotten good ones on
[10:36] <asac> hmm
[10:36] <asac> i tried to setup a new feisty chroot
[10:36] <asac> now apport-retrace
[10:36] <asac> has problems to install dbgsym packages
[10:36] <asac> The following packages have unmet dependencies:
[10:36] <asac>   libnss3-dbgsym: Depends: libnss3 (= <IP_ADDRESS>+1-0ubuntu1) but 2:1.firefox<IP_ADDRESS>+1-0ubuntu1 is installed.
[10:36] <asac>   libgcc1-dbgsym: Depends: libgcc1 (= 4.1.2-0ubuntu4) but 1:4.1.2-0ubuntu4 is installed.
[10:36] <asac>   libnspr4-dbgsym: Depends: libnspr4 (= <IP_ADDRESS>+1-0ubuntu1) but 2:1.firefox<IP_ADDRESS>+1-0ubuntu1 is installed.
[10:37] <asac> yeah its colorzilla
[10:38] <asac> gnomefreak: did you get past that point (e.g. package dependencies?)
[10:38] <asac> ?
[10:38] <gnomefreak> yeah i noticed that issue also
[10:38] <gnomefreak> i did yesterday i just dont remember how :(
[10:38] <asac> stil you can retrace?
[10:39] <gnomefreak> or did i skip them
[10:39] <gnomefreak> libnss3: Installed: 2:1.firefox<IP_ADDRESS>+1-0ubuntu1
[10:40] <gnomefreak> so i think i was able to just leave them alone. you can try apt-get -f install but iirc it didnt help
[10:42] <asac> hmm
[10:42] <asac> how?
[10:42] <asac> for me apport-retrace bails out
[10:43] <gnomefreak> you using sudo? with newest apport?
[10:45] <asac> hmm
[10:46] <asac> i am root in chroot
[10:47] <gnomefreak> for feisty are you using #apport-retrace -s -v -u bug# 2>&1 | tee retrace.log? and what is the error?
[10:48] <asac> what does -u do?
[10:48] <gnomefreak> unpack only dont set up
[10:49] <gnomefreak> something like that
[10:49] <asac> hmm
[10:49] <asac> now i don't get the error anymore
[10:49] <asac> i ran apport-retrace -s bug# before
[10:50] <gnomefreak> -u, --unpack-only     Only unpack the additionally required packages, do not configure them; purge packages again after retracing
[10:50] <gnomefreak> pitti told me on one of the many apport bugs i filed to use -u see if it still happens so i have been using it
[10:51] <gnomefreak> does this look ok(when you get a chance) http://librarian.launchpad.net/6718918/Stacktrace
[10:51] <asac> hmm
[10:52] <asac> funny thing is
[10:52] <asac> after using -u once
[10:52] <asac> i don't get the same problem as before anymore
[10:52] <asac> anyway ... its just garbage ... e.g. what is produced as trace
[10:52] <asac> --- stack trace ---
[10:52] <asac> #0  0x00002af41d0c30a0 in ?? ()
[10:52] <asac> --- thread stack trace ---
[10:53] <gnomefreak> what bug?
[10:53] <asac> for Bug 86277
[10:53] <Ubugtu> Malone bug 86277 in firefox "[feisty]  Firefox Crashed x86_64" [High,Needs info]  https://launchpad.net/bugs/86277
[10:53] <gnomefreak> damn
[10:53] <gnomefreak> i dont have 64
[10:54] <asac> i think we should close that one
[10:54] <asac> no way to get a better trace apparently
[10:54] <gnomefreak> i would ask him to backtrace it or steps to repro it other than that there isnt anything we can do but close
[10:54] <asac> lets just close
[10:54] <asac> then
[10:54] <asac> asking users to retrace if we don't know on our own how to do it won't help a lot
[10:55] <gnomefreak> trrue
[11:00] <asac> have you ever seen apport retracing dropping a useful retrace?
[11:00] <asac> e.g. the service
[11:02] <asac> is beta out?
[11:03] <gnomefreak> not sure about beta. and i have retraced some nice ones the past 24 hours. some 64bits the stack that is uploaded for feisty sometimes have good ones
[11:03] <asac> yeah ... some look somehow ok
[11:04] <gnomefreak> there are a few things we need to think about. we need a list of all dapper crashes for fx and tb. sinse we cant retrace them i would think check them see if anything helpfule from bug buddy if not find out if repro on edgy if so retrace them or if not close them
[11:04] <gnomefreak> not sure how to get a list of dapper crashes
[11:06] <gnomefreak> ok i just retraced one of the gtk_defaultbackground ones and it is correct stack and thread. another great output of one
[11:06] <gnomefreak> bug 90583 is the one
[11:06] <Ubugtu> Malone bug 90583 in firefox "Firefox crashes on opening pdf" [High,Needs info]  https://launchpad.net/bugs/90583
[11:08] <gnomefreak> i just uploaded my .log file to it
[11:10] <gnomefreak> ok now its uploaded :(
[11:12] <asac> Bug 93762 ... can be closed i guess :)
[11:12] <Ubugtu> Malone bug 93762 in firefox "Firefox crashed on feisty" [Undecided,Rejected]  https://launchpad.net/bugs/93762
[11:14] <gnomefreak> i agree
[11:17] <asac> hmm ... again there is a user that complains about launchpad not accepting crash reports
[11:17] <asac> is that really the case? e.g. maybe there is a constraint for attachments?
[11:18] <gnomefreak> asac: i think its they are too big for users connection (or they kill it maybe due to it takes too long)
[11:18] <asac> i thought that too initially
[11:18] <asac> but the more i read the comments, the more i guess there might be indeed a constraint
[11:18] <gnomefreak> i have uploaded huge crash reports in past they take forever but ive done it
[11:19] <asac> how huge?
[11:19] <gnomefreak> maybe. would need to talk to #launchpad
[11:19] <gnomefreak> 25mb
[11:19] <gnomefreak> give or take
[11:19] <asac> Yeah, I realize that the small report is pretty useless.  How should I get
[11:19] <asac> the complete report to you guys?  Launchpad would not accept the file, maybe
[11:19] <asac> because it's around 30 MB or so...
[11:20] <gnomefreak> well after what happened to my home dir i wont be accepting them by email. maybe we need to set up a site or something to take them?
[11:21] <gnomefreak> maybe a wiki wiht a table for them to fill out? (name date bug# file)  but i dont think wiki is the best to try that with
[11:22] <gnomefreak> try taring it or zipping it to save 10mb or so?
[11:22] <asac> don't think it helps
[11:22] <asac> coredump is already gzipped
[11:25] <gnomefreak> something to talk to LP and pitti about maybe see if there is something else we can do
[11:25] <asac> i asked on launchpad
[11:25] <asac> #launchpad
[11:25] <asac> lets see
[11:26] <gnomefreak> i see
[11:26] <asac> oh i am sooo tired
[11:26] <asac> i currently experiment how to survive a day without coffee
[11:26] <gnomefreak> i have one im downloading that is 30mb
[11:26] <gnomefreak> bug 90891
[11:26] <Ubugtu> Malone bug 90891 in firefox "firefox crashes" [High,Needs info]  https://launchpad.net/bugs/90891
[11:26] <asac> hmm
[11:26] <asac> ever downloaded one that is about 35mb?
[11:26] <gnomefreak> ah he didnt upload to LP though
[11:26] <asac> ah
[11:27] <gnomefreak> I can't upload the file here (I don't know why) so I've stored it in my web space. The adress is: http://frank95com.homelinux.com/pub/media/other/_usr_lib_firefox_firefox-bin.1000.crash
[11:27] <asac> yes
[11:27] <asac> lets bug lp folks
[11:27] <gnomefreak> k
[11:28] <gnomefreak> pastebin.ca allows uploads but they restrict them to like 100kb
[11:29] <asac> usually every webapp where you can upload to has some constraint
[11:29] <asac> however, i don't know what size it is for launchpad
[11:32] <gnomefreak> i think im gonna start marking the background ones as dupes as soon i as remember the one i got great stack on for it
[11:34] <gnomefreak> or not since i cant find it :(
[11:37] <gnomefreak> well if ther eis no limit what are people getting errors
[11:53] <gnomefreak> ok last retrace than im goin gto bed. im getting tired and its almost 7am
[12:09] <gnomefreak> asac: i made bug 90583 master of gtk_style_apply_default_background
[12:09] <Ubugtu> Malone bug 90583 in firefox "MASTER Firefox crashes  [@gtk_style_apply_default_background] " [High,Needs info]  https://launchpad.net/bugs/90583
[12:10] <gnomefreak> its feisty bug and since we dont know anything about it atm im going through email cause i saw a crap load of them iirc
[12:11] <gnomefreak> since the new totem has fixed most of the edgy bugs in feisty im going to assume this is different for now.
[12:32] <gnomefreak> night
[01:52] <asac> gnomefreak: ok ... so this is a new top-crash for us
[01:53] <asac> we need to find way to reproduce
[01:53] <asac> wo i can work on a fix
[01:53] <asac> or better find fix upstream :)
[03:19] <asac> hmmm Bug 94921
[03:19] <Ubugtu> Malone bug 94921 in firefox "[apport]  firefox-bin crashed with SIGSEGV in __kernel_vsyscall()" [Medium,Unconfirmed]  https://launchpad.net/bugs/94921
[03:19] <asac> apport did his best, but not suceeded :)
[03:25] <asac> hjmf: Bug 94861
[03:25] <Ubugtu> Malone bug 94861 in firefox "[apport]  firefox-bin crashed with SIGSEGV in __kernel_vsyscall()" [Medium,Rejected]  https://launchpad.net/bugs/94861
[03:25] <asac> maybe installing that extension hels?
[03:26] <asac> hjmf: however, where can one get that? Its a native extension and thus if its free-software we should add it to ubuntu archives
[03:28] <asac> i asked the author :)
[03:30] <hjmf> asac: hi! about bug 94921
[03:30] <Ubugtu> Malone bug 94921 in firefox "[apport]  firefox-bin crashed with SIGSEGV in __kernel_vsyscall()" [Medium,Unconfirmed]  https://launchpad.net/bugs/94921
[03:30] <hjmf> im going to retrace it but I bet that is flashplayer
[03:45] <hjmf> ... Ive lost my bet :/
[03:46] <hjmf> I cannot get a better retrace. I've asked the reporter for additional info about the crash
[03:46] <asac> ok
[03:50] <asac> ok incompatible allpeers extension causing crashes is now a new master bug ... there appear to be plenty of those.
[03:52] <asac> bug 95091 it is
[03:52] <Ubugtu> Malone bug 95091 in firefox "MASTER incompatible native extension: allpeers" [High,Needs info]  https://launchpad.net/bugs/95091
[03:56] <asac> ok i have resurrected a few about this that have previously been rejected
[04:05] <hjmf> noticed, Ive marked the one I retraced as dup of new master
[04:06] <asac> good ... if its allpeers its a safe bet :)
[04:06] <asac> the new master needs someone to take care ... so if anyone likes to communicate with upstream authors, its probably the right bug.
[04:06] <asac> maybe I should assign it to DFarning?
[04:07] <hjmf> sure he is the guy
[04:07] <asac> i am pretty bad at it :( ... i even dropped the ball on colorzilla ... i think I should ping him as he wanted to release under GPL
[04:07] <hjmf> ... he seems to like those things :)
[04:07] <asac> so we can package it
[04:09] <hjmf> I have to confess that I've never tried those extensions...
[04:09] <hjmf> :)
[04:09] <Admiral_Chicago> asac: why do we need bug#95091
[04:09] <Admiral_Chicago> bug 95091
[04:09] <Ubugtu> Malone bug 95091 in firefox "MASTER incompatible native extension: allpeers" [High,Needs info]  https://launchpad.net/bugs/95091
[04:10] <asac> Admiral_Chicago: look at the bug ... there are duplicates already
[04:10] <Admiral_Chicago> Allpeers is a closed source (moving to open source) extension that isn't in the repos though
[04:10] <asac> Admiral_Chicago: though its not exactly our problem we should try to shake things out ... we should at least contact author and ask him to open-source it
[04:10] <asac> :)
[04:10] <asac> if possible
[04:11] <asac> colorzilla author will open his source after i discussed this with him :)
[04:11] <Admiral_Chicago> there was an announcement about moving it to open source, but open source doesn't mean GPL
[04:12] <Admiral_Chicago> we can try to contact them for sure
[04:12] <Admiral_Chicago> perhaps with some more detailed bug reports though
[04:12] <asac> yes ... do you like that or should i ask dfarning ?
[04:12] <Admiral_Chicago> i'll do it
[04:13] <Admiral_Chicago> i'll assign it to myself temporarily
[04:14] <asac> Admiral_Chicago: cool :) ... if you need arguments why GPL et al, let me know :)
[04:14] <Admiral_Chicago> will do
[04:14] <asac> tell him that we could build package and it will automatically become available on lots of architectures (which he will probably not be able to build)
[04:15] <Admiral_Chicago> right.
[04:16] <Admiral_Chicago> its a team afaik
[04:16] <Admiral_Chicago> but I have to grab breakfast and head to class
[04:16] <asac> ok them :)
[04:20] <hjmf> awk for a while
[06:38] <gnomefreak> wtf is a memory error when doing retrace :(
[06:41] <AlexLatchford> https://bugs.beta.launchpad.net/ubuntu/+source/firefox/+bug/1
[06:41] <Ubugtu> Malone bug 1 in ichthux "Microsoft has a majority market share" [Critical,Confirmed]
[06:41] <AlexLatchford> gnomefreak: Why is this on us?
[06:42] <gnomefreak> i dont know
[06:42] <AlexLatchford> reject?
[06:42] <AlexLatchford> well To me it is not a firefox bug, it is purely an Ubuntu bug
[06:43] <gnomefreak> AlexLatchford: i would say find out who added it first
[06:43] <AlexLatchford> will do
[06:57] <asac> i feel that we are of real importance to resolve bug 1
[06:57] <Ubugtu> Malone bug 1 in ichthux "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
[06:57] <asac> if we do wrong we bug 1 can't be resolved :)
[06:57] <asac> ok out too
[07:02] <gnomefreak> ill be back later.