[07:36] <tjaalton> infinity: nvidia 352 in still in NEW, and as I hear now obsolete
[08:12] <slangasek> cyphermox: looking
[08:13] <cyphermox> slangasek: (sorry :)
[08:13] <cyphermox> slangasek: also, you said golang?
[08:13] <slangasek> cyphermox: yep; let me get up to speed on my mail and I'll find you a link
[08:13] <cyphermox> alright
[08:14] <slangasek> cyphermox: the udev rule removal is a backport of a change already in wily?
[08:15] <cyphermox> slangasek: no, it's an adaptation of how wily works
[08:15] <slangasek> cyphermox: hrm please expand
[08:15] <cyphermox> slangasek: things are Very Broken otherwise, system goes up in load due to multipath-tools being called repeatedly on the devices
[08:15] <cyphermox> (or udev being called repeatedly and failing to speak to the socket
[08:15] <slangasek> cyphermox: my question is whether the udev rule is dropped in wily
[08:16] <cyphermox> no, it's still in wily
[08:16] <cyphermox> multipath doesn't work the same in wily, it's 0.5.0
[08:17] <slangasek> hmm
[08:17] <slangasek> ok
[08:17] <cyphermox> I'm just trying to make things work as best I can backporting just the bits we need
[08:17] <slangasek> so what's the test case for that change?
[08:17] <cyphermox> the udev rule specifically?
[08:17] <slangasek> yes
[08:17] <cyphermox> *rules
[08:17] <slangasek> btw bug #1468897 is referenced in the SRU changelog but has no SRU test case
[08:18] <cyphermox> if the socket rule is there, you'll see a ton of errors from udev about the multipath socket which can't be reached, because, AIUI, udev doesn't understand the path
[08:18] <slangasek> if it's a duplicate of the other, please mark it as a duplicate.  If it's not, please add an explicit test case for it
[08:18] <slangasek> cyphermox: so that's the existing behavior you see with the udev rule as it sits in trusty-updates today?
[08:19] <cyphermox> and if the add|change rule is there; you'll see the system come up with >8 load average and multipath being started and finishing repeatedly in processes
[08:19] <cyphermox> slangasek: with no changes in trusty-updates, things seem to work properly
[08:20] <cyphermox> ^ that SRU changes how multipath speaks to udev (teaches multipath about udev, in short)
[08:20] <cyphermox> multipath is expected to receive the events already and handle them itself via multipathd
[08:21] <slangasek> cyphermox: you said you would see errors from udev becuase udev doesn't understand the path; but this is the existing rule present in trusty-updates; so that doesn't seem accurate
[08:21] <cyphermox> if you upgrade, you'll see errors, and I didn't see them before
[08:21] <cyphermox> but I agree, one should already see them
[08:22] <cyphermox> heh, I guess this makes it another bug, really
[08:22] <slangasek> cyphermox: so from an SRU standpoint: a) what is the udev rule for, b) how do we test that the thing the udev rule was supposed to do previously, still works after applying the SRU?
[08:23] <slangasek> cyphermox: I don't need a separate bug report for this but do want an explicit test case
[08:23] <cyphermox> slangasek: I'll get it on the bug report, it should have been there. In short, simulate paths appearing and disappearing by breaking FC links
[08:23] <cyphermox> that would be the easiest way to reproduce it
[08:24] <cyphermox> I asked to get access to hardware for that a while ago, but I didn't get a response
[08:43] <cyphermox> slangasek: I updated the two multipath bugs.
[09:49] <apw> did we force something to migrate, as for me the current state of wily-release is uninstallable in a big way
[10:36] <Laney> apw: example?
[10:41] <apw> Laney, the info is now in bug #1485970, seems apt could not figure out that it needed to configure libexpat1
[10:42] <apw> (i think you can take it from that that my uninstallability was falsly reported by apt as it was half way through)
[10:48] <Laney> apw: ah right, not straight uninstallability then
[10:56] <apw> Laney, no, it felt like that at first glance, but something all together different in the end
[11:53] <slangasek> cyphermox: "Some USB 3.0 devices *can* support multipath; users of such custom configurations will see USB devices not being considered as multipath devices" - is there a documented/documentable way for the users of such devices to get the previous behavior?
[11:53] <cyphermox> no
[11:53] <slangasek> ok
[11:53] <cyphermox> there's no way to get the previous behavior back, this is just theoretical
[11:53] <cyphermox> I'm not sure *how* you would do it but it should be feasible
[11:54] <cyphermox> but if we do have someone who decides they want to do USB 3.0 multipathed on Trusty, they're prepared for a bad upgrade, because 0.5.0 drops USB completely.
[11:54] <slangasek> so the consequence is that the multiple paths will show up as separate devices; references to the multipath device will be invalid; and the device will be accessible but lose the redundancy
[11:54] <slangasek> heh ok
[11:54] <cyphermox> I just couldn't apply these patches on top without breaking things
[11:55] <slangasek> infinity: ^^ I would like a second opinion on this
[11:55] <cyphermox> right, device will be usable but not redundant via /dev/mapper.
[11:55] <cyphermox> infinity and I discussed this before ,that's why I say USB 3.0 multipath could be done, he brought it up :)
[11:56] <slangasek> ok, so did he also voice his opinion on whether this is acceptable in an SRU?
[11:56] <slangasek> thanks for the thorough analysis of regression potential, regardless
[11:56] <cyphermox> not so much
[11:57] <cyphermox> (or I don't remember well enough)
[12:32] <cyphermox> fyi, I understand liblog-any-adapter-perl is a candidate for removal, it was apparently merged into liblog-any-perl, according to the latter's changelog, and I've checked the reverse-depends which seem to be either blocked in proposed, or fixed and transitioned because of alternate depends.
[13:00] <slangasek> cyphermox: liblog-any-adapter-perl sorted (via a bit of process-removals)
[13:01] <cyphermox> slangasek: thanks. there was already a bug from micah.
[13:05] <Riddell> slangasek, doko: if you're doing new reviews could you stop for a sec, some may need rejected?
[13:06] <slangasek> Riddell: it's not me
[14:58] <Pici> a/36
[16:43] <infinity> slangasek: The "you could do multipath on USB" assertion of mine was purely theoretical as an argument for why dropping device classes is probably "wrong", but I can't imagine that it's something people actually do.
[17:52] <slangasek> infinity: IOW, you're ok with this in an SRU?
[18:01] <infinity> slangasek: Yeah, I think so.  It was just a complaint that I think the upstream logic is overreaching.
[18:01] <infinity> slangasek: But, yeah, no real person would mpath over USB in any situation I can think of, except perhaps to test mpath when you don't own enough hard drives. :P
[20:50] <cyphermox> infinity: you really just need one to test multipath...
[20:50] <cyphermox> ;)
[20:53] <infinity> cyphermox: Sorry, more disk controllers. :P
[22:08] <robru> can somebody remind me how to build touch images? IIRC I was given permission to do this forever ago and I've completely forgotten where/how to do it
[22:09] <robru> infinity: ^
[22:10] <cjwatson> iso.qa.ubuntu.com, log in, select wily daily, checkbox left of "Product (Ubuntu Touch)" which should select everything in that section, make sure "Request a rebuild" is selected at the bottom, "Update rebuild status"
[22:10] <cjwatson> or if you need vivid, ssh -t nusakan sudo -iu cdimage, crontab -l | grep touch, copy and paste the bit beginning with DIST=vivid
[22:11] <cjwatson> that's nusakan.canonical.com depending on your ssh configuration, requires VPN
[22:12] <robru> thanks
[22:13] <robru> cjwatson: is there a wiki for that anywhere?
[22:14] <infinity> cjwatson: Pretty sure he's not in cdimage (and shouldn't be).
[22:15] <cjwatson> yeah so you can probably only do the wily one
[22:15] <robru> darn
[22:15] <robru> infinity: cjwatson: will one of you be around to do the vivid one a bit later?
[22:15] <cjwatson> I won't
[22:16] <infinity> robru: Define "bit".
[22:16] <robru> infinity: I'm guessing like an hour or two, we're still waiting for one silo to be QAd and published.
[22:17] <infinity> robru: An hour, yes, two, maybe.
[22:17] <robru> infinity: alright I'll poke the qa people
[22:22] <cjwatson> fixing things so that rebuild-requests knows how to kick off vivid touch builds would be mostly a SMOP; basically moving the EXTRA_PPAS variable setting out of crontab and into a config file somewhere
[22:36] <infinity> cjwatson: We're doing that right noiw.
[22:36] <infinity> now, too.
[22:36] <infinity> (not moving things around, just fixing rebuild-requests)
[22:46] <infinity> robru: stgraber is fixing the world for you right now so you can trigger vivid from iso.qa
[22:49] <robru> oh sweet
[22:50] <robru> it's almost ready, hit publish on the silo, just waiting for the PPA to publish the packages
[23:01] <robru> infinity: I see vivid on the ISO page, is it safe for me to trigger that yet?
[23:04] <infinity> robru: When do you need to?  Are you ready?
[23:05] <robru> infinity: yep we're ready
[23:05] <infinity> robru: If so, then yes, trigger from the tracker.  Both arches, obviously.
[23:05] <infinity> robru: We're watching for debugging reasons. :)
[23:05] <robru> infinity: great, thanks for enabling that
[23:05] <infinity> robru: But it should work.
[23:05] <robru> infinity: ok I just clicked on the rebuild thing, I don't see any changes in the web interface tho
[23:06] <robru> oh it does say rebuilding, nm
[23:06] <robru> 15:59:46 <sil2100> Ok, kicking the build now
[23:07] <robru> infinity: what happens if the build is kicked twice? ^
[23:08] <infinity> robru: The one he "kicked" never happened, since it was when we had it all disabled.
[23:08] <robru> lol
[23:08] <infinity> sil2100: Perhaps people should ask if a feature is done when someone says they're implementing it on the fly? ;)
[23:13] <sil2100> What what?
[23:14] <robru> sil2100: they were enabling vivid builds on iso.qa.u.c so that I could kick a build, and I did
[23:14] <sil2100> Ah, so it got kicked already? Ok
[23:14] <sil2100> Does it use the overlay in that case?
[23:14] <sil2100> I saw a request, didn't see anyone saying 'I kicked the build' so I kicked it
[23:15] <sil2100> I told Bill explicitly that I'll be back to kick the build
[23:15] <sil2100> So I didn't even expect anybody to kick it besides me
[23:15] <sil2100> Anyway, should I terminate the command I ran on nusakan?
[23:16] <robru> infinity claimed the command you ran didn't do anything. I'm not sure what there is to cancel
[23:16] <infinity> sil2100: Err, you did it by hand?
[23:16] <sil2100> I always do it by hand through nusakan
[23:17] <infinity> sil2100: Please don't?
[23:17] <sil2100> There was no other option in the past, I got nusakan access just for this purpose - that's what ogra_ and slangasek said I should do
[23:18] <sil2100> Not sure if that changed but no one informed me that's not the right way to do it
[23:18] <infinity> Ahh.  Well, they were wrong.  That's a terrible reason to give people access to a machine with sensitive private keys on it.
[23:18] <infinity> Someone should have pointed out to us that rebuilding this from the web UI should work. :P
[23:18] <sil2100> Well, now I do much more on nusakan, but that was the original idea
[23:18] <infinity> (which it now does)
[23:19] <sil2100> Anyway, should I kill off the command now or just leave it?
[23:19] <infinity> Just leave it.
[23:19] <infinity> Just means we can't test our stuff without building again, which might annoy you.
[23:19] <infinity> But killing annoys things too, so whatever. :P
[23:19] <sil2100> Sorry for the confusion, but as I said, I explicitly coordinated with the product team manager that I'll be around and that was the plan
[23:19] <robru> alright I gotta run out, we should sync up on this tomorrow I guess
[23:19] <robru> bbl
[23:19] <infinity> sil2100: Oh.  See, robru implied that he would need help with it, hence we fixed it so he wouldn't. :P
[23:20] <robru> infinity: sil was given access to nusakan forever ago. Ancient history now
[23:21] <infinity> robru: Yeah.  Just sayin' it was probably wrong back then.  Annoyed with past people.  I'll get over it.
[23:21] <infinity> (People being given access to nusakan willy-nilly caused me to get IS to actually write policy about sensitive machines)
[23:21] <sil2100> Well, as said, I use nusakan for much more now and I think that was the deal as well, but the original idea for me getting access was to 'manage and build images'
[23:22] <sil2100> hah ;)
[23:22] <infinity> sil2100: "much more"?  system-image stuff, I assume?
[23:23] <sil2100> Yeah, basically only system-image stuff ;p
[23:23] <infinity> All of that shouldn't be on nusakan either, but I guess we need all the people who care to figure out and fix that.
[23:23] <infinity> And by "all of that", I don't mean system image backend things, but the commands one runs to manipulate them, etc.
[23:24] <infinity> Shouldn't need shell on a machine with two highly sensitive private keys.
[23:24] <infinity> Rant over.  I should go be not here.
[23:24] <sil2100> That makes sense indeed
[23:24] <infinity> In the future, rebuilding from the web UI should work.
[23:25] <sil2100> Ok, will remember that, although building it from the terminal was so convinient!
[23:25] <infinity> The web ui is actually more convenient!
[23:25] <infinity> Don't need a terminal and a screen session.
[23:46] <cjwatson> I've said this before, but the easy-ish first step to making system-image more sensible is to split it off to a separate user.
[23:46] <cjwatson> A separate machine would be good too, but is more work.
[23:46] <cjwatson> Just a separate account removes access to cdimage keys, avoids the crontab awkwardness, etc.
[23:47] <sil2100> infinity: oh, and while you're here, did you get my e-mail with -proposed britney questions by any chance?
[23:49] <sil2100> hm, actually I remember you being on a sprint this week
[23:50] <sil2100> cjwatson: yeah, I suppose that sounds like a sensible solution, a separate machine would require many changes in system-image itself
[23:57] <cjwatson> Probably not hugely many, but at least more.
[23:57] <cjwatson> AFAIK there's nothing non-trivial requiring them to share a user, though.
[23:58] <cjwatson> The transition is a bit awkward and requires coordination with IS, but that should be about it ...