[06:18] <mapps> hi all
[08:50] <MooDoo> morning all
[09:28] <davmor2> Morning all
[09:37] <JamesTait> Good morning all!  Happy Tuesday, and happy Australia Day! 😃
[09:38] <JamesTait> No Men At Work or Neighbours theme tune, thank you. 😝
[09:38] <JamesTait> davmor2, that means you!
[09:45] <davmor2> pfff
[09:45] <davmor2> JamesTait: https://www.youtube.com/watch?v=qwlxeYA1SQI
[09:47] <davmor2> JamesTait: https://www.youtube.com/watch?v=_D-LmRNdQiQ
[09:49] <davmor2> JamesTait: I think that covers you pretty well, one is not neighbours and the other isn't Men At Work :P
[09:49] <JamesTait> Oh, I forgot about Home & Away (understandable).
[10:08] <brobostigon> morning boys and girls.
[10:08] <MooDoo> morning brobostigon
[10:09] <brobostigon> morning MooDoo
[10:31] <davmor2> morning brobostigon
[10:32] <davmor2> MooDoo: me owld mucka
[10:33] <MooDoo> davmor2: ello ow am ya!?
[10:35] <brobostigon> morning davmor2
[10:37] <davmor2> MooDoo: Am good ta, 'ow am yow?
[10:52] <MooDoo> davmor2: I'm coping :)
[10:52] <davmor2> MooDoo: oh that good hey :)  cheer yourself up and listen to absolute 80's  :)
[10:53] <MooDoo> davmor2: yeah that'll do it for now lol
[10:56] <MooDoo> :)
[10:57] <foobarry> whats the word i'm looking for
[10:58] <foobarry> if i want another way to say that i want editorial control over changes to a website to achieve a harmonious writing style across the site
[10:58] <foobarry> instead of harmonious
[10:58] <foobarry> consistent look and feel ?
[10:58] <foobarry> that should do. thanks guys
[11:13] <davmor2> foobarry: don't mention it.....no no really don't ;)
[11:44] <_Sponge> Blustery day here. Rain on , than off, then on again ...
[11:46] <davmor2> _Sponge: so England then
[11:46] <_Sponge> No ManxLand.
[11:47] <_Sponge> not that it matters.
[11:47] <_Sponge> Did anyone see that FairTaxTown documentary on the Beeb ?
[11:48] <_Sponge> My friend, the Lady from the Isle of Man, was on that.
[11:54] <awilkins> I did
[11:54] <awilkins> http://www.bbc.co.uk/programmes/b06ygl19
[11:55] <awilkins> TLDW : Yes, it's perfectly possible for small businesses to use the same tax-avoidance schemes as the big boys
[11:56] <awilkins> TBH I think the only thing that will get HMRC and the government to fix the situation is when someone commercializes tax-avoidance for small business
[11:56] <awilkins> Given that 99% of businesses in the UK are small businesses, there's a market there
[11:58] <directhex> wasn't that what the did at the end?
[11:58] <directhex> selling their "fair tax town" formula?
[11:59] <awilkins> I don't think they actually went through with it
[11:59] <awilkins> Currently they are still on the Light Side of the Tax
[12:00] <awilkins> They created a viable tax avoidance scheme but are only using it as a campaigning tool right now AFAICT
[12:00] <awilkins> The ringleader is running for head of the HMRC board
[12:00] <awilkins> https://www.change.org/p/consider-steve-lewis-for-next-chief-executive-of-hmrc-board-peoplestaxman
[12:01] <awilkins> From their front page : "The Fair Tax Town Scheme is designed to put us in a strong negotiating position with HMRC, and not to avoid tax…"
[12:02] <awilkins> Actually using the tax avoidance scheme would presumably be the nuclear option
[13:02] <knightwise> yo peeps
[13:02] <zmoylan-pi> o/
[13:32] <knightwise> hey zmoylan-pi how are you due
[13:33] <zmoylan-pi> better than your autocorrect? :-)
[13:33] <knightwise> Haha :)
[13:33] <knightwise> Fewwy Funnah
[13:35] <zmoylan-pi> proper keyboards for the non abbreviated win \o/
[13:37] <knightwise> The one on my mbp is big enough .. i just type too fast
[13:38] <zmoylan-pi> no such thing as typing too fast... merely a computer too slow to keep up
[13:40] <davmor2> zmoylan-pi: stop using that zx81 and use something a little more modern you know like an amiga or atari then ;)
[13:41] <zmoylan-pi> a zx81? do you think i'm made of money... ::hugs zx80::
[13:41] <davmor2> hahahaha
[13:42] <zmoylan-pi> and stay away from those new fangled ram packs... nothing but wobble... :-)
[13:43] <zmoylan-pi> i was tempted when i saw someone had connect a zx spectrum to twitter till i saw the network card used had a more powerful processor than the speccy
[13:45] <davmor2> I liked the guy that turned the raspi into a 48k emulator and installed it in an old spectrum I thought that was genius and all so he could play jetset willy :)
[13:46] <zmoylan-pi> it's not the same using a pc keyboard in an emulator somehow...
[13:49] <zmoylan-pi> maplins sell a fuse keyboard that is very reminiscent of the bbc keyboard.  tempting but too expensive
[13:58] <davmor2> ah the good old bbc micro :) whisks me back to school :)
[14:24] <MooDoo> used to play chucky egg or frak on our bbc at schoo :)
[14:34] <davmor2> we weren't really allowed to play games on them except for adventure games as those meant you read stuff as they were all text based :)
[15:20] <mapps> hm new x files was ok
[15:20] <diddledan> mapps: I liked it
[15:21] <diddledan> mapps: way to cluster filesystem-check our collective minds :-p
[15:22] <diddledan> everything we thought we knew about the cannon of the x-files… nope, you’re wrong
[15:43] <awilkins> Mulder : now a skeptic
[15:44] <awilkins> Scully : Enrolled in a commune in the Nevada desert that wears tinfoil hats and sends messages to aliens by drinking phosphorescent chemicals and peeing pictograms onto the vast desert mesa
[15:44] <awilkins> Smoking Man : wears a nicotine patch
[15:44] <awilkins> Lone Gunmen : all happily married
[15:53] <diddledan> awilkins: lmao
[16:26] <moreati> awilkins: married to other people, or to each other?
[16:31] <bigcalm> Good morning peeps :)
[16:34] <popey> hi bigcalm
[16:35] <popey> no lag on steamlink even on wifi here
[16:36] <bigcalm> popey: I haven't used mine for some time now, might have improved
[16:37] <popey> i just booted it up, did an OTA update and played GTA5
[16:37] <popey> didn't notice
[16:37] <bigcalm> popey: the issue I, and directhex, found was that now and then there would be a freeze in game play. Followed by restored game play, but the last action of the controller repeated many times.
[16:38] <bigcalm> Resulting in walking off ledges in Lego games mostly
[16:38] <popey> maybe I haven't played long enough to trigger that
[16:38] <popey> or don't have those games
[16:38] <bigcalm> This is over wifi n and LAN over power
[16:38] <bigcalm> It wasn't any one game, happens for all streaming things
[16:39] <bigcalm> As I say, I haven't used it for some time. Might have been fixed
[16:39] <bigcalm> directhex: Steam link still causing lag pockets for you?
[17:05] <_Sponge> knightwise: Still there ?
[17:50] <mapps> hmm
[17:50] <mapps> what to watch
[17:50] <brobostigon> the simpsons, :)
[17:51] <mapps> heh
[18:23]  * davmor2 just leaves this here https://www.youtube.com/watch?v=w0N4twV28Mw
[18:28] <diddledan> I’ve started on the hot-crossed buns already - it’s not even february!
[18:33] <davmor2> diddledan: dude that is so wrong
[18:33] <diddledan> :-p
[18:33] <diddledan> yet it feels so right
[18:33] <davmor2> you simply shouldn't stop eating hot-cross buns :)
[18:33] <zmoylan-pi> -5 points for use of the word dude... unless you work(ed) for dell... :-P
[18:34] <davmor2> zmoylan-pi: -5 for the use of that word that I use all the time :P
[18:53] <mapps> heh
[18:55] <mapps> lol shock numerous people claiming they had the 33mil winning ticket
[18:56] <diddledan> do they really think that camelot won’t check?
[18:56] <mapps> who knows, some people ust want attention from papers/tv
[18:57] <mapps> how could camelot check though if you bought the ticket in a shop and then chucked it away
[18:57] <diddledan> they won’t pay if you don’t have the ticket IIRC
[18:58] <mapps> ya i thought so..so saying you binned it or washed it
[18:58] <zmoylan-pi> just attach the genital electrodes and put them through lie detector test... not saying it's accurate but will thin the herd... :-D
[18:58] <mapps> means it goes unclaimed right?
[18:59] <mapps> how did this 21 yr old die..says she got wdged between 2 sofas on a drinking session?!
[18:59] <diddledan> o_O
[18:59] <mapps> some young girl travelling in australia
[18:59] <mapps> said she was on beta blockers and a history of palpitations..still seems odd
[22:02] <mapps> caught the end of murder games bbc3 docu drama about a 14yr old groomed by an 18yr old
[22:02] <mapps> pretty sad story;/
[22:02] <diddledan> mapps: lucifer is fun
[22:03] <mapps> i was looking at that earlier as it happens
[22:03] <diddledan> just watching the first ep
[22:03] <mapps> started 'power' ..heard of it? it sounded whack
[22:03] <mapps> but 7.8 , 8.2/10 on tv.com/imdb
[22:03] <diddledan> don’t think I know that one
[22:03] <mapps> so figured id give it a try...directed by 50 cent
[22:05] <mapps> ima download the bbc3 doc, it's strange to think something as innocent as playing games could endup in murder
[22:08] <zmoylan-pi> did you not notice all the gun fighting over cards in westerns?
[22:09] <mapps> heh
[22:09] <mapps> but i mean this is young kids being groomed over game forums and team speak stuff
[22:10] <mapps> must be so many vile people lurking on forums/server trying to groom kids, impossible to get a #
[22:11] <diddledan> mapps: I want to know why I haven’t been groomed by any vile people.


