=== michihenning is now known as michi
tjaaltoninfinity: nvidia 352 in still in NEW, and as I hear now obsolete07:36
slangasekcyphermox: looking08:12
cyphermoxslangasek: (sorry :)08:13
cyphermoxslangasek: also, you said golang?08:13
slangasekcyphermox: yep; let me get up to speed on my mail and I'll find you a link08:13
slangasekcyphermox: the udev rule removal is a backport of a change already in wily?08:14
cyphermoxslangasek: no, it's an adaptation of how wily works08:15
slangasekcyphermox: hrm please expand08:15
cyphermoxslangasek: things are Very Broken otherwise, system goes up in load due to multipath-tools being called repeatedly on the devices08:15
cyphermox(or udev being called repeatedly and failing to speak to the socket08:15
slangasekcyphermox: my question is whether the udev rule is dropped in wily08:15
cyphermoxno, it's still in wily08:16
cyphermoxmultipath doesn't work the same in wily, it's 0.5.008:16
cyphermoxI'm just trying to make things work as best I can backporting just the bits we need08:17
slangasekso what's the test case for that change?08:17
cyphermoxthe udev rule specifically?08:17
slangasekbtw bug #1468897 is referenced in the SRU changelog but has no SRU test case08:17
ubot93bug 1468897 in multipath-tools (Ubuntu Trusty) "multipath creates binding for Removable(USB) drives" [Medium,In progress] https://launchpad.net/bugs/146889708:17
cyphermoxif 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 path08:18
slangasekif it's a duplicate of the other, please mark it as a duplicate.  If it's not, please add an explicit test case for it08:18
slangasekcyphermox: so that's the existing behavior you see with the udev rule as it sits in trusty-updates today?08:18
cyphermoxand 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 processes08:19
cyphermoxslangasek: with no changes in trusty-updates, things seem to work properly08:19
cyphermox^ that SRU changes how multipath speaks to udev (teaches multipath about udev, in short)08:20
cyphermoxmultipath is expected to receive the events already and handle them itself via multipathd08:20
slangasekcyphermox: 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 accurate08:21
cyphermoxif you upgrade, you'll see errors, and I didn't see them before08:21
cyphermoxbut I agree, one should already see them08:21
cyphermoxheh, I guess this makes it another bug, really08:22
slangasekcyphermox: 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:22
slangasekcyphermox: I don't need a separate bug report for this but do want an explicit test case08:23
cyphermoxslangasek: I'll get it on the bug report, it should have been there. In short, simulate paths appearing and disappearing by breaking FC links08:23
cyphermoxthat would be the easiest way to reproduce it08:23
cyphermoxI asked to get access to hardware for that a while ago, but I didn't get a response08:24
cyphermoxslangasek: I updated the two multipath bugs.08:43
apwdid we force something to migrate, as for me the current state of wily-release is uninstallable in a big way09:49
Laneyapw: example?10:36
apwLaney, the info is now in bug #1485970, seems apt could not figure out that it needed to configure libexpat110:41
ubot93bug 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/148597010:41
apw(i think you can take it from that that my uninstallability was falsly reported by apt as it was half way through)10:42
Laneyapw: ah right, not straight uninstallability then10:48
apwLaney, no, it felt like that at first glance, but something all together different in the end10:56
=== shadeslayer_ is now known as shadeslayer
slangasekcyphermox: "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
cyphermoxthere's no way to get the previous behavior back, this is just theoretical11:53
cyphermoxI'm not sure *how* you would do it but it should be feasible11:53
cyphermoxbut 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
slangasekso 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 redundancy11:54
slangasekheh ok11:54
cyphermoxI just couldn't apply these patches on top without breaking things11:54
slangasekinfinity: ^^ I would like a second opinion on this11:55
cyphermoxright, device will be usable but not redundant via /dev/mapper.11:55
cyphermoxinfinity and I discussed this before ,that's why I say USB 3.0 multipath could be done, he brought it up :)11:55
slangasekok, so did he also voice his opinion on whether this is acceptable in an SRU?11:56
slangasekthanks for the thorough analysis of regression potential, regardless11:56
cyphermoxnot so much11:56
cyphermox(or I don't remember well enough)11:57
cyphermoxfyi, 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.12:32
slangasekcyphermox: liblog-any-adapter-perl sorted (via a bit of process-removals)13:00
cyphermoxslangasek: thanks. there was already a bug from micah.13:01
Riddellslangasek, doko: if you're doing new reviews could you stop for a sec, some may need rejected?13:05
slangasekRiddell: it's not me13:06
=== ogra_` is now known as ogra_
=== alexabreu is now known as alex-abreu
infinityslangasek: 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.16:43
slangasekinfinity: IOW, you're ok with this in an SRU?17:52
infinityslangasek: Yeah, I think so.  It was just a complaint that I think the upstream logic is overreaching.18:01
infinityslangasek: 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. :P18:01
cyphermoxinfinity: you really just need one to test multipath...20:50
infinitycyphermox: Sorry, more disk controllers. :P20:53
=== thierry-ibm is now known as thf
robrucan 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 it22:08
robruinfinity: ^22:09
cjwatsoniso.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
cjwatsonor if you need vivid, ssh -t nusakan sudo -iu cdimage, crontab -l | grep touch, copy and paste the bit beginning with DIST=vivid22:10
cjwatsonthat's nusakan.canonical.com depending on your ssh configuration, requires VPN22:11
robrucjwatson: is there a wiki for that anywhere?22:13
infinitycjwatson: Pretty sure he's not in cdimage (and shouldn't be).22:14
cjwatsonyeah so you can probably only do the wily one22:15
robruinfinity: cjwatson: will one of you be around to do the vivid one a bit later?22:15
cjwatsonI won't22:15
infinityrobru: Define "bit".22:16
robruinfinity: I'm guessing like an hour or two, we're still waiting for one silo to be QAd and published.22:16
infinityrobru: An hour, yes, two, maybe.22:17
robruinfinity: alright I'll poke the qa people22:17
cjwatsonfixing 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 somewhere22:22
infinitycjwatson: We're doing that right noiw.22:36
infinitynow, too.22:36
infinity(not moving things around, just fixing rebuild-requests)22:36
infinityrobru: stgraber is fixing the world for you right now so you can trigger vivid from iso.qa22:46
robruoh sweet22:49
robruit's almost ready, hit publish on the silo, just waiting for the PPA to publish the packages22:50
robruinfinity: I see vivid on the ISO page, is it safe for me to trigger that yet?23:01
infinityrobru: When do you need to?  Are you ready?23:04
robruinfinity: yep we're ready23:05
infinityrobru: If so, then yes, trigger from the tracker.  Both arches, obviously.23:05
infinityrobru: We're watching for debugging reasons. :)23:05
robruinfinity: great, thanks for enabling that23:05
infinityrobru: But it should work.23:05
robruinfinity: ok I just clicked on the rebuild thing, I don't see any changes in the web interface tho23:05
robruoh it does say rebuilding, nm23:06
robru15:59:46 <sil2100> Ok, kicking the build now23:06
robruinfinity: what happens if the build is kicked twice? ^23:07
infinityrobru: The one he "kicked" never happened, since it was when we had it all disabled.23:08
infinitysil2100: Perhaps people should ask if a feature is done when someone says they're implementing it on the fly? ;)23:08
sil2100What what?23:13
robrusil2100: they were enabling vivid builds on iso.qa.u.c so that I could kick a build, and I did23:14
sil2100Ah, so it got kicked already? Ok23:14
sil2100Does it use the overlay in that case?23:14
sil2100I saw a request, didn't see anyone saying 'I kicked the build' so I kicked it23:14
sil2100I told Bill explicitly that I'll be back to kick the build23:15
sil2100So I didn't even expect anybody to kick it besides me23:15
sil2100Anyway, should I terminate the command I ran on nusakan?23:15
robruinfinity claimed the command you ran didn't do anything. I'm not sure what there is to cancel23:16
infinitysil2100: Err, you did it by hand?23:16
sil2100I always do it by hand through nusakan23:16
infinitysil2100: Please don't?23:17
sil2100There was no other option in the past, I got nusakan access just for this purpose - that's what ogra_ and slangasek said I should do23:17
sil2100Not sure if that changed but no one informed me that's not the right way to do it23:18
infinityAhh.  Well, they were wrong.  That's a terrible reason to give people access to a machine with sensitive private keys on it.23:18
infinitySomeone should have pointed out to us that rebuilding this from the web UI should work. :P23:18
sil2100Well, now I do much more on nusakan, but that was the original idea23:18
infinity(which it now does)23:18
sil2100Anyway, should I kill off the command now or just leave it?23:19
infinityJust leave it.23:19
infinityJust means we can't test our stuff without building again, which might annoy you.23:19
infinityBut killing annoys things too, so whatever. :P23:19
sil2100Sorry for the confusion, but as I said, I explicitly coordinated with the product team manager that I'll be around and that was the plan23:19
robrualright I gotta run out, we should sync up on this tomorrow I guess23:19
infinitysil2100: Oh.  See, robru implied that he would need help with it, hence we fixed it so he wouldn't. :P23:19
robruinfinity: sil was given access to nusakan forever ago. Ancient history now23:20
infinityrobru: 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
sil2100Well, 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:21
sil2100hah ;)23:22
infinitysil2100: "much more"?  system-image stuff, I assume?23:22
sil2100Yeah, basically only system-image stuff ;p23:23
infinityAll 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
infinityAnd by "all of that", I don't mean system image backend things, but the commands one runs to manipulate them, etc.23:23
infinityShouldn't need shell on a machine with two highly sensitive private keys.23:24
infinityRant over.  I should go be not here.23:24
sil2100That makes sense indeed23:24
infinityIn the future, rebuilding from the web UI should work.23:24
sil2100Ok, will remember that, although building it from the terminal was so convinient!23:25
infinityThe web ui is actually more convenient!23:25
infinityDon't need a terminal and a screen session.23:25
cjwatsonI'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
cjwatsonA separate machine would be good too, but is more work.23:46
cjwatsonJust a separate account removes access to cdimage keys, avoids the crontab awkwardness, etc.23:46
sil2100infinity: oh, and while you're here, did you get my e-mail with -proposed britney questions by any chance?23:47
sil2100hm, actually I remember you being on a sprint this week23:49
sil2100cjwatson: yeah, I suppose that sounds like a sensible solution, a separate machine would require many changes in system-image itself23:50
cjwatsonProbably not hugely many, but at least more.23:57
cjwatsonAFAIK there's nothing non-trivial requiring them to share a user, though.23:57
cjwatsonThe transition is a bit awkward and requires coordination with IS, but that should be about it ...23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!