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