[00:01] <maxb> Hrm. bzr-svn seems to be doing a lot more work fetching tags now than it used to
[00:02] <jelmer> maxb: yes, consistent with bzr itself it now fetches all revisions referenced by tags, not just those in the branch tip ancestry
[00:02] <maxb> jelmer: unfortunately, on my largish work repository, this is the difference between bzr pull working, and taking so long that I give up and Ctrl-C it
[00:04] <maxb> wait.... all revisions referenced by tags? Doesn't that mean, given svn tags are not per-branch, that branching any branch of a svn repository has to walk and fetch the revisions on any branch which has been tagged?
[00:05] <jelmer> maxb: any relevant tag
[00:05] <jelmer> maxb: it doesn't fetch the branch tips, just the tags that would be in the branch that's fetched
[00:06] <jelmer> maxb: IOW for the 'ant' project in Apache SVN it would only fetch the revisions referenced by ant tags
[00:07] <jelmer> there has been some discussion about whether it's a good idea to fetch all revisions referenced by tags; perhaps it's something useful to bring up on the list
[00:07] <maxb> jelmer: but, consider some experimental branch that has tags - if the tags are bounded by project, branching trunk will now need to also pull in that experimental branch
[00:07] <maxb> For native bzr, it just about makes sense, because tags are per-branch
[00:08] <jelmer> maxb: it will only bring it in until the last revision that is tagged
[00:08] <maxb> which could still be a LOT of extra data transfer and processing time
[00:10] <jelmer> maxb: what about a svn tag that is based off a revision on the current branch but makes one additional modification?
[00:10] <maxb> hrm :-/
[00:12] <jelmer> maxb: I don't think this problem is specific enough to bzr-svn
[00:12] <jelmer> I had some unrelated tags on one of my bzr branches and also ended up fetching a lot of unrelated revisions
[00:21] <mgz> jelmer/maxb: if you notice any new plugin test failures with the latest bzr.dev please subscribe me to the bug
[00:21] <mgz> I changed the run_bzr args semantics a little and lots of the plugins' test suites use it.
[00:21] <jelmer> maxb: Suggestions on how to better handle tags on non-tip-ancestry revisions welcome
[00:22] <jelmer> mgz: ok
[01:00] <spiv> Good morning.
[01:01] <poolie> hi there spiv
[01:01] <poolie> like clockwork :)
[01:01] <spiv> :)
[01:02] <poolie> how are you, spiv?
[01:05] <spiv> Good, I seem to have escaped the worst of the cold going around this household.
[01:05] <poolie> you guys seem to have had a really bad run with that
[01:06] <poolie> over the last year or so i mean
[01:06] <spiv> Yeah.  Aside from the last week we'd been pretty good for maybe 2 months finally.
[01:06] <lifeless> EBABY
[01:07] <spiv> We think V picked this one up from another baby's 1st birthday rather than daycare for once.
[01:07] <poolie> itym fork() != 0
[01:07] <lifeless> len(pgroup)
[01:07] <lifeless> perhaps
[01:08] <poolie> i wish bug 456418 were fixed
[01:08]  * poolie tries to work out which of vila's patches comes first
[01:11] <poolie> jelmer: hooray for more tariff tests
[01:12] <poolie> jelmer, did you want to talk about the config mps or point me to any of them in particular?
[02:56] <poolie> spiv do you use selftest --subunit regularly?
[02:56] <poolie> i seem to have a bug where partway through the tests, the stream starts going to stderr
[02:58] <lifeless> wow
[02:58] <lifeless> poolie: do you say that because you've captured it, or because you start seeing the raw stream?
[03:02] <poolie> i am piping it into tribunal and part way through tribunal stops seeing updates and i get it in my terminal
[03:02] <poolie> it may well be a bzr test doing something weird with global state
[03:02] <poolie> just trying to narrow it down
[03:03] <lifeless> my guess would be a print statement (or debug statment) printing to stdout and not puttingn a \n on the statement
[03:04] <poolie> ah, yuck
[03:04] <poolie> and then the subunit libraries and tribunal are printing it out
[03:05] <poolie> i'd forgotten about that
[03:05] <poolie> that's easy to test with a simple redirection
[03:23] <spiv> poolie: I don't, although I use --parallel regularly, which does something similar I assue
[03:23] <spiv> *assume
[03:29] <lifeless> yup, --parallel does subunit for each core
[04:23] <poolie> it's probably a tribunal bug
[04:23] <poolie> too many yaks
[07:56] <poolie> maxb, hi
[07:56] <poolie> we might as well cease building for karmic in the daily ppa, hey?
[07:57] <maxb> poolie: hah
[07:57] <maxb> I was just finishing off an email proposing that before responding to your bing
[08:10] <jam> morning poolie
[08:21] <poolie> hello?
[08:22] <poolie> hi jam
[08:35] <jam> just saying hi
[08:37] <spiv> jam: hi :)
[08:43] <poolie> hi spiv
[08:47] <jam> hey spiv
[08:55] <spiv> Hmm, webnumbr seems to have stopped being able to fetch from launchpad :(
[09:00] <poolie> is there any indication why?
[09:02] <spiv> poolie: not that I can see.  Trying to create a new webnumbr against lp eventually just gives me a blank page, which suggests a problem on webnumbr's end
[09:59] <poolie> good night all
[10:01] <jelmer> g'night poolie
[11:03] <jelmer> jam: Do you know what the difference between Inventory._get_mutable_inventory and Inventory.copy is ?
[11:04] <jam> jelmer: CHKInventory._get_mutable_inventory() returns an Inventory() instead of a CHKInventory
[11:04] <jelmer> jam: I knew there was something I was missing. Thanks.
[11:10] <spiv> I wonder how many uses of _get_mutable_inventory are left.
[11:11] <spiv> We mostly just use explicit deltas now.
[11:11] <jelmer> I'm about to remove one, that leaves two uses
[11:11] <jelmer> one in a test, and one in MutableTree.update_basis_by_delta
[12:38] <jam> jelmer: talk about chasing the rabbit down the hole. Fixing iter_changes caused bugs to show up for WT.inventory which causes more test failures...
[12:38] <jam> we actually have some tests that we *don't* auto-detect nested trees (probably for performance reasons?)
[12:38] <jam> anyway, still chasing
[12:42] <jelmer> jam: ugh :-/
[12:43] <jam> jelmer: I think our tree-reference implementation is pretty incomplete, and basically it is 'just enough' to get the test suite to pass
[12:43] <jam> but alter one detail...
[12:53] <jelmer> jam: I can see how that's frustrating.. One of these days we should JF finish tree references..
[14:03]  * jelmer lunches
[15:29] <ablmf333> jelmer:  Morning.  Have u fixed the commit problem of bzr-svn?
[15:32] <jelmer> ablmf333: no, not yet
[15:32] <jelmer> ablmf333: https://bugs.launchpad.net/bzr-svn/+bug/765286
[15:34] <ablmf333> jelmer: Then, is there anyway to completely remove bzr info in svn repo, so I would be able to get a fresh check out that I can commit?
[15:34] <ablmf333> I deleted all the bzr:xxx properties
[15:34] <ablmf333> But I still couldn't commit
[15:35] <ablmf333> bzr still complains that I need to update before commit
[15:35] <jelmer> ablmf333: If you remove the bzr: properties you need to remove your bzr-svn cache and do a clean checkout
[15:35] <jelmer> ablmf333:
[15:36] <ablmf333> jelmer:  Where is the bzr-svn cache?
[15:36] <jelmer> ablmf333: usually ~/.cache/bazaar/svn/<uuid>
[15:37] <jelmer> jam: Nice work on the status improvements!
[15:37] <jam> jelmer: it could be better, I still don't get the improvement I wanted for 'bzr status' after 'bzr co', but I'm getting there
[15:37] <ablmf333> jelmer: How do I know which uuid should I delete?
[15:38] <jam> ah, I'm missing symlinks
[15:38] <jelmer> ablmf333: "svn info <url>" should display the UUID
[15:38] <jelmer> ablmf333: are these revision properties or file properties?
[15:38] <jam> (the tree I'm testing has a symlink in it, and we don't cache symlink targets on initial create, and it gets updated during first status)
[15:39] <ablmf333> jelmer: I just deleted every bzr:xxx on the trunk directory on svn server
[15:41] <jelmer> ablmf333: That won't help
[15:42] <ablmf333> jelmer: k, then how do I delete revision properties?
[15:42] <jelmer> ablmf333: That's not the point; removing *any* properties won't help with this issue.
[15:44] <ablmf333> jelmer: I don't get it.  What else could make bzr-svn thinks that my local branch is out of date?
[15:44] <jelmer> ablmf333: it's a bug that's got to do with your pending merges and its analysis of the revision graph
[15:45] <ablmf333> jelmer: No, no, I've committed the merge with svn.  Now I just want bzr-svn works on a fresh new checkout.
[15:48] <jelmer> ablmf333: so what's not updating exactly?
[15:49] <ablmf333> jelmer: I use `bzr co svn://....` to get a new checkout. Made some test modification and tried to commit, bzr tells me that the local is out of date.
[15:50] <ablmf333> jelmer: I just removed bzr-svn's local cache.  Hope that will help.
[15:52] <jelmer> ablmf333: what sort of changes are you committing, a merge?
[15:52] <ablmf333> jelmer: No, just a line of comment.
[15:55] <ablmf333> jelmer: bzr: ERROR: This operation requires storing bzr-svn metadata in Subversion file properties. These file properties may cause spurious conflicts for other Subversion users during merges. To allow this, set `allow_metadata_in_file_properties = True` in your configuration and try again.
[15:55] <ablmf333> jelmer: Should I do that?
[15:56] <jelmer> ablmf333: yep (it's consistent with what bzr-svn did for you previously)
[15:58] <ablmf333> jelmer: Thanks!  Finally I could use bzr-svn to work again.  Is there anything I should avoid in the future when using bzr-svn?
[15:59] <jelmer> ablmf333: not really, this is just a bug that's been fixed recently
[15:59] <jelmer> ablmf333: I would recommend /not/ removing file properties, that just breaks your bzr-svn cache and makes it slower
[16:01] <ablmf333> jelmer: k.  Thanks, hope u can fix the bug soon.
[19:20] <maxb> jelmer: FYI I have changed the dulwich-daily recipe to use ~vcs-imports/dulwich/trunk instead of ~dulwich/dulwich/trunk, because I think that will avoid the BzrCheckError
[23:44] <knighthawk> okay guys sorry for all the newbie questions but I'm lost again and RTFM hasn't helped me yet. So again I created a bzr repo using svn-import (no working tree) then I used 'bzr branch' to create a branch from the repo. Now from my brach (working tree) I'm trying to run 'bzr pull' from the svn repo. but I get 'bzr: ERROR: These branches have diverged. Use the missing command to see how.' it looks like I'm only one revision away from being able to do this
[23:44] <knighthawk>  (according to 'bzr missing') so It *seems* to me that I should run a merge then I should be able to pull only how do I merge a working tree with a none working tree?
[23:46] <knighthawk> btw if I got any of the terminology wrong please point it out. I'm trying to use it so I can get it right the terms all seem similar to svn but I'm thinking it may not be quite the same.
[23:53] <poolie> hi all
[23:53]  * fullermd waves at poolie.
[23:54] <fullermd> knighthawk: It's not quite clear what you're wanting or expecting...
[23:54] <fullermd> knighthawk: So you've got a branch from svn-import; call it A
[23:54] <fullermd> knighthawk: And a branch you made from A; call it B.
[23:54] <fullermd> Now you're wanting to...   pull from SVN into B?


[06:01] <jam> wallyworld_: would you rather do G+?
[07:45] <rogpeppe1> mornin' all
[07:50] <dimitern> morning
[07:51] <rogpeppe1> dimitern: hiya
[08:59] <jam> dimitern: /wave, I'm just grabbing a coffee, and then I'll be back for mumble
[08:59] <dimitern> jam: i'll be there shortly
[09:05] <fwereade__> dimitern, ping
[09:05] <dimitern> fwereade__: heyhey
[09:05] <fwereade__> dimitern, I don't recall: did we write code for joining new peer relations on Service.SetCharm?
[09:05] <dimitern> fwereade__: not yet, this is upcoming
[09:06] <fwereade__> dimitern, ah -- am I right in thinking we *did* write it but it's been pushed back behind the command? or did we just talk about it?
[09:08] <dimitern> fwereade__: that's right - it's behind the cmd
[09:08] <fwereade__> dimitern, cool, thanks, just trying to construct a model of reality ;p
[09:11] <dimitern> fwereade__: np :)
[09:12] <fwereade__> jam, dimitern, rogpeppe1: so, I have a testing conundrum wrt the order in which the unit agent joins relations; I'm going to ramble about it for a bit in the hope that one of you will tell me what I should obviously do
[09:13] <rogpeppe1> fwereade__: i'm listening
[09:13] <jam> fwereade__: you should obviously drink some coffee and go for a walk :)
[09:13] <fwereade__> 1) the unit agent should join relations in a particular order: peers first, then all others, and within those categories in creation order (ie id order)
[09:13] <fwereade__> jam, I've had a weekend to think about it, hasn't really helped ;p
[09:13] <jam> I will read traceback, currently OTP
[09:14] <fwereade__> jam, cheers
[09:15] <fwereade__> 2) black-box testing of relation-join order is very tricky in the first place -- I can come up with tests that sometimes demonstrate a problem, maybe
[09:15] <jam> "ordering" definitely seems like a whitebox test
[09:16] <fwereade__> 3) it's not currently possible to even *create* a peer relation for a service that has a higher id than any of the non-peer relations, because of missing functionality in Service.SetCharm
[09:16] <fwereade__> 4) but I could probably do that with a test internal to state
[09:17] <fwereade__> 5) how reasonable would it be to just define `type ByPriority []*Relation` in state -- which I think *can* be tested internally by doing inappropriate things to mongodb
[09:17] <fwereade__> (that's probably fine)
[09:18] <rogpeppe1> fwereade__: sorry, what exactly are you trying to test here? i seem to have missed that crucial detail.
[09:19] <fwereade__> 1) the unit agent should join relations in a particular order: peers first, then all others, and within those categories in creation order (ie id order)
[09:19] <rogpeppe1> fwereade__: ah, you're testing the unit agent
[09:20] <fwereade__> rogpeppe1, yeah
[09:20] <dimitern> fwereade__: is it possible/valid to remove(destroy) peer relations?
[09:20] <rogpeppe1> fwereade__: what would ByPriority do?
[09:21] <fwereade__> 6) and then, in the uniter, try to come up with an internal test that demonstrates that join order is consistent with a ByPriority sort even if I can't show that's what we're using
[09:21] <fwereade__> dimitern, not really, only as part of service destruction
[09:21] <fwereade__> rogpeppe1, sort as described in (1)
[09:21] <fwereade__> 7) that's it
[09:22] <rogpeppe1> fwereade__: is the reason you can't test priority externally that the id isn't visible outside state?
[09:22] <fwereade__> rogpeppe1, no -- id is easy
[09:22] <fwereade__> rogpeppe1, but there's no clear way to get the order of relations joined on another goroutine
[09:23] <fwereade__> rogpeppe1, watchers coalesce events, remember ;p
[09:23] <rogpeppe1> fwereade__: please remind me why the order that the unit agent joins relations is important
[09:24] <fwereade__> rogpeppe1, a DB in a peer relation that handles replication, say, should not start talking to a client until it knows that peers exist
[09:25] <fwereade__> rogpeppe1, that said, *that* precise scenario may be impossible to tell anyway
[09:25] <rogpeppe1> fwereade__: ok, that's a reason why peers need to be joined before others. what about the secondary ordering?
[09:26] <fwereade__> rogpeppe1, I think it's just so that charms get a picture of the world that's as consistent as possible
[09:27] <fwereade__> rogpeppe1, and if you're defining a sort order you may as well do it completely rather than give up half way through ;p
[09:27] <fwereade__> rogpeppe1, I should probably sync up with hazmat, actually, the more I think the less sure I am that this will help at all
[09:28] <fwereade__> rogpeppe1, join order doesn't actually impact hook order anyway, even in python, afaict
[09:29] <fwereade__> rogpeppe1, and there's no point a hook checking whether a peer relation exists -- it must always do so implicitly
[09:29] <fwereade__> rogpeppe1, so, hmm
[09:30] <fwereade__> rogpeppe, yeah, screw this, I'll talk to hazmat later and find something else to do for now
[09:31] <rogpeppe> oops, sorry, my computer just spontaneously rebooted
[09:31] <rogpeppe> fwereade__: last thing i saw was
[09:31] <rogpeppe> [Monday 25 March 2013] [09:29:04] <fwereade__> rogpeppe1, and there's no point a hook checking whether a peer relation exists -- it must always do so implicitly
[09:31] <fwereade__> rogpeppe, I said "so, hmm", and thought until I said "screw this"
[09:32] <fwereade__> sorry for the noise gents
[09:32] <rogpeppe> fwereade__: oh yes, i saw that.
[09:32] <rogpeppe> fwereade__: np.
[09:32] <rogpeppe> fwereade__: you might be interested to see what i did on saturday: https://codereview.appspot.com/8010043/
[09:33] <fwereade__> davecheney, can I WIP 107b please? trying to get an accurate +activereviews
[09:34] <rogpeppe> fwereade__: it generalises the transaction-space explorer i did before, and applies it to State. so far i only test a single operation though.
[09:34]  * fwereade__ looks
[09:40] <davecheney> fwereade__: sure
[09:49] <fwereade__> rogpeppe, that is very neat, but I'm not 100% sure it's a clean fit for the problem -- in my mind, it would be nicer to just allow tests to hook into a point where they can make arbitrary state changes just before the txn is run
[09:49] <fwereade__> rogpeppe, that seems more conducive to deterministic testing
[09:51] <rogpeppe> fwereade__: i think both things may have a place
[09:51] <rogpeppe> fwereade__: the advantage of my scheme is that it allows black-box testing
[09:52] <rogpeppe> fwereade__: and also potentially the writing of very compact tests that test existing operations against one another.
[09:54] <rogpeppe> fwereade__: actually, thinking about it, my scheme does provide the capability to allow make arbitrary state changes just before a txn is run too
[09:54] <fwereade__> rogpeppe, I am probably not seeing the consequences clearly
[09:54] <fwereade__> rogpeppe, but I was imagining something like http://paste.ubuntu.com/5645845/
[09:55] <rogpeppe> fwereade__: i'm not sure that's sufficient - some operations execute several transactions in their normal course of action
[09:55] <rogpeppe> fwereade__: so you'd want to be able to hook before or after any of those, i think
[09:55] <fwereade__> rogpeppe, what operations are these, that are not broken? ;p
[09:56] <rogpeppe> fwereade__: if circumstances change underfoot
[09:57] <rogpeppe> fwereade__: then an operation might legitimately execute several transactions
[09:57] <fwereade__> rogpeppe, oh, you mean when they abort due to state change rather than invalidity?
[09:57] <rogpeppe> fwereade__: yup
[09:57] <fwereade__> rogpeppe, I don't see the problem there tbh
[09:58] <rogpeppe> fwereade__: so, how do you test that the second transaction does the right thing even when the assumptions of *that* one are broken?
[09:59] <fwereade__> rogpeppe, close over a counter, if you can come up with a situation that really requires it
[09:59] <rogpeppe> fwereade__: and i think you want to be able to test what happens if the state is mutated both before and after a transaction is run (it's not clear when SetTxnCallback would be called)
[09:59] <fwereade__> rogpeppe, I'm not following -- why afterwards too?
[10:00] <fwereade__> rogpeppe, that thing I posted was a complete test case that needs minimal machinery in state AFAICT
[10:00] <rogpeppe> fwereade__: because if you get ErrAborted, you then inspect the state, which might have mutated in an unhelpful way since the transaction, and we'd like to be able to test that logic
[10:01] <fwereade__> rogpeppe, is that not just testing mgo/txn, rather than testing our own transactions?
[10:01] <rogpeppe> fwereade__: i don't think so
[10:02] <rogpeppe> fwereade__: for instance, consider Service.Destroy
[10:02] <fwereade__> rogpeppe, go on
[10:02] <rogpeppe> fwereade__: if it gets ErrAborted, it does a Refresh, then proceeds to act on the basis of that state.
[10:03] <rogpeppe> fwereade__: how do you test that logic?
[10:03] <fwereade__> rogpeppe, yes...
[10:03] <rogpeppe> fwereade__: i suppose you can assume that it's always a straightforward loop and the logic at each cycle is the same as the previous
[10:04] <fwereade__> rogpeppe, well, you know what state change you made in the callback... that should either be sufficient to kill completely or to allow a second attempt to go through, regardless of the implementation
[10:04] <fwereade__> rogpeppe, so you test that the expected thing happens, and you're done
[10:04] <fwereade__> rogpeppe, right..?
[10:06] <rogpeppe> fwereade__: i'm not quite following you there
[10:07] <fwereade__> rogpeppe, would you expand on why you need to assume it's a straightforward loop?
[10:08] <fwereade__> rogpeppe, I expect that in most interesting cases the construction of the new txn will be totally different from the old one
[10:08] <rogpeppe> fwereade__: ok. first a little bit of terminology that i've been using when thinking about this:
[10:09] <rogpeppe> fwereade__: an operation cycles between two states: "look" and "mutate". in look state, an operation queries the database and decides what op to perform; in mutate state, an operation runs a transaction.
[10:10] <rogpeppe> fwereade__: i think that any operation can be considered to start in look and then alternate between look and mutate.
[10:10] <rogpeppe> fwereade__: until it terminates
[10:10] <fwereade__> rogpeppe, ok...
[10:12] <fwereade__> rogpeppe, well, some start in a pre-looked state, but I expect we can handwave past that
[10:12] <rogpeppe> fwereade__: so, in general, we want to test that the correct thing happens regardless of the interleaving of look and mutate states of concurrently running operations.
[10:13] <rogpeppe> fwereade__: yeah, that's awkward, but we can get around it
[10:13] <fwereade__> rogpeppe, well, what I actually want to do is to test what happens to single operations when the state changes in prescribed ways between look and mutate
[10:14] <rogpeppe> fwereade__: well yes - that "change in a prescribed way" is just simulating some other operation happening there, right?
[10:14] <fwereade__> rogpeppe, it's actually running the operation, in my model
[10:15] <rogpeppe> fwereade__: ok, sure - so you're entirely encapulating all the look/mutate transitions of that other operation inside the SetTxnCallback hook
[10:15] <fwereade__> rogpeppe, yeah, if you like
[10:16] <fwereade__> rogpeppe, from my perspective the details of that other txn are a red herring, I think
[10:16] <rogpeppe> fwereade__: look at it this way: could you use SetTxnCallback to actually produce an ErrExcessiveContention error?
[10:16] <fwereade__> rogpeppe, ofc
[10:18] <fwereade__> rogpeppe, in service.Destroy, for example, add/remove the single unit of the service every time you go through
[10:19] <rogpeppe> fwereade__: yeah, i suppose so, by running a different operation at each stage, yeah
[10:19] <fwereade__> rogpeppe, maybe I'm not  following your approach right, though
[10:19] <fwereade__> rogpeppe, how would you do it?
[10:21] <rogpeppe> fwereade__: in a similar way actually, but rather than have a closure, we'd run an operation that did for i := 0; i < 5; i++ {add unit; remove unit} concurrently with the Destroy op
[10:23] <rogpeppe> fwereade__: in general, we can get arbitrary interleaving of look/mutate states between concurrent operations, and i'm interested in verifying that behaviour is correct in all those cases.
[10:23] <fwereade__> rogpeppe, I'm not seeing how you'd synchronize them to ensure proper coverage
[10:24] <rogpeppe> fwereade__: well with txntest there are two possibilities.
[10:24] <rogpeppe> fwereade__: if the state space is small enough, you can let it do it itself, and it'll run through all possible interleavings
[10:25] <rogpeppe> fwereade__: otherwise you can specify a set of interleavings to test
[10:25] <jam> mgz: morning
[10:26] <rogpeppe> fwereade__: say we've got two concurrent operations, a set of interleavings looks something like: 0.1.0t.1t.0*.1*
[10:27] <rogpeppe> fwereade__: where the number signifies the operation in question (one of two, in this case); a bare number indicates a look state; a "t" suffix indicates a transaction (mutate), and a '*' suffix indicates that the op terminates at that point.
[10:28] <rogpeppe> fwereade__: so the above trace says something like: both ops look at the state, and execute a transaction based on that state; they each look at the resulting state and stop.
[10:29] <fwereade__> rogpeppe, that STM like you're mixing up the tests for two operations, which is just about ok for 2 but becomes more tricky when there are 6, and that that case it would be clearer to test 0 in the context of 1, 2, 3, 4, and 5 separately
[10:29] <fwereade__> rogpeppe, especially if 4, 5, and 6 don't interact with one another
[10:30] <mgz> jam: hey
[10:30] <rogpeppe> fwereade__: i think that we are mixing up the tests for two operations because actually we want to know what happens when those two operations execute concurrently.
[10:30] <fwereade__> mgz, just quickly, did my suggestion on your review look like crack?
[10:31] <rogpeppe> fwereade__: given that we know that those operations operate on the same part of the state.
[10:31] <mgz> fwereade__: nope, but I do wonder if that's preferable to just having a base struct that contains 'config map[string]interface{}' and methods for operation on
[10:31] <mgz> I still have no feel for what idioms make sense
[10:32] <jam> mgz: I do think having a separate TestConfig attribute, and then that gets copied to something when it is actually used
[10:32] <jam> overriding the Config member vs copying from another member
[10:32] <fwereade__> mgz, my experience has been that the prefer-composition-over-inheritance-turned-up-to-11 approach actually leads to surprisingly neat code, even though my OO instincts led me to reach for inheritance-alike approaches by default
[10:32] <jam> (eg)
[10:33] <mgz> I shall give it a hack.
[10:33] <fwereade__> mgz, there's another approach that says, hey, what I suggested is doing almost exactly that anyway in effect
[10:33] <rogpeppe> fwereade__: your SetTxnCallback idea is definitely progress (and might well be all we need for the time being), but it still doesn't give me confidence that there's not some odd interaction between different concurrent operations that might not be predictable.
[10:34] <fwereade__> mgz, let me know how it goes, if it starts getting up your nose then your current approach is still progress
[10:35] <fwereade__> rogpeppe, it does mean we need to write the individual tests
[10:36] <rogpeppe> fwereade__: sure; that's true in both cases i think
[10:37] <fwereade__> rogpeppe, I'm woried about how that'd look with the general approach though
[10:37] <fwereade__> rogpeppe, here's a pile of transactions, here's a pile of possible acceptable errors for each transaction, GO
[10:38] <rogpeppe> fwereade__: it would probably be more like: here's two concurrent operations; verify that this condition holds after all these listed interleavings between the two.
[10:40] <fwereade__> rogpeppe, I worry that the condition will just be "either 0 won or 1 did"
[10:40] <fwereade__> rogpeppe, and that getting better than that, in the sense of detecting unknown weirdness, will be rather tricky
[10:41] <fwereade__> rogpeppe, some of them should of course be "both succeeded"
[10:41] <fwereade__> rogpeppe, anyway, thank you, that was an enlightening conversation
[10:41] <rogpeppe> fwereade__: in the general (automatically explored) case, that's true, because that actually is the expected fuzzy result. but when specifying a specific set of interleavings, you can specify them such that you know the expected result and verify accordingly.
[10:42] <fwereade__> rogpeppe, yeah, that does make sense
[10:43] <fwereade__> rogpeppe, seems to me to make it harder to unit test individual operations clearly
[10:44] <rogpeppe> fwereade__: possibly so. i'm not sure yet.
[10:44] <rogpeppe> fwereade__: i've found it an interesting experiment, even if we don't use it.
[10:45] <fwereade__> rogpeppe, definitely -- and I'll try to give it another look later, because I definitely didn't follow all the details on the first run through :)
[10:46] <rogpeppe> fwereade__: when i get a spare moment, i'll run up a test for Service.Destroy and see how it looks
[10:46] <rogpeppe> fwereade__: 'cos there's quite a lot of untested logic there.
[10:49] <fwereade__> rogpeppe, the errRefresh action is untested, but I'm not sure what else you're referring to
[10:50] <rogpeppe> fwereade__: errRefresh and ErrAborted
[10:51] <mgz> oh dear, my canonistack instance has just become very unhappy...
[10:51] <fwereade__> rogpeppe, but ErrAborted is tested really quite a lot
[10:51] <frankban> rogpeppe: fwereade__: please take a look at this error (config-get while deploying juju-gui): http://pastebin.ubuntu.com/5645957/ It seems something is going wrong while calling state/service.go:*Service.Config()
[10:52] <rogpeppe> fwereade__: ah, because we don't query mongo before making the initial transaction?
[10:52] <fwereade__> rogpeppe, yeah
[10:52] <fwereade__> rogpeppe, well, we do a bit, with the relations
[10:53] <rogpeppe> fwereade__: yeah
[10:53] <rogpeppe> fwereade__: i just saw that
[10:53] <mgz> Mar 25 10:49:54 go kernel: [1433100.892933] EXT4-fs error (device vdb): ext4_journal_start_sb:370: Detected aborted journal
[10:53] <mgz> Mar 25 10:49:54 go kernel: [1433100.894501] EXT4-fs (vdb): Remounting filesystem read-only
[10:53] <fwereade__> frankban, looking
[10:54] <rogpeppe> fwereade__: anyway, Service.Destroy does seem to be one of the more complex transactions around
[10:54] <rogpeppe> fwereade__: hence, i thought, a good example for trying to test thoroughly.
[10:54] <fwereade__> rogpeppe, Destroy txns are in general total bitches
[10:55] <fwereade__> frankban, what happens if you do a `juju get juju-gui` from the CLI?
[10:56] <fwereade__> frankban, hey, did you bootstrap with --upload-tools?
[10:56] <frankban> fwereade__: yes
[10:56] <fwereade__> frankban, bah, ok, I keep doing that and being confused by biarre errors ;p
[10:57] <frankban> fwereade__: and deployed using "juju deploy -e go --repository=/home/frankban/devel/juju/gostore local:precise/juju-gui"
[10:57] <fwereade__> frankban, would you paste me the full unit log please?
[10:58] <frankban> fwereade__: sure
[10:59] <fwereade__> frankban, a thought: did you also rebuild the CLI tools rcently?
[11:01] <frankban> fwereade__: http://pastebin.ubuntu.com/5645995/
[11:01] <frankban> fwereade__: how to do that? I usually just run "go install ./..." in launchpad.net/juju-core
[11:02] <fwereade__> frankban, yeah, that's what I do, usually followed by a paranoid ls -al $(which juju)
[11:03] <frankban> fwereade__: retrying
[11:04] <frankban> fwereade__: I usually go in $GOPATH/bin and use ./juju from there
[11:06] <fwereade__> frankban, I've got $GOPATH/bin on my path but I never quite trust that I haven't been screwing around with something and forgotten about it ;p
[11:07] <fwereade__> frankban, (my thinking here, fwiw, is that the keys for service settings documents *have* changed recently, but I'm pretty sure they're tested in some detail, so I'm hoping it's just a mismatch on your end)
[11:08]  * rogpeppe still thinks we should be changing our major version number every time we make a backwardly incompatible change. these kinds of issue are a pain to diagnose.
[11:12] <frankban> fwereade__: I am retrying after re-compiling trunk
[11:13] <fwereade__> frankban, cheers
[11:21] <fwereade__> bbiab
[11:31]  * TheMue dances around as he found why those too tests fail after the latest change
[11:32] <dimitern> mgz: standup?
[11:35] <dimitern> fwereade__: are you good for lunch aroung 13:30 (after standup)?
[11:44] <TheMue> lunchtime
[11:48] <frankban> fwereade__, rogpeppe: same error. either using the local charm or cs:precise/juju-gui
[11:49] <rogpeppe> frankban: could you paste a script which replicates the problem from scratch?
[11:52] <frankban> rogpeppe: it's just "juju bootstrap --upload-tools" and then "juju deploy cs:precise/juju-gui". it fails in the install hook.
[11:52] <rogpeppe> frankban: ok, i'll try it and see if i can reproduce the problem
[11:52] <frankban> rogpeppe: thanks
[12:00] <fwereade> frankban, sorry, everything went weird for a bit -- are you still seeing problems?
[12:01] <frankban> fwereade: yes, rogpeppe is trying to reproduce, basically I see the same install hook failure running "juju bootstrap --upload-tools" and then "juju deploy cs:precise/juju-gui".
[12:24]  * dimitern lunch
[12:28] <rogpeppe> frankban, fwereade: ok, i've reproduced the problem
[12:29] <frankban> rogpeppe: thanks, :-/
[12:30] <rogpeppe> fwereade: here's the whole error log that i see: http://paste.ubuntu.com/5646211/
[12:30] <rogpeppe> fwereade: sorry, uniter log
[12:34] <frankban> rogpeppe: that seems a charm error, unrelated to the problem I am encountering, and probably not depending on juju-core. It seems that config-get worked for you.
[12:34] <rogpeppe> frankban: yes, i was just coming to that conclusion
[12:36] <frankban> rogpeppe: so, it must be something in my configuration, maybe it's worth retrying after deleting stuff in $GOPATH/bin and /pkg?
[12:36] <rogpeppe> hmm, it would be nice if juju status could print the agent-version urls
[12:36] <fwereade> rogpeppe, yeah, it would
[12:36] <fwereade> frankban, rogpeppe: that's how it looks to me as well
[12:36] <rogpeppe> frankban: are you sure you're executing the juju from $GOPATH/bin ?
[12:37]  * fwereade has to go to lunch, late already, back later at dimiter's
[12:37] <rogpeppe> fwereade: enjoy
[12:38] <frankban> rogpeppe: yes I am, I am explicitly calling $GOPATH/bin/juju.
[12:38] <frankban> rogpeppe: in juju status I saw agent-version: 1.9.12 on machine 1 and agent-version: 1.9.11 on machine2
[12:38] <rogpeppe> frankban: and you've done go install launchpad.net/cmd/juju, presumably?
[12:39] <rogpeppe> frankban: ah!
[12:39] <rogpeppe> frankban: did you do a destroy-environment before bootstrapping?
[12:39] <frankban> rogpeppe: yes
[12:40] <rogpeppe> frankban: what does juju --version print?
[12:40] <frankban> $ ./juju version
[12:40] <frankban> 1.9.12-quantal-amd64
[12:40] <frankban> rogpeppe: ^^^
[12:41] <rogpeppe> frankban: what happens if you try: juju upgrade-juju --upload-tools ?
[12:42] <rogpeppe> frankban: it's really weird that you're seeing 1.9.11 on the second machine
[12:42] <frankban> rogpeppe: yes
[12:42] <rogpeppe> frankban: hold on, do you mean machine 0 and machine 1 ?
[12:43] <frankban> rogpeppe: do I need a bootstrapped juju before executing upgrade-juju?
[12:43] <rogpeppe> frankban: yeah
[12:43] <rogpeppe> frankban: but you've got that, no?
[12:43] <frankban> rogpeppe: yes, I need to bootstrap again, I destroyed the environment
[12:44] <rogpeppe> frankban: ah, in that case, i recommend blowing away $GOPATH/bin and $GOPATH/pkg and doing go install launchpad.net/juju-core/...
[12:44] <rogpeppe> frankban: before trying again
[12:44] <frankban> rogpeppe: ok
[12:57] <frankban> rogpeppe: same error :-/, and same agent version mismatch: http://pastebin.ubuntu.com/5646274/
[12:58] <frankban> rogpeppe: FWIW, I am using "default-series: precise" in environments.yaml
[13:08] <rogpeppe> frankban: what result does juju status print if you use the juju command from this branch: lp:~rogpeppe/juju-core/256-more-status ?
[13:11] <frankban> rogpeppe: http://pastebin.ubuntu.com/5646309/
[13:12] <rogpeppe> frankban: ah! i see the issue
[13:12] <frankban> rogpeppe: cool!
[13:13] <rogpeppe> frankban: i'm not sure of the best way to fix it though :-)
[13:13] <rogpeppe> frankban: note that the bootstrap node is running quantal, and the other node is running precise
[13:14] <frankban> rogpeppe: yes, that's maybe because I am bootstrapping the env using a juju compiled in my quantal machine
[13:15] <niemeyer> Hello rockstars
[13:16] <rogpeppe> frankban: ah! this is because your charm is precise not quantal
[13:16] <rogpeppe> frankban: so it's doing exactly what we asked it to do
[13:16] <rogpeppe> niemeyer: hiya
[13:16] <frankban> rogpeppe: indeed, I need the charm to be deployed on precise
[13:16] <niemeyer> rogpeppe: Yo
[13:16] <rogpeppe> frankban: so you're asking the impossible here
[13:17] <rogpeppe> frankban: because you're building the tools on quantal and expecting them to be used by a precise charm
[13:18] <rogpeppe> frankban: if we had changed the major version number as we should when we changed the db schema, you should have got a better error (no tools found)
[13:18] <frankban> rogpeppe: aha! so the machine in precise will always get the latest released version of the agent for that platform?
[13:19] <rogpeppe> frankban: the machine in precise will grab what tools it can find that match its series.
[13:19] <rogpeppe> frankban: this is arguably wrong. the latest thinking, i think, is that if there's anything at all in the private bucket, it should ignore anything else.
[13:20] <rogpeppe> frankban: anyway, your best best for fixing the problem is to create a quantal version of the gui charm
[13:21] <frankban> rogpeppe: ok, got it. so, I am deploying from trunk because I need "default-series" to be respected, but this way I am preventing the tools to be shared, because my machine is quantal, right?]
[13:21] <rogpeppe> frankban: yeah
[13:21] <rogpeppe> frankban: so if you deployed --upload-tools from precise, it would work (as it does for me)
[13:29]  * rogpeppe goes for lunch
[13:42] <dimitern> back
[13:52] <frankban> rogpeppe: so, I should be able to develop a precise charm bootstrapping from trunk (quantal) once a newer precise juju (containing latest settings changes) will be added to the cache, right?
[13:56] <rogpeppe> frankban: yeah
[13:57] <frankban> rogpeppe: cool, any plan on when this will happen already?
[13:57] <rogpeppe> frankban: next release date
[13:57] <rogpeppe> frankban: i'm not quite sure when that will be
[13:57] <rogpeppe> frankban: i think it's once every two weeks
[13:58] <frankban> rogpeppe: great, thanks for your help
[14:38] <fwereade> rogpeppe, ping
[14:38] <rogpeppe> fwereade: pong
[14:38] <fwereade> rogpeppe, Conn.PutCharm just adds 1 to revision -- was this thought about carefully or just cloned from python?
[14:39] <fwereade> rogpeppe, (when bumping revisions, that is)
[14:39] <fwereade> rogpeppe, (if you recall)
[14:39] <rogpeppe> fwereade: it was reasonably carefully thought about (i started with one approach, then gustavo suggested the current one)
[14:41] <rogpeppe> fwereade: erm, actually i might be thinking of bump-version
[14:41] <fwereade> rogpeppe, that's what I want you to be thinking about :)
[14:41] <fwereade> rogpeppe, I'm trying to figure out the right approach when upgrading
[14:41] <rogpeppe> fwereade: i mean upgrade-juju --bump-version
[14:41] <fwereade> rogpeppe, ah, ok
[14:41] <fwereade> rogpeppe, I guess it's essentially the same question: are we deliberately handwaving multiple users with their own local repos?
[14:41] <rogpeppe> fwereade: what other behaviour might you consider?
[14:42] <rogpeppe> fwereade: i think so.
[14:42] <rogpeppe> fwereade: the whole issue of local charms is wrong anyway
[14:42] <rogpeppe> fwereade: because one user's local charm might be nothing like another's
[14:42] <fwereade> rogpeppe, one greater than max rev of matching charms in state and local repo
[14:43]  * fwereade tries to figure out what's the worst thing that can happen if we just use PutCharm from upgrade-charm
[14:43] <fwereade> ...or if we actually can use it at all
[14:44] <rogpeppe> fwereade: i think we *should* use PutCharm from upgrade-charm
[14:44] <fwereade> rogpeppe, ok, but we need to get the charm twice then
[14:44] <rogpeppe> fwereade: and fix it if it's got the wrong behaviour
[14:44] <fwereade> rogpeppe, I fear it's more a rewrite than a fix
[14:45] <rogpeppe> fwereade: once when we deploy and once when we upgrade?
[14:45] <fwereade> rogpeppe, no, twice on upgrade
[14:45] <rogpeppe> fwereade: ah, how so?
[14:45] <fwereade> rogpeppe, we can't know what bumpRevision should be before we have a charm
[14:45] <rogpeppe> fwereade: bumpRevision only works with local charms, no?
[14:46] <fwereade> rogpeppe, charm dirs, specifically, local charms don't have to be dirs
[14:46] <rogpeppe> fwereade: bumpRevision doesn't work unless it's a dir
[14:46] <fwereade> rogpeppe, and we don;t know charm kind until we've got it
[14:46] <rogpeppe> fwereade: and i think that's probably ok
[14:46] <fwereade> rogpeppe, yes
[14:47] <fwereade> rogpeppe, so we can't know what's safe to pass for bumpRevision unless we get the charm and find out the type
[14:47] <rogpeppe> fwereade: this is client-side, right?
[14:47] <fwereade> rogpeppe, yeah
[14:48] <rogpeppe> fwereade: so what's wrong with just calling PutCharm with bumpRevision if specified, and just failing if it's not a dir?
[14:48] <fwereade> rogpeppe, bumpRevision, if sane, is automatic when upgrading
[14:48] <fwereade> rogpeppe, the question is determining sanity
[14:48] <rogpeppe> fwereade: ah, i see
[14:49] <rogpeppe> fwereade: hmm, i'm not sure that's right
[14:49] <rogpeppe> fwereade: that means that if i upgrade-charm a bundle, it will silently do a different thing than if i upgrade-charm a dir
[14:50] <fwereade> rogpeppe, yes -- when working with dirs, we do different things
[14:50] <rogpeppe> fwereade: i think i'd hope that upgrade-charm would do exactly the same thing regardless of the source of the charm.
[14:50] <rogpeppe> fwereade: currently we only do different things if you explicitly *ask* to do different things, no?
[14:51] <fwereade> rogpeppe, define "currrently"
[14:51] <fwereade> ;)
[14:51] <rogpeppe> fwereade: in the current trunk
[14:51]  * fwereade shrugs
[14:51] <rogpeppe> fwereade: of juju-core
[14:51] <fwereade> it's not implemented ;)
[14:52] <rogpeppe> fwereade: well, we have deploy --bump-revision
[14:52] <rogpeppe> fwereade: which i'd expect to be the same as upgrade --bump-revision
[14:52] <rogpeppe> sorry, upgrade-charm
[14:53] <rogpeppe> fwereade: i think making it explicit forces the user to think about potential multi-user issues
[14:54] <fwereade> rogpeppe, it was a heavily requested feature
[14:55] <rogpeppe> fwereade: bump-revision? or the automatic nature of it?
[14:55] <fwereade> rogpeppe, automatic bump
[14:56] <rogpeppe> fwereade: i'd be happier if upgrade-charm didn't change the local charm at all, but uploaded it at one revision higher than the charm in the state
[14:56] <rogpeppe> fwereade: the side-effect on disk seems unnecessary
[14:57] <fwereade> rogpeppe, not unreasonable
[14:57] <rogpeppe> fwereade: and in that case you can do it with any charm at all
[14:57] <fwereade> rogpeppe, hmmmm, not sure that makes sense to me
[14:58] <rogpeppe> fwereade: yeah, you probably want it to happen only with local charms
[14:58] <rogpeppe> fwereade: where there's no automatically updated revision when it changes
[14:58] <fwereade> rogpeppe, yeah
[14:59] <fwereade> rogpeppe, trying to figure out if I can forget about the charm in state and just do one higher than the local one though
[14:59] <rogpeppe> fwereade: if you're not changing it on disk, that won't work
[15:00] <rogpeppe> fwereade: BTW is there some way of finding out the highest revision number for a given charm in the state?
[15:00] <fwereade> rogpeppe, I didn't specifically agree to not-changing-on-disk, but I'm still considering it
[15:00] <fwereade> rogpeppe, nope
[15:01] <rogpeppe> fwereade: i think it might be best to go for the simplest possible approach here
[15:01] <rogpeppe> fwereade: for the time being
[15:01] <fwereade> rogpeppe, I think, though, that if we say local repos are only supported in single-user mode, we can get away with just bumping locally
[15:01] <rogpeppe> fwereade: yeah
[15:01] <fwereade> rogpeppe, ok, thanks, we'll see where we can get to with that
[15:01] <rogpeppe> fwereade: and don't worry about getting the charm twiece
[15:02] <rogpeppe> fwereade: (you could have PutCharm return a particular error if it can't bump the version)
[15:02] <fwereade> rogpeppe, as long as I check repo type I'll only do that when it's local
[15:02] <fwereade> rogpeppe, ah, hmm, yeah
[15:02] <fwereade> rogpeppe, cheers
[15:02] <rogpeppe> fwereade: np
[15:11] <rogpeppe> fwereade: does this code look right for adding then removing a relation? http://paste.ubuntu.com/5646600/
[16:03] <mattyw> anyone know a reason I might be getting connection timed out to when trying to run juju status?
[16:11] <rogpeppe> mgz: ping
[16:11] <mgz> rogpeppe: hey
[16:12] <rogpeppe> mgz: i was just looking at the test images stuff in environs/ec2
[16:12] <rogpeppe> mgz: what's supposed to be the difference between TestImagesContent and imagesData ?
[16:13] <rogpeppe> mgz: because as it is, anyone that runs the tests on i386 will get failing tests
[16:13] <rogpeppe> mgz: because TestImagesContent has no i386 entries
[16:13] <mgz> rogpeppe: right.
[16:13] <mgz> do you think the juju test suite passes on i386?
[16:14] <rogpeppe> mgz: i know it doesn't
[16:14] <rogpeppe> mgz: for this one reason (at least, i guess)
[16:14] <rogpeppe> mgz: i don't see any other reason why it shouldn't
[16:14] <mgz> so, this is an intermediate state. there's no reason to have a static imagesData at all.
[16:14] <rogpeppe> mgz: it's just for tests, right?
[16:15] <mgz> the tests that need it aren't testing the mapping of cloud thingy data to image ids
[16:15] <mgz> so, they should just be given something that will work
[16:15] <rogpeppe> mgz: yeah, the problem is that various pieces of logic use version.Current
[16:15] <rogpeppe> mgz: that is being fixed, but for the time being, i guess i'll add an i386 line to TestImagesContent
[16:16] <mgz> I envisioned the next step as just generating the right string from the same values as the lookup will use
[16:16] <rogpeppe> mgz: i think just fixing version.Current for the tests should do the job
[16:17] <rogpeppe> mgz: which is a little bit less whiteboxy
[16:18] <rogpeppe> mgz: it took me ages to work out why the lines in imagesData weren't being used :-)
[16:45] <dimitern> rogpeppe: care for a review? :) https://codereview.appspot.com/7927043/
[16:45] <rogpeppe> dimitern: will do
[16:45] <dimitern> rogpeppe: cheers
[17:06] <TheMue> fwereade: ping
[17:07] <fwereade> TheMue, pong
[17:07] <TheMue> fwereade: just too a look into deploy.go. could it be that deploy --config is already implemented?
[17:08]  * fwereade looks
[17:09] <TheMue> fwereade: it reads the YAML and passes it to conn.DeployService()
[17:10] <fwereade> TheMue, hmm, seems so
[17:10] <fwereade> TheMue, that's good news :)
[17:10] <TheMue> fwereade: seldom been so fast. *lol*
[17:11] <fwereade> TheMue, nice :)
[17:11] <fwereade> TheMue, just reviewed the $HOME stuff
[17:11] <fwereade> TheMue, please let me know if there's any uncertainty
[17:12] <TheMue> fwereade: yep, will read it now. did you find any Init() outside of main()? sh**, should be all removed. *sigh*
[17:12] <fwereade> TheMue, only a couple
[17:13] <TheMue> fwereade: ok, will clean it. thx for the review
[17:14] <rogpeppe> dimitern: am looking at your review. while i'm at it, if you want a simple one: https://codereview.appspot.com/8016043
[17:14] <fwereade> TheMue, as a suggestion, the two nastiest places are repo.go and cloudinit_test.go
[17:14] <dimitern> rogpeppe: sure
[17:14] <rogpeppe> fwereade: this branch should fix trunk tests under i386
[17:14] <rogpeppe> https://codereview.appspot.com/8016043
[17:15] <fwereade> TheMue, single small CLs to unmess those particular areas would probably make your life easier
[17:15]  * fwereade looks
[17:16] <TheMue> fwereade: yes, it started small, but then the effect growed
[17:16] <fwereade> TheMue, I know how it happens :)
[17:18] <fwereade> rogpeppe, LGTM
[17:18] <rogpeppe> fwereade: thanks!
[17:19] <TheMue> fwereade: regarding the cache path, could it be a problem if two different environments share the same cache path?
[17:19] <fwereade> TheMue, don't think so, at the moment, they both have the same store
[17:20] <fwereade> TheMue, this will probably end up changing but we don;t have to worry about that now
[17:21] <TheMue> fwereade: ok, hmm, thinking about one who has no $HOME/.juju/cache, because she only uses $JUJU_HOME for her environments
[17:21] <fwereade> TheMue, surely we just have to use JujuHome()?
[17:22] <TheMue> fwereade: yes, no more constant. and that has been the original idea, where Init() always ensures a $JUJU_HOME. ;)
[17:22] <fwereade> TheMue, I don't think that should be internal to the charm package though... seems like the simplest thing is to make cachePath a param
[17:22] <fwereade> TheMue, although that's probably out of scope
[17:23] <TheMue> fwereade: but not this CL, my technical leador told me. :D
[17:23] <fwereade> TheMue, just get it from JujuHome at runtime and forget that constant
[17:23] <fwereade> TheMue, :)
[17:23] <dimitern> rogpeppe: reviewed
[17:24] <fwereade> if anyone's free, frankban's https://codereview.appspot.com/7947043/ lacks for a recent second LGTM
[17:24] <rogpeppe> fwereade: will have a look after i've finished dimitern's
[17:24] <frankban> thanks rogpeppe
[17:33] <TheMue> fwereade: ah, your reviewd branch hasn't been the newest one. the Init()s seem already to be removed. *phew*
[17:34] <fwereade> TheMue, oh, damn, sorry
[17:34]  * fwereade wonders how he did that
[17:34] <TheMue> fwereade: no pro, only good for me.
[17:35] <TheMue> fwereade: the patch set is no 6, your comments on no 5.
[17:35] <fwereade> TheMue, hell, could have sworn I refreshed
[17:36] <fwereade> TheMue, sorry again
[17:37] <TheMue> fwereade: you still found enough ;)
[17:37] <jam> anyone around to ask about connection problems?
[17:37] <jam> I'm trying to bootstrap, and then status fails with lots of "connection established" but the immediately disconnecting.
[17:37] <mattyw> jam, do you mean me?
[17:38] <jam> I mean a juju-dev person
[17:38] <jam> like TheMue or fwereade
[17:38] <TheMue> jam: connecting to what?
[17:39] <jam> TheMue: this is the start of /var/log/juju/machine-0.log http://paste.ubuntu.com/5647008/
[17:39] <jam> connecting to mongo is failing because of auth
[17:40] <jam> juju the client does: http://paste.ubuntu.com/5647012/
[17:40] <jam> over and over
[17:40] <TheMue> jam: hmm, no, not had during my tests
[17:41] <mattyw> jam, TheMue you seen anything like this? https://bugs.launchpad.net/juju-core/+bug/1159885
[17:41] <_mup_> Bug #1159885: juju status fails with connection timed out (1.9.12-precise-i386) <juju-core:New> < https://launchpad.net/bugs/1159885 >
[17:41] <TheMue> jam: but i also made no life test this afternoon
[17:42] <jam> mattyw: connection refused looks more like mongod isn't running
[17:42] <jam> and I can see that it is
[17:42] <mattyw> jam, it looks like it fails to install - see the 404 error?
[17:43] <jam> mattyw: right, bug 1159885 is because mongod isn't running, what I'm running into is because mongod is running but doesn't have the right auth keys
[17:43] <_mup_> Bug #1159885: juju status fails with connection timed out (1.9.12-precise-i386) <juju-core:New> < https://launchpad.net/bugs/1159885 >
[17:44] <mattyw> jam, yeah I saw that, I just wondered if you'd seen anything like that before
[17:44] <jam> I have not specifically seen that
[17:48] <fwereade> mattyw, I think I have seen that with version mismatches... did you run bootstrap (1) build against your local tree (2) with --upload-tools (3) with a default-series matching your own machine?
[17:49] <fwereade> mattyw, soory, I mean jam
[17:49] <jam> I'm not using --upload-tools
[17:49] <mattyw> fwereade, no problem, If you're able to spare a few minutes to take a look at mine after helping jam I'd appreciate it
[17:49] <jam> this is failing immediately after bootstrap
[17:52] <fwereade> jam, mattyw, I need to hit the shops before they close I'm afraid -- jam, I would suggest that rogpeppe is your man for that error if it's on the machine
[17:53] <jam> k
[17:54] <fwereade> mattyw, ah-ha! there's no i386 mongo build available
[17:54] <fwereade> mattyw, tyvm for excellent bug report
[17:54] <jam> mattyw: right, good catch fwereade, you have to run an amd64 target. I have a small patch for that
[17:54] <mattyw> fwereade, good news, no problem, I've been at the receiving end of too many bad bug reports
[17:55] <fwereade> gtg, nn all
[18:00] <mattyw> jam, thanks for the patch, I'll give that a go tomorrow morning
[18:01] <jam> fwereade, rogpeppe: looks like a version skew. cloud-init is passing '--constraints' to jujud on startup, but that obviously isn't supported by juju 1.9.11
[18:03] <rogpeppe> jam: which issue are you referring to here?
[18:03] <jam> rogpeppe: I was trying to bootstrap today without passing --upload-tools
[18:03] <jam> it fails b
[18:03] <jam> because trunk tip
[18:03] <jam> asks jujud to use '--constraints'
[18:03] <jam> but it doesn't support it
[18:05] <rogpeppe> jam: yes, we've made a backwardly incompatible change
[18:06] <rogpeppe> jam: it's a problem that we never increment the major version number
[18:06] <jam> well, we bump the minor, but yeah, that is a 1.9.12 won't suceed to bootstrap a 1.9.11 binary
[18:07] <jam> but we haven't finished publishing 1.9.12
[18:07] <rogpeppe> jam: exactly, and that's what you're trying to do
[18:36] <rogpeppe> right, that's me for the day
[18:36] <rogpeppe> g'night all
[18:36] <rogpeppe> there's a trivial proposal up for review here, BTW: https://codereview.appspot.com/7931045
[20:05] <thumper> morning
[21:12] <niemeyer> thumper: Yo
[21:12] <thumper> hi niemeyer
[22:10] <vds> I'm trying to juju bootstrap on precise with trunk juju-core but I get the following error:  error: juju-origin: expected nothing, got nothing
[22:27] <vds> davecheney, maybe I can disturb you for this, I'm trying to juju bootstrap on precise with trunk juju-core but I get the following error:  error: juju-origin: expected nothing, got nothing
[22:34] <davecheney> vds: never heard of that configuration key
[22:34] <davecheney> i'
[22:34] <davecheney> id' suggest deleting it
[22:35] <davecheney> vds: as a general comment, environments.yaml are not portable between the py and go versions
[22:35] <davecheney> this could be considered a bug
[22:35] <davecheney> but it is what it is
[22:36] <thumper> davecheney: hey
[22:36] <vds> davecheney, ah, that's good to know, now I have a similar error for s3-uri
[22:36] <thumper> davecheney: can I get some time from you this afternoon to chat about general State stuff?
[22:37] <davecheney> thumper: your afternoon or my afternoon ?
[22:37] <davecheney> gotta piss of to get a haircut about 2.2, 2.5 hours from now
[22:37] <thumper> davecheney: after lunch my time, would love to do it now, but I'm going to the gym in about 20 minutes
[22:37] <davecheney> ok
[22:37] <davecheney> hit me up when you get back
[22:38] <thumper> ok, ta
[22:43] <vds> davecheney, I'm afraid there's something broken, no matter what option I fix or comment, I always get the same error: expected nothing, got SOMETHING_ELSE
[22:43] <vds> davecheney, can you point me to who could be interested in that behavior?
[22:51] <davecheney> vds: I am the bugmaster for juju-core
[22:51] <davecheney> i can help
[22:51] <davecheney> vds: can you provide me with a copy of the environments.yaml ?
[22:52] <vds> sure
[22:55] <vds> davecheney, http://pastebin.ubuntu.com/5647900/
[23:00] <davecheney> vds: try removing line 19
[23:00] <davecheney> local should be ignored
[23:00] <davecheney> but just in case remove it, we don't have a local provider
[23:00] <davecheney> also, canonistack is unlikely to work
[23:00] <davecheney> it hasnot free public ips
[23:00] <davecheney> your best bets are hp cloud an ec2
[23:01] <vds> davecheney, ok I'll try ec2
[23:01] <vds> davecheney, thanks
[23:24] <davecheney> Thurloat: so here is the problem, the prototype for ServeHTTP does not return anything
[23:24] <davecheney> you have a request, and a writer which you can write to about things in the request
[23:24] <davecheney> sorry
[23:26] <davecheney> wrong  ch
[23:48] <m_3> davecheney: hey, so I don't see any man pages in the goju package
[23:49] <m_3> davecheney: shall we try to repurpose the juju-0.6 manpages?
[23:49] <m_3> davecheney: this came up when adding update-alternatives... the juju-2.0 just didn't have one :)
[23:50] <m_3> davecheney: perhaps just a build step that dumps the cli options to troff?
[23:56] <davecheney> m_3: will raise a bug
[23:56] <davecheney> TBH, nobody has considered man pages
[23:57] <m_3> davecheney: ha.. nm... found issue 101... https://code.google.com/p/go/issues/detail?id=101
[23:57] <davecheney> even better (or worse)
[23:57] <davecheney> oh, that
[23:57] <m_3> no biggie.. just wondering
[23:57] <davecheney> yeah, sort of related
[23:57] <davecheney> m_3: good catch, this is a compatabilty gap between pyjuju and gojuju
[23:57] <m_3> seems like it'd be pretty easy to format help output dynamically... bet that's there in the issue
[23:58] <davecheney> thumper: ping
[23:58] <m_3> the juju-0.6 man is really just the list of subcommands... essentially the output of `juju`
[23:58] <davecheney> ^ thumper is putting his energy into making juju help tell you stuffs
[23:58] <davecheney> i dunno if that superceeds or augments the man pages
[23:58] <m_3> rockin
[23:59] <m_3> I'll just version juju-0.6 accordingly and we can go from there (do the same in the 2.0 packaging)
[23:59] <m_3> planning on having MP for you on that one


