[00:43] <axw> thumper: what's your stance  on things like ctx/txn?
[01:44] <thumper> axw: I strongly prefer what uncle Bob calls "Unse Pronounceable Names"
[01:45] <thumper> personally I use context
[01:45] <thumper> and prefer transaction
[01:45] <axw> thumper: ok. my reasoning is that, for things like ctx, the translation to context is automatic (for me)
[01:46] <axw> so I pronounce it "context"
[01:46] <thumper> but the point is, you need to translate
[01:46] <thumper> there is a cognitive process there
[01:46] <thumper> that takes ctx, and makes context
[01:46] <axw> not consciously
[01:46] <thumper> but it is there
[01:46] <thumper> when I see it, I still see "see tee ex"
[01:46] <davecheney> sure, so is translating source code into your native language
[01:46] <davecheney> i think it's a very minimal cost
[01:46] <davecheney> and we're trained to do it very effectively
[01:46] <thumper> davecheney: but writing code is all about people reading it
[01:46] <axw> if it's not the same for everyone that's fair enough
[01:47] <thumper> axw: I agree that some don't have that
[01:47] <thumper> but do you have a problem reading "context" as a variable?
[01:47] <thumper> davecheney: computers are easier to train
[01:47] <axw> thumper: only when it means the source line > 80 chars, or becomes a series of ugly lines
[01:48]  * davecheney is sad that we can't apply common sense here
[01:48] <thumper> axw: I agree, in which case the logic should be simplified
[01:48] <thumper> computers are good at optimising
[01:48] <thumper> davecheney: common sense isn't as common as we'd hope
[01:49] <thumper> axw: I remember writing some code one, it was c++
[01:49] <thumper> where I managed to use a single for_each function
[01:49] <axw> thumper: btw I'm not advocating ctx necessarily, just playing devil's advocate
[01:49] <thumper> in the end though, I rewrote it with a normal for loop that took two or three more lines
[01:49] <thumper> because it was more readable
[01:49] <thumper> one of my favourite programming mantras is:
[01:50] <thumper> just because you can, doesn't mean you should
[01:50] <thumper> however, smart C++ programmers would have been able to see what my extremely clever function was doing
[01:50] <thumper> but it wasn't obvious
[01:50] <thumper> I'd go for obvious over clever every time
[01:51] <thumper> however, I feel that there are some on our team that prefer clever
[01:51] <axw> thumper: agreed. I used to fall into the clever code trap, but try hard to steer away from it now. It doesn't scale well in teams, and I tend to forget what my code is meant to do
[01:51] <thumper> agreed
[01:52]  * axw remembers in horror at his former colleagues' naming conventions
[01:53] <axw> or lack thereof
[01:53] <axw> basically all the variables would be the first letter of the variable's compound word type
[01:53] <axw> var atp AggregateTableProvider
[01:53] <axw> fun times
[01:58] <thumper> haha
[01:59] <axw> bbl, lunch
[02:24] <bigjools> thumper: txn reads perfectly well! :)
[02:25] <bigjools> thumper: however when I see ctx my mind pronounces it as "cuntox"
[02:25] <thumper> heh
[02:25] <bigjools> blame big kev ...
[02:25] <thumper> well, everyone is different
[02:25] <bigjools> yeah
[02:25] <bigjools> which is precisely why you are right
[02:25] <thumper> the idea is to code for the majority
[03:03] <kvt> poking through the state pkg, and noticing some odd items a couple of the docs have counts, like serviceDoc has relation count, relations have unitcount.. is that just an optimization vs querying those?
[03:49] <thumper> kvt: probably
[04:26] <davecheney> bigjools: ping
[04:27] <bigjools> davecheney: hail
[04:28]  * thumper read that as 'fail'
[04:28] <thumper> perhaps I have too much on my mind
[04:28] <bigjools> understandable
[04:55] <thumper> jam: I've added Dubai to my clock city list so I can know what time it is there.
[04:56] <jam> thumper: :)
[04:56] <thumper> jam: so you are 8 hours out from me
[04:56] <thumper> jam: got time for a quick hangout?
[04:56] <jam> thumper: right. I'm right at the end of your day, I believe. though it depends whether I wake up and poke around before officially "starting".
[04:56] <jam> sure
[04:56]  * thumper starts one
[04:57] <thumper> https://plus.google.com/hangouts/_/f16d2fd28ebc5923a5ceb1a2e1ffc57f5b152404?hl=en
[04:57] <thumper> jam: ^^
[04:58] <jam> thumper: trying to connect, it rings on my phone where I don't want to connect
[04:58] <jam> and isn't loading on the desktop where I do
[04:58] <thumper> haha :(
[04:58] <thumper> hmm..
[04:58] <thumper> jam: did you want to set one up
[04:58] <thumper> ?
[04:59] <jam> let me make sure I'm signed into all of my accounts quickly
[05:00] <jam> thumper: I'll call you back, it is just getting stuck at "joining video call".
[05:01] <thumper> kk
[05:02] <jam> calling you
[05:02] <jam> https://plus.google.com/hangouts/_/f16d2fd28ebc5923a5ceb1a2e1ffc57f5b152404
[05:02] <jam> thumper: ^^
[05:02] <jam> I really don't prefer the "calling" style of hangout, vs just creating one and having people join it.
[05:41] <thumper> night people
[06:21] <davecheney> bigjools: 16:19 < kurt_> davecheney: do you know this error? error: cannot create bootstrap state file: gomaasapi: got error back from server: 400 BAD REQUEST
[06:21] <davecheney> any ideas ?
[06:22] <bigjools> davecheney: yes, maas was not accepting empty files.   I'm just going through activereviews and cleaning it out.
[07:13] <axw> jam: looks like the bot's /tmp is full of gocheck dirs
[07:13] <axw> are you able to clean that?
[07:13] <jam> axw: if you're able to see it, you're able to clean it, but I'll do it
[07:13] <axw> I can see it because my MP failed
[07:13] <axw> tests failed, because /tmp/gocheck-blah exists
[07:14] <axw> jam: gocheck doesn't set a seed for rand when it generates the temp dirs
[07:39] <rogpeppe> mornin' all
[07:54] <jam> morning rogpeppe
[07:54] <rogpeppe> jam: hiya
[08:01] <jam> rogpeppe: I have a couple more CLI API patches up that would appreciate a quick review.
[08:01] <rogpeppe> jam: ok, will have a look
[08:01] <jam> https://codereview.appspot.com/12744052/
[08:01] <jam> and
[08:02] <jam> https://codereview.appspot.com/12744053/
[08:04] <rogpeppe> jam: BTW we can work around the int64 vs float64 thing if we want to, but given that the API is accessed from javascript, I'm not entirely sure we should.
[08:05] <jam> rogpeppe: right. My concern is if someone out there is getting their settings as YAML and then parsing it into a struct that requires an int.
[08:05] <jam> We do have a "type" object in that struct, though.
[08:05] <jam> So the other option is that GetConfig/SetConfig start understanding the actual content of those messages
[08:06] <jam> but I'd like to just punt on all that :)
[08:07] <jam> rogpeppe: gustavo mentioned we can change the decode function to "UseNumber" but I'm not sure what that actually changes? If it doesn't have a decimal you get an int64?
[08:07] <jam> It uses arbitrary precision integers?
[08:09] <rogpeppe> jam: you can change it to get any type you want - one possibility is just to use a string.
[08:10] <jam> rogpeppe: I tracked it down, it is "json.Number" which is actually a string, and then you "Number.Float64()"
[08:10] <jam> it still wouldn't let us use DeepEquals easily
[08:10] <jam> but it would let us get what we want later on.
[08:10] <jam> But if we have to do that step
[08:10] <jam> we can int64(floatValue)
[08:10] <TheMue> jam: thx for review. setting an option to nil means unsetting it, so that the default is valid. and setting an option to "" will not be translated to nil anymore (as before). so for string options "" is a valid value while it's an error for other ones (like in pyjuju).
[08:10] <jam> and it just matters when you have > 40bits of precision in your int74
[08:10] <jam> int
[08:11] <jam> TheMue: right that is where I thought we were going: Allow "" to be a valid setting, and use nil to indicate you want a default value. So your patch fits that just fine.
[08:11] <rogpeppe> jam: exactly
[08:11] <rogpeppe> jam: and that might actually be a problem
[08:12] <TheMue> jam: yep
[08:12] <jam> rogpeppe: you mean losing precision on ints?
[08:12] <rogpeppe> jam: yes
[08:12] <rogpeppe> jam: we might be causing subtle breakage in existing charm usage
[08:13] <jam> rogpeppe: float64 has exact precision up to ~52 bits so it only matters if someone enters 2**61+1 that they care about that +1
[08:13] <rogpeppe> jam: yes
[08:13] <rogpeppe> jam: but that still might be important
[08:13] <rogpeppe> jam: for instance someone might be storing bytes in there or something
[08:14] <jam> rogpeppe: don't store bytes in a number type
[08:14] <jam> I think that is a fine statement
[08:14] <jam> we have strings
[08:14] <rogpeppe> jam: indeed
[08:14] <jam> and base64
[08:14] <rogpeppe> jam: but it's still a possible issue
[08:14] <jam> rogpeppe: I would be willing to take a patch that changed "juju set" to notice that you might lose precision and warn you
[08:14] <jam> rogpeppe: I'm happy to deal with it when someone shows it is an actual problem.
[08:15] <rogpeppe> jam: tbh i think it's ok to just say we only cope with 52 bits of precision
[08:15] <jam> rogpeppe: I feel the same way.
[08:15] <rogpeppe> jam: in fact, we *could* deprecate the "int" type entirely
[08:15] <jam> which is why I JFDI with float()
[08:15] <rogpeppe> jam: +1
[08:36] <rogpeppe> jam: those two CLs reference the same MP
[08:36] <rogpeppe> jam: i think i just reviewed the one without the prereq
[08:37] <rogpeppe> jam: so it proabably counts as a review of both :-)
[08:50] <jam> rogpeppe: yeah, I meant https://codereview.appspot.com/12943045/
[08:51] <jam> rogpeppe: so for Client object. What fwereade_ really wanted is to avoid exposing "Environ" to the CLI code as much as we can (because we shouldn't need stuff like provider creds for almost everything we do).
[08:51] <rogpeppe> jam: yeah, that seems reasonable
[08:51] <jam> rogpeppe: beyond that, there isn't much that api.State provides CLI above "api.State.Client()".
[08:52] <rogpeppe> jam: agreed
[08:52] <jam> so I'd like to start with restricting it to just Client, and see if we can make it with that
[08:52] <rogpeppe> jam: i think that sounds fine too
[08:52] <jam> but I'm happy to fix the comment
[08:52] <jam> rogpeppe: ah, back to you. IT turns out that multiple Close of api.State actually isn't ok
[08:53] <jam> underneath api.State.Close() just calls rpc.Conn.Close()
[08:53] <jam> which returns: errors.New("already closing")
[08:53] <jam> rogpeppe: should multiple Close calls be an error?
[08:53] <rogpeppe> jam: it's not clear
[08:54] <jam> rogpeppe: we had a test that state.State.Close() can be called multiple times (though like I copied, it didn't actually check the err return :)
[08:54] <rogpeppe> jam: on network connections, i think the second close will return an error
[08:54] <jam> you can add that, and it passes
[08:54] <jam> it fails for api.State.Close()
[08:56] <rogpeppe> jam: we could make rpc.Conn.Close return nil if it's already closing
[08:56] <jam> rogpeppe: that would be my preference, but you wrote it and I wanted to check what your reasoning was
[08:57] <rogpeppe> jam: i think i was principally following the original logic of net/rpc
[08:57] <rogpeppe> jam: which returns an error in that case
[08:58] <rogpeppe> jam: (if in doubt i followed net/rpc's conventions)
[08:58] <jam> rogpeppe: right: http://golang.org/src/pkg/net/rpc/client.go?s=7213:7248#L262
[08:58] <jam> though it returns a typed error
[08:58] <jam> which we could suppress at a higher level if we wanted.
[08:58] <rogpeppe> jam: that's true. but it's a typed error that actually means two possible things
[08:59] <rogpeppe> jam: 1) you just closed it; 2) the server shut down on you
[08:59] <jam> rogpeppe: sure, though if I'm calling Close() and that happened to be shutdown by the remote side, that doesn't sound like an error
[09:00] <jam> so I don't know if you need to distinguish between the two cases in this path
[09:00] <jam> in *my* opinion, Close() is one of those idempotent functions that you can call multiple times to make sure resources were cleaned up
[09:00] <jam> rogpeppe: if you agree, I'm happy to change rpc.Conn and assert it higher in the stack.
[09:02] <rogpeppe> jam: I think that sounds reasonable (presumably you mean "lower in the stack"?)
[09:02] <jam> rogpeppe: well I mean assert it across the stack
[09:02] <jam> so we assert api.Client.Close and APIConn.Close() and api.State.Close and rpc.Conn.Close()
[09:03] <jam> They happen to be implemented in terms of eachother, but it is nice to have the statement "Close() is idempotent at the various levels"
[09:03] <rogpeppe> jam: what's APIConn ?
[09:04] <jam> rogpeppe: juju.APIConn
[09:04] <rogpeppe> jam: oh doh!
[09:04] <jam> Contains an api.State and api.Environ
[09:04] <jam> rogpeppe: mirroring juju.Conn
[09:04] <rogpeppe> jam: yes, that all seems reasonable
[09:04] <jam> but *probably* going away
[09:04] <jam> I didn't want to be ripping it out at this point, but we have api.Client() where functionality that needs a place like juju.Conn can go, there doesn't seem much point in having both, and we *don't* want most CLI things to need an object that has Environ on it.
[09:05] <rogpeppe> jam: yes, i think it will probably go away, though there are one or two lingering bits
[09:05] <jam> rogpeppe: hopefully most of it involves moving things into the API :)
[09:05] <rogpeppe> jam: yeah, i'm very much +1 on putting everything behind api.Client
[09:06] <rogpeppe> jam: it wasn't possible before, because we couldn't mix logic that involved both Environ and State in a State method.
[09:08] <jam> rogpeppe: out of curiousity, why is rpc.Conn defined in "server.go" rather than "client.go" ?
[09:08] <rogpeppe> jam: it could be either
[09:08] <rogpeppe> jam: it's both the server and the client side
[09:09] <rogpeppe> jam: it could have been in a separate file, i guess, but i don't think it's a big issue
[09:10] <rogpeppe> mgz: morning!
[09:10] <mgz> qmorning!
[09:11] <jam> rogpeppe: no, it just wasn't where I was looking for it when dealing with connection on the client side. And the word "Conn" exists all over the place in our source code. :)
[09:11] <jam> mgz: morning
[09:11] <rogpeppe> jam: you should really use better tooling :-)
[09:11] <jam> rogpeppe: we should use better names
[09:11] <rogpeppe> jam: rpc.Conn seems just fine to me
[09:12] <rogpeppe> jam: it's unambiguous
[09:12] <jam> rogpeppe: except for net/rpc/Conn
[09:12] <rogpeppe> jam: they're both connections
[09:12] <jam> rogpeppe: but they both use "rpc.Conn" and are entirely different code.
[09:12] <jam> even if they are "similar"
[09:13] <rogpeppe> jam: ah, sorry, thought you were referring to net.Conn vs rpc.Conn
[09:14] <jam> rogpeppe: there may not actually be a net/rpc/Conn, but punning 'rpc' with a stdlib package is also not great naming.
[09:14] <rogpeppe> jam: in a large s/w environment, there are always going to be duplicate names. the package name spacing means that it's possible to reliably and quickly find the actually definition for any given name
[09:14] <rogpeppe> jam: and there are tools that integrate with your editor that makes that easy to do
[09:15] <rogpeppe> jam: (assuming you use emacs or vim :-])
[09:15] <rogpeppe> s/actually/actual/
[09:17] <rogpeppe> jam: do you think that all our names should be globally unique?
[09:18] <jam> rogpeppe: I'm not sure about globally unique, but avoiding repeated 10 times would be nice
[09:18] <jam> eg State
[09:18] <jam> Conn
[09:18] <jam> and Client
[09:20] <rogpeppe> jam: i think that that's actually a benefit - those names are well known concepts, and they're unambiguous when used in context (rpc.Conn vs net.Conn; uniter.State vs machiner.State, etc)
[09:20] <rogpeppe> jam: i guess it comes down to the "no needless repetition" thing
[09:20] <rogpeppe> jam: which is a conventional approach in Go
[09:20] <rogpeppe> jam: but does have some down sides, as you point out
[09:21] <jam> rogpeppe: I *do* like not having var foobar foo.FooBar  = new foo.FooBar(fooing the bars)
[09:21] <rogpeppe> jam: but you prefer foo.FooBar to foo.Bar ?
[09:22] <jam> rogpeppe: I like it being really easy to translate "foo := SomethingReturningAFoo()" into what Foo that is returning.
[09:23] <jam> and using "tools that are already installed on my system" rather than having to dig up "nostandard but useful tools" from 3rd parties.
[09:23] <rogpeppe> jam: presumably if it's foo.NewBar(), that's fairly obvious
[09:25] <jam> rogpeppe: except it is "rpc.Conn" and that is actually net/rpc/Conn or foo/bar/baz/rpc/Conn
[09:25] <jam> rogpeppe: so I have to look up what "foo" is actually being imported here.
[09:26] <rogpeppe> jam: it's true that package identifiers aren't unique (we use "testing" many times, for example)
[09:26] <jam> rogpeppe: and it is a source of confusion occasionaly.
[09:27] <rogpeppe> jam: yeah, it can be. but hopefully in situations where ambiguity might be a problem, we rename the identifiers appropriately.
[09:27] <rogpeppe> jam: we only use net/rpc in one place in our tree, for example
[09:27] <jam> rogpeppe: so there is "it is unambiguous when you've paged in enough context" and there is "it is unambiguous when you read 3 lines of code"
[09:29] <rogpeppe> jam: personally, i think it's reasonable to assume some contextual knowledge. but that might be just me.
[09:29] <rogpeppe> jam: and i have to say that when browsing code i'm not familiar with, i use godef a lot
[09:29] <jam> rogpeppe: in a team of 10+ having people look at code that they aren't as familiar with it is *useful* albeit not *required* to minimize the need for contextual knowledge.
[09:31] <jam> rogpeppe: it is a goal (generally) to code is such a way that it is understandable to people who aren't as intelligent as myself (especially since *I* will not remember everything in 1 month either :)
[09:31] <rogpeppe> jam: i totally agree with that
[09:31] <rogpeppe> jam: but i don't think that the redundant naming helps greatly there
[09:32] <rogpeppe> jam: in general, i find external Go code (using similar naming conventions to our current ones) is quite easy to browse and understand
[09:33] <rogpeppe> jam: but again, i do use godef (and godoc.org) a lot
[09:33] <jam> rogpeppe: one thing I would *really* like for godoc, is if you could click the Bar in "func Something() Bar)" and have it take you to the definition.
[09:34] <rogpeppe> jam: i think it does that, doesn't it?
[09:34] <rogpeppe> jam: yeah, it does
[09:35] <rogpeppe> jam: it linkifies all type names
[09:35] <jam> rogpeppe: not in the one-line overview, and the "func Something" doesn't give you the arguments or the return type, but if you keep drilling down until you get to the grey-box with more stuff that does eventually get there.
[09:36] <rogpeppe> jam: i might be looking at a different godoc.org to you
[09:36] <rogpeppe> jam: in the one i'm looking at, it's two clicks
[09:38] <rogpeppe> jam: (one to click on the one line overview, which takes you to the actual description, then another to click on the type name)
[09:38] <jam> rogpeppe: and a bit of visual searching to find the right thing, but with practice not too bad. I'm not sure if it used to do that, or if the specific layout of the page made it hard for *me* to see it.
[09:39] <rogpeppe> jam: it's quite possible. and the site does change - it might not have been so good in the past.
[09:39] <jam> I think I would also like to see the overview of functions for a Struct when you go to the structs definition (like there is in the top level index).
[09:40] <jam> AFAIK there isn't a way to jump to the place in the index
[09:40] <jam> and the index mixes
[09:40] <jam> things that return Foo
[09:40] <jam> with methods on Foo itself
[09:40] <jam> eg, http://godoc.org/net/rpc has Client
[09:40] <jam> which has functions returning a Client
[09:40] <jam> and functions on Client
[09:40] <jam> but no concise "these are the methods on Client"
[09:40] <rogpeppe> jam: yeah, it tries to classify factory funcs
[09:40] <jam> I don't mind them being nearby
[09:40] <jam> but it would be useful to have a simple "here are the methods" section
[09:41] <rogpeppe> jam: that's the overview, i guess
[09:41] <jam> in my head it would exist here: http://godoc.org/net/rpc#Client
[09:41] <jam> rogpeppe: they aren't visually distinct from the "here are factory functions"
[09:41] <jam> they are slightly different
[09:41] <rogpeppe> jam: yeah, you have to look for the (client *Client)
[09:42] <rogpeppe> jam: if you can think of a nice way of visually distinguishing them, i'm sure they'd be open to suggestions
[09:42] <rogpeppe> jam: it's not something that had occurred to me
[09:43] <jam> rogpeppe: Are all of the tests for "state/api/*" code over in state/apiserver?
[09:43] <jam> I don't see any _test.go files in state/api
[09:43] <jam> which is.. a bit surprising
[09:44] <jam> (I realize you sort of need apiserver in order to test api code, but I would expect to find api tests in the api package)
[09:44] <jam> rogpeppe: which might be why I put the APIClient.Close test in juju/*
[09:44] <jam> (I'm only *just now* remembering that I saw some api.Client tests in apiserver a few days ago)
[09:45] <jam> rogpeppe: as in, I don't have an immediately obvious place to put new tests that api.State.Close() and api.Client.Close() are idempotent.
[09:45] <jam> rogpeppe: so how do you find where there would be tests for api.State?
[09:45] <jam> rogpeppe: having a unique name instead of State
[09:46] <jam> would make that pretty obvious (i would think)
[09:46] <jam> so references of X not definitions of X
[09:46] <jam> and some of those references might be in the package itself
[09:47] <rogpeppe> jam: my original scheme for testing API functionality was to put all tests in the client.
[09:48] <jam> rogpeppe: there are no tests that I see in state/api/*, and there is no state/api/client/ directory
[09:48] <jam> rogpeppe: is it just that they were moved elsewhere?
[09:48] <jam> rogpeppe: also, no tests for state/api.State object that I can immediately find
[09:49]  * rogpeppe goes to look
[09:50] <rogpeppe> jam: the tests that are now in state/apiserver/client did originally live in state/api, i believe
[09:52] <rogpeppe> jam: yeah, that seems to be the case. they should really be in state/api/client, i think
[09:52] <jam> rogpeppe: I'll file a techdebt bug, but not fix it right now.
[09:53] <rogpeppe> jam: sgtm
[09:54] <rogpeppe> jam: FWIW, i still think that testing all API stuff through the client makes sense, as there's so little actual logic in the RPC layer.
[09:54] <rogpeppe> jam: and the way things are, we've got vast swathes of almost-but-not-quite identical tests at each layer
[09:55] <rogpeppe> jam: i guess the main reason we can't do that is that we decided to expose stuff in the API server that we don't make available in the client.;
[09:56] <jam> rogpeppe: which I've already run into, though it was in the "and this isn't tested" category AFAICT
[09:56] <jam> AddUnit supported ToMachineSpec but that wasn't exposed in api.Client
[09:57] <rogpeppe> jam: ha, yes
[09:57] <rogpeppe> jam: i have difficulty keeping track of what our test coverage is in this area
[09:57] <rogpeppe> jam: because the tests are so overlapping
[09:58] <jam> rogpeppe: so where do you think tests about api.State are today? (where should I add a test that calling api.State.Close() multiple times doesn't give an error)
[09:58] <rogpeppe> jam: i think that tests on api.State should live with the other tests on api.State.
[09:58] <rogpeppe> jam: it seems that that's currently (but wrongly) in state/apiserver/client
[09:59] <rogpeppe> jam: so i'd add it to those, to be moved over at some later date
[10:00] <fwereade_> rogpeppe, I was taking a casual look at Prepare... there's a 3.5 second sleep in jujud/machine.go
[10:00] <rogpeppe> fwereade_: yes, i've removed that since.
[10:00] <rogpeppe> fwereade_: but not re-proposed the branch
[10:00] <rogpeppe> fwereade_: (that was me trying to reproduce a saw-it-once-only test failure)
[10:01] <fwereade_> rogpeppe, :)
[10:05] <fwereade_> rogpeppe, seems fine to me, go ahead and land it, if anything turns out to be a problem for the followup work we'll find out soon enough
[10:05] <rogpeppe> fwereade_: i'm pretty sure it was nothing to do with my changes
[10:09] <jam> fwereade_: did you have anything to add to the float64() vs int64() discussion about the  ServiceGet() api?
[10:11] <fwereade_> jam, I'm fine accepting the json precision restrictions (well, I don't like it, but I don't think it's worth the effort of fixing)
[10:12] <jam> fwereade_: well *JSON* supports arbitrary precision integers AFAICT
[10:12] <jam> golang json.Unmarshal defaults to float64 though you can tweak it to return "type Number string"
[10:12] <jam> but that would make testing it harder rather than easier AFAICT
[10:13] <fwereade_> jam, shall we just call it a bug and move on?
[10:14] <fwereade_> jam, unless you judge it simple enough to make it Right rightnow
[10:15] <jam> fwereade_: my personal feeling is that 'juju get' will return similar-enough types that it probably isn't a problem, and I'm willing to deal with it when charms themselves really do need it
[10:15] <fwereade_> jam, seconded
[10:15] <jam> fwereade_: and I would say the test should be in state/api, except there are 0 tests in there :)
[10:15] <jam> which is what I was just chatting about with roger
[10:15] <fwereade_> jam, but let's document it as a bug regardless so it's easier to hunt it down and figure it out when it *does* happen
[10:16] <rogpeppe> jam: presumably we have a potential issue even if we do use int64 because python would (presumably) use arbitrary-precision ints when needed
[10:16] <jam> fwereade_: bug #1217282
[10:16] <_mup_> Bug #1217282: api.Client tests should be in state/api not state/apiserver/client/ <tech-debt> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1217282>
[10:16] <fwereade_> jam, oh bollocks, they're all in apiserver
[10:16] <jam> fwereade_: as yet I haven't actually found direct tests of api.State either.
[10:17] <jam> rog mentions they might be in state/apiserver/client/* but I haven't actually found a suite that is focused on the api.State object.
[10:17] <fwereade_> jam, oh yay
[10:18] <natefinch> jam: I sent an email that got blocked by the message size limit on juju-dev.... the autoreply I got said it was awaiting moderator approval... are there actual moderators that might approve it, or should I just recreate it?
[10:18] <jam> natefinch: I am not one of the moderators. Gustavo might be, but it is probably easier to just resubmit.
[10:18] <jam> I believe you can reject the existing message yourself.
[10:19] <natefinch> jam: yeah.... bah.  40k limit? What is this, 1998? :)
[10:23] <jam> morning evilnickveitch
[10:23] <jam> I don't remember you having the "evil" goatee, though.
[10:23] <evilnickveitch> jam, hey! My facial hair is in a constant state of flux to confuse my enemies
[10:25] <TheMue> fwereade_: in https://codereview.appspot.com/12752044/diff/8001/cmd/juju/get_test.go you made a comment regarding "default" in "juju get"
[10:26] <rogpeppe> jam: i'd like to see tests in state/api focused on the functionality that's in that package. you're right, tests for api.State itself seem to have vanished. i'm pretty sure i wrote some originally.
[10:26] <TheMue> fwereade_: could you explain your thoughts a bit more?
[10:27] <TheMue> fwereade_: i haven't touched the logic of get here, only moved. but i could handle it in a third CL.
[10:27] <rogpeppe> has anyone seen this when testing?
[10:27] <rogpeppe> PANIC: machine_test.go:58: MachineSuite.TearDownTest
[10:27] <rogpeppe> ... Panic: unauthorized db:presence ns:presence.presence.beings lock type:0 client:<IP_ADDRESS> (PC=0x414321)
[10:27] <fwereade_> TheMue, saying "the value is nil, and that's the default" is redundant/meaningless because a nil value is only possible when there's no default set
[10:28] <fwereade_> TheMue, so a trivial CL stripping "default: true" out of settings where the value is nil would be cool
[10:28] <TheMue> fwereade_: ok, will do
[10:28] <fwereade_> bbiab
[10:33] <jam> natefinch: you have https://code.launchpad.net/~natefinch/juju-core/005-azure-address/+merge/181117 still pending though it has my approval. just poking for you to think about landing it.
[10:34] <natefinch> jam: thanks, meant to talk to you about that. It's LGTM pending live tests, but the values aren't actually used anywhere in the branches, so I sorta can't live test
[10:34] <jam> natefinch: I meant "test against Azure"
[10:34] <davecheney> natefinch: nice work in the win32 installer
[10:34] <jam> as in actually running it live
[10:35] <davecheney> i hope you get some feedback
[10:35] <davecheney> but given the self selection population in the channel
[10:35] <davecheney> please don't take it too hard if you don't get a lot of feedback
[10:35] <natefinch> davecheney: my message got caught by the size limit on the mailing list, so no one but mods have seen it I suspect :)
[10:36] <natefinch> jam:  I guess I can insert some temporary code to call instance.Addresses[]... my point was that nothing calls that method in the branch I'm on
[10:37] <natefinch> at least as far as I could tell
[10:38] <davecheney> natefinch: i saw it
[10:38] <davecheney> i am not a nod
[10:38] <davecheney> mod
[10:39] <natefinch> davecheney: oh, ok, so maybe it was let through and there wasn't a message back to me about it... and since I don't think I get my own messages from the list... makes it hard to tell what's going on.
[10:40] <davecheney> natefinch: you do
[10:40] <davecheney> but gmail doesn't show them too you
[10:40] <natefinch> davecheney: oohh... ok, that could be it
[10:40] <davecheney> you can also check the listserv directlu
[10:41] <natefinch> Ahh yeah, I always forget I can do that
[10:42] <natefinch> well, good.
[10:58]  * TheMue => lunchtime
[10:59] <jam> natefinch: talking about the windows installer. should we just make a 32 bit one and not worry about it? juju-the-client won't ever really benefit from >4GB addressable space. Though I realize go itself works better in 64-bit because of how it does virtual adress
[10:59] <jam> addressing
[10:59] <jam> juju-the-client isn't long lived enough to really matter.
[10:59] <jam> when we get to 'jujud-the-daemon' we'll want to focus more on 64-bit
[11:00] <natefinch> jam: yeah, that's probably a good point. There's very little benefit from 64 bit as you said. And 32 bit is more portable, which is a lot more valuable
[11:00] <jam> (I originally started in 64-bit, and then went to 32-bit when we had C dependencies, because 64-bit mingw wasn't very good, and was thinking to switch back but maybe we just want to stay 32-bit for juju-the-client for now)
[11:05] <davecheney> does anyone know where cloud-init writes the original text of the user data ?
[11:10] <mgz> dave, sec
[11:10] <davecheney> i can never find the bugger
[11:11] <mgz> /var/lib/cloud/instance/user-data.txt
[11:11] <davecheney> mgz: ta muchly
[11:11] <davecheney> bloody hell, cloud-init has everything that opens and shuts
[11:11] <davecheney> oh shit, its base64 encoded
[11:11] <davecheney> well, that is one terminal i wont be using again
[11:12] <natefinch> lol
[11:12] <mgz> dave : in the same folder are the decoded bits
[11:13] <davecheney> mgz: last time I c&p something blindly from you
[11:13] <mgz> I included not cat :)
[11:15] <natefinch> it's like the CLI equivalent of rick rolling :)
[11:20] <fwereade_> guys, I'm afraid I won't make the standup, and I'll probably be working somewhat interrupted hours all week -- it emerges that the flat is actually literally falling apart and I need to find somewhere to live :/
[11:21] <natefinch> fwereade_: wow, damn
[11:21] <fwereade_> yeah, it kinda sucks
[11:21] <natefinch> fwereade_: yeah, I can see how that could be less than optimal
[11:23] <TheMue> fwereade_: iiirks, wishing you luck
[11:24] <natefinch> fwereade_: yeah, good luck, definitely. That's a crappy situation to be in.  Do you own the flat, or are you renting?
[11:33] <jam> natefinch: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 standup
[11:33] <jam> fwereade_: ^^
[11:34] <rogpeppe> mramm: standout, if you want to
[11:34] <rogpeppe> standup even
[11:34] <mgz> standover
[11:35] <jam> standarounder
[11:38] <davecheney> stand to the right
[11:49] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1202163/comments/4
[11:49] <_mup_> Bug #1202163: openstack provider should have config option to ignore invalid certs <juju-core:Triaged> <https://launchpad.net/bugs/1202163>
[11:49] <davecheney> jpds needs love on this one
[11:54] <mgz> that's sadly not as easy to do in gojuju as it was in pyjuju
[11:55] <davecheney> mgz: could we make it always on ?
[11:55] <davecheney> mgz: sorry, was jumping to the soluont
[11:55] <mgz> as in, never check certs?
[11:55] <davecheney> yes
[11:55] <davecheney> i know how to create a client that doens't check certs
[11:56] <mgz> that seems like a bad thing from a security perspective :)
[11:56] <davecheney> mgz: sure
[11:56] <davecheney> is the issue in passing down the 'please don't check' flag
[11:56] <davecheney> or implementing ' please don't check '
[11:57] <mgz> passing through to all the points that use an endpoint seems like the hard part
[11:57] <davecheney> mgz: what if it was at a per environment level ?
[11:58] <mgz> I'm just assuming go has a flag in the http library somewhere for not checking certs
[11:58] <davecheney> yup
[11:58] <mgz> davecheney: so, what happens in pyjuju, is we have the silly er... ssh-hostname-verify or something env config variable
[11:58] <davecheney> yup
[11:58] <mgz> that used to default to false, but got switched to true for openstack
[11:59] <mgz> and that gets used but the openstack provider client,
[11:59]  * davecheney remembers ssh-hostname-verify
[11:59] <mgz> *and* also the curl for looking up the instance id on machine startup
[12:00] <davecheney> cocking nora
[12:00] <mgz> we should be able to do roughly that for gojuju... but we use the swift container for many more things, like tools,
[12:01] <mgz> and without checking, I'm not totally certain all the places where we might access provider storage we actually have the environment config
[12:02] <mgz> because some of that is now initiated from each machine, whereas it used to all be from the provisioner
[12:03] <davecheney> i guess the 'just turn it off everywhere' option is not acceptable ?
[12:04] <mgz> given the elling that made us flip the default for python, I think not
[12:04] <jam> davecheney: I would think the self-signed cert thing is High + papercut vs Critical
[12:04] <mgz> *yelling
[12:04] <jam> Critical == block the next release until fixed
[12:04] <davecheney> jam: feel free to change it
[12:04] <jam> davecheney: just running it by you rather than having an edit war on LP :)
[12:04] <davecheney> jam: don't care
[12:05] <jam> natefinch: I sent what is hopefully a point-by-point discussion about the installer. Mostly it seems like "good enough for now".
[12:05] <natefinch> jam: thanks, the feedback is very much appreciated
[12:05] <jam> I'll check with Mramm if it is appropriate to upload it to juju-core proper today.
[12:06] <jam> at least, if he shows up to my 1:1 this morning.
[12:06] <mramm> jam: seems reasonable to upload it
[12:09] <natefinch> mgz: I moved my cards around so they're up to date. I'll poke the red squad about azure creds so  I can do a sanity check on the azure code and land that today
[12:10] <mgz> ace, and added an intaller one, great
[12:18] <natefinch-afk> going to be in and out some today, kids stuff.
[12:30] <davecheney> TheMue: https://docs.google.com/a/canonical.com/document/d/1aEvcmxSJaj1i9zNjGy48yKF-SPlTFwW-NiKfoO_Ygo4/edit
[12:30] <davecheney> could you please document juju unset in the release notes
[12:30] <davecheney> ta
[12:30] <TheMue> davecheney: yep, will do
[12:33] <jam> natefinch-afk: quick comment, we probably won't release 1.13.2 as a windows installer because of the known bug against azure with public tools. (fixed in trunk)
[12:34] <davecheney> also, 1.13.3 is coming at the end of the week
[12:34] <jam> davecheney: right, so we'll probably wait for 1.13.3 to do a public -setup.exe
[12:34] <davecheney> jam: and then we get to have the discusion about 1.14 again :)
[12:35] <jam> davecheney: to be fair we have chatted about it a few times now :)
[12:37] <natefinch-afk> davecheney: gotcha
[12:37] <davecheney> jam: next time's the charm
[12:57] <wallyworld> fwereade_: hiya, if you have time, would be great if you could look at this to ensure it matches our discussions. i hope to land it tomorrow so i can progress the simplestreams stuff with andrew https://codereview.appspot.com/13278043
[12:58] <jam> TheMue: in talking with mramm he mentioned you'd likely be interested in being at the doc sprint on Friday. Is that still true?
[12:59] <jam> I can add you to the invite list so you get a reminder.
[12:59] <jam> hey wallyworld, how's your day been?
[13:00] <wallyworld> busy :-)
[13:00] <wallyworld> i know understand how horrible and hard charms are to write :-(
[13:00] <wallyworld> we so need to fix that
[13:01] <wallyworld> the mental model is difficult and there are so many ways to subtley shoot yourself in the foot
[13:01] <davecheney> warning: juju may contain traces of footgun
[13:01] <wallyworld> traces = copious quantities
[13:02] <TheMue> jam: i'm interested in supporting the documentation, yes. i only have some troubles on this friday as i would have to leave at about 8pm local time.
[13:02] <jam> TheMue: I don't think you are expected to be there the whole time
[13:02] <jam> but if you can be there during your work day that is still a great advantage.
[13:03] <TheMue> jam: yep, absolutely no prob. sounds fine to me
[13:25]  * rogpeppe goes for lunch
[14:45] <TheMue> hmmmpf
[14:52] <TheMue> my software does not like me. first two missed tests i forgot but now a panic on the bot while i have a never seen failing test (but no panic) here. *sigh*
[14:54] <TheMue> and now it passes again.
[15:07] <TheMue> fu..
[15:07] <TheMue> running the failing suite isolated it works, but with go test ./... it fails
[15:08] <mgz> that is not uncommon
[15:14] <TheMue> mgz: but also not nice
[15:19] <fwereade_> TheMue, added a couple of comments to your review
[15:20] <TheMue> fwereade_: thx
[15:21] <TheMue> fwereade_: who's best to contact in the GUI team?
[15:41]  * TheMue has to leave, bank appointment
[16:01] <hazmat> fwereade_, the relationcount, unitcount on respective states (service, and relation) are primarily used for txn condition guards ?
[16:09] <natefinch-afk> arosales, mgz: either of you guys know how to set up juju with azure? I don't see anything on juju.ubuntu.com
[16:11] <mgz> not really, but you can just read the comment in the source/autogenerated config
[16:12] <mgz> provider/azure/config.go
[16:12] <natefinch-afk> mgz: cool, thanks
[16:14] <natefinch-afk> man, the SSO for azure is buggy. It only works if I log in from particular websites
[16:15] <natefinch-afk> evidently I should "contact your admin and report the following error: 80045C17"
[18:03] <rogpeppe> hmm, how is it possible that provider.StartInstance and provider.StartBootstrapInstance have gone in without any tests?
[18:04] <jamespage> anyone from the juju team care to join the 'deliverying juju 2.0 into saucy' session?
[18:04] <jamespage> rogpeppe, fwereade_, mramm ^^
[18:05] <rogpeppe> jamespage: if that's happening now, i'm afraid i'm just reaching end of day, so can't without domestic consequences...
[18:06] <jamespage> mgz, ^^
[18:43] <rogpeppe> if anyone fancies a largish but pretty mechanical code review: https://codereview.appspot.com/13269045
[18:43] <rogpeppe> natefinch: ^
[18:43] <rogpeppe> and with that, i *must* leave!
[18:43] <rogpeppe> g'night all
[18:44] <natefinch> rogpeppe: I'll take a look.  Gnight
[18:47] <kvt> surprising number of tests work on osx (+ mongodb w/ ssl) nice
[18:50] <natefinch> kvt: that's awesome. not entirely surprising, but it would be great if we could get all the tests passing on OSX.  Ideally, we'd be able to run the tests on any platform juju supports.
[18:56] <hazmat> natefinch, there are a couple of lxc tests that make it barf
[18:57] <hazmat> the mongodb manual compilation  for ssl was a bit unfortunate/time consuming, required some patching of scons config files.
[18:57] <natefinch> hazmat: yeah. lxc is kind of a problem child for cross compatibility.   Still, if we can isolate that with OS compilation restrictions, that's ok.
[18:58]  * kvt nods
[18:58] <kvt> kvt == hazmat + osx ;-)
[21:02] <thumper> morning
[21:02] <thumper> fwereade_: you around?
[21:02] <fwereade_> thumper, heyhey
[21:02] <thumper> fwereade_: got time for a chat
[21:02] <thumper> ?
[21:02] <fwereade_> thumper, sure, just a mo, would you start one please?
[21:03] <thumper> sure
[22:54] <bigjools> hullo
[23:00] <thumper> hi bigjools
[23:01] <bigjools> hey man
[23:18] <mramm> thumper: bigjools: hey all
[23:18] <bigjools> g'day mramm
[23:18] <thumper> hi mramm
[23:19] <davecheney> axw: hey
[23:19] <davecheney> off da phone
[23:19] <davecheney> gonna check out of my room and i'll see you in mitchel
[23:19] <axw> davecheney: okey dokey. I'm down there now
[23:19] <axw> davecheney: they took the wifi off when I mentioned we had a meeting room
[23:20] <davecheney> fuckers
[23:20] <axw> davecheney: ?
[23:20] <axw> davecheney: I mean they didn't charge me
[23:21] <mramm> davecheney: that is good at least
[23:21] <davecheney> oh right
[23:21] <davecheney> i thought they *turned it off*
[23:21] <axw> hah :)  no sorry
[23:22] <axw> hey mramm, how's it going?
[23:22] <mramm> axw: pretty good
[23:22] <mramm> busy with all kinds of stuff for the other teams the last couple of weeks
[23:22] <mramm> seems like juju core land is running pretty well
[23:23] <axw> cool :)
[23:41] <sidnei> mramm: if i can get one bug in your prioritization radar, it'd be https://bugs.launchpad.net/juju-core/+bug/1190985 it's biting us madly :/
[23:41] <_mup_> Bug #1190985: Confusing update-charm and deploy -u behavior <juju-core:Triaged> <https://launchpad.net/bugs/1190985>


[12:01] <dseomn> http://bugzilla.ubuntu.com/show_bug.cgi?id=19404 is really easy to fix for anybody with access to the overides files and might cause a problem if somebody's offended
[12:02] <elmo> dseomn: overrides don't work for package descriptions
[12:03] <dseomn> oh, ok
[12:05] <daniels> in that case, the override is called an upload
[12:10] <Keybuk> syndicate udev-0.074%
[12:10] <Keybuk> syndicate udev-0.074% dpkg-deb -c ../udev-udeb_0.074-1_i386.udeb
[12:10] <Keybuk> drwxr-xr-x root/root         0 2005-11-08 18:04:50 ./
[12:10] <Keybuk> syndicate udev-0.074%
[12:10] <Keybuk> \o/
[12:10] <Keybuk> SMALLEST UDEB EVER!
[12:11] <Kamion> Keybuk: dude, that's practically normal
[12:11] <Kamion> plenty of udebs only have maintainer scripts and nothing else
[12:11] <Keybuk> this doesn't have those either :p
[12:11] <Keybuk> typing "udev" and "udeb" on the same line is *hard*
[12:26] <jordi> lifeless: yes, carlos has a contract somewhere
[12:51] <sabdfl> sivang: ping
[12:51] <elmo> does someone want to do deal with gimp-print vs. gutenprint?
[12:51] <elmo> pretty pls
[12:52] <daniels> elmo: define 'deal with'
[12:53] <elmo> gimp-print wants to be removed, gutenprint replaces it
[12:53] <elmo> gimp-print has ubuntu mods
[12:53] <elmo> our changes need either merged into gutenprint, or some needs to tell me to PUSH THE BUTTON and force-sync gutenprint
[12:54] <daniels> s/guten/gimp-/2 ?
[12:56] <elmo> daniels: err, I'm confused, if you mean in the line "has ubuntu mods", then no
[12:57] <daniels> i meant the last word of the third line
[01:02] <elmo> ok, still no.  gimp-print no longer exists in debian, it's been removed in favour of gutenprint
[01:02] <elmo> sorry, I'm obviously being exceedingly unclear
[01:02] <elmo> I blame cvd
[01:05] <\sh> elmo: hmmm..jul 02 debian-devel : gimp-print (renamed to gutenprint) means we have to merge it
[01:07] <\sh> elmo: and no...i don't have any clue about printing...I like the paperless office
[01:12] <\sh> and I wonder what our nameserver (running on hoary) is doing now
[01:12] <\sh> socket.c:1119: unexpected error:
[01:12] <\sh> The Severity is 5
[01:16] <Keybuk> right, just set off a "d" run of mom now
[01:18] <\sh> Keybuk: was it purpose the 0.1breezy1 or just a demonstration?
[01:18] <\sh> ?)
[01:20] <Keybuk> \sh: ??
[01:22] <\sh> breezy-changes
[01:22] <\sh> oh mdz was it
[01:27] <\sh> Keybuk: anyways...give me a small hint..if MoM removes something from the changelog entry...it means it's wrong http://people.ubuntu.com/~scott/ongoing-merge/ace/ace_merged.debdiff
[01:29] <Keybuk> just means it went a bit screwy
[01:29] <\sh> ok...manual interaction is needed
[01:29] <\sh> I hope it's only the changelog
[01:35] <Keybuk> right, nda seems to be running now too
[01:47] <robertj> anyone care to discuss the GnomeUserInterface for Ubuntu Express's Computer Name screen?
[01:48] <robertj> The RFC 1178 is err...interesting
[01:51] <\sh> damn...the first upload .. and forgot the -v for debuild gnarf
[01:53] <tsume> yi pyip yip :)
[01:59] <minghua> hmm, Keybuk uses a Chinese quit message
[02:04] <cevizoglu> which means " is absurd"
[02:06] <Toma-> how do you request a package to be submitted to multiverse?
[02:07] <daniels>  is probably the chinese  glyph for dpkg or something ;)
[02:09] <cevizoglu> hehe
[02:15] <\sh> elmo: time for syncs...or better mail to u ?
[02:16] <elmo> \sh: whichever
[02:16] <\sh> I'll mail it...there are a lot to come this night
[02:17] <minghua> no,  is something like "ridiculous enough"
[02:17] <minghua>  is an adverb
[02:18] <minghua> daniels: Chinese doesn't have a glyph for dpkg (yet) :-)
[02:39] <PukingGeko> does anyone know if ieee80211 wireless modems work out of the box with the 2.6.14 kernel?
[02:58] <mpt> d'oh
[03:00] <\sh> hehehe...merges and MOTU hopefuls...I feel like I'm an old fart
[03:01] <tseng> \sh: you are!
[03:01] <\sh> tseng: oh damn...u r right :)
[03:21] <wasabi_> darnit. evms is breaking on breezy. =(
[03:58] <pitti> Kamion, elmo: still here?
[04:05] <jdub> GOOD MORNING FREEDOM LOVERS!
[04:06] <pitti> Hey hey jdub
[04:06] <pitti> jdub: back to home or BBB?
[04:06] <pitti> jdub: s/to/at/
[04:39] <whiprush> jdub: "ryan" is ubuntu-geek right?
[04:40] <daniels> yeah
[04:40] <whiprush> thanks
[05:11] <jdub>   binfmt-support: Depends: lsb-base (>= 3.0-6) but 3.0-1ubuntu8 is to be installed
[05:11] <jdub> ^ dapper
[05:39] <Kamion> jdub: yes, I'll sort it out when I merge lsb, in the meantime tough :P
[05:39] <Kamion> I'm not diverging binfmt-support just for that - the changes are minor
[05:50] <mvo> elmo: please sync python-apt from debian/incoming (override our changes is ok)
[05:50] <daniels> urgh.  i much preferred montral's weather.
[05:51] <daniels> luckily it appears a ton of rain is on the way.
[06:09] <Mithrandir> elmo: please sync xmltex 1.9-11 from unstable into dapper.
[06:12] <mvo> Mithrandir: hi! do you also battle jetlag right now :) ?
[06:12] <daniels> mvo: yes ;)
[06:12] <Mithrandir> mvo: yes. :-)
[06:12] <mvo> daniels: hello! did you had a good trip back?
[06:13] <Mithrandir> I tend not to be in the office at 0530 on most days.
[06:13] <mvo> we should rename it to #ubuntu-jetlag
[06:13] <daniels> mvo: long but largely hassle-free
[06:13] <mvo> daniels: same for me (except not as long as yours :)
[06:17] <daniels> mvo: ah, cool.  you just got back lyesterday?
[06:18] <mvo> daniels: yes, I was at home around mid-day, but felt *so* sleepy for the rest of the day
[06:19] <daniels> heh
[06:25] <mvo> Mithrandir: when did you plane leave in montreal?
[06:25] <mvo> daniels: yeah, the trip was quite good because I was traveling with seb128, ogra and dholbach
[06:25] <Mithrandir> mvo: plane left at 1755, got home at ~1100 yesterday, spent most of the day trying not to fall asleep
[06:27] <daniels> mvo: oh, cool!
[06:29] <mvo> Kamion: do we use the aptitude patch for "--allow-unauthenticated" in the installer?
[06:33] <minghua> elmo: please sync libmath++ 0.0.4-2 from debian, all previous ubuntu changes should be dropped
[06:43] <wasabi> Um. Trying to redo mbr from rescue mode. grub complains about no tty.
[06:56] <freeflying_> anyone know smurf
[06:57] <Burgundavia> small blue man, happy, last seen being bombed in unicef commercial
[06:57] <zakame> buwahahaha
[06:58] <Burgundavia> freeflying, honestly, he lives in Europe and thus is likely to be asleep right now
[07:00] <freeflying_> Burgundavia: Who is in charge of LocalTeam besides him ?
[07:00] <Burgundavia> freeflying, no idea, sorry
[07:00] <freeflying_> Burgundavia: thanks
[07:03] <minghua> freeflying_: are you hinting that there is going to be some activities from ubuntu-zh team? :-)
[07:04] <freeflying_> minghua: your help is very important to us
[07:05] <freeflying_> minghua: so we need advice from you
[08:11] <poningru> I had a question
[08:11] <poningru> are we still looking for testing process?
[08:12] <poningru> has anyone looked into litmus?
[08:12] <poningru> deved by mofo?
[08:12] <poningru> err -?
[08:12] <poningru> http://litmus.mozilla.org/run_tests.cgi
[08:12] <poningru> http://ws314.juntadeandalucia.es/guadalinex2005/live_installer/default/
[08:12] <poningru> err
[08:12] <poningru> http://wiki.mozilla.org/Litmus
[08:19] <pef> hello
[08:55] <pef> elmo: hello, can you confirm me my upload of "mixxx" package to archive is successfull ? (exists in Debian, new in Ubuntu)
[08:55] <pef> elmo: thank you :)
[10:33] <siretart> elmo: I'm very sorry, I botched an upload to debian :( - won't happen again, promised
[10:34] <HiddenWolf> siretart, just fix it. ;)
[10:34] <siretart> HiddenWolf: no, it shouldn't go there at all, it is now in the incoming queue of debian :(
[10:35] <HiddenWolf> siretart, so find an ftp-master and have it killed.
[10:50] <Mithrandir> elmo: please sync pkg-config from unstable into dapper.  Ok to override Ubuntu changes.
[10:52] <siretart> elmo: please sync 3ddesktop and aalib from unstable into dapper, overriding ubuntu changes
[10:58] <Mithrandir> elmo: please sync norwegian from unstable.  Ok to override Ubuntu changes.
[11:12] <siretart> elmo: please sync lxdoom from unstable, Ok to override Ubuntu changes
[11:16] <janimo> why the sync requests? isn't this automatic (for universe at least) as at the beginning of breezy ?
[11:16] <Lathiat> janimo: If we have changes, the sync does not happen automatically
[11:16] <janimo> so MOM is not happening?
[11:16] <Lathiat> janimo: Obviously we don't want to tread on top of the local changes
[11:17] <janimo> then why the need to specify 'ok to override' ?
[11:17] <Nafallo> janimo: mom is happening and we want to remove our changes
[11:18] <Nafallo> janimo: (override *ubuntu*)
[11:18] <janimo> aha so sync already happened, and stuck in MOM and you want a resync?
[11:18] <janimo> just like with breezy then, I get it now
[11:18] <Nafallo> sync didn't happen, cause we had *ubuntu* for the package.
[11:19] <Nafallo> then mom got it and we want to have a sync dropping our *ubuntu*
[11:19] <janimo> hmm I understand a different thing by sync then :)
[11:19] <janimo> sync = bring from debian to MOM
[11:19] <janimo> aka step 1
[11:19] <Nafallo> nope
[11:19] <Nafallo> sync is bring from debian into archive :-)
[11:20] <janimo> I thought of sync as a best effort thing :)
[11:20] <janimo> nothing guarranteed
[11:20] <janimo> ok it's clear now thanks
[11:20] <Nafallo> no problemo :-)
[11:23] <siretart> elmo: please sync mail-notification from unstable, Ok to override Ubuntu changes
[11:24] <zyga> hello
[11:30] <Lathiat> ermm
[11:30] <Lathiat> we are still using bugzilla
[11:30] <Lathiat> for main stuff
[11:30] <Lathiat> right?
[11:31] <siretart> Lathiat: for now, yes
[11:37] <poningru> when will migration occur?
[11:37] <poningru> to launchpad that is
[11:38] <siretart> poningru: there are still some features missing in malone, like NEEDINFO and some others. It will be done as soon as it is possible and feasible
[11:38] <poningru> ok
[11:39] <dholbach> siretart: we do have needinfo now
[11:40] <siretart> dholbach: oh. whats missing then in malone?
[11:40] <dholbach> various filters
[11:40] <siretart> ah, okay
[11:40] <dholbach> like the equivalent of bugzilla's "filter only upstream bugs", although jamesh just wrote something about it
[11:40] <dholbach> might be implemented too
[12:10] <slomo> elmo: please move everything of ffmpeg back to universe ;)
[12:12] <HiddenWolf> slomo, is it multiverse now?
[12:13] <slomo> HiddenWolf: no... libpostproc-dev is in multiverse for no good reason now, everything else in universe
[12:23] <Mithrandir> elmo: please sync xrestop from Debian unstable, ok to override Ubuntu changes.
[12:30] <Mithrandir> elmo: please sync siege from Debian unstable.  Ok to override Ubuntu changes.
[12:44] <\sh> elmo: please sync alleyoop form Debian unstable, Ok to override Ubuntu changes
[12:45] <Mithrandir> elmo: please sync debtags from Debian unstable.  Overriding Ubuntu changes is ok.
[01:11] <HiddenWolf> Mithrandir, you're on a roll, aren't you? ;)
[01:12] <Mithrandir> HiddenWolf: I'm almost falling asleep so it's better to do a bit of brainless work.
[01:12] <Treenaks> wanking!
[01:14] <dholbach> elmo: could you please sync atk1.0 from sid? ok to override ubuntu changes
[01:55] <mvo> elmo: please sync w3m from debian (override ok)
[01:59] <seb128> Mithrandir: any opinion on https://bugzilla.ubuntu.com/show_bug.cgi?id=18819 ?
[02:02] <HiddenWolf> guys, that expired certificate on bugzilla is bugging me. :P
[02:35] <mvo> elmo: please sync nmap (override ok)
[02:57] <dholbach> elmo: could you please sync dia from sid, ok to override changes
[02:58] <rob^^^> dholbach: btw, do you know of any reason not to default dia to anti-aliased?
[03:00] <dholbach> rob^^^: no idea
[03:03] <dholbach> elmo please sync at-spi from sid, ok to override
[03:04] <jsgotangco> hi
[03:18] <Keybuk> BeeeeeeeeeeeeeeeeeeeeeeeeeeeeeenC!
[03:19] <siretart> hi Keybuk
[03:19] <Keybuk> siretart: hey
[03:19] <the--dud> isnt benc that dvd-rw taiwan manufacturer?
[03:19] <the--dud> or something like that
[03:28] <siretart> elmo: thanks for the syncs. by chance, did you find some time to get my key added?
[03:31] <mvo> can someone please double-check that we can sync emacs21 (ubuntu #19169)? it looks all our changes are in debian now
[03:44] <jbailey> Riddell: Question for you, is there a kubuntu-artwork package of some sort?
[03:45] <Riddell> jbailey: no, it's all in kubuntu-default-settings
[03:45] <jbailey> Riddell: So from a branding POV, if someone wnated to make a Kubuntu derivative, is that and kubuntu-docs the two packages they would have to frob?
[03:46] <Riddell> yep
[03:46] <jbailey> Riddell: Thanks.
[03:47] <Riddell> I'd recommend they make a foo-default-settings and change /etc/kderc to point to their directory too so they are just overriding kubuntu's settings for the stuff they want
[03:47] <jbailey> But those are sysadming settings.  For someone producing a derivative and shipping it, that looks like it would be the wrong place to touch things.
[03:48] <jbailey> You don't want it to give annoying conffile warnings on each upgrade of the package.
[03:49] <Riddell> well the alternative is to throw out kubuntu-default-settings and not get all my great KDE tweaks (also kdm depends on kubuntu-default-settings unfortunatly)
[03:49] <jbailey> Right, but that's the same with ubuntu-artwork.
[03:50] <jbailey> If they touch that, they'd lose the Human theme, the sounds, etc.
[03:50] <jbailey> I think so far we assume that anyone doing a derivative is competant enough to know that.
[03:50] <jbailey> And it localises the changes they need to do to one package easily.
[03:54] <Simira> Mithrandir : you promised to get home early today!
[03:54] <siretart> huhu Simira :)
[03:55] <Simira> haha
[03:56] <Simira> siretart : we're still kind of on canadian time, so he left for job pretty early today.
[03:56] <jbailey> "Canadian time"? =)
[03:57] <jbailey> You know we have 5.5 timezones here, right? =)
[03:58] <Simira> jbailey :p Well, we've only been to one of them
[03:58] <desrt> i think that number is a little bit low
[03:59] <siretart> jbailey: I see that you create daily .debs of bzr in http://people.ubuntu.com/~jbailey/snapshot/bzr/, would you object to have the latest release of bzr in dapper?
[04:00] <siretart> jbailey: that means, If you don't object, I'd like to upload bzr 0.6 to dapper, based on your packaging work
[04:00] <pitti> Mithrandir: ping
[04:01] <Mithrandir> pitti: pong
[04:01] <pitti> Mithrandir: wrt cfengine, shall we throw cfengine-doc out of the seeds? or promote cfengine?
[04:02] <Mithrandir> pitti: I think promoting cfengine2 would be a good thing, and throw cf1 out.
[04:02] <pitti> Mithrandir: can you write a main inclusion report for cf2 then?
[04:03] <Mithrandir> boooing
[04:03] <Mithrandir> pitti: I'm going home now, but yes, I'll do that.  Mail me, please?
[04:03] <Simira> (pretty empty sound, eh?)
[04:03] <pitti> Mithrandir: k
[04:03] <Simira> Mithrandir : buy dinner!
[04:04] <siretart> magnon: did you notice, pitti has uploaded a the new jackd to dapper, so we can start that transition
[04:04] <magnon> yes I did :)
[04:04] <magnon> he told me
[04:04] <siretart> great :)
[04:04] <magnon> I will look at it when I get back tonight I guess
[04:04] <magnon> but now, time for board meeting in the party
[04:04] <siretart> oh. have fun there!
[04:05] <magnon> thxbye. :)
[04:14] <sivang> Mithrandir: you know anything about the Zope3 Packages?
[04:14] <Mithrandir> no
[04:14] <sivang> Mithrandir: ok
[04:20] <rob^^^> https://wiki.ubuntu.com/UbuntuExpress/GnomeUserInterface <- any thoughts on that suggestionf or combining steps?
[04:21] <ogra> elmo, ping
[04:24] <elmo> ogra: ?
[04:25] <ogra> elmo, something weird seems to have happened to sdl-mixer, could you kick it to trigger a build ?
[04:25] <elmo> ogra: no, talk to infinity or lamont, they handle the buildds
[04:26] <ogra> ok
[04:26] <ogra> infinity, ping ?
[04:29] <infinity> Pong!
[04:29] <infinity> sdl-mixer?
[04:29] <infinity> Looking.
[04:29] <ogra> infinity, greta, thanks
[04:30] <ogra> seems there was a race with smpeg at build time
[04:30] <seb128> infinity: please kick sound-juicer build
[04:30] <seb128> infinity: it failed because of gnome-media beeing not installable which is fixed
[04:31] <jbailey> siretart: 0.6 doesn't work.
[04:31] <infinity> seb128 : I think I'm going to do a mass-give-back soon anyway, since half the GNOME build-dep chain was uninstallable until yesterday.
[04:32] <jbailey> siretart: mpool gave me an 0.6.1 last night to try intead, haven't done it yet.
[04:32] <infinity> seb128 : I can't be bothered to track down what failed because of it.
[04:33] <siretart> jbailey: okay, so I assume you are at it. thanks
[04:33] <jbailey> siretart: Slowly, but yeah. =)
[04:34] <mvo> elmo: can you please sync python-apt from debian incoming (override ok)?
[04:34] <ogra> infinity, hmm... actually it seems i'm still to jetlagged and did read the buildlogs wrong, no race there... but sdl-mixer isnt in dapper
[04:34] <seb128> infinity: half of GNOME, I've looked some days ago on it and it was like 5 packages
[04:35] <mvo> any emacs-lover here who wants to have a second look on it before I request a sync?
[04:35] <ogra> sdl-mixer1.2 to be precise
[04:36] <siretart> mvo: I'm on xemacs ;)
[04:36] <sbalneav> ogra: whenever you get un-jetlagged, let me know, and we can talk about what mods need to be added to ltspfs to tie in with the spec.
[04:36] <mvo> siretart: did you had a good trip back?
[04:36] <wasabi_> jbailey: howdy
[04:37] <ogra> sbalneav, give me 1-2 days to sort my stuff here ... i also have to get it approved first
[04:37] <siretart> mvo: yes, the jetlag is still a bit annoying, but I'm fine. could sleep a bit in the plane. How was your trip back?
[04:37] <jbailey> wasabi_: Heyhey!  You pinged me yesterday for something /me looks
[04:37] <wasabi_> yeah
[04:37] <jbailey> Right!
[04:37] <jbailey> evms.
[04:37] <wasabi_> Yeah!
[04:38] <wasabi_> Any thoughts?
[04:38] <jbailey> evms is love, I agree.  Except that it ate my ppc partition table once and integrates poorly with the installer. =)
[04:38] <wasabi_> Ah hah.
[04:38] <sbalneav> ogra: no sweat.  From now on I'll be idling on both #ltsp and #ubuntu-devel, so you'll know where to find me.
[04:38] <Robot101> hahahaha gaim are using linphone libraries to implement googlt talk
[04:38] <wasabi_> What about using EVMS purely for activation of LVM and MD?
[04:38] <wasabi_> vs using mdadm and evms and lvm
[04:38] <ogra> sbalneav, oki... :)
[04:38] <wasabi_> Other wise, if evms is enabled, it should proactively disable lvm and md.
[04:39] <mvo> siretart: mostly good, the flight itself was a bit bumpy for 30min, but otherwise it was fine (but I feel still pretty jetlaged)
[04:39] <wasabi_> And include the md evms plugin in the initrd.
[04:39] <Kinnison> I thought device-mapper was meant to be integrating everything?
[04:39] <jbailey> wasabi_: Hmm.  The biggest problem there is that I don't think evms puts the nodes in /dev/mapper
[04:39] <wasabi_> device mapper is the kernel portion, but a user space utility has to set it up
[04:39] <jbailey> wasabi_: So that may break existing setups and require people to transition again.
[04:40] <wasabi_> hmmm
[04:40] <wasabi_> i thought it did
[04:40] <wasabi_> mine are in here.
[04:40] <jbailey> wasabi_: Feel free to tell me I'm wrong. =)
[04:40] <dholbach> see you
[04:40] <jbailey> g'n Daniel
[04:40] <jbailey> infinity: *poke*
[04:41] <jbailey> infinity: This involves you more than me now. =)
[04:41] <siretart> evms annoyed me a lot because it insisted on taking control over the partition table on devices handled by evms. lvm does not have such a restriction :/
[04:42] <wasabi_> Hmmm. You might be thinking about the older evms.
[04:42] <jbailey> siretart: Right.  With evms you have a choice of whether the partition is a pure evms partition (with crazy magic on it), or whether evms is just being nice and doing lvmish things for you.
[04:42] <wasabi_> evms2 is non kernel based.
[04:43] <wasabi_> It's just a user space library now that maps everything thru d-m
[04:43] <jbailey> The power of evms really comes when it can add its signatures to the partitions so that it can map them reliably.
[04:43] <wasabi_> Yeah, but it doesn't HAVE to do that.
[04:43] <jbailey> But otherwise it'll cheerfully just assemble other devices as it sees fit.
[04:43] <jbailey> Right. =)
[04:44] <jbailey> Keybuk: Hey.  It occurs to me that evms has the partition reading code already in userspace.
[04:44] <wasabi_> It will scan physical disks for md metadata, activate them
[04:44] <wasabi_> then scan everything for lvm metadata, activate them.
[04:44] <jbailey> Keybuk: Forcing evms for a scan might be a way of getting the partition table reading code out of the kernel.
[04:44] <wasabi_> and then scan everything else for evms metadata and activate those.
[04:44] <wasabi_> but it doesn't require evms metadata anywhere.
[04:44] <siretart> well, the last time I used it, I found it very confusing and annoying. I didn't find a rescue cd that time, to reassemble broken software raid setups, so I run away
[04:44] <wasabi_> I know that evms1 was pretty bad.
[04:44] <wasabi_> Which is why linus wouldn't accept it.
[04:45] <wasabi_> So they rewrote it in user space.
[04:45] <jbailey> siretart: Yeah, it's much better this time.
[04:45] <wasabi_> Now it's just a nice library/ui to manage all these different pieces: md, lvm
[04:45] <jbailey> wasabi_: I suspect that forcing evms is a bit much for dapper, really.
[04:45] <jbailey> It would make a good dapper+1 target.
[04:45] <wasabi_> Yeah... well, you see my specific case yesterday anyways.
[04:46] <wasabi_> If I do choose to use evms, they all step on each other.
[04:46] <jbailey> wasabi_: Right.  In this case I run each set of stuff based on looking at the ROOT= bit and guessng.
[04:46] <wasabi_> So maybe they should at least be mutually exclusive.
[04:46] <wasabi_> Yeah.
[04:46] <wasabi_> If ROOT#/dev/evms, disable md and lvm.
[04:47] <wasabi_> and do include the md evms plugin in the initrd.
[04:47] <jbailey> Well.  It only activates evms is the ROOT= is set to /dev/evms/FOO IIRC
[04:47] <wasabi_> Yeah, but evms depends on lvm
[04:47] <wasabi_> and lvm depends on md
[04:48] <jbailey> Only in the sense that the scripts have to be ordered.
[04:48] <jbailey> If evms gets to them first, lvm and md can't do their jobs.
[04:48] <jbailey> and md has to come before lvm in case the volume is spread across more than one disk.
[04:48] <wasabi_> and vica versa.
[04:48] <jbailey> I do agree that it would be nice to have sexier handling than can be gracefully provided in shell. =)
[04:48] <wasabi_> Was the evms md plugin left out for a reason?
[04:49] <jbailey> I WILL NOT STOP UNTIL I HAVE A SCHEME INTERPRETOR WRITTEN IN SHELL IN THE INITRAMFS!
[04:49] <jbailey> err.
[04:49] <jbailey> dontmindme
[04:49] <wasabi_> heh.
[04:49] <jbailey> wasabi_: Yes.  It's huge and we already have mdadm
[04:49] <wasabi_> But you might not be using mdadm with evms.
[04:49] <jbailey> wasabi_: It was the fight to try and get the size seriously reduced.
[04:50] <sladen> not sure about scheme.  But forth in the initramfs would absolutely rock
[04:50] <wasabi_> Well, I need to examine this system.
[04:50] <jbailey> Kinnison: Nah, I figure doing a read loop to split the string, then feeding it to a case stamement might just work enough. =)
[04:50] <wasabi_> What I know is that evms did not work until I added evms md plugin to the initrd and removed mdadm
[04:51] <jbailey> wasabi_: ah right, the other thing that came up was that mdrun assembles devices differently than mdadm --auto did.
[04:51] <jbailey> I suspect that md.o would preserve the behaviour off mdadm (which is certainly the correct one)
[04:51] <wasabi_> Yeah, sometimes does it in a different order.
[04:51] <wasabi_> so if you have two md's, they switch from md0 to md1
[04:51] <wasabi_> Which, metadata wise, is fine.
[04:51] <jbailey> But that shouldn't change for Dapper at all.
[04:52] <wasabi_> mdadm however has hard coded names in /etc/mdadm or whatever
[04:52] <jbailey> No.
[04:52] <jbailey> mdadm is able to detect them automatically no.
[04:52] <jbailey> +w
[04:52] <wasabi_> DEVICE partitions
[04:52] <wasabi_> ARRAY /dev/md0 level=raid0 num-devices=2 UUID=6b8b4567:327b23c6:643c9869:663348$   devices=/dev/sdb3,/dev/sda3
[04:52] <Kinnison> Hmm, a fully static lua50 interpreter with all the libs is 553k
[04:52] <wasabi_> That looks hard set to /dev/md0 to me
[04:52] <jbailey> There's metadata in there that suggests the MD number to set.
[04:53] <Kinnison> 112k without libc
[04:53] <Kinnison> and you could halve that without the libraries you don't need
[04:53] <infinity> Keyword: suggests.  It doesn't have to listen to you.
[04:53] <infinity> sladen : I will not put forth in initramfs, for purely religious reasons.
[04:54] <Keybuk> Kinnison: libc is generally "useful"
[04:54] <Kinnison> Keybuk: I assume initramfs has klibc though, so I don't have to -static
[04:54] <Keybuk> I suspect we'll drop klibc as a failed experiment
[04:55] <infinity> initramfs has both klibc and glibc currently, actually. :/
[04:55] <Kinnison> oh dear
[04:55] <ogra> ugh
[04:55] <Keybuk> as soon as you have one application you need in initramfs that won't compile against klibc, you've not only lost all of the benefit of klibc but actually made things worse by having two libcs

[04:56] <jbailey> Kinnison: Possibly.  glibc pulls in all the i18n machinery if you include a single output statement.
[04:56] <Keybuk> and as you get those apps to compile against klibc, the size of klibc approaches glibc
[04:57] <Keybuk> it might be better to build a minimal glibc without all that locale crap
[04:57] <jdub> yeah man, locales are for girls
[04:57] <infinity> mini-glibc?
[04:58] <infinity> I'd sign up for that as a solution.
[04:58] <Keybuk> girls and cheese-eating surrender monkeys
[04:58] <jbailey> In my spare time I can see if glibc still builds with the i18n machinery disabled.  I doubt it would, but it might be anicer hack than klibc.
[04:58] <sivang> lol
[04:59] <Keybuk> we could have a mini-Ulrich to go with it, who only rants a little bit

[04:59] <infinity> I'll register a mini-LJ account right now.
[05:00] <Robot101> rofl
[05:02] <jbailey> That's not fair.  Ulrich doesn't rant that much.  Mostly he ignores emails.  You have to be special to actually get ranted at.
[05:04] <HiddenWolf> Bij de epidemie op de Bible-belt raakten ook zwangere vrouwen besmet. Intussen zijn zeven van hen bevallen. Drie kinderen zijn geboren met een ernstig handicap, een ander kind is doof.  :P
[05:07] <madduck|msg_me> dilinger: vistaprint.co.uk makes free business cards, in case you want to cut your losses. sorry for the adv, no affiliation.
[05:16] <davyd> can someone check my dpkg-divert syntax? dpkg-divert --divert /usr/share/icons/.../distributor-logo.png.no-ubuntu-logo --rename --add /usr/share/icons/.../distributor.logo
[05:16] <madduck|msg_me> does it work?
[05:16] <madduck|msg_me> looks good.
[05:16] <davyd> according to me, that moves the icon to /u/s/i/h/4/a/distributor-logo.png.no-ubuntu-logo
[05:16] <davyd> which is seems to
[05:16] <davyd> but somehow
[05:16] <davyd> panel keeps finding it
[05:16] <davyd> it works on one machine, but not the other
[05:17] <madduck|msg_me> is this in postinst?
[05:17] <madduck|msg_me> dpkg-divert is weird. it's not a renamer...
[05:17] <madduck|msg_me> it's a renaming rule.
[05:17] <davyd> this is just something I ran, to make that icon go away
[05:17] <davyd> but to allow dpkg to still find the file
[05:20] <madduck|msg_me> here, this is the section from my book: http://rafb.net/paste/results/Wsh3Aa69.txt
[05:21] <madduck|msg_me> specifically:
[05:21] <madduck|msg_me> \footnote{The exact behaviour is that if
[05:21] <madduck|msg_me> a package \package{foo} diverts a file \package{bar}, \programme{dpkg} will
[05:21] <madduck|msg_me> only allow \package{foo} to write to the location of the original \file{bar}
[05:21] <madduck|msg_me> file. If any other package writes to the file, the access is diverted.}.
[05:23] <Simira> madduck|msg_me!
[05:23] <madduck|msg_me> Simira!
[05:23] <davyd> aah, it seems that I had a icon cache file
[05:34] <ogra> infinity, can you give back gcompris please, seems all build-deps are fulfilled (they weren't at sync time) ...
[05:37] <infinity> ogra : It already has been given back, unless you mean it's failed in the last hour..
[05:37] <ogra> infinity, ooohhh, thanks ...
[05:38] <infinity> Hrm, oh, it has failed in the last hour. :)
[05:38] <infinity> In fact, it failed 7 minutes ago.
[05:38] <infinity> sdl-mixer/smpeg.  I guess I'll have to manually intervene there in a bit,
[05:39] <ogra> strange
[05:39] <ogra> my pbuilder builds it fine over here
[05:40] <infinity> I hate to sound like a broken record, but do you have universe in your sources.list?
[05:41] <ogra> yes ...
[05:41] <ogra> ah... smpge has only the dev parts in main iirc ...
[05:41] <ogra> *smpeg
[05:41] <infinity> Bingo.
[05:42] <ogra> hehe... silly me
[05:42] <infinity> Is this a newly-introduced build-dep, or did smpeg change?
[05:43] <infinity> If the former, evaluate if you need it, if the latter, get the archive sorted. :)
[05:45] <ogra> gcompris needs it
[05:47] <infinity> I assume nothing actually needs to be seeded, anastasia probably just needs to be run.
[05:47] <infinity> elmo : Does anastasia have anything to say about smpeg?
[05:47] <ogra> i have no idea why it went to universe ...
[05:49] <elmo> infinity: promotoed
[05:49] <elmo> ogra: because things go to universe by default
[05:50] <infinity> elmo : Ta.
[05:50] <ogra> elmo, sdl-image1.2 build-depends on libsmpeg-dev, which in turn depends on libsmpeg ...
[05:51] <ogra> elmo, so i would think its pulled in through this
[05:51] <infinity> ogra : Yes, and anastasia picks that up (thanks to germinate), and elmo promotes it manually.
[05:51] <infinity> ogra : When NEW packages are uploaded, they go to universe, until someone manually intervenes.
[05:51] <ogra> ah, i see... i thought it was promoted in dapper, since gcompris built fine there
[05:51] <infinity> ogra : To prevent, say, you syncing something from Debian with crazy added biuld-deps, and having the world auto-promoted without anyone noticing.
[05:52] <ogra> this is no new build-dep...
[05:52] <elmo> like, say, abiword, MICHAEL
[05:52] <ogra> it was there before
[05:52] <infinity> ogra : SONAME bump in the library would be mhy assumption in this case (hence, a new package name)
[05:52] <elmo> ogra: dude, no it wasn't, stop arguing
[05:53] <ogra> elmo, i'm not arguing, i'm wondering ...
[06:02] <pitti> elmo: is/was the changelog scanning on rookery down? It's missing some recent updates
[06:02] <elmo> pitti: I've no idea, mvo runs it
[06:02] <pitti> mvo: ^
[06:02] <mvo> pitti: I can have a look
[06:03] <pitti> mvo: e. g. http://changelogs.ubuntu.com/changelogs/pool/main/libu/libungif4/libungif4_4.1.3-1ubuntu0.1/changelog
[06:32] <pitti> elmo: can you please sync adduser aspell-bn aspell-pt aspell-sv awstats cpio cvs grep-dctrl linux-wlan-ng pcre3 ?
[07:59] <\sh> elmo: please sync alsamixergui from debian unstable, override ubuntu changes ok
[08:48] <\sh> elmo: please sync alexandria from debian unstable, override ubuntu changes ok
[08:51] <slomo_> elmo: please sync aatv from debian/unstable... ubuntu changes can be dropped
[08:58] <slomo_> elmo: and please sync avahi from debian/experimental... thanks :)
[09:13] <slomo_> jdub: ping?
[09:20] <Amaranth> that rick guy is kinda clueless...
[09:21] <slomo_> infinity, lamont-away: please remove fox1.4 from dep-wait... it's fixed with the latest upload
[09:31] <bradb_> seb128: I just sent you an email directly telling you that Nov 11th is a holiday in Canada too. Enjoy!
[09:31] <seb128> bradb_: thanks ;)
[09:32] <bradb_> :P
[09:32] <seb128> bradb_: quick malone question, is there a "unknown" package for it?
[09:32] <bradb_> seb128: nope, just empty
[09:32] <bradb_> seb128: is there a reason to create an explicit "unknown" package, rather than just leave it empty?
[09:32] <seb128> bradb_: somebody assigned a bug to gnome-games because the corresponding package is not known by malone (probably launchpad)
[09:33] <seb128> bradb_: no, I just didn't figured how/where to reassign, I've tried to set "unknow" as package as we do with bugzilla
[09:33] <bradb_> you could just unset the package field
[09:33] <seb128> then "Ubuntu" since I thought I showed you a bug assigned to "Ubuntu" some day ago
[09:34] <seb128> and then I just closed the window figuring I'm not malone expert to do this :p
[09:34] <seb128> k, thanks
[09:34] <seb128> I'll do it and remember for next time :)
[09:34] <seb128> s/to do/enough to do/
[09:36] <jdub> slomo_, pong
[09:37] <slomo_> jdub: i've updated the gnome-user-share package to new upstream... with avahi instead of howl now... do you still want to be set as maintainer?
[09:38] <slomo_> jdub: i ask as the package was removed for breezy and maybe you don't care about it anymore
[09:38] <Chipzz> .win 28
[09:39] <jdub> slomo_, happy for it to be taken over
[09:39] <\sh> elmo: please sync alexandria from debian unstable, override ubuntu changes ok
[09:40] <slomo_> jdub: ok... so you don't want it anymore? i'll upload it then tomorrow... is there something that needs to be done to get it uploaded again (maybe elmo needs to remove it from some list)?
[09:41] <seb128> slomo_: oh, you are updating shared-admin?
[09:42] <seb128> s/shared-admin/gnome-user/share/
[09:42] <slomo_> seb128: yes... dholbach asked me this morning ;)
[09:43] <seb128> slomo_: cool, thanks
[09:43] <slomo_> seb128: np :)
[09:46] <seb128> elmo: libgnomecups sync please
[09:51] <seb128> elmo: gtksourceview too
[09:58] <daniels> great, discover1 is utterly broken
[09:59] <seb128> pitti: are you going to make a promotion page for gtkmathview ?
[10:00] <pitti> seb128: because of abiword?
[10:00] <pitti> seb128: seems like an easy case
[10:00] <seb128> pitti: yeah
[10:00] <seb128> abiword FTBFS due to it atm
[10:01] <seb128> fmtutil-sys: /var/lib/texmf/web2c/pdflatex.fmt installed.
[10:01] <seb128> Error: `tex -ini  -jobname=xmltex -progname=xmltex &latex xmltex.ini' failed
[10:06] <janimo> daniels, wan't discover1 meant to be deprecated? IIRC even during hoary there were talks about that
[10:07] <daniels> janimo: xserver-xorg still uses it
[10:07] <seb128> evil xorg
[10:08] <janimo> I know, I meant there was some talk about unifying xorg hw detection with the rest of the world
[10:09] <daniels> heh, yeah
[10:11] <janimo> daniels, unrelated: do you think fixing the X600/700 ati sigills is too risky for breezy-updates? (#17421)
[10:12] <slomo_> elmo: please sync avahi from debian experimental
[10:12] <seb128> slomo_: are you interested in avahi?
[10:13] <slomo_> seb128: sure... why do you ask? :)
[10:13] <daniels> janimo: tbh I'm not *entirely* sure how
[10:14] <daniels> janimo: but trust me, it's very much on my radar
[10:15] <janimo> isn't the patch attached enough?is it more complicated?
[10:15] <seb128> slomo_: because there is a spec about it and it will require some work before beeing accepted for dapper
[10:15] <seb128> slomo_: so if you want to contribute you are welcome :)
[10:15] <slomo_> seb128: yes i know the spec ;) i already told Lathiat some months ago that i can help with some stuff if he needs help on that spec...
[10:16] <daniels> janimo: oh, hmm
[10:16] <daniels> janimo: if that disables acceleration, then something is *seriously* wrong
[10:17] <seb128> slomo_: I've worked on the draft of the spec during UBZ, but Keybuk was not quite happy with it so it has been bounced back to draft
[10:17] <janimo> I think it is just the revert of what went into -75
[10:18] <janimo> so it is accelerated and working as in hoary
[10:18] <daniels> janimo: err, unless I'm very much mistaken, it's disabling acceleration that fixed it, and enabling it that breaks it
[10:18] <daniels> -    if (!xf86ReturnOptValBool(info->Options, OPTION_NOACCEL, FALSE)) {
[10:18] <daniels> +    if (!xf86ReturnOptValBool(info->Options, OPTION_NOACCEL, info->NoAccel)) {
[10:18] <daniels> that's original -> current
[10:18] <daniels> so if NoAccel is FALSE, then we're going with standard behaviour, i.e. enable acceleration
[10:19] <daniels> if it's TRUE, then we're disabling acceleration
[10:19] <janimo> lemme look again, double negations make my head spin
[10:20] <daniels> yeah
[10:20] <daniels> or triple, in this case
[10:20] <daniels> (negation of the function, NoAccel, then negation of that if you use FALSE)
[10:20] <slomo_> seb128: i'll think about solutions for the issues that are mentioned on the page... is someone already working on zeroconf (the application?) and what issues are with it?
[10:21] <janimo> all i know that NoAccel shoul be set TRUE for the X300 chips but not for X600 ones
[10:21] <daniels> hrm
[10:21] <seb128> slomo_: no
[10:21] <daniels> the feedback I was getting was that setting NoAccel fixed everything
[10:21] <janimo> so I wrote the NoAccel = FALSE just to replace the TRUE and keep the patch non-fuzzy, otherwise that if is not needed
[10:21] <daniels> right
[10:22] <daniels> but yeah, looking at the logs, if it segfaults in XAA setup, then surely we're walking the acceleration path
[10:22] <janimo> yes, NoAccel worked around the crash but made it slow
[10:22] <janimo> then the real fix was reverting the -75 change
[10:22] <janimo> I proposed the noaccel as a stopgap in the first day
[10:23] <janimo> s it should be acceled and it works that way on this chip as confirmed by a X700 owner too IIRC
[10:28] <daniels> hrm
[10:28] <daniels> which -75 change; just patch #025?
[10:30] <janimo> daniels, yes
[10:30] <daniels> janimo: hrm
[10:30] <janimo> I suppose I did not find the wholl 75 change
[10:30] <janimo> is there a place I can see the diffs between 75 and 76
[10:31] <janimo> actually -76 change the one blacklisting X300
[10:31] <janimo> but which also blackliste X600
[10:32] <janimo> I just assumed it was all confined to #025 as mucking with that fixes it
[10:33] <daniels> yeah, it's weird
[10:33] <daniels> i'm just looking at the diff now
[10:34] <janimo> btw why SIGILL? I understand it happened on some P2-s but doesn;t P-M include all instructions of previous CPUs?
[10:35] <daniels> so I'm wondering whether building it unoptimised (during the build, cd programs/Xserver/hw/xfree86/drivers/ati, edit the Makefile, remove all -O2 and replace with -O0) won't help
[10:36] <janimo> but changing the optimization flags will still leave X600 with NoAccel true  I assume?
[10:37] <janimo> so it will run but be slow
[10:38] <daniels> i'm just trying to narrow it down to something that crashes and something that doesn't
[10:38] <daniels> so if leaving that patch in (the one from -76) and having an optimised build breaks, and leaving the patch in and not having an optimised build works, then we've found our problem
[10:39] <janimo> by works you mean accelerated?
[10:39] <janimo> or just does not crash
[10:39] <daniels> not crash
[10:39] <daniels> not having accel sucks, but it's not fatal; crashing on start is, so I'm trying to work out what's causing that first
[10:39] <janimo> but that will still be a regressiojn from hoary
[10:40] <daniels> sure, but a less crap one.  one issue at a time; the bug is already confused enough as is.
[10:40] <janimo> I agree that my patch just avoids this card trigerring a deeper bug
[10:40] <daniels> one other thing to try I guess is changing the definition of NoAccel in radeon.h from Bool to int
[10:41] <janimo> so should I try the -O2 trick and then the Bool->Int one?
[10:42] <janimo> It's midnight here, I may try now, if not tomorrow morning, and update bugzilla
[10:42] <daniels> janimo: try Bool to int first, then -O2
[10:42] <daniels> janimo: okay, thanks
[10:42] <janimo> ok
[10:45] <janimo> You mean this in radeon_driver.c ? { OPTION_NOACCEL,        "NoAccel",          OPTV_BOOLEAN, {0}, FALSE },
[10:45] <janimo> I see no NoAccel in radeon.h
[10:47] <daniels> in #025
[10:47] <janimo> aha
[10:50] <mjg59> daniels: Of course, my X300 stopped crashing shortly before the end of the Breezy cycle
[10:50] <mjg59> I need to test it with Breezy final, but -3 days it seemed to work and be fast
[11:07] <mvo> elmo: please sync emacs21 from debian (override ok)
[11:08] <seb128> elmo: please sync gnome-common gnome-keyring
[11:15] <pitti> mvo, seb128: I just finished the sudo patch for testing a command
[11:15] <pitti> unfortunately upstream's patch did not work
[11:17] <seb128> why ?
[11:17] <pitti> seb128: too far away from the stable release
[11:17] <pitti> seb128: and it was huuuge
[11:18] <pitti> seb128: now I added a -t option and simply just exit with the test result instead of executing the command
[11:18] <pitti> seb128: small patch
[11:18] <mvo> pitti: nice
[11:18] <Amaranth> i thought you could just see if the user was in a certain group
[11:18] <Amaranth> all sudo users are in the admin group, aren't they?
[11:18] <pitti> Amaranth: no, that's not general enough
[11:18] <pitti> Amaranth: no
[11:18] <seb128> Amaranth: no
[11:19] <pitti> Amaranth: you can give certain users only certain restricted privs
[11:19] <seb128> Amaranth: where is your new menu editor?
[11:19] <seb128> pitti: cool
[11:19] <Amaranth> seb128: I currently have no computer to finish the package on, for complicated reasons
[11:20] <Amaranth> none of them hardware releated
[11:20] <Amaranth> err, related
[11:20] <seb128> hum
[11:20] <seb128> you pointed a package when I was at UBZ
[11:20] <seb128> and you have destroyed this one now?
[11:20] <Amaranth> and you didn't like it
[11:20] <Amaranth> no
[11:20] <Amaranth> bob2 was working on an ITP for debian, i think
[11:20] <seb128> I've not said I didn't like it
[11:20] <seb128> there is like 2 points to change
[11:20] <seb128> if I get the tarball I can update smeg to it in 5 min
[11:21] <Amaranth> tarball?
[11:21] <Amaranth> you mean the orig and diff?
[11:21] <seb128> you know, what upstream ship
[11:21] <seb128> sources
[11:21] <Amaranth> ah
[11:21] <seb128> no, if you have no package I don't really care
[11:21] <Amaranth> brb
[11:21] <seb128> updating from the current smeg package takes like 5 min
[11:22] <seb128> just point a tarball of the sources
[11:22] <seb128> bob2_: are you packaging smeg for deb?
[11:27] <Amaranth> http://dev.realistanew.com/alacarte/releases/0.8/alacarte-0.8.tar.gz
[11:27] <seb128> Amaranth: thanks
[11:27] <Keybuk> http://www.netsplit.com/2005/bootchart-dapper-20051109-1.png
[11:27] <Keybuk> ^ shiny
[11:27] <Amaranth> shiny but not good
[11:27] <Amaranth> over 1 minute?
[11:28] <seb128> Amaranth: there is a deb-src, do you want to get your package sponsored?
[11:29] <Amaranth> that's the one that needed the changes
[11:29] <Amaranth> if you want to do those real quick and upload it, sure
[11:30] <seb128> I don't have the comments I made on this box
[11:30] <seb128> but that was like 2 minor points
[11:30] <seb128> sure I can do the changes and upload tomorrow
[11:30] <seb128> (I'm going to bed soon for today)
[11:30] <Amaranth> it was removing the symlinks and the mv in rules and putting the smeg changelog back in
[11:30] <seb128> but you can as well fix that if you have noted them :)
[11:31] <Amaranth> I have no way of testing, I hate doing things without being able to make sure they work
[11:31] <seb128> k, I don't really care about the changelog
[11:31] <seb128> but I'll do an upload based on your version
[11:31] <seb128> just fixing the naming stuff
[11:31] <seb128> ok ?
[11:32] <Amaranth> ok
[11:32] <seb128> cool
[11:32] <daniels> why the hell does emacs need patching to support ppc64?
[11:33] <Amaranth> because emacs sucks?
[11:33] <pitti> I bet it has an integrated assembler :-)
[11:35] <\sh> elmo: please sync apt-move from debian unstable, override ubuntu changes ok
[11:41] <daniels> Keybuk: klibc> heh
[11:45] <Keybuk> brb
[11:48] <Keybuk> x.org is teh suck
[11:48] <Keybuk> it should cope better with me rmmod'ing mouse modules from under it
[11:51] <daniels> patches happily accepted
[11:52] <pitti> you know, with a topic of<PHONE_NUMBER> chars, I can never remember what you actually *changed*
[11:52] <Amaranth> i was just about to ask
[11:53] <Keybuk> pitti: http://www.netsplit.com/software/topicdiff
[11:53] <daniels> probably removal of #ubz?
[11:53] <pitti> Keybuk: thanks, cute
[11:54] <pitti> Keybuk: you have a script for *everything*, don't you? :-)
[11:54] <Keybuk> almost
[11:54] <jbailey> Keybuk: He keeps threatening to replace me with a shell script, but if he did he wouldn't have anyone to show his initramfs-tools hacks to ;)
[11:54] <jbailey> err.
[11:55] <jbailey> pitti: ^^
[11:55] <daniels> Keybuk: xchat is the SUCK
[11:55] <Keybuk> daniels: someone (pasc?) wrote one for irssi too
[11:55] <pitti> jbailey: I figured
[11:55] <Keybuk> my initramfs hack is love
[11:55] <carstenh> pitti: do you use xchat? if not, i have one for irssi :)
[11:55] <Keybuk> it even lets the initramfs get cleaned up, because it's chrooted into a different tmpfs and has its own mount of /proc
[11:56] <pitti> (I use xchat)
[11:56] <carstenh> ah, ok
[11:57] <daniels> carstenh: url for irssi plskthx
[11:58] <Keybuk> http://www.redellipse.net/code/topic-diff
[11:59] <carstenh> daniels: just a minute
[12:00] <carstenh> daniels: http://svn.df7cb.de/dotfiles/cb/.irssi/scripts/topic-diff.pl
[12:00] <daniels> 'sokay, I've grabbed pascalito's


[09:44] <Garzooka> :/
[09:44] <bazhang> Garzooka, ?
[09:46] <Garzooka> thats how I feel about #ubuntu-uk , can't get to the damn thing
[09:46] <bazhang> this is Phineas/Ferb/Nerml/catdog/bolt/etc?
[09:47] <Garzooka> *nermal
[09:47] <Garzooka> yeah
[09:47] <Garzooka> I actually admit it
[09:48] <Garzooka> I am all of those
[09:49] <Garzooka> and I am here to get sorted out
[09:50] <popey> your definition of 'sorted out' differs from mine
[09:51] <Garzooka> I know that popey,
[09:52] <Garzooka> you see I am getting fed up with being banned, we need to discuss and work out a solution
[09:53] <popey> You have been kicked/banned from the channel (and others in the Ubuntu namespace) many times over the years. You haven't changed your behaviour in that time.
[09:54] <popey> What possible reason could there be for unbanning you?
[09:54] <Garzooka> if you look in other channels you will find you are wrong
[09:54] <popey> Explain how I am wrong
[09:55] <Garzooka> I am behaving and (as I say) have no reson to be banned
[09:56] <Garzooka> I mean I've been perfectly alright  in other channels
[09:56] <popey> what channels?
[09:56] <Garzooka> ##windows
[09:56] <Garzooka> and possibly #ubuntu
[09:57] <popey> 16:31:49 < Garzooka> greetings
[09:57] <popey> 16:32:49 < Garzooka> greetings
[09:57] <popey> 16:52:27  * Garzooka starts humming the a team
[09:57] <popey> thats from #ubuntu
[09:57] <popey> 09:37:47 < Garzooka> greetings
[09:57] <popey> 09:38:48 < Garzooka> !ping
[09:57] <popey> 09:42:20 < Garzooka> I remember midnight comander
[09:57] <popey> that too
[09:57] <popey> none of it useful.
[09:58] <popey> So, I would say you haven't changed, you are not 'behaving'
[09:58] <Garzooka> I did start humming, everyone puts something like that
[09:58] <Garzooka> at some pojnt
[09:58] <Garzooka> point
[09:58] <popey> not in that channel
[09:59] <Garzooka> realy not in that channel?
[10:00] <Garzooka> oh, I hadn't realised until now
[10:00] <popey> You have neither asked for nor offered any assistance to anyone in that channel, which is acutally ths sole purpose of it.
[10:00] <Garzooka> I am the only one, I wish to make it up to you somehow
[10:01] <Garzooka> I mean I did ask questions in ##windows that made sence
[10:02] <Garzooka> and I do help people if I know what there going on about
[10:02] <popey> I'm not particularly interested in the activity of ##windows
[10:04] <Garzooka> if you look in #ubuntu I am trying to help someone
[10:07] <Garzooka> but the problem is I don't know much about ubuntu support
[10:07] <Garzooka> but I try my best
[10:08] <popey> one line of 'install a driver' doesn't counter months of being a dribbling lunatic in -uk
[10:08] <popey> In my very humble opinion
[10:10] <Garzooka> well I dont know that much about ubuntu
[10:10] <popey> right, i need to go and take my daughter to ballet. cheerio
[10:10] <Garzooka> seeya
[10:11] <Garzooka> I need another #ubuntu-UK op
[10:12] <Garzooka> any in here
[10:14] <Garzooka> AlanBell hello can you help me
[10:15] <Garzooka> or any ops should I say
[10:16] <AlanBell> hi Garzooka
[10:16]  * AlanBell reads back again
[10:17] <AlanBell> deja vu all over again
[10:17] <Garzooka> well kinda, but with the true story this time
[10:18] <AlanBell> well that at least is progress
[10:19] <AlanBell> so, in review you got a week of +q on the 30th december ish, which before it expired you managed to upgrade to a +b and you have been keeping that +b maintained ever since
[10:20] <Garzooka> the reson I change nicks and pretend I am another person is because I am fed up with being banned so I attempt to convince people I am a difrent person, but I am not
[10:20] <AlanBell> yes, that is ban evasion
[10:20] <AlanBell> which gets you banned for longer
[10:21] <Garzooka> I never knew that
[10:21] <Garzooka> :/
[10:22] <AlanBell> to be honest before the ban evasion and arguments in -irc you really were not annoying me that much in -uk
[10:22] <Garzooka> and I think thats unfair
[10:23] <Garzooka> I wasn't doing anything agenst the rules was i?
[10:25] <Garzooka> the thing is when I am banned I have to talk to one of my two most annoying ops ever
[10:26] <Garzooka> excluding you that is
[10:31] <AlanBell> I will have a chat with the other ops later and will clarify whether you are permanently banned or whether we should set a new expiration date
[10:31] <AlanBell> ban evasion is a seriously bad idea if you want to end up unbanned
[10:31] <Garzooka> thanks and goodbye
[10:31] <Garzooka> I will keep that in mind
[10:32] <Garzooka> goodbye
[13:59] <popey> 10:20:29 < Garzooka> the reson I change nicks and pretend I am another person is because I am fed up with being banned so I attempt to convince people I am a difrent person, but I am not
[13:59] <popey> as opposed to actually, y'know, fixing the behaviour
[17:34] <DJones> If he's fed up with being banned and isn't opposed to fixing the behaviour, why hasn't he done so and changed his behaviour.
[17:44] <m4v> tell him to pretend he's a person that behaves well
[17:52] <DJones> I'd rather he was a person who behaved well, rather than just pretending
[20:30] <guntbert> sometimes I wonder if the term "simple question" should set off various troll alarms :-)  (like a few minutes ago in #ubuntu-offtopic )
[20:31] <charlie-tca> yes
[20:31] <charlie-tca> like it did in #xubuntu a bit ago...
[20:41] <gpc> guntbert: I don't think they were trolling, they asked the same thing in #ubuntu and when redirected to -ot they parted the channel without incident.
[20:43] <guntbert> gpc: you may be right, and I didn't want to accuse anybody, only: the question was sort of strange....  (and usually the best way to keep troll away is to not answer...)
[20:43] <guntbert> and then my remark here was just an apropos
[20:46] <gpc> yeah I know :)
[21:16] <m4v> http://en.wikipedia.org/wiki/Factoid
[21:16] <m4v> "A factoid is a questionable or spurious—unverified, incorrect, or fabricated—statement presented as a fact, but with no veracity."
[21:16] <m4v> It doesn't sound good, does it?
[21:19] <gpc> not at all
[21:19] <guntbert> m4v: but entirely accurate (at least in some cases)
[21:19] <gpc> yup
[21:20] <m4v> I guess