| RAOF | bdmurray: How does one override phased-update percentages when an SRU has been stopped by errors.ubuntu.com crashes? | 01:53 |
|---|---|---|
| slangasek | RAOF: change-override -z | 04:10 |
| RAOF | slangasek: That would not continue the gradual ramp up to 100%, correct? | 04:12 |
| RAOF | For clarity: the crash that's stopped the phased-update appears to unrelated to the update, and is just a fairly rare crash that happened to be first seen (again) with the update. | 04:13 |
| RAOF | (file-roller, crash is https://errors.ubuntu.com/problem/a595b32f105a3f7cb708c518855658d3e48eea2c ) | 04:14 |
| slangasek | RAOF: i don't recall if that causes the phasing to be picked up again or not; I think it does? | 04:15 |
| RAOF | So, “change-override -s xenial -z 100 file-roller” would appear to be the correct invocation. | 04:17 |
| slangasek | to override and fully phase, yes | 04:18 |
| RAOF | It hadn't got to fully-phased before being killed; phased-updates.html says it got to 30%. So perhaps a more correct invocation would be “change-override -s xenial -z 30 file-roller” and then it will be picked back up and gradually phased to 100%? | 04:22 |
| RAOF | Oooh. Or, in fact, not. Need -s xenial-updates rather than -s xenial! | 04:31 |
| === cpaelzer_ is now known as cpaelzer | ||
| === NCommander is now known as mcasadevall | ||
| LocutusOfBorg | can anybody please remove mame on ppc64el? it has been removed in Debian, and should make it migrate | 09:18 |
| mwhudson | can someone delete https://launchpad.net/ubuntu/+source/golang-defaults/2:1.6.1+1ubuntu2~ppa1 ? | 09:30 |
| mwhudson | i've already uploaded a package with a non bogus version | 09:31 |
| mwhudson | (the former mentioned package is in NEW) | 09:31 |
| apw | mwhudson, ~ppa rejected | 12:48 |
| apw | mwhudson, the source should be reaped in nbs once your new one is accepted | 12:49 |
| === ratliff_ is now known as ratliff | ||
| bdmurray | RAOF: https://code.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides | 15:22 |
| cyphermox | I'm curious, what do autopkgtests have access to? can they only reach the archive or could we also ship, say, a preseed file on people.c.c or people.u.c to script the install of a VM to do integration tests that require a BIOS implementation to be run? | 15:32 |
| cyphermox | I'm thinking of an autopkgtest that could boot, install a VM, and drop some file in a specific location that could then be read from outside the VM to make sure it has booted with Secure Boot; for instance. | 15:32 |
| cyphermox | well, really, boot and install a new VM, then reboot with the install (which would have to have installed the package to test), and then drop a file, or otherwise have some way of checking results | 15:34 |
| cyphermox | AFAIK we can run VMs in an autopkgtest, the issue is whether a preseed might be reachable so that the install can be scripted. | 15:34 |
| rbasak | AIUI that would work, but I don't think it's wise to add external dependencies like that unless there's really no other way. And even then I'm not convinced. In this case, can you serve the preseed from the host of the VM? | 15:41 |
| cyphermox | rbasak: I suppose that could be done yes, it just increases the complexity of the test | 16:08 |
| cyphermox | rbasak: I'm asking because I already do ship a bunch of preseeds that I use elsewhere, on p.c.c | 16:09 |
| rbasak | cyphermox: it feels like they should be part of the test though, and not external. At the very least, store a copy of the preseeds inside the test and verify that the hosted ones are available and are identical. That might help someone avoid tearing hair out in future. | 16:10 |
| rbasak | Verify before running the actual test, that is. | 16:10 |
| rbasak | Also I'd get an ack from pitti or jibel or someone like that before proceeding. | 16:11 |
| cyphermox | that was the point by asking here. | 16:11 |
| rbasak | (I don't see pitti here) | 16:11 |
| rbasak | Sure - I'm just pointing out that I don't consider myself a pitti or a jibel, if that isn't obvious :-) | 16:11 |
| cyphermox | rbasak: well, your idea is not bad. making the preseed available from the test would be the best way to do it and it's not very complicated either as long as the networking for the VM happens correctly | 16:22 |
| cyphermox | rbasak: http://paste.ubuntu.com/17649438/ | 16:22 |
| rbasak | cyphermox: that's just a bit evil :) | 16:41 |
| rbasak | cyphermox: how about test-depending on apache2 and then just sticking the file into /var/www/html/? I think that should work. | 16:42 |
| cyphermox | rbasak: I was kind of opting to make it as lean as possible | 16:45 |
| cyphermox | but it looks like that will be necessary anyway, as I can't be bothered to otherwise clean up after that script | 16:46 |
| rbasak | Why? I'd swing more towards minimal code + less chance of false positives. | 16:46 |
| rbasak | If I upload an apache2 that breaks /var/www/html from working, that'll be my problem ;) | 16:46 |
| cyphermox | rbasak: what do you mean by minimal code? | 16:48 |
| cyphermox | you mean depending on apache2? | 16:48 |
| rbasak | cyphermox: I just meant that I wouldn't write many lines of code to achieve correctness either. Not that either of us are suggesting it, just explaining my principle here. | 16:49 |
| rbasak | But both of the options are minimal, so I favour the more correct one, at the cost of lean-ness in terms of test execution time. | 16:50 |
| cyphermox | rbasak: right, I agree | 16:50 |
| cyphermox | at least I can rely on service x start/service x stop to DTRT and not have to care about it. | 16:50 |
| rbasak | Yeah. Also things like concurrent hits to the server. | 16:50 |
| rbasak | Or a race while it loops round again. | 16:50 |
| cyphermox | bah, it's not like this is really expecting to get many hits | 16:51 |
| cyphermox | really, probably just once in the lifetime of a test. | 16:51 |
| rbasak | I can't think of a real world failure case either, and if you look into the details you might be able to demonstrate that there isn't one. | 16:51 |
| cyphermox | I don't care enough to bother ;) | 16:51 |
| rbasak | But one day d-i will start doing a HEAD before the GET or something, and you'll hit the race. Not worth looking :) | 16:52 |
| cyphermox | I was just thinking about whether it would be feasible to fully preseed a VM to DTRT here to test shim-signed or some other EFI blobs. | 16:52 |
| rbasak | (and when that day comes, someone will spend time figuring out why and then will want to hit you with something. Worth avoiding :-) | 16:52 |
| cyphermox | depends, it would likely be me wanting to hit myself over the head with something | 16:53 |
| bdmurray | Trevinho: you'd asked about compiz entering -updates these two errors still seem like they are new issues with the new version of compiz. https://errors.ubuntu.com/problem/a18b45b1acd6f9f0efe1c7533b04c92a5d830334 and https://errors.ubuntu.com/problem/7f28efb5fc498dcae25332fbdfdd56af6a47eb80 | 16:54 |
| Trevinho | bdmurray: hoestly I think these issues aren't unrelated to what the SRU changed | 16:57 |
| bdmurray | Trevinho: you mean aren't related right? | 16:58 |
| Trevinho | yeah, sorry bdmurray | 16:58 |
| seb128 | bdmurray, the file-roller issue should be cleared off as well | 17:07 |
| bdmurray | slangasek, infinity: could you fully phase compiz for xenial? | 17:07 |
| bdmurray | seb128: ack | 17:08 |
| seb128 | thanks | 17:08 |
| bdmurray | seb128: should we create an LP bug for it though? | 17:08 |
| seb128 | bdmurray, you can, looks like that bug was already there in trusty and got some reports there, it might be worth trying to fix at some point | 17:10 |
| bdmurray | seb128: okay, it doesn't seem as prevalent now though | 17:16 |
| seb128 | right, I think it's a pretty uncommon issue and not that important | 17:16 |
| slangasek | bdmurray: compiz phasing done | 17:25 |
| bdmurray | slangasek: thanks | 17:31 |
| === mcasadevall is now known as NCommander | ||
| cyphermox | I validated a SRU earlier today by downloading a package manually from LP; it looks as though things aren't being published for precise-proposed --- I still haven't seen mokutil pop up there, and it should have become available in proposed a few hours ago already | 20:11 |
| cyphermox | ie. timestamp for /ubuntu/dists/precise-proposed/main/binary-amd64/Packages.{bz2,gz} still has 2016-06-16 as a timestamp; I'm wondering if it's situation normal and it takes many hours for things to publish in the archive after they're cleared from Accepted; or if something is wrong, or if I'm looking at the wrong place | 20:12 |
| bdmurray | cyphermox: I'm confused you said validated an SRU but also said precise-proposed. I think validation would mean moving from -proposed to -updates. | 20:49 |
| infinity | cyphermox: Hrm? The mokutil in precise-proposed was published 5 hours ago. In theory. | 20:51 |
| * infinity looks. | 20:51 | |
| infinity | cyphermox: Oh. But that landed in universe. Should fix that. | 20:56 |
| infinity | cyphermox: Moved to main for precise/trusty/wily. | 20:57 |
| mwhudson | apw: thanks | 21:07 |
| cyphermox | bdmurray: verifying; then, except I had to retrieve it straight from the launchpad build | 21:14 |
| cyphermox | infinity: I was looking at both universe and main, neither seemed to list it | 21:15 |
| bdmurray | cyphermox: Ah, I get it. To perform the validation you had get the package from Launchpad. | 21:20 |
| cyphermox | yes | 21:20 |
| cyphermox | and what I mean is that for instance, the timestamp on http://archive.ubuntu.com/ubuntu/dists/precise-proposed/InRelease looks off. | 21:20 |
| infinity | cyphermox: Should be sorted as of the next mirror pulse (ie: it looks good on ftpmaster now) | 21:50 |
| * infinity goes hunting for hamburgers. | 21:55 | |
| cyphermox | infinity: coolio, thanks | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!