[06:10] <ScottAM> Hello I am looking for some help with my maas setup... I have set this up before using various solutions, however i have always used the same base package:  apt install maas
[06:10] <ScottAM> this time is a bit different I want to seperate the regional controller and the cluster controller
[06:11] <ScottAM> I have done this but my boot image sources are not found
[06:11] <ScottAM> simply put I get this error Error: No boot sources provide Ubuntu images.
[06:12] <ScottAM> does anyone know how to fix this?
[07:02] <catbus1> ScottAM: what's the exact error message?
[07:10] <catbus1> a google search leads to https://bugs.launchpad.net/maas/+bug/1375953, which is fixed last September.
[07:11] <ScottAM> The exact error message is   Error: No boot sources provide Ubuntu images
[07:12] <ScottAM> I did see that Bug but it doesn't seem to be the case
[07:12] <ScottAM> I just installed the system and set the admin password
[07:15] <ScottAM> There doesn't seem to be any different install instructions for seperate setups as opposed to setups that are configured on different servers
[07:46] <ScottAM> been researching a bit... is it a problem in a setup where the region-controller and the cluster-controller are on different servers if the maas command only exists on the cluster controllers?


[18:25] <mdeslaur> tjaalton: hey, you removed the security update in focal's xorg-server when you backported the new upstream version
[19:06] <tjaalton> mdeslaur: hmm?
[19:06] <tjaalton> mdeslaur: if so, I'll check tomorrow and reupload
[19:07] <tjaalton> was supposed to be a backport of the groovy package, which should be uptodate?
[19:15] <tjaalton> mdeslaur: what's missing? the new upstream release should have what got dropped, no?
[19:15] <tjaalton> the patches that got dropped I mean
[19:18] <mdeslaur> tjaalton: no, the patches were required in groovy too for the same version: https://launchpad.net/ubuntu/+source/xorg-server/2:1.20.9-2ubuntu1.1
[19:19] <tjaalton> mdeslaur: but the focal backport is based on that
[19:19] <mdeslaur> looks like we have a 1.1 mismatch, not sure how that happened
[19:20] <tjaalton> hmm
[19:20] <tjaalton> huh
[19:23] <tjaalton> both uploaded the same day
[19:23] <tjaalton> and I can't see mine getting rejected
[19:23] <tjaalton> but apt-get source does pull the security updae
[19:23] <tjaalton> update
[19:23] <tjaalton> shit
[19:23] <mdeslaur> unfortunate timing
[19:24] <mdeslaur> so I guess groovy is missing whatever that sru was, and focal is missing the CVE fixes
[19:24] <tjaalton> I guess this needs to go via the security pocket?
[19:24] <mdeslaur> either -updates or -security is fine, since the issue is only in -updates
[19:25] <mdeslaur> I can push it to -security on monday if that's easier
[19:27] <tjaalton> either is fine by me, but someone would need to review my upload anyway
[19:27] <tjaalton> I can do that now
[19:27] <tjaalton> uploading the fix that is
[19:36] <mdeslaur> ok
[19:37] <tjaalton> do you have powers to review it from the sru queue?
[19:38] <mdeslaur> no, someone from sru would need to do that
[19:38] <mdeslaur> well wait, what exactly are you asking? if I would look at it, or approve it?
[19:40] <tjaalton> approve
[19:40] <mdeslaur> no, I can't do that
[19:44] <tjaalton> right
[19:58] <tjaalton> ok, I self-rejected my upload back then because it had the wrong buglink
[19:58] <tjaalton> but I can't figure out what the correct one would be
[19:59] <tjaalton> I'll look into this tomorrow..
[20:00] <tjaalton> mdeslaur: thanks for the heads-up, and sorry about the mess /o\
[21:57] <mdeslaur> tjaalton: no problem! :)


[17:29] -queuebot:#ubuntu-ci-eng- rikmills, https://bileto.ubuntu.com/#/ticket/4913 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[18:14] -queuebot:#ubuntu-ci-eng- rikmills, https://bileto.ubuntu.com/#/ticket/4913 Pending binary packages
[18:54] -queuebot:#ubuntu-ci-eng- rikmills, https://bileto.ubuntu.com/#/ticket/4913 Diff missing
[21:47] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4906 Proposed pocket


[19:11] <ChinnoDog> JonathanD: lurker
[20:37] <JonathanD> Yes.
[20:37] <JonathanD> Yes I am.
[20:45] <ChinnoDog> Are you coming to our meetings?
[22:48] <ChinnoDog> JonathanD:
[22:55] <JonathanD> in DC?
[22:55] <JonathanD> unlikely :P
[22:56] <JonathanD> I'm here to troll for geeknic-goers.
[23:00] <ChinnoDog> JonathanD: I see how it is. You won't come here but you want us to go there.
[23:09] <JonathanD> heh :P
[23:10] <JonathanD> ChinnoDog: have a geeknic, I'll probably go to it :P
[23:13] <ChinnoDog> We could have a geeknic at the zoo. But, no grills allowed...
[23:13] <ChinnoDog> We could have a geeknic at the park right here if I am the one planning it. :-D


