[05:06] <mborzecki> morning
[05:41] <mardy> hi mborzecki, zyga-mbp
[05:41] <zyga-mbp> hey mardy
[05:41] <zyga-mbp> rainy cold morning here
[05:42]  * zyga-mbp writes some status reports today
[05:42] <mborzecki> mardy: zyga-mbp: hey
[06:27] <mborzecki> omg github ux has changed again, before when i clicked on a patch in a PR it would take me to that patch view, if there's just one it the same as I would be reviewing the whole PR
[06:28] <mborzecki> now you have to go to 'files changed', otherwise just clicking on a patch shows the patch in the fork repository, and comment added get added to that fork :/
[07:02] <pstolowski> morning
[07:34] <mup> PR snapd#10792 closed: packaging: backports of golang-go 1.13 are good enough <Simple 😃> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10792>
[07:38] <mborzecki> mvo: hi, can you land https://github.com/snapcore/snapd/pull/10781 ?
[07:38] <mup> PR #10781: tests: fix tests for 21.10 <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10781>
[07:39] <mup> PR snapd#10785 closed: tests: add test for store.SnapAction() request timeout <Simple 😃> <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10785>
[07:39] <mup> PR snapd#10786 closed: tests: print user sessions info on debug-each <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10786>
[07:40] <mborzecki> thanks!
[07:42] <mvo> mborzecki: my pleasure, let me know if there is more that I overlooked :)
[07:42] <mvo> pstolowski: and good morning !
[07:42] <mvo> mborzecki: and good morning to you as well :)
[07:44] <mup> PR snapd#10781 closed: tests: fix tests for 21.10 <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10781>
[07:51] <pstolowski> mvo: hmmm, looks like https://github.com/snapcore/snapd/pull/10785 should have landed as the new unit test failed there, but I can't repro this failure locallly
[07:51] <mup> PR #10785: tests: add test for store.SnapAction() request timeout <Simple 😃> <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10785>
[07:51] <pstolowski> *shouldn't have
[08:00] <mvo> pstolowski: uh, silly me
[08:02] <mvo> pstolowski: silly me indeed, it's just the "" that are different in latest go and current go, should be an easy fix. sorry for that
[08:03] <pstolowski> mvo: no worries, I'll prep a fix
[08:19] <mup> PR snapd#10793 opened: tests: fix regex of TestSnapActionTimeout test <⚠ Critical> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10793>
[08:49] <mborzecki> hmm https://paste.ubuntu.com/p/2yRyJBKKK6/ failed twice in a row?
[08:50] <pstolowski> mborzecki: https://github.com/snapcore/snapd/pull/10793
[08:50] <mup> PR #10793: tests: fix regex of TestSnapActionTimeout test <⚠ Critical> <Simple 😃> <Skip spread> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10793>
[08:50] <pstolowski> mborzecki: but it seems it still needs a tweak
[08:52] <mborzecki> heh 1.17.x thing
[08:52] <pstolowski> pushed one more tweak
[09:00] <miguelpires> pstolowski I think the regex fix is missing a " before the first colon. The test fails for me at least
[09:00] <pstolowski> miguelpires: even after the tweak i pushed a few minutes ago?
[09:01] <miguelpires> Yes
[09:02] <pstolowski> miguelpires: ah, there, i see
[09:03] <pstolowski> i'm slightly confused about the diff, i'm running 1.13.8 and we've 1.13
[09:24] <mup> PR snapd#10794 opened: build-aux: fork snapcraft.yaml for riscv64 <Created by xnox> <https://github.com/snapcore/snapd/pull/10794>
[09:41] <miguelpires> mvo: can you merge https://github.com/snapcore/snapd/pull/10793 and https://github.com/snapcore/snapd/pull/10784 please?
[09:41] <mup> PR #10793: tests: fix regex of TestSnapActionTimeout test <⚠ Critical> <Simple 😃> <Skip spread> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10793>
[09:41] <mup> PR #10784: o/snapstate: add ChangeID to conflict error <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10784>
[09:49] <mvo> miguelpires: sure
[09:49] <mup> PR snapd#10784 closed: o/snapstate: add ChangeID to conflict error <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10784>
[09:49] <mup> PR snapd#10793 closed: tests: fix regex of TestSnapActionTimeout test <⚠ Critical> <Simple 😃> <Skip spread> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10793>
[10:30] <mup> Bug #1925167 changed: Path to uefi-fw-tools binary file not created <Snappy:Invalid> <https://launchpad.net/bugs/1925167>
[10:33] <mup> Bug #1925167 opened: Path to uefi-fw-tools binary file not created <Snappy:Invalid> <https://launchpad.net/bugs/1925167>
[10:45] <mup> Bug #1925167 changed: Path to uefi-fw-tools binary file not created <Snappy:Invalid> <https://launchpad.net/bugs/1925167>
[10:46] <mborzecki> hm this failed on LP: https://paste.ubuntu.com/p/9FtG8BrWN8/ related to the change ID error change from miguelpires ?
[10:54] <mup> PR snapd#10795 opened: o/assertstate: check installed snaps when refreshing validation set assertions <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10795>
[10:55] <miguelpires> mborzecki: yes, that's related to my PR. Thanks for pointing, I think I made the test flaky
[10:55] <miguelpires> *pointing it out
[10:55] <pstolowski> mborzecki: hmm looks like there was an unexpected change in state, so id ended up being 2
[10:58] <mborzecki> yeah, miguelpires does it reproduce locally with -count <some-number> ?
[11:00] <miguelpires> yes, I can trigger it locally with just a few tries
[11:19] <mup> PR snapd#10796 opened: o/devicestate: fix flaky test remodel clash <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10796>
[11:22] <pstolowski> mvo: hey, could you please land https://github.com/snapcore/snapd/pull/10782 ?
[11:22] <mup> PR #10782: o/ifacestate: do not create stray task in batchConnectTasks if there are no connections <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10782>
[11:31] <pstolowski> miguelpires: silly question there (i'm not familiar with details of remodelling)
[11:37] <miguelpires> pstolowski: I don't see your question in the PR
[11:37] <pstolowski> miguelpires: grr i did it again and forgot to submit the review; now
[11:45] <mup> PR snapd#10797 opened: usersession/client: refactor doMany() method <Created by mardy> <https://github.com/snapcore/snapd/pull/10797>
[12:08] <mborzecki> pstolowski: is there anything else we can do in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1922293 or can it be closed now?
[12:08] <mup> Bug #1922293: Snaps appear broken on 21.04 Beta with ZFS <hirsute> <iso-testing> <snapd (Ubuntu):In Progress by stolowski> <zfs-linux (Ubuntu):Fix Released> <https://launchpad.net/bugs/1922293>
[12:10] <pstolowski> mborzecki: i think it can be closed
[12:33] <miguelpires> mvo: can you merge https://github.com/snapcore/snapd/pull/10796 please?
[12:33] <mup> PR #10796: o/devicestate: fix flaky test remodel clash <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10796>
[12:40] <mvo> miguelpires: sure
[12:45] <mup> PR snapd#10796 closed: o/devicestate: fix flaky test remodel clash <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10796>
[13:20] <mup> PR snapd#10798 opened: github: do not fail when codecov upload fails <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10798>
[13:20] <mborzecki> trivial PR ^^
[13:45] <mborzecki> mvo: can you take a look and land? ^^
[13:45] <mborzecki> (fwiw codecov uploads are failing atm)
[14:07] <ijohnson[m]> cachio_: hey have you seen either of these failures before ? https://pastebin.ubuntu.com/p/vccF9HBJjB/ and https://pastebin.ubuntu.com/p/cRPHmRQPZV/
[14:11] <ijohnson[m]> https://github.com/snapcore/snapd/pull/10799 will help unbreak master
[14:11] <mup> PR #10799: tests/main/preseed: update for new base snap of the lxd snap <⚠ Critical> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10799>
[14:15] <mup> PR snapd#10799 opened: tests/main/preseed: update for new base snap of the lxd snap <⚠ Critical> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10799>
[14:16] <mup> PR core#125 opened: Copy dpkg.yaml for LP Buildd <Created by ilasc> <https://github.com/snapcore/core/pull/125>
[14:17] <mup> PR core18#181 opened: Copy dpkg.yaml for LP Buildd <Created by ilasc> <https://github.com/snapcore/core18/pull/181>
[14:26] <mup> PR core20#113 opened: Copy dpkg yaml for buildd <Created by ilasc> <https://github.com/snapcore/core20/pull/113>
[14:50] <mardy_2nd> do we know if the failure to upload to codecov is a temporary failure on their side, or are there some keys that expired?
[14:53] <mborzecki> mardy_2nd: that's all there is in the log: https://paste.ubuntu.com/p/Z6T8N9YCQp/ do we need some token? ijohnson do you remember if we had to get one?
[15:00] <ijohnson[m]> bboozzoo: we didn't use to need a token, maybe we do now all of a sudden ?
[15:01] <mup> PR core20#113 closed: Copy dpkg yaml for buildd <Created by ilasc> <Merged by xnox> <https://github.com/snapcore/core20/pull/113>
[15:02] <mup> PR core18#181 closed: Copy dpkg.yaml for LP Buildd <Created by ilasc> <Merged by xnox> <https://github.com/snapcore/core18/pull/181>
[15:11] <zyga-mbp> mardy I never saw any codecov keys to begin with, perhaps just a temporary fluke?
[15:16] <mborzecki> ijohnson: ok, let's wait until tomorrow, maybe it's just temporary outage 🙂 unless we're run though our trial period or sth
[15:17] <mborzecki> that would be very 90's of them though :P
[16:00] <cachio_> ijohnson[m], no, didn't see those errores
[16:00] <mvo> mborzecki: sure, lnaded, sorry for the slow reply
[16:00] <mup> PR snapd#10798 closed: github: do not fail when codecov upload fails <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10798>
[16:01]  * cachio_ lunch
[17:37] <mardy> https://status.codecov.com/ all is green
[17:38] <mardy> but they did some release today, and maybe the last one fixes the issue: https://github.com/codecov/uploader/releases
[17:39] <ijohnson[m]> mardy: looks like they do a release on every PR, probably not a "stable" release
[22:32] <mup> PR core20#114 opened: Fix riscv64 build <Created by xnox> <https://github.com/snapcore/core20/pull/114>


[00:05] <brousch> icu
[00:05] <brousch> one of my friend's proxy servers got blocked earlier today
[00:05] <brousch> one his company was using
[00:06] <rick_h_x> well I'm connecting with xchat from home
[00:06] <rick_h_x> my irssi connection/colo can't connect
[00:06] <rick_h_x> it's like it's getting filtered
[00:06] <brousch> that's what happened to him
[00:07] <rick_h_x> crap
[00:09] <rick_h_> how about this
[00:09] <rick_h_> bah, colorscheme doesn't play nice with byobu at all
[00:11] <rick_h_> testing
[00:13] <rick_h_> there we go, that looks better
[00:28] <greg-g> welcome back
[00:28] <rick_h_> moved irssi to my EC2 instance :(
[00:42] <greg-g> lame
[01:25] <snap-l> Hello world
[01:26] <rick_h_> howdy
[01:26] <rick_h_> over?
[01:40] <jrwren> you keep and EC2 instance up all the time?
[01:40] <rick_h_> yea, have a pair of them
[01:41] <rick_h_> bmark.us, semiww.org, some other sites/etc
[01:42] <jrwren> that is $$$
[01:42] <jrwren> i take it you don't personally pay for 'em?
[01:42] <rick_h_> micro instance is about $15/mo
[01:42] <rick_h_> yea, personally pay for them
[01:46] <jrwren> wow, cool.
[01:46] <jrwren> i thought micro was about $30/mo... but that was probably old pricing.
[01:46] <rick_h_> no, that's the small instance
[01:46] <jrwren> plus free micro for a year, I guess I should be running some.
[01:46] <rick_h_> yea
[01:46] <jrwren> AMZ is always cutting prices on that, I think my pricing was old info
[01:46] <rick_h_> gotcha
[01:47] <rick_h_> anyway, yea handy to have around. Setup a second one for my jenkins instance and such for bmark
[01:47] <rick_h_> build.bmark.us
[01:47] <rick_h_> and working on some blog migrations/etc
[02:07] <jrwren> have you heard of htis free oprating system "lee knocks" ?
[02:08] <rick_h_> nope, must be something from communist countries
[03:34] <_stink_> yikes, github down!
[03:34] <_stink_> and right when i actually wanna look at stuff. :P
[03:52] <snap-l> Home.
[04:02] <greg-g> snap-l: how'd it go? splendidly I assume?
[04:07] <snap-l> Presentation went well, thanks
[04:07] <snap-l> Lots of good questions about podcasting
[04:09] <snap-l> Had only one snafu where I forgot the right music. ;)
[04:11] <greg-g> awesome!
[04:12] <greg-g> Sorry I couldn't make it :/
[04:17] <snap-l> np.
[04:17] <snap-l> It's the thought that counts. ;)
[04:17] <greg-g> well, then you've always got it from me :)
[04:18] <snap-l> Heading to bed. TTYL!
[04:18] <snap-l> heh
[12:48] <wolfger> http://shirt.woot.com/shirts/concerts-will-never-be-the-same
[13:04] <snap-l> heh
[13:34] <greg-g> :)
[13:34] <greg-g> g'morn
[13:39] <rick_h_> morning
[13:41] <rick_h_> snap-l: so it went well?
[13:42] <rick_h_> a whole new array of podcasts about to be born
[13:56] <snap-l> Heh
[13:56] <snap-l> Hope so
[13:56] <wolfger> what kind of array?
[13:57] <snap-l> krondor: You weren't at MUG?
[13:57] <snap-l> I had presents for you.
[13:58] <rick_h_> yea, krondor ping'd me, but it was when I was having my irc problems
[13:58] <rick_h_> ugh
[14:00] <krondor> Yeah sorry I was actually out the door toward mug when Em asked me to run some errands and it all derailed
[14:00] <krondor> How was the talk?
[14:00] <snap-l> Coming to CHC tonight?
[14:00] <snap-l> Talk went well
[14:00] <snap-l> Pretty good turnout as well, all things considered.
[14:01] <krondor> I'll try to make chc, I can guilt Em about mug too so that helps
[14:01] <snap-l> heh
[14:01] <rick_h_> hah
[14:01] <rick_h_> the good ole guilt trip
[14:02] <snap-l> Awesome. I'll bring the stuff then
[14:02] <snap-l> lmk if situations change.
[14:02] <snap-l> rick_h_: 8pm
[14:02] <snap-l> not 7pm
[14:03] <rick_h_> doh
[14:03] <rick_h_> redid
[14:03] <rick_h_> sorryt
[14:03] <rick_h_> trying to multi-task too much right now
[14:03] <snap-l> Proof that rick_h_ only copy and pastes!
[14:04] <snap-l> You must make penance, my son
[14:04] <snap-l> 1 day with Eclipse, no plugins.
[14:04] <snap-l> only then shall you redeem yourself.
[14:04] <rick_h_> psh
[14:04] <snap-l> and psh
[14:04] <snap-l> I'm sure there's a shell called psh out there. ;)
[14:05] <wolfger> perl shell, isn't it?
[14:06] <wolfger> http://www.focusresearch.com/gregor/sw/psh/
[14:06] <snap-l> Why yes, yes it is. :)
[14:06]  * snap-l feels an evil streak coming
[14:08]  * wolfger feel 'sudo apt-get install psh' in his near future
[14:11] <wolfger> snap-l: evil streak? You mean like altering somebody's environment to pipe STDOUT through cowsay?
[14:12] <rick_h_>  don't leave your laptop unattended at CHC tonight
[14:12] <rick_h_> might be a chsh in your future
[14:12] <wolfger> (actually, I'm plotting to pipe my STDERR through cowsay, which I think will be cool)
[14:27] <brousch> rick_h_: do you think a micro EC2 could run an instance of plone?
[14:29] <Blazeix> http://probablyinteractive.com/url-hunter
[14:29] <rick_h_> brousch: probably, I mean I'm running hudson on it
[14:33] <snap-l> Yay, fed Ex has made my package take a three day journey from Wisconsin
[14:33] <snap-l> Here's how that works
[14:34] <snap-l> Oh, even better, it'll probably take an additional day.
[14:37] <snap-l> http://ubuntuone.com/p/grk/
[14:37] <snap-l> Initially the delivery date was 5/9
[14:37] <snap-l> er, 3/9
[14:52] <snap-l> Sorry, it was 3-8 business days.
[14:53] <rick_h_> sql help with brain fart this morning
[14:54] <rick_h_> I want to SELECT id, score = 1 FROM table
[14:54] <rick_h_> where score isn't a col in the table
[14:54] <rick_h_> what's it called so I can google mysql and the dippy thing?
[14:55] <_stink_> 1 as score
[14:55] <_stink_> ?
[14:56] <brousch> yes
[14:56] <rick_h_> no, error there too
[14:56] <_stink_> blarg
[14:56] <rick_h_> ah, nvm
[14:56] <snap-l> Wouldn't that be SELECT id, 1 as score from table?
[14:56] <rick_h_> thats right
[14:56] <rick_h_> yea, thanks
[14:56] <_stink_> coolio
[14:56] <snap-l> np
[14:57] <snap-l> i remember hating SQL like crazy in college, now it's almost second nature
[14:58] <snap-l> Only things I have to look up are permissions
[15:00] <rick_h_> ah, got it, ugh
[15:01] <rick_h_> sometimes getting things into sqlalchemy can be fun
[15:19] <binbrain> on hold for the sec of state, there are "Yes, Michigan" ad is looping reminding me how awesome snow is
[15:20] <rick_h_> hah
[16:03] <jcastro> hey rick_h_
[16:03] <jcastro> I have a guest from work coming to CHC
[16:04] <jcastro> he's from canonical and is in town to do some tech support for a customer
[16:04] <rick_h_> jcastro: awesome, I won't be there though
[16:04] <rick_h_> packing for pycon
[16:04] <jcastro> boooooooooooooooooooooooooooooooooooo
[16:04] <rick_h_> but snap-l and company can take care of him
[16:05] <rick_h_> jcastro: yea, I know. priorities :)
[16:05] <jcastro> rick_h_: say hi to the crew there pls.
[16:05] <jcastro> I'm sure barry is going?
[16:05] <snap-l> Jesus, that damn opencore thread is going crazy.
[16:05] <rick_h_> will do, got voidspace to agree to an interview
[16:05] <rick_h_> and yea, barry is heading down.  Done.
[16:11] <snap-l> wolfger: You're too kind
[16:12] <snap-l> jcastro: Last name: Shuttleworth? :)
[16:12] <rick_h_> pack 2 laptops, 4 mics, power, xlr cables, clothes, cards
[16:12] <jcastro> heh no
[16:30] <greg-g> snap-l++
[17:01] <jrwren> greg-g: we are good for Apr 3rd
[17:01] <greg-g> jrwren: rock!
[17:01] <greg-g> thanks buddy
[17:02] <snap-l> Awesome! Thanks jrwren
[17:02] <jrwren> i may even have to attend.
[17:03] <greg-g> jrwren: even better
[17:03] <jrwren> ocelot... awesome.
[17:03] <jrwren> oneric, i have to use a dictionary
[17:04] <jrwren> wow, just googled it to Mirriam Webster. That is a great adjective.
[17:05] <jrwren> that womans body is oneiric <-- for the filthy word of the day version
[17:05] <rick_h_> yea, actually used the 'pronouce' on there to say it to me
[17:07] <snap-l> Onerous. ;)
[17:08] <jrwren> i had to double check the phonetics to learn to say it.
[17:08] <snap-l> http://www.merriam-webster.com/dictionary/oneiric <- Other Psychology terms made me laugh
[17:08] <jrwren> oh-nie-rick is how I read it.
[17:08] <snap-l> anxiety, conscience, fetish, hypochondria, intelligence, libido, mania, narcissism, neurosis, pathological, personality, phobia, psychosis, schadenfreude, subliminal
[17:09] <snap-l> oneiromancy - Divination by means of dreams
[17:09] <wolfger> Onery Ocelot?
[17:10] <wolfger> to follow Naughty Narwhal?
[17:10] <brousch> Ornery Ocelot
[17:10] <brousch> follows Pissed-off Piglet
[17:11] <wolfger> brousch++ for correct spelling; brousch-- for incorrect grasp of which letter follows which in the alphabet
[17:11] <snap-l> Perturbed Phytocondrian.
[17:12] <brousch> i use the canadian alphabet
[17:12] <brousch> bunch of backwards dorks
[17:13] <wolfger> Canadian alphabet... every letter is follow by "A"....
[17:13] <wolfger> A, eh? B, eh? C, eh?
[17:13] <snap-l> Just sent out a link to the MUG list with the podcasting links that came up during the presentation
[17:14] <snap-l> Also, Audio Technica's website can die in a fire.
[17:28] <rick_h_> heh, why the fire/dying?
[17:40] <snap-l> They make you have to chose your global location
[17:44] <jcastro> hey rick_h_
[17:44] <jcastro> when you go to pycon
[17:44] <jcastro> find Evan Dandrea and say hi
[17:48] <rick_h_> k, will do
[17:48] <jcastro> rick_h_: he's the installer guy, I need to send a message
[17:49] <jcastro> "Go Wings!" or something of that sort
[17:49] <jcastro> then he will know I sent you
[17:49] <jcastro> mwahahaha
[17:49] <rick_h_> hah
[17:49] <rick_h_> note added
[17:57] <wolfger> Greg Grossmeier has joined identi.ca ?
[18:22] <snap-l> yay, book arrived
[18:22] <snap-l> wolfger: gre-g has been on identi.ca for a while now
[18:22] <snap-l> Hell, he got me on idenit.ca
[18:23] <snap-l> Yay, book arrived early
[18:23] <rick_h_> what book?
[18:23] <snap-l> (*cough*True20 Adventures in Role Playing(*cough*)
[18:23] <snap-l> Revised edition
[18:24] <snap-l> http://true20.com/
[18:25] <rick_h_> man, I'm going to look goofy heading to DTW in shorts
[18:25] <snap-l> greg-g's UID on identi.ca is 158, mine is 160
[18:27] <wolfger> snap-l: According to Linkdin, he just joined
[18:27] <snap-l> Linkedin is not the best gauge of this
[18:29] <greg-g> wolfger: heh, yeah, the group on linkedin
[18:36] <brousch> rick_h_: you leave today for pycon?
[18:36] <rick_h_> brousch: tomorrow
[18:36] <rick_h_> getting packed up today
[18:37] <brousch> good. there's still time for me to stuff you in a trunk and take your spot
[18:38] <rick_h_> brousch: hah!
[18:38] <rick_h_> not likely, I'm getting stoked
[18:38] <rick_h_> seeing the twitter feed flying today
[19:19] <rick_h_> snap-l: ping, was it pro python you were talking about that was a bit much?
[19:19] <rick_h_> a bit heavy
[19:21] <snap-l> It was Pro Python, yes
[19:21] <snap-l> Seemed to get a little dense in the third chapter
[19:21] <snap-l> But maybe it is because I am weak
[19:22] <rick_h_> debating between pro python v python algorightms
[19:22] <rick_h_> for some on the trip reading
[19:23] <snap-l> Cheaper than picking up the PDF version from Apress
[19:23] <rick_h_> ?
[19:23] <snap-l> Pro Python
[19:24] <snap-l> $27.99 Kindle vs $34.99 PDF on Apress
[19:24] <rick_h_> ah, gotcha
[19:24] <rick_h_> suprisingly little amz reviews on both
[19:38] <snap-l> God, I hate SOAP
[19:38] <rick_h_> lol
[19:43] <snap-l> Maybe it's more that I hate SoapUI
[19:45] <rick_h_> no, stick with your first instinct
[19:49] <binbrain> snap-l: SOAP is awful
[19:50] <snap-l> Yeah, no shit. :)
[19:51] <binbrain> I wish it'd hurry up and DIAF
[19:56] <snap-l> ++
[20:42] <brousch> making a logo for west MI linux users group. what do you think? http://dl.dropbox.com/u/101667/wmlug-3.2.png
[20:42] <snap-l> nice! ;)
[20:42] <greg-g> neat
[20:43] <rick_h_> yea, good stuff
[20:44] <brousch> if he farts it will hit detroit
[21:14] <binbrain> brousch: what's wrong with the old one?
[21:15] <binbrain> I was going to the west MI LUG back when we made the 1st logo
[21:15] <binbrain> 10 years ago I guess
[21:17] <brousch> it has no logo
[21:17] <brousch> http://wmlug.org/
[21:17] <brousch> you are probably thinking of the grand rapids linux users group, which does have a logo
[21:18] <binbrain> ahh, your right
[21:18] <binbrain> where does the WMUG meet?
[21:19] <brousch> new horizons learning center on the east side of town
[21:19] <brousch> it formed during a multi-year lull in grlug activity. now grlug is also active and we have double the linux group
[21:20] <binbrain> interesting
[21:24] <brousch> the grlug web site is even crappier than the wmlug one
[21:35] <jcastro> jrwren: http://techcrunch.com/2011/03/09/founder-stories-stack-exchange-spolsky-vc/
[21:45] <gamerchick02> Yay, a new Rick's Rant!
[22:10] <snap-l> Seriously, Facebook comments?
[22:10] <snap-l> I can't read comments on a site without allowing Facebook into my life?
[22:11] <AndIrc_> heh, yep
[22:11] <AndIrc_> it's coming
[22:12] <snap-l> Well, Techcrunch just entered my shitlist again
[22:17] <rick_h_droid> heh, party
[22:21] <rick_h_droid> lococast ep 14 out. get it while it's hot. sorry for the audio
[22:45] <snap-l> rick_h_: Wooooooooot
[22:45] <rick_h_droid> ??
[22:45] <snap-l> lococast release.
[22:55] <gamerchick02> techcrunch is crap. you can't read comments without having a fB account?
[22:56] <gamerchick02> dangit, ya'll i just listened to Rick's Rants...
[22:58] <Blazeix> I sort of think of it as a plus. If you have a facebook account, you're subjected to techcrunch's comments.
[22:58] <Blazeix> If you don't, you're spared.
[22:58] <gamerchick02> good point.
[23:04] <gamerchick02> hrm. my brother's fudge is actually pretty good. very sweet (moreso than regular fudge) but good...


