=== michihenning is now known as michi [07:36] infinity: nvidia 352 in still in NEW, and as I hear now obsolete [08:12] cyphermox: looking [08:13] slangasek: (sorry :) [08:13] slangasek: also, you said golang? [08:13] cyphermox: yep; let me get up to speed on my mail and I'll find you a link [08:13] alright [08:14] cyphermox: the udev rule removal is a backport of a change already in wily? [08:15] slangasek: no, it's an adaptation of how wily works [08:15] cyphermox: hrm please expand [08:15] slangasek: things are Very Broken otherwise, system goes up in load due to multipath-tools being called repeatedly on the devices [08:15] (or udev being called repeatedly and failing to speak to the socket [08:15] cyphermox: my question is whether the udev rule is dropped in wily [08:16] no, it's still in wily [08:16] multipath doesn't work the same in wily, it's 0.5.0 [08:17] hmm [08:17] ok [08:17] I'm just trying to make things work as best I can backporting just the bits we need [08:17] so what's the test case for that change? [08:17] the udev rule specifically? [08:17] yes [08:17] *rules [08:17] btw bug #1468897 is referenced in the SRU changelog but has no SRU test case [08:17] bug 1468897 in multipath-tools (Ubuntu Trusty) "multipath creates binding for Removable(USB) drives" [Medium,In progress] https://launchpad.net/bugs/1468897 [08:18] 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] 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] cyphermox: so that's the existing behavior you see with the udev rule as it sits in trusty-updates today? [08:19] 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] slangasek: with no changes in trusty-updates, things seem to work properly [08:20] ^ that SRU changes how multipath speaks to udev (teaches multipath about udev, in short) [08:20] multipath is expected to receive the events already and handle them itself via multipathd [08:21] 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] if you upgrade, you'll see errors, and I didn't see them before [08:21] but I agree, one should already see them [08:22] heh, I guess this makes it another bug, really [08:22] 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] cyphermox: I don't need a separate bug report for this but do want an explicit test case [08:23] 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] that would be the easiest way to reproduce it [08:24] I asked to get access to hardware for that a while ago, but I didn't get a response [08:43] slangasek: I updated the two multipath bugs. [09:49] did we force something to migrate, as for me the current state of wily-release is uninstallable in a big way [10:36] apw: example? [10:41] Laney, the info is now in bug #1485970, seems apt could not figure out that it needed to configure libexpat1 [10:41] bug 1485970 in apt (Ubuntu) "apt-get dist-upgrade falied with a dbus trigger loop due to an unconfigured library (libexpat1)" [Undecided,New] https://launchpad.net/bugs/1485970 [10:42] (i think you can take it from that that my uninstallability was falsly reported by apt as it was half way through) [10:48] apw: ah right, not straight uninstallability then [10:56] Laney, no, it felt like that at first glance, but something all together different in the end === shadeslayer_ is now known as shadeslayer [11:53] 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] no [11:53] ok [11:53] there's no way to get the previous behavior back, this is just theoretical [11:53] I'm not sure *how* you would do it but it should be feasible [11:54] 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] 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] heh ok [11:54] I just couldn't apply these patches on top without breaking things [11:55] infinity: ^^ I would like a second opinion on this [11:55] right, device will be usable but not redundant via /dev/mapper. [11:55] infinity and I discussed this before ,that's why I say USB 3.0 multipath could be done, he brought it up :) [11:56] ok, so did he also voice his opinion on whether this is acceptable in an SRU? [11:56] thanks for the thorough analysis of regression potential, regardless [11:56] not so much [11:57] (or I don't remember well enough) [12:32] 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] cyphermox: liblog-any-adapter-perl sorted (via a bit of process-removals) [13:01] slangasek: thanks. there was already a bug from micah. [13:05] slangasek, doko: if you're doing new reviews could you stop for a sec, some may need rejected? [13:06] Riddell: it's not me [14:58] a/36 === ogra_` is now known as ogra_ === alexabreu is now known as alex-abreu [16:43] 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] infinity: IOW, you're ok with this in an SRU? [18:01] slangasek: Yeah, I think so. It was just a complaint that I think the upstream logic is overreaching. [18:01] 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] infinity: you really just need one to test multipath... [20:50] ;) [20:53] cyphermox: Sorry, more disk controllers. :P === thierry-ibm is now known as thf [22:08] 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] infinity: ^ [22:10] 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] 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] that's nusakan.canonical.com depending on your ssh configuration, requires VPN [22:12] thanks [22:13] cjwatson: is there a wiki for that anywhere? [22:14] cjwatson: Pretty sure he's not in cdimage (and shouldn't be). [22:15] yeah so you can probably only do the wily one [22:15] darn [22:15] infinity: cjwatson: will one of you be around to do the vivid one a bit later? [22:15] I won't [22:16] robru: Define "bit". [22:16] infinity: I'm guessing like an hour or two, we're still waiting for one silo to be QAd and published. [22:17] robru: An hour, yes, two, maybe. [22:17] infinity: alright I'll poke the qa people [22:22] 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] cjwatson: We're doing that right noiw. [22:36] now, too. [22:36] (not moving things around, just fixing rebuild-requests) [22:46] robru: stgraber is fixing the world for you right now so you can trigger vivid from iso.qa [22:49] oh sweet [22:50] it's almost ready, hit publish on the silo, just waiting for the PPA to publish the packages [23:01] infinity: I see vivid on the ISO page, is it safe for me to trigger that yet? [23:04] robru: When do you need to? Are you ready? [23:05] infinity: yep we're ready [23:05] robru: If so, then yes, trigger from the tracker. Both arches, obviously. [23:05] robru: We're watching for debugging reasons. :) [23:05] infinity: great, thanks for enabling that [23:05] robru: But it should work. [23:05] infinity: ok I just clicked on the rebuild thing, I don't see any changes in the web interface tho [23:06] oh it does say rebuilding, nm [23:06] 15:59:46 Ok, kicking the build now [23:07] infinity: what happens if the build is kicked twice? ^ [23:08] robru: The one he "kicked" never happened, since it was when we had it all disabled. [23:08] lol [23:08] sil2100: Perhaps people should ask if a feature is done when someone says they're implementing it on the fly? ;) [23:13] What what? [23:14] sil2100: they were enabling vivid builds on iso.qa.u.c so that I could kick a build, and I did [23:14] Ah, so it got kicked already? Ok [23:14] Does it use the overlay in that case? [23:14] I saw a request, didn't see anyone saying 'I kicked the build' so I kicked it [23:15] I told Bill explicitly that I'll be back to kick the build [23:15] So I didn't even expect anybody to kick it besides me [23:15] Anyway, should I terminate the command I ran on nusakan? [23:16] infinity claimed the command you ran didn't do anything. I'm not sure what there is to cancel [23:16] sil2100: Err, you did it by hand? [23:16] I always do it by hand through nusakan [23:17] sil2100: Please don't? [23:17] 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] Not sure if that changed but no one informed me that's not the right way to do it [23:18] 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] Someone should have pointed out to us that rebuilding this from the web UI should work. :P [23:18] Well, now I do much more on nusakan, but that was the original idea [23:18] (which it now does) [23:19] Anyway, should I kill off the command now or just leave it? [23:19] Just leave it. [23:19] Just means we can't test our stuff without building again, which might annoy you. [23:19] But killing annoys things too, so whatever. :P [23:19] 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] alright I gotta run out, we should sync up on this tomorrow I guess [23:19] bbl [23:19] sil2100: Oh. See, robru implied that he would need help with it, hence we fixed it so he wouldn't. :P [23:20] infinity: sil was given access to nusakan forever ago. Ancient history now [23:21] robru: Yeah. Just sayin' it was probably wrong back then. Annoyed with past people. I'll get over it. [23:21] (People being given access to nusakan willy-nilly caused me to get IS to actually write policy about sensitive machines) [23:21] 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] hah ;) [23:22] sil2100: "much more"? system-image stuff, I assume? [23:23] Yeah, basically only system-image stuff ;p [23:23] 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] And by "all of that", I don't mean system image backend things, but the commands one runs to manipulate them, etc. [23:24] Shouldn't need shell on a machine with two highly sensitive private keys. [23:24] Rant over. I should go be not here. [23:24] That makes sense indeed [23:24] In the future, rebuilding from the web UI should work. [23:25] Ok, will remember that, although building it from the terminal was so convinient! [23:25] The web ui is actually more convenient! [23:25] Don't need a terminal and a screen session. [23:46] 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] A separate machine would be good too, but is more work. [23:46] Just a separate account removes access to cdimage keys, avoids the crontab awkwardness, etc. [23:47] infinity: oh, and while you're here, did you get my e-mail with -proposed britney questions by any chance? [23:49] hm, actually I remember you being on a sprint this week [23:50] cjwatson: yeah, I suppose that sounds like a sensible solution, a separate machine would require many changes in system-image itself [23:57] Probably not hugely many, but at least more. [23:57] AFAIK there's nothing non-trivial requiring them to share a user, though. [23:58] The transition is a bit awkward and requires coordination with IS, but that should be about it ...