[00:00] <davecheney> http://play.golang.org/p/0jeSRlVe8B
[00:00] <davecheney> ^ maybe that makes a little more sense
[00:01] <davecheney> thumper: can you show me the hole in the code where this function would fit
[00:01] <davecheney> maybe that would help me suggest a better implementation
[00:02] <rick_h_> davecheney: via the api we want to colocate a service with another on an existing machine. If I create a service with 0 units, and then add a unit with the machine id of an existing machine any chance of it working?
[00:03] <rick_h_> I cna't test it out via the cli becaus I can't deploy a service with --num-units=0
[00:03] <davecheney> rick_h_: deploy --to
[00:03] <davecheney> ^ that is what you are trying to do, right ?
[00:03] <rick_h_> yea, that's cli, but I need api for the gui
[00:03] <rick_h_> davecheney: yes, basically
[00:03] <davecheney> ok, let me figure out how the cli does it
[00:04] <rick_h_> but doing it with manual placement
[00:04] <rick_h_> davecheney: thanks
[00:04] <rick_h_> davecheney: sorry, we're getting the demo rules changed on us and trying to get back to a working demo
[00:04] <rick_h_> appreciate the help
[00:06] <davecheney> rick_h_: ok, i dont know what that means
[00:06] <davecheney> oh yes i dio
[00:06] <davecheney> ODS is here isn't it
[00:06] <rick_h_> davecheney: yep :)
[00:07] <rick_h_> davecheney: and our demo of lxc container on a running machine isn't happy with openstack running on openstack
[00:07] <rick_h_> so we're trying to change it on the fly to colocated on bare metal vs in lxc
[00:07] <davecheney>         err = client.ServiceDeployWithNetworks(
[00:07] <davecheney>                 curl.String(),
[00:07] <davecheney>                 serviceName,
[00:07] <davecheney>                 numUnits,
[00:07] <davecheney>                 string(configYAML),
[00:07] <davecheney>                 c.Constraints,
[00:07] <davecheney>                 c.ToMachineSpec,
[00:07] <davecheney>                 includeNetworks,
[00:07] <davecheney>                 excludeNetworks,
[00:07] <davecheney>         )
[00:07] <davecheney> this is the api (i guess call), there is a numunits on ther
[00:08] <rick_h_> ok, so it's coming in with the service
[00:08] <rick_h_> we need to break the steps up, but will see how we do
[00:08] <davecheney> hang on , still checking
[00:10] <davecheney> http://paste.ubuntu.com/7455044/
[00:10] <rick_h_> thanks looking
[00:10] <davecheney> so num units 1
[00:10] <davecheney> tomachinespec <- the machine you want to pin the service to
[00:11] <rick_h_> yea, we're deploying the service with 0 units and then making individual add unit calls.
[00:11] <davecheney> that won't work
[00:11] <davecheney> --to is a dirty hack
[00:11] <davecheney> its internal name is 'hulk smash'
[00:12] <rick_h_> ugh
[00:12] <rick_h_> ok
[00:12] <davecheney> so you'll have to deply one unit with --to, then make additional calls to add-unit --to
[00:12] <rick_h_> yea, that breaks more stuff for us then. thanks for looking
[00:13] <davecheney> the reason its like this is --to skips the normal machine selection logic, and just spats the unit on that machine
[00:13] <davecheney> that splatting isn't recorded in mongo at all
[00:13] <rick_h_> understood
[01:18] <axw> wallyworld_: that issue curtis reported is fixed by the tools CL you just did?
[01:19] <wallyworld_> axw: yes
[01:19] <axw> cool
[01:39] <wallyworld_> axw: did you have time for a quick standup?
[01:39] <axw> wallyworld_: sure
[02:13] <thumper> davecheney: around?
[02:14] <davecheney> thumper: ack
[02:15] <thumper> davecheney: got time for a hangout?
[02:15] <davecheney> thumper: sure
[02:15] <thumper> let me just let the dog in
[02:17] <thumper> davecheney:  https://plus.google.com/hangouts/_/g4gj3fe657m4xgcesqioprs6vqa?hl=en
[02:18] <davecheney> joining ...
[02:29] <thumper> davecheney: play.golang.org/p/3LV_d5HJb3
[02:36] <waigani> axw: ping
[02:36] <axw> waigani: pong
[02:37] <waigani> axw can I pick your brain? hangout?
[02:37] <axw> sure
[02:47] <axw> waigani: sorry was a bit hard to hear you, didn't realise you were logging off. cya ;)
[02:48] <waigani> oh whoops, didn't mean to hang up on you :/
[02:48] <axw> waigani: nps
[02:48] <axw> you got everything you needed right?
[02:48] <waigani> yep, all good now, thanks :)
[02:48] <axw> nps
[02:49] <waigani> I was going to ask how harding was going, but you seem to be in the thick of it
[02:50] <axw> waigani: just picking off bugs one at a time, not that different from before
[02:51] <waigani> axw: you're looking very productive! Thunderbird keeps popping up with merge proposals from you an wallyworld_ every 5min!
[02:52] <axw> I don't really feel very productive doing bitsy things, but it's still useful
[02:53] <wallyworld_> getting the test suite to pass reliably is very productive :-)
[02:57] <axw> wallyworld_: do you really want me to look at the LXC defaults thing, or was that just an idea? I've got a good idea about how to fix #1316272
[02:57] <_mup_> Bug #1316272: juju destroy-environment >=256 nodes fails <amd64> <apport-bug> <destroy-environment> <maas-provider> <sm15k> <third-party-packages> <trusty> <juju-core:Triaged> <MAAS:Invalid> <juju-core (Ubuntu):New> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1316272>
[02:58] <wallyworld_> go for it, it was just an idea
[02:58] <wallyworld_> that maas one is more important
[02:59] <axw> cool
[04:00] <jam> thumper: gocheck provides a gc.FitsTypeOf checker that takes two objects and tells you if the first one matches the type of the second one
[04:08] <thumper> jam: I don't want the type, but object identity
[04:08] <jam> thumper: so it isn't "unsafe" to grab a uintptr object
[04:08] <jam> AIUI
[04:08] <jam> it is only "unsafe" to cast that back into a type
[04:09] <thumper> jam: however the interface is a tuple of two pointers
[04:09] <jam> thumper: reflect.Value(obj).Pointer() == reflect.Value(obj2).Pointer()
[04:09] <thumper> jam: doesn't work if the type isn't a pointer
[04:09] <jam> I don't have the scrollback on this terminal for your non-comparable types
[04:09] <thumper> it panics
[04:09] <jam> thumper: &obj is still a pointer
[04:09] <jam> well, would always be a pointer
[04:09] <thumper> no
[04:10] <thumper> no it isn't
[04:10] <thumper> a value type can implement an interface
[04:10] <thumper> and in fact we have an example in juju-core
[04:10] <jam> sure, but &obj is still a pointer
[04:10] <thumper> where a value type is an error and uncomparable
[04:10] <jam> thumper: if it is a value type, then they *are not* the same obj.ect.
[04:10] <jam> object
[04:10] <thumper> jam: but you don't know
[04:10] <thumper> jam: look, I have examples in test code
[04:11] <thumper> which expected behaviour
[04:11] <thumper> if it can be done a different way
[04:11] <thumper> I'm happy, but AFAIK, it cannot
[04:16] <jam> thumper, so to start with, I'm not sure that comparing errors by identity is actually what we want to be doing, rather than checking if this error is part of this type of errors.
[04:16] <jam> I realize our code is a bit mixed on this point
[04:16] <jam> where we have some concrete errors
[04:16] <jam> and we have other variable ones
[04:16] <jam> and we get some unhashable/uncomparable ones from various libs
[04:16] <thumper> it isn't helpful to discuss this here without examples
[04:16] <jam> I've run into it elsewhere in our code where I wanted to put error types into a map
[04:17] <jam> but it fails to lookup because we get an unhashable error type.
[04:17] <jam> In that case, we just swallowed the panic
[04:17] <jam> that was the Serve code, IIRC
[04:17] <jam> which wants to map known errors into error codes
[04:20] <jam> thumper: state/apiserver/common/errors.go func singletonCode(err error) (string, bool)
[04:20] <jam> 	// All error types may not be hashable; deal with
[04:20] <jam> 	// that by catching the panic if we try to look up
[04:20] <jam> 	// a non-hashable type.
[04:20] <jam> thumper: if your error is a value type, then it pretty much *cannot* be the same object as some other object, because as soon as it is passed on the stack, it is a new object.
[04:21] <jam> as such, you can just say "if this isn't a Pointer() then it isn't the same object"
[04:21] <jam> and force the equivalence to false in that case.
[04:24] <thumper> jam: play.golang.org/p/dnd98Gl1O4
[04:27] <jam> thumper: http://play.golang.org/p/IjRIj8SaWk
[04:27] <jam> without unboxing the internal implementation
[04:28] <jam> of interface
[04:28] <thumper> but catching panic is just as horrible
[04:28] <thumper> jam: I'm going to take this to the list anyway
[04:28] <thumper> jam: so we can discuss it there
[04:29] <thumper> personally I wish that golang made this easier for me, but it doesn't
[04:29] <thumper> we will have one icky thing or the other
[04:29] <thumper> both are horrible IMO
[04:29] <thumper> but which is more horrible?
[04:29]  * thumper shrugs
[04:33] <jam> thumper: they give different results, too: http://play.golang.org/p/JQ5Ga8k-xd
[04:33] <jam> since if you have an 'error' it is pointing at a concrete value, so while you can't pass that value around without it changing to a new value, you *can* pass around the error interface to it
[04:34] <jam> which gives you a new interface at each step, but the underlying object is the same.
[04:34] <thumper> jam: well that is problematic
[04:34] <jam> thumper: though is the actual error you care about comparing to a value type ?
[04:34] <thumper> it may be
[04:34] <thumper> and that is one horrible bit
[04:34] <thumper> it may be a value type
[04:34] <thumper> and it *may* be uncomparable
[04:35] <thumper> and since it might happen
[04:35] <thumper> we need to handle it
[04:35] <jam> thumper: well, we do have some control on the system and can say things like "if you want your errors to be compared to be the same, they must be comparable types"
[04:36] <jam> I'm not sure what the use case is for being able to compare all possible error implementations
[04:36] <thumper> um... because you are writing an error handling library?
[04:36] <jam> thumper: its still your code
[04:36] <jam> you can give parameters of what is supported
[04:36] <thumper> not all of it
[04:37] <thumper> ugh
[04:37] <jam> Value type errors that are uncomparable aren't *nice* errors in go world
[04:38] <thumper> agreed
[07:01] <davecheney> waigani: ping
[07:01] <waigani> davecheney: pong
[07:03] <davecheney> waigani: do you remember the issue that we had before vegas related to juju blowing up on 64k kernels ?
[07:03] <waigani> davecheney: going offline soon
[07:03] <davecheney> there was one test package that would always blow up
[07:04] <davecheney> waigani: if you don't remember, that is fine
[07:04] <waigani> davecheney: just trying to think ...
[07:04] <waigani> everything stopped working for me before vegas
[07:05] <waigani> yeah sorry, I'll have a look over the issues/emails in the morning and see if I can remember
[07:05] <davecheney> waigani: np
[07:05] <davecheney> i'll figure it out
[07:07] <davecheney> 2014-05-13 07:06:58 INFO juju.worker runner.go:260 start "peergrouper"
[07:07] <davecheney> 2014-05-13 07:06:58 DEBUG juju.worker.peergrouper worker.go:421 found new machine "0"
[07:07] <davecheney> 2014-05-13 07:06:58 ERROR juju.worker.peergrouper worker.go:137 peergrouper loop terminated: cannot get replica set status: cannot get replica set status: not running with --replSet
[07:07] <davecheney> 2014-05-13 07:06:58 ERROR juju.worker runner.go:218 exited "peergrouper": cannot get replica set status: cannot get replica set status: not running with --replSet
[07:07] <davecheney> 2014-05-13 07:06:58 INFO juju.worker runner.go:252 restarting "peergrouper" in 3s
[07:07] <davecheney> local provider shits itself in a loop
[07:17] <davecheney> bugs raised today: 3
[07:17] <davecheney> bugs fixed today: 0
[08:09] <davecheney> if I do
[08:10] <davecheney> juju deploy X
[08:10] <davecheney> X is resolved by the charm store, yes ?
[08:10] <davecheney> is it resolved by the client, or by the api server ?
[08:10] <davecheney> (having proxy issues)
[08:10] <davecheney> ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju deploy --debug cs:trusty/mysql                                                                                2014-05-13 07:54:41 INFO juju.cmd supercommand.go:301 running juju-1.19.3-trusty-ppc64 [gccgo]
[08:10] <davecheney> 2014-05-13 07:54:41 DEBUG juju.conn api.go:185 trying cached API connection settings
[08:10] <davecheney> 2014-05-13 07:54:41 INFO juju.conn api.go:268 connecting to API addresses: [<IP_ADDRESS>:17070]
[08:10] <davecheney> 2014-05-13 07:54:41 INFO juju.state.api apiclient.go:198 dialing "wss://<IP_ADDRESS>:17070/"
[08:10] <davecheney> 2014-05-13 07:54:41 INFO juju.state.api apiclient.go:144 connection established to "wss://<IP_ADDRESS>:17070/"
[08:10] <davecheney> 2014-05-13 07:56:49 ERROR juju.cmd supercommand.go:304 cannot download charm "cs:trusty/mysql-0": Cannot access the charm store. Are you connected to the internet? Error details: Get https://store.juju.ubuntu.com/charm-info?charms=cs%3Atrusty%2Fmysql-0: dial tcp <IP_ADDRESS>:443: connection timed out
[08:37] <voidspace> morning all
[08:38] <axw> morning voidspace
[08:39] <axw> can someone please review a change to gomaasapi? https://code.launchpad.net/~axwalk/gomaasapi/testservice-nodes-release/+merge/219309
[08:40] <axw> (I'm updating the MAAS provider's StopInstances to do bulk release)
[08:43] <wwitzel3> voidspace: ping
[08:44] <voidspace> wwitzel3: morning :-)
[08:44] <voidspace> axw: morning
[08:44] <voidspace> wwitzel3: give me a few minutes and I'll join you in the hangout?
[08:45] <wwitzel3> voidspace: sounds good
[08:49] <fwereade> axw, lbox? I really like line-by-line comments :)
[08:50] <fwereade> axw, (this is not really a case where it's super-important, 'tis true)
[08:53] <fwereade> axw, basically LGTM but a few comments
[08:58] <fwereade> jam, axw, voidspace, wwitzel3, et al: I'm approving https://codereview.appspot.com/91390043/ but I'd still appreciate comments
[09:00] <axw> fwereade: sorry, does gomaasapi have lbox set up?
[09:01] <axw> does not appear to
[09:01] <fwereade> axw, good point -- but is it more than a .lbox file in the source tree?
[09:01] <axw> fwereade: making dinner, will take a look at your doc later
[09:01] <axw> fwereade: I have no idea
[09:05] <jam1> fwereade: I've come up with a possible problem with just putting Version into another attribute of the request header.
[09:06] <fwereade> jam1, oh yes?
[09:06] <jam1> In that old servers will just happily ignore the field and return the wrong thing
[09:06] <jam1> fwereade: it just means we have to be more careful in not allowing the client-side code to accidentally try a new version request
[09:07] <voidspace> fwereade: will read
[09:07] <voidspace> fwereade: thanks
[09:07] <jam1> fwereade: if we were to re-use the "id" field, then we would have gotten back ErrBadId, and we could have mapped that into "oh, that actually means NotImplemented"
[09:07] <jam1> now we just get "ok"
[09:07] <fwereade> jam1, ie only send versioned requests to server that have already stated they support versions? that does sound reasonable to me
[09:07] <jam1> I *think* we're ok, because we detect what the server supports at Login time.
[09:09] <jam1> fwereade: it is just one of those things where we have to be "extra careful" because we can do it wrong and things will still seem to be working, but might be subtly broken.
[09:09] <jam1> Like when we want to change the Set() api so that blank strings are accepted and don't mean "set to default".
[09:10] <jam1> if the client code had a bug that it just always used 2,Set() it would "just work" except when you tried to set to an empty string on an old server and it would set it to the default value.
[09:10] <jam1> fwereade: anyway, I have a model for how the client side code might work, and since we probe for available versions at Login time we should be able to do client side filtering appropriately
[09:10] <fwereade> jam1, yeah, I see your point, my personal instinct still slightly leads toward not reusing the field but I'm having a hard time justifying it -- at least a single layer of id-munging to support old clients using watcher ids is much more localised
[09:11] <jam1> Its just one of those "I'd like it to break noisily when we make a mistake"
[09:11] <jam1> fwereade: yeah, I like having it as an explicit Version. I was mostly just bringing up an issue that we should at least be aware of.
[09:11] <fwereade> jam1, cheers
[09:12] <jam1> fwereade: I guess partially I was also hoping that I wouldn't have to do as much changes to the RPC package because I had a new field and could do magic there, but it turns out everything was only nice and orderly because of all the other changes I've done along the way.
[09:12] <jam1> like handling Id early rather than late, etc.
[09:12]  * fwereade cheers
[09:23] <jam> fwereade: I'm about halfway through your arch overview, and I'm trying to get a feel for how much we need the "here be dragons" side comments vs the "this is how it is laid out". I like letting people know that what we have is not perfect yet, I just wonder if they distract from getting an understanding first.
[09:24] <jam> IF we had footnotes, I think they'd make excellent footnotes
[09:24] <fwereade> jam1, I go back and forth -- "how it is" and "how it should be" *are* separate, but I find that focusing only on the former ends up giving it a misleading air of the latter
[09:25] <fwereade> jam1, yeah, footnotes would be the answer, wouldn'tthey
[09:25] <jam> sidebars, something :)
[09:25] <jam> fwereade: yeah, I certainly appreciate the "it is this way because it has been this way, and we don't quite understand why the alternatives weren't chosen"
[09:25] <jam> which seems like something an overview could at least hint at.
[09:26] <jam> "eponymous" a word I've probably only ever read, I'm not actually sure how it is pronounced :)
[09:27] <fwereade> jam, I like that word so I probably shouldn't use it ;)
[09:27] <fwereade> jam, I thought I remembered deleting it actually, maybe some part of my brain rebelled and inserted it somewhere else
[09:28] <jam> fwereade: for example, `Provisioner`, `Upgrader`, and `Uniter`, each used by the eponymous +worker types
[09:28] <jam> I'm fine with it, fwiw
[09:28] <jam> I was just reading it over and realized, I know exactly what he means, but I don't actually know how to pronounce that word.
[09:29] <fwereade> jam, I can say what I think it should sound like in the standup, but I'm not *certain* that I haven't just made that up
[09:29] <jam> fwereade: https://www.google.com/search?client=ubuntu&channel=fs&q=eponymous&ie=utf-8&oe=utf-8 has a "pronounce it" button
[09:30] <fwereade> jam, well, google agrees with me
[09:30] <fwereade> jam, not sure that's enough to pronounce myself "right" but I'll go with it ;)
[09:31] <jam> fwereade: :)
[09:33] <jam> fwereade: LGTM with some trivials
[09:33] <jam> for your arch doc
[09:33] <jam> https://codereview.appspot.com/91390043/
[09:38] <fwereade> jam, thanks, I'll work those into the next CL
[09:39] <jam1> fwereade: so API versioning again. I like the idea that changing the Version argument can change the type of the thing being returned, but changing the Id should *not* be allowed to do so.
[09:39] <jam1> However, with us just registering a "give me an object" function
[09:40] <jam1> we can't quite tell the type without actually getting a concrete one.
[09:40] <jam1> the existing code used static introspection of functions to do some of this
[09:40] <jam1> what I'd *like* is to be able to have
[09:41] <jam1> instead of Register(func(State, Resources, Authorizer) (interface{}, error))
[09:41] <jam1> instead have
[09:41] <jam1> Register(func(State, Resources, Authorizer) (FixedType, error))
[09:41] <jam1> but I'm not sure if you can actually get away with that.
[09:42] <jam1> just because you need to be able to cast the function pointer you get to *something* to be able to call it (I think)
[09:42] <wwitzel3> jam1, fwereade: you guys have time to chat about rsyslog API stuff real quick? voidspace and I are in a hangout
[09:42] <fwereade> wwitzel3, sure
[09:42] <jam1> wwitzel3: can you link the hangout?
[09:43] <wwitzel3> https://plus.google.com/hangouts/_/canonical.com/moonstone
[10:39] <fwereade> jam1, sorry, don't wait for me re standup
[10:39] <jam1> fwereade: np
[10:39] <fwereade> jam1, just 1 main thing: you have work items, but do you also have people writing proto-docs and handing over to evilnickveitch?
[10:40] <jam1> fwereade: I believe the intent is to have Frank focus on some of that as he comes over to core
[10:40] <jam1> or you're talking more about proto-docs before implementation of current feature?
[10:41] <jam1> fwereade: for what I'm working on, I still haven't actually gotten enough implementation to know how its going to hang together, but when I get a bit further I would be happy to write how to use API versioning doc
[11:02] <voidspace> jam1: as you suspected, bringing up new state servers doesn't rewrite the rsyslog conf on units
[11:03] <voidspace> jam1: so we *definitely* need the additional notification
[11:03] <jam> voidspace: so my guess is, that if you then bounce unit-wordpress-0 it will rewrite syslog.conf because it will read the new addresses from agent.conf
[11:03] <jam> but I think we want to do it right away
[11:03] <voidspace> right
[11:03] <voidspace> we're working on doing it the right way
[11:04] <jam> voidspace: I think ideally we would be writing rsyslog data from information we get directly from the API server, rather than punning the apiaddresses data
[11:04] <jam> agent.conf (pie-in-the-sky) would be only enough information to get your real truth from the API server.
[11:09] <voidspace> jam: we're going to add an RsyslogHostPorts endpoint (or similar) that effectively (currently) wraps APIHostPorts
[11:09] <voidspace> I think :-)
[11:09] <axw> jam: is there a way to merge an MP to trunk via LP?
[11:09] <jam> voidspace: so thats good, we just need to change the ports as the data goes through.
[11:09] <voidspace> right
[11:09] <axw> jam: or do I need to branch/merge/push
[11:09] <jam> axw: what trunk?
[11:09] <voidspace> we'll currently just add the global port to each address
[11:09] <axw> jam: gomaasapi
[11:10] <voidspace> but that's easy to then change if we *actually* have different ports
[11:10] <jam> axw: branch and push
[11:10] <axw> ok, ta
[11:10] <jam> axw: gwacl is controlled by our bot, but gomaas is manual
[11:10] <jam> IIRC
[11:10] <axw> yep, seems so. thanks
[12:08] <wwitzel3> voidspace: https://code.launchpad.net/~wwitzel3/juju-core/009-ha-rsyslog-api
[12:34] <perrito666> could someone please tal https://codereview.appspot.com/92320043/ ?
[12:35] <perrito666> and yes, that is awk that I am using, I am from the past
[12:43] <natefinch> perrito666: looking
[12:44] <perrito666> natefinch: turns out it was a bit less trivial than originally thought :p
[12:45] <natefinch> perrito666: heh, I never thought it would be trivial ;)
[12:45] <perrito666> I am an optimistic guy
[12:45] <natefinch> sleep 60 ...  well that inspires confidence
[12:45] <natefinch> (not a judgement of the programmer)
[12:47] <perrito666> mm, did I push that?
[12:47] <natefinch> it's there, yeah
[12:47] <perrito666> tx god for restores, bugs in bash in go are a pain to spot
[12:48] <perrito666> s/restores/reviews
[12:48] <natefinch> honestly, the problem is that we're just passing huge strings to bash.  That's not really the way we should be running terminal commands
[12:49] <natefinch> the single { for mongo and the double {{ for go templates is particularly gnarly
[12:50] <perrito666> natefinch: you should see how that outputs to the shell
[12:50] <perrito666> '\"'\"' <-- that is '
[12:50] <natefinch> heh
[12:51] <natefinch> reminds me of "\\\\" for a literal \ in a regex
[12:52] <natefinch> "http:\\\\\\\\"
[12:52] <jam> perrito666: I'm ~ sure that you can change the agent.conf on machine-0 to just read "localhost:17070" and it would be happy
[12:54] <perrito666> I can try
[12:55] <jam> perrito666: that can potentially simplify your logic a lot
[12:56] <perrito666> jam: true
[12:57] <jam> perrito666: also, is it possible to use the values for "state-port" and "api-port" instead of assuming they are 37017 and 17017 respectively?
[12:57] <jam> If it is hard to do, don't worry too much about it, as I don't think anyone has *actually* run with a non-standard port, but the configuration *is* ther.
[12:59] <perrito666> jam: it is not that much effort to add it, I have been avoiding additions beyond necessity because restore is quite fragile and I did not want to make future/present bug hunting even harder
[13:02] <natefinch> I wish we could just remove the port configuration, it would make our code significantly simpler.
[13:24] <perrito666> brb
[13:28] <natefinch> jam: how do I figure out what revision a branch is on, say if the code were copied to a github, for example?  .bzr/branch/last-revision  has a revision number, but the diffs look off
[13:29] <jam> natefinch: every branch has its own revision numbering but the revision-id is unique. You can do "bzr revno" or "bzr revision-info" to get details
[13:29] <jam> natefinch: and you can't exactly push a bzr branch to github
[13:29] <jam> but otherwise you can pass "-d" to revision-info to select a different location
[13:29] <jam> bzr revision-info -d lp:juju-core
[13:30] <jam> for example
[13:30] <natefinch> bzr revno worked.
[13:31] <jam> natefinch: sure I just wanted to be clear that having the same revno doesn't mean it has the same contents, because if we are both at 2250 and we both commit, we'll both be at 2251 but have different revision-ids
[13:32] <natefinch> the code was copied into git, but I wasan't sure if that would throw off bzr, but it seems  the .bzr stuff was left intact
[13:32] <natefinch> jam: ahh I see
[13:32] <jam> natefinch: so if you're using bzr-git, we might  be magic enough to map into git and then back into bzr again.
[13:33] <jam> otherwise you wouldn't be able to do "bzr revno $GITLOCATION"
[13:34] <natefinch> I presume revnos are at least unique per branch, right?  so trunk 2200 is a definitive revision
[13:34] <jam> natefinch: it is, but pull/push can change the order of history and 2200 *can* become something different.
[13:35] <jam> there are ways to enforce it (set append-revisions-only will refuse a push that would change revnos)
[13:38] <natefinch> ew.... so, why even bother with revision numbers if they don't mean anything static?
[13:40] <jam> natefinch: because most of the time (and the tool can help enforce it) they are static within a branch
[13:40] <jam> and they are *far* more meaningful and understandable than hashes
[13:41] <jam> if I tell you I changed it at rev 2500 in trunk, you can tell really quickly if your copy of trunk has the change I proposed
[13:42] <jam> things like trunk branches should always have append_revisions_only set (I believe I did that for juju-core)
[13:42] <jam> so push can't change the old numbers.
[13:44] <natefinch> interesting
[13:45] <natefinch> I do like numbers I can understand rather than just giant hashes that have no intrinsic meaning
[13:45] <bodie_> mornin fellas
[13:45] <natefinch> morning bodie_
[13:48] <perrito666> sinzui: you can try turning on the restore test again
[13:48] <sinzui> perrito666, I saw the  change and queued the test
[13:50] <perrito666> great, not that I dont have faith but Ill be expectant
[14:11] <fwereade> guys, I'm feeling somewhat sick, I'm going to go and lie down for a while, probably back later
[14:12] <perrito666> ok, get better
[14:19] <wwitzel3> natefinch: you want to assit with this code structuring?
[14:20] <wwitzel3> assist
[14:25] <natefinch> wwitzel3: oh yeah, sorry, one second, I'll get back in the hangout
[14:47] <jam> sinzui: is there a new URL for reports.vapor.ws ? or is it intended to be private
[14:48] <sinzui> jam, oh!
[14:48] <sinzui> jam, I think abentley put it behind apache in the last 12 hours
[14:48] <sinzui> http://reports.vapour.ws/
[14:48] <jam> sinzui: ah, just directly not at the random port
[14:49] <perrito666> hey, does anyone have the link to the doc from the sprint, it is not showing in my docs as shared with me
[14:53] <perrito666> natefinch: well, apparently we where very consistent on not writing details regardin WAL
[14:53] <perrito666> :p
[14:56] <natefinch> perrito666: https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.hpeo5xue46ue
[14:56] <natefinch> perrito666: if you go to google docs for canonical, it should be in the list of recent documents, which is where I ususally go to find stuff
[14:57] <perrito666> ah, recent, didnt think of that
[14:57]  * perrito666 facepalms
[14:58] <natefinch> perrito666: it's ok, it took me like 6 months at canonical to start using recent :)
[14:59] <perrito666> the fact that the listing of files for google docs looks like a teenagers windows desktop in the 90s does not help at all :p
[15:24] <sinzui> perrito666, your revision is building now in CI. I hope to see a pass in the next 80 minutes http://juju-ci.vapour.ws:8080/
[15:33] <perrito666> sinzui: oh the suspense
[15:37] <perrito666> hey anyone around here was present at the HA talks, most precisely when you talked about WAL? I think I am on track but would love to double check
[15:37] <perrito666> sinzui: yay, a dns humanly readable name cool
[16:24] <sinzui> perrito666, PASS http://juju-ci.vapour.ws:8080/job/functional-backup-restore-devel/806/console
[16:25] <perrito666> \o/
[16:51] <Sebas_> hi folks :)
[16:56] <voidspace> fwereade: ping
[16:56] <fwereade> voidspace, pong
[16:56] <voidspace> fwereade: you gave my branch an LGTM today
[16:57] <fwereade> voidspace, that was nice of me :)
[16:57] <voidspace> fwereade: it turned out I'd missed some of our copy-pasta config tests
[16:57] <voidspace> fwereade: haha, it was premature of you ;-)
[16:57] <voidspace> but yes, nice
[16:57] <voidspace> fwereade: so I've fixed those tests to use the new format, including the ruleset for a single state server
[16:57] <voidspace> fwereade: plus a test that if we have multiple state servers that we get entries for both (for the case of two) in the generated template
[16:58] <fwereade> voidspace, <3
[16:58] <voidspace> fwereade: essential testing the logic in the template
[16:58] <voidspace> fwereade: should I ask for another look at the branch, or as it's *essentially* test fixes should I just reapprove?
[16:59] <bodie_> fwereade: should we think about merging the action yaml parsing stuff into our code before dressing it for MR?
[17:00] <fwereade> voidspace, the general answer is "use your judgment" -- if you're confident in it, and the approach has been LGTMed, don't feel you *have* to get *everything* rereviewed
[17:00] <bodie_> or make those two separate mr's (we'd assumed the previous work was a discard)
[17:00] <voidspace> fwereade: it's just fixing tests, and they all pass this time (*coff*) so I'm inclined to just re-approve
[17:00] <voidspace> thanks
[17:00] <fwereade> voidspace, go for it
[17:01] <fwereade> voidspace, we have the landing bot after all, so all you *really* risk there is looking stupid if they keep on failing ;p
[17:01] <fwereade> bodie_, keep them separate
[17:01] <fwereade> bodie_, that CL is basically fine, I don't want it to grow and grow and incorporate more and more, that's painful for everybody
[17:01] <voidspace> fwereade: if I was afraid of looking stupid I wouldn't get much done...
[17:02] <bodie_> was that a dumb enough question?  ;)
[17:02] <bodie_> yes
[17:02] <fwereade> bodie_, until it's exposed in the UX, and until it's doing things that affect actual DB integrity/sanity, small incremental steps are great
[17:02] <fwereade> bodie_, keep trying ;p
[17:02] <fwereade> bodie_, I'm sure you can ask much dumber questions if you put your mind to it ;p
[17:05] <bodie_> fwereade, I suppose the worst of them are the ones that remain unasked and instead are expressed as dumb code ;)
[17:06] <fwereade> bodie_, exactly :)
[17:09] <wwitzel3> anyone have a second to look at a screenshare and tell my why my tests are getting a state server not found error? fwereade, natefinch ?
[17:11] <fwereade> wwitzel3, not much more than a second tbh, but I can try :)
[17:11] <wwitzel3> https://plus.google.com/hangouts/_/canonical.com/moonstone
[17:11] <natefinch> wwitzel3: ug.  I can look, though the tests that try to set up an environment always give me like 3 days of trouble
[17:11] <voidspace> natefinch: we have 20 minutes ;-)
[17:12] <natefinch> voidspace: luckily fwereade offered assistance for a second, which is almost certainly worth more than my 20 minutes :)
[17:17] <Sebas_> hey there! I'm recently having an issue with lxc containers created by the juju-local in an ubuntu trusty
[17:17] <Sebas_> I installed a new fresh ubuntu each time (3 times by now)
[17:18] <Sebas_> the lxcbr0 is missing
[17:18] <Sebas_> so everything is failing apart :(
[17:18] <Sebas_> someone have's a clue of what can be or where to look?
[17:21] <natefinch> Sebas_: can you pastebin your /etc/lxc/lxc.conf   /etc/default/lxc and /etc/default/lxc-net ?
[17:22] <Sebas_> natefinch: of course!
[17:22] <Sebas_> natefinch: just a minute
[17:22] <natefinch> Sebas_: I'm not an lxc expert, but it sounds like maybe your lxc is configured to use a different bridge, which is a known problem with juju local
[17:23] <Sebas_> natefinch: there's no /etc/lxc/lxc.conf
[17:23] <natefinch> Sebas_: that's ok, there isn't for me either, I think that's the default
[17:23] <Sebas_> hmmm but in the local machine exist properly
[17:23] <Sebas_> like lxcbr0
[17:25] <natefinch> Sebas_: check /etc/default/lxc-net    - that's where mine is configured to use lxcbr0, perhaps yours is configured differently for some reason
[17:26] <Sebas_> natefinch: take a look http://pastebin.com/KN4XxqrD
[17:27] <Sebas_> i'm comparing with a local virtualbox machine that is working
[17:27] <natefinch> looks just like mine
[17:28] <natefinch> Sebas_: Specifically what error are you seeing?
[17:28] <Sebas_> natefinch: the bridge is just missing :(
[17:28] <Sebas_> in the container
[17:29] <Sebas_> its really wired
[17:29] <natefinch> Sebas_: can you copy and paste the actual text? It'll help me find it in the code and maybe figure out what it's trying to do and why it's failing
[17:30] <Sebas_> natefinch: the problem is that there isn't an error
[17:30] <Sebas_> its just missing so, the from it can't access internet from the container
[17:32] <voidspace> EOD folks
[17:32] <voidspace> g'night all
[17:32] <voidspace> see you tomorrow
[17:32] <natefinch> night voidspace
[17:32] <Sebas_> voidspace g'night
[17:34] <Sebas_> natefinch: whats your kernel? mine is 3.13.0-24-generic
[17:35] <Sebas_> seems ok
[17:36] <natefinch> Sebas_: I'm on 3.13.1, but I doubt that's the difference
[17:37] <Sebas_> yep :(
[17:37] <Sebas_> natefinch: i dump some dmesg
[17:37] <Sebas_> http://pastebin.com/ZHjDkhHE
[17:37] <Sebas_> just wat I thought is relevant
[17:40] <wwitzel3> EOD for me
[17:40] <perrito666> wwitzel3: bye
[17:43] <natefinch> Sebas_: brb, I need to reboot
[17:50] <perrito666> fwereade: still on the clock?
[17:50] <natefinch> perrito666: he's salary, that means he's always on the clock ;)
[17:51] <perrito666> natefinch: I have no clue what that means
[17:51] <perrito666> :p
[17:52] <natefinch> perrito666: salaried vs. hourly wages.  he gets paid the same amount whether he works 20 hours a week or 120.  In theory, "on the clock" applies to people who have to clock in and out because they're paid by the hour (wage).
[17:53] <perrito666> ahh I see no such linguistic distinction in spanish
[17:54] <perrito666> salary person means you get paid :p and then you need to specify by/the X
[17:54] <natefinch> yeah, we say salaried vs. hourly to differentiate
[17:54] <perrito666> anyway, I just wanted to know what percentage of his attention was still on the screen, which apparently amounts to 0 :p
[17:55] <natefinch> haha well, it is rather late there
[17:55] <perrito666> If I understood correctly the adding wal to mongo was only to add --journal to the mongo-db invocation, and perhaps find a way to test that
[17:56] <perrito666> I was just hunting for someone that actually took part on that conversation
[17:56] <natefinch> perrito666: if --journal is defined by the mongo docs as turning on WAL, then all you need to test is that we call --journal.  No need to test that mongodb does what it says it'll do
[17:57] <natefinch> and maybe contemplate what happens when someone upgrades from a previous juju that didn't specify --journal
[17:57] <perrito666> natefinch: so it says :) http://docs.mongodb.org/manual/tutorial/manage-journaling/
[17:58] <Sebas__> natefinch: thoughts ? :P
[17:58] <natefinch> Sebas__: sorry, got distracted.  Is the problem then just that the containers can't contact the internet?
[17:58] <Sebas__> natefinch: btw thanks for your help :)
[17:59] <natefinch> Sebas__: doing my best, but you've unfortunately encountered the Juju dev with the least amount of Linux experience :)
[17:59] <Sebas__> yep, because of the missing lxcbr0 bridge
[17:59] <natefinch> Sebas__: you said you had lxcbr0 on your local machine, right?
[17:59] <Sebas__> yes
[18:00] <Sebas__> but not into the container
[18:00] <Sebas__> which is wired hehe
[18:00] <natefinch> Sebas__: so, the container doesn't need lxcbr0.... mine don't have that, and they can contact the internet just fine
[18:00] <Sebas__> hmmm
[18:01] <Sebas__> natefinch: you are right!
[18:01] <Sebas__> so now i more lost
[18:01] <Sebas__> hehe
[18:01] <natefinch> perrito666: do you know anything about lxc containers and their networking?
[18:05] <perrito666> natefinch: very little you want to ask to vladk|offline or dimitern
[18:06] <Sebas__> the thing is that, it isn't a random error
[18:06] <Sebas__> is with fresh installed ubuntu trusty
[18:06] <perrito666> lxbr0 iirc is the virt interface for bridging lxc containers, the containers themselves should have "regular" ifaces
[18:08] <Sebas__> perrito666: yeah, and it seems it haves, i checked now
[18:08] <Sebas__> and the eth0 is there like it should
[18:09] <natefinch> Sebas__: so, all juju does is make LXC containers using the usual methods. It's not really doing anything magical to the containers.  I don't know why your containers are broken, but it's likely an environmental issue rather than a juju issue, per se.  I know that doesn't help you much, though.   You might try getting on #ubuntu and seeing if someone there can help debug your lxc issues.
[18:10] <Sebas__> ooh ohh! i think i know what is it
[18:10] <Sebas__> natefinch: you are correct
[18:10] <Sebas__> till now I didn't know what was it
[18:10] <Sebas__> but
[18:11] <Sebas__> i ping just the ip to see if wasn't an resolve problem
[18:11] <Sebas__> of geteway
[18:11] <Sebas__> and it pings!!
[18:12] <Sebas__> im going to try to route by hand
[18:12] <natefinch> cool :)
[18:12] <natefinch> brb, gotta water the carrots
[18:14] <Sebas__> natefinch: yeah but the route already exist :(
[18:15] <Sebas__> damn it !
[18:15] <Sebas__> hehe
[18:22] <fwereade> perrito666, passing by briefly: http://docs.mongodb.org/manual/tutorial/manage-journaling/ seems to imply it's on by default (at least on 64-bit) -- might we be thinking about the writeconcern, which I think needs fixing too?
[18:23] <natefinch> fwereade: I have writeconcern in a different branch.  Possibly this is a noop then
[18:23] <fwereade> perrito666, cool -- it's still worth doing for 32-bit systems though
[18:29] <perrito666> fwereade: indeed, for what I see we even have tests that check for journaling stuff happening, we seem to be assuming it on by default
[19:27] <perrito666> ok, eod for me
[19:27] <perrito666> bye guys
[19:28] <natefinch> perrito666: see ya
[20:09] <thumper> cmars: morning
[20:10] <cmars> hi thumper
[20:10] <thumper> cmars: when I organised our chat in about an hour I had forgotten about a physio appt I have
[20:10] <thumper> cmars: can we push it back an hour?
[20:10] <thumper> so in 1:50?
[20:11] <cmars> sure
[20:12] <thumper> thanks
[20:12] <thumper> I'll put in the calendar this time
[20:39] <fwereade> thumper, btw, my eyes glazed over a little looking at that CL, but progress seems sane -- was there anything in particular you wanted to talk about?
[20:40] <thumper> fwereade: agreement on direction mainly
[20:40] <fwereade> cmars, not sure if you saw my review; I'm mainly just unsure what forces prompted it. separate certs for state vs api seems perfectly sane to me, I just haven't thought through the upgrade process and wanted to be reassured that someone had
[20:53] <sinzui> hello rocket scientists. Does anyone have a strategy for using a newly built tool for an arch not in the streams. I want to add-machine a ppc instance. Ubuntu never published an official juju-core 1.18.2, but I tested a tool that I want juju to use when provisioning
[20:54]  * sinzui ponders creating a private stream with  extra tools.
[20:55] <sinzui> natefinch, ^ have you ever pondered this
[20:55] <fwereade> sinzui, that would be my advice -- wallyworld's `juju metadata` stuff should make it doable?
[20:55]  * fwereade waves his hands enthusiastically
[20:55] <sinzui> fwereade, yes, I can do that making a new stream. I can change juju-metadata-tools exactly once because of a bug in juju
[20:56] <fwereade> sinzui, hmm, is that failed mutability or failed immutability?
[20:57] <wallyworld> you should be able to create metadata for just the one tarball, and put that plus the tarball in cloud storage. it will look there and fallback to streams.c.c for other arches
[20:57] <sinzui> fwereade, we cannot change *-metadata-url once set, but we can bootstrap with out it (use streams.canonical.com), then change it once later
[20:57] <fwereade> wallyworld, I still get nervous about the falling back :)
[20:57] <fwereade> sinzui, heh, failed immutability then
[20:57] <sinzui> I reported the tools version of the bug, other users reported the image- version of the bug
[20:58] <fwereade> wallyworld, do you recall why we made those immutable? I can see how it *could* be a can of worms, but there's a clear use case there as well
[20:58] <wallyworld> fwereade: can't recall now sorry :-( i'm sure it was a good idea at the time
[20:58] <wallyworld> also, it never used to fallback, but we made it so
[20:59] <sinzui> fwereade, Once juju-1.18.2-trusty-ppc64el.tgz is know to the juju-ci-3 env, I am 30 minutes from have two slaves in two different networks to prove trans-cloud envs rock
[20:59] <sinzui> wallyworld, It might have made sense to not let you change the values before we added mirrors
[20:59] <fwereade> wallyworld, yeah, I think the falling back was a bit of an act of desperation... if it's *possible* to find *some* tools, please do :)
[21:00] <fwereade> sinzui, awesome
[21:02] <wallyworld> fwereade: don't quite grok the last tools comment. the fallback thing was to allow some tools to be found in cloud storage, say, and the rest from streams
[21:03] <fwereade> wallyworld, yeah, it's precisely that that makes me nervous -- 2 different locations for tools raises an unholy spectre of two different versions of juju that think they're the same
[21:03] <fwereade> wallyworld, it's something that scares me, but probably not something I ought to get too stressed about
[21:03] <fwereade> wallyworld, and the happy path is evidently happy
[21:03] <wallyworld> i sorta agree but users complained and it was not usable the other way
[21:03] <bodie_> famous last words
[21:04] <fwereade> wallyworld, I'm just whining, you know how I love to do that
[21:04] <wallyworld> you are english :-)
[21:04] <fwereade> bodie_, I've had 6 months since I first said them ;p
[21:05] <wallyworld> sinzui: do you have all you need to try out the jenkins github lander with my test core repo? is there anything i can do?
[21:07] <sinzui> fwereade, wallyworld . I think the scenario here is ops may want to choose new source for images and tools. They certainly want just one source. they may want to change the source to get special images or tools. private clouds need to do this if they move things. envs in public clouds may want to get special streams
[21:07] <waigani> morning all, back again :)
[21:07] <sinzui> wallyworld, I need time. I don't think I can start the tests until monday.
[21:08] <wallyworld> no worries, just ensuring i didn't need to do anything else to help
[21:08] <wallyworld> not urgent :-)
[21:08] <fwereade> sinzui, that was sorta my perspective; definitely +1 on making them mutable; *also* +1 on mandating a single source, but my nightmares re allowing multiple have not yet come to pass, so your job right now should be easier even if not for my favourite reaons
[21:09] <wallyworld> sinzui: if that url bug is not already high, we can add it to the high pool
[21:10] <bodie_> fwereade -- I'm getting a strong spidey sense about the way we're trying to do Actions.  can you help me understand why it's necessary for the hook to trust the action info?
[21:10] <bodie_> if I were writing an Action hook, I'd be parsing args myself
[21:10] <bodie_> unless I'm misunderstanding the purpose of this
[21:13] <fwereade> bodie_, one somewhat-significant reason is so that we can provide a nice gui for it, but that probably shouldn't be (the* overriding reason within core
[21:14] <fwereade> bodie_, declaring what an action accepts in a standard format STM to be a Good Thing on general principles, too, fwiw
[21:14] <fwereade> bodie_, and if we *do* guarantee that the data we deliver will match the declared interface, we should be able to save charm authors quite a lot of boilerplate checking
[21:15] <fwereade> bodie_, if we don't, I think we add quite a lot to the burden of implementing an action
[21:15] <fwereade> bodie_, imagine how bad it would suck if every single method just took (args ...interface{})
[21:17] <fwereade> bodie_, spidey-sense rising or fading? ;)
[21:27] <cmars> does anyone else see intermittent failures in cmd/jujud when running all the tests? they usually disappear if I 'go test ./cmd/jujud' by itself
[21:29] <thumper> yes
[21:33] <bodie_> fwereade, I see regarding reducing Action boilerplate
[21:34] <bodie_> should've mentioned I was stepping away
[21:35] <bodie_> yes, it seems like everything using interface{} would somewhat defeat the utility of Go ;)
[21:39] <bodie_> yet if we're using json-schema on the charm, why is it OK to define in a yaml file?
[21:59] <wallyworld> cmars: we're working on fixing the test suite but there's a lot to work through
[21:59] <wallyworld> fingers crossed we'll get it sorted real soon now
[21:59] <cmars> wallyworld, thanks. I was mostly wondering if it was just my dev env
[22:00] <wallyworld> nah, the bot is sad too
[22:00] <wallyworld> cmars: feel free to file a bug tagged test-failure and we can look to ensure it's not a new issue
[22:02] <wallyworld> thumper: if you are interested or have a spare moment, i'd love a look at https://codereview.appspot.com/94410043  it consolidates the lxc clone settings
[22:02] <thumper> will look later
[22:03] <wallyworld> no hurry
[22:39] <sinzui> wallyworld, any insights? http://pastebin.ubuntu.com/7459884/
[22:46] <wallyworld> looking
[22:51] <wallyworld> sinzui: can you also paste the index file?
[22:52] <sinzui> wallyworld, http://pastebin.ubuntu.com/7459905/
[23:02] <wallyworld> sinzui: sadly there's a lack of logging in the code around where i suspect it's failing, i'm still looking
[23:03] <waigani> menn0: standup :)
[23:03] <wallyworld> can we get the all-machines.log?
[23:03] <sinzui> wallyworld, thank you. I have a fallback plan of bootstrapping the machine as a separate env.
[23:04] <wallyworld> sinzui: before you do, grab the all-machines.log for me and i'll look at that
[23:04] <wallyworld> i think it's failing creating the manual provisioning script
[23:04]  * sinzui does
[23:37] <sinzui> wallyworld, oh, 403. damn, when I recreated this container it lost the public permissions
[23:38] <sinzui> wallyworld, I see a ppc64 machine on a different cloud being provisioned
[23:38] <perrito666> sinzui: still around?
[23:38]  * sinzui is so excited
[23:38] <sinzui> perrito666, I am
[23:40] <perrito666> sinzui: I have a patch proposed for HA restore, I was wondering if I should push it once its reviewed or if there is a CI test for that story in the foreseeable future
[23:40] <perrito666> no pressure
[23:41] <sinzui> perrito666, I will have a test running tomorrow morning or even tonight. I sketched it out last week.
[23:42] <perrito666> wow you are fast :) there is a comment asking this on the bug, if you couuld add the info as an answer there once the test is there I will be very thankful
[23:42] <perrito666> (also I will be happy not to do that by hand again :p)


