| slangasek | netcfg accepted | 00:00 |
|---|---|---|
| cjwatson | thanks! | 00:01 |
| cjwatson | Daviey: ^- | 00:01 |
| Daviey | cjwatson: oh lovely. | 00:03 |
| Daviey | thanks | 00:03 |
| mdeslaur | infinity: uhm, any ideas why the old flash version disappeared from the partner archive? | 00:08 |
| mdeslaur | I guess I'll upload a i386 only flash 11 flashplugin-nonfree for now | 00:10 |
| lamont | wgrant: that's good to know. I expected it was the case, but whenever I don't remember, I get all paranoid. | 00:16 |
| slangasek | mdeslaur: because when the new one is uploaded the previous version eventually gets garbage collected | 00:16 |
| mdeslaur | slangasek: we had that stopped a while ago, specifically for this reason.. | 00:17 |
| slangasek | oh? who stopped it where/how? | 00:17 |
| slangasek | and was that related to why cocoplum has been failing to garbage collect at all for a while, causing the mirroring script to overrun and blow up? :) | 00:18 |
| mdeslaur | slangasek: I think it was infinity last time, but I'm not sure | 00:18 |
| mdeslaur | slangasek: could be related, I'm not sure how it was stopped | 00:19 |
| cjwatson | [5~/wg 97 | 00:20 |
| cjwatson | bah | 00:20 |
| mdeslaur | doesn't make sense that we break the _installer_ for two days every two weeks when we publish a new flash | 00:20 |
| wgrant | In LP's defense, it also doesn't make sense to pull stuff from partner directly like that. | 00:24 |
| mdeslaur | wgrant: it's a terrible terrible hack, flashplugin-nonfree need to die.die.die | 00:25 |
| wgrant | slangasek: cocoplum's process-death-row was broken because of ancient DB breakage from when we tried to delete dapper. It should have been working for ~2 weeks now, though. | 00:25 |
| slangasek | yep | 00:25 |
| slangasek | mdeslaur: doesn't the installer know how to fall back to the Adobe website if it can't find it on partner, in which case making sure we always update the installer package *first* would help? | 00:26 |
| mdeslaur | slangasek: no, it doesn't know, and the reason we moved it to the partner archive was that adobe removed the old version before we could even get it into the partner archive | 00:27 |
| slangasek | yes - but having it try partner, with adobe as a fallback, means that the installer will always be able to pull from one of the two sites | 00:28 |
| slangasek | but if infinity has some other special way to prevent garbage-collection of old versions, that's fine too | 00:29 |
| mdeslaur | that would be an improvement, but that wouldn't solve the problem we have, which is once the new version comes out, the old one gets nuked everywhere | 00:29 |
| slangasek | how does it not solve the problem? | 00:29 |
| mdeslaur | when it's gone in partner, it's also gone from the adobe site | 00:29 |
| slangasek | it ensures that the current version of the installer package always works | 00:29 |
| slangasek | no, the point is to make sure it's *not* gone from partner until the installer package is updated | 00:29 |
| mdeslaur | right | 00:30 |
| slangasek | new adobe release - everything pulls from archive.c.c in preference | 00:30 |
| slangasek | new installer package - can't find it on archive.c.c, pulls from adobe | 00:30 |
| slangasek | new package pushed to partner - installer pulls from archive.c.c again | 00:31 |
| skaet | slangasek, infinity, yes, that is my understanding of what pitti and ogasawara worked out. | 00:31 |
| skaet | ogasawaraYesterday we uploaded a new linux-meta-3.0.0-12.14 to resolve some missing meta-packages. This morning we also uploaded a new linux-3.0.0-12.20 kernel to resolve unmet install dependency issues for linux-image-extra. We uploaded to -proposed as a safety precaution in case it takes too long to build. It will be copied to the release pocket should it finish building in time, else it'll be promoted to -up | 00:31 |
| skaet | dates as a day 0. | 00:31 |
| mdeslaur | slangasek: new package is always pushed to partner before we update the multiverse package | 00:32 |
| mdeslaur | also, adobe tarball is _very_ different from what we ship | 00:32 |
| mdeslaur | so we'll need to understand both formats / both hash sums | 00:32 |
| skaet | slangasek, infinity: quote above was from release team meeting today, also there, pitti indicated getting the linux into the images to test for toolchain regressions and the like was desirable. | 00:34 |
| slangasek | skaet: ... what toolchain regressions? | 00:36 |
| slangasek | that is, toolchain regressions from what? | 00:37 |
| slangasek | anyway - yes, will copy to the release pocket then | 00:37 |
| skaet | slangasek, toolchain parts changed since last kernel was built. | 00:37 |
| skaet | not expecting to see anything be an issue, but early testing rather than later seemed appropriate. | 00:38 |
| skaet | or at least that was how I understood pitti's comments. | 00:38 |
| slangasek | if there is a toolchain-induced regression, we have no time to fix the toolchain anyway | 00:38 |
| slangasek | so if that's really a concern, it's better to NOT push to release | 00:38 |
| slangasek | so that the testing can be done in a manner that doesn't compromise the release | 00:39 |
| skaet | http://irclogs.ubuntu.com/2011/10/07/%23ubuntu-meeting.html#t15:42 | 00:39 |
| mdeslaur | infinity, slangasek, skaet: I just uploaded a minimal change flashplugin-nonfree to fix the issue | 00:39 |
| skaet | thanks mdeslaur | 00:39 |
| slangasek | mdeslaur: thanks. are you also planning to fix the flashplugin-downloader return code before release? | 00:40 |
| mdeslaur | slangasek: I included that in the upload also | 00:40 |
| slangasek | mdeslaur: yay :) | 00:40 |
| wgrant | mdeslaur: I wonder if the old workaround was to rsync partner without deleting. | 00:40 |
| mdeslaur | slangasek: :) | 00:40 |
| wgrant | There was nothing to keep them on cocoplum, AFAIK. | 00:41 |
| mdeslaur | wgrant: let me try and find the previous discussion in my irc logs, one sec | 00:41 |
| Daviey | Surely when adobe release a new one, flashplugin-nonfree stops functioning as the wget (or md5sum) fails? | 00:45 |
| mdeslaur | Daviey: yes, that was the original problem, that way someone moved the wget to the partner archive at some point in the past | 00:46 |
| mdeslaur | adobe doesn't archive past releases | 00:46 |
| skaet | slagasek, http://irclogs.ubuntu.com/2011/10/07/%23ubuntu-release.html, around 15:00-15:40. | 00:48 |
| slangasek | skaet: sorry, what am I looking at? The only thing I see in that time range is about archive opening for P? | 00:49 |
| skaet | slangasek, no worries, was an iterspersed conversation. 15:49: doko/pitti comments. | 00:51 |
| mdeslaur | wgrant: sorry, I can't find the discussion in my logs | 00:51 |
| slangasek | skaet: ah, I see | 00:52 |
| cjwatson | I don't think a toolchain regression should be a concern; for that to be plausible, the toolchain would have to have changed | 00:52 |
| skaet | slangasek, 14:08, me realizing that there was a kernel spin going on. | 00:52 |
| cjwatson | there've been libc changes, but they have negligible effect on the kernel | 00:53 |
| cjwatson | gcc-4.6 and binutils have not been uploaded since the last kernel upload | 00:53 |
| skaet | cjwatson, there was a binutils change I thought in the window between kernels. | 00:53 |
| skaet | hmm... if you think not, I'll double check. | 00:53 |
| cjwatson | no, there wasn't; the last binutils change was completely published before the last kernel upload. | 00:54 |
| slangasek | skaet: so basically, I have no problem with copying the kernel from proposed to the release pocket because I'm confident that there's no risk of regression from the toolchain. I just think "check for toolchain regressions" is a bogus justification for doing the copying, because this is the one place we don't want to find out about them. | 00:54 |
| skaet | slangasek, cjwatson, kernel published on 9/23 ABI bump. binutils on 9/20. yes, toolchain should be fine. | 00:58 |
| cjwatson | 9/22 but who's counting :) | 00:58 |
| cjwatson | (changelog date != upload date) | 00:59 |
| skaet | chuckle, yeah you're right. | 00:59 |
| skaet | :) | 00:59 |
| cjwatson | [5~/wg 97 | 00:59 |
| cjwatson | *sigh* | 00:59 |
| skaet | huh?? | 00:59 |
| cjwatson | laggy system running my IRC client | 00:59 |
| cjwatson | occasionally misinterprets control characters | 01:00 |
| skaet | thanks, was a confusing set. | 01:00 |
| skaet | slangasek, please do the copy. I think we're all convinced at this point, and may as well pick it up in next set of builds. | 01:03 |
| slangasek | skaet: copy done | 01:03 |
| slangasek | afk for dinner | 01:03 |
| * skaet hopes that she doesn't live to regret those words... crossing fingers. | 01:03 | |
| skaet | thanks slangasek, enjoy dinner. | 01:03 |
| Daviey | it will go horrible wrong.. just to keep life interesting. | 01:06 |
| cjwatson | I'll do a d-i upload tomorrow or so to pick that up | 01:09 |
| skaet | ^ mdeslaur , thanks. looked good. | 01:44 |
| skaet | infinity, slangasek - just downloaded the latest software-center update, and am not able to install packages - keep getting installArchives() failed: Selecting previously deselected package <insert name of package> tried it with 3 separate packages, can you confirm? | 02:26 |
| skaet | yet it does seem to show up as installed. | 02:27 |
| infinity | skaet: That's disconcerting. | 02:39 |
| skaet | infinity, indeed. Can you try it. | 02:40 |
| infinity | Yeah, I'm looking for something to install without a ton of deps. :P | 02:40 |
| skaet | It actually does seem to work to install/uninstall - but keep getting the message saying its failed as it does the task - disconcerting. | 02:41 |
| * infinity installs Filezilla. | 02:41 | |
| infinity | skaet: Worked and gave me the Installed checkbox... | 02:42 |
| skaet | fresh update with the software center and linux fix just accepted this evening? | 02:44 |
| infinity | skaet: Can you run SC from a command line and see if it spews any terminal messages? | 02:44 |
| skaet | sure | 02:45 |
| infinity | Ahh, yes, my SC is out of date. | 02:46 |
| infinity | Let's try again. | 02:46 |
| * infinity finds all that "Possible missing firmware" spam on mkinitrd disconcerting. | 02:49 | |
| infinity | skaet: Latest version still works as advertised for me. :/ | 02:54 |
| infinity | I hate having mechanic's syndrome sometimes. | 02:55 |
| slangasek | skaet: trying to confirm here. If you downgrade to the previous version, does the problem persist for you? | 02:56 |
| skaet | infinity, slangasek bug 870446 has my screenshots. | 02:56 |
| ubot4 | Launchpad bug 870446 in software-center (Ubuntu) "installing or removing packages - seeing message saying it has failed, but it seems to succeed (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870446 | 02:56 |
| skaet | slangasek, will try. | 02:58 |
| infinity | Hrm. | 03:08 |
| infinity | Thought it might somehow relate to your testing with gnumeric, but can't reproduce with that either. | 03:08 |
| * infinity tries a fresh install on his Panda instead of his crazy desktop. | 03:09 | |
| slangasek | skaet: I don't see it here either | 03:14 |
| skaet | slangasek, I'm seeing it in on prior version of software center as well. | 03:15 |
| skaet | machine is a pure victim machine, no customizations. defaults all the way. | 03:15 |
| slangasek | hmm | 03:16 |
| slangasek | well, the error message in the screenshot is about preconfiguring packages | 03:16 |
| slangasek | which is about debconf | 03:16 |
| slangasek | what image was used for installing? | 03:16 |
| skaet | I used the beta2, and then updated every day since then. | 03:17 |
| slangasek | which beta2 image? | 03:17 |
| skaet | amd64 desktop | 03:17 |
| * slangasek nods | 03:17 | |
| skaet | its release notable, since the right action does seem to happen, but something is wrong for it to appear in the first place. | 03:19 |
| skaet | s/it/the message saying it failed/ | 03:20 |
| slangasek | well, I think it's probably somehow specific to your machine if no one else has reported it or is seeing it now. The error message definitely points to a problem specific to debconf, which makes me wonder if it's not software-center at all having the problem | 03:20 |
| slangasek | but rather something to do with debconf on the backend | 03:20 |
| infinity | Corrupt debconf DB? | 03:20 |
| slangasek | could be any number of things | 03:21 |
| infinity | skaet: If you purge gnumeric and reinstall it with apt-get, do you get anything fancy? | 03:21 |
| slangasek | skaet: could you check if 'apt-get install $pkg' gives normal... what infinity said | 03:21 |
| slangasek | btw, I think I understand the udev issue well enough now to push a workaround after all | 03:22 |
| skaet | slangasek, infinity - trying | 03:22 |
| infinity | slangasek: That sound... Promising? | 03:22 |
| slangasek | I still don't know why we're losing a worker thread, but I do know why we were winding up with /dev screwed up post-initramfs - and that's because the init-bottom script was set -e and udevadm control --exit exits non-zero if it hits a timeout waiting for udevd to die | 03:23 |
| slangasek | so if we just raise udevadm control's timeout a little on the commandline to ensure udevd *does* die first, we should get clean (if slow) boots in all these cases | 03:23 |
| slangasek | and then it's just a matter of figuring out why the heck udev is losing its mind | 03:24 |
| infinity | What happened to the pkill option? | 03:29 |
| slangasek | infinity: it turned out to be irrelevant | 03:29 |
| slangasek | udevadm control --exit is doing all the right things | 03:30 |
| infinity | Kay. | 03:30 |
| slangasek | except for the bit where udevd and udevadm control each having a 60s timeout means udevadm usually hits its timeout first, returning non-zero | 03:30 |
| infinity | But that timeout would have to be insanely high to catch every possibe problem, I assume. | 03:30 |
| slangasek | no, it just needs to be about 61s long | 03:30 |
| infinity | Ahh. | 03:30 |
| slangasek | :) | 03:30 |
| infinity | Just longer than udevd. I didn't catch that. | 03:31 |
| slangasek | which, granted, *is* insanely high, and that we're hitting it at all means something's badly messed up | 03:31 |
| infinity | Well, if udevd is hung... | 03:31 |
| infinity | Or, rather, in a patient loop waiting for something else to timeout. | 03:32 |
| slangasek | it's successfully reaped all of its children, but for some reason it still has references open to the now-dead worker thread | 03:32 |
| slangasek | so udevd appears to be waiting around for no reason at all | 03:32 |
| slangasek | big bug - but for the initramfs script itself, all we care about is that we're not hitting the timeout in the caller unnecessarily | 03:33 |
| infinity | It's not still dealing with events or something? | 03:33 |
| slangasek | *that* is what's causing /dev to fail to be mounted, and is a clear bug in the script | 03:33 |
| infinity | Does exit trigger the same codepath as stop-exec-queue before it shuts down? | 03:33 |
| slangasek | stop-exec-queue? | 03:33 |
| infinity | --stop-exec-queue | 03:34 |
| infinity | Signal udevd to stop executing new events. Incoming events will be queued. | 03:34 |
| slangasek | I don't think so... will check in a bit | 03:34 |
| infinity | How reproducible is this hitting the 60s wall business? | 03:35 |
| slangasek | with the right VM, I seem to be getting it about 50% of the time (with small sample size) | 03:35 |
| slangasek | on real hardware, I've not seen it at all | 03:35 |
| slangasek | but TREllis and lynxman have | 03:36 |
| slangasek | (and in that case, it's somehow related to a bnx2 firmware load failure) | 03:36 |
| infinity | Oh, also, rewinding a bit, you mentioned set -e terminating the script early and then life carrying on. | 03:37 |
| infinity | Didn't run-scripts used to panic when a child exited non-0? | 03:37 |
| infinity | This seems like a regression to me. :P | 03:37 |
| slangasek | I don't know | 03:37 |
| infinity | (I had the same issue debugging jasper seemingly "skipping a bunch of code" because something was broken earlier up) | 03:37 |
| infinity | I was almost sure that initramfs scrip bugs used to panic(). They sure should. | 03:38 |
| infinity | Well, I think they should. | 03:38 |
| slangasek | care to track it down in the history? | 03:38 |
| infinity | Maybe it was deemed unfriendly somehow. | 03:38 |
| infinity | Yeah, going to look and see. | 03:38 |
| skaet | slangasek, infinity - updating to the lastest flashplugin-downloader got rid of the message. I'll be closing the bug. | 03:42 |
| infinity | Oh! | 03:42 |
| infinity | It was a postinst failing over and over or something? | 03:42 |
| infinity | Wait, but fp-downloader doesn't fail. | 03:42 |
| infinity | (which is also a bug) | 03:43 |
| mdeslaur | infinity: the new one now fails properly, fyi | 03:45 |
| infinity | mdeslaur: \o/ | 03:45 |
| skaet | infinity, I'll paste you the terminal messages before and after in a PM. | 03:45 |
| infinity | slangasek: I might be misremembering the panic-on-non-zero-exit thing. Can't find a change that would have removed it. Or the changelog sucks and I need to root through history. :/ | 03:46 |
| infinity | slangasek: That still feels wrong to me, though. Skipping half a script and still booting can be pretty damaging (not to mention confusing). | 03:46 |
| infinity | mdeslaur: Hahahah. According to skaet's apt output, in some cases, it would fail anyway, thought entirely by accident. | 03:47 |
| mdeslaur | infinity: oh, can I see it? | 03:47 |
| infinity | nspluginwrapper: /usr/lib/flashplugin-installer/libflashplayer.so is not a valid NPAPI plugin | 03:47 |
| infinity | mdeslaur: (That was her previous version, upgrading made it happy) | 03:48 |
| infinity | But she was in a broken postinst loop with that. | 03:48 |
| mdeslaur | infinity: ooooh, there's a bug about people hitting that. That happens when it's missing. | 03:48 |
| infinity | Well, upgrading fixed her up. | 03:49 |
| mdeslaur | skaet, infinity: can I see the log output? | 03:49 |
| infinity | That was the only thing relevant in her recent logs. | 03:49 |
| infinity | I assume it broke earlier on an upgrade attempt, probably hidden by a GUI. | 03:49 |
| infinity | Or something. :/ | 03:49 |
| mdeslaur | we definitely need to create a few deliberately broken packages to test all the gui tools failures before LTS | 03:50 |
| infinity | Yeah, I'm not really happy with how the GUI tools deal with failure. | 03:50 |
| infinity | Failure happens. Especially in third-party repos and PPAs (but even in our own). | 03:50 |
| infinity | And we deal with it fairly poorly. | 03:50 |
| infinity | apport will pick it up from update-manager. | 03:51 |
| infinity | No idea about SC. | 03:51 |
| infinity | I think we need a friendly GUI "rollback" option, though. | 03:52 |
| skaet | +1 on that | 03:52 |
| infinity | Cause for a non-technical-non-bugfiling-non-googling-for-answers user, it's sort of the end of the world to just have your packaging system broken "forever" by a broken package. | 03:52 |
| * skaet is visualizing her mom, about now. | 03:53 | |
| infinity | And I'm not even talking some fancy LVM snapshotting thing (a la Windows rollback), I just mean some clever heuristics to try to purge a system of an obviously unconfigurable package. | 03:53 |
| infinity | "Installing foo failed, would you like to try purging it with fire, or would you prefer to never install another piece of software again without confusing errors?" | 03:54 |
| slangasek | infinity: no, fp-downloader doesn't fail, but fp-installer which depends on it *does* | 03:57 |
| infinity | slangasek: Oh, quite right, I didn't look at the package name, just the failure. | 03:58 |
| infinity | It's all the same to me. flash.* | 03:59 |
| slangasek | yet another reason the failure should be made fatal at the source | 03:59 |
| slangasek | hmm, this is the exact same conversation as the initramfs one | 03:59 |
| infinity | Sort of, yes. | 03:59 |
| infinity | Now my head hurts. | 04:00 |
| slangasek | infinity: as far as stop-exec-queue is concerned, --exit also causes incoming events to no longer be queued | 04:22 |
| slangasek | (but otherwise has the same effect, that events in the queue are no longer processed) | 04:22 |
| infinity | Mmkay. | 04:40 |
| * slangasek works on figuring out what the event stuck in udev's gullet is | 04:52 | |
| * skaet wishes slangasek luck, and figures she better call it a night. | 05:00 | |
| slangasek | skaet: 'night - have a good flight! | 05:00 |
| skaet | thanks! | 05:02 |
| * infinity might call it a day too. | 05:02 | |
| infinity | skaet: 'Night. | 05:02 |
| * slangasek waves to infinity | 05:02 | |
| skaet | infinity, have a good flight, see you in london! | 05:03 |
| skaet | slangasek, decision baton passes to you now. Have fun. :) | 05:04 |
| * slangasek twirls it on his ear | 05:04 | |
| skaet | lol | 05:05 |
| slangasek | pitti, cjwatson, infinity: udev uploaded to the oneiric queue; I've tested this build 20x now on the VM where I previously got the timeout 50% of the time, boots cleanly each time (no delays, no initramfs panics, no read-only rootfs). I've also installed it on a pair of test laptops and done a couple reboots each, no problems seen there either. So I think this is good to go in today. | 08:18 |
| pitti | slangasek: yay | 08:21 |
| pitti | infinity: ah, did you accpet the libimobiledevice SRU? | 08:26 |
| * pitti sends the call for testing to the bug | 08:26 | |
| pitti | infinity: (no harm done, I just thought we'd wait with proposed stuff until Monday) | 08:26 |
| slangasek | pitti: what's the right place to upstream this udev patch? | 08:35 |
| pitti | slangasek: mailing linux-hotplug@vger.kernel.org (you don't need to be subscribed, I think) | 08:35 |
| slangasek | pitti: ok, thanks | 08:36 |
| pitti | will review from queue once it's diffified | 08:36 |
| pitti | i386 kernel working fine, testing amd64 now | 08:36 |
| * slangasek tries to remember how to get git to send a patch by email instead of sending embarrassment | 08:36 | |
| pitti | slangasek: git format-patch origin | 08:38 |
| slangasek | that's the easy part | 08:38 |
| pitti | this will produce a 0001-blabla.patch, which you just attach to a mail | 08:38 |
| slangasek | well, ok, if that's the local convention, that's easy enough :) | 08:38 |
| pitti | slangasek: I've never tried sending it directly from git | 08:39 |
| pitti | that seems to work everywhere (attach .patch to bugzilla or to mail) | 08:39 |
| pitti | amd64 kernel also works; copying oneiric-proposed to oneiric | 08:39 |
| pitti | ogasawara: ^ FYI | 08:40 |
| slangasek | pitti: oh, they're already copied to oneiric | 08:40 |
| pitti | oh, ok | 08:40 |
| slangasek | I haven't deleted from -proposed yet though | 08:40 |
| pitti | yesterday I earned the job to test them and copy them, but so much the better | 08:41 |
| pitti | anyway, I can start the weekend without worrying about these kernels now :) | 08:41 |
| pitti | http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html looks as good as we can get it, I htink | 08:41 |
| pitti | and http://people.canonical.com/~ubuntu-archive/testing/oneiric_outdate.html clean as well -- SHIP IT! | 08:42 |
| pitti | http://china-images.ubuntu.com/oneiric/daily-live/20111008/ -- yippie! not oversized any more | 08:42 |
| * pitti loves when things all come together | 08:42 | |
| pitti | I'll accept firefox into -proposed, the earlier, the better | 08:45 |
| pitti | slangasek: oneiric-proposed kernel cleaned up | 08:48 |
| pitti | slangasek: great work on udev! that must have kept you up all night! | 08:52 |
| slangasek | pitti: well, I'm still trying to get to bed before dawn ;) | 08:52 |
| cjwatson | Oh botheration. | 09:32 |
| cjwatson | Around beta 1, I went to the effort to get an account on a system to test a fix for bug 774089, and I completely forgot to upload it | 09:34 |
| ubot4 | Launchpad bug 774089 in parted (Ubuntu) (and 6 other projects) "Booting fails 3 times, works every fourth time after new install of Natty Narwhal amd64 on Macbook Pro (affects: 22) (heat: 135)" [Critical,Triaged] https://launchpad.net/bugs/774089 | 09:34 |
| cjwatson | However the last few comments on that bug suggest that things are now working due to kernel changes | 09:34 |
| cjwatson | So maybe I should leave it alone ... | 09:34 |
| infinity | pitti: Wasn't I, I wasn't home. | 09:42 |
| pitti | lamont: temporarily made allspice and crested help out with the lucid/natty langpack builds (i386) | 09:56 |
| cjwatson | ^- hopefully final d-i of the cycle to pick up new linux and netcfg | 09:58 |
| pitti | have a nice weekend everyone! | 10:21 |
| pitti | I'll accept base-files/apport/kerneloops tomorrow morning, and kick off a full set of images tomorrow evening | 10:21 |
| infinity | pitti: I thought we were doing that Sunday? | 12:29 |
| infinity | pitti: Oh, I guess "tomorrow" is Sunday for you. | 12:35 |
| infinity | pitti: Don't mind me, it's still "Friday" for me, despite it being 6am. :P | 12:35 |
| cjwatson | infinity: don't worry, we'll have you on the one true timezone next week | 13:30 |
| infinity | cjwatson: I'm always happier in that timezone anyway. | 13:30 |
| infinity | I should probably just accept that it's where I belong and move. | 13:30 |
| cjwatson | joiiiiiiiin uuussssss | 13:34 |
| Daviey | Hmm, can i protest this? | 13:41 |
| infinity | Nope. | 13:42 |
| lamont | infinity: if you move to europe, you'll just wind up running on an apac TZ instead. | 13:42 |
| infinity | lamont: Pessimist. | 13:43 |
| nigelb | I thought infinity was immune to time-zones. | 13:43 |
| lamont | dude. I remember australia | 13:43 |
| infinity | lamont: I never slept at all in Australia. | 13:43 |
| mdeslaur | since we no longer have a timezone database, I think the point will be moot soon anyway | 13:43 |
| infinity | (which seems to be happening this week too...) | 13:44 |
| lamont | mdeslaur: where did we put the database>? | 13:44 |
| lamont | remember. sleep is important. always remember where you put it. | 13:44 |
| Daviey | probably fallen behind the fridge. | 13:44 |
| infinity | lamont: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html | 13:45 |
| * lamont afk | 13:47 | |
| ogra_ | hmm, there is an issue with the qatracker, for ac100 it points to an img.gz file, we dont build img.gz for ac100, only tar.gz and .bootimg | 14:03 |
| stgraber | ogra_: can you give me the path of a valid one and the invalid path? I'll go update the tracker | 15:02 |
| infinity | stgraber: Valid path is two files, can the tracker do that? | 15:06 |
| infinity | stgraber: http://cdimage.ubuntu.com/daily-preinstalled/20111007/oneiric-preinstalled-desktop-armel+ac100.tar.gz | 15:06 |
| infinity | stgraber: http://cdimage.ubuntu.com/daily-preinstalled/20111007/oneiric-preinstalled-desktop-armel+ac100.bootimg | 15:06 |
| infinity | stgraber: Those two files. | 15:07 |
| stgraber | ok, I'll have a look soonish | 15:07 |
| infinity | stgraber: If it can only deal with one, make it the tar.gz | 15:07 |
| stgraber | ok, it can only have one, so I'll make it point to the .tar.gz | 15:08 |
| infinity | Kay. | 15:08 |
| stgraber | infinity, ogra_: did that do the trick? | 15:12 |
| infinity | stgraber: Looks better. Why do only some images have hashes? | 15:14 |
| infinity | (I'm using http://iso.qa.ubuntu.com/qatracker/dllist) | 15:14 |
| infinity | doko_: Maybe I'm missing something here, but how does editing a manpage fix symbol alignment issues? | 15:17 |
| infinity | doko_: http://launchpadlibrarian.net/82305059/binutils_2.21.53.20110810-0ubuntu3_2.21.53.20110810-0ubuntu4.diff.gz | 15:17 |
| stgraber | infinity: because of some weird and buggy magic that's hardcoded in the php code ;) | 15:19 |
| stgraber | infinity: I'm working on rewritting all that | 15:19 |
| === erichammond1 is now known as erichammond | ||
| === erichammond1 is now known as erichammond | ||
| === erichammond1 is now known as erichammond | ||
| ogra_ | stgraber, thanks looks good | 15:53 |
| ScottK | Looks like it'd be good to update python-defaults. There's a dh_python2 bug that will cause some packages to misbuild. It doesn't affect anything currently in the archive, but it'd be great to avoid trouble with backports. | 15:58 |
| ScottK | Uploaded. | 16:29 |
| ScottK | Most of the diff is tests. | 16:29 |
| dylan-m | Hi there! So, I have one change for the Ubuntu install slideshow (a new picture + updated translations), and I'm wondering if there's any way to get that in the final ISO without causing trouble. Just a little thing, so no problem if there isn't a way. (Though it _would_ be awesome!) | 16:55 |
| * dylan-m hides away sheepishly | 16:55 | |
| infinity | dylan-m: Upload it and I'll look at the diff. If it looks obviously safe, sure. | 17:02 |
| dylan-m | infinity: Great, thanks! Searching my memory, (since this is a package that's only there for the installer) I guess it'll happen in the odd chance the image is rebuilt, and otherwise not. Is that correct? | 17:04 |
| infinity | Correct, but the images are being rebuilt. | 17:06 |
| ScottK | Thanks. | 17:06 |
| ScottK | (for whoever accepted python-defaults) | 17:07 |
| infinity | ScottK: Was me. | 17:08 |
| infinity | ScottK: That probably could have been an SRU, but whatever. | 17:08 |
| ScottK | Could have, but it seems better not to have to mess with stuff like that after release. | 17:09 |
| * lamont has stabbed rossm and thrown it back into the pool | 17:34 | |
| * infinity is amused by update-manager-0.152.23/AutoUpgradeTester/profile/eduubuntu/DistUpgrade.cfg (note the typo) and wonders if that's referenced that way elsewhere in the code, or if it doesn't actually work. | 17:40 | |
| infinity | And, of course, mvo isn't online to ask him about it. :P | 17:40 |
| jibel | infinity, it actually doesn't work http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ | 17:43 |
| jibel | IOError: Can't find profile '/home/mvo/update-manager/main/AutoUpgradeTester/profile/edubuntu/DistUpgrade.cfg' (/home/mvo/update-manager/main/AutoUpgradeTester) | 17:43 |
| infinity | jibel: Special. Rejecting, then. | 17:43 |
| infinity | Maybe that'll make him show up on IRC to talk. ;) | 17:43 |
| slangasek | mdeslaur: pff, that merely means we no longer have an *upstream* for the timezone database :) | 17:57 |
| mdeslaur | slangasek: but, I've already convinced my wife to switch all our clocks to UTC! | 18:23 |
| slangasek | haha | 18:40 |
| slangasek | pitti: hmm, my mail to linux-hotplug@vger.kernel.org doesn't seem to have reached the mail archive yet | 19:01 |
| * slangasek chuckles at his outbound mail logs. Well, it was accepted... 250 2.7.1 Looks like Linux source DIFF email. | 19:02 | |
| GrueMaster | ScottK: Just an FYI - kubuntu on omap4, no visible issues on install or login. I don't have time to go through and do a full app sweep, but it looks a lot better than releases past. | 19:05 |
| ScottK | GrueMaster: Great news. Thanks. | 19:05 |
| GrueMaster | Two more platforms and arm is done. | 19:09 |
| slangasek | ScottK: can you comment on how the kubuntu ISO's boot sequence is put together? I have bug #870832 reported on kubuntu specifically; wonder if there's a difference here in the display manager handling that causes a race not seen elsewhere | 19:09 |
| ubot4 | Launchpad bug 870832 in plymouth (Ubuntu) "Plymouth not shown during live disk shutdown. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870832 | 19:09 |
| slangasek | OTOH, broder was commenting on something like this earlier... | 19:09 |
| * ScottK looks | 19:09 | |
| ScottK | slangasek: I have seen that happen a few times. | 19:10 |
| stgraber | slangasek: Got an e-mail from mvo. The fix for edubuntu upgrade will be a new update-manager upload to Oneiric (so that it gets into the .tar.gz for natty). | 19:10 |
| stgraber | slangasek: the fix is just a one line change in the code adding edubuntu-desktop to the list of package to ensure are always upgraded | 19:10 |
| stgraber | oh, just read backog ;) | 19:11 |
| stgraber | apparently it already went through | 19:11 |
| ScottK | I never saw it consistently, but I don't know of anything Kubuntu specific that would cause it. The kdm upstart job is as close a copy to what's in gdm as I could manage. | 19:11 |
| ScottK | I've NFK what causes it as it wasn't consistent. | 19:11 |
| stgraber | infinity: did you see anything else wrong in mvo's upload? | 19:13 |
| stgraber | infinity: if not, I'll just re-upload with that fixed | 19:13 |
| slangasek | ScottK: understood. I'll boot up a VM here and see what I can figure out; I don't expect we'll try to fix it for oneiric, but at least we can have it triaged | 19:15 |
| slangasek | stgraber: ah, already in then, good :) | 19:15 |
| stgraber | slangasek: well, got rejected by infinity ;) | 19:16 |
| slangasek | ah right | 19:16 |
| infinity | stgraber: Nothing else obviously wrong. | 19:22 |
| stgraber | infinity: ok, expect it in the queue soonish then :) | 19:24 |
| stgraber | trying to figure out how to build the source package of update-manager... having some problem getting the pre-build stuff to pass... | 19:36 |
| infinity | Lacking build-deps, I assume? | 19:36 |
| stgraber | I'm running in a clean LXC container with all the build-deps installed ;) | 19:37 |
| slangasek | it's not the build-deps | 19:38 |
| slangasek | it's the how-to-generate-the-source deps | 19:38 |
| slangasek | for which we have no good way to provide a manifest, unfortunately | 19:39 |
| slangasek | (and no, I don't know what's in that list in the update-manager case... I just know this problem affects everything mvo maintains :) | 19:39 |
| stgraber | I have an extra 30 minutes I can spend on that before going to the airport, if I can't get it to work, I'll text mvo asking for him to grab the branch and upload ;) | 19:42 |
| stgraber | oh, I think I got it | 19:43 |
| ScottK | slangasek: Sounds almost manoj like. | 19:43 |
| slangasek | heh | 19:43 |
| stgraber | it seems to be a case where "bzr bd -S" doesn't do the same thing as "debuild -S -sa" with the former working ;) | 19:43 |
| slangasek | oh, well, yes, that's the generate-the-source-package hook part... debuild -S assumes you already have a full source package tree, which you don't | 19:44 |
| slangasek | generated bits :) | 19:44 |
| Daviey | bug 865701 , might want added to the release notes? | 19:48 |
| ubot4 | Launchpad bug 865701 in unity (Ubuntu) "Maximized windows can be accidentally closed from wrong monitor. (affects: 3) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/865701 | 19:48 |
| stgraber | ok, I "think" I got it to work ;) debdiff between mvo's upload and mine looks good at least. Should be in the queue soonish | 19:49 |
| slangasek | Daviey: please open a task on the ubuntu-release-notes project for this | 19:50 |
| slangasek | I'm not sure that's release-notable though because it's difficult to explain in a way that will make sense to users... I think it's more important to get the DX team to fix it ASAP in SRU | 19:50 |
| Daviey | slangasek: yeah, i wasn't certain. | 19:51 |
| slangasek | Daviey: well, it's easy enough to open a task on u-r-n, and we can always close 'invalid' afterwards :) | 19:51 |
| Daviey | ack | 19:52 |
| infinity | stgraber: Accepted. | 20:05 |
| stgraber | infinity: thanks! | 20:11 |
| slangasek | ScottK: when you've seen bug #870832, do you know if it's always been after choosing the *install* option (i.e., never after "Try $OS")? | 20:15 |
| ubot4 | Launchpad bug 870832 in plymouth (Ubuntu) "Plymouth not shown during live disk shutdown. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870832 | 20:15 |
| charlie-tca | smoketested Xubuntu images; they do install and they did not crash on my hardware | 20:16 |
| stgraber | that's usually a good start | 20:17 |
| slangasek | heh, aren't those the alpha milestone criteria? :-P | 20:19 |
| slangasek | hopefully it does more than that ;) | 20:20 |
| ScottK | slangasek: I don't. | 20:21 |
| slangasek | ScottK: ok. my current hypothesis is that this relates to the fact that kdm (or lightdm) is never fully running when you choose "install", so the confusing sequence of shutdown events somehow causes plymouth to be started while an X server is still running; but this is so far only a hypothesis | 20:23 |
| slangasek | if that's what's happening, it's probably a bug in ubiquity | 20:23 |
| ScottK | OK. So if it happens from a full live session then that blows your theory, right? | 20:24 |
| charlie-tca | new images spinning tomorrow, you want all the tests done in detail today and tomorrow? | 20:24 |
| ScottK | (even if an install was done from that session) | 20:24 |
| slangasek | ScottK: yes | 20:24 |
| ScottK | OK. I'll keep an eye out for it if I get time for ISO testing this week (bad week for a release $WORK wise for me). | 20:24 |
| slangasek | charlie-tca: I'm not asking for any extra testing of the current images per se, just being drily amused on a Saturday afternoon :) | 20:25 |
| cjwatson | slangasek: hm, doesn't plymouth start on stopped ubiquity-dm or some such as well on shutdown? | 20:41 |
| cjwatson | (if not there may be a reason mind ...) | 20:42 |
| infinity | cjwatson: It starts on desktop-shutdown | 20:43 |
| infinity | cjwatson: Does ubiquity-dm emit that? | 20:43 |
| cjwatson | it may not; that's new IIRC | 20:43 |
| infinity | It is. | 20:43 |
| cjwatson | can't check right now | 20:43 |
| infinity | You can blame vorlon for missing one DM. :P | 20:43 |
| cjwatson | it would have to be careful about it, as there are situations where you can transition from ubiquity-dm to a real dm | 20:44 |
| ScottK | Can't blame vorlon for any Ubuntu problems. | 20:44 |
| infinity | cjwatson: Indeed. | 20:44 |
| infinity | cjwatson: And no, it doesn't emit any such thing. But yeah, it would have to be careful about that case. | 20:45 |
| * cjwatson would look if he weren't supervising a madly bouncing toddler | 20:48 | |
| * infinity goes to get ready to catch his flight to the land of promised timezone parity. | 20:48 | |
| infinity | cjwatson: Velcro walls, velcro clothes, done. | 20:49 |
| cjwatson | It might be worth a shot. | 20:49 |
| cjwatson | Safe travels | 20:50 |
| infinity | cjwatson: Is there a runlevel switch when ubiquit-dm transitions to lightdm? | 20:51 |
| cjwatson | No | 20:51 |
| infinity | Then this, stolen from the lightdm init should work: | 20:52 |
| infinity | post-stop script | 20:52 |
| infinity | if [ "$UPSTART_STOP_EVENTS" = runlevel ]; then | 20:52 |
| infinity | initctl emit desktop-shutdown | 20:52 |
| infinity | fi | 20:52 |
| infinity | end script | 20:52 |
| cjwatson | hm, ok, that makes sense | 20:52 |
| slangasek | infinity, cjwatson: I didn't miss it, I only converted the DMs that were already listed as causing plymouth to start to use the new event | 21:09 |
| slangasek | cjwatson: but if it were just "ubiquity-dm doesn't emit it", then plymouth wouldn't start *at all* on shutdown; whereas the observed behavior is that plymouth starts up and something takes the console into text mode underneath it | 21:10 |
| charlie-tca | slangasek: yeah, I stepped out to bang my head on the wall a couple of times. humor is back now | 21:10 |
| slangasek | charlie-tca: :) | 21:11 |
| slangasek | and since ubiquity-dm is also 'stop on ... stopping kdm', ubiquity-dm with its X session should be stopped *first*, before kdm's post-stop script triggers the event | 21:13 |
| cjwatson | it's start on starting kdm too; maybe kdm is starting up afterwards, briefly? | 21:17 |
| cjwatson | not to the point of starting the dm, but it might hit the job ... | 21:18 |
| cjwatson | hm, no, this is incoherent | 21:18 |
| slangasek | well, I also haven't ruled out there being an upstart bug involved | 21:20 |
| slangasek | anyway, this is all weekend tinkering, not something I think we should try to fix for release | 21:20 |
| ScottK | python-pypm in queue will fix package installability. It's a quick build, so not a bad one to keep in queue for stimulating the publisher. | 21:38 |
| * ScottK larts tumbleweed for not syncing it after he fixed it in Debian. | 21:38 | |
| tumbleweed | oops | 21:54 |
| tumbleweed | btw, I see people complaining about my devscripts change. Was that not how we normally handled things (I thnaven't checked yet) bug 870618 | 21:55 |
| ubot4 | Launchpad bug 870618 in devscripts (Ubuntu) "debchange: "precise" is the default distribution in oneiric (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/870618 | 21:55 |
| ScottK | Usually the default distro is changed after release, but I think it's fine. | 21:55 |
| ScottK | Saves me having to change it myself. | 21:56 |
| Laney | indeed, I'd wontfix that report. It's not as if we'll be seeing many uploads from now to release. | 22:02 |
| tumbleweed | I get the feeling the reporter is expecting dhc on oneiric to default to oneiric | 22:02 |
| tumbleweed | I only run development Ubuntu's so I'm not used to knowing if that's the usual behavior | 22:03 |
| stgraber | I guess one could argue that most of our users are more likely to upload to a PPA than to the archive, having the current release set by dch would then make more sense | 22:20 |
| slangasek | tumbleweed: historically we have not changed the dch target before release, no | 22:24 |
| slangasek | it doesn't really matter either way; 'oneiric' will be a wrong target within 5 days, and 'precise' will be wrong for over half the support lifetime of oneiric | 22:25 |
| slangasek | ... though I guess this has a negative impact on ppa usage | 22:26 |
| slangasek | tumbleweed: ^^ on that basis, I think it actually would be better to revert this... and for precise perhaps we should plan to come up with a way to pull a default target from the user environment instead of from the commandline? | 22:27 |
| tumbleweed | slangasek: yeah, the PPA usage arguement is sound | 22:28 |
| slangasek | devscripts seems to be on kubuntu DVD and on server | 22:29 |
| slangasek | tumbleweed: if you intend to upload to revert this, please do so today to get it on the ISOs, or else send it to -proposed | 22:29 |
| tumbleweed | I'll need a sponsored upload (not a core dev, but happy to prepare that now) | 22:30 |
| stgraber | tumbleweed: I'm happy to sponsor if you have it ready in the next 20 minutes | 22:30 |
| stgraber | (waiting for my flight) | 22:30 |
| tumbleweed | stgraber: thanks: http://paste.debian.net/135105/ | 22:34 |
| tumbleweed | eep, forgot to close thebug, anyway... | 22:37 |
| stgraber | tumbleweed: I'll update the changelog | 22:38 |
| stgraber | tumbleweed: uploaded | 22:40 |
| tumbleweed | stgraber: ta | 22:42 |
| * ScottK considers "makes PPA uploads to the current release harder" a feature, not a bug, but whatever. | 22:48 | |
| slangasek | whyso? | 22:49 |
| ScottK | I think people who don't know what they are doing slamming crap into PPAs is a source of trouble. | 22:49 |
| ScottK | I'm personally sick and tired of hunting down bugs that turn out to be due to bad PPA uploads. | 22:50 |
| ScottK | Not that it happens a lot, but it's frequent enough on just the few packages I really triage on that I think it's a large problem. | 22:50 |
| stgraber | well, if they upload to the dev release, they'll then most likely re-upload once they understand what they did wrong | 22:50 |
| * tumbleweed hears a lot of flak from good developers who find ppas hard to use | 22:50 | |
| stgraber | and so will use twice the builder time | 22:50 |
| ScottK | That and I think that PPAs have been generally harmful for developer recruitment (it's in a PPA, so why should I bother <-- heard that more than once) | 22:51 |
| ScottK | Reviewing the diff anyway. | 22:52 |
| tumbleweed | but yes, I also see lots of people braeking their installs (esp at upgrades) by using hundreds of dodgy PPAs | 22:52 |
| ScottK | Accepted. | 22:52 |
| ScottK | So while I find PPAs to be a very valuable development tool, I think that there is a lot of negatives that go with it. | 22:53 |
| ScottK | On balance, I'm not convinced we're better off. | 22:53 |
| stgraber | I heard quite a few people saying that having some kind of "official" PPAs for some specific projects or team and showing a big scary warning when adding any other PPA could help with that | 22:54 |
| stgraber | though it doesn't help solve the "it's in a PPA, so why should I bother" part | 22:54 |
| ScottK | "Official" PPAs are a slippery slope that IMO we shouldn't start down. | 22:56 |
| stgraber | I can see why a project (as in upstream project) would like that though. I certainly agree that we don't want to have "official" Ubuntu PPAs as we already have way enough different ways of getting something to our users | 22:57 |
| mdeslaur | ScottK: I probably shouldn't say this, but I keep stuff I wrote in a PPA, because I only see disadvantages in getting it into the archive | 22:57 |
| ScottK | mdeslaur: I believe you. | 22:58 |
| mdeslaur | and I do agree that people pulling random stuff out of PPAs is annoying also, especially when it conflicts with stuff that _is_ in the archive | 22:59 |
| slangasek | yeah, I've recently seen an awful lot of non-Ubuntu "lib32fooN" packages on people's systems conflicting with ia32-libs... I suspect ppas are to blame | 23:01 |
| slangasek | apport should probably be made smarter and refuse to file bugs in those cases | 23:01 |
| * slangasek turns that "should" into a bug report | 23:02 | |
| tumbleweed | otoh, if people want to break their systems, I'd rather they did it with a ppa than building the world from source | 23:02 |
| mdeslaur | tumbleweed: true | 23:03 |
| slangasek | bug #871030 filed | 23:05 |
| ubot4 | Launchpad bug 871030 in apport (Ubuntu) "apport should disallow filing bugs for package install failures when they conflict with non-Ubuntu packages (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/871030 | 23:05 |
| mdeslaur | I wish there was a bigger difference between patform and applications | 23:05 |
| mdeslaur | but that's a whole other discussion :) | 23:06 |
| ScottK | Having been stuck doing work on an OS recently where that's the case (BSD, forget which one), that has it's own set of problems. I'm convinced now it's different, not better. | 23:22 |
| mdeslaur | ScottK: this is a UDS-beer discussion :) | 23:23 |
| ScottK | Sure thing. | 23:25 |
| ScottK | Sorry I won't be able to make it this time. | 23:25 |
| mdeslaur | ScottK: what? you won't be at UDS? Seriously? | 23:26 |
| ScottK | Seriously. | 23:26 |
| mdeslaur | ScottK: if you're not there, we should cancel it. | 23:26 |
| mdeslaur | ok, enough off-topic rambling from me in here | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!