[00:27] <davecheney> niemeyer: OT, i met Benny Siegert last night
[00:27] <davecheney> he now works for google as an SRE
[00:27] <davecheney> and was visiting Sydney
[00:28] <niemeyer> davecheney: Benny.. hmm
[00:29] <niemeyer> davecheney: I think I had a couple of interactions with him only in golang-nuts@
[00:29] <niemeyer> davecheney: There was an event yesterday, right? How was it?
[00:30] <davecheney> excellent
[00:30] <davecheney> numbers are improving every time
[00:30] <davecheney> we had 50 people
[00:30] <davecheney> more maybe
[00:30] <davecheney> the room was packed
[00:31] <thumper> davecheney: a go meetup?
[00:32] <davecheney> yup
[00:32] <davecheney> that was why I couldn't make the meeting last night
[00:32] <davecheney> I run the sydney golang meetup group
[00:32] <thumper> ah
[00:33] <thumper> I think I've just found a real use of the struct composition with methods...
[00:33] <thumper> the alias struct in supercommand.go
[00:33] <thumper> it overrides Info
[00:33] <thumper> but not the other methods
[00:34] <thumper> those get resolved to Command?
[00:34] <thumper> I do have to be honest in thinking that this looks like bastardised inheritance
[00:34] <davecheney> thumper: it's much less than that
[00:34] <davecheney> it is no inheritence at all
[00:35] <thumper> so how does it resolve the correct function calls?
[00:35] <davecheney> always at compilation time
[00:35] <thumper> sure, how
[00:35] <davecheney> embedded fields are just syntactic sugar
[00:36] <davecheney> type S struct { io.Reader }
[00:36] <davecheney> var s S
[00:36] <davecheney> s.Read is just sugar for s.Reader.Read
[00:36] <davecheney> ^ one example
[00:36] <thumper> only if s.Read doesn't exist?
[00:36] <davecheney> yup
[00:36] <thumper> hmm
[00:39]  * thumper pokes supercommand internals some mroe
[00:43]  * thumper gets hit by python vs. go differences again
[00:48] <thumper> hmm...
[00:48] <thumper> davecheney: how clever is go in matching similar names
[00:48] <thumper> eg. I have: type A struct {val Foo}
[00:48] <thumper> and a method
[00:48] <thumper> func bar() {
[00:49] <thumper> no...
[00:49] <thumper> func bar(val Foo) {
[00:49] <thumper> a = A{val: val}
[00:49] <thumper> will it match those properly?
[00:49] <thumper> or do I have to rename something
[00:55] <davecheney> thumper: o_O
[00:55] <thumper> davecheney: this is relatively normal python and c++
[00:56] <davecheney> didn't undestand your example
[00:56] <davecheney> say again, over
[00:56] <thumper> davecheney: I have a function parameter that matches the name inside a structure
[00:56] <thumper> that I'm trying to initialise
[00:56] <thumper> so I'm trying to create an A
[00:56] <thumper> where A.val == parameter val
[00:56] <davecheney> yup, no problem there, they are different names
[00:57] <thumper> so A{val: val} is fine?
[00:57] <davecheney> sure
[00:57] <thumper> coolio
[00:57] <davecheney> val: isn't a symbol
[00:57] <davecheney> it's the name of a struct member
[00:57]  * thumper nods
[00:57] <davecheney> s/symbol/identifier
[00:57] <davecheney> when embedding you always have to disambiguate
[00:57] <davecheney> ie
[00:58] <davecheney> type S struct { io.Reader }
[00:58] <thumper> does go have a set type?
[00:58]  * thumper wants an ordered set
[00:58] <davecheney> actually, that is a crap example
[00:58] <davecheney> no, no set type
[00:58] <davecheney> you can use a map
[00:58] <thumper> :(
[00:58] <davecheney> maps are not ordered
[00:58] <davecheney> map iteration is random
[00:58] <thumper> no, but I want one
[00:58] <thumper> plz add to go 1.1
[00:59] <thumper> set + ordered_set
[00:59] <thumper> and ordered_map
[00:59] <thumper> :)
[00:59] <davecheney> the standard way is to extract the keys of a map
[00:59] <davecheney> sort them
[00:59] <davecheney> then using that sorted slice
[00:59] <davecheney> you get the picture
[00:59]  * thumper loves python
[00:59] <thumper> for key, val in sorted(some_dict):
[00:59] <davecheney> it is what it is
[01:00] <thumper> hmm.. missed the .items()
[01:00]  * thumper nods
[01:00]  * thumper will work around it
[01:02] <thumper> davecheney: so... if a second parameter is passed to make([]string, size)
[01:03] <thumper> davecheney: is the underlying array that size?
[01:03] <thumper> so meaning make([]string, 4) -> {"","","",""} ?
[01:03] <thumper> or is it actually empty with just enough space for 4 elements?
[01:04]  * thumper feels like he needs to read the language spec again
[01:05] <thumper> hmm. found it
[01:05] <thumper> make([]T, length)
[01:05] <thumper> make([]T, length, capacity)
[01:05] <thumper> hmm
[01:05] <thumper> is foo := []string
[01:05] <thumper> an array or a slice?
[01:06] <thumper> actually: foo := []string{}
[01:06] <davecheney> []slice
[01:07] <davecheney> [1234]array
[01:07] <davecheney> var foo []string -> nil slice, len and cap are 0
[01:07] <davecheney> foo := []string{} -> non nil slice, len and cap are 0
[01:08] <davecheney> foo := make([]string, 0) -> non nil slice, len and cap are 0
[01:08] <davecheney> if you are using reflect there is a difference between the 1st, and second and third arguments
[01:08] <davecheney> otherwise there is no difference
[01:09] <thumper> so... what I want is foo := make([]string, 0, len(otherthing))
[01:09] <thumper> as I don't want anything initially in foo
[01:09] <thumper> but I want to avoid unnecessary allocations
[01:10] <thumper> and I know at max there will be len(otherthing) elements
[01:10] <thumper> sound reasonable?
[01:10] <davecheney> sure
[01:10] <thumper> kk
[01:10] <davecheney> most times we don't bother setting a capacity
[01:10] <davecheney> just
[01:10] <davecheney> var foo []string ; for _, v := range thing { foo = append(foo, v) }
[01:11] <davecheney> ^ as an example
[01:11] <thumper> why?
[01:11] <thumper> how often would the underlying array resize?
[01:11] <thumper> it just seems like good manners to me
[01:12] <thumper> perhaps I'm over thinking
[01:15] <davecheney> i forget the exact mthod
[01:15] <davecheney> doubling up to 1000 elements then +1000 I think
[01:15] <davecheney> i can find out
[01:17] <thumper> so, adding 20 items causes how many allocations to an empty slice?
[01:17] <thumper> with a default capacity of zero
[01:17] <thumper> it means initially you are getting quite a few, unless the 0 -> next is something like 10
[01:18] <thumper> the default capacity specified for C++ std::vectors is 10 (by most implementations) for this exact reason
[01:18] <thumper> hmm...
[01:18] <thumper> not doubling all the time was a cause of a bug I hit with solaris c++ std::stringstreams a long while back
[01:18] <thumper> it was iterative
[01:19] <thumper> and not expecting the amount of data I was throwing at it
[01:19] <davecheney> I can check, i think it might start at 8
[01:19] <davecheney> but I am guessing
[01:19] <davecheney> if you think it is important, then set the capacity when known
[01:19] <davecheney> but avoid getting distracted by all the other places in the code where we do not do so
[01:19] <thumper> I only think it is important because I want to avoid unnecessary allocations
[01:20] <thumper> however
[01:20] <thumper> there will likely be absolutely zero notice by a user
[01:20] <thumper> so I'll keep the code simple
[01:34]  * thumper on the move again
[02:55] <thumper> bollocks, bollocks, bollocks
[02:55]  * thumper hacks and slashes recent changes
[03:31] <thumper> davecheney: back?
[03:31] <thumper> if I have a type of []string, and a method that takes (args ...string)
[03:31] <thumper> how to I pass the former into the latter?
[03:34] <thumper> found it
[03:37] <davecheney> yup, varags syntax
[03:37] <davecheney> func F(args ...string)
[03:37] <davecheney> var s []string
[03:37] <davecheney> F(s...)
[03:43] <thumper> davecheney: found it in the spec
[03:43] <thumper> quite a handy doc that
[03:43] <thumper> I'm liking how fast go compiles
[03:43] <davecheney> yeah, that is nice
[03:46] <thumper> davecheney: am I right in thinking that len(nil) == 0?
[03:47] <davecheney> thumper: depends on the type of nil
[03:48] <davecheney> that is capital T type
[03:48] <davecheney> i'm not really sure
[03:48] <davecheney> len of a nil slice or map is 0
[03:48] <thumper> ok, it is for a nil slice
[03:49] <davecheney> in that case, yes, it len of a nil slice of map is 0
[03:49] <davecheney> the of map is new in 1.1
[03:49] <davecheney> no, sorry
[03:49] <davecheney> it in 1.0
[03:49] <davecheney> there is another simplification for map in 1.1
[04:02] <thumper> davecheney: I have another branch, this one changes the way aliases for supercommands are handed
[04:02] <thumper> handled
[04:02] <davecheney> nice
[04:03] <thumper> just running all the tests now prior to proposing
[04:03] <davecheney> propose!!
[04:03] <davecheney> screw that, proposing takes minutes
[04:03] <thumper> now we get aliases shown in the generated help
[04:03] <davecheney> tests will be done by then
[04:03] <thumper> :)
[04:03] <thumper> it takes about 90s to run all the tests here
[04:03] <thumper> actually, I should time it again
[04:04] <thumper> I found myself after lunch futsing around too much with the aliases in the supercommand
[04:04] <davecheney> the work stealing algo for running multiple tests packages could be better
[04:04] <thumper> in order to provide the right help
[04:04] <thumper> ended up reverting it all
[04:04] <davecheney> but butter still would not be taking 90 seconds for a test
[04:04] <thumper> then changing the way it was done in a different branch
[04:05] <thumper> if you ask for help on an alias, now it will give you help on the actual command and say at the bottom it lists all the aliases
[04:06] <thumper> hmm lbox died on a launchpad api error
[04:08] <davecheney> yeah, it does that
[04:08] <davecheney> just do it again
[04:08] <davecheney> i've learnt to keep my commit messages
[04:08] <davecheney> in a text file
[04:12] <thumper> lbox is proposing...
[04:13] <thumper> https://code.launchpad.net/~thumper/juju-core/command-aliases/+merge/149461
[04:13] <thumper> so... I'm on dinner tonight
[04:13]  * thumper thinks
[04:13] <thumper> I think we decided to go out for my daughter's birthday
[04:13] <thumper> that makes it easy
[04:14] <thumper> https://codereview.appspot.com/7370043
[04:17] <davecheney> have a good one
[04:29] <thumper> I will
[04:29] <thumper> it is at my favourite resturant here
[04:29] <thumper> soooo... good
[04:31] <davecheney> how fortuitus
[08:20] <rogpeppe> morning all
[08:20] <rogpeppe> evening davecheney :-)
[08:20] <dimitern> rogpeppe: morning
[08:24] <davecheney> evening all
[08:24] <dimitern> davecheney: hiya
[08:26] <davecheney> rogpeppe: do you think we have the same set of issues that we had with bootstrapping precise from quantal
[08:26] <davecheney> that we do for ppl wanting to do 386 -> amd64, and all the other permutations
[08:26] <rogpeppe> davecheney: in this case, we just want to use 386 all down the line
[08:27] <rogpeppe> davecheney: so i don't think the same problems arise
[08:27] <rogpeppe> davecheney: although there may well be things i don't know about
[08:28] <davecheney> rogpeppe: i think there are wrinkles
[08:28] <davecheney> for example
[08:28] <davecheney> _most_ ec2 instances are amd64
[08:28] <davecheney> except for standard (?) and micro
[08:29] <davecheney> so i think it is more compliated than saying 'i want this environment to have amd64 quantal machines'
[08:29] <fwereade> davecheney, rogpeppe: this question is uppermost in my mind
[08:29] <fwereade> davecheney, rogpeppe: and I *think* it's ok
[08:29] <davecheney> fwereade: my initial response is to say 'juju only makes amd64 machines'
[08:29] <davecheney> and ignore the arch on the host machine
[08:30] <fwereade> davecheney, certainly we must ignore the arch on the host
[08:30] <davecheney> so bootstraping from anything, osx runing on arm produces amd64 machines
[08:30] <davecheney> fwereade: then that might solve rogpeppe 's question
[08:30] <fwereade> davecheney, I think that the tighest constraint we have is what arches we have the tools built for
[08:30] <davecheney> fwereade: i'd be relieved to say, for the future that we can predict, amd64 is all we do
[08:30] <rogpeppe> davecheney: what about --upload-tools ?
[08:31] <davecheney> rogpeppe: fuk
[08:31] <davecheney> double shit
[08:31] <rogpeppe> davecheney: that's my motivating case at the moment
[08:31] <rogpeppe> fwereade: mornin' BTW. hope you're feeling a little better.
[08:31] <fwereade> davecheney, I don't think there's a compelling reason to drop i386 support on ec2
[08:32] <fwereade> rogpeppe, heyhey, pretty crappy tbh, I will be off and on
[08:32] <davecheney> fwereade: apart from it being a wrinkle we don't need
[08:32] <rogpeppe> davecheney: i'm not sure i see the problem.
[08:32] <rogpeppe> davecheney: currently the logic chooses the image based on the arch and series of the tools found.
[08:32] <davecheney> rogpeppe: it's just more perumutations that we don't need righ tnow
[08:33] <rogpeppe> davecheney: i *think* all we need to do is provide a mongo db binary and it'll just work
[08:33] <davecheney> rogpeppe: i don't think we need to do that
[08:33] <davecheney> we should always request an amd64 image
[08:33] <davecheney> if it happens that the development tools are 386
[08:34] <rogpeppe> davecheney: not if the caller wants to upload tools
[08:34] <davecheney> that isn't a problem on linux
[08:34] <rogpeppe> davecheney: and have them run on the bootstrap machine
[08:34] <davecheney> yeah, that works fine
[08:34] <davecheney> just clamp the AMI request to amd64, job done
[08:35] <rogpeppe> davecheney: ah, because you can always run 386 binaries ok
[08:35]  * dimitern rebooting
[08:35] <davecheney> yeah
[08:35] <davecheney> going the other way, amd64 tools on a t1.micro will be sadface
[08:35] <davecheney> but that is a bridge to cross at another time
[08:35] <fwereade> davecheney, is that any worse than *anything* on a t1.micro? ;p
[08:36] <davecheney> exactly
[08:36] <davecheney> it's not the way the market is heading
[08:36] <rogpeppe> davecheney: i'm not really sure i see the motivation though. we're going to need different mongo binaries sooner or later. why not just upload 'em now and avoid the special-case hacks in the code?
[08:36] <davecheney> rogpeppe: --upload-tools is the hack
[08:36] <davecheney> i'm fine with hackig it some more
[08:36] <davecheney> rogpeppe: is there an issue for this work ?
[08:37] <rogpeppe> davecheney: yeah, wait a mo
[08:37] <rogpeppe> davecheney: https://bugs.launchpad.net/juju-core/+bug/1130209
[08:37] <_mup_> Bug #1130209: we need a mongodb compiled for i386 <juju-core:New> < https://launchpad.net/bugs/1130209 >
[08:38] <rogpeppe> davecheney: but that's fairly specific - i assumed it was the right solution
[08:38] <davecheney> rogpeppe: mind if I rename that issue to what I see is the problem ?
[08:39] <rogpeppe> davecheney: ok
[08:39] <rogpeppe> davecheney: which is?
[08:41] <davecheney> "juju should always request an amd64 AMI image"
[08:41] <davecheney> actually, that will probably mean we can't boot t1.micros
[08:41] <davecheney> but whatever
[08:42] <fwereade> davecheney, I *think* that we can start any ec2 instance with AMD64
[08:42] <fwereade> davecheney, but I'm not quite convinced this is an ok shortcut
[08:43] <davecheney> fwereade: why not ?
[08:43] <fwereade> davecheney, haven't people already used juju on ARM machines? even if they don't run the state server?
[08:43] <rogpeppe> fwereade: i've made some replies to https://codereview.appspot.com/7326052/
[08:44] <davecheney> fwereade: only as a client
[08:44] <davecheney> my view of the crystal ball shows only environments containing amd64 machines
[08:44] <davecheney> when highbank or calexeda come asking, we fix the problem then
[08:44] <fwereade> davecheney, what about the arm stuff that had to be added to python juju for maas?
[08:45] <rogpeppe> fwereade: i'm not sure what to do. i really don't have time to fix all the bugs currently - i can abandon the CL and just leave as an example for the GUI folks if you'd prefer.
[08:45] <davecheney> fwereade: in the spirit of delivering 13.04, we have to leave the goal posts in the ground
[08:45] <fwereade> davecheney, I do not believe I am the person trying to move them...
[08:45] <rogpeppe> davecheney: what *is* the problem with just uploading 386 mongo binaries, BTW?
[08:46] <davecheney> rogpeppe: well, 1, we don't have those binaries, so that is work
[08:46] <rogpeppe> davecheney: i pointed you at some
[08:46] <davecheney> 2, getting the deps in the archive is going to be an amazing ballache, so i'd rather no x2 it
[08:46] <rogpeppe> davecheney: i don't understand - which deps in which archive?
[08:47] <davecheney> rogpeppe: with respect, I have proposed a solution that has a low cost now, and a known cost in the future
[08:47] <davecheney> we don't have to gold plate this
[08:47] <davecheney> we just have to make it work on jam's dev machine, right ?
[08:47] <rogpeppe> davecheney: if i'd had the credentials, i could have fixed this with a single s3 upload last night
[08:48] <davecheney> rogpeppe: how can I send them too you ?
[08:48] <davecheney> i'm more than happy for someone else to fix this
[08:48] <rogpeppe> davecheney: i have the ones you gave me before, but they don't seem to work any more
[08:49] <davecheney> yeah, niemeyer reset them a few times trying to get the permission junk working
[08:49] <rogpeppe> davecheney: ah
[08:49] <davecheney> rogpeppe: email me your public key
[08:49] <davecheney> i'll bootstrap a machine
[08:49] <davecheney> and leave them there for you
[08:51] <fwereade> rogpeppe, the issue with that CL is that moving code from one wrong place to a different wrong place is of limited utility... is there some other command that is a bit more robust and doesn't need to be reimplemented inside state?
[08:51] <rogpeppe> fwereade: well, surely the *place* is right - it's just the code is wrong?
[08:52] <fwereade> rogpeppe, the code cannot be correct while it's in that place, though, can it?
[08:52] <rogpeppe> fwereade: the code cannot be correct in any place!
[08:53] <rogpeppe> fwereade: 'cos it's buggy
[08:53] <fwereade> rogpeppe, yeah, but the bugs are intractable while it's outside the state package
[08:53] <rogpeppe> fwereade: do you think we should just delete set and get support because they're currently wrong?
[08:54] <fwereade> rogpeppe, I think that picking something that's wrong as a demonstration of how to do something right is problematic
[08:54] <rogpeppe> fwereade: i agree that stuff needs to move into the state package, but i don't think i want to say to the gui folks - "yes you can make access to the command functionality through the API but you have to fix all our current bugs as you do so"
[08:58] <fwereade> rogpeppe, ok, but... what will statecmd be, then, if not just a holding area for buggy code, soon to be replaced by better state API calls?
[08:59] <fwereade> rogpeppe, this feels like inserting an extra step... you don't have to fix the bugs, but I don't see what the benefit is of adding another layer
[09:00] <rogpeppe> fwereade: the benefit of the extra layer is at least we're not duplicating the buggy code
[09:00] <rogpeppe> fwereade: because it needs to be called from two places now
[09:01] <fwereade> rogpeppe, er, what? why would we be duplicating it if we put it in one place, ie in state?
[09:01] <fwereade> rogpeppe, both those places use the state API though, right?
[09:03] <rogpeppe> fwereade: the idea is that the functions in statecmd are *directly* equivalent to the command line commands, with all the parameter checking that implies.
[09:03] <rogpeppe> fwereade: i thought about putting them in state too
[09:04] <rogpeppe> fwereade: it depends whether we feel that almost all the code in juju/cmd should actually be done in state.
[09:04] <rogpeppe> cmd/juju
[09:06] <fwereade> rogpeppe, well that case obviously has to be; and offhand I can't think of one that shouldn't, can you?
[09:07] <rogpeppe> fwereade: so what should i say to the GUI folks? hold off while we refactor cmd/juju ?
[09:08] <fwereade> rogpeppe, I would say "put it in state, like this"... maybe I'm not understanding some of the constraints?
[09:09] <fwereade> rogpeppe, blast, sorry, need a quick break, can we pick this up a bit later?
[09:09] <rogpeppe> fwereade: ok
[09:40] <fwereade> rogpeppe, hey, sorry to abandon you; I think I might be returning to bed for a while again soon, but we should finish this
[09:40] <rogpeppe> fwereade: shall we G+?
[09:40] <fwereade> rogpeppe, sgtm, will you start?
[09:40] <rogpeppe> fwereade: ok
[09:43] <rogpeppe> fwereade: ha, i've made a hangout, but the window has disappeared
[09:43]  * fwereade tries
[11:00] <fwereade> jam, ping: https://codereview.appspot.com/7307128/patch/1/6
[11:01] <fwereade> jam, for your first comment, I thought it was covered by "// Environ constraints are not available before initialization." just above?
[11:01] <fwereade> jam, and for the second: yes to the first bit, clarify please to the seconds
[11:02] <fwereade> jam, I'm still pretty flaky today so am appearing and disappearing at random, just answer whenever and I'll see it when I see it
[11:32] <dimitern> jam, mgz: standp
[12:14] <rogpeppe> fwereade: i already have two LGTMs on this, but i'd really like your input too, as you've been following this stuff: https://codereview.appspot.com/7314116/
[12:29] <fwereade> rogpeppe, am I right in thinking there's no api.IsNotFound?
[12:32] <fwereade> rogpeppe, also, who should I be talking to to figure out the deal with yaml-in-the-gui?
[12:33] <fwereade> rogpeppe, because I'm still pretty strongly -1 on the two-parallel-paths-not-checked-on-the server bit
[12:49] <fwereade> dimitern, rogpeppe, TheMue: would one of you do a quick review on https://codereview.appspot.com/7331053/ please? it's near-as-dammit trivial and already has one LGTM
[12:50] <rogpeppe> fwereade: hmm, sorry missed your remarks above
[12:50] <rogpeppe> fwereade: from the top:
[12:51] <rogpeppe> fwereade: yes, there's no api.IsNotFound - it's spelt api.ErrCode() == api.CodeNotFound instead
[12:52] <fwereade> rogpeppe, how about something more like api.ErrHasCode(err, api.CodeNotFound), perhaps?
[12:53] <fwereade> rogpeppe, just bikeshedding really, but I thought that IsNotFound was pretty handy
[12:53] <rogpeppe> fwereade: in #juju-gui, bac or gary_poster are two possibilities
[12:53] <fwereade> rogpeppe, cool, ty
[12:53] <rogpeppe> fwereade: in ec2, i started with HasCode, but it turns out it's nicer to have a function that returns the error code.
[12:54] <fwereade> rogpeppe, ok, fair enough on that, not sure I really like my suggestion
[12:54] <rogpeppe> fwereade: for one thing, in tests, c.Assert(api.ErrCode(err), Equals, api.CodeNotFound) gives a nicer error message on failure
[12:54] <rogpeppe> fwereade: also, you can do switch code := api.ErrCode(err); code {
[12:55] <fwereade> rogpeppe, ok, sgtm, thanks :)
[12:55] <rogpeppe> fwereade: np
[12:55] <rogpeppe> fwereade: FWIW i don't think the two parallel paths thing is really a problem - i just documented that Config overrides Options.
[12:56] <rogpeppe> fwereade: but there's an issue around that that i was discussing with niemeyer yesterday (in your absence)
[12:56] <rogpeppe> fwereade: which is that yaml is strictly more expressive than the options in this context, because yaml can express null, but options cannot, only an empty string.
[12:57] <fwereade> rogpeppe, feels like unnecessary nastiness with no real benefit to me... if we *have* to have the yaml path I think it's better to convert to yaml at the CLI end than to overload the params
[12:57] <fwereade> rogpeppe, isn't an empty string "fall back to the default" in this context?
[12:57] <rogpeppe> fwereade: if only js had decent yaml support... (if only yaml wasn't insane...)
[12:57] <fwereade> rogpeppe, ha, yeah
[12:58] <rogpeppe> fwereade: yes, but it could also be "set this to the empty string"
[12:58] <rogpeppe> fwereade: and in yaml you can express that difference
[12:58] <rogpeppe> fwereade: my inclination is to always make an empty string equivalent to null
[12:58] <rogpeppe> fwereade: then the two paths are equivalent
[12:59] <fwereade> rogpeppe, yeah, I think we kinda decided that a while ago, but that might just be in informal inference I made
[12:59] <rogpeppe> fwereade: FWIW niemeyer thought that it was reasonable to have yaml be more expressive.
[13:00] <TheMue> fwereade: You've got a +1.
[13:00] <rogpeppe> fwereade: BTW if it wasn't for the js stuff, i would have no hesitation at all about dropping the yaml path
[13:00] <TheMue> fwereade: And thx for your review, the change is proposed again.
[13:00] <fwereade> rogpeppe, in that case I think we should drop Options -- it is more important to me that we drop one of them rather than it sepcifically be the yaml
[13:00] <fwereade> TheMue, tyvm, I'll take a look in a bit
[13:05] <rogpeppe> fwereade: i just had a little chat in #juju-gui - here's the result: http://paste.ubuntu.com/1690301/
[13:07] <rogpeppe> fwereade: the thing is that if we drop Options, then, when they're not doing file upload, the gui will have to create well-formed yaml from the given options. perhaps that's not a problem, but i don't have an issue with there being two ways to specify the same thing, as long as the interaction between the two is well defined.
[13:08] <rogpeppe> fwereade: alternatively, we could have two entry points: ServiceSet and ServiceSetYAML
[13:08] <rogpeppe> fwereade: under the surface they'd invoke the same thing
[13:09] <fwereade> rogpeppe, I think I'd rather separate them like that if nothing else
[13:09] <rogpeppe> fwereade: ok, although i still don't really understand the problem
[13:10] <fwereade> rogpeppe, or... they could just JSON it in the GUI, and that's still valid YAML, right?
[13:10] <fwereade> rogpeppe, so long as we handle ""/null consistently
[13:10] <rogpeppe> fwereade: true. i suppose my ickiness head goes "json-in-json-string, yeuch"
[13:11] <fwereade> rogpeppe, I think that with the YAML requirement we're already way over that line
[13:12] <rogpeppe> fwereade: that's only required if you want to upload yaml. i'd prefer not to pollute the clean path because of that requirement
[13:14] <fwereade> rogpeppe, can you live with two separate calls?
[13:16] <fwereade> rogpeppe, that seems to me like the least polluting approach possible ;)
[13:17] <rogpeppe> fwereade: yeah, i'll do two separate calls.
[13:25] <fwereade> rogpeppe, cool, tyvm
[13:26] <fwereade> TheMue, I'm wondering about the 301s on paths with ..
[13:26] <fwereade> TheMue, surely if anything's a 403, it's attempts to read/write outside the path?
[13:27] <fwereade> TheMue, and a prefix of "../" acting the same as no prefix is a bit weird as well I think
[13:27] <fwereade> TheMue, when listing I mean
[13:29] <TheMue> fwereade: I've wondered too and it took me some time to discover it.
[13:29] <TheMue> fwereade: It's a feature of the http daemon of Go.
[13:29] <TheMue> fwereade: It resolves relative paths and sends a redirect to the client.
[13:30] <TheMue> fwereade: And I also wondered about why using it with a pattern doesn't lead to a 301. Strange.
[13:32] <fwereade> TheMue, hmm, where does it redirect to?
[13:33] <TheMue> fwereade: I have to check now that the URL doesn't contain the environ name anymore.
[13:34] <TheMue> fwereade: Before it has been from /environname/../foo to /foo
[13:34] <TheMue> fwereade: But only a redirect, I client has to interpret it itself.
[13:35] <fwereade> TheMue, hmm, would you look into that please? it should not have been doing that, that gets access to the files in the foo environment
[13:36] <TheMue> fwereade: Now as it is change (w/o the environment as part of the URL) this can't happen. But the access when knowing a path or the port has already been open before.
[13:36] <TheMue> fwereade: Right now we don't do any authentication on the storage.
[13:36] <fwereade> TheMue, so where does localhost:60006/../foo redirect to?
[13:38] <TheMue> fwereade: I have to look. But as I said: the redirect is no access. It's only a transformation of the URL (w/o validation if a path exists) and sending it to a possible client).
[13:38] <TheMue> fwereade: If that does then react on it and does a request and the file doesn't exists it gets a 404.
[13:39] <fwereade> TheMue, fwiw I think you'll find the cli will probably be losing direct environ access in the near future, so the security point may be moot
[13:39] <TheMue> fwereade: But give me some minutes, now I'm interested in that redirect too.
[13:39] <fwereade> TheMue, but nonetheless I would rather have a PUT to ../wherever/blah *fail* rather than just put *somewhere* ;)
[13:39] <fwereade> TheMue, thanks
[13:40] <TheMue> fwereade: Sorry, the Go server works differently. I have to look if it provides a kind of hook to get involved in the resolving.
[13:41] <TheMue> fwereade: And security has nothing to do with the generated redirect, here we should introduce a real authentication feature.
[13:41] <TheMue> fwereade: At least basic auth.
[13:43] <fwereade> TheMue, what scenarios are we protecting against here?
[13:44] <TheMue> fwereade: One moment, testing.
[13:45] <fwereade> TheMue, I guess multiple users running local jujus on the same machine... but even then, each of them must be able to become root in order to start an env, right?
[13:46] <fwereade> TheMue, but then people who can't start an env could still look inside and/or write to it, so, I guess, yeah: we should have some auth
[13:46] <TheMue> fwereade: GET /../* is directly delivered (no redirect, as I said) as /*
[13:47] <fwereade> TheMue, ok, that's fair enough I suppose; but GET /../foo redirects?
[13:48] <TheMue> fwereade: Yeah, the storage backend is totally open right now, so beside using our own tool any wget/curl/scripting can simply access it in any way. And that's not good in the long run.
[13:49] <fwereade> TheMue, it *is* a dev tool, not a production system... and, hold on, can we not restrict it to connections from localhost?
[13:49] <TheMue> fwereade: /../foo* to /foo*
[13:50] <fwereade> TheMue, so that one's a redirect?
[13:50] <TheMue> fwereade: But as said, it is NO redirect. The redirect is in PUT (funnily) and has also been when we used the environ name in the path.
[13:51] <fwereade> TheMue, ok, sorry: GET never redirects, but PUT and DELETE do?
[13:51] <TheMue> fwereade: Restriction by IP should be possible, but not localhost, but the IP of the LXC containers.
[13:52] <fwereade> TheMue, it's not clear that we ever want something in a container to use it as a Storage
[13:52] <TheMue> fwereade: Hehe, ok, step by step.
[13:52] <mgz> right, I was wondering about access control on the local provider storage too
[13:52] <rogpeppe> fwereade: any chance of a review of https://codereview.appspot.com/7314116/ ? (it sounded like you were looking at it earlier - perhaps you just didn't publish your comments?)
[13:52] <fwereade> TheMue, when should a container be able to get a Storage to work with?
[13:53] <TheMue> fwereade, mgz: Please seperate those discussions, first redirect, later security.
[13:53] <TheMue> fwereade: Once again, step by step.
[13:53] <mgz> TheMue: I'll try to leave comments on the review
[13:53] <rogpeppe> mgz: eventually, we could probably use admin-secret for security, if we cared much.
[13:54] <mgz> rogpeppe: it's probably less security and more accidental clashing you care about for local
[13:55] <TheMue> fwereade: First approach has been to use a URL like host:1234/<<environ>>/<<name>>.
[13:55] <TheMue> fwereade: In that case a ".." leads to a redirect.
[13:55] <rogpeppe> mgz: i don't think accidental clashing is a problem necessarily - we can store the address of the storage in the environ's directory.
[13:55] <TheMue> fwereade: Now we use host:1234/<<name>>.
[13:56] <TheMue> fwereade: Here /../<<name>> doesn't lead to a redirect, but the ".."  :D
[13:57] <fwereade> TheMue, ...and *that* redirects to..?
[13:57] <fwereade> TheMue, /<<name>> ?
[14:00] <TheRealMue> fwereade: But again, it doesn't deliver ata, it does no existence check, nothing.
[14:02] <fwereade> TheRealMue, sure, that wasn't really on my mind -- I just wanted to know *what* it was doing :) maybe it would be good to document the details of what's going on under the hood, in the tests?
[14:02] <TheRealMue> fwereade: Yeah, PUT /../foo redirects to /foo.
[14:02] <TheRealMue> fwereade: I'll document it, yip.
[14:02] <fwereade> TheRealMue, tyvm
[14:03] <TheRealMue> fwereade: It's simply a "if contains("..") { transformAndRedirect(url) }. ;)
[14:08]  * rogpeppe goes to lunch
[14:24] <niemeyer> Yo
[14:31] <dimitern> niemeyer: hey
[14:39] <fwereade> niemeyer, heyhey
[14:57] <fwereade> rogpeppe, mramm, TheMue: kanban?
[14:57] <rogpeppe> fwereade: in 2 mins, no?
[14:57] <TheMue> fwereade: Yep, in 2 mins.
[14:58] <fwereade> rogpeppe, what's the deal with 208-simplify-config-tests? did that go anywhere, or was another variant chosen, or what?
[14:58] <rogpeppe> fwereade: ah, i was reminded of that this morning. i haven't yet addressed jtv's final comment on that CL
[15:17] <bac> rogpeppe: there are naming differences between what you landed as your first branch and the second branch that is under review, e.g. ServiceSetParams vs. SetConfigParams.  which is the one you'll be using?
[15:30] <fwereade> rogpeppe, I would favour longer but more painfully explicit names, if possible
[15:31] <fwereade> rogpeppe, sorry, my comments on the second don't apply so well in the light of the decusuins re the first
[15:31] <rogpeppe> fwereade: i thought ServiceSet was ok
[15:31] <rogpeppe> fwereade: (given that we've got "juju set")
[15:31] <rogpeppe> fwereade: but you'd prefer ServiceSetConfigParams?
[15:32] <fwereade> rogpeppe, ah, hmm, I think consistency there is actually quite good
[15:32] <rogpeppe> fwereade: well, sure, but i'd have ServiceSetConfig to match
[15:32] <rogpeppe> fwereade: i just thought that was on the verge of unnecessarily verbose
[15:33] <fwereade> rogpeppe, yeah, indeed, I am newly taken with the benefits of ServiceSetParams/EnvironSetParams(?)
[15:33] <rogpeppe> fwereade: great, thanks
[15:33] <rogpeppe> bac: i changed the names as suggested in the review
[15:34] <rogpeppe> bac: the second branch will change to match - i still need to do some work on it as per discussions before landing it
[15:35] <bac> rogpeppe: ok, so the names in the landed branch are preferred.  thanks.
[15:39]  * TheMue has a late lunch today, biab
[15:48] <fwereade> rogpeppe, btw, is there a bug in LP for that `juju-log "--lol screw you"` issue?
[15:48] <rogpeppe> fwereade: no, gimme 30s
[15:49] <fwereade> rogpeppe, would you assign it to tim please, and suggest the SetFlags tweak we discussed?
[15:49] <rogpeppe> fwereade: k
[15:56] <rogpeppe> fwereade: hmm, do you know where the implementation of the jujuc commands is in the python?
[15:57] <rogpeppe> fwereade: oh, found it
[15:57] <fwereade> rogpeppe, sorry I missed you
[15:58] <rogpeppe> fwereade: i can't see how the "we don't interpret flags" thing is consistent with the fact that there's a -l flag to juju-log
[15:58] <rogpeppe> fwereade: i can't see how that works in the python
[15:59] <rogpeppe> fwereade: (i'm looking in juju/hooks/commands.py, BTW)
[15:59] <fwereade> rogpeppe, I would guess that the parser just ignores the stuff it doesn't recognise and passes it on in the args
[15:59] <fwereade> rogpeppe, what does it use: optparse?
[16:00] <rogpeppe> fwereade: argparse
[16:01] <fwereade> rogpeppe, yeah, I think that has parse_known_args?
[16:02] <rogpeppe> fwereade: it doesn't use that method
[16:02] <rogpeppe> fwereade: it just uses parse_args
[16:03]  * rogpeppe manages to see through *some* of the python magic
[16:03] <fwereade> rogpeppe, ah, wait, it gets a bunch of stuff from juju/hooks/cli.py as well I think
[16:04] <rogpeppe> fwereade: yeah, that's the place that calls parse_args
[16:04] <rogpeppe> fwereade: in the __call__ magic method
[16:04] <mramm> anybody have a link to tim's gap analysis doc?  I can't seem to find it in my google drive.
[16:05] <rogpeppe> fwereade: hmm, i think this might be magic too:         self.parser.add_argument("message", nargs="+")
[16:05] <rogpeppe> fwereade: perhaps that "+" signifies "anything remaining"
[16:05] <fwereade> rogpeppe, very probably
[16:06] <rogpeppe> fwereade: so "juju-log -l INFO foo" will send a "foo" message at info level, but "juju-log -z foo" will log "-z foo" at normal level
[16:06] <rogpeppe> fwereade: if that's true, it's really not very nice and breaks all our arg parsing rules.
[16:12] <fwereade> rogpeppe, sorry, my dad just arrived from england, was saying hello
[16:12] <rogpeppe> fwereade: np
[16:12] <fwereade> rogpeppe, I agree that that is not very nice
[16:12] <rogpeppe> fwereade: am just trying to understand argparse
[16:12] <rogpeppe> fwereade: "+" just says any remaining args - it still seems to give an error when a flag isn't recognised
[16:13] <fwereade> rogpeppe, hmm, maybe it has special handling for "--" followed by "something weird"
[16:13] <rogpeppe> fwereade: maybe - i'll try that next
[16:15] <rogpeppe> fwereade: yup, that's right. yulk
[16:16] <rogpeppe> fwereade: here's my testbed: http://paste.ubuntu.com/1691047/
[16:16] <rogpeppe> fwereade: sample: http://paste.ubuntu.com/1691052/
[16:17] <rogpeppe> fwereade: looks like if you've got a space in the arg it's treated as if it can't be a flag
[16:17] <fwereade> rogpeppe, ok, I guess that makes sense, but still, eww :)
[16:18] <rogpeppe> fwereade: no, that's not true either
[16:18] <rogpeppe> fwereade: if there's a space in the arg, it's treated as a flag *only* if the prefix doesn't match a flag
[16:19] <fwereade> rogpeppe, wait what? I don;t think that fits with what you showed me
[16:19] <fwereade> rogpeppe, treated as an arg?
[16:19] <rogpeppe> fwereade: so "tst.py '-z arg'" goes through ok but "tst.py -z ' arg' fails
[16:20] <rogpeppe> fwereade: which seems so so wrong to me
[16:20] <fwereade> rogpeppe, I dunno, it actually seems pretty sane... but it's annoying to have to replicate all the magic
[16:21] <fwereade> rogpeppe, it's not *nice* but it is making an effort to do the Right Thing even in the face of crazy args like "--> roflcopter"
[16:21] <rogpeppe> fwereade: it seems wrong to me because in general i'd think that -z$arg and -z "$arg" should be handled exactly the same
[16:21] <fwereade> rogpeppe, yeah, reasonable perspective
[16:21] <rogpeppe> fwereade: what if the create arg as "-lINFO" ?
[16:21] <rogpeppe> s/create/crazy/ s/as/was/
[16:22] <fwereade> rogpeppe, well it *is* meaningless anyway because we dropped all the logging levels :/
[16:22] <rogpeppe> fwereade: ha
[16:22] <fwereade> rogpeppe, gtg for a bit, back later
[16:22] <rogpeppe> fwereade: ok
[16:48] <rogpeppe> fwereade: https://bugs.launchpad.net/juju-core/+bug/1130771
[16:48] <_mup_> Bug #1130771: juju-log is not compatible with python version <juju-core:New> < https://launchpad.net/bugs/1130771 >
[17:10] <fwereade> rogpeppe, responded
[17:11] <TheMue> niemeyer: Your ubuntufinder.com is quite cool.
[17:11] <rogpeppe> fwereade: i wonder if the argparse semantics are actually documented anywhere
[17:14] <dimitern> niemeyer: yeah, pretty cool UI with these rolling radio buttons / shelves :)
[17:17] <rogpeppe> fwereade: i had a go at fixing that live test failure yesterday, and got some way, but it still fails. does this look reasonable to you? http://paste.ubuntu.com/1691273/
[17:18] <fwereade> rogpeppe, hmm, that looks like it ought to work
[17:18] <rogpeppe> fwereade: unfortunately the provisioner never actually shuts down the instance. i'm wondering if i should remove the machine too.
[17:19] <fwereade> rogpeppe, no, that's the provisioner's job... does it really not do it? I could have sworn it did
[17:19] <rogpeppe> fwereade: yeah, i thought so too
[17:19] <fwereade> rogpeppe, if not then, well, this is why it was bad to invent our own shutdown process in those tests ;p
[17:19] <rogpeppe> fwereade: BTW, i *think* that Machine.Destroy should not require a Refresh if the last view of the machine had assigned units.
[17:20] <rogpeppe> fwereade: agreed
[17:20] <fwereade> rogpeppe, we should try regardless of the latest known state? not convinced, but go on
[17:21] <rogpeppe> fwereade: yeah, because it's what's actually out there in the state that's important AFAICS
[17:21] <rogpeppe> fwereade: in the above loop, there's no real reason we need to keep on refreshing while trying Destroy periodically
[17:22] <fwereade> rogpeppe, I would think it more usual to watch, refresh on change, and then use that -- recent -- state as a basis for making further decisions on what to do
[17:22] <rogpeppe> fwereade: in this case, there's nothing to watch
[17:23] <rogpeppe> fwereade: or... maybe there is
[17:23] <rogpeppe> fwereade: well, anyway, the in-memory state has no bearing on whether we can or can't call Destroy
[17:23] <fwereade> rogpeppe, a machine watch will observe those changes
[17:23] <rogpeppe> fwereade: yeah
[17:25] <fwereade> rogpeppe, it has plenty of bearing -- once we've figured out whether it's a sane request, we decide whether or not to even call anything, all based on in-memory state
[17:25] <rogpeppe> fwereade: why should we? the in-memory state doesn't tell us anything about whether the machine has units *now*, no?
[17:26] <mgz> bah, why did I type images, I meant instance-types
[17:26] <mgz> terminology is hard
[17:26] <rogpeppe> fwereade: hmm, except, i guess, when there are *no* units and the machine is dying
[17:26] <fwereade> rogpeppe, no, but if you're interested we'll tell you when it changes... why accommodate impatient hammering of the API
[17:27] <rogpeppe> fwereade: i'm not sure why {wait for change; refresh; destroy} is better than {wait for change; destroy}
[17:27] <rogpeppe> fwereade: it certainly surprised me when i discovered it was necessary.
[17:28] <fwereade> rogpeppe, because if you didn't refresh then you obviously have no basis for assuming it's destroyable ;p
[17:28] <rogpeppe> fwereade: i know it changed :-)
[17:28] <rogpeppe> fwereade: the overhead of calling destroy is probably not far off that of calling refresh. or... maybe it is actually much cheaper in fact.
[17:30] <fwereade> rogpeppe, define cheap... destroy will potentially lock the service document, won't it?
[17:30] <rogpeppe> fwereade: yeah, i guess so
[17:31] <fwereade> rogpeppe, ah wait that's only for a unit, doesn't apply
[17:31] <rogpeppe> fwereade: oh yes, not for a machine
[17:31] <fwereade> rogpeppe, I somehow switched to thinking about units
[17:31] <rogpeppe> fwereade: anyway, i think of mutating operations on the state as write-through. i found it strange that one failed only because of in-memory state.
[17:32] <rogpeppe> fwereade: (even though the actual state would have allowed the operation)
[17:32] <fwereade> rogpeppe, I've been thinking of mutating operations on the state as scary, and preferring to avoid them unless I'm as sure as I can be that they'll go through
[17:33] <fwereade> rogpeppe, because it is not easy to determine by inspection just what docs will be involved in a given txn, and how many other txns get clipped by it
[17:34] <rogpeppe> fwereade: it's a pity we can't even set a machine to Dying when it has units - then having no units with a dying machine would be definitive
[17:35] <fwereade> rogpeppe, that's a known bug that we officially do not care enough about to fix by 13.04
[17:36] <fwereade> rogpeppe, if the provisioner's not actually cleaning up the machine, that is an issue of vastly greater magnitude ;)
[17:37] <rogpeppe> fwereade: true 'nuff
[17:48] <frankban> hi all, does the current juju-core trunk support default-series? I have precise in my env configuration, but nodes are created using quantal.
[17:49] <rogpeppe> fwereade: do you know about the above question?
[17:50] <niemeyer> TheMue, dimitern: Cheers!
[17:51] <rogpeppe> fwereade: first watcher in the API implemented: https://codereview.appspot.com/7390043/
[17:51] <fwereade> rogpeppe, heh, you would have been the person I asked
[17:52] <fwereade> frankban, so the charm you're using is definitely a precise one?
[17:52] <rogpeppe> fwereade: darn. i should really know :-)
[17:52] <fwereade> rogpeppe, I am up to my elbos in that stuff at the moment so the behaviour will doubtless change somewhat over the next couple of says
[17:52] <fwereade> rogpeppe, but it does *kinda* look like every machine is started with the series/arch of the machine that launches it :/
[17:53] <rogpeppe> fwereade: it's started with the series/arch of whatever tools it can find, i think
[17:53] <frankban> fwereade: yes, it's the juju gui charm (deployed from local repository). however, the bootstrap node is also quantal
[17:54] <rogpeppe> fwereade: anyway, gotta go. we're packing the car up, off to the Lakes for some snowy hills
[17:54] <fwereade> rogpeppe, enjoy
[17:54] <bac> bye rogpeppe.  you around tomorrow?
[17:54] <rogpeppe> fwereade: will do. have a great rest of week. should be in contact sporadically by email
[17:54] <rogpeppe> bac: no, sorry. away for rest of week.
[17:55] <bac> rogpeppe: have fun!
[17:55] <rogpeppe> bac: will try me best :-
[17:55] <rogpeppe> )
[17:56] <fwereade> frankban, ok, that just sucks profoundly... but, yeah, I don't see how that's meant to actually work
[17:57] <fwereade> frankban, it seems that the machine we start is to all intents and purposes random
[17:57] <fwereade> frankban, good thing I am working on that right now
[17:58] <frankban> fwereade: cool, thanks
[17:59] <rogpeppe> see y'all monday!
[21:22] <bac> hi, i've put a small branch up for review at https://codereview.appspot.com/7401043/
[21:29] <thumper> bac: looks good to me, but I have no confidence in my ability to review it yet
[21:30] <thumper> bac: particularly to know if it works or is even right :)
[21:34] <thumper> Q) an uninitialized string in a struct has a value of "" ?
[21:39] <bac> thumper: yes
[21:39] <thumper> cool...
[21:40] <bac> thumper: thanks for looking.  since it is just code reorg and the previously existing tests still pass that says something (though the tests aren't much)
[21:40] <thumper> hopefully within a week or so I'll feel happier commenting on merge proposals
[21:42] <bac> thumper: is the requirement two reviews?
[21:42] <thumper> yeah
[22:40] <davecheney> thumper: will review your CL in two secs
[22:40] <thumper> sure
[22:46]  * thumper afk for lunch


[02:13] <GrueMaster> rsalveti: Still hanging around?
[02:14] <rsalveti> GrueMaster: yup
[02:18] <GrueMaster> Interesting info on our audio issues.  Quick update:  Dove & panda are new hardware for this cycle, hence new bugs.  Beagle, however, works with lucid, fails with maverick.
[02:18] <rsalveti> GrueMaster: but new kernel for beagle, that could explain
[02:19] <GrueMaster> new everything.  New kernel, new alsa, new pulseaudio...
[02:19] <GrueMaster> Lots of variables.
[02:19] <rsalveti> true
[02:20] <GrueMaster> And I have eliminated the kernel for the most part, as I can run speaker-test just fine.
[02:20] <rsalveti> hm, ok
[02:21] <GrueMaster> Oh, and btw, our own David Henningsson has created an alsamixertest script that should help in figuring out what needs to be in alsa.conf.
[02:22] <GrueMaster> https://launchpad.net/~diwic/+archive/maverick
[02:22] <GrueMaster> I haven't tested it yet, but I have built it for armel.
[02:23] <GrueMaster> Requires a loopback cable (hp<>mic), and all mine are currently tied up.
[02:23] <rsalveti> hm, cool
[02:24] <rsalveti> if you want to test that with panda, I sent you an email with latest deb, that has probably everything we need from the kernel side
[02:24] <GrueMaster> At any rate, it has been a long day of testing.  I'm going to backup this fresh lucid image on my beagle, then kill it with an upgrade.
[02:24] <rsalveti> setting up the card name and everything
[02:24] <GrueMaster> Yea, I saw the email  Also planned on doing that before I call it quits.
[02:25] <rsalveti> cool
[06:27] <rsalveti> berco: can you share with us the file /usr/share/alsa/cards/SDP4430.conf? want to test with latest audio patch series
[06:28] <rsalveti> I'm already getting SDP4430 - SDP4430 from /proc/asound/cards
[07:23] <Xase> ... Can anyone assist me in setting up an ARM toolchain for ubuntu x86
[07:26] <persia> Xase, What are you seeking to accomplish?
[07:26] <rsalveti> Xase: with maverick you just need to isntall the correct packages
[07:26] <Xase> To build the android Kernel for an arm device.
[07:27] <Xase> /bin/sh: arm-eabi-gcc: not found
[07:27] <Xase> I have Maverick.
[07:27] <Xase> What packages?
[07:27] <rsalveti> gcc-4.5-arm-linux-gnueabi for example
[07:27] <Xase> ...
[07:27] <persia> Xase, Which release are you running?
[07:27] <rsalveti> just give apt-cache search arm-linux
[07:27] <Xase> Well that would explain that's why I couldn't find it.
[07:27] <Xase> Lol
[07:27] <rsalveti> you should see the cross packages
[07:27] <Xase> I had no idea that's what apt-cache did.
[07:28] <Xase> Man... I wish there was a "ubuntu-phone" I could be running instead.
[07:28] <Xase> Or if MeeGo was a little more... well going.
[07:28] <Xase> :D
[07:28] <persia> Xase, It's called "Kubuntu-Mobile"
[07:29] <Xase> No effin way >_>
[07:29] <persia> Mostly gets tested on the n900s
[07:29] <Xase> ... I almost bought one of those.
[07:29] <persia> But needs a few hacks, because the n900 kernel isn't open, etc.
[07:29] <persia> Also works for i386 phones (but actually doesn't have the driver for the baseband chip in my x86 phone)
[07:29] <rsalveti> the kernel is open
[07:30] <Xase> ... there are x86 phones?
[07:30] <persia> rsalveti, Not according to the kubuntu-mobile guys 12 hours ago.  Are you sure?
[07:30] <Xase> Now you're just blowing my mind.
[07:30] <persia> Xase, Yes, but this isn't the best channel to discuss them :)
[07:30] <rsalveti> persia: well, afaik yes
[07:30] <Xase> Of course not.
[07:30] <Xase> But now I must google explosively.
[07:30] <rsalveti> you could try upstream + additional patches from the stock kernel
[07:30] <persia> rsalveti, Maybe some closed drivers or something?  I dunno: there's a special procedure.
[07:30] <rsalveti> you can grab the kernel sources from it
[07:31] <rsalveti> generally you should just take care of the battery and watchdog stuff
[07:31] <rsalveti> to avoid random resets
[07:31] <Xase> Hmm
[07:31] <Xase> still reports: /bin/sh: arm-eabi-gcc: not found
[07:31] <persia> rsalveti, You might want to touch base with rbelem and ian_brasil: they'd love to have a less complicated procedure :)
[07:31] <persia> Xase, Which release are you running?
[07:32] <Xase> Maverick.
[07:32] <rsalveti> Xase: after installing the correct packages you should see arm-linux-gnueabi-gcc
[07:32] <rsalveti> persia: sure, I worked with them directly at indt already, will try to ping them later
[07:32] <persia> And if your build file needs arm-eabi-gcc, you'll have to modify the build file.
[07:32] <rsalveti> to understand what's going on :-)
[07:32] <Xase> /bin/sh: arm-eabi-gcc: not found
[07:32] <persia> rsalveti, I thought you'd find them familiar names :)
[07:33] <Xase> ln -s arm-linux-gnueabi-gcc arm-eabi-gcc ?
[07:33]  * rsalveti listening a cool mp3 from temple of the dog at his omap 4 board
[07:33] <rsalveti> with latest patches
[07:33] <Xase> Wouldn't just a symbolic link be fine?
[07:33] <rsalveti> but still manual work on alsa side
[07:33] <rsalveti> Xase: question is, why?
[07:33] <rsalveti> your build script is the wrong guy here
[07:33] <Xase> ... so I don't have to keep modifying stuff.
[07:34] <Xase> I didn't create the build script.
[07:34] <Xase> Blame Google.
[07:34] <rsalveti> well, you can then create a link and mess with your system :-)
[07:34] <rsalveti> but I guess that at least this part is expected from you to change it
[07:34] <rsalveti> it's the cross-compiler
[07:36] <Xase> So you'd instead recommend just modifying the build script?
[07:37] <rsalveti> yup
[07:37] <rsalveti> cooloney: I think I found a possible culprit for the mem issue
[07:38] <rsalveti> cooloney: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=644bab98ce980246e6b945962fec9a733a48c325;hp=adaf930e8ae3eaca5d8eda744dfce96caf71447e
[07:38] <rsalveti> cooloney: at http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-ti-omap4-1gb I added the previous patches and this latest one on top
[07:38] <Xase> Darn that's inexplicably complicated at the moment.
[07:38] <Xase> Lemme find my CTRL+F
[07:38] <rsalveti> cooloney: you can find the deb file at http://people.canonical.com/~rsalveti/maverick/kernel/es2/linux-image-<IP_ADDRESS>+_<IP_ADDRESS>+-87_armel.deb if you want to test it
[07:38] <cooloney> rsalveti: got it, awesome man
[07:39] <rsalveti> I'm running the 5th build atm, no issues
[07:39] <rsalveti> without highmem
[07:39] <rsalveti> if I use highmem I'll always get this problem
[07:39] <cooloney> rsalveti: yeah, let me try it. 2G:2G split right
[07:39] <rsalveti> cooloney: we were missing one errata for pl310
[07:40] <rsalveti> cooloney: then I found that at the upstream l-o we already got a patch that selects the errata by default
[07:40] <rsalveti> just did the same thing
[07:41] <Xase> bah arm-eabi-gcc isn't specified in either Kbuild or Makefile >_>
[07:41] <cooloney> rsalveti: so even we enable this errata for pl310, we still needs 2G:2G split and npitre's patch, right?
[07:41] <cooloney> without highmem
[07:41] <rsalveti> cooloney: yup
[07:41] <cooloney> rsalveti: thanks, got it
[07:41] <rsalveti> cooloney: that could be at least one workaround to use 1gb
[07:41] <rsalveti> while we try to debug the highmem issue
[07:41] <rsalveti> but would prefer to test highmem with upstream
[07:41] <cooloney> rsalveti: yeah, just in time, a workaround to us 1G for our release
[07:42] <rsalveti> but even getting the mmc fix, couldn't get it recognized with upstream kernel
[07:42] <cooloney> rsalveti: yeah, i tried patches in l-o list for mmc of es2.0 board, but the same as you
[07:42] <Xase> arm-linux-gnueabi-menuconfig?
[07:43] <Xase> nm
[07:43] <Xase> I'm reading wrong.
[07:43] <rsalveti> cooloney: description of the errata: http://paste.ubuntu.com/503055/
[07:43] <Xase> so wrong.
[07:43] <Xase> Just do yourself a favor and put me on the ignore list.
[07:44] <rsalveti> cooloney: so it seems this could be our culprit, just need more testing
[07:44] <rsalveti> will let it building during the night and check it tomorrow
[07:44] <rsalveti> but so far so good
[07:45] <rsalveti> 2cpus, with l2, 2g:2g and 1gb support
[07:45] <Xase> BAH
[07:46] <Xase> ...
[07:46] <Xase> Wow.
[07:47] <Xase> I guess this is goodbye guys.
[07:47] <Xase> I just rm'd the arm asm
[07:47] <Xase> from the project file
[07:47] <cooloney> rsalveti: great, man,
[07:48] <cooloney> rsalveti: i will post your patches with npitre's again
[07:48] <Xase> Sweet. Nevermind.
[07:48] <Xase> I need sleep.
[07:49] <rsalveti> cooloney: with highmem I can easily get Unhandled fault: imprecise external abort
[07:49] <Xase> ...
[07:49] <rsalveti> so probably another issue
[07:49] <rsalveti> cooloney: cool, just let do some more testing and then we can post it
[07:49] <Xase> Too tired 2:49 AM... something about supporting nothing but the Calgary with this source >_>
[07:49] <rsalveti> *lets
[07:51] <cooloney> rsalveti: without highmem, it looks like l2 controller pl310 is the root cause. So this errata is necessary.
[07:52] <cooloney> rsalveti: i agree with highmem, it is different from pl310 errata issue.
[07:53] <rsalveti> cooloney: yeah
[07:53] <rsalveti> there's also some more l2x0 patches going upstream: http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk
[07:54] <rsalveti> and sram fixes at http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap_for_2.6.37
[07:54] <cooloney> rsalveti: yeah, i reviewed that before. those l2x patches are for kexec implementation on omap4
[07:55] <cooloney> and it follows Thomas Gleixner's generic one
[07:55] <rsalveti> yep
[07:57] <persia> kexec is awfully nice :)
[07:58] <cooloney> persia: heh, need more testing and backport some patches to enable that.
[07:59] <rsalveti> maybe with 2.6.37 on N :-)
[07:59] <persia> No worries.  I think I need two more cycles before we depend on it :)
[07:59] <Xase> ... gaddangit
[08:00] <Xase> I've messed up my source.
[08:01] <Xase> Gotta read the config a bit more clearly >_>
[08:05] <Xase> Well see, because I couldn't get it to compile I had modified a ton of crap, so now using the plain source... it compiles out of box.
[08:05] <Xase> Thanks #ubuntu-arm
[08:06] <persia> Xase, So it's working for you now?
[08:07] <Xase> Kind of...
[08:07] <Xase> Still getting this "message"
[08:07] <Xase> arch/arm/mach-msm/board-mot.h:125: error: #error Calgary is the only HW supported by this release
[08:07] <Xase> And that's after using the source directly from the Calgary source page.
[08:08] <Xase> I have no clue what it means though so... shrug.
[08:08] <persia> And you're targeting a Calgary device?
[08:08] <Xase> Anyways... anything I can do to help Ubuntu-arm out.
[08:08] <Xase> Yes Persia.
[08:08] <Xase> Also known as the Motorola Devour.
[08:08]  * persia suspects some subtle machine definition in the cross-compiler somewhere.
[08:09] <Xase> Should... I speficy TARGET=Calgary ?
[08:09]  * persia has no information about the source being compiled.
[08:09] <Xase> I'm new to any sort of compiling outside of software...
[08:09] <persia> If that's a sensible option, try it.
[08:09] <Xase> It's the source for the Calgary Device.
[08:10] <persia> Note that you'll probably get better advice about the specific compilation steps from a Calgary-specific resource (wiki, forum, channel, mailing list, etc.).  We mostly focus on running Ubuntu native on ARM.
[08:10] <persia> (with a wink and nod at limited cross-compilation)
[08:11] <Xase> TARGET_PRODUCT=calgary makes sense =/
[08:11] <Xase> Yeah.
[08:11] <Xase> Kind of figured.
[08:11] <Xase> If there was anything for the Calgary.
[08:11] <Xase> It's an end-of-lifed device.
[08:11] <Xase> But I am better off asking in Android perhaps ;)
[08:12] <Xase> Again, is there anything I can do to help test/debug ARM Ubuntu?
[08:21] <persia> Xase, If you happen to have hardware that can run it (e.g. Netwalker, Efika MX, Beagleboard, IGEPv2, Efika SmartBook, etc.) and want to help test and fix bugs, that would be great.
[08:22] <Xase> =( I will try
[08:22] <Xase> I might be able to attain something
[08:22] <persia> If you don't have any of that, but have other ARMv7+VFP capable armel hardware with a working (recent) linux kernel, please try our userspace.
[09:34] <berco> rsalveti: sorry, I didn't see your post earlier
[09:35] <berco> rsalveti: I just attached the file to bug #637947
[09:35] <ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/637947
[09:35] <berco> rsalveti: do you have all you need kernel wise?
[09:53] <NCommander> ogra: you about to help merge? :-)
[10:24] <sveinse> If I want to make a maverick target image, which version of rootstock should I use?
[10:25] <persia> sveinse, theoretically, anything ought work to some degree, but <IP_ADDRESS> would be most likely to have the best support.
[10:26] <sveinse> thanks
[12:54] <dcordes> Hi. Can somebody point to the oo.org build time problem ?
[13:57]  * dcordes drops a pin
[13:58]  * ogra shades his ears from the noise
[14:00] <dcordes> ^^
[14:08] <dcordes> I see a disruption of the force in 09-29 image
[14:09] <dcordes> it won't start oemconfig althoug I have the semephore set
[14:09] <ogra> hmm, has been tested a lot though (since it's the RC candidate)
[14:09] <ogra> what arch ? omap or omap4 ?
[14:21] <dcordes> ogra: I picked the omap4 and applied the few changes as usual
[14:21] <ogra> "the few changes" ?
[14:22] <dcordes> it's not much really
[14:22] <dcordes> I install my kernel modules
[14:22] <dcordes> add few networking scripts
[14:22] <dcordes> and do
[14:22] <dcordes> 'touch /var/lib/oem-config/run'
[14:22] <dcordes> usually after that, I start the rootfs and it will run oemconfig
[14:23] <dcordes> no problems
[14:23] <ogra> yeah, it surely does for us
[14:23] <dcordes> It might be corruption then. I see some error message:
[14:24] <dcordes> Use of uninitialized value $item in hash element at /usr/share/perl5/Debconf/Format/822.pm
[14:25] <ogra> yeah, smells like
[14:25] <dcordes> need to get to the library and download the new image @ 3,3MB/s againm
[15:03] <rsalveti> berco: thanks
[15:04] <rsalveti> berco: got the file from latest proposed tree with tons of sound patches
[15:04] <rsalveti> *kernel
[15:14] <cooloney> rsalveti: i am going to post out our highmem issue workaround patch including your pl310 errata one.
[15:14] <cooloney> rsalveti: do you think we need more test
[15:15] <rsalveti> cooloney: well, just saw that I'm going to the 10th build here
[15:15] <rsalveti> no issues
[15:15] <rsalveti> so it seems better
[15:15] <rsalveti> cooloney: were you able to test?
[15:15] <rsalveti> i just tested using usb, didn't test yet with mmc
[15:16] <rsalveti> but you can propose it, np, it's a fix anyway that we're not using atm
[15:17] <cooloney> rsalveti: yeah, i tested it on my mmc, just 1 build, it passed.
[15:17] <cooloney> rsalveti: ok, let me post it firstly
[15:17] <rsalveti> cool
[15:20] <cooloney> rsalveti: you know, it is quite slow for me to connect with ports.ubuntu.com
[15:20] <cooloney> rsalveti: drive me crazy
[15:20] <cooloney> rsalveti: i will test audio fixing tomorrow.
[15:22] <rsalveti> yeah, can imagine
[15:24] <cooloney> rsalveti: thx for the testing, it seems like that you're never sleep
[15:26] <rsalveti> cooloney: I try to :-)
[15:26] <rsalveti> cooloney: I saw you changed my patch to change just the config file
[15:26] <rsalveti> while it works for us, as we build just one flavor, I decided to change the Kconfig because this was the same change that went upstream
[15:27] <rsalveti> that would fix the issue for all ARCH_OMAP4 boards
[15:28] <rsalveti> but I'm ok with your patch, just to let you know why I changed the Kconfig :-)
[16:07]  * rsalveti lunch
[16:46] <robclark> hmmm...
[16:46]  * robclark somehow manages to murder an mmc card with fdisk..
[16:49] <GrueMaster> btdt.
[16:49] <GrueMaster> I usually end up doing a complete nuke at that point.  dd if=/dev/zero of=/dev/<SD Card>
[16:50] <robclark> no... I no longer even get a device file for the card
[16:53] <GrueMaster> ouch
[16:53] <GrueMaster> May need to reboot.
[16:54] <GrueMaster> Also, I discovered on one of my cards that one of the plastic guides on the side near the contacts had bent covering the contact.  Breaking it off fixed it.
[16:56] <GrueMaster> ogra_ac: For the release notes:  upgrading beagle from lucid->maverick can run of of free space if USB drive is 4G or less.  Haven't tried yet on larger.
[16:56] <ogra_ac> mind to talk to skaet and add it to the wiki `
[16:56] <ogra_ac> ?
[16:57] <GrueMaster> I'll drop a not on #u-release.
[16:57] <GrueMaster> note even.
[17:25] <prpplague> ogra_ac: ping
[17:27] <ogra_ac> prpplague, i'm here
[17:27] <prpplague> ogra_ac: hey, we were discussing possibly using a usb->sata on the bamboo board
[17:27] <prpplague> ogra_ac: any thoughts on that?
[17:28] <ogra_ac> you will be easily maxing out the USB with that i guess
[17:28] <ogra_ac> the babbage imx51 board has such a setup, not really an advantage over a simple external USB disk
[17:29] <prpplague> well the EHCI through put it pretty stable
[17:29] <prpplague> ogra_ac: are they using OHCI or EHCI ?
[17:29] <ogra_ac> ehci
[17:29] <ogra_ac> ~24MB/sec reported by hdparm
[17:29] <prpplague> ahh
[17:31] <ogra_ac> and i doubt you can get much more through USb
[17:32] <ogra_ac> so i guess just attaching SATA to the USB bus wont really gain much over a cheapo external USB disk directly attached to USB
[17:32] <prpplague> yea that is kinda of why i didn't consider it
[17:32] <prpplague> other than size of storage
[17:32] <ogra_ac> i thought there was a way to attach it differently ?
[17:32] <GrueMaster> It would be nice for convenience, but won't enhance performance.
[17:32] <ogra_ac> gpio?
[17:33] <prpplague> ogra_ac: it is possible to do PATA via the GPMC, and then use a PATA->SATA bridge
[17:34] <robclark> prpplague: maybe even PATA is fine.. I think they still sell those
[17:34] <ogra_ac> ah
[17:34] <robclark> ;-)
[17:34] <ogra_ac> GPMC, right
[17:34] <GrueMaster> Hmm.  PATA<>CF would be interesting.
[17:34] <ogra_ac> yeah, even PATA would rock
[17:34] <prpplague> GrueMaster: PATA to CF is pretty easy
[17:35] <prpplague> the only thing that would have to be done is a kernel driver to "work the gpmc" like a PATA interface
[17:35] <GrueMaster> Yes I know.  I have 3 running systems that way.  Fileserver, firewall, and serial-console monitor.
[17:35] <robclark> prpplague: well get crackin!  ;-P
[17:36] <robclark> GPMC->PATA would probably drive two hd's, wouldn't it?  A master and slave..
[17:36] <prpplague> robclark: gotta finish current project first
[17:36] <GrueMaster> Pfft.  Multitask.
[17:36] <GrueMaster> :P
[17:36] <prpplague> robclark: not sure i have enough chipselect signals to do two
[17:37] <robclark> hmm..
[17:40] <robclark> prpplague: I guess I don't need both LED's..  depopulate one, some blue wire, and use that gpio as an extra CS?
[17:41] <prpplague> robclark: negative
[17:41] <prpplague> robclark: the controls need to be tied to the gpmc controller
[17:41] <prpplague> robclark: the gpmc has it's on chipselects and such to control memory read/writes
[17:56] <ogra_ac> ARGH !!!!
[17:56] <ogra_ac> who designed the pandaboard.org page !!!!!
[17:57]  * ogra_ac just linked the logo in a blog post ...
[17:57] <ogra_ac> at least i thought i link the logo
[17:57] <ogra_ac> sigh
[17:57] <ogra_ac> the whole page is a jpeg
[17:57] <GrueMaster> Heh.
[17:57] <ogra_ac> what an insanity !!
[17:59] <rsalveti> ogra_ac: hehe
[17:59] <rsalveti> they asked already to change to at least a png
[18:01] <ogra_ac> that wont make it smaller though ... i just bloated planet.ubuntu.com with it
[18:02] <robclark> I don't know what you guys are talking about...  pandaboard.org looks fine in lynx ;-)
[18:02]  * robclark ducks
[18:03] <ogra_ac> LOL
[18:03] <GrueMaster> HA
[18:03] <robclark> ogra_ac: maybe orbarron could send you a more appropriately sized logo?
[18:04] <ogra_ac> robclark, well, its fine now
[18:04] <ogra_ac> i'll just live with the embarrasement
[18:09] <gourneau> Can rootstock be used to build debian root fle systems?
[18:11] <ogra_ac> gourneau, i dont think anyone tested that ever
[18:12] <dcordes> ogra_ac: any ac100 kernel news ?
[18:12] <gourneau> Maybe it will be me then, I want to use Ubuntu.  How are the seed images defined?
[18:13] <ogra_ac> dcordes, see planet.ubuntu.com
[18:13] <ogra_ac> (no, no kernel news, but fully working images
[18:13] <ogra_ac> )
[18:14] <dcordes> ogra_ac: ah well didn't see any user space problems ..
[18:14] <ogra_ac> dcordes, plenty
[18:15] <dcordes> the SoC doesn't support neon right ?
[18:15] <ogra_ac> right
[18:17] <dcordes> what userspace related problems do you see ?
[18:17] <dcordes> did you create a meta bug ?
[18:17] <ogra_ac> android kernel
[18:17] <ogra_ac> no
[18:17] <ogra_ac> i dont think you will see any official support for the device any time soon
[18:17] <dcordes> haha sometimes you make me laugh
[18:18] <ogra_ac> feel free to create one though
[18:18] <dcordes> I am looking to make things work, not if they will magically fix.
[18:18] <ogra_ac> dcordes, thne tak to phh in #ac100 :)
[18:18] <dcordes> I know the bum
[18:18] <ogra_ac> *then talk
[18:19] <ogra_ac> he has done a lot of low level stuff
[18:19] <ogra_ac> and is still doing
[18:19] <dcordes> without kernel source ?
[18:19] <ogra_ac> well, there kind of is kernel source
[18:20] <ogra_ac> its not as if there wouldnt be public branches of tegra eclair
[18:20] <dcordes> now you got me all confused
[18:20] <ogra_ac> the kernel supports modules ;)
[18:20] <ogra_ac> you cant change the core indeed
[18:21] <gourneau> Does anyone know of a good Ubuntu tablet about 7 inches, with a host USB port.  The smartq v7 is the best I can find.
[18:28] <dcordes> gourneau: htc hd2 but you need to supply external power for the usb and the display is not 7 inches
[18:29] <ogra_ac> and you can run ubuntu natively ?
[18:35] <orbarron> orga_ac: pandaboard.org is a temp site for now... plz forgive the jpeg
[18:36] <dcordes> ogra_ac: yes
[18:36] <dcordes> ogra_ac: http://vimeo.com/14630263
[18:36] <ogra_ac> orbarron, i dont care about jpeg, i care about that i right clicked the logo and pasted ion my blog post ... now my post has the whole site in it
[18:36] <dcordes> ogra_ac: with full snappyness
[18:37] <dcordes> lol bluepaste :>
[18:37] <GrueMaster> ogra_ac: Do any of our initramfs scripts touch nand on beagle?  I keep getting nand i/o errors on mtdblock0.
[18:38] <ogra_ac> GrueMaster, nope
[18:38] <GrueMaster> But only after upgrading lucid to maverick (which replaces the kernel in nand).
[18:38] <ogra_ac> GrueMaster, not in maverick
[18:38] <GrueMaster> Very odd.
[18:38] <GrueMaster> That's what I thought.
[18:38] <ogra_ac> oh, upgrade is different
[18:38] <ogra_ac> that still uses nand indeed
[18:38] <GrueMaster> No, this is running a preinstalled image.
[18:39] <dcordes> Is there any known breakage in 27th omap4 preinstalled image ?
[18:39] <GrueMaster> But I only get the error if the maverick kernel is also in nand.
[18:39] <GrueMaster> dcordes: Use the 29th.  It will be the official RC.
[18:40] <dcordes> GrueMaster: ok I downloaded it already but had some strange problem
[18:41] <dcordes> sounds like it must be on my end if you consider it for RC
[18:41] <dcordes> somebody interested in adding HTC HD2 maverick RC infomration in planet ?
[18:42] <dcordes> then we have covered the full embedded family
[18:42] <dcordes> smartbook, dev board and cell phone
[19:11] <dcordes> nevermind :)
[19:16] <devilhorns> grrrrr
[19:16] <devilhorns> someone needs to spank the icon designers
[19:18] <ajay> hi all , i have igep board but in minicom i am getting message as ����
[19:18] <ajay> no boot prompt
[19:19] <GrueMaster> devilhorns: Are you referring to bug 651391?
[19:19] <ubot2> Launchpad bug 651391 in gnome-control-center (Ubuntu) "Changing desktop font changed entire theme appearance in une-efl (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/651391
[19:19] <devilhorns> GrueMaster, no, gimme a sec, I will show you my "gripe" :)
[19:19] <rsalveti> ajay: probably missing x-loader and u-boot
[19:20] <ajay> but green light is glowing on that board
[19:20] <devilhorns> GrueMaster, ok, keep in mind when you look @ this, that my code does everything properly (in that it centers the icons)
[19:20] <devilhorns> http://home.comcast.net/~devilhorns/files/unity_efl.png
[19:20] <devilhorns> GrueMaster, but, look @ the button
[19:21] <devilhorns> and looking @ the icon itself, you can see "the problem"
[19:21] <GrueMaster> Yep.  Icons aren't centered in their frame.  Bad.
[19:22] <devilhorns> yep :)
[19:22] <devilhorns> now what kinda moron makes icons like that ... *sigh*
[19:22] <ajay> rsalveti, is this happens due to any null modem cable error as well?
[19:22] <GrueMaster> There's probably a patent if they did.
[19:22] <rsalveti> ajay: could be, but generally you get tons of weird characters when getting garbage
[19:22] <devilhorns> a patent for centering icons ? I highly doubt that :)
[19:23] <rsalveti> ajay: are you open it with 115200?
[19:23] <ajay> yes
[19:23] <GrueMaster> Never know with software patents.
[19:23] <ajay> hw and sw flow control is off
[19:23] <rsalveti> generally I never use minicom, just screen /dev/ttyUSB0 115200 is enough for me
[19:23] <devilhorns> GrueMaster, well, if that is the case, then every designer on the planet is in trouble :) I mean really, how Doesn't center images ? :)
[19:23] <rsalveti> but could be cable issues also
[19:23] <rsalveti> maybe wrong pins
[19:24] <GrueMaster> heh
[19:24] <ajay> rsalveti, i have checked i am using cross cable
[19:24] <ajay> null modem
[19:24] <ajay> IDC10 DB9 also as mentioned in websites
[19:26] <ajay> rsalveti, for screen /dev/ttyUSB3 115200 also i am getting just blank screen
[19:26] <rsalveti> ajay: any garbage?
[19:26] <ajay> nothinmg
[19:26] <ajay> if i write then it is getting garbage
[19:27] <ajay> rsalveti, if i write same thing is getting printed
[19:27] <rsalveti> hm
[19:28] <ajay> just for enter key getting printed at start �
[19:28] <devilhorns> GrueMaster, btw
[19:28] <ajay> is it cable problem?
[19:28] <ajay> or uboot xloader got corrupted
[19:28] <devilhorns> that bug is not in une-efl ... it's a control-center (appearance properties) problem
[19:28] <GrueMaster> That's what I thought when I filed it.
[19:29] <rsalveti> ajay: could be, but it it was corrupted you should not get any echo from uart
[19:29] <ajay> rsalveti, but not even getting uboot prompt
[19:29] <ajay> or any message saying loading
[19:30] <devilhorns> yea, the issue is that "appearance-properties" creates a "custom" theme whenever you change any "looks" (fonts, colors, etc). When it creates that "custom" theme, it takes the base theme, changes all the properties for it in gconf, then saves it. When it does the changes, it reads the values of the original theme (icons, colors, etc) and updates gconf values for that
[19:30] <pcacjr__> ajay: are you doing that with sudo ?
[19:30] <rsalveti> ajay: I would first suggest you to make sure you're using a valid x-loader and u-boot
[19:30] <rsalveti> if I'm not wrong, there's a default one at the nand
[19:30] <devilhorns> so modifying anything, resets all the gconf properties to default for that "base theme", and saves the custom values
[19:31] <rsalveti> then checking if the cable and etc is correct
[19:31] <devilhorns> so it's reseting "icon theme" to the default for that original theme
[19:31] <ajay> pcacjr, i am doing with root
[19:32] <ajay> rsalveti, how to make sure that i am using valid xloader or u-boot
[19:32] <pcacjr__> rsalveti: should he at least get some weird bytes on the screen ?
[19:33] <devilhorns> GrueMaster, @ any rate, I'm not going to "doctor" my code for badly designed icons :) the centering issue will remain just that. an "issue" because of bad icons :)
[19:33] <GrueMaster> I wouldn't either.  File a bug on the icon set.
[19:33] <rsalveti> ajay: getting the stock one, provided by the igep website
[19:33] <rsalveti> pcacjr__: yup
[19:33] <devilhorns> GrueMaster, indeed :) Will do that later when I have some time
[19:34] <rsalveti> ajay: http://shop.igep.es/index.php?main_page=product_info&cPath=1&products_id=8&zenid=701aa01925001b84ed070559d8ac0851
[19:34] <rsalveti> probably same one from beagle
[19:35] <ajay> rsalveti, i have same one
[19:35] <rsalveti> ajay: http://www.igep.es/index.php?option=com_content&view=article&id=99&Itemid=112&dir=/var/www/vhosts/igep.es/httpdocs/downloads/01-ISEE_Products/IGEPv2/SW_Releases/binaries
[19:37] <ajay> rsalveti, shall i keep xloader and uboot in sdcard
[19:37] <ajay> from above link
[19:38] <rsalveti> yep, at least at beagle you can boot using the x-loader and u-boot from the sdcard by using the user button, don't know if we have the same for igepv2
[19:38] <ajay> rsalveti, no there is no button for igep
[19:38] <ajay> rsalveti, http://labs.igep.es/index.php/How_to_recover_a_IGEP_bricked_board
[19:39] <ajay> this site is for showing to recover a board
[19:39] <ajay> but not sure shall i follow these steps
[19:42] <dcordes> bbl
[19:42] <rsalveti> ajay: well, if you just follow these steps you'll for sure be able to flash a valid x-loader and u-boot, and get something at your uart
[19:42] <rsalveti> if you set up your sd and still see garbage, than your problem could be related with your cable setup
[19:55] <devilhorns> anyone running unity ?
[19:59] <ajay> rsalveti, is this problem due to power cable also?
[20:00] <rsalveti> ajay: just if you're not using the proper 5v one
[20:17] <ogra_ac> bug 607752
[20:17] <ubot2> Launchpad bug 607752 in ubuntu "[needs-packaging] devmem2 needs packaging (affects: 2) (heat: 59)" [Wishlist,New] https://launchpad.net/bugs/607752
[20:17] <ogra_ac> hrm
[20:17] <ajay> rsalveti, i tried above wiki of recovering brick igep board
[20:17] <ajay> but for this also i am getting similar error as no messages
[20:18] <ajay> if i press any key from keyboard hetting printed as �
[20:20] <rsalveti> so probably an issue at your cable setup, or usb-serial converter
[20:26] <lool> rsalveti: Plenty of people get this issue with IGEP
[20:26] <lool> There is a hardware grounding issue I'm sure
[20:27] <lool> one workaround is using a differnt USB serial adapter, or a real PC serial port; another workaround is plugging a mini-USB cable to the IGEP to help grounding
[20:29] <rsalveti> lool: hm, interesting
[20:35] <vgrade> hi guys, anyone working on i.MX51
[20:37] <ogra_ac> amitk does
[20:40] <vgrade> ogra_ac, thanks
[21:02] <GrueMaster> rsalveti: Can you download http://ports.ubuntu.com/dists/maverick/main/installer-armel/20100211ubuntu28/images/omap/netboot/omap/* and try on your beagleXM?  I am seeing it either not detecting my USB keyboard or it is locking up hard.
[21:02] <rsalveti> GrueMaster: sure
[21:02] <GrueMaster> You will have to copy these to an existing image partition1 to get MLO & u-boot.bin
[21:03] <rsalveti> sure, np
[21:03] <rsalveti> GrueMaster: which image did you use as base?
[21:03] <GrueMaster> RC
[21:03] <GrueMaster> Or 20100929.
[21:04] <rsalveti> OK, ping back you in some minutes
[21:07] <GrueMaster> too bad u-boot for beagle doesn't support tftp.  Make my life much easier.
[21:12] <ogra_ac> rsalveti, GLES packages uploaded
[21:13] <ogra_ac> cross your fingers that the release team lets them in :)
[21:13] <rsalveti> ogra_ac: cool, let's wait and see :-)
[21:13] <rsalveti> ogra_ac: where can I track it?
[21:13] <ogra_ac> i filed bug 652347
[21:13] <ubot2> Launchpad bug 652347 in ubuntu "[needs-packaging] opengles-sgx-omap3 and powervr-omap3 need to be packaged for maverick (affects: 1) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/652347
[21:13]  * ogra_ac hopes thats enough to justify the FFe
[21:14] <ogra_ac> rsalveti, some clear final statement for bug 607752 would be helpful btw
[21:14] <ubot2> Launchpad bug 607752 in ubuntu "[needs-packaging] devmem2 needs packaging (affects: 2) (heat: 59)" [Wishlist,New] https://launchpad.net/bugs/607752
[21:15] <rsalveti> yup, devmem2 is very useful but ugly
[21:16] <ogra_ac> right
[21:16] <ogra_ac> the discussion just doesnt end clearly with "we will use it"
[21:17] <rsalveti> ok, will comment on it
[21:35] <GrueMaster> rsalveti: I get the same results on the beagle & beagleXM with the netboot image.  complete lockup.
[21:36] <rsalveti> weird, my image is just resizing, will test it when it finishes
[21:36] <rsalveti> now creating swap...
[21:36] <GrueMaster> resizing?
[21:36] <GrueMaster> It should boot into the debian installer.
[21:37] <rsalveti> yep, but I was going to test your kernel to see if it works or not
[21:38] <GrueMaster> Make sure you are using the boot.scr, uImage and uInitrd from http://ports.ubuntu.com/dists/maverick/main/installer-armel/20100211ubuntu28/images/omap/netboot/omap/*
[21:38] <rsalveti> I just flashed 20100929
[21:38] <GrueMaster> Oh.
[21:38] <rsalveti> yup, will use that
[21:38] <GrueMaster> No need to go through the preinst boot stuff.
[21:39] <rsalveti> I know, just wanted to at least have a proper rootfs
[21:39] <rsalveti> ok, will use your kernel and initrd now
[21:39] <GrueMaster> Why?  It creates one (or it is supposed to).
[21:40] <GrueMaster> brb
[21:41] <ogra_ac> rsalveti, the initrd contains the debian-installer
[21:41] <ogra_ac> it will wipe your rootfs
[21:42] <rsalveti> oh, ok, didn't know the debian-installer was inside it
[21:42] <rsalveti> yep, so just booting it should be enough
[21:42] <rsalveti> let me try
[21:42]  * rsalveti used with the pre-installed image
[21:42] <ogra_ac> the great thing is that the whole installer lives in ram
[21:42] <ogra_ac> so you can do whatever you like to your disks
[21:48] <ward|> whats the simplest way of getting a rootfs for my PXA272 based PDA ? i should be able to roll my own kernel
[21:48] <ogra_ac> see /topic
[21:48] <ogra_ac> ;)
[21:48] <ward|> is that the simplest way?
[21:48] <ward|> allready saw that
[21:48] <rsalveti> GrueMaster: yup, no usb
[21:49] <rsalveti> GrueMaster: probably missing modules...
[21:49] <ogra_ac> rsalveti, yeah
[21:49] <rsalveti> let me boot with uart
[21:49] <ogra_ac> old re-occuring bug
[21:50] <ward|> ogra, oh never mind, it cant get much simpler than that i see :p
[21:50] <ogra_ac> ward|, yep :)
[21:52] <rsalveti> no modules at all
[21:52] <rsalveti> not good
[21:55] <ward|> so together with a 2.6.x kernel this should work fine? is there a minimum version or something?
[21:58] <ogra_ac> ward|, udev in ubuntu is usually tied closely to the kernel version
[21:58] <ogra_ac> ward|, so you should make sure yu have something matching
[21:59] <ward|> ogra, ah, so if i only got one specific kernel version i can compile, i should forget about it and use another distro?
[21:59] <ogra_ac> which version do you have ?
[22:03] <ward|> ogra, let me see
[22:04] <ward|> ogra, 2.6.26
[22:04] <ogra_ac> ugh
[22:04] <ogra_ac> thats ancient
[22:04] <ogra_ac> with luck you can use jaunty on that
[22:04] <ogra_ac> but jaunty is EOL in a few weeks
[22:05] <ward|> well its not really coneniant updatiung the kernel all the time on a closed source PDA lol
[22:05] <ogra_ac> indeed
[22:07] <GrueMaster> Ok, netboot for dove works.  Just finished.
[22:15] <rsalveti> GrueMaster: so, no modules at your uInitrd
[22:16] <GrueMaster> Well now.  That would be a bad thing.
[22:21] <rsalveti> ndec: upstream kernel is activating the errata for arch_omap4: https://patchwork.kernel.org/patch/183142/
[22:21] <rsalveti> so I believe it should be fine with it
[22:21] <rsalveti> at least my board is still up and building after using the errata
[22:22] <rsalveti> 20 hours, and 9 builds
[22:23] <ndec> rsalveti: but my understanding is that this errata is not needed on es2.0, it's fixed in the arm chip in es2.0...
[22:24] <ndec> rsalveti: but i might be wrong ;-)
[22:24] <rsalveti> ndec: yep, thought the same but couldn't find anything about it =\
[22:29] <rsalveti> GrueMaster: any idea why we're building the initrd without any modules?
[22:29] <rsalveti> ogra: said that this is a re-occuring bug
[22:29] <ogra> rsalveti, space
[22:29] <GrueMaster> Nope.  Ask an engineer.  btw, meeting.
[22:29] <rsalveti> yup
[22:59] <ward|> ogra, i think i found out why the devs chose 2.6.26 lol
[23:00] <ward|> ( ogra, provided you are ogra_ac)
[23:00] <ogra> yes, i'm both on differnt devices in different rooms
[23:00] <ward|> yeah just making sure :)
[23:01] <ward|> the debian EABI docs use this version aswell, and they make it clear only that one is supposed to work: "NOTE: Take a lot of care, that _only this old linux kernel version works_."
[23:02] <ward|> so maybe there are a lot more devices lie mine with this outdated kernel
[23:03] <ward|> thought i should mention it so ubuntu-arm devs can investigate this if they want to
[23:08] <robclark> ndec / rsalveti: which errata?
[23:09] <rsalveti> robclark: PL310_ERRATA_588369
[23:09] <robclark> ok.. let me check
[23:10] <robclark> rsalveti: ok.. this one seems to apply to the cortex-a9 IP, prior to r2p0
[23:10] <robclark> (just need to check which rev on cortex is in es2.0)
[23:11] <robclark> r1p2.. so keep the errata enabled
[23:15] <rsalveti> robclark: oh, cool, thanks for identifying it
[23:19] <robclark> rsalveti: btw, was there any new discoveries on highmem in last couple days?
[23:20] <rsalveti> robbiew: well, we were first trying to debug the issue without highmem, because we always face problems when using highmem
[23:20] <rsalveti> with one cpu, without l2
[23:20] <rsalveti> so then I found that we were not using this errata yesterday
[23:20] <robclark> oh, ok.. so same sort of issue even without highmem?
[23:21] <robclark> so w/ PL310 errata patch, it is getting more stable?
[23:21] <rsalveti> gave it a try and I'm running without highmem, 2g:2g, 1gb, 2cpus and doing well
[23:21] <robclark> ok.. that sounds like an improvement
[23:21] <rsalveti> robclark: more than 20 hours building
[23:21] <robclark> have you tried w/ highmem yet?
[23:21] <rsalveti> no issues
[23:22] <rsalveti> robclark: yup, and still get the issue easily, so probably another bug
[23:23] <robclark> and that is also w/ the nvidia highmem patch?
[23:23] <rsalveti> robclark: yup
[23:23] <robclark> hmm.. ok.. so still another issue lurking :-(
[23:23] <rsalveti> yeah :-( but at least we have a workaround to use 1gb now
[23:24] <robclark> yeah.. I think 2g/2g is way to go for now
[23:25] <rsalveti> and the build is now taking less than 2 hours
[23:25] <rsalveti> using an external usb disk
[23:31] <robclark> ohh..  we tried a USB drive at the last sprint, although I think it was quite a slow usb powered hd..
[23:38] <GrueMaster> That and it was all ES1 then, wasn't it?
[23:39] <rsalveti> probably, and using usb otg
[23:47] <GrueMaster> rsalveti: Can you confirm Bug #652522?  Thanks
[23:47] <ubot2> Launchpad bug 652522 in debian-installer (Ubuntu) "modules missing from omap netboot image. (affects: 1) (heat: 8)" [Medium,New] https://launchpad.net/bugs/652522
[23:48] <rsalveti> GrueMaster: sure


[01:36] <kristina__> anyone here ??
[01:38] <eric> hello
[01:42] <eric> hi
[01:42] <eric> hello
[03:07] <kristina__> hi eric
[03:09] <kristina__> am wondering can anyone answer me , am trying to download armitage already done with metasploit , now when I try to download it from its official site they block me claiming the site contains malicious spyware ?? anyone who can help ?
[22:53] <william_clarck> Teste chat..
[23:09] <alkisg> Test succeeded :)
[23:52] <mate|35516> can i move my swap file out of root and put it in my home drive, my root drive is an ssd