[01:11] <zebastianortis> http://freedomainradio.com/BOARD/forums/p/28810/221573.aspx#221573
[17:26] <now3d> Hi there.  Could I ask if you would consider switching the Adobe Flash videos to be in the Ogg Theora format and use <video> tag? I looked at http://lubuntu.net/ but all the videos wouldn't play from Firefox on Ubuntu.
[17:28] <Timo_> that's an interesting point you're making :)
[17:28] <phillw> hiyas now3d you can propose it on the mailing list, but we are running really tight for the 11.04 deadlines
[17:29] <phillw> now3d: https://wiki.ubuntu.com/Lubuntu/GettingInvolved
[17:30] <phillw> all contributions are welcome, and we do have some lively discussions on emails - but you will not be spammed to death and have your email inbox filled :D
[18:16] <needhelp> hi@all
[18:17] <needhelp> i installed lubuntu but in the end the pc needs to restart
[18:17] <needhelp> but didnt restart
[18:17] <needhelp> i close the pc myself
[18:17] <needhelp> and after i started the pc nothing works
[18:17] <needhelp> i cant open webbrowser
[18:18] <needhelp> someone can help me
[18:18] <now3d> phillw: ok, i will email. Do you know if i can post without being a member to<EMAIL_ADDRESS>?
[18:19] <now3d> needhelp: what happens when you restart? Can you login ok?
[18:19] <needhelp> i can login
[18:19] <needhelp> i see the destop
[18:20] <needhelp> but i cant use the webbrowser and other programms
[18:20] <needhelp> thats the 2nd time i installed but same problem
[18:21] <now3d> are the other programs on the start menu?
[18:22] <now3d> perhaps your hard drive has errors, which prevent the install completing.
[18:22] <needhelp> mhh wait i need to start my pc
[18:31] <needhelp> ok i started it is there a opinion to repair by cd?
[18:31] <needhelp> my english is not so good im from germany
[18:32] <Yorvyk> needhelp, there isn't a repair option. What's the problem
[18:34] <needhelp> i installed lubuntu but in the end of the instalation it needs to restart but after 15 min the computer didnt restart
[18:34] <Yorvyk> now3d, I think your suggestion about the videos is a good one, if you wan'y I'll put it in the mailing list for you .
[18:34] <needhelp> i  closed the computer myself
[18:34] <needhelp> and after i start computer nothing works
[18:34] <needhelp> i can login
[18:35] <needhelp> webbrowser cant start
[18:36] <needhelp> i can start terminal
[18:36] <Yorvyk> needhelp, type 'chromium-browser' in the terminal
[18:38] <needhelp> failed
[18:38] <now3d> needhelp: You could press Alt+F-key, and see if any error messages there
[18:39] <now3d> needhelp: Also please boot and check your drives for bad sectors: http://m.jguk.org/2007/11/check-your-filesystems.html
[18:40] <needhelp> after i did
[18:40] <needhelp> what need i do
[18:41] <needhelp> can i repair the system by cd or a code
[18:41] <needhelp> cant
[18:41] <Yorvyk> needhelp, did the browser start
[18:42] <needhelp> no ddidnt
[18:43] <Yorvyk> did you get any error message in the terminal
[18:43] <needhelp> y i did wait i trie to copy by usb stick
[18:52] <needhelp> cant anybody help me
[18:52] <needhelp> can i install firefoy
[18:52] <needhelp> firefox if yes how
[18:53] <now3d> needhelp: Did you complete fsck check on your drive?
[18:53] <now3d> needhelp: Did you press Alt+F-key and see any output indicating the error?
[18:53] <bioterror> X was broken on Natty
[18:53] <now3d> needhelp: I will wait for your replies on these two questions before providing further help
[18:53] <bioterror> upgrades fixed it
[18:55] <needhelp> nothing happens if i press alt+ f
[18:56] <now3d> Which F-Keys did you press?
[18:57] <needhelp> F
[18:57] <needhelp> ah sry i need to pres f1 or f2 or f3
[18:57] <now3d> F is a "function key" see top of keyboard
[18:57] <needhelp> orß
[18:57] <needhelp> OR?
[18:57] <needhelp> what
[18:57] <now3d> press Ctrl+Alt+F1  etc
[18:58] <needhelp> i need to login?
[18:58] <now3d> no, just look at the error output. You can see the error from install. do not reboot manuaully
[18:59] <needhelp> im newbie in linux
[18:59] <needhelp> how i see the error output
[18:59] <needhelp> i need to write something?
[19:05] <now3d> are there any errors indicated on the different screens?
[19:05] <now3d> Ctrl+Alt+F8 normally should show after the install
[19:08] <needhelp> how i come out command display i pushed crt+alt+f1     now if i push crt+alt+f8 nothing happens
[19:09] <Yorvyk> ctrl+alt+f7
[19:11] <needhelp> ok i pushed ctr  alt f8  ther is only a _
[19:12] <needhelp> what do i need to do
[19:14] <needhelp> only a _ is blinking
[19:14] <needhelp> what do i need to do
[19:20] <now3d> needhelp: Did you look after the install completed?   Or did you reboot?
[19:23] <bioterror> hi sz
[19:35] <szczur> hi bioterror
[19:43] <lubuntufan> Hello, can someone tell me how many partitions to create and the size, including swap. thanks
[19:44] <Yorvyk> lubuntufan, you can get away with as little as 3 GiB for /
[19:45] <bioterror> one partition and swap
[19:45] <bioterror> depends what you're doing
[19:45] <bioterror> and how much ram
[19:45] <bioterror> if you're going to hibernate, then about as much SAWP as you have you RAM
[19:45] <bioterror> but like 2GB is okay for the swap and rest /
[19:46] <Yorvyk> lubuntufan, https://help.ubuntu.com/community/SwapFaq is as good as any expalnation of swap
[19:46] <lubuntufan> Thanks, Yorvyk. I have been having difficulties with teh installation. Primary HD is Win7 and I am installing to a SD Card (duped as a HD) and from a USB. It installs fine but deletes all teh partitions on the SD.
[19:48] <Yorvyk> lubuntufan, that depends on what you tell the installer to do
[19:49] <Yorvyk> lubuntufan, I always specify which partition to install to.
[19:49] <lubuntufan> If I try to install on a Fat32 partition on the SD, I get an error that no root file system defined. Hence chose the automated install "install along with other OSs" option.
[19:49] <Yorvyk> lubuntufan, it won't install on FAT32
[19:50] <Yorvyk> and I wouldn't recommend a swap a partition on an SD card either
[19:51] <Yorvyk> unless you only intend to try it for a short while
[19:51] <lubuntufan> Ok. that's where teh problem is..not installing on Fat32. So what do you receommend?
[19:52] <bioterror> ext4 ofkooz
[19:52] <lubuntufan> How about NTFS?
[19:52] <bioterror> hahahaha
[19:52] <bioterror> "I Like my filesystem like my girls, fat and 16" :D
[19:52] <Yorvyk> ext2 on an SD card or create a partition on the HD
[19:54] <Yorvyk> If you have over 1.5 GiB of RAM you don't really need swap
[19:54] <bioterror> Yorvyk, any scientific proofs about not using journaling fs on sd
[19:54] <lubuntufan> Thanks. so do I need to create 2 partitions or will the installer also create the swap partition?
[19:54] <lubuntufan> ok. that answered my question...I have 4GB RAM
[19:56] <Yorvyk> So use manual install and select the SD card if you want to install there and tell it to format Ext2 and mount it at /
[19:57] <Yorvyk> bioterror, SD cards don't have very good wear levelling built in and are not designed to be constantly written and erased.
[19:58] <bioterror> Yorvyk, I think that's related to older cards
[19:58] <bioterror> flash drive technology has advanced
[19:58] <lubuntufan> Thank you so much Yorvyk. I will give it a try. But a bit leery on teh manual install. My SD is a SDHC Ultra II - 16GB.
[19:58] <bioterror> have you heard that they are using SSD drives!
[19:59] <lubuntufan> I am trying to us Lubuntu as a lightweight qucik boot for surfing/youtube etc.
[19:59] <bioterror> Yorvyk, if you think about DSLR cameras
[20:00] <Yorvyk> Yes but SSD drives have wear levelling algorithms built in so the same space doesn't get written to again and again.
[20:00] <Yorvyk> Good luck lubuntufan, any more problems call back :)
[20:02] <bioterror> ext4 can be used without journaling
[20:02] <bioterror> :D
[20:02] <lubuntufan> Thank you guys. The other reaon I am using teh SD is as I am running out of space in teh primary HD.
[20:03] <Yorvyk> I just recommend Ext2 because it saves altering parameters
[20:03] <Yorvyk> lubuntufan, you need to have a tidy up :)
[20:04] <lubuntufan> Let me try the installation again :)
[20:04] <Yorvyk> bioterror, Newer SD cards could last for years before failing but I don't like encouraging excessive wear if it can be avoided
[20:05] <bioterror> well yeah
[20:05] <bioterror> those are okay for reading stuff
[20:06] <bioterror> but constant usage is not good as browser cache on stuff
[20:06] <bioterror> and stuff
[20:07] <Yorvyk> In a camera you are not constantly reading and writing
[20:10] <bioterror> you're writing
[20:10] <phillw> I always advise a microsoft approved speed usb device, they are faster ans designed with fault tollarence built in. They cost 2 - 3 times of a standard usb stick, but mine has never let me down. I recall one guy saying he was going to blow up the manufactures of the 'cheap' ones as he'd had several fail on him. :P
[20:10] <bioterror> if you use RAW files, you write 10-40MB files
[20:12] <Yorvyk> USB stickes are different to SD cards.  SD cards rely on the controller and on cheap card readers fitted to most PCs these are not brilliant
[20:13] <phillw> Yorvyk: there are also SD cards and 'SD' cards... same applies - you get what you pay for :)
[20:13] <Yorvyk> The two most reliable USB flash drives I've had were £5 for 2 from Netto
[20:15] <Yorvyk> But if the controller is nothing great it may still end up writing to the same place over and over again
[20:15] <phillw> my 2GB one runs a full lubuntu with remembering every thing, it's actually hard to determine which is faster, as lubuntu is so lean.
[20:16] <phillw> my next laptop will be usb3 :D
[20:16] <Yorvyk> Can you get USB3 things to plug in?
[20:17] <phillw> I'm not sure if usb3 is fully supported in the kernel.
[20:17] <Yorvyk> May not be as there isn't much to test it on.
[20:18] <bioterror> 64GB USB3 stick is cheap ;)
[20:19] <Yorvyk> How cheap
[20:19] <phillw> Yorvyk: I've not seen it officially announced yet ... http://www.pcpro.co.uk/news/255991/linux-first-to-support-usb-3
[20:20] <Yorvyk> I saw a MOBO about 18 months ago with USB3 on it but there was nothing to plug into it.
[20:20] <bioterror> hmmm
[20:20] <bioterror> actually
[20:21] <bioterror> 60GB usb 3.0 key is 245€
[20:22] <phillw> now, that's odd, why would Xorg be using up 30% of my processor time?
[20:22] <phillw> I've just seen my CPU usage spike to nearly 100%.
[20:23] <Yorvyk> what else was running
[20:24] <tenach> What is a good, slim ftp application?
[20:24] <bioterror> lftp
[20:25] <tenach> bioterror: thanks :D
[20:25] <phillw> http://pastebin.com/d6fXhZ9W
[20:25] <bioterror> I've never seen a really good working graphical ftp client on linux
[20:25] <bioterror> tbqh
[20:26] <tenach> bioterror: I really enjoy filezilla, but on my work machine i usually just use nautilus.
[20:26] <tenach> However, I'm spinning my own liveusb of lubuntu so I can have a slim, portable workstation.
[20:26] <bioterror> lftp handle sftp and stuff
[20:26] <tenach> That's all i need. :D
[20:27] <bioterror> you just need to remember that mirror -Rc sends stuff, and mirror -c receives
[20:27] <Yorvyk> phillw, it was bored and wanted some thing to do
[20:28] <phillw> Yorvyk: yeah, but it's a reet PITA to have to reboot, as I have to restart dragoneyes...... :(
[20:30] <bioterror> just kill X? :D
[20:30] <Yorvyk> I can get Xorg to spike like that moving windows around on a slow machine
[20:30] <Yorvyk> but it doesn't remain at that level
[20:36] <Yorvyk> phillw, I've  solved the problem http://pastebin.com/J4gnEfCR :P
[20:52] <phillw> Yorvyk: and now I'm totally confused.... http://pastebin.com/96idu249
[20:56] <Yorvyk> phillw, I've seen a few things about high Xorg usage, what video driver are you using
[20:57] <phillw> ahh... I think I found the cause, I had two instances of Chromium running.
[20:58] <phillw> as to why it would that to Xorg, pass.....
[20:59] <Yorvyk> phillw, that looks like a bug to me
[21:00] <phillw> yeah but in which package? Xorg or Chromium?
[21:01] <Yorvyk> Yeah :)
[21:02] <phillw> I'll see if does it again and report it to both teams - they can then argue it out :P
[21:02] <Yorvyk> all you can do really


