| === michihenning is now known as michi | ||
| tjaalton | infinity: nvidia 352 in still in NEW, and as I hear now obsolete | 07:36 |
|---|---|---|
| slangasek | cyphermox: looking | 08:12 |
| 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:13 |
| slangasek | cyphermox: the udev rule removal is a backport of a change already in wily? | 08:14 |
| 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:15 |
| cyphermox | no, it's still in wily | 08:16 |
| cyphermox | multipath doesn't work the same in wily, it's 0.5.0 | 08:16 |
| 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:17 |
| ubot93 | bug 1468897 in multipath-tools (Ubuntu Trusty) "multipath creates binding for Removable(USB) drives" [Medium,In progress] https://launchpad.net/bugs/1468897 | 08:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| cyphermox | I asked to get access to hardware for that a while ago, but I didn't get a response | 08:24 |
| cyphermox | slangasek: I updated the two multipath bugs. | 08:43 |
| apw | did we force something to migrate, as for me the current state of wily-release is uninstallable in a big way | 09:49 |
| Laney | apw: example? | 10:36 |
| apw | Laney, the info is now in bug #1485970, seems apt could not figure out that it needed to configure libexpat1 | 10:41 |
| ubot93 | 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: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 |
| Laney | apw: ah right, not straight uninstallability then | 10:48 |
| apw | Laney, no, it felt like that at first glance, but something all together different in the end | 10:56 |
| === shadeslayer_ is now known as shadeslayer | ||
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| cyphermox | (or I don't remember well enough) | 11:57 |
| 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. | 12:32 |
| slangasek | cyphermox: liblog-any-adapter-perl sorted (via a bit of process-removals) | 13:00 |
| cyphermox | slangasek: thanks. there was already a bug from micah. | 13:01 |
| Riddell | slangasek, doko: if you're doing new reviews could you stop for a sec, some may need rejected? | 13:05 |
| slangasek | Riddell: it's not me | 13:06 |
| Pici | a/36 | 14:58 |
| === ogra_` is now known as ogra_ | ||
| === alexabreu is now known as alex-abreu | ||
| 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. | 16:43 |
| slangasek | infinity: IOW, you're ok with this in an SRU? | 17:52 |
| 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 | 18:01 |
| cyphermox | infinity: you really just need one to test multipath... | 20:50 |
| cyphermox | ;) | 20:50 |
| infinity | cyphermox: Sorry, more disk controllers. :P | 20:53 |
| === thierry-ibm is now known as thf | ||
| 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:08 |
| robru | infinity: ^ | 22:09 |
| 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:10 |
| cjwatson | that's nusakan.canonical.com depending on your ssh configuration, requires VPN | 22:11 |
| robru | thanks | 22:12 |
| robru | cjwatson: is there a wiki for that anywhere? | 22:13 |
| infinity | cjwatson: Pretty sure he's not in cdimage (and shouldn't be). | 22:14 |
| 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:15 |
| 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:16 |
| infinity | robru: An hour, yes, two, maybe. | 22:17 |
| robru | infinity: alright I'll poke the qa people | 22:17 |
| 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:22 |
| 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:36 |
| infinity | robru: stgraber is fixing the world for you right now so you can trigger vivid from iso.qa | 22:46 |
| robru | oh sweet | 22:49 |
| robru | it's almost ready, hit publish on the silo, just waiting for the PPA to publish the packages | 22:50 |
| robru | infinity: I see vivid on the ISO page, is it safe for me to trigger that yet? | 23:01 |
| infinity | robru: When do you need to? Are you ready? | 23:04 |
| 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:05 |
| robru | oh it does say rebuilding, nm | 23:06 |
| robru | 15:59:46 <sil2100> Ok, kicking the build now | 23:06 |
| robru | infinity: what happens if the build is kicked twice? ^ | 23:07 |
| 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:08 |
| sil2100 | What what? | 23:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| robru | infinity: sil was given access to nusakan forever ago. Ancient history now | 23:20 |
| 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:21 |
| sil2100 | hah ;) | 23:22 |
| infinity | sil2100: "much more"? system-image stuff, I assume? | 23:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:46 |
| sil2100 | infinity: oh, and while you're here, did you get my e-mail with -proposed britney questions by any chance? | 23:47 |
| sil2100 | hm, actually I remember you being on a sprint this week | 23:49 |
| sil2100 | cjwatson: yeah, I suppose that sounds like a sensible solution, a separate machine would require many changes in system-image itself | 23:50 |
| 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:57 |
| cjwatson | The 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!