| plars | xnox: I'm having trouble locating it at the moment, but istr there was a recent bug with auto-resize where it would let you proceed even if there wasn't enough space to install the new system. I think I'm still hitting it but I can't seem to locate the bug #. Is this one you know offhand? | 14:27 |
|---|---|---|
| bdmurray | xnox: bug 1162454 has a couple of duplicates | 15:21 |
| ubot2` | Launchpad bug 1162454 in ubiquity (Ubuntu) "Installer was crashing" [High,Confirmed] https://launchpad.net/bugs/1162454 | 15:21 |
| plars | I seem to be stuck on an oem install at: | 18:23 |
| plars | Applying changes - Noting disappearance of ubiquity | 18:23 |
| plars | it's been stuck here for at least the past 2 hours | 18:23 |
| plars | when I unroll the details, it says "dpkg: ubiquity: dependency problems, but removing anyway as you requested: ubiquity-frontend-gtk depends on ubiquity (= 2.13.18)" | 18:24 |
| cjwatson | plars: bug 1161943, fixed in ubiquity 2.4.1 | 19:34 |
| ubot2` | Launchpad bug 1161943 in System76 "oem-config hangs when removing ubquity" [Undecided,New] https://launchpad.net/bugs/1161943 | 19:34 |
| cjwatson | er, 2.14.0 | 19:34 |
| plars | cjwatson: thanks! | 19:37 |
| plars | I was just in the process of reproducing it on another machine | 19:37 |
| plars | cjwatson: is there due to be another spin soon? latest I have is from Thursday | 19:38 |
| cjwatson | plars: a bunch of things got stuck - I thought I'd cleared it earlier but there still seems to be something going on | 19:39 |
| plars | cjwatson: ack | 19:39 |
| cjwatson | looking as time permits | 19:39 |
| cjwatson | Hm, I fear the new code doesn't handle kills of ssh triggers | 19:47 |
| infinity | cjwatson: The old code didn't kill SSH triggers either. At least, not in any way that killed the other end. | 21:11 |
| cjwatson | No, that wasn't quite what I meant though | 21:17 |
| cjwatson | A bunch of cron.* processes on nusakan were apparently hung waiting for non-existent child processes | 21:18 |
| cjwatson | Which is confusing because os.wait() should have come back | 21:18 |
| cjwatson | But not working today, so I just did minimal cleanup so that builds could proceed, after failing to gather any more useful information | 21:19 |
| infinity | You'd think os.wait would be a really thin wrapper around something sane. | 21:20 |
| cjwatson | It is | 21:20 |
| cjwatson | Unfortunately I can't tell what was really going on due to fascist ptrace restrictions | 21:21 |
| cjwatson | So I was mostly guessing | 21:21 |
| infinity | Blame kees. | 21:21 |
| infinity | I do. | 21:21 |
| * antarus blames kees for everything | 21:21 | |
| cjwatson | And I couldn't reproduce a similar problem in a cut-down test case | 21:22 |
| cjwatson | So meh | 21:22 |
| * antarus grumbles about yama | 21:22 | |
| cjwatson | Anyhow, I've poked Ubuntu desktop image builds | 21:23 |
| * infinity misread that as "puked". | 21:23 | |
| cjwatson | That too | 21:24 |
| infinity | "Here, let me vomit out some images for you." | 21:24 |
| cjwatson | Oh, I suspect I see why cron.* was hung. It was trying to fetch the livefs build log without a timeout. | 23:12 |
| cjwatson | Cron mail clarified that my os.wait guess was entirely wrong. | 23:16 |
| * cjwatson fixes | 23:17 | |
| cjwatson | That's a relief. I was wondering if everything I knew about Unix process handling was wrong. | 23:21 |
| cjwatson | Which, I mean, it probably still is, just more subtly. | 23:21 |
| infinity | Heh | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!