[08:06] <kirkland> RoAkSoAx: pong
[15:33] <RoAkSoAx> kirkland: ping :).
[15:33] <kirkland> RoAkSoAx: yo
[15:33] <RoAkSoAx> kirkland: I finally setup a cloud, however I did it all in VM's since I wanna start looking into the HA thingy
[15:34] <RoAkSoAx> kirkland: I faced couple issues, in fact I still have one
[15:34] <RoAkSoAx> the scs is not recognized by the clc
[15:34] <kirkland> RoAkSoAx: is this Maverick or Lucid?
[15:34] <RoAkSoAx> maverick, the setup I'm doing is 1 clc, 1 walrus, 1 cc/scs, 1 nc
[15:35] <RoAkSoAx> kirkland: at first the issue was that the nc was not being recognized, then I got it fixed, but then the scs was not recognized apparently
[15:35] <kirkland> RoAkSoAx: hmm, okay
[15:35] <kirkland> RoAkSoAx: Daviey is mostly in charge of eucalyptus for Maverick
[15:36] <kirkland> RoAkSoAx: i probably need to point you to him
[15:36] <RoAkSoAx> kirkland: i'll ping him, though I'll try everything out in Lucid :)
[15:37] <kirkland> RoAkSoAx: maverick should be fine
[15:37] <RoAkSoAx> kirkland: everything was working at first, besides the NC because it was not recognized
[15:38] <RoAkSoAx> kirkland: then I got it recogniced, but the sc was not anymore
[15:41] <RoAkSoAx> when I do euca_conf --list-scs it shows that the registered sc is "cluster1  sc-host"
[15:43] <RoAkSoAx> kirkland: i'll setup another with Lucid. When I have it running I'll let you know to try to try to get the HA working at least for a couple of controllers
[23:32] <RoAkSoAx> kirkland: I have to copy keys between the clc and cc right?