[05:05] <jam> hey wallyworld_, how's it going?
[05:05] <wallyworld_> g'day
[05:05] <wallyworld_> ell thanks
[05:05] <wallyworld_> well
[05:05] <jam> wallyworld_: any reviews, etc, I can help you out with?
[05:05] <jam> (My review email box sometimes has 400 things in it from just a couple days. Unforunately, I'm in too many groups on LP :)
[05:06] <wallyworld_> i've landed everything, am working on some stuff. i'd be happy to fill you in via mumble since i will not be at the meeting
[05:06] <jam> wallyworld_: sure
[10:08] <rogpeppe> if anyone has some space to look at this, a review would be very much appreciated: https://codereview.appspot.com/7178044/
[10:32] <dimitern> what's the idea with panicWrite() -> writeCertAndKey called unexpectedly in the bootstrap tests?
[10:32] <dimitern> it seems it'll fail always in the normal case
[10:34] <dimitern> rogpeppe: can you help here? ^^
[10:35] <rogpeppe> dimitern: hmm, i haven't seen that. looking.
[10:35] <dimitern> rogpeppe: so there's that callback in environs.Bootstrap(Env, uploadTools, writeCertAndKey())
[10:36] <dimitern> rogpeppe: which in the tests is always panicWrite instead
[10:36] <rogpeppe> dimitern: yeah. that will only happen if the environment config doesn't have a CA cert and key
[10:36] <rogpeppe> dimitern: so if that's happening in the openstack tests, i'd guess you've got a config without those in
[10:36] <dimitern> rogpeppe: so for the tests what I'm supposed to do - remove the ca/key from ~/.juju ?
[10:37] <rogpeppe> dimitern: no, pass the testing CA cert and key in the env config
[10:37] <dimitern> rogpeppe: missing? ahaa ok
[10:37] <rogpeppe> dimitern: i *think* that's right. give me a few moments to check.
[10:38] <rogpeppe> dimitern: yeah, that seems about right.
[10:38] <rogpeppe> dimitern: grep for CACert in environs/ec2/*.go
[10:39] <dimitern> rogpeppe: I saw it - authorized-keys as well perhaps?
[10:39] <rogpeppe> dimitern: maybe
[10:40] <rogpeppe> dimitern: not for live tests
[10:40] <rogpeppe> dimitern: you actually want it to use the authorized keys from your home directory for live tests, so you can ssh to the started instances
[10:41] <dimitern> rogpeppe: I see, ok - now I added these conf keys and it passed
[10:41] <rogpeppe> dimitern: cool
[10:54] <aram> hi.
[10:56] <rogpeppe> aram: hiya
[11:00] <dimitern> aram: hey
[11:01] <dimitern> rogpeppe: so after the bootstrap is done, we're trying to open the state and connect to the bootstrap machine - how is this simulated in the local live tests?
[11:15] <dimitern> and why is mongo on my machine defaulting to 27017 and juju expects it to be at :37017 ?
[11:16] <rogpeppe> dimitern: we don't simulate that in the local live tests AFAIR
[11:17] <rogpeppe> dimitern: we decided that trying to simulate the cloud-init stuff was going too far
[11:17] <dimitern> rogpeppe: but I can see things like: [LOG] 18.27607 JUJU environs/openstack: started instance "8cd71439-c5f6-47bd-94e1-f7693d47f11a"
[11:17] <dimitern> opening connection
[11:17] <dimitern> [LOG] 23.11676 JUJU environs/openstack: waiting for DNS name(s) of state server instances [8cd71439-c5f6-47bd-94e1-f7693d47f11a]
[11:17] <dimitern> [LOG] 23.11794 JUJU state: opening state; mongo addresses: ["localhost:27017"]; entity ""
[11:17] <dimitern> [LOG] 23.11974 JUJU state: connecting to <IP_ADDRESS>:27017
[11:18] <rogpeppe> dimitern: does the connection succeed?
[11:18] <dimitern> I changed 37017 to 27017 to match my running mongo and StateInfo to return localhost
[11:18] <dimitern> no
[11:18] <dimitern> I'm lost.. what has to happen at this step in BootstrapAndDeploy ?
[11:18] <dimitern> it's still a test (live, if local)
[11:19] <rogpeppe> dimitern: if you look at the ec2 live tests, you'll find that LiveTests.CanOpenState is false for the local "live" tests
[11:19] <dimitern> rogpeppe: got you! right this should work then :)
[11:19] <rogpeppe> dimitern: and BootstrapAndDeploy looks at CanOpenState to see if it can connect to the state
[11:19] <rogpeppe> dimitern: BootstrapAndDeploy can't work unless the relevant agents are started too
[11:20] <dimitern> rogpeppe: so it's only a truly live test then?
[11:20] <rogpeppe> dimitern: which we don't do in the local tests - we test them independently
[11:20] <rogpeppe> dimitern: yes
[11:20] <rogpeppe> dimitern: although it does test some stuff, i guess
[11:20] <dimitern> rogpeppe: I see
[11:21] <rogpeppe> dimitern: (in the local case)
[11:21] <dimitern> rogpeppe: and HasProvisioner = false as well for local tests?
[11:22] <rogpeppe> dimitern: yeah
[11:22] <rogpeppe> dimitern: i did once suggest that we could have the local tests start the agents too, but it was considered not worth it.
[11:26] <jam> dimitern: I'm pretty sure Mongo gets set up directly by the test infrastructure. Which is why it isn't on the port you expected.
[11:26] <dimitern> jam: it seems something like that, anyway I'm skipping these now
[11:27] <jam> dimitern: cloudinit_test.go spawns it with "--port 37017"
[11:27] <dimitern> jam: yeah, I saw this
[11:27] <dimitern> jam: but was still confusing at first
[11:27] <niemeyer> Good morning
[11:28] <dimitern> niemeyer: morning
[11:29] <dimitern> jam: shall we start?
[11:29] <jam> dimitern: I'm on
[11:29] <jam> mgz: poke
[11:29] <jam> wallyworld won't be making it, movie night
[11:39] <mgz> dimitern: the other part (talking to the metadata service) is in juju.unit.address.OpenStackUnitAddress
[11:57] <dimitern> finally, openstack bootstrap - https://codereview.appspot.com/7181046/
[11:59] <rogpeppe> niemeyer: hiya
[12:02] <niemeyer> rogpeppe: Just finished a pass on https://codereview.appspot.com/7178044/
[12:02] <rogpeppe> niemeyer: thanks
[12:09] <rogpeppe> niemeyer: i'm not entirely sure of the best approach to the two-error thing
[12:09] <rogpeppe> niemeyer: if we get ErrDead and some other error, which error should we act on?
[12:10] <rogpeppe> niemeyer: and which error should we return from Run?
[12:11] <niemeyer> rogpeppe: Both are good questions.. "whatever" is probably not the right answer. :-)
[12:11] <niemeyer> rogpeppe: I'll step out to grab some coffee and ponder meanwhile
[12:11] <rogpeppe> niemeyer: runTasks returns the first error and logs the others
[12:11] <rogpeppe> niemeyer: ok
[12:11] <niemeyer> rogpeppe: Think about how both are handled meanwhile
[12:11] <niemeyer> rogpeppe: So we can talk
[12:34] <niemeyer> rogpeppe: SO, how do we handle ErrDead vs. other errors?
[12:35] <rogpeppe> niemeyer: i think we could make an importance hierarchy of errors, perhaps
[12:35] <rogpeppe> niemeyer: ErrDead > UpgradedError > * > nil
[12:35] <niemeyer> rogpeppe: How do we handle ErrDead vs. other errors today in that context?
[12:35] <rogpeppe> niemeyer: we just choose the first one, except that UpgradedError gets priority
[12:36] <niemeyer> rogpeppe: You mean we never compare an error to ErrDead?
[12:36] <niemeyer> rogpeppe: Why do we even have it?
[12:36] <rogpeppe> niemeyer: we do, in order to return nil from Run if the error is ErrDead
[12:37] <rogpeppe> niemeyer: because if the entity has died, we just exit normally
[12:37] <niemeyer> rogpeppe: Yes, and that means we actually exit from the process
[12:37] <rogpeppe> niemeyer: and in that case, we probably don't care if someone wants to upgrade us, or other errors.
[12:37] <rogpeppe> niemeyer: yup
[12:38] <niemeyer> rogpeppe: I think we do care we've seen an error, to log it if nothing else.. but indeed ErrDead should not be dropped silently
[12:38] <rogpeppe> niemeyer: i've been toying with the idea of letting the tomb package have some sort of control over error precedence, rather than just discarding later erorrs
[12:39] <rogpeppe> niemeyer: for instance, one might give it an error-precedence comparison function.
[12:39] <niemeyer> rogpeppe: Seems like unnecessary complexity
[12:39] <rogpeppe> niemeyer: you're probably right
[12:39] <niemeyer> rogpeppe: Let's just solve the problem at hand
[12:40] <rogpeppe> niemeyer: there are two places we'd want to solve it in: runTasks and the machine agent top level. both are really a similar thing.
[12:42] <rogpeppe> niemeyer: and there's also the issue of the "configuration does not have state server cert/key" fatal error.
[12:43] <rogpeppe> niemeyer: i wonder if we could define func IsFatal(err error) bool
[12:43] <rogpeppe> niemeyer: then we  wouldn't have to kill the tomb in the above place
[12:44] <rogpeppe> niemeyer: which means we don't run the risk of squashing those errors.
[12:44] <niemeyer> rogpeppe: Isn't that unrelated to the actual problem?
[12:44] <niemeyer> rogpeppe: ErrDead must not be dropped silently.. there are two possible errors, and one of them is being dropped silently. That sounds rather easy.
[12:45] <rogpeppe> niemeyer: actually there are n possible errors, one for each task (if you look at runTasks)
[12:45] <rogpeppe> niemeyer: we don't want to drop UpgradedError either
[12:46] <niemeyer> rogpeppe: I'm talking about that loop
[12:46] <niemeyer> rogpeppe: There are only two possible errors there
[12:46] <rogpeppe> niemeyer: the loop in MachineAgent.Run ?
[12:46] <niemeyer> rogpeppe: The one where the review comment was made
[12:49] <rogpeppe> niemeyer: it's possible that we can drop ErrDead silently in runTasks too
[12:49] <rogpeppe> niemeyer: but maybe we don't care that much.
[12:50] <niemeyer> rogpeppe: There's already logic there to pick a proper error
[12:50] <niemeyer> rogpeppe: If it's broken, it should be fixed
[12:50] <niemeyer> rogpeppe: If it isn't..
[12:50] <rogpeppe> niemeyer: it just chooses the first error (unless something returned an UpgradedError)
[12:51] <rogpeppe> niemeyer: tbh dropping ErrDead in favour of UpgradedError isn't a problem
[12:51] <rogpeppe> niemeyer: it'll just mean it'll restart only to die with ErrDead
[12:52] <niemeyer> rogpeppe: It's also cheap to do it right, but that's really unrelated to the problem at hand
[12:52] <rogpeppe> niemeyer: the loop in MachineAgent.Run is the moral equivalent of the loop in runTasks IMHO - both loops are multiplexing more than one task and returning the result
[12:53] <rogpeppe> niemeyer: which is why i'm thinking about both of them here
[12:53] <niemeyer> rogpeppe: Sure, whatever works
[12:54] <rogpeppe> niemeyer: i think i know a decent way to solve the problem.
[12:55] <rogpeppe> niemeyer: it's kinda funny that we'll end up ignoring the tomb.Err() value, but i think we've gone beyond its capabilities here.
[12:56] <niemeyer> rogpeppe: tomb.Err should be whatever error took precedence
[12:56] <rogpeppe> niemeyer: tomb.Err is always going to be the first error that happened to kill the tomb
[12:56] <niemeyer> rogpeppe: Sure, and that's great
[12:57] <rogpeppe> niemeyer: that's not necessarily the error we're going to use though
[12:57] <niemeyer> rogpeppe: If it was killed ahead of time
[12:57] <niemeyer> rogpeppe: All errors are used
[12:57] <niemeyer> rogpeppe: Some of them are logged, others returned
[12:59] <rogpeppe> niemeyer: sure. tomb.Err won't be the error that took precedence though.
[12:59] <niemeyer> rogpeppe: Yes, nevermind.. I think we both understand the context
[13:00] <rogpeppe> niemeyer: yeah.
[13:01] <dimitern> are we having the weekly meeting?
[13:01] <dimitern> it seems no one but me is there.. at least using the link in the calendar
[13:01] <rogpeppe> dimitern: i guess so.
[13:01] <rogpeppe> dimitern: i'll join now
[13:02] <aram> what is the url?
[13:02] <rogpeppe> aram: https://plus.google.com/hangouts/_/33acfc2c8af8792568274fa110371db956f9fde7
[13:02] <aram> thanks
[13:03] <rogpeppe> niemeyer: meeting?
[13:04] <niemeyer> Yep, let's do it
[13:14] <rogpeppe> mramm: meeting?
[13:14] <aram> mramm: https://plus.google.com/hangouts/_/33acfc2c8af8792568274fa110371db956f9fde7
[14:44] <rogpeppe> niemeyer: PTAL https://codereview.appspot.com/7178044/
[14:44]  * rogpeppe goes for some lunch
[14:50] <niemeyer> rogpeppe: LGTM
[14:50] <niemeyer> rogpeppe: Thanks for the changes
[14:57] <rogpeppe> niemeyer: cool, thanks for the prompt review
[15:25] <rogpeppe> niemeyer: ping
[15:44] <niemeyer> rogpeppe: Hey
[15:44] <rogpeppe> niemeyer: i just wanted to run an idea past you
[15:44] <niemeyer> rogpeppe: Of course
[15:46] <rogpeppe> niemeyer: i find myself replacing state.Info with a pair of (state.Info, api.Info) everywhere, and i'm wondering if it would be bad to just add a state.Info member to api.Info, to be removed when we can use the API on its own.
[15:46] <niemeyer> rogpeppe: I think we covered that before
[15:46] <rogpeppe> niemeyer: that was the connection itself
[15:46] <rogpeppe> niemeyer: this is just the info, which i think is more reasonable
[15:47] <rogpeppe> niemeyer: as it's got no methods, and i wouldn't embed it
[15:47] <niemeyer> rogpeppe: I think the reasoning is the same
[15:48] <rogpeppe> niemeyer: could you remind me of the reason this is a bad idea
[15:48] <rogpeppe> ?
[15:51] <niemeyer> rogpeppe: Sure: http://pastebin.ubuntu.com/1559918/
[15:52] <rogpeppe> niemeyer: i think there's a significant difference between Info and State here.
[15:52] <niemeyer> rogpeppe: The idea is exactly the same
[15:52] <rogpeppe> niemeyer: we're going to need the state.Info around until the very last remnant goes
[15:52] <rogpeppe> niemeyer: because it's used in setting up the thing that everything talks to
[15:52] <niemeyer> rogpeppe: Disagree.. you only need it in places where the API doesn't cover
[15:53] <rogpeppe> niemeyer: you need it in the top-level places where the state is connected to - in juju.Conn and at the top level in jujud. those places are used by everything.
[15:54] <rogpeppe> niemeyer: so as long as there's something using it, you'll still need it, AFAICS
[15:54] <niemeyer> rogpeppe: The top level in jujud is "used by everything"?
[15:55] <rogpeppe> niemeyer: the top level in jujud creates a *state.Info, which is then passed to all the tasks.
[15:55] <rogpeppe> oops
[15:55] <rogpeppe> creates a *state.State, of course
[15:55] <rogpeppe> niemeyer: as long as we have one task that needs a *state.State, we'll need the *state.Info.
[15:56] <niemeyer> rogpeppe: That's totally fine?
[15:56] <rogpeppe> niemeyer: but at that point we could just remove the StateInfo field from api.Info
[15:56] <rogpeppe> niemeyer: with considerably less disruption to the APIs
[15:56] <niemeyer> rogpeppe: That will mean that every single entity in the system that has a StateInfo will have the api.Info, even if it doesn't care about it
[15:56] <rogpeppe> niemeyer: no
[15:56] <niemeyer> rogpeppe: It's exactly the same motivation described before
[15:57] <niemeyer> Dec 12 09:55:31 <niemeyer>	rogpeppe: It's pretty much impossible to tell if things you're passing apiState in actually are ported or not, without investigating all calls
[15:57] <niemeyer> Dec 12 09:56:09 <niemeyer>	rogpeppe: In general, when something is ported we can actually *port* it
[15:57] <rogpeppe> niemeyer: every single entity in the system that has a api.Info will have state.Info
[15:57] <rogpeppe> niemeyer: but not vice versa
[15:58] <niemeyer> rogpeppe: Sorry, my opinion is the same.. if you want to talk to William and get agreement on something else, please feel free to move on with it
[15:58] <niemeyer> rogpeppe: I would just be explicit myself
[15:58] <rogpeppe> niemeyer: ok, fair enough.
[15:58] <rogpeppe> niemeyer: in which case, does the following change to Environ make sense to you? http://paste.ubuntu.com/1559933/
[16:00] <rogpeppe> niemeyer: i was considering having two entry points, StateInfo and APIInfo, but they duplicate almost all of their work.
[16:00] <rogpeppe> niemeyer: and we'll only want one eventually
[16:00] <niemeyer> rogpeppe: It is kind of weird.. but that method always was
[16:00] <rogpeppe> niemeyer: StartInstance?
[16:00] <niemeyer> rogpeppe: I think eventually it should be returning something environ-specific
[16:00] <niemeyer> rogpeppe: StateInfo
[16:01] <rogpeppe> niemeyer: then the environ would connect to the state?
[16:01] <niemeyer> rogpeppe: Same thing about StartInstance
[16:01] <niemeyer> rogpeppe: But I think this change looks fine for the moment, yeah
[16:02] <niemeyer> rogpeppe: Those other things are things to think in the future
[16:02] <niemeyer> rogpeppe: Why does it need both, btw?
[16:03] <rogpeppe> niemeyer: how else does a new instance know how to connect to the API?
[16:03] <niemeyer> rogpeppe: Supposedly there's a lot of duplication in them.. what's the information that is unique to each?
[16:03] <rogpeppe> niemeyer: the port
[16:04] <rogpeppe> niemeyer: and, currently, api.Info holds a single address, not a list
[16:04] <niemeyer> rogpeppe: Hmm.. any particular reason?
[16:05] <rogpeppe> niemeyer: just that it was easy to get going, and i'm not quite sure how we'll make use of an address list as an API client.
[16:05] <rogpeppe> niemeyer: perhaps just choose one at random
[16:06] <niemeyer> rogpeppe: I'm not sure either, but it's quite clear that this will happen
[16:06] <rogpeppe> niemeyer: but given that nothing has more than one address currently, it seems a bit like overkill
[16:06] <niemeyer> rogpeppe: Yes, probably random
[16:06] <rogpeppe> niemeyer: it'll be easy enough to change when HA comes in
[16:06] <niemeyer> rogpeppe: I'd not do thta
[16:06] <niemeyer> rogpeppe: It's easy to overlook it
[16:07] <niemeyer> rogpeppe: For example, the data file in Amazon holds a list
[16:07] <niemeyer> rogpeppe: In S3, that is
[16:07] <niemeyer> rogpeppe: Changing to multiple addresses is just a matter of adding more of them, and that won't break previous clients
[16:07] <rogpeppe> niemeyer: i'd never intended to change that, just the Addr field in api.Info
[16:08] <niemeyer> rogpeppe: My point is that it's easy to overlook stuff up if you hide the fact this is *intended* to be a list
[16:08] <rogpeppe> niemeyer: but if you think it should be changed now, i'll do that
[16:09] <niemeyer> rogpeppe: Using the single item in a list is easy.. backporting data files and making sure previous clients continue to work correctly when you provide a list isn't
[16:15] <niemeyer> I'm going to step out to take Otávio to his ear check-up
[16:15] <niemeyer> Back in a bit
[16:26] <hazmat> niemeyer, ping
[17:33]  * niemeyer is back
[17:44] <rogpeppe> niemeyer: i'm presuming the same reasoning applies to juju.Conn too, so i'm making juju.APIConn which is the same as juju.Conn but holds api.State
[17:44] <niemeyer> rogpeppe: Uh?
[17:45] <rogpeppe> niemeyer: the alternative is to have juju.Conn hold both *state.State and *api.State
[17:45] <niemeyer> rogpeppe: I didn't imagine we'd be forking Conn
[17:45] <rogpeppe> niemeyer: your reasoning applies there too, i think
[17:45] <niemeyer> rogpeppe: I don't see how..
[17:46] <niemeyer> rogpeppe: Conn is what we want to port..
[17:46] <rogpeppe> niemeyer: if we're just passing around juju.Conn, with both connections in it, how can we know easily what's left to port?
[17:47] <niemeyer> rogpeppe: Whatever uses juju.Conn will continue using juju.Conn
[17:47] <rogpeppe> niemeyer: ok, what about things that use Conn.State directly?
[17:47] <niemeyer> rogpeppe: Either return both, or add an APIState method
[17:47] <rogpeppe> niemeyer: it's a field
[17:47] <niemeyer> rogpeppe: The latter is probably better
[17:48] <niemeyer> rogpeppe: Sure, whatever
[17:49] <rogpeppe> niemeyer: i actually started doing it that way, but thought you'd prefer it separate. and actually, the code *is* quite a bit cleaner when it's kept separate.
[17:50] <niemeyer> rogpeppe: and then duplicate all the methods of Conn, and all the tests?
[17:50] <rogpeppe> niemeyer: each method of Conn will need to be ported individually
[17:50] <bigjools> has go got an x509 library?
[17:50] <rogpeppe> niemeyer: because most of them have state-related types in the signatures
[17:50] <niemeyer> rogpeppe: Yes, and it can be ported on the same Conn
[17:51] <niemeyer> bigjools: Yep
[17:51] <bigjools> cool, ta
[17:51] <niemeyer> bigjools: In the standard library.. have a look under crypto
[17:51] <bigjools> sounds good, ta
[17:51] <niemeyer> bigjools: http://golang.org/pkg/crypto/
[17:52] <rogpeppe> bigjools: we do a fair amount of x509 hackery in juju-core - grep for x509
[17:52] <niemeyer> rogpeppe: Still.. the idea is being able to port one at a time
[17:52] <niemeyer> rogpeppe: But, I really don't mind too much, to be honest..
[17:52] <bigjools> ya, we need to use it for Azure
[17:52] <niemeyer> rogpeppe: It feels like a lot of work to be introducing a second juju.Conn and duplicating all the tests and porting all the client sites
[17:52] <niemeyer> rogpeppe: If you feel like that's easier..
[17:53] <rogpeppe> niemeyer: i think it may be
[17:54] <rogpeppe> niemeyer: i'll see how it goes.
[17:54] <rogpeppe> niemeyer: currently it certainly seems cleaner than interleaving the code,  but i may well change my mind!
[17:54] <niemeyer> rogpeppe: If there are two methods, you'll be unable to port one of them at a time, for example..
[17:55] <niemeyer> rogpeppe: But you have better context than I do, so go for it
[17:55] <rogpeppe> niemeyer: it would be awkward the other way around too - e.g. AddService returns *state.Service, which AddUnits expects as an argument
[17:56] <niemeyer> rogpeppe: Yeah, and maybe the API is not that big anyway
[17:57] <rogpeppe> niemeyer: i think so. we'll see
[17:57] <rogpeppe> niemeyer: i've gotta go now. good progress made today, BTW.
[17:57] <rogpeppe> g'night all
[17:59] <niemeyer> rogpeppe: Great to hear!
[17:59] <niemeyer> rogpeppe: It looks like things are progressing very well indeed
[17:59] <niemeyer> rogpeppe: Have a good evening there
[20:28] <bigjools> What are the requirements of provider storage now?  What needs to be stored and what key is used to access it?


[04:35] <CyberKnet> I just switched from 4x250gb raid 5 on a 3ware escalade 9500S-4LP to a single (new) 1.5tb drive directly to the motherboard - removed the old drives from the system ... but the new hard drive keeps ... disappearing
[04:35] <CyberKnet> rebooting brings the hard drive back online
[04:36] <CyberKnet> the drive is still mounted, but running ls in the directory yields ls: cannot open directory: Input/output error
[04:37] <CyberKnet> (before the reboot, that is)
[04:40] <CyberKnet> Anyone have any ideas what could cause this, or how I could go about finding out what is causing this?
[04:40] <CyberKnet> I looked in dmesg, and I do see ata-related things - hard resetting, and link coming up at 1.5gb
[04:45] <CyberKnet> smart reports the disk is healthy
[04:54] <CyberKnet> Hmmm... well, I am going to install another drive of the same make and model, and see if I get any difference there
[12:22] <stuarticus> Hi, can anyone let me know how "safe" it is to run a distribution upgrade? I'm a bit nervous given I currently have a working system! Has anyone tried and had any problems/successes?
[13:10] <stuarticus> I take it that's a no?
[13:59] <CyberKnet> stuarticus: You know the old adage...
[13:59] <CyberKnet> If it aint broke...
[14:00] <stuarticus> Kind of what I was thinking! I have been quite impressed with 10.04 so far on my laptop though and thought it might be worth it
[14:00] <stuarticus> Guess there's no big hurry
[19:57] <slaine> anything other than update-manager -d required to upgrade a mythbuntu box to 10.04 ?
[19:59] <squish102> is there a place that people report the successes of upgrading ;)
[19:59] <squish102> how has the 10.04 upgrade been going?
[19:59] <slaine> I'm very tempted to just do it and deal with any issues
[20:00] <slaine> much as I have done over the years (this is an old mythbuntu box)
[20:56] <tgm4883> squish102, probably the forums
[20:56] <tgm4883> you shouldn't need update-manager -d, just update-manager
[21:30] <gregl> Does mythbuntu use pulse audio?
[21:30] <tgm4883> gregl, I don't think we do
[21:31] <tgm4883> IIRC, mythtv doesn't support pulse audio yet
[21:31] <tgm4883> there is experimental support
[21:32] <gregl> tgm4883, Glad to hear..I want to up grade but pulse is always a failure for me..Audio is way out of sync..
[21:52] <packet-sent> I need to set my laptop to do nothing when lid is closed I have used the gconf-tool in the past is there a similar tool installed in mythbuntu?
[21:58]  * tgm4883 sighs
[21:59] <tgm4883> you join, wait 10 minutes to ask your question, then leave after 3 minutes?
[21:59]  * tgm4883 goes back to poking at backup/restore


[14:05] <kwwii> _MMA_: dude, around?
[14:05] <_MMA_> yep
[14:07] <kwwii> I am going to tweak your human-murrine stuff and put it in today (along with a clear looks theme) for testing
[14:08] <kwwii> did you ever build a package of the murrine stuff?
[14:08] <_MMA_> Ok. Didnt I do that a while ago? :P Can you send me what you do?
[14:08] <_MMA_> What murrine stuff?
[14:08] <kwwii> the stuff you did quite a while ago
[14:08] <kwwii> with the orange panel (that being the only part I removed)
[14:08] <_MMA_> Ahh....
[14:09] <_MMA_> The only theme I packages was the Ubuntu Studio one.
[14:09] <_MMA_> Everything else was just tinkering.
[14:43] <kwwii> cool, I am adding it to murrine engine now
[14:44] <kwwii> http://sinecera.de/palettes.svg
[14:44] <kwwii> erm
[14:44] <kwwii> njpatel: http://sinecera.de/palettes.svg
[14:58] <_MMA_> kwwii: Adding what to the engine?
[15:00] <_MMA_> kwwii: You're not saying you're adding a theme to gtk2-engines-murrine are you?
[15:04] <kwwii> the gtkrc
[15:04] <kwwii> yes, we are
[15:07] <_MMA_> kwwii: No dont. Create a theme pack for it.
[15:07] <_MMA_> Themes shouldnt go in with engines.
[15:09] <kwwii> after talking to seb he told me to put it in with the engine
[15:09] <_MMA_> kwwii: Putting it there screws with Xubuntu and Ubuntu Studio.
[15:09] <_MMA_> Want me to jump in -desktop?
[15:10] <kwwii> yes, if you want to stop that from happening please do
[21:27] <ArthurArchnix> Hello again... where would I find the icon for the symlink? You know, the arrow that shows up on all symlinks...


[18:22] <ryzokuken> hi all!
[18:22] <ryzokuken> anyone up? Needed a little help.
[18:44] <RajRajRaj> ryzokuken: whats up?
[18:45] <ryzokuken> RajRajRaj, wanted a decent linux laptop
[18:45] <ryzokuken> could not find any
[18:45] <RajRajRaj> what options do u have?
[18:46] <ryzokuken> not many
[18:46] <ryzokuken> Dell and Lenovo refused
[18:46] <ryzokuken> all laptops with i7-7th have windows preinstalled
[18:46] <ryzokuken> I have an option from ASUS
[18:46] <ryzokuken> http://www.amazon.in/Asus-FX553VD-DM483-15-6-inch-i7-7700HQ-Graphics/dp/B06XJ4RMW7/ref=sr_1_1?ie=UTF8&qid=1499366030&sr=8-1&keywords=asus+fx553vd
[18:46] <u-la-la> [ Buy Asus FX553 FX553VD-DM483 15.6-inch Laptop (Core i7-7700HQ/8GB/1TB/Endless OS/2GB Graphics) Online at Low Prices in India - Amazon.in ] - http://www.amazon.in
[18:46] <ryzokuken> but this does not have an SSD
[18:50] <RajRajRaj> ryzokuken:  i have used asus myself
[18:52] <RajRajRaj> lenovo is great too
[18:52] <RajRajRaj> asus sucks at support in india
[18:53] <ryzokuken> lenovo says they don't have linux laptops with i7
[18:53] <ryzokuken> someone told me dell can get you an ubuntu laptop if you can wait
[18:53] <ryzokuken> but they said no too
[18:54] <RajRajRaj> dell sucka at hardware quality
[18:54] <ryzokuken> hmm
[18:55] <RajRajRaj> what is your budget?
[18:55] <ryzokuken> what should I buy?
[18:55] <ryzokuken> under 80k is fine
[18:55] <ryzokuken> the important thing is to find one that doesn't come with windows preinstalled
[18:55] <RajRajRaj> checkout this list https://support.lenovo.com/in/en/solutions/pd031426
[18:55] <ryzokuken> the budget is not a problem
[18:55] <u-la-la> [ Linux for Personal Systems ] - https://support.lenovo.com
[18:56] <ryzokuken> RajRajRaj, so all of these systems can be ordered with the mentioned linux variants?
[18:57] <RajRajRaj> ryzokuken:  contact customer care once you made your list of choice
[18:59] <ryzokuken> RajRajRaj, every single lenovo thinkpad seems really overpriced
[18:59] <ryzokuken> are actual showroom rates different (I think they are)
[19:00] <RajRajRaj> ryzokuken:  amazon prices are ok
[19:02] <ryzokuken> RajRajRaj, E470 seems fine
[19:03] <ryzokuken> it does not have an SSD as well, though
[19:03] <RajRajRaj> ryzokuken:  do consider asus if you have some trusted repair shop near by you. http://www.amazon.in/Laptops-Asus-Computers-Accessories/s?ie=UTF8&page=1&rh=n%3A1375424031%2Cp_89%3AAsus
[19:03] <ryzokuken> I don't think I would go ahead and buy this for 70k though
[19:03] <u-la-la> [ Amazon.in: Asus - Laptops: Computers & Accessories ] - http://www.amazon.in
[19:04] <ryzokuken> ASUS offered the same specs with linux for 57k
[19:05] <RajRajRaj> asus is great
[19:05] <RajRajRaj> only support sucks
[19:05] <ryzokuken> RajRajRaj, I have a few quite nearby
[19:05] <RajRajRaj> if you know repair shops n have good contacts. just buy asus
[19:06] <ryzokuken> 11-12 around the city, must be fine
[19:06] <ryzokuken> about the SSD though
[19:06] <ryzokuken> how much difference would an SSD make
[19:06] <ryzokuken> what do you think?
[19:06] <RajRajRaj> usually asus hardware quality is best so fraud shops steal parts from asus
[19:06] <ryzokuken> https://www.asus.com/in/Laptops/ASUS-FX553VD/specifications/
[19:07] <ryzokuken> this is what I had in mind
[19:07] <u-la-la> [ ASUS FX553VD | Notebooks | ASUS India ] - https://www.asus.com
[19:07] <ryzokuken> take a look
[19:07] <RajRajRaj> ssd can make aroud 5000 - 10k rs difference
[19:08] <RajRajRaj> Graphic
[19:08] <RajRajRaj> NVIDIA GeForce GTX 1050 , with 2GB GDDR5 VRAM  >>> not good i guess
[19:09] <ryzokuken> Not a GPU power user, so its fine I guess


[02:37] <billisnice> my firefox will not open on my ubuntu puter?  9.04
[02:38] <ScottK> billisnice: #ubuntu is the channel for support.
[05:20] <duncan> Hi.  I've got a question about developing a .deb for Ubuntu that creates a file association in Gnome and KDE.  Is this the right place?
[05:20] <duncan> (That is, a .deb to run on Ubuntu - not part of Ubuntu itself)
[05:23] <ScottK> duncan: Basic packaging questions (which it sounds like that is) are better asked on #ubuntu-motu
[05:24] <duncan> Thanks :-)
[09:59] <billisnice> my screen resolution does not stay, it switch when i reboot and is so small i barely can see it.
[11:13]  * zhxk finds a messy code that appears on bum, and want's to know where does the discription to the items comfrom:http://imagebin.ca/view/BLL1WLF.html
[11:40] <zhxk> #ubuntu-dev
[12:16] <cjwatson> kirkland`: the client uses the private key to sign a message proving that it has the public key - it doesn't give the private key to the server (and it would be a serious security breach if it did), so pam modules invoked from /etc/pam.d/ssh have no access to it. To make that work I think you'd need to get into ssh protocol extensions, as you'd need to arrange to send the wrapped passphrase back to the client for unwrapping
[13:56] <DRAGGER> Hello , how i do install application using direct link for e.g. "http://argouml-downloads.tigris.org/nonav/argouml-0.28/ArgoUML-0.28-src.tar.gz"
[14:03] <steveire> cjwatson: ping? Is there anything else I can do about bug https://bugs.launchpad.net/bugs/366282
[16:19] <kirkland`> cjwatson: gotcha, that makes sense.  i should have known that.
[16:50] <kirkland`> pitti: Bug 359997, i don't understand your comment
[16:50] <kirkland`> "Does your commit fix that path issue as well?"
[16:52] <kirkland> pitti: bug updated
[16:54] <james_w> kirkland: that's not pitti is it?
[16:55] <kirkland> james_w: oh, good call :-)
[16:55] <kirkland> pitti: sorry for the spam :-)
[16:57] <LaserJock> hmm, would an annoying UI bug that was introduced via an Ubuntu patch seem like an SRU candidate?
[19:44] <ion_> Ooo, unattended-upgrades uses apt-listchanges in jaunty. It was so minor an annoyance i never got around to reporting it not executing apt-listchanges, but i’m happy now that it does.
[19:45] <mbana> will anything break if i install notification-daemon
[19:45] <mbana> i want the old one
[19:47] <ion_> Ah, someone else had reported it. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507639
[19:49] <mbana> shall i just remove notify-osd?
[21:39] <ion_> The overall look of the distribution is also likely to be refreshed. "Brown has served us well but the Koala is considering other options," Shuttleworth noted.
[21:39] <ion_> Oh noes. Brown is good.
[21:40] <maco> lots of people seem to take issue with earth tones though...not quite sure why
[21:44] <hyperair> i don't like brown
[21:44] <jdong> ugh it's artwork. Can't we focus on making things work instead? or is that a lost cause?
[21:44] <mdke> stuff doesn't work?
[21:44] <hyperair> to put it bluntly, when i first used ubuntu (6.06) i thought the interface looked like shit, and changing the theme was one of the first things i did
[21:45] <jdong> mdke: there's always room for improvement.
[21:45] <mdke> jdong: I think there are a few bugs still outstanding
[21:45] <jdong> bootup speed, X flickering, intel/X stability is a major nightmare for me, IO interactivity particularly with Firefox....
[21:45] <jdong> now don't get me wrong I love my Ubuntu machines and am satisfied with them, not trying to troll here
[21:45] <jdong> but there's certainly always room for improvement
[21:45] <jdong> the artwork has never tended to be a thing that's bothered me. the theme's appearance and usability is fine to me
[21:46] <hyperair> flickering i don't see
[21:46] <hyperair> but i seriously lost it earlier when i got three hard locks in two hours
[21:46] <jdong> hyperair: it takes about 2 seconds to flip from X to a VT.
[21:46] <hyperair> 2 seconds huh
[21:46] <jdong> which has to be done on suspend and resume.
[21:46] <hyperair> i don't switch to VTs much heh
[21:46] <hyperair> oh!
[21:46] <hyperair> hmm
[21:46] <hyperair> big problem.
[21:46] <hyperair> i don't suppose KMS can help this?
[21:46] <jdong> compare that to my macbook running OS X which resumes in 150ms from lid-up to ping response.
[21:47] <jdong> I think KMS is supposed to help
[21:47] <jdong> but I don't think it'll be on the order of 150ms resume.
[21:47] <jdong> and when you use a laptop on-the-go occasionally, suspend-resume speed is a big deal
[21:47] <hyperair> 150ms..
[21:47] <hyperair> that is crazy.
[21:47] <hyperair> how do you measure 150ms?
[21:47] <jdong> hyperair: the unlock screen is waiting before I can pull the lid up.
[21:47] <hyperair> ..shit
[21:48] <jdong> hyperair: 10ms ping polling from another system
[21:48] <jdong> over *WIFI*
[21:48] <hyperair> O_O
[21:48] <jdong> how much of that 150ms is re-establishing wifi? :)
[21:48] <jdong> I'm convinced the network links up before the CCFL backlight can engage.
[21:48] <jdong> I've heard the LED macbooks resume even faster.
[21:48] <Chipzz> jdong: my macbook also resumes that fast; but I don't think it's suspended when you close the lid
[21:48] <Chipzz> just sleep or sth
[21:49] <Chipzz> (dunnow the accurate terms)
[21:49] <jdong> Chipzz: it's put into S3+S4 hybrid.
[21:49] <jdong> Chipzz: that is, it writes out a hibernate to disk image AND then goes into RAM sleep
[21:49] <jdong> Chipzz: that way if battery runs out it can resume from disk, if battery remains it will wake like normal standby
[21:49] <Chipzz> what I *do* like is that if your battery runs out while the lid is closed, it automatically hibernates
[21:50] <Chipzz> hrrrm ah k
[21:50] <jdong> the suspend part takes about 10 seconds to write out the encrypted RAM image.
[21:50] <jdong> the resume part is instant if you don't lose battery power
[21:50] <Chipzz> yeah
[21:50] <Chipzz> one of the things I like about osx :)
[21:50] <jdong> you can use a pmset command to turn off the hibernate image so suspend is instant too
[21:50] <Chipzz> (or is that not os specific?)
[21:51] <jdong> Chipzz: Windows Vista does the hybrid sleep thing too
[21:51] <jdong> and there is support in Linux too via the s2both command but I've never gotten it working
[21:51] <jdong> namely it takes well over 30 seconds to write something out, but neither resume from RAM nor resume from disk worked in Intrepid.
[21:52] <Chipzz> not running linux on mine though
[21:53] <Chipzz> (</blush>)
[21:53] <jdong> I dual on my macbook but to be honest most of the time on the go it runs OS X.
[21:53] <jdong> apart from the suspend-resume thing, our entire campus is Cisco 24-channel MIMO 802.11N connected
[21:54] <jdong> and OS X can easily pull 13MB/s up and down
[21:54] <jdong> Ubuntu kernel panics when ath9k tries to connect to 5.8GHz N
[21:54] <jdong> seems to be a known ath9k upstream bug
[21:55] <Chipzz> recent model?
[21:55] <jdong> no, this is older, the first core2duo generation black plastic.
[21:55] <jdong> the newer ones use broadcom cards which ironically work better if you use go-to-RMS-hell drivers
[21:55] <Chipzz> hrrrm
[21:55] <jdong> and are apparently a lot less expensive too
[21:56] <jdong> I've been considering shelling out the 20 bucks to swap in one of those
[21:56] <Chipzz> didn't know 802.11N did go that far back
[21:56] <jdong> the atheros A+G chipset that was in those macbooks could be firmware-upgraded to N
[21:56] <jdong> yay software defined radios!
[21:56] <Chipzz> see, firmware is not evil! *grin* :)
[21:57] <jdong> lol
[21:57] <jdong> as long as it's redistributable IMO I don't see the difference between it being loaded on by the OS or by the OEM in factory. It's still a blob we can't change.
[21:57] <Chipzz> well, I wouldn't call a free upgrade to N evil anyway :P
[21:59] <Chipzz> anyway, afk again :)
[22:01] <maco> hyperair: i thought feisty's wallpaper looked like chocolate milk. one of my cousins called it mousse and wanted to get a spoon to try to eat her screen
[22:02] <hyperair> lol
[22:02] <hyperair> that's hilarious


[15:59] <Dro> hello and happy new year for everyone ~~
[16:58] <praisethemoon> o/
[17:02] <elacheche> o/
[17:16] <praisethemoon> elacheche, how is it going?
[17:22] <elacheche> Good praisethemoon :) u?
[17:22] <praisethemoon> i'm good as well
[17:23] <praisethemoon> preparing a new presentation for the next workshop
[17:25] <elacheche> :)
[17:33] <praisethemoon> elacheche, https://j.gifs.com/BB6VNW.gif
[17:33] <praisethemoon> XD


[03:34] <pikiora> Oh, sorry bout that said wee one is demanding lol
[03:34] <pikiora> very very demanding
[08:50] <ibrojoker> hi
[17:50] <olly> morning
[18:22] <ibeardslee> morning
[18:23] <kcj> Morning.
[18:23] <kcj> tgif.
[18:57] <chilts> morning
[19:28] <ajmitch> morning
[21:07]  * olly wonders why the lag to the machine in the living room is so bad
[21:07] <olly> i could walk there and back quicker


[06:21] -queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.19 => 1:2.11+dfsg-1ubuntu7.20] (ubuntu-server, virt)
[06:21] -queuebot:#ubuntu-release- Unapproved: qemu (disco-proposed/main) [1:3.1+dfsg-2ubuntu3.5 => 1:3.1+dfsg-2ubuntu3.6] (ubuntu-server, virt)
[07:05] <ginggs> LocutusOfBorg: why not move to Texas?
[08:17] <LocutusOfBorg> ginggs, -EDIDNTGET
[08:29] <cjwatson> infinity: Plausibly related.  Does it happen in an unstable chroot?
[08:46] <ginggs> LocutusOfBorg: plenty of space in Texas (old BOfH joke)
[08:50] <LocutusOfBorg> lol! :D
[08:51] <cjwatson> The only way to increase space there would be to increase the allocation for all builders, which would need care to ensure that it doesn't run the whole cloud out of space.  A more immediately practical solution is often to remove intermediate outputs during the build.
[09:14] <Laney> :|
[09:15] <Laney> second time this has happened now - rabbitmq has stopped delivering events to the autopkgtest workers
[09:15] <Laney> if I restart them, they get one job only and then sit around waiting for the next queue item
[09:15] <Laney> which is there but isn't sent to them
[09:16] <apw> Laney, as if they had not acked it, or tried to ack the wrong 'correspondance-id'; do you check the return from ack (if it returns things)
[09:17] <doko> cjwatson: that's probably triggered by building for one more python version ...
[09:19] <doko> hmm, no, b-d on python3-dev
[09:22] <doko> update_excuses is outdated
[09:22] <LocutusOfBorg> cjwatson, I was trying to avoid an useless patching of opencv, specially if Debian seems to have generally a little bit more space wrt Ubuntu (it might be not the only package)
[09:22] <LocutusOfBorg> but yes, I can steal the itk4 removal bits post build and to some ppa testing
[09:23] <Laney> apw: the acking seems to work fine, at least as far as I can tell
[09:23] <Laney> it's like the server craps itself somehow
[09:25] <apw> we had a lot of trouble with our one on precise doing things like that; i have not seen the saem since it moved to bionic
[09:25] <apw> though it tended to do that when a queue was not being drained and it ran out of literally everything to store the incoming messages on
[09:25] <apw> i assume you've checked for that kind of thing
[09:26] <Laney> I don't see anything in the logs
[09:26] <Laney> but if you wanted to look too, maybe you would ?
[09:26] <Laney> rabbitmq-server/0
[09:26] <Laney> it is xenial so perhaps when we upgrade it'll be better ?
[09:53] <Laney> ok, recovered it for now with apw's help
[09:54] <Laney> (it was blocking on a memory threshold which we increased, should probably be deployed on a larger instance next time)
[10:40] <RikMills> could an AA please remove the s390x binary from telegram-desktop? debian maintainer was patching the build scripts to make that build, but has now dropped that, as the resulting build had other issues that meant it didn't work anyway
[11:08] -queuebot:#ubuntu-release- Unapproved: zsys (eoan-proposed/universe) [0.2.2 => 0.2.2+19.04] (no packageset)
[11:34] <cjwatson> infinity: I analysed the rumur failure and filed https://bugs.debian.org/943705 with my findings
[11:35] -queuebot:#ubuntu-release- Unapproved: rejected carla [source] (eoan-proposed) [2.0.0-0ubuntu4+gitde67dcb]
[11:37] <sil2100> Laney: hey! Looking at the gnome-terminal eoan SRU - you want to copy it forward into focal once it's in eoan? SInce I see focal is still on 3.34.0
[11:38] <Laney> yeah was going to
[11:38] <Laney> for some of the later SRUs I did upload backports
[11:39] <Laney> but I didn't go back and do that for the earlier ones, hoped copy up would be ok
[11:42] <sil2100> Yeah, I think it should be ok at least now,
[11:42] <sil2100> As long as we don't forget to bin copy it ;p
[11:43] <Laney> aye
[11:46] -queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (eoan-proposed) [3.34.2-1ubuntu1]
[11:48] <LocutusOfBorg> please NBS proposed cleanup? missing build on amd64: python-bzrlib, python-bzrlib-dbg (from 2.7.0+bzr6622-17ubuntu1)
[11:52] <cjwatson> hm, that feels like a proposed-migration bug?  those binaries don't exist in focal-proposed, so the only way to stop p-m saying that seems to be to remove them from focal, which seems like a bad idea without a full migration
[11:57] -queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (eoan-proposed) [77.0.3865.120-0ubuntu<IP_ADDRESS>]
[12:02] -queuebot:#ubuntu-release- Unapproved: haproxy (bionic-proposed/main) [1.8.8-1ubuntu0.5 => 1.8.8-1ubuntu0.6] (ubuntu-server)
[12:03] -queuebot:#ubuntu-release- Unapproved: haproxy (disco-proposed/main) [1.8.19-1ubuntu1 => 1.8.19-1ubuntu1.1] (ubuntu-server)
[12:03] -queuebot:#ubuntu-release- Unapproved: haproxy (eoan-proposed/main) [2.0.5-1 => 2.0.5-1ubuntu0.1] (ubuntu-server)
[12:04] <LocutusOfBorg> somebody accepted remmina-plugin-kwallet in main, it should be probably moved to universe, what do you think?
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (disco-proposed) [1.8.19-1ubuntu1.1]
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (eoan-proposed) [2.0.5-1ubuntu0.1]
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (bionic-proposed) [1.8.8-1ubuntu0.6]
[12:06] <LocutusOfBorg> unless you want to consider MIRing libkf5wallet-bin
[12:06] <LocutusOfBorg> can anybody please do the magic?
[12:08] -queuebot:#ubuntu-release- Unapproved: accepted opencryptoki [source] (eoan-proposed) [3.11.1+dfsg-0ubuntu2.1]
[12:09] -queuebot:#ubuntu-release- Unapproved: accepted opencryptoki [source] (disco-proposed) [3.11.0+dfsg-0ubuntu2.1]
[12:16] -queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (eoan-proposed) [3.34.1+git20191022-1ubuntu1]
[12:17] -queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (eoan-proposed) [3.34.1+git20191024-1ubuntu1~19.04.1]
[12:18] <sil2100> Laney: (I assume you have uploaded gnome-shell there, looks like a version error - 19.04.1 instead of 19.10.1?)
[12:18] <sil2100> ^
[12:22] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (eoan-proposed) [2.3.2-0ubuntu2~19.10.0]
[12:23] <cjwatson> LocutusOfBorg: remmina-plugin-kwallet moved to universe
[12:35] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (disco-proposed) [2.3.2-0ubuntu2~19.04]
[12:49] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (bionic-proposed) [2.3.2-0ubuntu2~18.04.0]
[12:54] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (xenial-proposed) [2.3.2-0ubuntu2~16.04.0]
[12:58] -queuebot:#ubuntu-release- Unapproved: rejected cinder [sync] (disco-proposed) [2:14.0.1-0ubuntu3]
[13:14] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (disco-proposed) [2:14.0.2-0ubuntu1]
[13:17] <Laney> sil2100: ah!
[13:18] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (disco-proposed) [2:19.0.3-0ubuntu1]
[13:29] <RikMills> proposed migration runs are crashing with a connection error
[13:29] <RikMills> not sure if someone gets an alert on that, so just saying
[13:30] <Laney> run*s*?
[13:31] <RikMills> last 2
[13:31] <Laney> just watch this one
[13:31] <Laney> I restarted rabbitmq
[13:32] <RikMills> ok. fingers crossed
[13:35] <Laney> not that we need any more test requests :-)
[13:44] <LocutusOfBorg> tga
[13:44] <LocutusOfBorg> thanks for remmina
[14:01] -queuebot:#ubuntu-release- Unapproved: gnome-shell (eoan-proposed/main) [3.34.1-1ubuntu1 => 3.34.1+git20191024-1ubuntu1~19.10.1] (desktop-extra, mozilla, ubuntu-desktop)
[14:02] <Laney> sil2100: proper version there now, thanks!
[15:10] <RikMills> Laney: failed with a slightly different error, and restarted again on a new run
[15:11] <Laney> completely different
[15:11] <Laney> but yes, I know, I'm watching
[15:11] <Laney> if that keeps happening we'll need to beef up this code with a retry
[15:13] <RikMills> ok. thanks :)
[15:14] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-68.77~16.04.1] (kernel)
[15:16] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-68.77~16.04.1] (kernel)
[15:21] -queuebot:#ubuntu-release- Unapproved: open-iscsi (bionic-proposed/main) [2.0.874-5ubuntu2.7 => 2.0.874-5ubuntu2.8] (ubuntu-desktop, ubuntu-server)
[15:25] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-68.77~16.04.1]
[15:25] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-68.77~16.04.1]
[15:29] <Laney> sil2100: just noticed
[15:29] <Laney> I: [Mon Oct 28 15:28:48 2019] - rust-rand-isaac/0.2.0-1 stuck for 48 days (email last sent at 0 days old, threshold for sending 35 days), emailing
[15:29] <Laney> I: [Mon Oct 28 15:28:48 2019] - Failed to send mail! Is SMTP server running?
[15:29] <Laney> I: [Mon Oct 28 15:28:48 2019] - {'': (501, b'5.1.3 Bad recipient address syntax')}
[15:29] <Laney> in proposed-migration logs
[15:30] <sil2100> Laney: oh, looks like something's busted in the Robert-code, I can take a look at that
[15:32] <Laney> I like the "it's probably the system' fault" error message :D
[15:32] <Laney> system's*
[15:34] <Eickmeyer> sil2100: Thanks for the reject on that, I'll upload a new version. Your reply clarified something for me. Thanks!
[16:16] <Laney> looks like there's a perl -8 and a perl -9
[16:16]  * Laney kills the -8 jobs
[16:28] <Laney> that was GREAT!
[16:30] -queuebot:#ubuntu-release- Unapproved: python3.8 (disco-proposed/universe) [3.8.0-1~19.04 => 3.8.0-3~19.04] (no packageset)
[16:31] -queuebot:#ubuntu-release- Unapproved: python3.8 (eoan-proposed/universe) [3.8.0-1 => 3.8.0-3~19.10] (no packageset)
[16:33] -queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (bionic-proposed/main) [3.6.8-1~18.04 => 3.6.9-1~18.04] (core)
[16:34] <rbalint> sil2100, if you have some sru cycles left could you please accept open-iscsi?
[16:42] <sil2100> rbalint: what series?
[16:44] -queuebot:#ubuntu-release- New source: python3.8 (bionic-proposed/primary) [3.8.0-3~18.04]
[16:52] <rbalint> sil2100, bionic
[17:05] -queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.8]
[17:07] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-68.77] (core, kernel)
[17:09] <infinity> cjwatson: Ta.
[17:10] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-68.77] (core, kernel)
[17:56] <vorlon> jamespage: Debian has removed neutron-lbaas as "replaced by Octavia"; are we good to drop it in focal also?
[17:59] <RikMills> can these binaries be removed in -release please?
[17:59] <RikMills> telegram-desktop/s390x: debian maintainer stopped patching to build on this, as the build is not usable anyway.
[18:00] <RikMills> calibre ppc64el/s390x: switched to building with qtwebengine, not available on those arches
[18:01] <RikMills> both are part of the Qt transition
[18:14] <ginggs> RikMills: files bugs, subscribe ~ubuntu-archive
[18:24] <RikMills> never had to do that before for removals
[18:30] <ginggs> RikMills: you've just been lucky
[18:33] <RikMills> vorlon: you want bugs?
[18:34] <ginggs> ...this is how you get bugs :D
[18:35] <RikMills> I don't mind. on binaries in the past I have just asked an AA, and they JFDI if it was valid
[18:37] <vorlon> I don't need bug reports for binary removals no
[18:38] <RikMills> vorlon: thanks. I was stating to wonder if my memory was off
[18:39] <RikMills> the calibre one is quite clear. if you need it, I can dig out the salsa comments on telegram-desktop
[18:42] <RikMills> https://salsa.debian.org/debian/telegram-desktop/commit/86d77755e0d40220e3d592b312d28315e134664f#note_116029
[18:51] <vorlon> RikMills: removals done
[18:52] <RikMills> vorlon: thank you! :)
[19:08] -queuebot:#ubuntu-release- Unapproved: carla (eoan-proposed/universe) [2.0.0-0ubuntu3 => 2.0.0-0ubuntu4] (ubuntustudio)
[19:50] <LocutusOfBorg> please kick out opencv from proposed pocket, otherwise this big chunk won't ever migrate...
[19:50] <LocutusOfBorg> otb is now entangled with qt/opencv, not building and unpatchabile in the near future
[21:51] <tkamppeter> The Bionic SRU for network-manager is hanging in -proposed with
[21:51] <tkamppeter> Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)
[21:51] <tkamppeter> What does it mean? I cannot imagine any freeze in Bionic.
[21:52] <tkamppeter> Or can someone unblock it?
[21:52] <apw> tkamppeter, everything in all stable releases are blocked, they are not rleeased by britney
[21:54] <tkamppeter> apw, is network-manager available for the verification of the SR in -prposed now?
[21:59] <infinity> tkamppeter: I'm not sure I understand the question.  The binaries are built, and someone should verify all three linked bugs are fixed.  That's not been done.
[22:07] <tkamppeter> infinity, OK, thanks.
[22:20] <wxl> shouldn't focal be in packages.ubuntu.com?
[22:25] <infinity> Rhonda's response time on updating packages.ubuntu.com isn't always immediate.
[22:26] <wxl> okie dokie
[22:33] <tomreyn> is pinging Rhonda about it part of the post-release-upgrade-things-to-do list, though?
[22:36] <Ukikie> I did on another channel, as I'm sure someone else did somewhere else.
[22:51] <wxl> fcitx now unconditionally breaks fcitx-module-quickphrase-editor (qt4) in lieu of fcitx5-module-quickphrase-editor. in eoan the former was a virtual package for the latter, but not so in focal. anyways, this apparently has been breaking at least lubuntu, kubuntu, and kylin builds for several days. at some point the build process seems to remove fcitx5-module-quickphrase-editor, which is weird.
[22:53] <valorie> wxl: is this part of tsimonq2's acts of violence on qt4?
[22:53] <valorie> unforeseen I'm sure
[22:53] <wxl> valorie: heh, no, i don't think him specifically. this happened up in debian land.
[22:54] <valorie> ah, but he's doing it in debland too!
[22:54] <wxl> well his name ain't on it XD https://salsa.debian.org/input-method-team/fcitx/commit/2de59f4f0cf93c37cded286bfd0c2dcb055aac12
[22:55] <wxl> and indeed not mentioned anywhere on the upstream bug either https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874868
[22:56] <wxl> you know i am the first one to jump at the opportunity to blame simon, but i think i can safely say he had little to do with this
[22:59] <RikMills> wxl: the reason is that the issue is fixed in fcitx-qt5, but that fixed version is stuck in proposed due to the Qt5 transition
[22:59] <RikMills> *I think*
[23:01] <wxl> i think you're right given the change i see in the proposed version:
[23:01] <wxl>     + No longer let fcitx5-module-quickphrase-editor provide
[23:01] <wxl>       fcitx-module-quickphrase-editor since the new fcitx is
[23:01] <wxl>       declaring "Breaks:" relationship on the latter one.
[23:01] <RikMills> yep
[23:02] <wxl> ok so can we at least blame simon for not fixing the transition already? XD
[23:02] <RikMills> seems reasonable :D
[23:02] <valorie> no good deed goes unpunished!
[23:03] <wxl> ok well that mystery is solved


[04:26] <ScottK> We're doing all library transitions in -proposed now?
[04:29] <infinity> ScottK: The archive certainly doesn't seem to be aware of this.
[04:29] <infinity> ScottK: But yeah, especially for seeded packages, transitioning in proposed sure ends up a nicer experience for users and testers.
[04:30] <infinity> ScottK: I'm looking into britney automagic migration stuff this week and next.  With any luck, we can just switch to proposed for all uploads and be done with it.
[04:30] <ScottK> Just call it unstable.
[04:31] <ScottK> Then alias the release pocket to testing.
[04:34]  * xnox doesn't want people to accidently upload to wrong distro though if pockets match names in debian & ubuntu
[04:36] <infinity> ScottK: Yeah, not gonna happen. :P
[04:37] <infinity> ScottK: Also, it's instant migration, so not quite the same deal.
[04:37] <ScottK> The window is narrower, but you can still have interlocked transitions due to archive skew.
[04:38] <infinity> Well, yes.
[04:38] <infinity> But given that we also don't have a strict concept of package ownership, the answer to that problem is "fix it, then".
[04:38] <ScottK> I will be surprised though if eventually someone doesn't say, "You know, we really ought to test these packages before they migrate".
[04:38] <infinity> Much as it currently is when our release pocket sucks.
[04:39] <infinity> When autopkgtest stuff gets more coverage, I wouldn't be at all unhappy with slowing the migration down a bit to force testing.
[04:39] <infinity> But we'll see.
[04:39] <ScottK> True, but 'instant' can suddenly get a lot longer when your little library transition has to wait for a Qt build to finish on armel.
[04:39] <infinity> That will be an entirely different debate on velocity versus quality, etc.
[04:39] <infinity> ScottK: Yes, but we want things in sync on arches.
[04:40] <ScottK> Yes we do.
[04:40] <infinity> ScottK: (And much like Debian, we may blacklist non-supported arches)
[04:40] <infinity> ScottK: Though, I don't intend to do that except as a last resort (like the current armel/mono breakage)
[04:40] <ScottK> Speaking of non-supported  architectures ...
[04:41] <ScottK> Would you have a moment to look at clamav in lucid-backports.
[04:41] <ScottK> It FTBFS from a test failure I've seen once on other archs, but is 100% after about 5 tries on ppc.
[04:41] <ScottK> (on lucid - fine on other releases)
[04:42] <infinity> I was going to suggest trying a different kernel, but that was on a precise kernel even.
[04:43] <infinity> And I assume previous failures weren't all on ross?
[04:51] <ScottK> I didn't think to check.
[04:53] <ScottK> infinity: Can you retry it again and make sure it hits !ross?
[04:54] <infinity> ScottK: Done.
[04:54] <ScottK> Thanks.  I guess we wait now.
[05:10] <infinity> ScottK: Not sure if it relates, but while it's compiling testsuites, there's a char->uint conversion warning thrown by the compiler.
[05:11] <infinity> Actually, there are a fair few of those...
[05:11] <infinity> Though, I can't see how that would make it fail on only one release.
[05:28] <RAOF> infinity: I'll let robert_ancell ask what needs AA attention.
[05:28] <infinity> robert_ancell: Answer fast, I have a midnight date with a patio and a cold beer.
[07:48] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-archive/2012-June/045233.html - new change-override tool
[08:02] <gema> slangasek: you volunteered, I don't think it is so much for you to do it, but for you to help us find who should be doing it, or pointing us to the test cases, or get started somehow
[08:17] <xnox> http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html is in Pub Time mode =)
[08:17] <cjwatson> And so it should be! :-)
[08:33]  * cjwatson fires his LP branch to remove change-override.py off to EC2
[08:36]  * xnox 'cjwatson and LP Archive Admin days with your favourite Core Dev characters available now in the software centre as part of the Humble Indie Bundle in the Ubuntu Software centre"
[08:37]  * xnox 'cjwatson and the LP Archive Admin days with your favourite Core Dev characters available now as a part of the Humble Indie Bundle in the Ubuntu Software Centre"
[08:37] <cjwatson> odd chap
[08:37]  * xnox tries to be funny and fails at spelling and grammar
[08:42] <cjwatson> Now, I wonder what to do with security-kernel-overrides.  It's kind of broken anyway due to something funky with indices, but maybe I should fix that anyway ...
[08:42] <cjwatson> Or maybe it's time to fix LP so that binaries default to the same component as their source
[08:43] <micahg> cjwatson: +1, that would solve my remaining override issues :)
[08:45] <cjwatson> (Bug 192076)
[08:45] <ubot2> Launchpad bug 192076 in launchpad "component of new binary packages should default to source component" [Critical,Triaged] https://launchpad.net/bugs/192076
[08:53] <infinity> cjwatson: That's a wonderfully old bug.
[08:53] <infinity> cjwatson: Would love it fixed.
[08:54] <infinity> cjwatson: Though, security-kernel-overrides still had a place for hardy kernels, where some bits are in universe.
[08:54] <infinity> (Not that I ever use the script, I don't trust it, I just eyeball madison output and make it match)
[08:56] <infinity> cjwatson: Of course, if it was fixed to actually look at listed components and DTRT, I think the hardy kernel would probably Just Work.
[08:56] <infinity> (And if not, we could fit it to do so)
[08:57] <cjwatson> security-kernel-overrides just plain didn't work last I checked, because the written-out overrides in indices were horribly incomplete.
[08:57] <cjwatson> I probably ought to investigate that
[09:02] <jibel> can you respin ubuntu desktop ? ubiquity on the image is 2.11.5 but 2.11.6 in the squashfs
[09:04] <jibel> it breaks oem-config
[09:21] <cjwatson> That's freaky.  .list should always be >= .manifest, if anything.
[09:22] <cjwatson> Oh, it was built in parallel with something else apparently so it didn't sync the mirror.
[09:22] <cjwatson> I wonder what.
[09:24] <cjwatson> jibel: I'm investigating this rather than blindly respinning.
[09:24] <jibel> cjwatson, ok, thank you
[09:30] <cjwatson> There was a semaphore set that should have been clear.
[09:30] <cjwatson> So it always thought it was doing a parallel build even though it wasn't.
[09:30] <cjwatson> Apparently this situation has persisted since an Ubuntu daily-live build was killed on 20120606.
[09:31] <cjwatson> It must have been killed extremely unceremoniously; normally build-image-set cleans up the semaphore on exit.
[09:32] <cjwatson> I've cleaned this up and kicked off another build.  However this time it actually *was* in parallel with a server build, which suffered from the same problem, so I'll wait for that to finish and then try yet again.
[09:32] <cjwatson> I'm surprised that nobody noticed that all the server packages date from 2012-06-06.
[09:34] <infinity> cjwatson: More evidence that no one tests between milestones? :P
[09:35] <infinity> cjwatson: (Since the Alpha-1 server build was pretty much on that date)
[09:39] <infinity> cjwatson: Regarding the new change-override.  Remember how the LP script gave a visual clue what it was overriding?  That was actually kinda helpful.
[09:39] <cjwatson> infinity: Example?
[09:39] <infinity> cjwatson: Yours says "universe/utils/optional -> main", I'd expect "UNIVERSE/utils/optional -> MAIN"
[09:40] <infinity> It upper-cased the chunk of the override stanza that was being overridden.
[09:40] <cjwatson> No it didn't.
[09:40] <infinity> Did too.
[09:40] <cjwatson> It upper-cased the priority.
[09:40] <cjwatson> Unconditionally.
[09:40] <cjwatson> 2012-06-14 18:22:46 INFO    Override Component to: 'universe'
[09:40] <cjwatson> 2012-06-14 18:22:46 INFO    'libboost-graph1.46-dev-1.46.1-7ubuntu3/main/libdevel/OPTIONAL' binary overridden in quantal/amd64
[09:40] <cjwatson> And I have history to prove it.
[09:40] <infinity> Huh.  I swear I've seen it do the other thing.
[09:40]  * infinity scratches his head.
[09:40] <cjwatson> And that was just a side-effect of priorities being DB enumerated types.
[09:41] <cjwatson> I lower-cased it because that always annoyed me. :-)
[09:41] <cjwatson> If you want to upper-case as a hint, that sounds cool, it's just not because change-override.py always did it. :-)
[09:41] <infinity> Maybe I only noticed it when I was doing priorities...
[09:41] <cjwatson> But maybe only upper-case on the LHS.
[09:42] <infinity> I do now wonder how my brain saw that differently all these years.
[09:42] <infinity> Maybe I need a new one.
[09:43] <knome> can i have the old one?
[09:44] <infinity> I thought I might keep in a jar and figure out how to talk to myself.
[09:44] <knome> bah. still no brain-eating :(
[09:44] <knome> oops
[09:44] <knome> :)
[11:51] <cjwatson> jibel: Should be happier now.
[12:36] <ScottK> infinity: Thanks.
[13:44] <ogra_> stgraber, looking yt your edubuntu omap buildlog you need some tweaks to tell livecd-rootfs to use universe i think
[13:44] <ogra_> *at
[13:46] <stgraber> ogra_: ah? the build failure I got looked fine, epoptes depends on a package that never built on armhf...
[13:47] <ogra_> stgraber, oh, i thought it was a package in universe :)
[13:47] <ogra_> yeah, if it didnt build thats an "okayish" error indeed
[13:49] <stgraber> well, it also happens to be in universe but so was epoptes, so that part seems to work :)
[13:49] <stgraber> I thought alkis fixed that issue by making epoptes conditionally depend on ssvnc which is also supported and built on armhf but apparently not
[13:50] <ogra_> trivial fix then
[13:50] <ogra_> unless you can convince him to fix xvnc4viewer on arm ;)
[13:51] <stgraber> hehe, I actually tried that then when I saw the packaging of that thing I gave up and started writting my own vnc client ;)
[13:51] <stgraber> xvnc4viewer's source is basically an old version of the vnc source + a copy of an old version of the X server + a bunch of patches
[13:52] <ogra_> yeah, i know ... iirc doko was the last person looking at it for arm and gave up ... but that was like 2-3years ago :)
[13:53] <stgraber> well, I guess nothing changed, it still looked like a terrible mess when I looked at it a couple of months ago ;)
[13:53] <ogra_> yeah
[13:53] <stgraber> IIRC the actual source of the FTBFS is in the X code, not in the vnc code, so we'd need to find the fix in the upstream X code and backport it to whatever old version is bundled in vnc4...
[13:54] <ogra_> well ... could ... yes ... indeed ...
[13:55] <stgraber> but for now I'm mostly of the opinion of just letting that package die ;) and trying to get as far away of it as possible for Edubuntu.
[13:56] <ogra_> hehe, yeah, thats surely the better move ...
[14:09] <slangasek> gema: ok - I'm going to point you at stgraber then
[14:11] <stgraber> slangasek: context? :)
[14:12] <slangasek> stgraber: work item to provide test cases for ipv6
[14:13] <stgraber> slangasek: ok
[14:34] <Laney> I should fix my procmail rules to do deduplication... this thread being cross-posted to -devel and -release is getting annoying
[14:37] <stgraber> Laney: deduplication? you're actually getting duplicates? in my case it looks like mailman is being clever and doesn't send me duplicates, but I end up having 50% of the thread on one list and 50% on the other :)
[14:38] <Laney> yeah I get allo f them on both
[14:38] <cjwatson> stgraber: Exactly why I hate deduplication
[14:39] <Laney> that could get annoying, yeah. Would have to be made deterministic somehow.
[14:40] <stgraber> it'd be fine if the To field would always be in the same order as the first match will move the e-mail, but apparently it's quite random, making them get into both folders...
[14:40] <stgraber> I guess I could write a script that sorts the To field, then uses that for filtering :)
[15:29] <ogra_> cdimage@nusakan:~$ ARCHES=armel+omap4 buildlive ubuntu daily-live &&  ARCHES=armel+omap4 for-project ubuntu cron.daily-live
[15:29] <ogra_> ubuntu-armel-omap4 on annonaceae.buildd starting at 2012-06-21 15:28:58
[15:29] <ogra_> ssh: connect to host annonaceae.buildd port 22: No route to host
[15:29] <ogra_> heh
[15:31] <ogra_> nice way to tell me: "screw you we dont build armel images anymore, fix y<our finger memory, damned !!!"
[15:31] <stgraber> ogra_: shouldn't that be celbalrai.buildd ?
[15:32] <ogra_> stgraber, well, for arm*el* it should be nothing :)
[15:32] <stgraber> ogra_: heh, right :)
[15:32] <ogra_> my fingers just didnt leanr that yet
[15:32] <ogra_> *learn
[15:33] <stgraber> ogra_: I'll be ready to kick another edubuntu test build after the publisher finishes its job, will check that you aren't already running a build before triggering it :)
[15:34] <ogra_> oh, i can run armhf+omap instaed
[15:34] <ogra_> no problem
[15:36] <stgraber> ogra_: that'd be great, hopefully my default-arches config works now and it'll indeed only build for omap4 :)
[15:37] <ogra_> running armhf+omap --- but i'm not sure infinity is done with switching his load balancing stuff back on again
[15:38] <ogra_> so i might or might not block you atm, seems my build also starts on celbalrai
[15:41] <stgraber> well, I'd usually have both omap and omap4 running on celbalrai at the same time, so I assumed it's fine as long as it's not the exact same "arch" building twice
[15:41] <ogra_> the buildds block while they build for one arch
[15:42] <ogra_> and a build usually takes 90min
[15:42] <stgraber> ok, that explains why it looks like they're both starting building at the same time, but the second one takes double the time
[16:28] <stgraber> ogra_: looks like your build just finished (well, failed), so I'm starting an Edubuntu build now
[16:28] <ogra_> yep, i got what i want (logs)
[16:30] <ogra_> my live build finished properly though :)
[16:33] <ogra_> gah, where did we hardcode ext4 ... i thought we had bound that to preinstalled
[16:36] <ogra_> hmm, obviously not in buildlive
[17:57] <ogra_> stgraber, looks like you are done ?
[17:59] <ogra_> stgraber, i'm firing off another attempt and will leave for the evening afterwards
[18:00] <ogra_> (so celbalrai is free for you afterwards if you want to do more testbuilds)
[18:01] <stgraber> ogra_: yep, my build worked (only did livefs)
[18:35] <Laney> NCommander: moar snipping please :-)
[18:36] <NCommander> Laney: I think we have a proposal that works all
[18:38] <Laney> well, if you reply again I'd rather not have to page down for 15 minutes :P
[18:42] <stgraber> NCommander: your proposal basically means that freezes will work as they do currently :)
[18:42] <stgraber> NCommander: as Edubuntu won't be able to move to the new milestone-less stuff and edubuntu is a superset of Ubuntu (and we're introducing a server version this cycle)
[18:42] <NCommander> stgraber: whch is what Kubuntu wants. Ubuntu doesn't wish to be part of those freezes so we can simply remove them
[18:42] <stgraber> so that'd mean that all packages in Ubuntu would still have to be frozen as Edubuntu will still need the freeze
[18:43] <NCommander> stgraber: please respond to Robbie's email then
[18:44] <Laney> I'm not sure I've seen much support from the RT for the idea of dropping freezes anyway
[18:45] <stgraber> yeah, I mentioned it very early in the thread but my point of view is that we're already doing signifcant improvements to the way the archive works this cycle and that I'd really prefer we don't mess with our release process on top of that :)
[18:46] <stgraber> we can always discuss doing that kind of change at next UDS after we've had a cycle (or part of anyway) of using -proposed and extended automated testing
[18:47] <stgraber> NCommander: I'll respond to Robbie with Edubuntu's view once I confirmed that my view matches that of the rest of the Edubuntu release team (that being highvoltage)
[18:47] <NCommander> stgraber: excellent
[18:47] <Laney> I think that for this cycle we should just have the community team do their additional milestones when we're not doing official ones.
[18:47] <Laney> Then we'll have some data at UDS as to how it goes, without having to potentially mess stuff up.
[18:48] <stgraber> yep, I certainly have no problem whatsoever with more people testing the dailies and that'd let us easily review things at next UDS
[18:48] <Laney> like "was the archive working enough to let this happen?" "were the results useful?"
[18:53] <NCommander> Laney: I recommend you post in the thread
[18:53] <Laney> it seems too big to be productive already
[18:53] <Laney> I'd rather discuss it at the meeting and see if we can come to a position as the release team
[18:55] <stgraber> +1
[18:57] <Laney> skaet: can/should we put it on the agenda?
[18:59] <seb128> NCommander, btw next time can you refrain to create issues for anyone and crosspost when not needed?
[19:02] <highvoltage> stgraber: I'm kind of annoyed at Jono's post and I'm tempted to reply
[19:03] <highvoltage> stgraber: but I don't want to delute any official message you'll be sending on the topic
[19:04] <stgraber> highvoltage: I think the beginning of my message may also apply to your concern.
[19:04] <highvoltage> stgraber: just started to read your message, your first paragraph is almost exactly what I was already typing :)
[19:05] <stgraber> highvoltage: hehe, I remember we discussed it with skaet at UDS and said we need to fix our documentation and "people" to stop saying derivatives when they mean flavours
[19:05] <highvoltage> stgraber: just finished reading it. perfect. not sure I would've been so nice so I'm glad you sent it.
[19:05] <stgraber> :)
[19:12]  * skaet has a workitem to talk to the webops about cleaning up derivatives...
[19:14] <skaet> Laney,  if you want to bring it up as a topic for discussion tomorrow, fine.   Maybe start a new thread on ubuntu-release first,  so folks who haven't been following the ubuntu-devel thread in all its glory can understand the issue?
[19:14] <Laney> Really? :(
[19:14] <highvoltage> stgraber: I still want to reply to jono's mail
[19:14] <Laney> I don't want to risk starting another discussion / fragmenting the existing one
[19:15] <infinity> Laney: Does it need discussing as an actionable item, really?  While I (unlike many) am on the "hey, we should probably drop milestones" side of the fence, I don't think we should JFDI and see what explodes.
[19:15] <highvoltage> I think I'll send it to him as a private mail.
[19:15]  * ScottK looks up.
[19:15] <infinity> Laney: The only sane way forward is to increase testing, change the culture, and make milestones irrelevant.  And if that works, then drop them.
[19:16] <infinity> Laney: I suspect it'll take two sentences and about 30 seconds to get concensus that we can't even consider B without first doing A.
[19:16] <Laney> I'm just asking for a conversation within the release team.
[19:16] <Laney> then we can give our position to those pushing for whatever change is being considered now.
[19:16] <ScottK> infinity: Depends on how many managers are in the room.
[19:16] <Laney> if it's 30 seconds, all the better.
[19:16] <infinity> ScottK: I'm happy to phone a few up and get them to agree to the above position statement too. :P
[19:17] <infinity> Laney: This means I need to actually attend the release meeting, doesn't it?  Since I'm one of the few RMs that seems to hold a strong opposing view here.
[19:18] <infinity> Laney: (Well, an opposing view with a cautious approach, though)
[19:18] <skaet> Laney,  I'm fine with it just being a conversation then.   Was just worried that some weren't following ubuntu-devel thread
[19:18] <Laney> It would certainly be nice if all interested were there
[19:19] <Laney> maybe we could just draft some thing on the pad though
[19:19] <skaet> Laney,  lets see who's there tomorrow,  and if its quorum talk about it.   If not,  I'll set up something else next week for us to get together with the release team and talk about it.
[19:19] <stgraber> infinity: FWIW I'm not saying we should keep milestones forever, but I'm clearly of the opinion that doing a change of this magnitued in the middle of a release cycle is a bad idea and that any change shuld be done incrementally, in the right order and evaluated after each step.
[19:20] <Laney> skaet: ok then
[19:20] <highvoltage> +1 to that
[19:20] <stgraber> infinity: but the current proposal sounded a lot like JFDI to me and I'm clearly opposed to that
[19:23] <infinity> stgraber: The original proposal didn't even talk about dropping milestones, just relaxing/dropping freezes (which we kinda already did for A1)
[19:23] <infinity> stgraber: It morphed into dropping milestones (which, yes, there's been a lot of discussion about), but no one thinks we can JFDI without making sure it's sane.
[19:24] <infinity> stgraber: Anyhow.   I'll show to the meeting tomorrow and give my 2c.
[19:24] <ScottK> infinity: I think the conclusion was that you can't really drop freezes and keep the milestones.
[19:24] <ScottK> So you have to pick one.
[19:25] <infinity> ScottK: That depends on how you define milestones.
[19:25] <infinity> ScottK: If it's just a rallying point where people decide to test harder, target features, etc, you don't need a freeze.
[19:26] <infinity> ScottK: If it's to produce a release-quality image, you do need a freeze, but if that's the point, we always fail anyway.
[19:26] <ScottK> Even for Alpha 1 (where there was no attempt to produce release quality images) we still freeze and need it.
[19:26] <infinity> ScottK: Hence why I included the anonymous "well, all the bugs we know about are kinda crap, but they'll be fixed in tomorrow's daily anyway" quote in the thread.
[19:26] <infinity> ScottK: We don't even pretend milestones are release-quality, so why put all the effort into trying to make them so?
[19:27] <ScottK> I think a graduated set of goals would make sense.
[19:27] <ScottK> Informally we generally consider Alpha 1 a win if you can install something and it boots.
[19:28] <ScottK> We could lay out the release criteria for each milestone so that we aren't over-engineering early on.
[19:28] <ScottK> For Beta 2, I think we should be aiming for release quality images (at least for all the installer components).
[19:28] <ScottK> That would shorten the needed freezes without switching entirely away from our existing system.
[19:28] <infinity> We certainly want to achieve higher quality as we go, yes.
[19:29] <infinity> Though, one of the goals of PlusOne is to keep quality as high as we can.
[19:29] <infinity> Which was why I suggested a cultural shift to PlusOneQA to go with PlusOneMaint.  ie: stop pretending only milestones matter, essentially.
[19:29] <ScottK> Yes, but I think it's be useful to have a defined point to say "It's good enough, move on" for the early ones.
[19:29] <infinity> It does make the whole machine operate much more smoothly if "everything sucks for 3 weeks and then we freeze to test and fix it" isn't the status quo.
[19:30] <ScottK> Agreed.
[19:30] <ScottK> I think a general shift towards the idea that things should generally not be crap is very good.
[19:30] <infinity> Aaanyhow.  I haz to work.  But I'll come to the release meeting tomorrow and be the voice of insanity to balance against everyone's reason. ;)
[19:35] <skaet> ScottK,  agreed,  we've been informally turning up the quality as we go along,  gettting the expectations for what happens at alphas/betas written down, was something I was thinking was overdue
[19:37] <NCommander> seb128: (sorry, was on the phone). would you please ellibrate to what issues? (as for cross-posting, given the topic involved release tasks, it was just as revelant on u-release as it is on u-devel)
[19:41] <seb128> NCommander, I would assume that the release team members care enough about Ubuntu to be subscribed to -devel and I saw at least 5 people today complain about your crossposting making it hard to follow the discussion
[19:42] <seb128> NCommander, like you didn't add any value by crossposting but you make job harder for list admin, people commenting and people following
[19:42] <seb128> NCommander, several people replied on one of the two list only as well splitting the discussion thanks to you
[19:42] <NCommander> seb128: ah, I shall stop
[19:42] <NCommander> I apologize for the headache I caused
[19:42] <seb128> nw, but crossposting just sucks
[19:43] <NCommander> nw?
[19:43] <seb128> no worry
[19:43] <seb128> sorry ;-)
[19:43] <NCommander> seb128: guess I'm used to mutt handling it sanely
[19:43] <seb128> what's sanely?
[19:43]  * NCommander crawls under the bed in fear of the listadmins
[19:43] <NCommander> If the message id matches, it shows it once, with two From: lines
[19:43] <seb128> the people who commented there today said they have half of the discussion landing on their -devel folder and the other half on -release
[19:43] <NCommander> (though that might have been some procmail/muttrc magic I did)
[19:45] <ScottK> I have them going to the same folder, so it was just hitting the delete key.
[19:50]  * NCommander decides to don a fake beard, get a Mexican Passport, and flees before the listadmins come to rm me out of existance
[20:38] <Laney> hey, LP's Debian import really /did/ get faster :-)
[20:39] <Laney> Date: Thu, 21 Jun 2012 13:52:05 +0000 Subject: zeitgeist-sharp_<IP_ADDRESS>-3_amd64.changes ACCEPTED into unstable
[20:39] <Laney> syncpackage: Source zeitgeist-sharp -> quantal/Release: current version <IP_ADDRESS>-2, new version <IP_ADDRESS>-3
[20:55] <infinity> Oh?  Does this mean I can sync my uploads?
[20:55]  * infinity looks.
[20:55] <infinity> Evidently not.
[20:56] <infinity> Laney: Thanks for the false hope.