[01:18] <cmaloney> Are we having fun yet?
[01:31] <rick_h_> working on the camper wooo
[03:46] <greg-g> watching On Site With Thomas with Rowan and eating popcorn for dinner since Carrie is at a baby sitting coop meeting thingy
[03:46] <greg-g> also, mentally prepping for tomorrow's flight to Zurich
[11:54] <brousch> greg-g: Wait, there's no baby sitting available during the baby sitting co-op meeting?
[12:02] <rick_h_> morning
[12:11] <cmaloney> Good morning
[12:52] <mrgoodcat> gooood morning campers
[12:53] <brousch> rick_h_: Remote work is part of your Javascript junkie job request, right?
[12:53] <rick_h_> brousch: yea
[12:57] <cmaloney> rick_h_: Was that personality test work-related?
[12:58] <rick_h_> cmaloney: yea, manager training
[12:58] <rick_h_> cmaloney: I took one at my first job out of college as well
[12:58] <cmaloney> I really, really hate personality tests. :)
[12:58] <rick_h_> so comparing the diff (though I don't have the details of my first one)
[12:58] <rick_h_> I wouldn't care but I did it straight out of college and I find the idea of reflecting on changes over 10yr ish to be interesting
[12:59] <cmaloney> Yeah, you've become more tolerant of wrong people. :)
[12:59] <rick_h_> :P
[12:59] <cmaloney> Instead of complete annihilation, you've chosen nihilism.
[13:01] <brousch> Hm, ENTJ seems to fit you well, rick_h_
[13:01] <cmaloney> It's a horoscope
[13:01] <rick_h_> brousch: yea, I was surprised the N turned to S, but then again maybe I've gotten more list-like over time
[13:02] <rick_h_> to be fair, it was only slightly S vs N so I guess I play the middle well enough
[13:02] <cmaloney> I think you've also become more tolerant.
[13:02] <cmaloney> and by tolerant I mean you're not force-choking those who oppose you. ;)
[13:03] <rick_h_> hah
[13:03] <rick_h_> I'll take it
[13:05]  * cmaloney just got an idea for Darth Vader in management training
[13:21] <cmaloney> OK, this is strange
[13:23] <cmaloney> On Reddit: someone posted http://www.reddit.com/r/progmetal/comments/24xnva/fountain_of_lamneth_rush/
[13:23] <bookiebot> http://is.gd/oJWlln - Too Many Requests
[13:23] <cmaloney> hah.
[13:24] <cmaloney> .np squeekyhoho
[13:24] <bookiebot> squeekyhoho's current track - I Think I'm Going Bald by Rush on Caress Of Steel
[13:24] <cmaloney> I _rarely_ play Caress of Steel
[13:24] <cmaloney> but the Squeezebox picked it at random.
[13:54] <brousch> So Jython is not quite dead yet http://fwierzbicki.blogspot.com/2014/05/jython-27-beta2-released.html
[13:54] <bookiebot> http://is.gd/SiYd95 - Frank Wierzbicki's Weblog: Jython 2.7 beta2 released!
[13:54] <jrwren> who cares about jython when pypy is so awesome?
[13:55] <brousch> People who love Swing?
[13:55] <cmaloney> jrwren: Now now now, I'm sure the folks who are interested in Java libraries would take umbrage with your statement.
[13:55] <cmaloney> both of them.
[13:55] <jrwren> brousch: THERE ARE NONE!
[13:56] <brousch> Good luck running your applet on pypy
[13:56] <cmaloney> jrwren: wherever there are two people gathered there will be a magazine.
[13:56] <brousch> Everybody loves applets
[13:56] <cmaloney> brousch: ANd parachute pants.
[13:56] <brousch> It's Java right in your browser!
[13:57] <jrwren> applet?
[13:57] <jrwren> those don't exist.
[13:57] <brousch> I made a Java applet in 1997. that is well after parachute pants were popular
[13:57] <jrwren> i did too, in '96 or 97, was only wya to get audio on a webpage, and I wanted my webpage to play music!
[13:58] <brousch> Well I learned one thing from that blog post. It looks like Maven Central is pypi for Java http://search.maven.org/
[13:58] <bookiebot> http://is.gd/UoZuo1 - The Central Repository Search Engine
[13:59] <jrwren> you didn't know about maven?
[13:59] <jrwren> java folks LOVE maven
[14:01] <brousch> I just encountered it for the first time when trying to build bookie for Android, but I'm not a Java guy
[14:09] <jrwren> i only know of it cuz I know java folks and we talk nerdy
[14:14] <mrgoodcat> what is maven?
[14:14] <mrgoodcat> a build system?
[14:25] <jrwren> like brousch said, its like pypi
[14:25] <jrwren> so... its like rubygems.org
[14:25] <brousch> I think maven is a build system, and Maven Central is pypi
[14:25] <jrwren> it can be.
[14:26] <jrwren> you can also use it with ant, but still trigger maven dependency mgmt
[14:26] <jrwren> although I have no idea how folks do things these days
[14:41]  * cmaloney is checking out Vundle
[14:53] <mrgoodcat> i use vundle
[14:55]  * jrwren ddgs
[14:56] <jrwren> oh! that is the new thingy.
[14:58] <jrwren> I still use pathogen
[14:59] <rick_h_> what does vundle do that pathogen doesn't?
[14:59] <rick_h_> I didn't follow
[15:02] <cmaloney> Vundle allows you to add the plugin in your .vimrc
[15:03] <cmaloney> It's one more layer above pathogen.
[15:03] <cmaloney> rick_h_: I think you're the one person it's not intended for. :)
[15:03] <cmaloney> lepture.com/en/2012/vundle-vs-pathogen
[15:10] <jrwren> i'd do vundle if I were starting over.
[15:10] <jrwren> i'm just too lazy to start over.
[15:10] <brousch> Eclipse4Life!
[15:13] <greg-g> brousch: that'd be a catch-22, it's just getting started.
[15:14] <jrwren> wtf is Eclipse4Life?
[15:18] <brousch> That's what I say to irritate the vimmers
[15:41] <rick_h_> oh, so vundle just does git pulls for you
[15:41] <rick_h_> so you need a new tool to automate that?! cursed open source
[15:43] <brousch> Small, focused tools. If you don't like that, join me in Eclipse4Life
[15:44] <rick_h_> yea, let me get right on that whole 'stab my eyes out' thing
[15:45] <brousch> maybe emacs is more your style
[15:45] <rick_h_> already using a kenisis to avoid wrist pain thanks
[15:45] <jcastro> hey so I tried atom
[15:45] <jcastro> and it's <3
[15:46] <rick_h_> jcastro: :P
[15:46] <brousch> OSX-only. It can DIAF until it runs on Linux
[15:46] <jcastro> it's more of a sublime replacement than a vim replacement
[15:46] <jcastro> runs linux yo
[15:47] <brousch> Front page has only OSX download link, FAQ says only OSX
[15:48] <jcastro> https://github.com/atom/atom#linux-requirements
[15:48] <bookiebot> http://is.gd/wQFR1Q - atom/atom · GitHub
[15:48] <jcastro> it took a while to build though, like 20 minutes on my i7
[15:48] <brousch> Geez, well at least now it doesn't have to DIAF
[15:48] <brousch> Thanks
[15:49] <jrwren> I still don't know what Eclipse4Life means
[15:50] <brousch> It means use Eclipse for the rest of your life
[15:51] <jrwren> Is Eclipse like some tool for watching the moon and sun and earth interact?
[15:51] <brousch> Y U troll me bro?
[15:53] <brousch> Windows requirements for Atom are interesting: Visual Studio 2010 C++ Express, Github for Windows, and Python2.7?
[15:57] <cmaloney> Funnily enough it was the Atom announcement that indirectly got me to try Vundle.
[16:08] <jrwren> yes, I am trolling you brousch :)
[16:34] <ColonelPanic001> Eclipse is a tool for stress testing your CPU and RAM
[16:35] <ColonelPanic001> and your patience
[16:43] <jrwren> I probably would love eclipse if someone ever taught me how to use it.
[16:43] <jrwren> every time I try to learn it, I get angry and stop using it. Its unusable IMO
[16:44] <rick_h_> no...no you wouldn't
[16:45] <jrwren> you are right, I wouldn't love it.
[16:45] <jrwren> I might tollerate it.
[16:45] <jrwren> kinda like redhat based distros... tollerable.
[16:45] <cmaloney> I have the same problem. Every time I play with Eclipse it pisses me off.
[16:45] <jrwren> cmaloney: ^5
[16:46] <rick_h_> i used it professionally and don't miss a thing
[16:46] <cmaloney> It's like having an entire ecosystem based on cargo-cult installation
[16:46] <cmaloney> (coincidentally that's also part of the reason I don't care for Ruby)
[16:47] <cmaloney> (though when compared with Eclipse Ruby's ecosystem seems downright professional)
[16:50] <greg-g> speaking of ruby: https://twitter.com/arirubinstein/status/463848382386040832
[16:50] <bookiebot> http://is.gd/gq8VRY - Twitter / arirubinstein: curl localhost:3000/staraction ...
[16:50] <cmaloney> heh
[16:50] <cmaloney> Wasn't that fixed a while back?
[16:51] <greg-g> http://seclists.org/oss-sec/2014/q2/260 this suggests not?
[16:51] <bookiebot> http://is.gd/qW0gdy - oss-sec: [CVE-2014-0130] Directory Traversal Vulnerability With Certain Route Configurations
[16:51] <cmaloney> Oh ffs
[17:38] <mrgoodcat> cmaloney: what do you mean by cargo-cult?
[17:41] <brousch> Hm, got an email from these guys asking to talk to me. They got my info from GitHub and called me "a Macgyver". Looks kind of interesting actually https://www.truevault.com/
[17:41] <bookiebot> http://is.gd/HE2DwB - TrueVault - HIPAA compliant data store
[17:51] <greg-g> mrgoodcat: https://lmddgtfy.net/?q=cargo+cult
[17:51] <bookiebot> http://is.gd/daQwAL - Let Me DuckDuckGo That For You
[17:51] <rick_h_> lol
[17:51] <greg-g> damnit bookiebot, ruining things
[17:52] <mrgoodcat> lol
[17:52] <mrgoodcat> greg-g: i would have probbably figured it out from the url anyways
[17:52] <mrgoodcat> duck duck go > google
[17:52] <greg-g> those "let me X for you" urls should be short urls/obfuscated
[17:53] <mrgoodcat> you could have shortened it. bookiebot would still have ruined your fun though
[17:55] <greg-g> mrgoodcat: I want *them* to do it for me! I'm lazy!
[17:55] <greg-g> http://ur1.ca/h9vp0
[17:55] <bookiebot> Let Me DuckDuckGo That For You
[17:55] <mrgoodcat> haha. i think lmgtfy has a shorten option
[17:56] <mrgoodcat> it is nice to know what shortlinks are before clicking on them though
[17:56] <greg-g> doesn't look like it, but I've moved on ;)
[17:57] <mrgoodcat> jcastro: i'm building atom on my chromebook right now and it's SOOOO SLOOOWWW
[17:57] <jcastro> heh
[17:57] <jcastro> took about 25minutes on my i7 btw
[17:57] <mrgoodcat> dual core 1.4
[17:58] <mrgoodcat> celeron ftw
[17:58] <cmaloney> celeron: impersonating a real processor since 1995.
[17:58] <mrgoodcat> 2793.71
[17:58] <mrgoodcat> most important number
[17:58] <mrgoodcat> BOGOMIPS :)
[17:59] <mrgoodcat> this celeron is haswell based
[17:59] <jcastro> I am pleasantly surprised at how well the C720 runs
[17:59] <mrgoodcat> same
[17:59] <mrgoodcat> love it
[17:59] <jcastro> I mean, other than compiling software, it's <3
[17:59] <mrgoodcat> although it could use a bit more ram
[17:59] <brousch> Get the 4GB model foolio
[17:59] <jcastro> yeah I put like 16GB of RAM in my machine for chrome, and they're slumming it at 4GB
[18:00] <mrgoodcat> i've got 2
[18:00] <mrgoodcat> couldn't get my hands on the 4 model
[18:00] <rick_h_> jcastro: you went chromebook?
[18:00] <brousch> They come and go
[18:00] <jcastro> rick_h_, I added one
[18:00] <rick_h_> cool
[18:00] <mrgoodcat> i'll get a pixel if i can find a good deal on it
[18:00] <jcastro> it's our couch PC, mostly Jills
[18:00] <mrgoodcat> but pixel doesn't have haswell
[18:00] <mrgoodcat> which is pretty bummer
[18:02] <brousch> mrgoodcat: Currently at Office Depot for $270 (http://www.officedepot.com/a/products/504674/Acer-Aspire-C720-29554G01aii-116-LED/) and Newegg for $265 (http://www.newegg.com/Product/Product.aspx?Item=N82E16834314406)
[18:02] <bookiebot> http://is.gd/3XQqKR - Acer Aspire C720 29554G01aii 116 LED ComfyView Notebook Intel Celeron 2955U 140 GHz by Office Depot
[18:02] <bookiebot> http://is.gd/cRY9pd - Newegg.com - Computer Parts, PC Components, Laptop Computers, LED LCD TV, Digital Cameras and more!
[18:05] <brousch> I might get one of these http://www.pcworld.com/article/2151161/lenovo-announces-n20p-chromebook-with-touchscreen-and-300-degree-hinge.html
[18:05] <bookiebot> http://is.gd/CNcMc5 - Lenovo announces consumer N20 Chromebooks
[18:10] <mrgoodcat> depends on specs
[18:11] <mrgoodcat> i saw that yesterday
[18:13] <mrgoodcat> i'd like to have haswell, >=4gb ram, and a pixel-quality 11-13 inch screen
[18:13] <mrgoodcat> removeable ram and ssd would be nice too
[18:15] <brousch> It has 4GB of RAM, but the usual crappy Chromebook screen
[18:16] <brousch> The Samsung Chromebook 2 13" is the only other one with a nice screen
[18:16] <jcastro> rick_h_,  the way thinkpads are going I am afraid we're all going to end up with chromebooks
[18:17] <mrgoodcat> i <3 cromebooks
[18:17] <cmaloney> Pretty much
[18:17] <brousch> You'll buy your thinkpad with ChromeOS or Windows.  Chromebooks are 11-13" at 1366x768 resolution. It's entirely different
[18:28] <rick_h_> brousch: oh oh oh my bad
[18:29] <rick_h_> brousch: I thought you were talking about cheap laptops still.
[18:30] <mrgoodcat> haters gonna hate
[18:30] <mrgoodcat> i love my c720
[18:31] <jrwren> 1366x768??? fuck that.
[18:31] <mrgoodcat> i don't love the screen
[18:31] <mrgoodcat> but we love our kids even when they eat glue right?
[18:31] <jrwren> i'll never go less than 1440x900
[18:31] <jrwren> mrgoodcat: you got kids?
[18:31] <mrgoodcat> lol no
[18:31] <mrgoodcat> fuckallofthat
[18:31] <brousch> jrwren: Then you need the Samsung Chromebook 2 13" (1080p) or Pixel
[18:32] <mrgoodcat> neither of those have the CPU i want
[18:32] <jrwren> aren't those $$$$
[18:32] <brousch> Samsung is an ARM CPU though, so you can all of the good stuff from Linux
[18:32] <mrgoodcat> haswell is way better for battery life
[18:32] <brousch> can't get
[18:32] <brousch> Pixel can be found for $850 used
[18:32] <jrwren> Samsung Chromebook 2 looks pretty sweet, but I'm not sure I want to run ubuntu ARM
[18:32] <mrgoodcat> i can get 4 of these for that
[18:33] <jrwren> indeed!
[18:33] <jrwren> get 4, and matrix the displays
[18:33] <mrgoodcat> atom has failed to build like 10 times now. i've tried multiple versions of node/npm and running as sudo. i even uninstalled and reinstalled deps
[18:35] <mrgoodcat> bah. needed to set node to use python2
[18:35] <jrwren> years ago there was an X windows virtual server which would display to multiple X windows servers.
[18:35] <jrwren> i wonder if that is still around
[18:36] <mrgoodcat> oh finally it builds
[18:36] <mrgoodcat> slowly
[18:39] <brousch> Node needs Python?
[18:39] <mrgoodcat> jcastro: have you used sublime?
[18:39] <mrgoodcat> brousch: no, but the build script does
[18:40] <mrgoodcat> for atom
[18:40] <jcastro> mrgoodcat, yeah it's my current editor
[18:40] <mrgoodcat> better or worse than atom?
[18:40] <mrgoodcat> i'm building atom right now but ST3 is my current
[18:44] <jcastro> i'ts more finished
[18:44] <jcastro> but I will be transitioning to atom
[18:47] <mrgoodcat> i like that atom is OSS
[18:47] <mrgoodcat> but ST3 is hard to beat
[18:53] <mrgoodcat> jcastro: does atom install fuck with your .profile or anything like that?
[18:53] <jcastro> not afaict
[18:53] <jrwren> git grep .profile
[18:53] <jrwren> will answer that quickly
[18:54] <jcastro> the only issue I have right now is that it takes a long time to build
[18:54] <jcastro> but someone can set up launchpad to build packages eventually
[18:54] <jcastro> oh, and the 5 second start up time isn't so hot either
[18:54] <mrgoodcat> i got it fixed
[18:55] <mrgoodcat> apm is a bad program name
[18:55] <mrgoodcat> since it already exists
[18:55] <jrwren> node-apm isn't it?
[18:55] <jrwren> i mean when debian packaged?
[18:55] <mrgoodcat> what do you mean?
[18:56] <rick_h_> in the debian world things get prefixed
[18:56] <mrgoodcat> apm is the atom package manager
[18:56] <mrgoodcat> ah got it
[18:56] <mrgoodcat> /usr/local/share/atom/atom: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory
[18:57] <mrgoodcat> i have libudev1 and libudev-dev installed
[18:59] <mrgoodcat> i just linked libudev.so.1 to libudev.so.0
[18:59] <mrgoodcat> and atom started....
[18:59] <mrgoodcat> so i hope that wasn't a bad idea
[19:08] <jrwren> looks like you should have libudev0 maybe?
[19:08] <jrwren> its maybe becuase you are on 14.04 instead of 12.04?
[19:11] <mrgoodcat> yea 14.04 doesn't have libudev0 in the repos
[19:12] <mrgoodcat> so here's to hoping they're similar enough not to screw me up :)
[19:13] <jrwren> it likely is
[19:15] <mrgoodcat> started reading the changelog but gave up
[19:15] <mrgoodcat> too long
[19:15] <mrgoodcat> looks like mostly security updates though
[19:15] <mrgoodcat> and bugfixes
[19:15] <jrwren> it comes from system3
[19:16] <jrwren> systemd
[19:16] <jrwren> which likely HAS had a lot of changes since 12.04, but maybe not in libudev :p
[19:16] <jrwren> its TINY: http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev
[19:17] <bookiebot> http://is.gd/5xWseP - systemd/systemd - System and Session Manager
[19:18] <mrgoodcat> why does atom need libudev?
[19:18] <jrwren> great question
[19:19] <jrwren> git grep udev, find out ;)
[19:20] <mrgoodcat> it
[19:21] <mrgoodcat> it's not in there....
[19:21] <mrgoodcat> maybe node needs it?
[19:21] <mrgoodcat> nope...
[19:21] <mrgoodcat> now i'm confused
[19:21] <jrwren> WTF is CSON?
[19:22] <jrwren> coffee script object notation *eyeroll*
[19:22] <mrgoodcat> coffee json
[19:22] <mrgoodcat> you must have seen the mega CSON?
[19:23] <jrwren> i can't pretend to understand how /usr/local/share/atom/atom even ends up being an ELF executable
[19:23] <jrwren> https://github.com/atom/atom is all coffee
[19:23] <bookiebot> http://is.gd/wQFR1Q - atom/atom · GitHub
[19:23] <mrgoodcat> haha
[19:23] <mrgoodcat> read the build script
[19:23] <jrwren> which one?
[19:24] <mrgoodcat> actually not sure
[19:25] <mrgoodcat> idk how it works
[19:44] <mrgoodcat> Did rick_h_ make this? http://vim.sexy
[19:44] <bookiebot> http://is.gd/2ODQaZ - vim is sexy
[19:45] <rick_h_> hah, no
[19:47] <mrgoodcat> seems like something you'd make
[19:47] <jsivak> good to see those new TLD's put to good use.
[19:53] <brousch> OMG WTF. In VB.NET you declare the length of an array by specifying it's last index, but arrays are zero indexed
[19:55] <brousch> So if you want to declare an 8 element array it's dim bleh(7) as whatever
[19:55] <mrgoodcat> so Dim students(6) As Integer actually makes an array of 7
[19:55] <mrgoodcat> lol
[19:56] <brousch> Yes!
[19:56] <brousch> In my case, I was declaring an array based on the length of another array, but it kept coming out with 1 empty element
[19:56] <jsivak> heh, *more* reasons to dislike VB
[19:56] <mrgoodcat> haha
[19:57] <mrgoodcat> length() isn't 0 indexed?
[19:57] <mrgoodcat> but declaring is?
[19:57] <brousch> Correct!
[19:57] <mrgoodcat> BWAHAHA
[19:57] <brousch> WTFBBQ
[19:57] <jsivak> .. actually, I have dim memories about that being one of the "issues" of porting VB to VB.NET.. they had to "inherit" some things..
[19:58] <jsivak> (since the underlying byte-code is probably more like C than VB.. )
[19:59] <brousch> Apparently they break language features in between releases. I have to work in VB.NET for VS 2008 right now. I wonder if they will fix this in newer versions
[20:00] <brousch> I'll put a comment beginning with WTF to mark this stuff
[20:00] <cmaloney> http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:item.detail?hide_menu_area=true&GroupID=460&Code=0B47189
[20:00] <bookiebot> http://is.gd/gMu7N1 - ThinkPad Compact Bluetooth Keyboard with TrackPoint US English | Lenovo | (US)
[20:00] <jsivak> heh.. "ultimate correctness" (e.g. fix in future) or "at least its consistent" (e.g. broken forever).. not sure which is better.
[20:01] <brousch> ooooh, that keyboard is hawt
[20:02] <rick_h_> cmaloney: it's cool but laptop scissor switches :(
[20:02] <cmaloney> Saw popey with two of them (different models I think) and thought of rick_h_
[20:02] <cmaloney> yeah, that's the only downside
[20:02] <rick_h_> oh yea, I've been so tempted many times
[20:03] <rick_h_> see, I do have the ability to resist...once in a while
[20:03] <cmaloney> but hey, that's one way to work around the broken Thinkpad keyboard on their stupid laptops
[20:03]  * rick_h_ says that while opening his new UPS box with three NUCs inside for his upcoming MAAS garage
[20:04] <cmaloney> dafuq?
[20:04] <cmaloney> Which ones did you buy?
[20:04] <rick_h_> jcastro: knows what I'm talking :)
[20:04] <cmaloney> Oh no
[20:04] <cmaloney> I see where this is going already.
[20:05] <rick_h_> business class multi IP service installed next tues
[20:05] <rick_h_> going to have two diff networks at home
[20:05] <cmaloney> juju deploy nuc dafuq
[20:05] <mrgoodcat> wow
[20:05] <rick_h_> http://www.newegg.com/Product/Product.aspx?Item=N82E16856102052
[20:05] <bookiebot> http://is.gd/BLLO9Z - Newegg.com - Intel NUC D54250WYK1 Intel QS77 2 x 204Pin Intel HD Graphics 5000 NUC Kit
[20:05] <mrgoodcat> i should host my shit at rick_h_'s house
[20:05] <cmaloney> mrgoodcat: Pretty soon you will
[20:06] <mrgoodcat> rick_h_: you going to host bmark.us or something?
[20:06] <rick_h_> mrgoodcat: no, it's for work
[20:06] <rick_h_> well, mostly work and playing with juju/charms/etc
[20:06] <rick_h_> but the goal is to have a maas setup teammates can use
[20:07] <cmaloney> Basically rick_h_ is going to have CI for Juju in his basement.
[20:07] <rick_h_> woot!
[20:08] <brousch> Geez. Took me 12 lines of VB to do this code that would take 2 lines of Python
[20:09] <mrgoodcat> pastie for lulz? or proprietary code?
[20:12] <brousch> I really miss list comprehensions http://pastebin.com/NVwmcirs
[20:12] <bookiebot> http://is.gd/7GSd7L - Imports System Imports System.IO Public Class MainForm Dim PATH_TO_BOMS - Pastebin.com
[20:13] <brousch> I'm sure some of it due to not knowing VB.NET well
[20:17] <cmaloney> Python does the same thing re: length of arrays
[20:17] <cmaloney> That's the fun of arrays that start from 0
[20:17] <jrwren> brousch: in VB.NET you can set the base of arrays per file.
[20:18] <jrwren> http://msdn.microsoft.com/en-us/library/aa266179%28v=vs.60%29.aspx
[20:18] <bookiebot> http://is.gd/tFkbw5 - Option Base Statement
[20:18] <cmaloney> jrwren: That sounds like an excellent shotgun for an unsuspecting foot
[20:18] <jrwren> OPTION BASE 0 if you want zero based arrays like a REAL lang :)
[20:18] <brousch> That sounds like a recipe for fun
[20:18] <brousch> It is base 0
[20:18] <brousch> but you define it by the last element, not the length
[20:19] <jrwren> "Basically rick_h_ is going to have CI for Juju in his basement."  I just added Descending to the Order By and it works
[21:17] <brousch> Order By Name Descending
[21:17] <jrwren> oh yup.
[21:17] <jrwren> sorry, i forgot about taht
[21:17] <jrwren> but ye, descending works.
[21:17] <jrwren> see...
[21:17] <jrwren> LINQ
[21:18] <jrwren> linq really makes other lang comprehensions look BAD
[21:18] <brousch> I think you condenced 12 lines of my code to 1
[21:18] <jrwren> I figured I would
[21:18] <jrwren> cuz you can inline that bomDirInfo
[21:18] <jrwren> not bad for a guy who has never written VB.NET :p
[21:19] <brousch> You are today's champion
[21:19] <brousch> So that's LINQ?
[21:21] <brousch> I can actually in-line the first line too
[21:21] <brousch> cmbJobNumber.Items.AddRange((From dirInfo In New DirectoryInfo(PATH_TO_BOMS).GetDirectories() Select dirInfo.Name Order By Name Descending).ToArray())
[21:29] <jrwren> yes, that **From XX In YY Select SSS Order By OO ** is linq
[21:31] <brousch> I was able to adjust it for another similar method too
[21:34] <jrwren> yay!
[21:34] <jrwren> saving U code.
[21:34] <jrwren> I R UR code savior
[21:35] <brousch> You win an Internet Cookie!
[21:36] <jrwren> https://brousch.com/+authorize-token/+login?oauth_token=:p  INET blahblah<PHONE_NUMBER> brousch.com / 15 0
[21:39] <brousch> Wow, this works really nicely now
[21:48] <brousch> jrwren: Thanks for the help.
[22:35] <jrwren> brousch: you are welcome :)