[11:00] <ajmitch> Burgwork: so, time to start writing up some specs for UDS
[11:04] <Burgwork> indeed
[11:04] <Burgwork> shall we up our existing specs?
[11:05] <ajmitch> review them & see what got done & what didn
[11:05] <ajmitch> 't
[11:05] <Burgwork> right
[11:05] <ajmitch> see what's reasonable for feisty+1
[11:05] <Burgwork> can you write a feisty+1 authtool one?
[11:05] <ajmitch> sure
[11:05] <Burgwork> I was thinking
[11:05] <ajmitch> if it's needed
[11:05] <ajmitch> are you going to be there?
[11:05] <Burgwork> your auth tool thing should do the following:
[11:06] <Burgwork> 1. do timo's group hack thing
[11:06] <Burgwork> 2. make members of the ldap group admin, admin on the local machine
[11:07] <ajmitch> 0. work nicely
[11:08] <Burgwork> heh
[11:08] <Burgwork> are we looking at fds or openldap for feisty+1
[11:08] <Burgwork> ?
[11:09] <ajmitch> probably still openldap
[11:09] <ajmitch> depends if fds 1.1 can be released
[11:09] <ajmitch> it's mainly the core server that has been autotooled
[11:09] <Burgwork> yep
[11:10] <ajmitch> but I need time off work first
[11:10] <Burgwork> rocking
[11:10] <Burgwork> I never got one
[11:10] <ajmitch> probably due to motu council stuff, I guess
[11:11] <ajmitch> I can't think of any other reason that I'd be invited
[11:11] <Burgwork> ahh
[11:11] <Burgwork> have you heard anything more about the CC elections
[11:11] <ajmitch> nope
[11:11] <ajmitch> nor TB nominations
[11:12] <ajmitch> I really should get back to FDS packaging
[11:12] <ajmitch> try & get something usable on the laptop to take with me
[11:12] <Burgwork> http://cobbler.et.redhat.com/
[11:13] <ajmitch> you want that packaged?
[11:13] <Burgwork> no, I just wondered if it was userful
[11:13] <Burgwork> useful, rather
[11:13] <ajmitch> could be useful for edubuntu
[11:13] <ajmitch> you've worked at userful too long, I see
[11:21] <Burgwork> apparently jorge
[11:21] <Burgwork> is paying somebody to do ltsp failover this summer
[11:21] <Burgwork> develop it, that is
[11:21] <Burgwork> his employer, not him
[11:22] <ajmitch> oh, interesting
[11:23] <Burgwork> I think another feisty+1 is to have ltsp+ldap auth+fat clients work perfectly
[11:24] <Burgwork> then we can have provisioned computing
[11:26] <Burgwork> looks like cobbler could be extended to be a control server
[11:27] <Burgwork> however, it looks like cobbler is not reallyl needed, if we have ltsp fat clients
[11:30] <Burgwork> ajmitch: shall I ping ogra, so we can have a "provisioned Ubuntu" meeting at some point?
[11:32] <ajmitch> yeah, may as well
[11:33] <ajmitch> eg promising the world, etc
[11:33] <Burgwork> do it
[11:33] <Burgwork> I am looking for 6 weeks off
[11:33] <Burgwork> 1 to go to GUADEC, 1 for Sevilla, 2 weeks of shitting around Europe and then 2 in ZA
[11:33] <ajmitch> it's likely to be unpaid leave, but that doesn't matter too much when the week is paid for
[11:33] <ajmitch> nice
[11:33] <ajmitch> I've only been here a little while
[11:34] <Burgwork> oh, Sevilla is in May
[11:34] <Burgwork> I is idiot
[11:34] <ajmitch> oh?
[11:34] <ajmitch> when did you think it was?
[11:35] <Burgwork> july, like guadec
[11:35] <ajmitch> ah
[11:35] <ajmitch> so you're not likely to get to sevilla
[11:35] <Burgwork> well, I will try
[11:35] <Burgwork> if I can get sponsored, I am good
[11:36] <Burgwork> ajmitch: do you have an i810?
[11:37] <ajmitch> i915, but yes
[11:38] <ajmitch> using compiz with it
[11:39] <Burgwork> ah
[11:40] <Burgwork> are you using the modsetting branch?
[11:40] <Burgwork> I have 915 as well
[11:40] <ajmitch> not currently
[11:40] <ajmitch> I found that it didn't work so well with the modesetting branch
[11:40] <ajmitch> probably not updated for drm api changes or something silly
[11:41] <Burgwork> ah