[00:07] <mpt> jam, success!
[00:10] <jam> mpt: so does bzr check on your original branch work?
[00:12] <poolie> lifeless: can you join us if you're still around?
[00:12] <mpt> jam, I'll get back to you on that, it's checking revision 117/38124 :-)
[00:12] <jam> mpt: if it didn't fail right away, that is, indeed a good sign
[00:12] <mpt> jam, however, "bzr log" gives me a KeyError in a different branch
[00:13] <jam> mpt: well, then you need to do the 'bzr branch' with *that* revision, too :)
[00:13] <mpt> woohoo
[00:13] <mpt> ok
[00:14] <mpt> this could be a long night
[00:15] <mpt> thanks for your continued help jam
[00:16] <jam> mpt: I'll be off in a bit, but you can poke at spiv or igc I think
[00:16] <mpt> ok
[00:21] <pickscrape> Well, I've got bzr diff --stat working
[00:27] <tufloc> is there a way to enable user authentication for the dedicated bzr server?
[00:45] <mneptok> tufloc: serve the branch over ssh/sftp
[00:47] <tufloc> I'm starting to miss svn
[01:01] <tufloc> the dedicated server doesn't allow write operations?
[01:03] <mwhudson> it can do
[01:05] <bob2> pickscrape: yay
[01:47] <jml> igc: <3
[01:53] <nhandler> Could someone explain to me how to modify the email address that is used by bzr? It shows up as username@host (where username is my current username and host is the host of my computer).
[01:53] <cody-somerville> bzr help whoami
[01:54] <nhandler> Thanks cody-somerville, that did it
[02:06] <tufloc> any idea what's wrong here? when I try to init-repo the central repository I get this error "bzr: ERROR: No such file: '/dir': [Errno 2] No such file" (using sftp)
[02:08] <mwhudson> tufloc: what was the command line ?
[02:08] <tufloc> bzr init-repo --no-trees sftp://dir
[02:11] <lifeless> spiv: ping; any idea what would trigger InvalidURL: Invalid url supplied to transport: "2e/%2554%2552%2545%2545_%2552%254f%254f%2554.kndx"
[02:11] <lifeless> only happening on remote tests. ..
[02:11] <lifeless> oh; punicode
[02:12] <lifeless> jam: ping
[02:13] <tufloc> mwhudson, nevermind
[02:14] <lifeless> tufloc: you want sftp://host/absolute_path
[02:14] <tufloc> yeah
[02:14] <lifeless> tufloc: or sftp://host/~/homedirpath
[02:45] <lifeless> ok, fetch.py converted
[02:46] <lifeless> well, nearly
[02:56] <igc> lifeless: wrt the Development1 format, currently it says "(needs bzr.dev from before 1.3)" and ...
[02:56] <igc> "This format should be retained until the second release after bzr 1.2."
[02:56] <igc> What do you want those strings to say now?
[02:56] <lifeless> the idea is they roll
[02:57] <lifeless> so if this lands in 1.6 it will say from 1.6
[02:57] <lifeless> (from before 1.6)
[02:57] <igc> and retain until 1.6 + 2?
[02:58] <lifeless> 1.5 + 2
[02:58] <lifeless> so we delete it after 1.7 is released
[02:58] <igc> ok
[02:59] <lifeless> this gives users of a dev format 2 development cycles to toy with it
[02:59] <igc> lifeless: so what's the relationship between development1 and BzrBranch7 if any?
[02:59] <lifeless> development1 incorporates BzrBranch7
[03:00] <lifeless> as well as the new pack format
[03:00] <bob2> does dev1 support rich roots atm?
[03:00] <igc> is development1 needed for stacked branches to land (sorry if that's a dumb Q)?
[03:00] <lifeless> dev1 *is* stacked branches
[03:00] <igc> ok
[03:01] <igc> I wasn't sure if one was a copy of the other or dependent on the other
[03:01] <lifeless> so:
[03:01] <igc> (yet to look at the code in dpeth)
[03:01] <lifeless> development is an alias to the tip of the dev series
[03:01] <lifeless> dev1 is the first dev format to support stacking
[03:01] <lifeless> dev refers to branch7 and packs-that-stack
[03:01] <lifeless> sorry, last line should read dev1 refers ....
[03:02] <lifeless> bob2: no it doesn't - we do need to stack on existing non rich root repos
[03:02] <lifeless> development-rich-root however should (I think I skipped that for development-subtree, this should likely be fixed)
[03:03] <bob2> ah, right - just hanging out for the unification ;)
[03:03] <lifeless> there won't be a unification, but there will be a pivot on the default
[03:04] <pickscrape> I'm looking at getting --stat working as an option to bzr log, but can't find an obvious way to hook it in
[03:05] <pickscrape> That is, without copying and pasting the code from cmd_log, which doesn't strike me as being at all clever :)
[03:06] <lifeless> pickscrape: you may well need to change log to be more hookable
[03:07] <pickscrape> What I really need is a hook that is called after each log entry, which passes the revision and/or tree that can be worked with
[03:07] <pickscrape> lifeless: so I'd need to hack on bzr itself and send to the mailing list etc?
[03:08] <pickscrape> It jsut occurred to me that such a hook would allow glog -p (patch) to be implemented as a plugin also.
[03:08] <pickscrape> s/glog/log/
[03:12] <spiv> lifeless: hmm
[03:12] <lifeless> http://mail.python.org/pipermail/python-dev/2004-July/046416.html
[03:12] <lifeless> is enough for me
[03:12] <spiv> lifeless: I don't recall off the top of my head
[03:12] <lifeless> I don't know if 'sorted()' has the same guarantee, but I happen to have a list
[03:12] <spiv> lifeless: it would, yeah
[03:12] <lifeless> would or does :P
[03:13] <spiv> I would be shocked if sorted() was not stable but list.sort() was.
[03:13] <lifeless> given the impact is more than your shock :)
[03:13] <lifeless> I will use list.sort
[03:14]  * spiv nods
[03:14] <lifeless> also pydoc sorted blows
[03:14] <spiv> pydoc blows.
[03:15] <spiv> file:///usr/share/doc/python2.5/html/lib/built-in-funcs.html#l2h-68 is where it's at.
[03:15] <spiv> (although even that doesn't mention stability)
[03:16] <lifeless> yah, thus my not depending on it
[03:16] <lifeless> pydoc has the potential to be extremely useful, it is saddening that it is not
[03:16] <spiv> Sure.
[03:16] <pickscrape> lifeless: how would you recommend making cmd_log more hookable? Using a mechanism like post_push etc or something more raw like an overridable method of cmd_log?
[03:17] <lifeless> pickscrape: well, I think the general concept here is that log -v, log --diff, log --stat all need the same minimum data: a tree delta
[03:18] <lifeless> pickscrape: so I'd think of it as selecting which filter to pass tree deltass through during log
[03:18] <lifeless> pickscrape: -> a registry of filters, and the core code calls into that
[03:18] <pickscrape> lifeless: Bearing in mind that the user might be asking for more than one filter at the same time.
[03:19] <pickscrape> Could quite legitimately want to do bzr log -p --stat
[03:19] <lifeless> pickscrape: sure. may need some infrastructure work to allow selecting multiple items from a registry
[03:20] <pickscrape> The existing formats could also be rewritten as filters in this registry too.
[03:20] <lifeless> pickscrape: the ones that do tree deltas yes - thats exactly what I'm suggesting
[03:20] <lifeless> --line vs the default is already registry based
[03:21] <lifeless> they select what revisions are shown and ordering; somewhat different part of the code path for log
[03:22] <pickscrape> I'll have a think about that then. It certainly seems that log --stat is impossible without it.
[03:32] <kumi_> Just curious, what benefits does rich-root have over pack-0.92?
[03:32] <kumi_> Or rich-root-pack (what's the difference with rich-root?)
[03:33] <poolie> kumi_: this format puts a unique id on the root directory, so it can be used with versioned subtrees (like svn externals) and split/join-
[03:34]  * kumi_ looks up svn externals
[03:35] <poolie> basically so that you can link an external library into a subdirectory of your project
[03:38] <kumi_> Nice. I can think of several places where that would be useful to me
[03:41]  * igc lunch
[03:41] <lifeless> abentley: around?
[03:41] <abentley> lifeless: Hi.
[03:42] <lifeless> I have a question about rich root root id generation during fetch
[03:42] <jfro> hey all, quick question, is there a way to edit a file in a past revision, like say if you accidentally committed a hard-coded password in your code =P
[03:42] <abentley> lifeless: Okay.
[03:42] <lifeless> the parents list for the new root text is the revisions parent list - revisions with different root ids, and including ghosts
[03:43] <lifeless> did you consider looking up the root id in the revision tree of revisions with different roots, to find root-renames done in those trees?
[03:43] <abentley> That doesn't sound like a good idea.
[03:43] <lifeless> which line are you replying to :)
[03:43] <abentley> The first.
[03:44] <abentley> I wasn't considering root ids changing.
[03:44] <lifeless> the first was a paraphrase of the comment in the existing code
[03:44] <abentley> Oh, well maybe I was.  I don't remember that...
[03:44] <lifeless> fetch.py line 390 in bzr.dev
[03:45] <kumi_> Is it possible to try rich-root in version 1.5?
[03:45] <lifeless> anyhow, It seems to me that running reconcile after generating these texts could find mismatched parents with the current code, because it does look at the full inventory of each tree
[03:45] <abentley> lifeless: That says we *drop* parents with different file_ids.
[03:45] <lifeless> abentley: yes, I meant drop with my use of '-', sorry for confusion
[03:46] <lifeless> revisions_parent_list.subtract(changed_ids)
[03:46] <abentley> lifeless: It looked like a dash to me.
[03:46] <lifeless> kumi_: it is, there are some caveats: its a one way conversion
[03:46] <lifeless> kumi_: we plan to make it the default soon
[03:46] <kumi_> I think I'll wait, thanks lifeless
[03:47] <lifeless> abentley: ok, with the confusion sorted, the next line was my actual question: did you consider looking for that id elsewhere in the other tree
[03:47] <kumi_> btw I fixed that windows problem you helped with yesterday. thanks again
[03:47] <lifeless> kumi_: excellent
[03:47] <lifeless> kumi_: I saw the comment in the bug; I wonder if we can make the error nicer/more clear
[03:47] <abentley> lifeless: I don't think I did.
[03:48] <kumi_> lifeless: yes, if it mentioned where the error came from "plink.exe", that would be enough
[03:48] <lifeless> abentley: ok. I'm not going to change this code, I just wondered while looking. Could you think about it at some point?
[03:48] <lifeless> abentley: (well, I have to rephrase the code to new apis,but I'm not changing the intent of the code)
[03:49] <abentley> Sure.
[03:49] <abentley> What I was aiming for was a conversion that was reasonably hi-fi, but definitely with good performance.
[03:50] <abentley> And definitely reproduceable.
[03:51] <lifeless> right, which we have. It seems a shame if (and I think it does) reconcile and check were to find things to do post-conversion ;).
[03:53] <abentley> lifeless: Not a tragedy, though, since only experimental versions of Bazaar could get into that situation.
[03:55] <lifeless> abentley: couldn't converters ? e.g. arch could have an id be root one commit elsewhere another in theory
[03:55] <abentley> I don't think converters touched root ids.
[03:56] <abentley> Not until bzr-svn went dirstate-with-subtree on us.
[03:56] <lifeless> mmm, I'd need to check
[03:56] <lifeless> anyhow, I'm not fussed, you know the implications at least as well as I do
[03:57] <lifeless> 19 references to weave_store in bzrlib/*.py to go
[03:57] <lifeless> argh!
[03:57] <lifeless> weave_modifed_revisions = set(file_weave.versions())
[03:57] <lifeless> all-of-history calls die die die
[04:21] <poolie> lifeless: we need something stronger than -Devil i think
[04:21] <poolie> cutely name though it is
[04:21] <lifeless> poolie: what d you mean by stronger?
[04:26] <pickscrape> -Dsatanic
[04:30] <jamesh> -Dponies
[04:30] <lifeless> but we have one
[04:33] <poolie> lifeless: i mean one that's harder to ignore
[04:34] <lifeless> poolie: e.g. output to console not just log?
[04:35] <poolie> i guess the only thing is to actually fix them then make them fail the tests
[04:38] <lifeless> I think thats the only workable approach
[04:38] <lifeless> some O(history) operations are necessary
[04:38] <lifeless> I really should tackle log at some point
[04:38] <lifeless> but I want to cry when I see the code
[04:49] <mwhudson> log.py needs a lot of love
[04:49] <mwhudson> (also, revision numbering)
[04:50] <beuno> +1 to revision numbering  :)
[04:58] <lifeless> users seem to really like it
[04:58] <igc> lifeless: is there a reason why add_falback_repository in repository.py checks for format compatibility but ...
[04:58] <igc> the one is remote.py does not?
[04:58] <lifeless> igc: yes
[04:59] <igc> and it is ...?
[05:00] <lifeless> its only a proxy object
[05:00] <thumper> poolie: I just want to make sure you are aware of the bzr client side stacking policy stuff that abentley has and its need to be in 1.6 with the other stacking stuff.
[05:00] <lifeless> or perhaps its oversight. But I think that was my thinking in february
[05:24] <igc> thumper: your alias patch is merged to bzr.dev now
[05:24] <thumper> igc: w00t
[05:40] <igc> pqm seems much faster today. Thanks to whomever enabled the 'go-fast' option.
[05:46]  * igc pick up kids
[05:57] <lifeless> abentley: I plan to add a file_id parameter to PlanMerge, does that seem ok? (vf is now a VersionedFiles so we need a prefix
[05:59] <kumi_> Hmm, I have an error when I try bzr st: KeyError: 'pop(): dictionary is empty'
[06:00] <lifeless> kumi_: there was a bug in merge, it is fixed in mainline I believe
[06:00] <lifeless> kumi_: you have just done a merge haven't you ?
[06:00] <kumi_> oh dear
[06:00] <kumi_> yeah I just did
[06:00] <lifeless> just revert
[06:00] <kumi_> Alrighty
[06:00] <kumi_> Is there any way to get around this?
[06:01] <lifeless> well, you probably did merge and then merge --force?
[06:01] <kumi_> Nope, just bzr merge -c 161
[06:02] <abentley> lifeless: That makes sense.
[06:02] <lifeless> kumi_: its probably already merged; I think grabbing the latest bzr.dev may be the most straight forward solution
[06:02] <abentley> lifeless: At some point, if we're brave, we might allow multiple file ids :-)
[06:02] <lifeless> abentley: I'm trying to balance scope creep, and updating apis towards that as I go
[06:02] <lifeless> but yeah :)
[06:03] <kumi_> lifeless: unfortunately I can't do that (on Windows and I don't know how to compile)
[06:03] <lifeless> kumi_: oh, there is no need to compile
[06:03] <lifeless> kumi_: if you have python already installed you can just branch bzr and run it; if you don't then its more tricky. Do you have python installed ?
[06:03] <kumi_> Yeah, I have Python 2.5
[06:04] <lifeless> then bzr branch http://bazaar-vcs.org/bzr/bzr.dev <some-path-here>
[06:04] <lifeless> I think there is a bzr.bat included in there by default
[06:04] <kumi_> Cheers, I'll try that
[06:05] <kumi_> is bzr.dev usually in a stable state?
[06:05] <lifeless> if there isn't say so and I'll help you
[06:05] <lifeless> we run all our regression tests before every merge - we try to keep it immediately releasable
[06:05] <kumi_> nice :)
[06:06] <lifeless> (except for occasional massive feature drops, they tend to cause issues no matter how hard we try - but even then its still passing tests)
[06:12] <kumi_> Out of curiosity, is there a way to branch the point releases?
[06:12] <lifeless> I think there are tags, there are also separate branches for each release
[06:12] <kumi_> gotcha
[06:25] <kumi_> I branched bzr.dev and I put it in a directory away from my 1.5.0 files. If I run C:\bin\Python25\python.exe G:\temp\bzrdev\bzr version, it's not using it's own path for bzrlib
[06:27] <kumi_> I will try the start_bzr.bat that is in bzr.dev (have to modify it because it uses bzr.exe)
[06:28] <poolie> abentley: hitchhiker is very cool
[06:28] <abentley> poolie: thanks.
[06:28]  * jml was thinking the same thing.
[06:29] <abentley> poolie: I deliberately left out write commands for now.
[06:29] <abentley> I
[06:29] <abentley> I'm not sure any good would come of that.
[06:30] <kumi_> Where is the BZR_HOME environmental variable supposed to point to?
[06:30] <bob2> kumi_: normally it's unset and HOME is used
[06:30] <spiv> kumi_: generally you don't want to set it
[06:30] <kumi_> the location of bzr, tools, doc, contrib, etc? Or the location where bazaar.conf etc are located?
[06:31] <kumi_> OK
[06:32] <poolie> kumi_: if it's not set it defaults to ~/.bazaar on unix
[06:32] <poolie> not sure where on Windows but bzr --version should show it
[06:33] <kumi_> That's why I asked, it doesn't explicity mention "home"
[06:33] <kumi_> only "Bazaar configuration" and "Bazaar log file" directories. All looks fine, though
[06:34] <poolie> i think it's the first
[06:35] <abentley> poolie: It looks like it defaults to ~/ on unix
[06:35] <kumi_> me too
[06:41] <kumi_> On Windows, if you set BZR_HOME to c:\foo, it will put configuration files in c:\foo\bazaar\2.0, and the log file in c:\foo\.bzr.log
[06:50] <lifeless> hitchhiker?
[06:52] <poolie> lifeless: a text-mode client for bzr transports
[06:52] <lifeless> lftpesque?
[06:54] <poolie> yes
[07:00] <kumi_> lifeless: it worked! Thanks a million
[07:01] <lifeless> kumi_: cool
[07:09] <kumi_> hm, automirror doesn't seem to work when a revision is pushed
[07:13] <lifeless> igc: you have removed the use of chain, but kept the import :P
[07:26] <igc> lifeless: o damn - I'll fix that
[07:27] <igc> lifeless: any further thoughts on that RemoteRepository check of fallback issue?
[07:27] <lifeless> no
[07:28] <igc> I'm just wrapping up my review of the Development1 thread and the rest is ok  I think
[07:29] <lifeless> I don't think we want to merge the formats just yet, because they are so limited
[07:29] <lifeless> but perhaps I'm wrong
[07:30] <igc> as in the development1 formats?
[07:31] <lifeless> yes.
[07:31] <lifeless> lets start at the bottom and work up
[07:31] <lifeless> get them fully ready to merge at minimum
[07:32] <igc> lifeless: so some quick Qs if you have time
[07:33] <igc> the new init method in BzrBranch6?
[07:34] <igc> it's saving development1... as the metadir
[07:34]  * igc pulls up the diff
[07:35] <igc>     def __init__(self):
[07:35] <igc>         super(BzrBranchFormat6, self).__init__()
[07:35] <igc>         self._matchingbzrdir.repository_format = \
[07:35] <igc>             RepositoryFormatPackDevelopment1Subtree()
[07:36] <lifeless> yes
[07:36] <lifeless> thats for testing
[07:36] <igc> lifeless: any side-effects from that?
[07:36] <lifeless> yes, tests run with old branches, new repositories. Its good :)
[07:37] <poolie> i'm trying to page back in the countedlock refactoring
[07:37] <poolie> which is meant to eventually help Remote objects stay in sync with their vfs objects
[07:37] <poolie> want to finish it off anyhow
[07:38] <igc> lifeless: and is all_revision_ids() still meant to return a list? Or just a sequence now?
[07:39]  * igc wondering why check.py needed the list() added around all_revision_ids()
[07:39] <lifeless> igc: well, if you remove it and it fails, it needs it ;P
[07:39] <igc> some tests were updated to put set() around things which is fine of course
[07:41] <igc> lifeless: the code change is harmless enough but I'll update the al_revision_ids docstring if it's no longer correct
[07:41] <lifeless> what does it claim ?
[07:41] <igc> I guess it would need to be added to API CHANGES/BREAKS as well if it no longer aways returns a list
[07:41] <igc> "Returns a list ..."
[07:42] <lifeless> yeah thats false now, lists are very slow at duplicate detection
[07:43] <igc> ok - I'll tweak that docstring
[07:43] <igc> and update NEWS
[07:48] <igc> poolie, spiv: is one of you able to review the external_references tests patch please?
[07:49] <lifeless> igc: I can review your changes if they are busy
[07:49] <igc> lifeless: in this case, they had already reviewed that code
[07:50] <lifeless> igc: ah, k
[07:50] <poolie> i can
[07:50] <igc> poolie: thanks. you had voted tweak earlier though it may need some more given spiv's comments
[07:50] <poolie> it's a good time, i just worked out what patch i want to do but haven't started
[07:50] <poolie> is this
[07:51] <poolie> igc hm the only patch about that i see was in february
[07:51] <poolie> ok i see it
[07:51] <poolie><EMAIL_ADDRESS>right?
[07:51] <igc> poolie: https://lists.ubuntu.com/archives/bazaar/2008q1/037703.html is the earlier thread
[07:51] <igc> poolie: that's the one
[07:53] <poolie> +from bzrlib.tests import (
[07:53] <poolie> +                          adapt_modules,
[07:54] <poolie> not a big deal but can you make them just indented by 4 spaces in future, as the others are
[07:54] <poolie> (might not even be your code)
[07:56] <lifeless> I think the rest of the others were deep
[07:56] <lifeless> or something
[08:02] <poolie> i wish the boilerplate in load_tests wasn't proliferating the way it is
[08:09] <poolie> igc, sent
[08:17] <igc> poolie: thanks
[08:18] <igc> lifeless: please let me know if you have any comments on poolie's requested tweaks
[08:20] <lifeless> so, they seem fine
[08:20] <lifeless> the scenario tuple is name, dict_of_things
[08:20] <igc> lifeless: and vila has voted resubmit
[08:20] <poolie> i'll reply to vincent
[08:20] <lifeless> the multiply_ method is different, I did look at reusing but its at the wrong level
[08:21] <lifeless> - it does too much
[08:22] <igc> poolie: thanks. Did you mind submitting this to pqm as well, once tweaks are agreed?
[08:25] <lifeless> vila: ping; please look at bzrlib/tests/*_implementations/__init__.py
[08:27] <vila> lifeless: regarding adapt_modules ? or regarding defining adapter classes ?
[08:27] <lifeless> regarding the need
[08:28] <lifeless> to adapt many modules identically
[08:28] <lifeless> (we do it *all the time*)
[08:28] <vila> I'm fine with using adpat_modules, I'm not with gettind rid of adapter classes
[08:29] <lifeless> vila: I want to nuke them all
[08:29] <vila> the adpater classes ?
[08:29] <lifeless> yes, there should only be one
[08:29] <lifeless> application and generation of scenarios are different responsibilities
[08:30] <lifeless> this became clear some time after first creating the ability to adapt at all
[08:30] <lifeless> tests.TestScenarioApplier is meant to be used as an instance, not subclassed; its subclassable for historic reasons onl
[08:30] <lifeless> y
[08:31] <vila> hence my tendency to call the classes adapters not appliers :)
[08:31] <lifeless> its fine to have a class for generating scenarios that you reuse and extend, but it shouldn't subclass the applier
[08:32] <lifeless> instead have it provide the scenarios and use them with a stock applier
[08:33] <vila> lifeless: I never thought about it but I fully agree, just apply that sentence to my comments
[08:33] <vila> ..with the stock applier of course ;)
[08:33] <lifeless> (which it uses :P)
[08:34] <vila> so adap_tests and adapt_modules will become methods ? Sounds coherent.
[08:35] <lifeless> errr
[08:35] <lifeless> I'm scrambled now
[08:36] <lifeless> this is 4 month old code and I'm deep updating merge
[08:36] <lifeless> can I come back to this?
[08:38] <poolie> hello vila
[08:38] <vila> hi poolie ;)
[08:39] <poolie> i sent mail wihch i think robert will agree with
[08:39] <poolie> bit i can never tell
[08:39] <poolie> oh the scrollback does make it look like he would agree
[08:39] <lifeless> thats why there is you, and me, vive la difference!
[08:39] <poolie> but*
[08:43] <poolie> vila, i may be missing the point somehow
[08:50] <vila> poolie: well, I'm waiting for your mail, but seeing Robert comments, I think I need to re-read the code with the idea of separating scenario generation and application, I'm deep into other subjects right now. I remember being uneasy with the adap_test and adpat_modules functions but not *why* I thought subclassing applier was the best solution
[08:51] <vila> I remember it vastly simplified the http tests where many combinations were required between transport implementation/proxy/auth schemes with tests needing various combinations
[08:51] <vila> but may be that's specific to http
[08:54] <lifeless> vila: I think you would find the repository_check_reconcile permutations enlightening
[08:55] <lifeless> they do a cross product test permutation
[08:56] <lifeless> nearly done
[08:56] <lifeless> 17 references to go outside of tests
[08:57]  * jml always wants to say "cartesian product" not "cross product".
[08:57] <lifeless> fine
[08:57] <jml> but I guess the latter makes sense.
[08:58]  * vila always translate 'cross product' into 'produit cartesien' ;-)
[08:58] <jml> heh heh
[08:58] <RAOF> Not to be confused with the _actual_ operation 'cross product' :)
[08:59]  * vila also has no trouble translating applier into 'adapteur' hence he missed lifeless point ;)
[09:00] <vila> lifeless: url ? grep repository_check_reconcile bzr.dev gives no matches :)
[09:01] <poolie> :)
[09:02] <lifeless> test_check_reconcile.py
[09:02] <lifeless> and __init__.py
[09:02] <lifeless> in repository_implementations package
[09:02] <lifeless> back soon -> atm
[09:02] <lifeless> poolie: ringing you for brief chat
[09:03] <poolie> jml, hm, Cartesian product seems more correct
[09:04] <jml> poolie: especially since the ordering doesn't matter, since they are unit tests.
[09:04] <poolie> lifeless: ready whenever
[09:05] <jml> iirc, cross product makes sense if you define multiplication as 'cons'
[09:08] <spiv> Ah, I just accidentally found the bug in the test suite that allowed bug 237067 to happen.
[09:13] <poolie> spiv, good for you
[09:16] <lifeless> mobiles work better with battery power
[09:26]  * igc dinner
[09:31] <vila> lifeless: class RepositoryTestProviderAdapter(TestScenarioApplier): explains my confusion I would say :) Or are you referring to a newer, yet unknown to me, implementation ?
[09:31] <vila> lifeless: hmm, no, I think you meant:     broken_scenario_applier = TestScenarioApplier()
[09:31] <vila>     broken_scenario_applier.scenarios = broken_scenarios_for_all_formats
[09:31] <vila> which better illustrates your point
[09:35] <vila> poolie, igc, lifeless: I just realized I did  class ServerAdapter(tests.TestScenarioApplier): in my local_test_server plugin just to define a dict :-)
[09:47] <lifeless> vila: yes :)
[09:47] <lifeless> vila: this is the point really
[09:47] <lifeless> also
[09:47] <lifeless> crying tiger++
[09:49] <vila> lifeless: consider me enlightened then :) But not for the tiger though...
[09:49] <lifeless> its thai food
[10:27] <awilkins> It's the new filem "Crying Tiger, Sulking Dragon"
[10:30] <proppy> Hi, I get the following when installing bzr on ubuntu-hardy
[10:30] <proppy> http://pastebin.com/m76595733
[10:30] <proppy> is this a known problem ?
[10:32] <Peng> I don't think scrollkeeper is related to bzr.
[10:33] <poolie> oops
[10:33] <poolie> proppy: please report a bug against scrollkeeper
[10:33] <proppy> poolie: thanks for the direction :)
[10:34] <proppy> poolie: https://edge.launchpad.net/scrollkeeper/+filebug ?
[10:34] <proppy> or scrollkeeper package in ubuntu ?
[10:35] <proppy> https://bugs.edge.launchpad.net/ubuntu/+source/scrollkeeper/+filebug
[10:35] <poolie> the second is better but either will do
[10:41] <proppy> poolie: reported https://bugs.edge.launchpad.net/ubuntu/+source/scrollkeeper/+bug/237579
[11:21] <strk> is this the #bzr branch ? :)
[11:22] <strk> ok, serious question: does bzr support aliases for locations ?
[11:22] <jamesh> strk: there is a bzr bookmark plugin you might want to try
[11:22] <Peng> Ooh, you were just barely too fast for me.
[11:22] <jamesh> https://edge.launchpad.net/bzr-bookmarks
[11:23] <jamesh> https://launchpad.net/bzr-bookmarks
[11:23] <nasloc__> anyone know how to update partial (like only doc directory) in a checkout?
[11:24] <nasloc__> I wanna update part of working tree, not full of them.
[11:24] <Peng> nasloc__: I don't think you can do that.
[11:24] <Peng> nasloc__: You can revert only parts of a tree, but that doesn't help if you want to update to a new revision..
[11:25] <nasloc__> Peng, oh :(  because svn can do that and my partner says he would use bzr over svn if bzr supports that.
[11:26] <nasloc__> Peng, thanks anyway.
[11:26] <Peng> nasloc__: With Bazaar, you'd finish your work and commit, then merge new changes. Not sure how that translates to checkouts though..
[11:27] <jamesh> nasloc__: you can always use multiple branches
[11:27] <jamesh> if you generally edit a subset of a tree as a unit, then perhaps it should be its own branch
[11:30] <nasloc__> jamesh: ok I'll check if that works. thanks
[12:05] <james_w> yay! Bazaar shirt.
[12:23] <gour> james_w: where, what, how...
[12:33] <james_w> gour: it just arrived in the post.
[12:33] <james_w> they were a gift for all contributors to celebrate the 1.0 release. Mine just took a bit of time to arrive.
[12:37] <gour> heh...next time let's think to better contribute...well, we're still news with bzr
[12:37] <gour> s/news/new
[13:23] <j^> jam, regarding the bzr_access cleanup, i put a patch at http://oil21.org/~j/patches/bzr_access.permission_fix.bundle
[13:31] <strk> we're doing some tests with bzr. I get:
[13:31] <strk>   Path conflict: a_silent_test_file / RENAMED_TEST
[13:31] <strk> how to resolve such conflicts ?
[13:36] <james_w> strk: put the file that you want at the path and then "bzr resolve <path>"
[13:36] <james_w> I've never had to deal with one, so I can't be more specific, sorry.
[13:37] <strk> mm, I did bzr resolve a_silent_test_file
[13:37] <strk> resolved, but kept the other :)
[14:28] <igc> abentley: if you're around, can you help me with some subtree Qs?
[14:29] <abentley> igc: Okay.
[14:29] <igc> looking at sprout() in bzrdir.py, what's the recurse_branch bit about?
[14:29] <igc> the variable isn't used ...
[14:29] <igc> which might well be a bug
[14:30] <igc> Also, do you think shallow=shallow ought to be passed?
[14:30] <igc> (in lifeless' branch that is)
[14:33] <lifeless> igc: I would say shallow should propogate to child trees, yes.
[14:34] <igc> thanks. I could see why they wouldn't
[14:34] <igc> s/could/couldn't/
[14:34] <abentley> igc: Nesting generally requires a tree and a branch.
[14:35] <abentley> Because the location of the nested tree's branch is determined by the current tree's branch.
[14:36] <igc> ok
[14:37] <abentley> So it looks like the loop at 1009 may be buggy.
[14:39] <abentley> If buggy, it's buggy for a scenario where a lightweight checkout is being sprouted.
[14:42] <abentley> Actually, I'm not sure source_branch can ever be None when branching.
[14:43] <abentley> In the lightweight checkout scenario, I think it would be set to the lightweight checkout's branch.
[14:43] <igc> abentley: I'd expect so.
[14:44] <igc> So do you think recurse_branch can be safely deleted?
[14:44] <abentley> I think so.
[14:45] <igc> me too. It looks like it was going to be used by then wasn't needed ... or something like that.
[14:45] <igc> s/by/but/
[14:45] <igc> abentley: thanks.
[14:46] <abentley> igc: What's the purpose of your branch for shallow branch support?
[14:46] <igc> I'm just reviewing Robert's work and making any minor tweaks as I go
[14:48] <abentley> Are you working with Robert's prototype or the final one based on VersionedFiles?
[14:49] <igc> the one lifeless asked me to merge bzr.dev into
[14:49] <igc> I've run export-loom and I'm working my way up the stack
[14:49] <igc> reviewing each thread
[14:50] <igc> lifeless has agreed to review my tweaks and then I'll merge the pieces, giving him time to continue on the VersionedFile stuff
[15:28] <abentley> igc: Would it be appropriate to land my stacking policy stuff on that?
[15:29] <igc> abentley: sure
[15:29] <igc> I'm just putting up the next patch now fwiw
[15:34] <abentley> igc: Are you in Sydney?
[15:34] <igc> Brisbane
[15:39] <abentley> Well, that's dedication.
[15:40] <igc> and deadlines :-)
[15:51] <igc> that's it from me today - night all
[16:15] <barry> hi bzr hackers.  i'm having some trouble integrating setuptools_bzr with looms.  i'm wondering if anybody is available to lend some help
[16:30]  * khaeru bleats
[16:30] <khaeru> Anyone home?
[16:32] <abentley> barry: I can help later, but I'm putting out fires right now.
[16:33] <barry> abentley: thanks!  no rush, i have a hackaround in place right now.  ping me when you're free?
[16:33] <abentley> will do.
[16:34] <barry> abentley: thx!
[17:05] <proppy> regarding testing deferToThread addition
[17:05] <proppy> here is the failing test
[17:05] <proppy> http://proppy.aminche.com/hg/service-test/rev/583aae136706
[17:05] <proppy> and the patch that make test pass http://proppy.aminche.com/hg/service-test/rev/1c8716677930
[17:05] <proppy> someone care to parse it ?
[17:08] <proppy> oops wrong channel
[17:08] <proppy> :)
[17:22] <abentley> barry-away: What can I do for you?
[17:37] <plexq> how do I list what changes where in a revision?
[17:43] <Kinnison> how do you mean?
[18:09] <barry> abentley: https://bugs.edge.launchpad.net/setuptoolsbzr/+bug/237652
[18:10] <abentley> barry: from bzrlib.plugin import load_plugins; load_plugins()
[18:10] <barry> abentley: that'll load the loom plugin and install any necessary hooks?
[18:11] <abentley> barry: Right.  Especially, in this case, it will register the loom branch formats.
[18:11] <barry> abentley: awesome, thanks
[18:11]  * barry is trying it...
[18:16] <barry> abentley: works like a charm.  thanks!
[18:16] <abentley> You're welcome.
[19:18] <radix> Stacked branches sound awesome. It sounds like it'll make using launchpad code hosting much more practical.
[19:24] <gour> radix: they won't be in 1.6?
[19:24] <radix> gour: what?
[19:25] <gour> stacked branches
[19:25] <radix> gour: Was that meant to be a statement?
[19:26] <radix> I don't understand the question.
[19:26] <gour> stacked branches will not be ready for bzr-1.6, right?
[19:27] <radix> gour: I don't know, I'm not a bazaar developer.
[19:27] <radix> gour: I just read jam's blog about them.
[19:27] <radix> http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html
[19:27] <gour> i'm speaking based on what i heard here, iirc
[19:28] <pygi> shhh gour again :)
[19:29] <gour> pygi: ;)
[19:40] <jam> gour: well, we are reviewing the changes to hopefully get it landed today
[19:41] <jam> at least as a dev format
[19:54] <gour> jam: great. you working tirelessly to improve bzr
[19:55] <gour> i'm waiting to finish some written assignments (still under darcs) and then we'll conduct a big darcs --> bzr migration
[19:55] <jam> we try, I do get tired sometimes :)
[19:55] <kumi_> wow, more sexy new features :)
[19:56] <pickscrape> The rate and quality of work done on this project astounds me.
[19:57] <gour> jam: hopefully you don't code too much when getting tired ;)
[19:57]  * gour agrees with pickscrape
[19:57] <pickscrape> I think that's testament to the tool too, which presumably helps a great deal :)
[19:57] <jam> naw, that's when I review code :)
[19:58] <jam> pickscrape: well, we have some decent processes in place. Though honestly as a developer it is a slightly different view
[19:58] <jam> *big* changes are easy because of our process
[19:58] <jam> *small* changes end up with a lot of process overhead versus their actual impact
[19:59]  * gour hopes to become somewhat familiar with python to be able to help a bit in the future. for now we're busy working on a haskell (project)
[19:59] <jam> 11,000 unit tests can be a great thing, and can be a bit of a pain at the same time :)
[20:04] <pickscrape> :)
[20:04] <pickscrape> Our developers have a simple solution to that problem: don't write them and don't bother to run them.
[20:40] <schierbeck> you guys know if there's a bzr-svn ppa?
[20:41] <Peng> bzr-svn is in the main bzr PPA.
[20:42] <beuno> AFAIK, that version doesn't work the bzr 1.5, which is the version in PPA
[20:42] <beuno> but jelmer would know best
[20:42] <schierbeck> ok
[20:42] <schierbeck> i was hoping there was a more recent version
[20:42] <Peng> Yeah, ppa compatibility sucks.
[20:42] <Peng> Well, in this case, it's not the ppa's fault really, but still. :P
[20:42] <jelmer> bzr-svn isn't in PPA anymore
[20:42] <Peng> Oh?
[20:43] <Peng> Where is it?
[20:43] <jelmer> the only packages available are my packages for Debian Sid (http://samba.org/~jelmer/debian)
[20:44] <schierbeck> cool
[20:48] <schierbeck> what about bzr-avahi?
[20:49] <schierbeck> can't find a ppa for that either
[21:12] <jam> new this week post
[21:13] <jam> for those who want there news right away
[21:13] <jam> http://jam-bazaar.blogspot.com/
[21:21] <pickscrape> jam: an interesting read, and something for us to think about when we come to migrate to bzr
[21:29] <bimberi> jam: Thankyou.  I look forward to seeing how Elliot is described each week. ;)  You've invented "pair-blogging"!
[21:30] <jam> yeah, statik is pretty creative in that regard
[21:30] <jam> In our case, the pairing is mostly out of necessity, I tend to write too much or too little
[21:31] <jam> statik is good about helping to make sure it isn't all just a stream-of-consciousness out of me
[21:31] <jam> and he is certainly better about humor
[21:32] <statik> aw shucks
[21:33] <bimberi> :)
[21:37] <pickscrape> I tend to ramble bit time when I write.
[21:37] <pickscrape> big time
[22:32] <lifeless> moin
[22:46]  * beuno hugs bzr shelve/unshelve
[22:47]  * pickscrape wonders why the shelf isn't core
[23:05] <beuno> mwhudson_, howdy    :)
[23:05] <mwhudson_> beuno: i hate my isp
[23:05] <beuno> mwhudson_, I think most people here do   :p
[23:06] <beuno> ever thought about irssi on a server somewhere stable?
[23:06] <mwhudson_> as of this morning, we're moving house though, hopefully the connection will be more stable there
[23:06] <mwhudson_> beuno: yes i have, but not done anything about it
[23:06] <beuno> mwhudson_, if you don't like irssi, there is ircproxy, which is client-agnostic
[23:06] <beuno> but, if you're moving, that may help
[23:07] <bob2> irssi_proxy is quite spiffy
[23:08] <beuno> mwhudson_, anyway, I've been poking at loggerhead from a "clean it up" point of view, and I've found that it uses args/kwargs quite inconsistently. I'd like to mode everything to kwargs, unless you have something against me doing thath
[23:08] <mwhudson_> beuno: you mean in urls?
[23:08] <beuno> mwhudson_, yes
[23:09] <beuno> in some cases, it uses /revision/, and, in some /revision?values=random
[23:09] <mwhudson_> yeah, it's not great
[23:10] <mwhudson_> beuno: on a call now, i'll get back to you in a few minutes
[23:10] <beuno> (as a side effect, using args let's you use wget/curl, but there has to be a better way around it)
[23:10] <beuno> mwhudson_, sure, no hurry
[23:13] <lifeless> beuno: ? is less likely to be cached in general
[23:13] <lifeless> beuno: and you can use wget/curl with ? just fine
[23:16] <beuno> lifeless, in respect to ?, do you mean that as a good thing, or as something bad?
[23:17] <beuno> and, I can't seem to get loggerhead to recieve any ? parameters from wget/curl
[23:19] <beuno> actually, looking deeper into it
[23:19] <beuno> I only get the first parameter
[23:19] <beuno> not the subsequent ones with &
[23:21] <lifeless> beuno: put '' around the url
[23:21] <lifeless> & is a shell metachar
[23:21] <lifeless> :)
[23:21] <mwhudson_> beuno: i bet this is a shell issue or something
[23:22] <beuno> lifeless, argh, thank, works. mwhudson_ told me yesterday, but it didn't seem to work, so I may of had a problem in the code
[23:23] <beuno> ok, good, back to more reliable benchmarks now  :)
[23:27] <mwhudson_> beuno: so, i actually quite like having the revision, at least, in the path part of the url
[23:28] <mwhudson_> if i was starting again, i'd probably have:
[23:28] <mwhudson_>  /branch/path -> changelog view
[23:28] <mwhudson_>  /branch/path/$revno -> revision view
[23:28] <mwhudson_>  /branch/path/$revno/path/to/file -> annotate view
[23:29] <mwhudson_>  /branch/path/$revno/path/to/dir -> inventory view
[23:29] <mwhudson_> i think having the "restrict to revisions that touch some file" as a query arg makes some kind of sense
[23:30] <beuno> ok, 3 sec to generate a 36k line diff in bzrlib, 20sec to apply the template and return. It outputs a 7mb file, which is considerable. We should be able to cut that down with proper CSS/HTML.
[23:30] <lifeless> ><
[23:31] <beuno> mwhudson_, that sounds like a good structure, and add kwargs for any filters we may want/need
[23:32] <mwhudson_> beuno: what are the comparable numbers for trunk?
[23:32] <mwhudson_> (if you have the RAM to repeat the benchmark...)
[23:32] <beuno> mwhudson_, well, I can't compare, since trunk generates a diff for each file, twice
[23:32] <lifeless> so
[23:32] <lifeless> nested trees
[23:33] <beuno> mwhudson_, my PC chokes at ~20k diffs with trunk, if that serves for comparison
[23:35] <mwhudson_> beuno: heh heh
[23:37] <beuno> the diff uses 100-150 RES memory, and it's mainly the templating engine
[23:37] <beuno> we could probably improve it a *lot* if, instead of a per-line loop, we had a per-column loop  (3 columns)
[23:38] <beuno> but I'd expect some work would need to be done in order to get CSS to show that properly in many scenarios
[23:39] <beuno> anyway, lots of room for improvement, but, the current branch is a major improvement over trunk, in resource usage
[23:41] <mwhudson> right
[23:42] <mwhudson> i'm sure our admins would like a three orders of magnitude improvement more than a three fold improvment
[23:42] <mwhudson> but they'll be happy with what we've got already, i'm sure
[23:43] <beuno> mwhudson, I have many ideas, so it's hard not to drift away. I'll focus on getting this approach cleaned up for review, and plan the next step after that
[23:43] <mwhudson> thanks
[23:44] <beuno> I even have the html/css for the new theme partly ready, which I will play around with until we can adapt it's current design to what will actually be used
[23:49] <mwhudson> so why does bzr push-ing a new branch very very occasionally create a branch reference instead?
[23:53] <igc> morning
[23:55] <lifeless> mwhudson: bleep, it shouldn't because you can't actually open a branch reference
[23:55] <lifeless> (they resolve at open)
[23:55] <lifeless> there was, once, a bug
[23:56] <mwhudson> lifeless: yeah, it certainly shouldn't
[23:57] <mwhudson> lifeless: https://pastebin.canonical.com/5889/ (apologies for the private url)
[23:57] <lifeless> you should apologise for openid instead
[23:58] <lifeless> your bash history may help reproduce
[23:58] <mwhudson> i deleted the branch and pushed again, it worked fine this time
[23:58] <poolie> good morning lifeless, all
[23:58] <mwhudson> i know this happened to thumper a week or so ago