[20:29] <raevol> HAPPY FRIDAY
[20:34] <pleia2> ++
[20:42] <raevol> pleia2: i submitted my talk proposal :3
[20:42] <raevol> fingers crossed
[20:42] <pleia2> raevol: yay :)


[01:43] -queuebot:#ubuntu-release- Unapproved: update-manager (jammy-proposed/main) [1:22.04.12 => 1:22.04.13] (core)
[01:55] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[02:01] <pabs3> bdrung has changed chdist to use Ubuntu devel https://salsa.debian.org/debian/devscripts/-/commit/c4f65475d3549e81dfce56426e947e579afa92eb
[02:01] <pabs3> but this causes warnings from apt: W: Conflicting distribution: http://archive.ubuntu.com/ubuntu devel InRelease (expected devel but got lunar)
[02:01] <pabs3> would it be possible for the 'devel' symlink to be turned into a proper suite finally?
[02:01] <pabs3> this was requested in these two old ubuntu-archive/apt bugs:
[02:01] -ubottu:#ubuntu-release- Commit c4f6547 in debian/devscripts "chdist: Default to Ubuntu devel release in sources.list example"
[02:01] <pabs3> https://bugs.launchpad.net/ubuntu/+bug/1821272
[02:01] -ubottu:#ubuntu-release- Launchpad bug 1728616 in apt (Ubuntu) "using 'devel' in sources.list causes apt-get update to fail" [Undecided, Opinion] [duplicate: 1821272]
[02:01] <pabs3> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1728616
[02:01] -ubottu:#ubuntu-release- Launchpad bug 1728616 in apt (Ubuntu) "using 'devel' in sources.list causes apt-get update to fail" [Undecided, Opinion]
[02:09] <cjwatson> Requires non-trivial Launchpad work and is unlikely to happen any time soon.
[02:10] <cjwatson> IMO that chdist change should be reverted.
[02:11] <cjwatson> It's a nice idea, but it's not a priority - I'd rather do other archive rework that will make this sort of thing easier in future (as we are currently doing).
[02:17] <cjwatson> (Well, maybe not reverted.  But not done like that.)
[02:27] -queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[02:34] <mwhudson> i just have a symlink in ~/.chdist :-)
[03:28] <pabs3> cjwatson: thanks for the info. since apt only warns not errors these days, maybe chdist can just be kept as-is until it gets fixed in the archive.
[07:44] <LocutusOfBorg> hello ubuntu-archive, uwsgi needs some NSB proposed cleanup, e.g.
[07:44] <LocutusOfBorg> old binaries left on amd64: uwsgi-plugin-jvm-openjdk-11, uwsgi-plugin-jwsgi-openjdk-11, uwsgi-plugin-rack-ruby3.0, uwsgi-plugin-ring-openjdk-11, uwsgi-plugin-servlet-openjdk-11 (from 2.0.20-4build1)
[07:45] <LocutusOfBorg> (every architecture except riscv64 where only uwsgi-plugin-rack-ruby3.0 has to go)
[07:47] <LocutusOfBorg> arraybolt3, the failure looks real
[07:47] <LocutusOfBorg> E: Unknown Error: '<class 'KeyError'>' ("The cache has no package named 'python3.11:ppc64el'")
[08:00] <LocutusOfBorg> arraybolt3, I think depending on python3.11 will fix the issue and it can be reverted once the big migration happens), for some reasons on my pc I can't install update-notifier-common without being forced to have python3.11
[08:01] <LocutusOfBorg> on testbed there is already python3.10, probably this is satisfying the dependency but not completely
[08:02] <LocutusOfBorg> maybe vorlon can hint that test for now?
[08:04] <LocutusOfBorg> and also python-cryptography can now go away on i386 maybe?
[08:04] <arraybolt3> LocutusOfBorg: I'd be happy to upload a new version of l-u-n with python3.11 as a dependency, if it works with python3.11.
[08:05] <LocutusOfBorg> arraybolt3, and then revert the upload? seems more a case of a one-time force badtest
[08:05] <arraybolt3> I'll test and make sure locally, and then push it. Really there's no need to undo it later in Lunar since python3.11 is what we're transitioning to anyway.
[08:05] <LocutusOfBorg> having an upload just to solve a temporary issue
[08:05]  * arraybolt3 looks at something real quick
[08:05] <LocutusOfBorg> arraybolt3, the problem is not in your package, its in every package using that apt-check as tool btw
[08:05] <LocutusOfBorg> so, fixing it looks meh
[08:06] <arraybolt3> Hmm, that makes sense.
[08:06] <arraybolt3> (Odd, if it's python3.11 that's missing... l-u-n depends on Python, should it not install python3.11 if -proposed is enabled or it's part of the autopkgtest triggers?)
[08:06] <arraybolt3> *enabled and pinned
[08:09] <arraybolt3> And I see the failure here (earlier test<EMAIL_ADDRESS>Same failure presumably, full python3.11 installed as part of the autopkgtest. Maybe I'm misunderstanding the error message.
[08:32] <LocutusOfBorg> (and distro-info now wants mypy)
[08:33] <LocutusOfBorg> bdrung, can we avoid mypy on i386? ^^
[09:34] -queuebot:#ubuntu-release- New sync: pyatem (lunar-proposed/primary) [0.8.2-1]
[10:01] <ginggs> bdmurray: i wasn't looking at finalcif in particular, that was just part of a mass retry
[10:01] <ginggs> bdmurray: i have added finalcif to big_packages for arm64 also
[10:04] <ginggs> bdmurray: i'm not actively looking OOM failures, but if i find a package that regressed everywhere except armhf, then i'll investigate
[10:15] <bdrung> LocutusOfBorg, uploaded distro-info 1.5 to skip mypy on i386
[10:24] <LocutusOfBorg> <3
[10:44] -queuebot:#ubuntu-release- Unapproved: software-properties (jammy-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[11:32] -queuebot:#ubuntu-release- Unapproved: software-properties (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[11:34] -queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [<IP_ADDRESS>.20 => <IP_ADDRESS>.21] (desktop-core, ubuntu-server)
[11:36] <seb128> tjaalton, hey, if you do a SRU shift today it would be great if you could checkout those ^ software-properties J/F/B uploads which are followup bugfixes updates to the recent SRU adding an Ubuntu Pro UI (which is currently halted due to some error reports)
[11:37] -queuebot:#ubuntu-release- Packageset: Added xdg-desktop-portal-lxqt to lubuntu in kinetic
[11:37] -queuebot:#ubuntu-release- Packageset: Added xdg-desktop-portal-lxqt to lubuntu in lunar
[11:47] <LocutusOfBorg> arraybolt3, the error changed
[11:47] <LocutusOfBorg> E: Unknown Error: '<class 'KeyError'>' ("The cache has no package named 'polkitd-pkla:amd64'")
[12:02] <seb128> tjaalton, and also update-manager J/F/B from Robert for similar reasons
[12:04] -queuebot:#ubuntu-release- New sync: xdg-terminal-exec (lunar-proposed/primary) [0~20221120-1]
[12:16] -queuebot:#ubuntu-release- New binary: harfbuzz [i386] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:17] -queuebot:#ubuntu-release- New binary: harfbuzz [amd64] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:17] -queuebot:#ubuntu-release- New binary: harfbuzz [s390x] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:18] -queuebot:#ubuntu-release- New binary: harfbuzz [arm64] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:19] -queuebot:#ubuntu-release- New binary: harfbuzz [ppc64el] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:22] -queuebot:#ubuntu-release- New binary: harfbuzz [armhf] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[13:15] -queuebot:#ubuntu-release- New binary: harfbuzz [riscv64] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[13:42] <vorlon> LocutusOfBorg: hi, what's the current state of things with pyqt5?
[13:48] <jbicha> vorlon: python-fabio/amd64 autopkgtest is giving us problems :(
[13:48] <LocutusOfBorg> this trigger worked for pyqt5
[13:48] <LocutusOfBorg> ['pyqt5/5.15.8+dfsg-2', 'lubuntu-update-notifier/0.5.3', 'python3-defaults/3.11.1-0ubuntu1', 'python3.11/3.11.1-2', 'policykit-1/122-3']
[13:53] <tjaalton> seb128: i'm actually off this week..
[13:55] <vorlon> LocutusOfBorg: done a run of NBS cleaning on -proposed
[13:56] <LocutusOfBorg> ta!
[14:01] <vorlon> LocutusOfBorg: python-cryptography: I tried to lose rsync and build-deps by dropping vestigial rsync dep from livecd-rootfs, but now https://people.canonical.com/~ubuntu-archive/germinate-output/i386.lunar/all shows linux also build-depends on it
[14:02] <vorlon> xnox: ^^ is that a real build-dep on rsync from linux or can it be dropped?
[14:02] <vorlon> xnox: oh.  Actually we only build linux-libc-dev from linux on i386, could the build-dep on rsync be arch-qualified?
[14:03] <vorlon> apw: ^^
[14:04] <jbicha> python-fabio worked :)
[14:05] <LocutusOfBorg> python-fabio worked
[14:05] <LocutusOfBorg> oops sorry
[14:06] <apw> vorlon, a good question.  we used to use rsync for copying source for linux-goldfish ... will check if it is still used.
[14:06] <vorlon> apw: thanks.  Trying to unpick python3-cryptography from i386 to avoid bootstrapping a mess of rust build-deps
[14:06] <apw> vorlon, very sensible.
[14:07] <LocutusOfBorg> thanks :D
[14:08] <apw> vorlon, ok it looks like we only actually use rsync in builds which have tools or docs
[14:09] <apw> vorlon, i believe i386 only produced linux-libc-dev which would not use either of those.
[14:09] <vorlon> apw: right
[14:09] <apw> vorlon, so i think the short answer should be we can arch limit it.
[14:10] <apw> vorlon, can you just assume we will do that, and i can push a change to our master for it
[14:10] <LocutusOfBorg> vorlon,
[14:10] <LocutusOfBorg> E: Unknown Error: '<class 'KeyError'>' ("The cache has no package named 'linux-headers-6.1.0-14:armhf'")
[14:10] <LocutusOfBorg> please hint lubuntu-update-notifier on armhf
[14:10] <LocutusOfBorg> I'm really tired to have to pick stuff randomly from proposed to let it pass
[14:11] <LocutusOfBorg> its not python3-defaults fault, and we need migration to see it auto heal
[14:11] <vorlon> apw: so from your perspective I can go ahead and nuke rsync/i386 from lunar?
[14:11] <vorlon> LocutusOfBorg: will look after I axe rsync
[14:11] <apw> vorlon, yeah, if we somehow are using it we will find something else to do the copy :)
[14:12] <LocutusOfBorg> vorlon, let me try another trigger with linux/6.1.0-14.14
[14:13] <vorlon> apw: thanks.  Cross-checking that nothing else that builds i386 binaries builds on it (which germinate won't tell me until the linux build-dep is gone..)
[14:15] <vorlon> hurray, nothing else needs it
[14:16] <apw> vorlon, proposing https://paste.ubuntu.com/p/T4Mc7yT4KV/ for the kernel
[14:17] <vorlon> apw: LGTM
[14:21] <seb128> tjaalton, no worry, I will try to see if there is any other SRU reviewers around, enjoy the rest of your holidays!
[14:22] <seb128> @SRUteam, could someone review the software-properties and update-manager SRU uploads in J/F/B queues? Those are bugfix followup updates to fix issues with the new Ubuntu Pro UIs (the current version in updates are halted due to new error reports so that's an attempt to get that feature unblock which is rather important)
[14:23] <vorlon> LocutusOfBorg: lubuntu-update-notifier/armhf badtest'ed
[14:24] <LocutusOfBorg> ta
[14:24] <vorlon> seb128: well I'm the other SRU vanguard for today, but as I'm in roadmap sessions I don't know whether I'll get to it before EOD
[14:25] <seb128> vorlon, right, well I tried at least, thanks
[14:36] <LocutusOfBorg> vorlon, it passed lubuntu-update-notifier with proposed pocket
[14:37] <LocutusOfBorg> so, unless I miss something, next britney run should see pyqt5 as candidate
[14:44] <vorlon> sweet
[14:47] <vorlon> looks like a britney run just finished and we're waiting for the next to kick off
[14:47] <vorlon> (otherwise I was going to kill any in-progress to not waste the time)
[15:05] <utkarsh21021> heey. Is there an example of a seed "inheriting" from another seed?
[15:12] <vorlon> utkarsh21021: STRUCTURE in any of the seed pods shows the inheritance; some of those seeds have associated Tasks, some do not
[15:17] <utkarsh21021> vorlon: is there any documentation around this?
[15:18] <vorlon> utkarsh21021: if there is it should be in germinate
[15:18] <utkarsh21021> I am looking for an example of seed (eg: server-minimal, desktop-minimal, et al), that'd be using other seeds as the base and then improving on top of it.
[15:21] <vorlon> utkarsh21021: an example of this might be the 'required' vs 'minimal' seeds in platform; required is a seed with no Task-* headers
[15:21] <vorlon> so its contents end up as direct dependencies of ubuntu-minimal when that package is germinated
[15:23] <vorlon> utkarsh21021: so e.g. you might move most of the contents of server-minimal into server-minimal-common and then have server-minimal and cloud-minimal both depend on it (in STRUCTURE) to have a common base definition that is itself not a metapackage
[15:27] <utkarsh21021> interesting!
[15:28] <utkarsh21021> I don't understand the headers (Task-*) at all, I'll look up to find more details about
[15:28] <utkarsh21021> also, to begin with, the cloud-minimal seed would look like:
[15:28] <utkarsh21021> * server-minimal
[15:28] <utkarsh21021> * openssh-server
[15:29] <utkarsh21021> that's what we want to try to see if images build and boot with that and then take it from there
[15:29] <vorlon> if you expect cloud-minimal to be a strict superset of server-minimal and you want both ubuntu-cloud-minimal and ubuntu-server-minimal to be installed as packages on the cloud images, yes
[15:30] <utkarsh21021> so perhaps server-minimal-common is not need at this point I believe, right?
[15:30] <vorlon> also you wouldn't list '* server-minimal' because that's not a package
[15:30] <vorlon> but '* ubuntu-server-minimal'
[15:32] <utkarsh21021> yes, correct. The metapackage.
[15:32] <vorlon> utkarsh21021: perhaps not needed, but there's certainly some stuff in server-minimal that you might think about not including in clouds; e.g. maybe multipath-tools doesn't belong?
[15:33] <utkarsh21021> yes!
[15:33] <vorlon> (and removing it has the nice benefit of not running that besotted daemon ;)
[15:33] <utkarsh21021> true.
[15:33] <vorlon> so based on past discussions, I would recommend you aim for a refactor into a -common
[15:35] <utkarsh21021> right now, we're using "server" as the base seed (ubuntu-server package in the cloud-image) and we'd like to go to server-minimal and then see how the seed behaves and then carve things out to make a cloud-minimal, should we have a lot of extra things
[15:36] <utkarsh21021> or do you think we should directly start with refactoring server-minimal into server-minimal-common and then make the two use it.
[15:36] <utkarsh21021> s/./?/ :)
[15:39] <vorlon> the latter is my suggestion.  you're going to wind up with a cloud-minimal package anyway, and there's no fundamental reason it should depend on server-minimal, the interdependencies can be left expressed in the seeds themselves
[15:47] <ricotz> LocutusOfBorg, hi, could you sync llvm-toolchain-16?
[15:52] <LocutusOfBorg> ricotz, why?
[15:53] <ricotz> LocutusOfBorg, I was looking for a clang-16 build to testing and noticed the recent debian upload
[15:56] <LocutusOfBorg> new britney run just started
[15:56] <LocutusOfBorg> lets see
[15:56] <LocutusOfBorg> ricotz, can't you upload in a ppa?
[15:56] <LocutusOfBorg> its an rc1
[15:56] <LocutusOfBorg> not sure if we should have it
[15:57] <LocutusOfBorg> vorlon, I think the uwsgi NBS cleanup didn't work?
[15:59] <vorlon> LocutusOfBorg: possibly it raced the publisher
[15:59] <LocutusOfBorg> oh... sad
[15:59] <LocutusOfBorg> also colord, what is preventing its migration? colord-sensor-argyll/i386 has unsatisfiable dependency
[16:00] <vorlon> $ m -s lunar-proposed -S uwsgi|grep 2.0.20-4build1
[16:00] <vorlon> $
[16:00] <vorlon> (m == rmadison)
[16:00] <ricotz> LocutusOfBorg, ok, I assumed llvm rc1 releases are usually uploaded
[16:00] <LocutusOfBorg> rmadison -u ubuntu uwsgi-plugin-jvm-openjdk-11 -s lunar
[16:00] <LocutusOfBorg>  uwsgi-plugin-jvm-openjdk-11 | 2.0.20-4 | lunar/universe | amd64, arm64, armhf, ppc64el, s390x
[16:00] <LocutusOfBorg> vorlon, ^^
[16:01] <vorlon> LocutusOfBorg: if it's dropped on all archs, it shouldn't need NBS removal from the release pocket until after the migration
[16:02] <LocutusOfBorg> oh ok
[16:02] <LocutusOfBorg> so it was blocked by tests not finish
[16:06] <LocutusOfBorg> so this run might be the good one to see big migration?
[16:06]  * LocutusOfBorg crosses fingers
[16:21] <utkarsh21021> vorlon: thank you! \o/
[16:24] <utkarsh21021> also, a fundamental question: if I want to depend on a seed, the (cleanest) way is to depend on its respective metapackage, no?
[16:24] <utkarsh21021> for eg: if I create a seed: cloud-minimal and I want to depend on server-minimal, the way to do so would be to add "* ubuntu-server-minimal" to it, no? or is there another way to inherit things?
[16:25] <utkarsh21021> do note that I'll go with the splitting route (server-minimal-common), but I am just asking the above to get my basics right. :)
[16:25] <vorlon> utkarsh21021: yes you would both declare the dependency on the metapackage and list the relationship in STRUCTURE
[16:27] <utkarsh21021> got it, thank you!
[16:40] <LocutusOfBorg> lets see what now is preventing migration
[17:22] -queuebot:#ubuntu-release- New binary: icu [amd64] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:22] -queuebot:#ubuntu-release- New binary: icu [i386] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:27] -queuebot:#ubuntu-release- New binary: icu [ppc64el] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:27] -queuebot:#ubuntu-release- New binary: icu [s390x] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:30] <bdmurray> ubuntu-sru: I'm looking at the update-manager SRU
[17:30] <ahasenack> update-notifier you mean?
[17:31] <ahasenack> we talked about it in standup, it looks like (to be verified) that most crashes are in the older version, not the new one
[17:31] <bdmurray> No, I mean update-manager per seb's ping
[17:31] <jbicha> ugh, graphviz rebuild is now in the way of the py3.11 migration
[17:31] <ahasenack> ah, ok
[17:32] <bdmurray> re update-notifier do you mean that the version numbering in the crash is wrong?
[17:33] <ahasenack> I have to look again, but the report was confusing. Even when you select a version in the dropdown menu, it shows crashes from other versions
[17:34] <bdmurray> Well if its something wonky with the Error Tracker or the data in it I'd be keen to hear / talk about it
[17:34] <ahasenack> so from here https://people.canonical.com/~ubuntu-archive/phased-updates.html
[17:34] <ahasenack> I click on the jammy +120 link
[17:34] <ahasenack> which lands me in https://errors.ubuntu.com/?release=Ubuntu%2022.04&package=update-notifier&period=day&version=<IP_ADDRESS>
[17:34] <ahasenack> the table however shows crashes from all over the place
[17:35] <ahasenack> then I click  on the top one, with most crashes
[17:35] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (jammy-proposed) [1:22.04.13]
[17:35] <ahasenack> and land at https://errors.ubuntu.com/problem/6eb58ea52b7701b979663a5c7bed4a8bac1c762d
[17:35] <ahasenack> so I started with jammy, <IP_ADDRESS>
[17:36] <ahasenack> then I find the first one of that version, and now I'm looking at an actual crash from that version
[17:37] <ahasenack> that just has a list of libraries, and that it was a segfault, no furter useful info so far
[17:37] <bdmurray> Looking at the bucket / problem url my question would be is 54.4 crashier than other versions?
[17:37] -queuebot:#ubuntu-release- New binary: icu [armhf] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:37] <bdmurray> er 54.5
[17:38] <ahasenack> you mean this? https://errors.ubuntu.com/problem/6eb58ea52b7701b979663a5c7bed4a8bac1c762d
[17:39] <bdmurray> yes
[17:39] <ahasenack> that particular page lists this error for a multitude of versions of update-notifier
[17:39] <ahasenack> what does "<number> U" mean? The "U" in particular?
[17:39] <bdmurray> right and is it happening more often with the latest version?
[17:39] <bdmurray> U is the pocket the package is from
[17:40] <ahasenack> only .3 is the most recent previous version listed, .4 isn't there. .3 has 784, .5 (latest) has 305
[17:40] <ahasenack> the release version (3.192.54) has a staggering 17k crashes
[17:41] <ahasenack> the graph for 22.04 on https://errors.ubuntu.com/problem/6eb58ea52b7701b979663a5c7bed4a8bac1c762d is raising, but the values are zero for all datapoints, it must be an average over a large amount of samples
[17:42] <bdmurray> I would put little stock in the graph
[17:42] <ahasenack> there are crashes reported today on the release version (22.04 3.192.54)
[17:42] -queuebot:#ubuntu-release- New binary: icu [arm64] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:42] <ahasenack> ah, the page loads more if you scroll down
[17:43] <jbicha> kanashiro[m]: please don't do more rebuilds for the ruby transition until the massive python3-defaults transition makes it out of -proposed
[17:44] <vorlon> yeah, reverting graphviz
[17:45] <vorlon> kanashiro[m]: you need to pay attention to what packages are already in -proposed before you upload them, these uploads are actively setting back progress on the migration
[17:46] <vorlon> I have posted rebuild scripts before to ubuntu-devel that do this analysis
[17:46] <jbicha> vorlon: ignition-math also interrupts. not sure about kamailio and grpc
[17:46] <vorlon> ok looking
[17:48] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[17:49] <kanashiro[m]> vorlon: sorry, my script is not smart enough to consider that (and I might have missed your script in ubuntu-devel). I am stopping the rebuild of non-ruby libraries (ruby-*)
[17:49] <vorlon> kamailio does via protobuf+libphonenumber
[17:50] <bdmurray> I reuploaded update-manager for focal due to debdiff noise
[17:53] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:<IP_ADDRESS>]
[17:55] <vorlon> kanashiro[m]: https://lists.ubuntu.com/archives/ubuntu-devel/2022-April/041994.html and there's the associated question about where such a tool should be distributed so people can find it :/
[17:58] <kanashiro[m]> vorlon: thank you for the link, I am saving the script locally for the future
[18:04] <tsimonq2> vorlon: IMO ubuntu-dev-tools
[18:05] <vorlon> tsimonq2: except ubuntu-dev-tools is being maintained in Debian (^_^) and doesn't get SRUed
[18:05] <vorlon> so it's fine to say "ubuntu-dev-tools" except for the bit where ubuntu-dev-tools as a whole is currently badly served by being a .deb
[18:15] <vorlon> reverts are published; killed current britney run
[18:16] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:<IP_ADDRESS>]
[18:17] <tsimonq2> vorlon: I'm not sure I see it going away as a deb but a snap could be useful... I wonder the same for ubuntu-archive-tools. I also wonder how common local modifications are
[18:18] <vorlon> ubuntu-archive-tools is less general audience and also takes frequent commits because of the i386 whitelisting stuff, I'm not keen to move that to a snap
[18:21] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:<IP_ADDRESS>]
[18:22] -queuebot:#ubuntu-release- New binary: icu [riscv64] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[18:28] <jbicha> vorlon: do you think grpc might need to be reverted too?
[18:28] <vorlon> jbicha: it didn't look like it to me, I haven't reverted it yet
[18:30] <LocutusOfBorg> vorlon, missing ignition-math
[18:30] <LocutusOfBorg> Implicit dependency: python3-defaults ignition-math (not considered)
[18:31] <vorlon> LocutusOfBorg: see above discussion
[18:32] <vorlon> eh except somehow when I copied ignition-math back I copied back the same broken version
[18:32] <vorlon> sigh
[18:34] <LocutusOfBorg> vorlon, thanks for understanding :) I did read the backlog, but I found the wrong version being in proposed and you said you restarted britney already, this is why I asked :)
[18:34] <LocutusOfBorg> keep up the good work!
[18:45] <bdmurray> ginggs: Do you have a process for rerunning tests that have always failed? e.g. I've just added r-cran-rstanarm to big_packages but retry-autopkgtest-regressions won't find it because its always failed
[18:47] <bdmurray> Oh, just use a trigger of migration-reference/0 ...
[20:02] <LocutusOfBorg> this britney run looks like failed to do the job
[20:02] <LocutusOfBorg> lets hope for next one :)
[20:25] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (jammy-proposed) [<IP_ADDRESS>]
[20:27] <vorlon> seems it didn't pick up the published graphviz either.  Yes, fingers crossed for the next one
[20:27] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (focal-proposed) [<IP_ADDRESS>]
[20:30] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [<IP_ADDRESS>.21]
[20:36] <bdmurray> ^ I've reviewed software-properties too
[20:39] <LocutusOfBorg> vorlon, does your script work if the system where its run is not a devel release?
[20:40] <LocutusOfBorg> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_"$release"_*Packages"
[20:40] <LocutusOfBorg> can't we fix the script to download such files maybe? WDYT?
[20:42] <vorlon> LocutusOfBorg: probably better to make it use chdist?
[20:43] <vorlon> LocutusOfBorg: but I always run it in a chroot, which ensures the uploads are also prepared in the same environment as the devel series
[20:43] <tsimonq2> vorlon: what's the license on your script? ;P
[20:45] <vorlon> tsimonq2: GPL3
[21:02] <LocutusOfBorg> vorlon, sigh
[21:03] <LocutusOfBorg> grpc 1.51.1-3build2
[21:03] <LocutusOfBorg> is it a problem w.r.t. migration?
[21:03] <LocutusOfBorg> oh backlog
[21:04] <vorlon> LocutusOfBorg: it doesn't look like it to me.  protobuf is a lib transition, old soname should be retained and grpc in release pocket should still be installable?
[21:05] <LocutusOfBorg> maaaaaaybe, who knows?
[21:05] <LocutusOfBorg> migrating libphonenumber8/8.12.57+ds-3build2/amd64 to testing makes kamailio-phonenum-modules/5.6.2-1build2/amd64 uninstallable
[21:05] <LocutusOfBorg> this wasn't there...
[21:05] <vorlon> should be addressed by the sync of the previous kamailio
[21:06] <LocutusOfBorg> lets cross fingers
[21:35] <vorlon> LocutusOfBorg: britney is definitely /trying/ to migrate it
[21:36] <vorlon> (which is why this run is longer)
[21:36] <vorlon> I: [2023-02-03T21:35:36+0000] -     got: 682+0: a-121:a-125:a-116:i-1:p-105:r-108:s-106
[21:36] <vorlon> I: [2023-02-03T21:35:36+0000] -     * arm64: gqrx-sdr, i2masschroq, libgnuradio-analog3.10.3, libgnuradio-blocks3.10.3, libgnuradio-digital3.10.3, libgnuradio-fft3.10.3, libgnuradio-filter3.10.3, libgnuradio-network3.10.3, libgnuradio-runtime3.10.3, libpappsomspp-widget0, msxpertsuite, msxpertsuite-minexpert, xtpcpp
[21:44] <vorlon> fwiw glibc has been uploaded; so if anything else needs rebuilt for python3-defaults to go through, it may get entangled and require some more finessing
[21:48] <LocutusOfBorg> did it migrate?
[21:49] <LocutusOfBorg> W: [2023-02-03T21:40:40+0000] - failed: amgcl is not a valid candidate (or it already migrated)
[21:49] <LocutusOfBorg> WTF
[21:50] <LocutusOfBorg> oh... it went through
[21:50] <LocutusOfBorg> if I got it right
[21:54] <vorlon> yes it migrated
[21:54] <LocutusOfBorg> YAY!
[21:54] <vorlon> I: [2023-02-03T21:40:37+0000] - final:
[21:54] <vorlon> -libgdal31/armhf,-libgit2-1.3/armhf,-libgit2-1.3/ppc64el,-libgit2-1.3/s390x,-libgnuradio-analog3.10.3/amd64,-libgnuradio-analog3.10.3/arm64,-libgnuradio-analog3.10.3/armhf,-libgnuradio-blocks3.10.3/amd64,-libgnuradio-blocks3.10.3/arm64,-libgnuradio-blocks3.10.3/armhf,-libgnuradio-digital3.10.3/amd64,-libgnuradio-digital3.10.3/arm64,-libgnuradio-digital3.10.3/armhf,-libgnuradio-fft3.10.3/amd64,-libgn
[21:54] <vorlon> uradio-fft3.10.3/arm64,-libgnuradio-fft3.10.3/armhf,-libgnuradio-filter3.10.3/amd64,-libgnuradio-filter3.10.3/arm64,-libgnuradio-filter3.10.3/armhf,-libgnuradio-network3.10.3/amd64,-libgnuradio-network3.10.3/arm64,-libgnuradio-network3.10.3/armhf,-libgnuradio-pmt3.10.3/amd64,-libgnuradio-pmt3.10.3/arm64,-libgnuradio-pmt3.10.3/armhf,-libgnuradio-runtime3.10.3/amd64,-libgnuradio-runtime3.10.3/arm64,-l
[21:54] <vorlon> ibgnuradio-runtime3.10.3/armhf,-libgsoap-2.8.117/amd64,-libhmat-oss2/amd64,-libhmat-oss2/arm64,-libhmat-oss2/armhf,-libhmat-oss2/riscv64,-libhmat-oss2/s390x,-libldap-2.5-0/i386,-liblimesuite20.10-1/amd64,-liblimesuite20.10-1/arm64,-liblimesuite20.10-1/armhf,-liblimesuite20.10-1/ppc64el,-liblimesuite20.10-1/riscv64,-libopenimageio2.3/amd64,-libopenimageio2.3/arm64,-libopenimageio2.3/armhf,-libopenima
[21:54] <vorlon> geio2.3/ppc64el,-libopenimageio2.3/riscv64,-libopenimageio2.3/s390x,-libosmocore18/amd64,-libosmocore18/arm64,-libosmocore18/armhf,-libosmocore18/ppc64el,-libosmocore18/s390x,-libosmogsm17/amd64,-libosmogsm17/arm64,-libosmogsm17/armhf,-libosmogsm17/ppc64el,-libosmogsm17/s390x,-libpoppler123/armhf,-libprimesieve10/amd64,-libprimesieve10/arm64,-libprimesieve10/armhf,-libprimesieve10/riscv64,-libprimes
[21:54] <vorlon> ieve10/s390x,-librte-eal22/amd64,-librte-eal22/arm64,-librte-eal22/ppc64el,-librte-ethdev22/amd64,-librte-ethdev22/arm64,-librte-ethdev22/ppc64el,-librte-hash22/amd64,-librte-hash22/arm64,-librte-hash22/ppc64el,-librte-kvargs22/amd64,-librte-kvargs22/arm64,-librte-kvargs22/ppc64el,-librte-mbuf22/amd64,-librte-mbuf22/arm64,-librte-mbuf22/ppc64el,-librte-mempool22/amd64,-librte-mempool22/arm64,-librte
[21:55] <vorlon> -mempool22/ppc64el,-librte-meter22/amd64,-librte-meter22/arm64,-librte-meter22/ppc64el,-librte-net22/amd64,-librte-net22/arm64,-librte-net22/ppc64el,-librte-rcu22/amd64,-librte-rcu22/arm64,-librte-rcu22/ppc64el,-librte-ring22/amd64,-librte-ring22/arm64,-librte-ring22/ppc64el,-librte-telemetry22/amd64,-librte-telemetry22/arm64,-librte-telemetry22/ppc64el,-libuhd4.2.0/amd64,-libuhd4.2.0/arm64,-libuhd4
[21:55] <vorlon> .2.0/armhf,-libuhd4.2.0/ppc64el,-libuhd4.2.0/riscv64,-libuhd4.2.0/s390x,adacgi,adasockets,ahven,akonadi,amgcl,analitza,android-platform-frameworks-base,anet,angelfish,apbs,apertium,apertium-lex-tools,apriltag,astra-toolbox,astroidmail,astrometry.net,autofdo,avogadrolibs,berkeley-express,blueman,borgbackup,borgbackup2,bornagain,brian,broker,btrfs-progs,bup,cegui-mk2,ceph,cg3,chatty,chemps2,clementine
[21:55] <vorlon> ,cluster3,compiz,createrepo-c,cryptominisat,cubemap,cura-engine,cwiid,dbusada,dde-qt5integration,deepin-image-viewer,deepin-qt5dxcb-plugin,deepin-terminal,device-tree-compiler,displaycal-py3,distcc,drgn,dtkcore,dtkgui,dtkwidget,dune-common,dune-functions,dune-geometry,dune-grid,dune-grid-glue,dune-istl,dune-localfunctions,dune-typetree,dune-uggrid,dupeguru,enki-aseba,evolution,evolution-data-server,
[21:55] <vorlon> evolution-ews,faiss,fcitx-qt5,fcitx5-qt,fife,flightgear,fontforge,freecad,freesas,gammaray,gcin,gdcm,geis,gemmi,genomicsdb,gensio,getfem,gfal2-bindings,gi-docgen,gnat,gnss-sdr,gnucash,gnudatalanguage,gnuradio,gobject-introspection,gprbuild,gr-air-modes,gr-fosphor,gr-funcube,gr-gsm,gr-hpsdr,gr-iqbal,gr-limesdr,gr-osmosdr,gr-radar,gr-rds,gr-satellites,graphviz,grass,grpc-java,gst-plugins-bad1.0,gtk4,h
[21:55] <vorlon> alide,haruna,harvest-tools,heartbeat,hedgewars,hfst,hime,horizon-eda,hplip,hugin,ignition-fuel-tools,ignition-fuel-tools4,ignition-gazebo,ignition-gui,ignition-launch,ignition-math,ignition-msgs,ignition-msgs5,ignition-sensors,ignition-transport,ignition-transport8,imath,insighttoolkit4,isospec,itinerary,jack-mixer,kaidan,kamailio,ki18n,kicad,kiconthemes,kineticstools,kirigami-addons,kirigami2,kitin
[21:56] <LocutusOfBorg> vorlon is our new BAAB (Britney as a Bridge)
[21:56] <LocutusOfBorg> :)
[21:56] <LocutusOfBorg> SCNR
[21:57] <sarnold> that was less horrific than I feared :)
[21:58] <vorlon> the lp copies are happening now, enjoy your email
[21:58]  * arraybolt3 's head starts spinning trying to figure out what flags are being set on who
[21:58] <sarnold> oh bother I didn't realize i +q but -b :( sorry there
[21:59] <sarnold> arraybolt3: apparently me neither, lol
[21:59] <sarnold> definitely lunchtime
[21:59] <sarnold> (and the flood continued to ops due to +z, there was less of it than I feared, heh)
[22:00] <LocutusOfBorg> might be a good time to autosync?
[22:00] <arraybolt3> \o/ Woohoo! Did that just unstick qtbase too?
[22:01] <LocutusOfBorg> it did indeed
[22:01] <LocutusOfBorg> also protobuf, gsoap, and a ton of stuff
[22:03] <LocutusOfBorg> also gnat indeed!
[22:11] <bdmurray> I uploaded glibc on behalf of schopin a little bit ago
[22:27] <vorlon> LocutusOfBorg: no autosync yet; as usual there were a collection of packages that failed to copy due to launchpad api overload, so we should let a second run through to clean everything up before copying more in
[22:28] <vorlon> so what happened to cause all these rust uninstallables?
[22:28] <vorlon> smells like a wrong removal
[22:32] <vorlon> ah heh it was my removal of the NBS librust-ahash+compile-time-rng-dev that broke everything
[22:34]  * vorlon shakes his fist at reverse-depends not handling virtual packages
[22:35] <tumbleweed> do you have a strategy for hanlding them in mind?
[22:36] <tumbleweed> because multiple providers can often satisfy the virtual package
[22:37] <vorlon> tumbleweed: I would rather they report too much than too little; reverse-depends already doesn't distinguish alternative depends that might be satisfied by another package
[22:37] <tumbleweed> that's true
[22:39] <vorlon> anyway, in this case I manually checked for reverse-build-depends but not reverse-depends; I'm confused by why the first wasn't sufficient, but I guess lesson learned
[22:42] <vorlon> copied graphviz, protobuf, ignition-math, kamailio back to -proposed (kanashiro[m])
[22:43] <vorlon> now afk
[22:56] <kanashiro[m]> vorlon: thank you!
[23:13]  * Eickmeyer[m] prays for a successful Ubuntu Studio build tomorrow with this migration
[23:23] -queuebot:#ubuntu-release- New binary: tiff [amd64] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:23] -queuebot:#ubuntu-release- New binary: tiff [i386] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:25] -queuebot:#ubuntu-release- New binary: tiff [ppc64el] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:25] -queuebot:#ubuntu-release- New binary: tiff [s390x] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:25] -queuebot:#ubuntu-release- New binary: tiff [armhf] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:26] -queuebot:#ubuntu-release- New binary: tiff [arm64] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:59] -queuebot:#ubuntu-release- New binary: tiff [riscv64] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)