| jbicha | bdrung: I don't think we need to have a trash icon by default in gnome-panel | 00:57 |
|---|---|---|
| bdrung | jbicha: two reasons for it: we had it previously and we have one in unity | 01:14 |
| jbicha | bdrung: and two reasons against it: upstream doesn't do it, and who needs trash on the desktop? | 01:18 |
| jbicha | there's a half dozen folders I might be interested in having quick access to, but I almost completely ignore the trash folder | 01:20 |
| jbicha | gjs will require a mini-transition for fixing the gir1.2-gjs-1.0 to gir1.2-gjsdbus-1.0 package name but gnome-shell is the only rdepends | 01:22 |
| jbicha | bdrung: we also had the Firefox launcher, but I'm not planning to add that to gnome-panel by default either | 01:23 |
| ScottK | jbicha: What packages? Just gjs and gnome-shell? | 01:46 |
| jbicha | ScottK: yes, gnome-shell is the only rdepends for the gjs gir package | 01:47 |
| ScottK | jbicha: OK and does gnome-shell have it's build-dep versioning such that I can just accept them both and not worry about archive skew? | 01:47 |
| ScottK | bdrung: I'm rejecting gnome-panel since it seems there's some controversy about it. Please go to the ubuntu-desktop list, get some consensus, and then upload again if needed. | 01:49 |
| jbicha | ScottK: in my test build, the gjs dependency worked out ok, it's a run time depends so it was added explicitly but without an explicit version | 02:01 |
| ScottK | OK. | 02:02 |
| micahg | jbicha: that's because Debian dropped the symbols file IIRC (don't remember if we took the change as well) | 02:02 |
| micahg | jbicha: oh, nevermind me :) | 02:02 |
| deej | infinity: Did you have a chance to poke kapok this afternoon? | 02:18 |
| infinity | deej: Oh crap, not yet. Can do so right now. | 02:18 |
| infinity | deej: Though, I'm assuming some cron jobs have run by now. | 02:19 |
| deej | infinity: I'm assuming you're right :) | 02:20 |
| infinity | deej: Certainly seems like there've been a few successful builds, yeah. | 02:21 |
| deej | infinity: Cool, I'll chalk it up as fine, I'm going to do cardamom unless you have an objection | 02:22 |
| infinity | deej: No, no. Please do. :) | 02:22 |
| infinity | deej: We'll put them both through their paces a bit more heavily soon. I've just been headless chickening all day, and you fell off the stack. :/ | 02:23 |
| deej | I figured, no worries, everyone's swapping hard on the run up to release | 02:23 |
| ScottK | roaksoax: Where's the FFe for maas-provision? | 03:45 |
| ScottK | New source during final freeze. I love it. | 03:45 |
| ScottK | Happens every cycle there is some new package or major feature that some Canonical project needs to get in during final freeze. | 03:46 |
| infinity | It's universe, I assume. | 03:49 |
| infinity | We've done universe debian syncs of new packages too. | 03:49 |
| jbicha | please don't promote gnome-shell/mutter/gjs to -release yet, I'm getting this error when I try running it http://fpaste.org/ZRvq/ | 03:51 |
| ScottK | infinity: With FFe. | 03:51 |
| ScottK | infinity: I don't mind doing FFe/sync of packages people want from Debian. I don't mind if someone wants to do an FFe and some archive admin volunteers to review this one. | 03:52 |
| ScottK | New source not from Debian takes a much finer tooth comb to review. | 03:53 |
| ScottK | Given that Maas was such a priority, I guess I'd have thought they could have actually considered the release schedule. | 03:53 |
| Daviey | ScottK: I'm taking maas-provision along with jdstrand | 03:53 |
| ScottK | OK. | 03:53 |
| Daviey | ScottK: It's to satisfy MIR requirements. | 03:53 |
| ScottK | There should still be an FFe. | 03:53 |
| ScottK | OK. | 03:53 |
| Daviey | it's a rename/copy of cobbler package, that jdstrand wanted, and has already agreed to srcNEW review. | 03:54 |
| Daviey | it was requested in the cobbler MIR | 03:54 |
| ScottK | debian/changelog says "Initial maas-provision release" | 03:55 |
| ScottK | Then I'll revise my rant to "If it's just a fickin' source rename, please say so in debian/changelog." | 03:55 |
| Daviey | ScottK: it does have a debian/Debian.readme | 03:55 |
| Daviey | err, .source | 03:55 |
| ScottK | Yes, I think "renamed from ...." should make it into the changelog. | 03:56 |
| ScottK | Since that is, in fact, a change. | 03:56 |
| ScottK | I was going to reject it with a note that said "No FFe, reupload after you get an FFe", but I'll leave it for you to deal with then. | 03:57 |
| Daviey | ScottK: wait. | 03:57 |
| * ScottK isn't doing anything. | 03:57 | |
| Daviey | ScottK: it's not a 'rename' as the original package will still exist. | 03:57 |
| ScottK | So were duplicating source in the archive under a new name? | 03:58 |
| Daviey | ScottK: yes | 03:58 |
| ScottK | Please tell me that's somehow actually more brilliant than it sounds. | 03:59 |
| infinity | ... | 03:59 |
| Daviey | ScottK: Security team doesn't want default cobbler in main.. The other option is to embded cobbler into the maas package, which i have less interest in. | 03:59 |
| jbicha | what makes this cobbler any more delicious? | 04:00 |
| micahg | why can't the universe cobbler use the main part? | 04:00 |
| ScottK | micahg: My thought exactly. | 04:01 |
| micahg | see libav/libav-extra spilt | 04:01 |
| micahg | *split | 04:01 |
| Daviey | "use the main part"? | 04:01 |
| ScottK | Somehow I suspect that jdstrand wasn't actually begging to have duplicate source in the archive. | 04:01 |
| Daviey | ScottK: He was. | 04:02 |
| ScottK | Wow. | 04:02 |
| infinity | micahg: I imagine the issue is that they're trying to shove something in main that depends on bits of cobbler. | 04:02 |
| ScottK | Sounds like, but I think "then why not split just those bits out" is a reasonable question. | 04:03 |
| infinity | Indeed, and have cobbler {Build-,}Depend on them. | 04:03 |
| ScottK | I hope the answer isn't something like, "Yes, in theory, but this whole time based release thing threw us off - we needed more time." | 04:11 |
| deej | infinity: FYI, cardamom is done, I'm about to close out the ticket, if you run across anything weird, just re-open it, it's enormously prioritized so we'll have a look sooner rather than later | 04:12 |
| infinity | deej: Check, thanks. They'll get a bit of a workout overnight, but I'll abuse them tomorrow to make sure they're all good. | 04:14 |
| deej | Sounds good | 04:17 |
| Daviey | ScottK: So, with maas.. we only use a subset of cobbler features. Having duplicated source measn the security team only need to support vulnerabilities in the areas that maas uses. | 04:18 |
| Daviey | Otherwise security would block the full MIR, as it seems to be quite vulnerability prone. | 04:19 |
| ScottK | Right, but wouldn't it be possible to have cobbler use the part you want in Main so it's not duplicated? | 04:19 |
| Daviey | ScottK: do you think it's reasonable to abuse an otherwise functional package and still keep the ame name? | 04:20 |
| Daviey | people should be able to use cobbler still, no? | 04:20 |
| ScottK | Sure. | 04:20 |
| Daviey | ScottK: we use a subset of most of the binary packages. | 04:21 |
| ScottK | I see. | 04:21 |
| Daviey | ScottK: Spotted an issue with the source upload, can you reject it please? | 04:21 |
| ScottK | Sure. | 04:21 |
| Daviey | thanks! | 04:21 |
| ScottK | Done. | 04:22 |
| Daviey | ta | 04:22 |
| jbicha | ^ ok that gnome-shell works | 04:46 |
| infinity | Promise? | 04:48 |
| ScottK | It's Universe. He's got several more tries to throw it at the archive if he needs to. | 04:49 |
| jbicha | works for me | 04:49 |
| jbicha | works enough for me to go to bed | 04:49 |
| infinity | jbicha: ;) | 04:56 |
| ScottK | That was the "Universe not frozen" handwave. | 05:11 |
| infinity | cjwatson: Did you want to refresh d-i translations at the same time as uploading for armhf/omap4 issues? | 05:19 |
| infinity | cjwatson: My d-i bits are committed, at any rate, depends on mklibs being built and installed first. | 05:25 |
| pitti | yay, we have an LP langpack export; /me goes to build packages | 05:25 |
| infinity | pitti: Want to review my mklibs upload first? ;) | 05:25 |
| pitti | infinity: waiting for diff, will do then | 05:26 |
| infinity | pitti: Danke. | 05:26 |
| micahg | pitti: have fun with 4 shiny new roseapples :) | 05:27 |
| pitti | ooh! | 05:27 |
| pitti | and new amd64, too | 05:27 |
| pitti | still on manual, though | 05:27 |
| micahg | pitti: yeah, by design | 05:27 |
| infinity | pitti: The new ones aren't manual. | 05:27 |
| infinity | pitti: The old ones are. | 05:27 |
| pitti | infinity: OOI, why do we have so many armel PPA buildds? | 05:28 |
| infinity | pitti: Effed if I know, that's a world I don't pay attention to. | 05:28 |
| infinity | Since the PPAs I care about build on the distro buildds. | 05:28 |
| pitti | if anything I had expected armhf, but most PPAs have neither after all | 05:28 |
| pitti | anyway, was just curious | 05:28 |
| infinity | pitti: Well, those are "virtual" PPA builders. Which translates to "only a few special people build there". | 05:29 |
| * micahg estimates 2.5 hours for the langpacks with the 4 new buildds | 05:29 | |
| infinity | pitti: Folks with devirt PPAs build on the distro machines. | 05:29 |
| pitti | argh, mislooked, it's the export from Monday; so, more waiting | 05:29 |
| infinity | pitti: So, I dunno, I assume IS knows what they're doing with the distribution of the "special" ones. | 05:29 |
| pitti | infinity: right, hence my question why we have so many of them, I've never seen them doing anything | 05:30 |
| infinity | pitti: Maybe they do it when you're not looking? ;) | 05:30 |
| pitti | heisenbuilders? | 05:30 |
| infinity | (I honestly have no clue, I suspect it may be Spads testing his qemu madness) | 05:30 |
| pitti | lol | 05:30 |
| slangasek | you laugh, but he's serious :) | 05:31 |
| slangasek | I think that's probably what they are | 05:31 |
| infinity | ScottK: Is all the dev* stuff in proposed to be copied to release? | 05:31 |
| pitti | infinity: could I temporarily reactivate the older i386 builders for langpacks, or would that screw up anything? | 05:32 |
| infinity | pitti: Go nuts. | 05:32 |
| pitti | ok, great | 05:32 |
| infinity | pitti: It's not broken, just disabled to make sure the new ones get a workout. | 05:32 |
| pitti | export is estimated to be done at 0800 UTC | 05:32 |
| pitti | with that much buildd capacity we can have them in the archive by 1200 UTC | 05:33 |
| ScottK | infinity: No idea. | 05:33 |
| infinity | slangasek: How do you feel about mklibs? | 05:33 |
| micahg | pitti: if you just grab allspice and roseapple for i386 for the rebuild, you should be done in under 2 hours :) | 05:34 |
| infinity | ScottK: They start with a K, you end with a K, I just assumed. | 05:34 |
| micahg | err..I mean langpack build | 05:34 |
| ScottK | Oh. Looking. | 05:34 |
| * micahg really needs to go to sleep soon | 05:34 | |
| slangasek | infinity: oh man, I haven't talked to mklibs in years, it'd be great to catch up | 05:34 |
| slangasek | :P | 05:34 |
| infinity | slangasek: Here's your chance, he's in the queue, pacing! | 05:34 |
| ScottK | infinity: Yes. | 05:35 |
| pitti | infinity: uh, it's not any more | 05:35 |
| infinity | ScottK: Cheers. | 05:35 |
| infinity | pitti: *raise brow* | 05:36 |
| pitti | infinity: I mean, I accepted it, as you asked me to :) | 05:36 |
| infinity | pitti: Oh! | 05:36 |
| infinity | pitti: I was expecting challenging questions about the fine art of library reduction and WTF I was on. | 05:36 |
| infinity | pitti: But thanks! | 05:36 |
| pitti | infinity: it seemed quite consistant with the other changes (initramfs, etc.) you did thehre | 05:36 |
| infinity | pitti: If I fall asleep before mklibs is published, want to sponsor (and tag) the debian-installer release sitting in bzr for me? | 05:37 |
| pitti | at which point will we update base-files for lsb-release? | 05:37 |
| pitti | infinity: sure, no problem | 05:38 |
| infinity | pitti: Isn't there some countdown wiki that details when we do all that? | 05:38 |
| pitti | https://wiki.ubuntu.com/ReleaseProcess | 05:38 |
| pitti | it doesn't mention base-files, though | 05:38 |
| infinity | Oh. | 05:38 |
| pitti | oh, it does | 05:38 |
| infinity | pitti: Does do. | 05:39 |
| infinity | so. | 05:39 |
| pitti | Release minus 3 days: | 05:39 |
| pitti | Make sure that /etc/issue, /etc/issue.net, and /etc/lsb-release are correct | 05:39 |
| infinity | Yeahp. | 05:39 |
| infinity | I got there just when you did. :P | 05:39 |
| pitti | it's just well within the time when skaet wanted us to have actual release candidates | 05:39 |
| pitti | so if we want to do that, we'd have to do it today | 05:39 |
| pitti | as tonight she wanted to build the first RCs | 05:39 |
| infinity | I think it's pretty optimistic to believe we won't upload a single package affecting any image after now. | 05:40 |
| infinity | But sure? | 05:40 |
| * micahg will get his blueman upload in before bed then | 05:40 | |
| pitti | oh, I agree; tonight's images won't be the final ones | 05:40 |
| pitti | I thought the subtle difference was that they _could_ be | 05:40 |
| pitti | i. e. there is nothing which is knowingly missing on them, etc. | 05:41 |
| pitti | so that any further image we do is just to pick up opportunistic bug fixes | 05:41 |
| infinity | pitti: Oh, since you might end up sponsoring d-i for me, want to check the diff in bzr now and review that, so you can pre-approve your own upload? :P | 05:41 |
| pitti | r1676 is straightforward | 05:42 |
| infinity | pitti: That's already uploaded. 1677 isn't. :P | 05:42 |
| pitti | oh? | 05:42 |
| pitti | I didn't see a "released..." bzr commit | 05:42 |
| infinity | Hence why 1676 is tagged, and 1677 isn't. | 05:42 |
| pitti | ah, you don't use dch -r/debcommit -r | 05:42 |
| infinity | pitti: Follow the tags, not the commit messages. Silly man. ;) | 05:43 |
| pitti | so, I don't know what --ldlib does, but again that and the ln -s stuff seems consistent with the previous uploads | 05:43 |
| pitti | infinity: yeah, I'm a huge fan of using UNRELEASED | 05:44 |
| micahg | +1 | 05:44 |
| pitti | infinity: so, LGTM | 05:44 |
| infinity | pitti: mklibs tries to heuristically find the linker via readelf on random binaries, which on armhf finds the wrong path first (nodeterministically, no less) | 05:44 |
| infinity | pitti: Instead of trying to deal with the mystery of which one gets copied, --ldlib overrides the random search madness and just says "use that one, idiot". | 05:45 |
| * pitti nods | 05:45 | |
| infinity | I so desperately want to rewrite mklibs to not be crap. | 05:46 |
| infinity | And then make initramfs-tools depend on it. | 05:46 |
| slangasek | ^^ death to defoma | 05:46 |
| infinity | Cause they both get different things differently wrong. | 05:46 |
| infinity | slangasek: Huzzah! | 05:47 |
| micahg | even Debian's on board with death to defoma | 05:47 |
| slangasek | most of Debian has been for quite some time; it just took a while to implement ;) | 05:47 |
| micahg | can one of the distinguished AAs copy {thunderbird,enigmail}/lucid from ubuntu-security-proposed to *lucid-proposed*? | 05:51 |
| pitti | can do | 05:53 |
| infinity | Speaking of scary library reduction silliness. Before I call this linker move "done", can anyong think of anything else that does this sort of small-filesystem-creation and might be broken? | 05:53 |
| pitti | ubuntu-vm-builder? | 05:54 |
| micahg | debootstrap? | 05:54 |
| pitti | pbuildler --create | 05:54 |
| pitti | and pbuilder, too | 05:54 |
| * slangasek waits for infinity to rephrase the question :) | 05:54 | |
| infinity | None of those do reduction. | 05:54 |
| infinity | They just install packages. :P | 05:54 |
| infinity | Hrm, dracut's probably broken too, but who uses that? | 05:55 |
| micahg | pitti: is it possible to do that copy w/out retrying the failed builds? | 05:58 |
| slangasek | wow, why do we have dracut in the archive? | 05:58 |
| infinity | We do. | 05:58 |
| slangasek | ^^ why | 05:58 |
| infinity | Also, it's written in /bin/bash, but implements its own arg parsing instead of using getopts. | 05:58 |
| infinity | I wash my hands of this. | 05:58 |
| pitti | micahg: I don't think so; I can only specify with or without binaries | 05:58 |
| micahg | :( | 05:59 |
| pitti | micahg: https://launchpad.net/ubuntu/+source/thunderbird/11.0.1+build1-0ubuntu0.10.04.1 | 05:59 |
| micahg | pitti: ok, meh, the powerpc build dies after an hour, ok, I can get the build killed I guess | 06:00 |
| pitti | all building again :/ | 06:00 |
| pitti | enigmail copied, too | 06:00 |
| micahg | well, if someone needs the powerpc buildd in the next hour, I'll go find someone to kill the build | 06:00 |
| micahg | there's a second one free | 06:00 |
| * micahg has to do another upload anyways to fix armel/powerpc, but wanted to get some initial testing in | 06:01 | |
| micahg | well, I don't have to, but I probably will | 06:01 |
| infinity | Because you want a cookie? | 06:02 |
| * infinity mails micahg porting cookies. | 06:02 | |
| micahg | heh, I don't like regressions ;) | 06:04 |
| * infinity wonders what happened to the context for the debian/rules patch in http://launchpadlibrarian.net/102433012/fontconfig_2.8.0-3ubuntu8_2.8.0-3ubuntu9.diff.gz | 06:05 | |
| infinity | Oh diff, you playful scamp. | 06:05 |
| infinity | pitti: Nevermind the d-i, I'll upload it myself. ;) | 06:24 |
| pitti | ack | 06:25 |
| infinity | pitti: Okay, linux-ti-omap4 and mklibs are published to ftpmaster, uploading d-i. | 06:29 |
| pitti | will review in a bit with diff | 06:31 |
| pitti | oh, already accepted apparently | 06:31 |
| infinity | Oh? | 06:32 |
| infinity | Looks like it's in the queue to me. :P | 06:32 |
| pitti | weird, wasn't when I refreshed after queuebot's msg; anyway, there now | 06:33 |
| pitti | diff from 20101020ubuntu133 to 20101020ubuntu134 (999 bytes) | 06:41 |
| pitti | infinity: desperately wanted to stay below 1 kB? :-) | 06:41 |
| * infinity hopes those are the last fires he needs to put out this week, but knows better. | 06:41 | |
| infinity | pitti: Hey, I had to tweak the changelog to get that diff size! | 06:41 |
| pitti | http://people.canonical.com/~ubuntu-archive/component-mismatches.svg still makes me sad | 06:43 |
| * infinity points pitti to the server team./ | 06:43 | |
| pitti | infinity: I'll flush -proposed, but keep python-defaults as that has some "not me" tag in the pad^Wwiki | 06:44 |
| infinity | pitti: Yeah, I still don't see the fear of python-defaults, but whatever. ;) | 06:44 |
| * micahg figures it's too late to drop libwvstreams4.6-qt from wvstreams | 06:44 | |
| pitti | micahg: zero reverse dependencies, so technically possible; is it important to drop it? | 06:45 |
| micahg | it's the last QT3 thing in main aside from lsb | 06:46 |
| pitti | oh | 06:46 |
| infinity | But since LSB is there, we can't drop QT3 anyway. | 06:46 |
| infinity | So, meh. | 06:46 |
| micahg | yeah, but the -dev packages would drop to universe ;) | 06:46 |
| infinity | Is that a win? | 06:46 |
| micahg | doesn't encourage use? idk | 06:47 |
| infinity | We enable everything by default these days, so I don't see how it discourages use. | 06:47 |
| infinity | And anyone who knows how support works knows that we actually support by source package. Cause we kinda have to. | 06:47 |
| slangasek | pitti: what's your opinion on doing SRUs for multiarch library enablements? | 06:47 |
| pitti | slangasek: at this point I don't fear simple .so multiarchification any more | 06:48 |
| infinity | slangasek: It would probably require some more strict testing than the average SRU... | 06:48 |
| infinity | slangasek: (All the rdeps, etc) | 06:48 |
| pitti | I'm more wary of the special cases like per-arch plugin paths etc, as they are prone to unintended side effects and errors | 06:48 |
| slangasek | I don't fear it, but I'm not sure it meets our SRU policy :) | 06:48 |
| pitti | no, technically it doesn't | 06:48 |
| pitti | except if these could be considered "safe and simple changes" | 06:49 |
| micahg | we could theoretically use -backports since that'll require rdep testing anyways if SRU is out | 06:49 |
| pitti | traditionally we've been more permissive on LTSes, so you can certainly find plenty of examples that don't match the letter of the policy | 06:49 |
| pitti | but if we change a few libraries which actually cause pain to people, I think that would be okay | 06:50 |
| pitti | slangasek: do you have a particular example in mind? | 06:50 |
| infinity | Yeah, half the SRUs in an LTS.1 don't meet the policy, cause we try to "polish" the thing we have to support for 5 years. | 06:50 |
| slangasek | pitti: orbit2, libart-lgpl, libbonobo, libbonoboui, and gnome-vfs | 06:50 |
| pitti | oh, the old gnome 2 stack | 06:50 |
| slangasek | yep | 06:51 |
| micahg | yuck, why? | 06:51 |
| slangasek | because software still uses them :) | 06:51 |
| micahg | yes, but anything that needs multiarch installability? | 06:52 |
| pitti | they don't have too many application rdepends, so that should be bearable IMHO | 06:52 |
| pitti | slangasek: gnome-vfs might again be more tricky, though, due to modules | 06:52 |
| slangasek | micahg: they're still in main, and there's binary-only software that wants them; so yes | 06:53 |
| micahg | hmm, I guess there wasn't time to kill them properly | 06:55 |
| pitti | there, new langpack tarball for real now | 07:26 |
| stgraber | good morning | 07:43 |
| pitti | hey stgraber | 07:43 |
| micahg | well, so much for a blueman upload before bed, CDBS has outsmarted me at this hour | 07:45 |
| pitti | what are you trying to do? | 07:46 |
| micahg | pitti: can we discuss in -desktop or -motu? | 07:46 |
| pitti | sure | 07:47 |
| pitti | ^ I'll reupload with an additional single-digit bug fix | 08:05 |
| pitti | ^ apport reuploaded with that bug fix, and now sent to -proposed | 08:12 |
| pitti | so it can be accepted now, and we just defer the move to release; I updated https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus accordingly | 08:12 |
| infinity | pitti: Looks good. | 08:16 |
| pitti | and that won't ruin the nice tie that I have with seb128 in the bug stats :) | 08:17 |
| infinity | He'll get more in. | 08:18 |
| infinity | Just wait. | 08:18 |
| pitti | nah, all to -proposed now | 08:18 |
| pitti | which bdmurray's scripts don't seem to count | 08:18 |
| infinity | I suppose I don't even register on this statistic. | 08:18 |
| pitti | adconrad@ubuntu.com has 11 fixes | 08:19 |
| pitti | everyone does | 08:19 |
| infinity | 11. Yeah. Close enough to not registering. | 08:20 |
| infinity | I need to start filing bugs for every upload I do, to make myself look better. :P | 08:20 |
| micahg | pitti: do you want blueman in -proposed for extended testing? | 08:23 |
| micahg | it's on 2 ISOs | 08:23 |
| pitti | micahg: at least for keeping build skew/failures away, yes | 08:23 |
| micahg | it's a quick build :) | 08:23 |
| pitti | we don't actually test the bits in -proposed | 08:23 |
| pitti | as soon as they are built and published, we copy them over, unless the pad says not to | 08:24 |
| pitti | s/pad/wiki/ | 08:24 |
| micahg | pitti: right, I'm asking if you want extended testing :), I can ask the xubuntu/lubuntu folk to help | 08:24 |
| pitti | they can be tested on a live system, of course (by downloading them manually) | 08:24 |
| stgraber | right, finished catching up on IRC backlog and e-mails post-vacation, now to find some bugs to kill ;) | 08:24 |
| pitti | micahg: can never hurt, but I thought it's just dropping one file? | 08:24 |
| micahg | pitti: it's dropping a few files, yeah, I just don't know if any other components depend on them | 08:25 |
| micahg | I picked a couple of simple fixes from Debian as well (control file only) | 08:26 |
| micahg | stgraber: why is queuebot not picking up the lubuntu packageset? (see blueman above) | 08:40 |
| stgraber | micahg: hmm, not sure, will have a look | 08:41 |
| micahg | stgraber: thanks, one of the reasons I had it created was to help with this stuff :) | 08:43 |
| pitti | infinity: so even roseapple now counts as "old" now? | 08:48 |
| infinity | pitti: Only in the sense that it existed before elmo gave us new ones. | 08:49 |
| infinity | pitti: I think we get to keep it. | 08:49 |
| infinity | pitti: Like I said, I just had all the old ones on manual to make sure the new ones got a fair test. | 08:49 |
| stgraber | micahg: well, queuebot does the right thing ... LP seems to lie though | 08:49 |
| pitti | infinity: understood, thanks | 08:49 |
| * infinity pokes the build history for all the new ones. | 08:49 | |
| micahg | stgraber: http://paste.ubuntu.com/935149/, LP seems to be right :) | 08:50 |
| micahg | Task: xubuntu-desktop, lubuntu-desktop | 08:50 |
| infinity | Poor lamiak hasn't seen a build yet. All the rest seem fine. | 08:50 |
| pitti | langpack import is at zh_TW | 08:50 |
| micahg | infinity: wait until the langpack builds start ;) | 08:50 |
| pitti | it'll get plenty of exercise RSN | 08:51 |
| stgraber | >>> set([pkgset.package_set_name for pkgset in lp.distributions['ubuntu'].archives[0].getPackagesetsForSource(sourcepackagename = 'blueman')]) | 08:51 |
| stgraber | set([u'xubuntu']) | 08:51 |
| stgraber | micahg: ^ | 08:51 |
| infinity | stgraber: Weird, cause it shows in the queue. | 08:51 |
| stgraber | infinity: yeah and edit_acl.py shows it too... it's just when specifically using getPackagesetsForSource that it fails | 08:52 |
| * micahg doesn't know the LP API enough to argue | 08:52 | |
| infinity | There, lamiak got a build. | 08:53 |
| stgraber | micahg: I poked #launchpad | 08:53 |
| infinity | pitti: Okay, you have more i386 than you could ever want now. Enjoy. | 08:56 |
| pitti | oh, you commissioned some amd64 ones, too? | 08:56 |
| pitti | wow | 08:56 |
| cjwatson | infinity: may as well - I'll go and do that now | 08:57 |
| infinity | crested and yellow can keep up with the trickle. | 08:57 |
| pitti | I think at this point building the sources and uploading them from macquarie will be slower than the binary builds :-) | 08:57 |
| infinity | cjwatson: Oh see, if I'd thought you would want to, I would have not uploaded. Oh well. | 08:57 |
| infinity | cjwatson: Alternately, I could have done it myself, but I have no idea how. :P | 08:57 |
| cjwatson | infinity: ah, never mind, I was still working my way through scrollback. Not that important. | 08:59 |
| cjwatson | I've requested a download from LP now just in case there's another. | 08:59 |
| stgraber | sorry for that, should be working fine now ;) | 09:10 |
| stgraber | micahg: so basically the call I was using to get the packagesets was the one used by LP to check for archive upload rights | 09:10 |
| stgraber | micahg: which doesn't work with the lubuntu package set as it doesn't have any uploader | 09:10 |
| stgraber | micahg: the bot now uses another API call that should return the right thing | 09:11 |
| infinity | Huzzah. | 09:12 |
| pitti | langpacks look good, uploading/accepting | 09:23 |
| infinity | pitti: What do you know about this lightdm upload? Sure looks featurey to me. | 09:23 |
| pitti | infinity: not much; can review if you want | 09:24 |
| pitti | i. e. I didn't get an advance warning about it or so | 09:24 |
| infinity | I reviewed it, and is seems sane, but it's definitely new features. | 09:24 |
| Laney | -proposed: maybe it's for SRU | 09:24 |
| infinity | Possibly. | 09:25 |
| infinity | We've blurred the lines a bit. | 09:25 |
| infinity | Except, it doesn't meet SRU guidelines either. :P | 09:25 |
| infinity | Again, new features. | 09:25 |
| pitti | ah, to -set-defaults | 09:25 |
| Laney | Yes, but then it's Not Our Problem™ :P | 09:25 |
| infinity | Not saying I'd reject it off-hand, and it looks sane and well-contained, and obviously not broken at a glance. | 09:26 |
| pitti | not sure if these were requested by some derivative or OEM or whatnot | 09:26 |
| pitti | I don't remember reading a bug about those | 09:26 |
| infinity | pitti: Just get someone to formally ask for a FFe, so if another RM asks them about it, they can say "Release member X said I could." :P | 09:26 |
| pitti | so l-s-d is for derivative mybuntu-defaults pacakges to change the lightdm defaults instead of hacking the config file | 09:27 |
| infinity | pitti: It has my stamp of "looks correct to me, and I can see the value in it". | 09:27 |
| pitti | err, perhaps I should use a slightly longer abbreviation | 09:27 |
| pitti | infinity: *nod* | 09:27 |
| infinity | Though, if they're going to keep hacking features into lightdm, for the love of the Flying Spaghetti Monster, can someone make it write to utmp/wtmp? | 09:28 |
| infinity | I'm so sick of not being logged in when I'm logged in. | 09:28 |
| pitti | infinity: you can reproduce that bug? | 09:28 |
| pitti | please do tell Robert | 09:28 |
| pitti | he and I can't, at least | 09:28 |
| infinity | pitti: Bug? What bug? It's a missing feature. | 09:29 |
| infinity | adconrad@cthulhu:~$ w | 09:29 |
| infinity | 03:28:58 up 11 days, 11:00, 0 users, load average: 0.04, 0.08, 0.05 | 09:29 |
| infinity | USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT | 09:29 |
| infinity | adconrad@cthulhu:~$ | 09:29 |
| pitti | bug 870297 | 09:29 |
| ubot2 | Launchpad bug 870297 in lightdm "Lightdm logins not being logged in wtmp" [High,Confirmed] https://launchpad.net/bugs/870297 | 09:29 |
| infinity | ^-- Are you saying you actually have sessions? | 09:29 |
| pitti | I have 6 of them | 09:29 |
| infinity | *blink* | 09:29 |
| pitti | it's not trivial to reproduce, so perhaps robert can borrow an ssh to your box or something | 09:30 |
| infinity | Sure. I was always under the impression it was just a missing feature. | 09:30 |
| infinity | It's easy to reproduce here. :P | 09:30 |
| pitti | "last" uses the same db, right? | 09:32 |
| infinity | last uses wtmp. | 09:32 |
| infinity | I can't remember what w uses. Probably the same. | 09:32 |
| * infinity tries to remember the difference between wtmp and utmp, but it's been a while since he had to care. | 09:32 | |
| infinity | Ahh, "man wtmp" is helpful. | 09:33 |
| pitti | "last" has data for every day here | 09:33 |
| infinity | wtmp is logins, utmp is current session data. | 09:33 |
| infinity | And yeah, I have neither, except for console logins. | 09:33 |
| infinity | And ssh. | 09:34 |
| infinity | So, I should invert that. | 09:34 |
| infinity | I have everything, except for lightdm-spawned sessions. :P | 09:34 |
| pitti | https://launchpad.net/builders is a joy to look at | 09:34 |
| infinity | pitti: The utmp/wtmp manpage seems pretty informative. It's like a HOWTO for mangling them in C. :P | 09:36 |
| stgraber | ^ affects the testing lab in Montreal at least, possibly some other setups too (not sure how many people actually netboot the live cd though) | 09:47 |
| infinity | stgraber: Did you learn nothing 6 months ago? All important casper uploads happen within ~12h of release. | 09:48 |
| stgraber | I also noticed that the current code generating resolv.conf would generate an invalid file if no domain or search path are defined in the dhcp (fairly common for home networks) | 09:48 |
| infinity | I should reject that just based on the above principle. | 09:48 |
| stgraber | infinity: ;) | 09:48 |
| stgraber | infinity: I'm happy to upload it next Wednesday if that makes you happy :) | 09:48 |
| infinity | I'd be thrilled, but then it need to include a fix for a REALLY RC, CAN'T LIVE WITHOUT FIXING IT bug. | 09:49 |
| infinity | So, go find one of those. | 09:49 |
| infinity | I should try sleeping again. | 09:50 |
| infinity | I can almost hear pitti giggling with childlike glee from here. | 09:50 |
| pitti | 584 jobs (1 hour) is really not that bad :) | 09:50 |
| infinity | pitti: So, if I fix launchpad to dispatch arch:all (with no any) sources to *all* architectures, will that make you even happier? | 09:51 |
| pitti | it certainly would :) | 09:51 |
| infinity | You'd have an army of angry pandas. | 09:51 |
| stgraber | I'm sure a lot of people would be quite happy to that | 09:52 |
| infinity | Well, I really wanted to be able to do arch affinity at one point too (for things like openbios), but... | 09:52 |
| infinity | That looks more painful to solve. | 09:52 |
| infinity | Doing the above (just letting arch:all builds fly willy-nilly) would be fairly simple. | 09:53 |
| infinity | Hrm. | 09:54 |
| infinity | I wonder if I could fudge affinity, now that I think about it. | 09:54 |
| infinity | If a package is listed as, say, "Architecture: all powerpc", I could then send it to PPC as a '-b' build. | 09:55 |
| tumbleweed | building arch:all anywhere would certainly find us a bunch of interesting bugs :) | 09:57 |
| infinity | tumbleweed: Bugs I'd love to fix, I don't see that as a bad thing. | 09:57 |
| tumbleweed | but yes, some packages really do need affinity. We don't want to just give them back until they hit the right architecture | 09:57 |
| pitti | we'd also need to find a solution for packages which are really arch:all, but don't work on some | 10:05 |
| pitti | usb-creator and the like | 10:05 |
| infinity | I'm having a nice lightbulb here. | 10:06 |
| infinity | You can include packages in control that aren't actually built. | 10:07 |
| infinity | So, we just have people include a dummy package that's for the arch they want affinity with. | 10:07 |
| infinity | And if I see "all foo" where "foo" isn't a wildcard, I pass the build to a "foo" builder as a '-b' (instead of the usual '-B'), and done. | 10:07 |
| infinity | There might be some broken assumptions in the queue code as well, but that should be fixable. | 10:08 |
| infinity | But declaring it in the source package beats having some silly affinity database in LP. | 10:08 |
| infinity | (I suppose instead of that hackish heuristic, we could define a new control stanza too) | 10:09 |
| pitti | XS-Build-Architecture: ? | 10:10 |
| infinity | Something like that. | 10:10 |
| pitti | err, XC- probably | 10:10 |
| infinity | C? | 10:10 |
| infinity | S is source. | 10:10 |
| pitti | S is .dsc, C is changes, right? | 10:10 |
| pitti | I suppose .changes is the most important one, but S can't hurt either | 10:10 |
| infinity | No, changes isn't important at all. | 10:10 |
| infinity | LP throws it away once it's grabbed some bits. | 10:11 |
| infinity | .dsc (S) is what matters. | 10:11 |
| infinity | Besides, you want the hint to persist, if people apt-get source, etc. | 10:11 |
| infinity | Or apt-cache source, rather. | 10:11 |
| tumbleweed | is that the case for wanna-build too? (caring about .dsc rather than changes). Debian is intending to do arch-all builds at some point | 10:13 |
| infinity | tumbleweed: .changes is only for queuebots. | 10:13 |
| infinity | tumbleweed: .dsc is what matters (or should matter) to anything that processes source. So, yeah, wanna-build as well. | 10:13 |
| infinity | Unless someone broke wanna-build when I wasn't looking. :P | 10:14 |
| tumbleweed | sounds sane :) | 10:14 |
| infinity | Well, there's one place where .changes matters to wanna-build, I guess. | 10:14 |
| infinity | But it doesn't read it. | 10:14 |
| infinity | The queue bots have to tell w-b which Dist the upload was targetted to (which is only in the .changes) | 10:15 |
| infinity | Beyond that, it's useless. | 10:15 |
| Laney | Have fun bikeshedding it out with ftp-master :P | 10:16 |
| infinity | (If you're setting up a new w-b, though, you just scan a source archive) | 10:16 |
| infinity | And no, if I implement this in Ubuntu/LP, it'll be an XS header (ie: local), and people can argue about it later, I don't care. :P | 10:17 |
| tumbleweed | :) | 10:17 |
| infinity | It's probably been 6 or 7 years since I committed to wanna-build, I think I'd prefer to stay arm's length from whatever flamewar might come up. | 10:18 |
| infinity | tumbleweed: Oh, as for Debian "wanting to do arch:all", the easy solution is just to make all i386 buildds build with -B by default, and you're done. | 10:18 |
| Laney | I guess this wouldn't apply to so many packages, but it would be a shame if this were implemented differently over there | 10:18 |
| infinity | tumbleweed: That's how we did it back when we used dak/w-b. | 10:19 |
| infinity | tumbleweed: One sbuild config. | 10:19 |
| tumbleweed | infinity: of course, but presumably that wouldn't happen in debian until there was affinity, or there'd be broken packages | 10:19 |
| infinity | Well, not if they intend to turn off arch:all uploading at the same time, yeah. | 10:20 |
| * tumbleweed wonders if we'll still be using maintainer-built debs in 10 years | 10:20 | |
| infinity | (I like right now that arch:all uploading is a way to get around Debian not allowing source uploads...) | 10:20 |
| infinity | You can totally just do a source+all upload, and let all the binaries get cooked on the buildds. :P | 10:20 |
| * tumbleweed should do that more | 10:20 | |
| infinity | I tend to go the other direction, and build on as many arches as I have the time for. | 10:21 |
| infinity | But I'm not normal. | 10:21 |
| infinity | Or sane. | 10:21 |
| infinity | Laney: And yeah, affinity should, realistically, affect such a tiny subset of packages (I'd consider anything that doesn't NEED it to be buggy), that I don't think it matters if we implement it differently. At worst, it's a few tiny diffs to carry, at best, we just change our implementation to accept their input. | 10:23 |
| Laney | I was thinking in terms of your cost implementing it :-) | 10:23 |
| Laney | (and then possibly reimplementing) | 10:23 |
| infinity | The LP bits are costly. Parsing a different header isn't. :P | 10:23 |
| infinity | And if they implement it directly as a staple-on DB for w-b or something, we can't leverage that anyway. | 10:24 |
| Laney | Yes, so as long as the general approach is the same then we're good. | 10:24 |
| infinity | The only way it can be shared is source-level, which implies control fields, which means, at worst, we have to parse a new field. | 10:24 |
| infinity | (The other option would be to extend P-a-s, but given the efforts to phase it out over the years, that would seem like an odd choice) | 10:25 |
| tumbleweed | dependency availability will differ across archs, packages shouldn't end up in depwait because they hit an unsupported arch | 10:26 |
| infinity | tumbleweed: That's readily solvable for Debian, since they do dep-waits pre-dispatch now. | 10:27 |
| cjwatson | infinity: Debian were planning a field for affinity, I think. Mark Hymers was talking about it at debconf. | 10:27 |
| infinity | For us, I'm sure I could work something out in the dep-wait resolver. | 10:27 |
| infinity | cjwatson: Cool, then we're on the same page logically, and the name really doesn't matter. Names can change. | 10:27 |
| infinity | Unless they're linkers. | 10:28 |
| infinity | But I'm not bitter. | 10:28 |
| tumbleweed | :) | 10:28 |
| ev | finally getting around to tackling this arm build failure in whoopsie (while the world burns in our crashdb retracer farm) - how does one get build depends into porter-armel? | 10:43 |
| cjwatson | sudo apt-get install | 10:44 |
| ev | cjwatson: I think I'm missing a step there. Do I need to schroot into something? | 10:45 |
| ev | as sudo apt-get install asks for my nonexistent password | 10:45 |
| pitti | ev: yes, dchroot into the precise chroot | 10:45 |
| pitti | there you can sudo | 10:45 |
| ev | ah, dchroot | 10:46 |
| ev | cheers | 10:46 |
| cjwatson | schroot nowadays, not dchroot | 10:46 |
| cjwatson | (per motd) | 10:46 |
| ev | oops - I'm so used to seeing that bird that I skipped right past that | 10:47 |
| infinity | ev: I'm still betting you're looking for something related to char signedness. Unless it's pure coicidence that it fails on the 3 arches where that's different. | 10:47 |
| ev | apols for that | 10:47 |
| infinity | ev: Which means you might have a more pleasant time debugging on the powerpc porter. It's faster. | 10:47 |
| ev | infinity: cheers for the tip - I missed you pointing that out previously | 10:47 |
| ev | ah indeed | 10:47 |
| Q-FUNK | Would anyone happen to know what is the current status with esteid-browser-plugin in NEW? chrisccoulson asked me to re-upload once upstream had fixed specific issues and it's now been taken care of. | 10:48 |
| ev | fixed. It was not returning boolean from a glib callback | 11:50 |
| infinity | Q-FUNK: Is that the firefox plugin that no one wants to accept, because having plugins in the archive means maintaining/updating them through 5 years of firefox releases? | 11:52 |
| pitti | I guess we can put back the amd64 builders to normal duty? | 11:58 |
| === greyback is now known as greyback|lunch | ||
| infinity | pitti: Sure. | 12:01 |
| pitti | infinity: ok, doing | 12:01 |
| infinity | I was alread. ;) | 12:01 |
| infinity | already.. | 12:01 |
| pitti | ah, ok; I switched two over | 12:02 |
| Q-FUNK | infinity: upstream has been doing a fine job at tracking firefox and thunderbird releases. | 12:03 |
| infinity | Q-FUNK: Sure, but does that mean someone in Ubuntu (you?) is committed to doing the same? | 12:03 |
| infinity | If not, we're better off having users install from upstream, as we do for pretty much all plugins. | 12:04 |
| Q-FUNK | infinity: the package itself has been team-maintained in a PPA for the past 2 years already. | 12:04 |
| infinity | That doesn't actually answer the question. | 12:04 |
| Q-FUNK | yes, it does. there's a team committed to maintaining it. | 12:05 |
| Q-FUNK | this cannot be installed from upstream, because it accesses security modules and other stuff that is distro-specific. | 12:05 |
| infinity | Alright. Then I guess we're back to having one of us nitpick over the source. | 12:06 |
| Q-FUNK | which is always welcome. chrisccoulson's suggestion of submitting the code to mozilla for review was also a welcome idea. | 12:07 |
| stgraber | partman-base looks good (did a manual diff as LP seems a bit slow at the moment) | 12:07 |
| chrisccoulson | hi :) | 12:10 |
| cjwatson | stgraber: thanks, accepted | 12:10 |
| Q-FUNK | infinity: upstream himself is on the LP team. he's also extremely receptive to code reviews and bug reports. this should help minimize the need for chrisccoulson or whoever else maintains FF from having to do anything more than file the occasional bug report. | 12:10 |
| Q-FUNK | chrisccoulson: hey :) | 12:11 |
| ev | ^ that fixes the powerpc and arm build failure. Ignore the giant diff. That's all backend code that does not get built into packages. | 12:12 |
| stgraber | ev: having a look | 12:13 |
| stgraber | ev: ouch, giant diff indeed, what did you do to make the source 25MB larger? | 12:14 |
| ev | heh, new yui3 | 12:14 |
| stgraber | anyway, looks sane when ignoring backend/ | 12:15 |
| stgraber | ^ please someone accept whoopsie-daisy | 12:15 |
| infinity | Done. | 12:18 |
| stgraber | live-build looks good too (generates kernel-img.conf on ! alpha|amd64|hppa|i386|ia64|m68k|mips|mipsel with link_in_boot = yes) (so in our case, powerpc, armhf and armel) | 12:20 |
| infinity | Seems sane. | 12:21 |
| phillw | is bug 966403 going to get into the RC? | 12:21 |
| ubot2 | Launchpad bug 966403 in linux "Lubuntu Install (entire disk with encryption) doesn't prompt for disk password." [High,Triaged] https://launchpad.net/bugs/966403 | 12:21 |
| cjwatson | I suspect it'll stand a better chance if it's not on linux. | 12:22 |
| cjwatson | Wait, /me reads the bug | 12:22 |
| cjwatson | Wow, actually a kernel bug | 12:22 |
| phillw | that was the one I mentioned that needed a new kernel & couldn't find. | 12:23 |
| cjwatson | phillw: seems like a stretch. All we know is that it's fixed in current mainline, but there's no possibility of updating to 3.4-rc2 in precise. | 12:23 |
| cjwatson | It's a fair way from here through bisecting to find the specific commit that fixed it to backporting that. | 12:23 |
| phillw | okies, thanks. I'll get something written up for our release notes. | 12:24 |
| phillw | basically, they need to grab that kernel? | 12:25 |
| stgraber | no, you don't want to recommend your users to run the mainline kernel builds | 12:25 |
| cjwatson | I doubt that's a sane workaround for most people. | 12:25 |
| cjwatson | Probably saner to use plymouth:force-drm as in comment 24. | 12:25 |
| stgraber | gah, cjwatson was faster ;) | 12:25 |
| ev | thanks stgraber and infinity | 12:26 |
| phillw | okay. As long there is a workaround for it :) I'm a couple of thousand miles from my test rig on a course - so am 100% reliant on the lubuntu testing team :) | 12:26 |
| stgraber | and it's also not clear exactly what hardware is affected or how widespread the problem is. It's also very unlikely to be Lubuntu specific, with it being a kernel bug, it should affect Ubuntu just as much | 12:26 |
| cjwatson | indeed | 12:27 |
| jdstrand | ftr, I felt that cobbler was unsupportable for 5 years and since the server team only needed a smallish part of cobbler for maas, but were under a time crunch, I gave them various options which would meet their timeframe and objectives while reducing the maintenance burden of both teams | 12:27 |
| stgraber | phillw: I'm not sure it's even worth a release note entry, according to LP the same reporter had the issue on Lubuntu and Kubuntu but I don't see any other duplicate, making me think it's happening on a very specific piece of hardware | 12:28 |
| jdstrand | a couple of those options included duplicate code, which is not ideal, but better than supporting all of cobbler for the lts | 12:29 |
| infinity | jdstrand: Fair enough, as long as you're down with reviewing it all. | 12:29 |
| === doko_ is now known as doko | ||
| jdstrand | yes, I signed up for that | 12:29 |
| infinity | And as pennance, you get to review that firefox plugin in the queue too... | 12:30 |
| infinity | *duck* | 12:30 |
| * ogra_ grins | 12:30 | |
| stgraber | phillw: I think release noting would just make anyone with encryption problem set plymouth:force-drm which by itself can cause other problems (on systems with multiple video cards, like most new laptops). Might be better to just track that as a bug and hope it's fixed for the first point release. If we suddenly see duplicates appearing, we can always add an entry to the release notes post-release. | 12:30 |
| jdstrand | my team also has a method for tracking duplicate/embedded code so neither will be forgotten about | 12:30 |
| phillw | stgraber: okies, I'll have the workaround added to the lubuntu/FAQ/Workarounds so the support team have easy access to it. | 12:31 |
| stgraber | phillw: sounds good | 12:31 |
| jdstrand | oh that esonian plugin, thanks, but uhh, no thanks :) | 12:31 |
| Q-FUNK | heheh | 12:31 |
| jdstrand | infinity: I thought my penance was the initial review :P | 12:31 |
| jdstrand | a pre-penance | 12:31 |
| infinity | I like to keep thinking of new ways to make people suffer. | 12:32 |
| infinity | I consider it proactive. | 12:32 |
| jdstrand | you do have a knck for it | 12:32 |
| jdstrand | knack* | 12:32 |
| jdstrand | :) | 12:32 |
| infinity | jdstrand: S'ok, my penance for past sins appears to be making 5 eglibc uploads to two distros in 3 days. | 12:33 |
| jdstrand | haha | 12:34 |
| jdstrand | ouchie | 12:34 |
| * jdstrand hugs infinity | 12:34 | |
| stgraber | cjwatson: can you do another rebuild of ubuntu desktop? last langpack finished building an hour ago, so everything should be published now. | 12:42 |
| cjwatson | ah, yes, I was just about to do that | 12:45 |
| cjwatson | running | 12:45 |
| stgraber | thanks | 12:46 |
| pitti | skaet wanted to do a full rebuild of everything tonight, FYI | 12:49 |
| stgraber | pitti: her "tonight" or our "tonight"? :) | 12:50 |
| pitti | stgraber: could very well be her "tonight", given that she said it | 12:50 |
| pitti | so we can certainly fit in a rebuild now, if for nothign else than checking that the sizes are ok | 12:51 |
| cjwatson | apt/oneiric LGTM now | 12:51 |
| * pitti checks casper | 12:51 | |
| cjwatson | pitti: well, I hope so, since it's it's already running | 12:51 |
| cjwatson | s/it's // | 12:51 |
| pitti | casper not published yet on arm* | 12:51 |
| pitti | but it is for the x86, so we can test that | 12:52 |
| Q-FUNK | chrisccoulson: thanks for your e-mail. I've personally tested the extension, but I'm unable to test the plugin without an estonian ID card. however, kalev uses the same code on fedora, afaik. | 12:52 |
| infinity | pitti: casper's not used on arm, so that works. | 12:52 |
| pitti | right, only missing for ppc (but I doubt it'll behave much different, and it's not like anyone would care today) | 12:53 |
| stgraber | pitti: right, I quickly checked that casper was published on amd64 and i386 as it's where that change will be used, I don't think we do netboot desktop image testing of powerpc | 12:53 |
| jdstrand | Daviey: is the maas-provision in NEW now the one you want looked at? | 12:53 |
| === greyback|lunch is now known as greyback | ||
| cjwatson | oh, here, there are some new workarounds for openssl problems in upstream CV | 12:54 |
| cjwatson | CVS | 12:54 |
| Q-FUNK | cjwatson: anything that would help for Bug #972783 by any chance? | 12:56 |
| ubot2 | Launchpad bug 972783 in openssl "Crashes with segmentation fault operating asn1_meth_table" [High,Confirmed] https://launchpad.net/bugs/972783 | 12:56 |
| cjwatson | I looked but I'm not sure | 12:57 |
| cjwatson | the changes don't seem to be on that particular code path, but it's openssl, who knows | 12:57 |
| Q-FUNK | :D | 12:57 |
| jbicha | ^ gnome-online-accounts has a new feature: Facebook support | 13:02 |
| seb128 | jbicha, did you check with kenvandine? | 13:03 |
| seb128 | jbicha, I think he has not concerns about how the work involved with maintaining support for handling of an online site which might change auth etc during the 5 years of the lts | 13:03 |
| seb128 | has some concerns* | 13:04 |
| infinity | If it's just facebook chat, that's xmpp. | 13:04 |
| infinity | I don't see how they'd plan to break it too badly. | 13:04 |
| seb128 | infinity, well it's account registration and stuff | 13:04 |
| jbicha | seb128: no, I didn't ask him | 13:05 |
| seb128 | infinity, which might be different from im | 13:05 |
| seb128 | infinity, it would also not be the first time a such site is "unhappy" about third party clients which let you use them without advertisement or such | 13:06 |
| seb128 | infinity, or that would change rules about third party clients | 13:06 |
| jbicha | we do already support Google & Windows Live there though... | 13:06 |
| seb128 | knowing that gnome-online-accounts is not used under Unity | 13:06 |
| seb128 | jbicha, yeah, i don't say it shouldn't be done, I'm just pointing it has issues over new code, it also has an implication on the 5 years support | 13:07 |
| seb128 | we never know what those websites might do in 2 years and what impact in will have on client code | 13:08 |
| kenvandine | jbicha, that was added rather late and i didn't have time to really look at it before release | 13:09 |
| kenvandine | jbicha, and of course the support issues in an LTS | 13:10 |
| kenvandine | it is more than just the xmpp registration | 13:10 |
| cjwatson | Q-FUNK: it certainly wouldn't hurt for somebody closer to that bug to file it upstream ... | 13:11 |
| Q-FUNK | cjwatson: good point. this being ssaid, the exact same code works with the same openssl version on other non-debian-based distros. | 13:12 |
| jbicha | well Debian & Fedora enable the Facebook provider, but I'll defer to your judgment | 13:13 |
| kenvandine | jbicha, if it had landed earlier i would have probably enabled it | 13:13 |
| kenvandine | but it came late | 13:13 |
| cjwatson | Q-FUNK: Does it fail on Debian too? We don't have a particularly extensive Ubuntu patch set here. | 13:14 |
| cjwatson | comment 8 on the esteid bug, "I built OpenSC 0.12.2 with LibSSL 1.0.0e and this resulted the same bug." - I wonder if that was upstream openssl or Ubuntu's | 13:16 |
| Q-FUNK | cjwatson: those estonian ID card support packages have not been submitted to debian yet but, afaik, someone compiled their own using our ubuntu packages and encountered the same issue. | 13:16 |
| cjwatson | also strictly speaking "other non-debian-based distros" actually distro singular, the only success report is on Fedora | 13:17 |
| cjwatson | and an unspecified version of Fedora at that, so could be older openssl? | 13:17 |
| Q-FUNK | IIRC it also works on gentoo. | 13:17 |
| Q-FUNK | no, that was specifically since 1.x | 13:17 |
| cjwatson | Nobody mentioned that in the esteid bug | 13:17 |
| Q-FUNK | cjwatson: could you add those comments to the LP bug? tramm can then further precise on LP or upstream, as needed. | 13:18 |
| seb128 | jbicha, kenvandine: well, neither Debian or Fedora will actively support it for 5 years, it's easier for them to enable it ;-) | 13:18 |
| cjwatson | done | 13:20 |
| Q-FUNK | thanks! | 13:20 |
| Q-FUNK | cjwatson: tramm is the one who filed this report. | 13:22 |
| Q-FUNK | cjwatson: if there's anything else you need him to provide, please feel free to ask. | 13:23 |
| cjwatson | Q-FUNK: realistically, I'm just drive-by-ing openssl for the purposes of sorting out all this TLS 1.2 stuff, I don't know it well enough to know what to ask really | 13:31 |
| cjwatson | which is why I'm trying to narrow down whether this is Ubuntu-specific or not, as either Kurt (in Debian) or upstream will likely be able to help better | 13:32 |
| ogra_ | infinity, oh, should we drop the ti-omap4-ppa stuff from the archive before release (just struck me that its still there) | 13:32 |
| Q-FUNK | cjwatson: does Kurt track issues at ubuntu as well? | 13:36 |
| jbicha | ok, I filed an actual FFe bug for g-o-a, bug 984897 | 13:40 |
| ubot2 | Launchpad bug 984897 in gnome-online-accounts "FFe: Sync gnome-online-accounts 3.4.1-1 (main) from Debian unstable & enable Facebook" [Wishlist,New] https://launchpad.net/bugs/984897 | 13:40 |
| cjwatson | Q-FUNK: not AFAIK | 13:40 |
| cjwatson | openssl 1.0.1-4ubuntu2 uploaded to -proposed - please note I'd like to get this manually tested before promotion to precise (if it doesn't become an SRU instead) | 14:06 |
| cjwatson | I'm hoping it will fix bug 969343 and at least not regress the other TLS 1.2 issues | 14:06 |
| ubot2 | Launchpad bug 969343 in wpasupplicant "Unable to connect to WPA enterprise wireless" [Undecided,Incomplete] https://launchpad.net/bugs/969343 | 14:06 |
| skaet | cjwatson, pitti - what's happening with respins? | 14:43 |
| skaet | ie. are any more already known to be needed? | 14:44 |
| * skaet trying to figure out timing of switching over to release candidate on the tracker and defaults, etc. | 14:45 | |
| pitti | skaet: langpacks are in, apport/kerneloops standing by, some other fixes are in from today | 14:45 |
| skaet | pitti, waiting to get signed WUBI in as well. | 14:46 |
| pitti | there is still a python-defaults in -proposed which I'm not sure about (the wiki has a stop sign for that) | 14:46 |
| cjwatson | handful of installer tweaks based on today's QA still to do | 14:46 |
| pitti | and there's a lightdm in unapproved which is technically a new (small) feature | 14:46 |
| cjwatson | and possibly this dpkg-divert bug depending on upstream feedback | 14:46 |
| pitti | it looks alright to me, though; infinity reviewed the patch, and would feel better with a formal FFE bug, though | 14:47 |
| ogra_ | that recent mail about linker changes on ubuntu-devel-discuss looks a bit worrying | 14:47 |
| pitti | so it's "accept now" vs. "wait for the paperwork" | 14:47 |
| ogra_ | (--as-needed vs --no-as-needed) | 14:47 |
| jbicha | ogra_: but that changed months ago, didn't it? | 14:47 |
| ogra_ | jbicha, we just got a new toolchain upload | 14:47 |
| ScottK | As long as someone has reviewed the details of the python-defaults change (I didn't), since it's built on all archs, it's probably better if it goes in. | 14:48 |
| * ogra_ refers to https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-April/013579.html | 14:49 | |
| skaet | pitti, re: python-defaults, want slangasek in on discussion. I thought he was agreeing with doko in channel yesterday it should be a 0-day SRU, but given its built, rather include it now, if its been carefully reviewed. | 14:49 |
| skaet | ScottK, agreed. | 14:49 |
| ScottK | doko said it could be either. | 14:49 |
| seb128 | ogra_, jbicha: well --as-needed was clearly "broken" during precise, like stuff would build with missing -l flags where they would fail i.e in gentoo or debian | 14:50 |
| ScottK | I'm more of the "why wait" school as it'd be weird for -release to have no /usr/bin/python2 and for an SRU to add it. | 14:50 |
| seb128 | not sure if that "fixes" that, but yeah it seems late for a toolchain change if there is one | 14:50 |
| ogra_ | seb128, so you think that was fixed with the recent upload ? | 14:50 |
| seb128 | ogra_, could be | 14:50 |
| ogra_ | iirc the current toolchain change was arm only | 14:50 |
| ogra_ | at least it was supposed to be | 14:51 |
| ogra_ | but it touched the linker | 14:51 |
| ogra_ | it might even be that he is between two uploads (there were multiple ones) and it is fixed already ... just wanted to give a heads up since if it actually changed thats a bit worrying | 14:51 |
| slangasek | skaet, ScottK: yes, the python2 part is not really SRU-suitable; so I think this is better to include in -release, though I'm not sure what testing the packages have gotten yet and think there should be some explicit testing before we copy | 14:52 |
| skaet | pitti, please copy it over and lets get itincluded. | 14:52 |
| skaet | oops | 14:52 |
| skaet | missed the last part of slangasek's statement | 14:53 |
| doko | I did an update test, and double checked that the replaces are correct | 14:53 |
| skaet | thanks doko :) | 14:53 |
| skaet | slangasek, any other spot testing you recommend? | 14:54 |
| ScottK | I'd suggest a Lucid -> Precise upgrade test since it has /usr/bin/python2 as well. | 14:55 |
| doko | ScottK, lucid has python2? | 14:55 |
| slangasek | yes, that'd be good - testing that it updates correctly from all of lucid, oneiric, and current precise | 14:55 |
| ScottK | I thought. Let me check. | 14:55 |
| pitti | /usr/bin/python2 -> python2.6 | 14:56 |
| pitti | yep | 14:56 |
| cjwatson | it did, that's why I filed that bug about the broken Replaces | 14:56 |
| pitti | (in lucid) | 14:56 |
| seb128 | ogra_, seems others are not too concerned about it ;-) | 14:56 |
| pitti | python-minimal: /usr/bin/python2 | 14:56 |
| cjwatson | bug 954609 | 14:56 |
| ubot2 | Launchpad bug 954609 in python-defaults "/usr/bin/python2 overwrites file in old versions of python-minimal" [Medium,In progress] https://launchpad.net/bugs/954609 | 14:56 |
| ScottK | doko: Yes. In python-minimal: http://packages.ubuntu.com/search?searchon=contents&keywords=python2&mode=exactfilename&suite=lucid&arch=any | 14:56 |
| doko | ScottK, ahh, yes. in python-minimal, as now | 14:56 |
| skaet | seb128, ogra_ - just tackling things in order.... ;) we don't have .. and raise the hand syntax going. | 14:58 |
| skaet | lol | 14:58 |
| seb128 | ;-) | 14:58 |
| ogra_ | seb128, well, then i'll go with the unwashed masses | 14:59 |
| * ogra_ looks for a nose clamp though | 14:59 | |
| bjf | failing to install grub with today's daily-live iso .. amd64 | 15:05 |
| bjf | the usb key comes up as /dev/sda, i'm trying to install to /dev/sdb | 15:05 |
| bjf | i get error dialog saying grub install fails | 15:05 |
| cjwatson | logs | 15:05 |
| bjf | it seems to be trying to install grub to /dev/sda | 15:06 |
| bjf | cjwatson: will do | 15:06 |
| skaet | doko, is --as-needed change ( https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-April/013579.html ) a side effect of the last set of full rebuilds we include? | 15:08 |
| ScottK | skaet: It appears there's still an open question about getting Maas into Main. mass-provision (still in source New) is apparently required for that. I don't know if that, in the end, implicates an image that's tested or not. | 15:08 |
| doko | skaet, no, unchanged from oneiric | 15:10 |
| cjwatson | we added --as-needed yonks ago. https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed | 15:10 |
| skaet | ogra_, seb128 ^ | 15:11 |
| doko | cjwatson, but oneiric was the first release where we left it turned on for the final release | 15:11 |
| ogra_ | cjwatson, right, to me it just looked like it switched from that mail | 15:11 |
| cjwatson | doko: sure | 15:11 |
| cjwatson | ogra_: *shrug* I think he's misunderstanding something | 15:11 |
| ogra_ | and "within the last days" made me worry it changed due to the recent uploads (planned or not) | 15:12 |
| cjwatson | maybe he meant to say that it was a change since lucid (true) but didn't express himself well | 15:12 |
| cjwatson | it didn't | 15:12 |
| ogra_ | yeah, got tha now :) | 15:12 |
| ogra_ | *that | 15:12 |
| seb128 | ogra_, cjwatson: yeah, the stuff that lack -l option and shouldn't build still build, i.e no change, I still think there is something weird in there but I didn't have time to look at what,why this cycle to report a bug ;-) | 15:16 |
| skaet | is there a bug for the man page update? or can someone quickly handle? | 15:17 |
| bjf | cjwatson bug 984989 | 15:17 |
| ubot2 | Launchpad bug 984989 in grub-installer "grub install fails. installing from /dev/sda to /dev/sdb" [Undecided,New] https://launchpad.net/bugs/984989 | 15:17 |
| skaet | ScottK, thanks, hadn't checked that yet today. Will be following up. | 15:19 |
| ScottK | Beyond that, I don't know. Daviey was on it last night. | 15:20 |
| cjwatson | so a's the USB stick and b's the internal disk, hmm, it's supposed to handle this | 15:20 |
| cjwatson | I thought there was even an automatic test for it, bah | 15:20 |
| bjf | cjwatson: yes, that is correct | 15:21 |
| cjwatson | bjf: any chance of an otherwise identical run with the 'debug-ubiquity' boot parameter? | 15:22 |
| cjwatson | then 'apport-collect 984989' | 15:22 |
| cjwatson | (when it fails) | 15:22 |
| bjf | cjwatson: will try, it seems to have borked my usb stick, will rebuild it | 15:22 |
| cjwatson | yeah, that's not impossible :-/ | 15:23 |
| cjwatson | bjf: I'd quite like to do some remote-hands debugging of it, timing permitting | 15:26 |
| bjf | cjwatson: i'm yours to command | 15:26 |
| cjwatson | the way it's supposed to work is that we look at where /cdrom is mounted from, and if that's the same as the GRUB installation location then we use the disk containing /boot instead, or failing that, just the next disk in the list | 15:28 |
| cjwatson | either something's going wrong in that, or the output isn't being used | 15:28 |
| cjwatson | the apport-collect logs will let me rule the latter in or out, but probably won't help much in debugging the former | 15:28 |
| bjf | cjwatson: you just want me to add "debug-ubiquity" after boot=casper right? | 15:30 |
| cjwatson | yeah | 15:30 |
| bjf | cjwatson: it's telling me "No additional information collected" does that mean i didn't get the debug-ubiquity correct? | 15:45 |
| slangasek | skaet: I've noticed that there are no milestones pre-created for 12.04.x point releases - I guess that should happen soon? | 15:45 |
| cjwatson | bjf: no, err, it means apport doesn't work the way I think it does, I guess. just attach /var/log/{syslog,partman,installer/debug} by hand | 15:46 |
| bjf | cjwatson: will do | 15:46 |
| skaet | slangasek, I stuck them on the release notes, but yup, need to add them on the release itself. They're on the ReleaseSchedule - can you review and let me know if you're aware of any changes? Otherwise will go add them today. | 15:47 |
| slangasek | skaet: oh, I'm not aware of any changes | 15:47 |
| slangasek | anyway, you can change the target date of the milestone after it's added... but you can't target bugs to a milestone before it exists :) | 15:47 |
| skaet | slangasek. :) doing now. | 15:49 |
| skaet | precise-updates does exist though. ;) | 15:49 |
| slangasek | yep... using it | 15:50 |
| slangasek | .1 is close enough now that I think it'd be useful to be more specific :) | 15:50 |
| bjf | cjwatson: done | 15:50 |
| skaet | :0 | 15:54 |
| skaet | :) even | 15:54 |
| kirkland | cjwatson: I see that you uploaded a fix in ecryptfs-utils 96-0ubuntu3, but I'm not seeing the diff in launchpad; I want to ensure that I commit the change to the upstream lp:ecryptfs branch | 16:05 |
| kirkland | cjwatson: https://launchpad.net/ubuntu/+source/ecryptfs-utils I only see 96-0ubuntu2 | 16:06 |
| stgraber | kirkland: http://launchpadlibrarian.net/102498742/ecryptfs-utils_96-0ubuntu2_96-0ubuntu3.diff.gz | 16:07 |
| stgraber | kirkland: not in the archive yet, currently in the release queue | 16:07 |
| kirkland | slangasek: I saw some noise in -meeting about ecryptfs/btrfs... I tested that a good bit in the 11.10 cycle, but I don't recall ever testing that in this 12.04 cycle | 16:07 |
| kirkland | stgraber: thanks! I'll commit upstream now | 16:08 |
| cjwatson | kirkland: thanks. in rather a rush, trying to get several pieces in place | 16:08 |
| kirkland | cjwatson: understood, no problem | 16:08 |
| cjwatson | in particular trying to unbreak lowish-mem amd64 encrypted-home installs | 16:09 |
| kirkland | cjwatson: thanks, I've committed and pushed r675 to lp:ecryptfs | 16:11 |
| slangasek | kirkland: ecryptfs/btrfs... all speculative at this point, don't really know | 16:12 |
| kirkland | slangasek: mkay | 16:13 |
| ev | skaet: the signed wubi is up, but I discovered bug 985050 while testing it | 16:20 |
| ubot2 | Launchpad bug 985050 in ubuntu "A Downloaded Wubi binary shows the autorun menu if an Ubuntu cd is inserted" [High,New] https://launchpad.net/bugs/985050 | 16:20 |
| skaet | ev, fix coming today? | 16:21 |
| ev | unlikely - I have to bolt in 40 minutes | 16:21 |
| ev | I'lll see what I can manage in the time I have left | 16:21 |
| skaet | ev, thanks. (and thanks for letting me know) | 16:22 |
| cjwatson | the downloaded binary doesn't actually have to be on the released images, of course | 16:22 |
| cjwatson | IWBNI they were in sync | 16:22 |
| cjwatson | but the current signed one should be good enough for CD images? | 16:23 |
| ev | yes | 16:24 |
| skaet | thanks ev | 16:25 |
| skaet | thanks jdstrand. :) | 16:27 |
| jdstrand | skaet: np | 16:31 |
| cjwatson | still working on bug 979350, but need to go and think about it for a while | 16:40 |
| ubot2 | Launchpad bug 979350 in ubiquity "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [High,Confirmed] https://launchpad.net/bugs/979350 | 16:40 |
| Cimi | pitti, ping | 16:57 |
| === bulldog98_ is now known as bulldog98 | ||
| SpamapS | FYI, I have a fix for bug 981130 .. ceph.. its not on any CD that I know of.. but wanted to raise the heads up while I do my test build | 17:41 |
| ubot2 | Launchpad bug 981130 in ceph "python-ceph Depends on librgw1, which is no longer built" [High,In progress] https://launchpad.net/bugs/981130 | 17:41 |
| micahg | librados2 (from ceph) is seeded in: | 17:42 |
| micahg | kubuntu: dvd | 17:42 |
| micahg | ubuntu-server: daily | 17:42 |
| SpamapS | kubuntu? | 17:43 |
| SpamapS | Oh kvm | 17:43 |
| micahg | librbd1 is as well | 17:43 |
| SpamapS | right ok | 17:43 |
| micahg | seeded-in-ubuntu FTW :) | 17:43 |
| SpamapS | yeah I haven't tried that | 17:43 |
| skaet | slangasek, rt #52293 for those point release milestones. FYI. | 18:09 |
| slangasek | ok | 18:09 |
| * skaet --> lunch | 18:09 | |
| cjwatson | skaet: why does milestone creation need an RT? any member of the TB can do it | 18:35 |
| cjwatson | actually, I thought release team could too, but TB certainly can | 18:35 |
| skaet | cjwatson, both slangasek and I tried earlier. Figured you were busy with the bugs. | 18:35 |
| skaet | I'll forward you the details if you want to just take care of it. | 18:36 |
| cjwatson | I'll do it when I'm back at my desk. IS is contended enough that I think we should only bother them when necessary | 18:36 |
| cjwatson | I can pick it up from RT | 18:36 |
| skaet | cjwatson, that will work. Thanks. | 18:37 |
| cjwatson | oh, bah, no permission to view ticket | 18:38 |
| cjwatson | you should use the platform address so that doesn't happen :) | 18:38 |
| cjwatson | please forward me the details, then | 18:38 |
| cjwatson | (https://wiki.canonical.com/SysAdminRtUsageGuide#rt-queues) | 18:39 |
| slangasek | cjwatson: both release team and ubuntu-drivers are shown as drivers on https://launchpad.net/ubuntu/precise/, but the button is missing for adding milestones; seemed like a LP weboppy thing from there | 18:42 |
| cjwatson | I have an ajax thing for adding milestones | 18:42 |
| cjwatson | perhaps it's because techboard owns the distribution | 18:42 |
| cjwatson | silly permissioning if you ask me, but | 18:42 |
| * skaet nods | 18:42 | |
| skaet | forwarding... | 18:42 |
| slangasek | yeah, it's a regression in permissions vs. what we had previously then :) | 18:43 |
| slangasek | skaet, cjwatson, ev: any of you know what's expected for the "Wubi upgrade" test case that's not already covered by the standard upgrade tests? | 18:45 |
| slangasek | I'm not sure why we have that as a separate test, tbh | 18:45 |
| * balloons is listening in | 18:46 | |
| ev | slangasek: If memory serves, we historically had a few upgrade failures that were specific to grub under wubi | 18:49 |
| slangasek | ev: do you think that's still relevant now? | 18:49 |
| * skaet applauds slangasek's effort to prune test cases out of manditory that don't add value ;) | 18:58 | |
| balloons | I guess that's our answer slangasek | 18:59 |
| skaet | balloons, we need to wait for ev's input, but its the right question. ;) | 19:01 |
| balloons | skaet, well, I mean in theory it's different, but I was asking how much focus should we place on it compared to our other wubi fresh install testing | 19:02 |
| ev | we landed the disk image stuff last cycle, so it hasn't been through a round of upgrade testing | 19:04 |
| ev | I'd say yes, so long as I'm not volunteering at the same time :) | 19:04 |
| skaet | ev, we'll let balloons try to find a volunteer first ;) | 19:06 |
| balloons | lol -- I have volunteers | 19:07 |
| ev | oh thank goodness | 19:07 |
| balloons | the question is to apply them to upgrade testing or new install | 19:07 |
| ev | half and half please :) | 19:07 |
| balloons | and I was asking slangasek for the old wubi versions to test them.. I'll have some folks go thru it | 19:07 |
| ev | it's still pointed to from the website | 19:08 |
| ev | the wubi binary, that is | 19:08 |
| ev | from 11.0 | 19:08 |
| ev | 11.10 even | 19:08 |
| slangasek | ev: is a full upgrade test the right thing to test? Would it make more sense to ask for installing 11.10, then doing a test specifically for grub or kernel upgrades? | 19:12 |
| ev | yeah, all I think that matters is that the thing boots | 19:12 |
| slangasek | (faster, less affected by irrelevant bugs, etc) | 19:12 |
| ev | does it pass grub does the kernel work | 19:12 |
| ev | done | 19:12 |
| phillw | slangasek: are the RC's still on cron-job for ~ 16:00 - 18:00 Thursday, or is it a manual build when you guys & gals are happy? | 19:13 |
| phillw | (GMT) | 19:14 |
| * slangasek redirects that question to skaet | 19:14 | |
| * phillw offers skaet cookies for an answer... :) | 19:15 | |
| skaet | phillw, we'll leave the cron on tonight, but it will redirect to release candidate milestone now. | 19:15 |
| skaet | after tonight we're turning it off | 19:15 |
| * skaet likes cookies.... thanks! | 19:15 | |
| phillw | I'll try and get some one at UDS-Q with paypal account and send some funds for cookies :) | 19:16 |
| skaet | :) | 19:16 |
| phillw | You'll be enjoying UDS-Q, i'll be on my final exmas.... fancy a swap? | 19:17 |
| phillw | skaet: but joking aside, what sort of (GMT) do you expect the RC's to land on http://iso.qa.ubuntu.com/qatracker ? | 19:18 |
| skaet | phillw, look at the times of the ones today landed, and should be the same torrow. | 19:19 |
| phillw | thanks, I'm GMT +5.5 over here, so time is a bit of a blur. | 19:19 |
| skaet | We have more bugs than I'd like though right now, so manual respins should be expected. | 19:20 |
| cjwatson | wubi upgrades have historically been a disaster, so (while I think we nailed most of the horrible ones a few cycles ago) I do think it's worth giving them some attention | 19:21 |
| balloons | ev skaet, so i instructed to grab and install 11.10 wubi and then attempt a normal dist-upgrade to 12.04 | 19:21 |
| cjwatson | yeah | 19:21 |
| balloons | and see if it boots :-0 | 19:21 |
| cjwatson | I don't care what the other packages do | 19:21 |
| phillw | okay, that was the start of my email to the lubuntu-qa team.... "they will arrive, when they arrive, owing to -release wanting to get as many bugs squashed as is humanly possible".... Is that okay with you skaet? | 19:23 |
| skaet | yup. fair 'nuf. | 19:23 |
| skaet | thanks phillw | 19:23 |
| phillw | skaet: they're nagging :P | 19:23 |
| skaet | phillw, feel free to encourage them to start on today's dailies, they're pretty close. | 19:24 |
| skaet | to what will be there tomorrow. | 19:24 |
| slangasek | how does this look? http://testcases.qa.ubuntu.com/Testing/Cases/WubiUpgrade | 19:27 |
| cjwatson | milestones created now | 19:27 |
| cjwatson | LGTM | 19:28 |
| skaet | thanks cjwatson | 19:28 |
| slangasek | balloons: ^^ if that description looks ok to you, I'll link it from the ISO tracker in place of what's currently there | 19:28 |
| balloons | looks much nicer than before | 19:28 |
| balloons | umm.. I was mentioning making some minor changes of your choice | 19:28 |
| balloons | for extra flavor during the upgrade :-0 | 19:28 |
| skaet | slangasek, looks good to me too. | 19:29 |
| balloons | change desktop background, install an extra package.. otherwise it's exactly the same | 19:29 |
| balloons | can you linky it? | 19:29 |
| balloons | I've sent the links to the testcase.. they should all see your new version | 19:29 |
| slangasek | testcase link fixed | 19:32 |
| slangasek | balloons: so for the Wubi upgrade test case, I think we specifically want to limit the variables and not encourage making changes as part of the testing; the more holistic testing of other images already gives us that, for Wubi I'd rather we be short and to the point given that it's a challenge to get testing done at all | 19:33 |
| balloons | slangasek, probably true | 19:34 |
| balloons | noted | 19:34 |
| slangasek | now for Wubi *install*, there are other paths worth testing | 19:34 |
| slangasek | because there could be flavor-specific install failures | 19:34 |
| slangasek | but the upgrade path, since what we care about is core common packages (kernel+grub), there's no sense throwing in sources of other possible bugs | 19:35 |
| balloons | slangasek, yes.. so it's a different case than normal upgrade testing | 19:35 |
| slangasek | stgraber: can you see any reason not to merge "Upgrade wubi i386" and "Upgrade wubi amd64" on the iso tracker? They each have a single test case, and they're the same .exe anyway | 19:38 |
| skaet | slangasek, stgraber - have added "Precise Pre-release" to the tracker, and updated nusakan to auto post to it. | 19:39 |
| slangasek | ok | 19:40 |
| skaet | stgraber, any problem if I do a test build and post images, while we still have the daily testing active? (I figured turn off the Precise Daily just before the cron kicks in so we get as many results gathered as we can. | 19:40 |
| slangasek | oh boo, stgraber is in the wrong timezone, guess I shouldn't expect a prompt reply and should just mangle the tracker horribly ;) | 19:41 |
| stgraber | skaet: if we publish a candidate now we might as well turn of the dailies | 19:41 |
| stgraber | skaet: as the dailies will have an older build | 19:41 |
| skaet | stgraber, ok, I'll hold off on testing. Was just wanting to see if server had issues with all the recent changes landing, we could sort before EOD. | 19:42 |
| * skaet wants to leave the dailies active until later. | 19:42 | |
| balloons | I have mentioned to everyone the dailies are live until tomorrow | 19:42 |
| balloons | they won't be expecting a switch until then | 19:43 |
| balloons | it would be good to leave them in place for now if possible | 19:43 |
| skaet | hmm... stgraber is it possible, or is it going to cause major issues with the database to have two milestones in testing. (ie. Daily and Pre-release) | 19:44 |
| skaet | ? | 19:44 |
| stgraber | skaet: two milestones marked as testing is fine, I'm just worried about the confusion it'd create to have some builds in the final milestone and some others in daily | 19:44 |
| skaet | no builds should be going to daily now. | 19:45 |
| slangasek | balloons: wubi testing is now a single "product" on the iso tracker, cf. http://iso.qa.ubuntu.com/qatracker/milestones/204/builds/15333/testcases | 19:45 |
| slangasek | with i386 and amd64 as test cases instead of as separate "products" 'cuz they aren't | 19:46 |
| balloons | slangasek, did you break any links? | 19:46 |
| skaet | we can turn off the daily after the publishing run tomorrow morning (your current time ;) ) and disable cron at that point. | 19:46 |
| slangasek | balloons: nope | 19:46 |
| skaet | that way, folks can keep adding results across the timezones, rather than waiting for the cron to publish. | 19:46 |
| balloons | ok good ;-) | 19:46 |
| stgraber | slangasek: sorry, was just about to tell you it'll be a bit of a mess to do that specific change ;) | 19:46 |
| slangasek | stgraber: doesn't look messy to me ;) | 19:46 |
| stgraber | slangasek: because renaming the i386 product and dropping amd64 will break the history | 19:47 |
| slangasek | well... I renamed the existing test case too | 19:47 |
| slangasek | so it shouldn't break history too badly | 19:47 |
| balloons | ahh I see slangasek .. yea, we can turn off the other links after today's daily | 19:47 |
| slangasek | it'll just change how it looks | 19:47 |
| balloons | no reason to have upgrade wubi i386/amd64 anymore | 19:47 |
| stgraber | slangasek: Sure but that just made it worse ;) if you now access the results from Oneiric, you'll see a Wubi product containing two test cases, only one of which has results and you'll see another Wubi amd64 product with a single testcase containing the remaining results | 19:48 |
| ScottK | I'm pretty sure reviewing Wubi test case results from Oneiric is not on anyone's high priority TODO list. | 19:50 |
| stgraber | ScottK: sure, but fixing the history later on will be even harder than fixing it now | 19:50 |
| stgraber | ScottK: that's why my suggestion would have been not to do the change in the UI and let me move the results properly in the DB :) | 19:51 |
| ScottK | Right. | 19:51 |
| slangasek | stgraber: you can still do that now, if you like, yes? | 19:51 |
| stgraber | slangasek: yeah, I'm trying to do that now | 19:52 |
| slangasek | ok | 19:52 |
| balloons | woot! a green label on wubi on the iso tracker | 20:06 |
| skaet | :) | 20:10 |
| stgraber | slangasek: done | 20:11 |
| slangasek | stgraber: cheers | 20:11 |
| slangasek | skaet: infinity's asked for an FFe to get the wubi fs image using ext4 instead of ext3; bug #859552 - this was blocked until this week by the livefs builders not having a new enough kernel to allow ext4 | 20:14 |
| ubot2 | Launchpad bug 859552 in live-build "[FFe] Wubi should use ext4 disk images" [Undecided,In progress] https://launchpad.net/bugs/859552 | 20:14 |
| slangasek | skaet: I think we should do this so it's consistent with the defaults elsewhere - and in light of the wubi community testing, the sooner the better | 20:14 |
| slangasek | balloons: ^^ | 20:14 |
| balloons | oh my | 20:15 |
| balloons | wow | 20:15 |
| balloons | SO late | 20:15 |
| slangasek | yes | 20:15 |
| infinity | Yep. | 20:15 |
| infinity | The timing wasn't my choice, really. :P | 20:16 |
| balloons | I don't see what we lose by staying with ext3? | 20:16 |
| slangasek | balloons: the only thing it changes is the filesystem... which should really be a pass/fail thing | 20:16 |
| * slangasek yields the floor to infinity | 20:16 | |
| balloons | yes.. and ext4 isn't really new anymore, most of it's craziness with data loss etc has been wrapped up for years now | 20:16 |
| * ScottK votes for wubi with btrfs. | 20:17 | |
| slangasek | wubtr | 20:17 |
| cjwatson | arwubtrf | 20:17 |
| * slangasek chokes | 20:17 | |
| slangasek | balloons: so am I reading you right that you think changing this now would make it a problem to get it re-tested? | 20:18 |
| slangasek | because if so, I think that's the nail in the coffin for .0 | 20:19 |
| infinity | I should hope not... | 20:19 |
| balloons | slangasek, I don't think it's a problem persay | 20:19 |
| slangasek | ok | 20:19 |
| infinity | If we can't retest wubi in the next week, we have bigger problems (like, if anything else changes) | 20:19 |
| balloons | but most of the testing we're doing today is with ext3 | 20:19 |
| balloons | that's all | 20:19 |
| balloons | :-) | 20:20 |
| infinity | balloons: Sure, but will you even notice the change? ;) | 20:20 |
| balloons | shouldn't nope | 20:20 |
| slangasek | balloons: as long as there are *some* people still willing to help (re)test late today or tomorrow, I think that would cover us | 20:20 |
| balloons | but i guess the testing won't be as crazy after this with wubi tis all | 20:20 |
| balloons | we'll have a good poke tomorrow | 20:20 |
| infinity | (As to "data loss crazines" and such, ext4 has been the default filesystem for all our other images for a long while... Which is the motivation to make wubi match; wubi's our only ext3 consumer, and it's a tiny subset) | 20:20 |
| balloons | so get it in by then :-) | 20:20 |
| slangasek | yeah, that's not a problem | 20:20 |
| slangasek | I think we can have the ext4 image rolled up in <1h | 20:21 |
| slangasek | infinity: is that right? | 20:21 |
| infinity | slangasek: Or 1.5... It takes an upload/build/publish-cycle, thanks to something being hardcoded in a live-build patch. | 20:21 |
| slangasek | ok | 20:21 |
| infinity | But after that, yeah, one quick revert on cdimage, and I can spin test images. | 20:21 |
| slangasek | balloons: so we can have the change in 2 hours, and can revert it in another 2 if need be | 20:21 |
| * infinity goes to find a coffee, so he can deliver on this. | 20:22 | |
| balloons | slangasek, so are we going to get a new wubi.exe? | 20:25 |
| slangasek | balloons: still waiting for skaet to comment | 20:26 |
| infinity | wubi.exe doesn't need to change. | 20:26 |
| infinity | Just the images. | 20:27 |
| slangasek | oh, right | 20:27 |
| slangasek | balloons: we will *hopefully* be getting a new wubi.exe as well, but definitely not today | 20:27 |
| infinity | (and not related to this) | 20:27 |
| slangasek | correct | 20:27 |
| slangasek | ev: was there a bug number for the autorun issue? | 20:28 |
| ev | slangasek: https://bugs.launchpad.net/wubi/+bug/985050 | 20:28 |
| balloons | so are the dailies getting vanquished early, or are we still ok? | 20:28 |
| ubot2 | Launchpad bug 985050 in ubuntu "A Downloaded Wubi binary shows the autorun menu if an Ubuntu cd is inserted" [High,New] | 20:28 |
| infinity | slangasek: Looks like it'll be livefs afternoon for me, sulfur's getting set up too. | 20:31 |
| slangasek | balloons: still ok | 20:31 |
| slangasek | infinity: alrighty :) | 20:31 |
| slangasek | bug #985190 | 20:35 |
| slangasek | boo | 20:35 |
| slangasek | hmm, no bugbot | 20:35 |
| slangasek | or none that loves me anyway | 20:35 |
| slangasek | oh, that plymouth crash is a drm crash - yaay, I can pass the buck ;) | 20:36 |
| infinity | Hahaha. | 20:36 |
| phillw | balloons: is release on tuesday or thursday of next week? | 20:46 |
| infinity | Thursday. | 20:47 |
| phillw | infinity: can you give balloons a reminder :P | 20:48 |
| balloons | infinity, phillw ? lol | 20:49 |
| balloons | did I say release was Tuesday? | 20:50 |
| balloons | if so -- tell me where, I've known it was thursday | 20:50 |
| phillw | balloons: just as well meeting was not cancelled... it is now D-Day minus one :) | 20:50 |
| balloons | that was a mistype :-) | 20:50 |
| balloons | ohh -- did I say it in the qa meeting? | 20:50 |
| * infinity should have made the wubi live-build hook autodetect targets, so he didn't have to upload a new version to change this. | 20:51 | |
| balloons | if so, it's on tape so to speak :-0 | 20:51 |
| phillw | yes, you did! | 20:51 |
| balloons | slangasek, http://testcases.qa.ubuntu.com/Install/DesktopWubi can you update this at all? it's pretty cd-centric | 20:51 |
| balloons | phillw, gotta watch this balloons guy | 20:51 |
| ev | right, wubi is fixed as http://people.canonical.com/~evand/wubi/precise/wubi-r265.exe | 20:52 |
| ScottK | doko: Here's a question for you: Why is /usr/bin/pyversions in python and /usr/share/python/pyversions.py and /usr/share/man/man1/pyversions.1.gz in python-minimal? It seems like /usr/bin/pyversions should be in minimal with them. | 20:53 |
| ev | skaet: ^ I've asked IS for it to be signed - that might have to wait until tomorrow when Spads is around | 20:53 |
| slangasek | ev: thanks | 20:53 |
| ev | as far as I can tell, that behaviour has been there for ages | 20:54 |
| ev | my initial suspicion that it was the result of my autorun fix was wrong | 20:54 |
| ev | slangasek: sure thing | 20:54 |
| slangasek | balloons: hmmm, better if someone who knows it better can edit that one | 20:54 |
| slangasek | balloons: though certainly the first test case there has become irrelevant because we no longer offer it from CD... | 20:55 |
| infinity | slangasek: Fresh live-build uploaded with the wubi/ext* revert/re-apply. Can be accepted once we have consensus, I guess. | 20:58 |
| infinity | (Or rejected, if not) | 20:58 |
| balloons | slangasek, yes, essentially the cd based ones can all be gutted right | 20:58 |
| doko | ScottK, hmm, don't know a reason, and I can't remember that this is intentional | 20:59 |
| balloons | does the cd boot helper still exist? is it possible? | 21:00 |
| slangasek | balloons: I don't know if it does or not... needs someone with Windows running to verify ;) | 21:01 |
| ScottK | doko: I can see some potential for race conditions when the two packages are in different states (I'm not sure). Is it worth changing? | 21:01 |
| balloons | slangasek, lolololol | 21:03 |
| doko | ScottK, I don't think so, but if you want, go ahead | 21:05 |
| ScottK | I won't mess with it for precise then. I'll do it in Debian. | 21:06 |
| ScottK | (then Ubuntu will get it in Q) | 21:06 |
| tyhicks | I've attached a simple debdiff to bug 935407 to fix the refpolicy-ubuntu (in universe) FTBFS on Precise. I think it is a good candidate for a FFe. | 21:10 |
| ubot2 | Launchpad bug 935407 in refpolicy-ubuntu "refpolicy-ubuntu version 0.2.20091117-0ubuntu1 FTBFS on i386 in precise" [High,In progress] https://launchpad.net/bugs/935407 | 21:10 |
| micahg | tyhicks: bug fixes don't need an FFe | 21:10 |
| tyhicks | micahg: Ah, thanks. I'll ping you privately for the next steps. | 21:11 |
| Laney | ^ FTBFS fix. Probably needs FFe. | 21:14 |
| infinity | skaet: Did you have an opinion on https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/859552 ? | 21:16 |
| ubot2 | Launchpad bug 859552 in live-build "[FFe] Wubi should use ext4 disk images" [Undecided,In progress] | 21:16 |
| === highvolt1ge is now known as highvoltage | ||
| infinity | Laney: That's quite a version bump for an FTBFS. Does it have impact on rdeps? | 21:16 |
| infinity | (does it have rdeps?) | 21:16 |
| infinity | I'm assuming from the package name that it does. :P | 21:16 |
| Laney | no, it's just a frontend to the cabal library | 21:17 |
| Laney | think gem | 21:17 |
| infinity | Ahh. | 21:17 |
| infinity | And eww. | 21:17 |
| Laney | yes | 21:17 |
| slangasek | gem, except written by someone who actually worked on a distribution | 21:17 |
| highvoltage | heh | 21:18 |
| * infinity wonders why the other language folks never got on board with the Debian/Perl ideal of "if it's in CPAN, and it's not in Debian, it's not worth using". | 21:18 | |
| Laney | ah, it will make haskell-platform uninstallable | 21:19 |
| * Laney fiddles in Debian | 21:19 | |
| ScottK | infinity: Python and Pypi seems to be getting there. | 21:20 |
| slangasek | doko: bug #983981> why would you assume the new python-minimal is unpacked at that point? | 21:25 |
| ubot2 | Launchpad bug 983981 in update-manager "Lucid -> Precise main failed to upgrade: ERROR: pycompile:Requested versions are not installed dpkg: error processing python2.7-minimal installed post-installation script returned error exit status 3" [High,New] https://launchpad.net/bugs/983981 | 21:25 |
| slangasek | doko: there's nothing in the python2.7-minimal dependencies that says python-minimal should be unpacked first | 21:26 |
| slangasek | doko: maybe python2.7-minimal needs a Breaks: python-minimal (<< $our_ver)? | 21:26 |
| ScottK | doko: I moved /usr/bin/pyversions to python-minimal in Debian. If you end up having to upload for that ^^^ then I would suggest doing the same for precise. | 21:31 |
| skaet | infinity, would prefer slangasek and ev weigh in. I want it in principle, but not sure we can react to making it happen in time. Want to make sure all the blockers are fixed first. | 22:07 |
| * skaet appologizes was otp | 22:07 | |
| slangasek | skaet: ev and I have weighed in already in favor, but wanted to make sure you were in the loop | 22:08 |
| infinity | skaet: slangasek and ev have both already weighed in. | 22:08 |
| infinity | What he said. ;) | 22:08 |
| slangasek | infinity: so go ahead, and coordinate with balloons wrt the timing | 22:08 |
| infinity | slangasek: Alright, accept my live-build upload, then? ;) | 22:08 |
| * infinity goes back to fiddling with nusakan and sulfur for now. | 22:09 | |
| slangasek | righto | 22:09 |
| skaet | slangasek, infinity, thanks for making sure I'm in the loop. :) | 22:12 |
| skaet | slangasek, did someoneles already accept the apport change? | 22:44 |
| * skaet not seeing in the scroll back?? | 22:44 | |
| slangasek | I don't know | 22:44 |
| skaet | its not on the queue... or I'm blind. | 22:45 |
| ScottK | In proposed? | 22:45 |
| slangasek | scrollback here tells me pitti rejected the upload to -release and re-sent it to -proposed | 22:45 |
| ScottK | There's an apport in proposed. | 22:45 |
| slangasek | yep | 22:45 |
| skaet | cool. Thanks! | 22:46 |
| * skaet accepting kerneloops | 22:46 | |
| skaet | slangasek, could you copy it into -release | 22:46 |
| skaet | ? | 22:46 |
| ScottK | ^^^ was due to FFe still in progress. | 22:47 |
| ScottK | You may see it again if we decide it's a good idea. | 22:47 |
| skaet | ack. | 22:47 |
| ScottK | Laney: ^^^ for the same reason. Until you're sure it's all sorted, I don't want it in queue and getting pushed through by mistake. | 22:48 |
| Laney | ScottK: I was just dputting a fakesync of the platform | 22:48 |
| * ScottK is looking at kubuntu-docs. | 22:48 | |
| Laney | maybe not fake sync, a --no-lp sync | 22:48 |
| ScottK | Laney: OK. We should be able to rescue it from rejected. | 22:48 |
| Laney | yeah. | 22:48 |
| skaet | infinity, could you take a look at the openssl one if you get a chance? | 22:49 |
| ScottK | Kubuntu images will need respins for kubuntu-docs if nothing else. | 22:50 |
| cjwatson | openssl is only for release if manual testing checks out in time. | 22:50 |
| cjwatson | But I uploaded it to -proposed and it should be able to go in there any time. | 22:51 |
| slangasek | skaet: apport copied | 22:51 |
| skaet | cjwatson, sorry - didn't see it on the wiki page. Adding it now. | 22:52 |
| ScottK | Laney: Accepted. | 22:52 |
| ScottK | (platform) | 22:52 |
| Laney | they both need to go in together ... | 22:52 |
| * Laney is just writing the FFe | 22:53 | |
| cjwatson | skaet: not sure I put it there, mentioned on IRC earlier | 22:53 |
| ScottK | Laney: FAILED: haskell-cabal-install (Can't resurrect rejected syncs) | 22:53 |
| infinity | skaet: On it. | 22:53 |
| ScottK | You'll need to sync it again. | 22:53 |
| Laney | hah | 22:54 |
| slangasek | infinity: see intervening discussion between cjwatson and skaet, openssl is not ready to be copied | 22:54 |
| skaet | cjwatson, IRC context fails with the volume of traffic, hence pad desire in first place. Sorry I missed it in the backscroll. | 22:54 |
| infinity | slangasek: No, but still ready to be built in proposed. | 22:54 |
| slangasek | oh | 22:54 |
| Laney | ScottK: coming up | 22:54 |
| infinity | slangasek: (Assuming it looks not broken) | 22:54 |
| Laney | and that is it for me — goodnight | 22:54 |
| slangasek | right, I misunderstood and thought it was already in proposed | 22:54 |
| infinity | Patches look sane. | 22:55 |
| skaet | good night Laney, sleep well. | 22:56 |
| cjwatson | slangasek: it's not in -proposed yet, no | 22:56 |
| infinity | cjwatson: Is now. | 22:56 |
| slangasek | :) | 22:57 |
| cjwatson | skaet: sure, I was acting with an ordinary developer hat on, not a release team hat on | 22:57 |
| skaet | :) | 22:57 |
| cjwatson | skaet: we don't expect developers to edit the pad AIUI | 22:57 |
| infinity | cjwatson: I'd say developers can certainly edit to say "Don't copy this without testing feedback" or other negative comments. | 22:58 |
| infinity | cjwatson: It's developers editing to encourage accepting things that would be a bit unfortunate. :P | 22:58 |
| slangasek | can but are not expected to | 22:58 |
| cjwatson | indeed | 22:59 |
| infinity | Oh, sure. | 22:59 |
| skaet | infinity, while I'm cleaning things up, python-defaults went in - yes? | 22:59 |
| infinity | skaet: Nope. it built everywhere, but it's still in -proposed. | 22:59 |
| infinity | There seemed to be some dissent among the ranks about what should happen to it. | 22:59 |
| ScottK | skaet: I thought it was waiting for doko to do a lucid upgrade test with it. | 23:00 |
| ScottK | (when last we discussed it) | 23:00 |
| skaet | Thanks ScottK - that was it. Long day | 23:00 |
| skaet | will update wiki to denote that. | 23:00 |
| slangasek | ^^ apt-setup accepted (discussed it with cjwatson already) | 23:03 |
| infinity | cjwatson: How many of the uncommitted changes in ~cdimage/cdimage are yours? I'm trying to tidy up a bit. | 23:14 |
| cjwatson | infinity: none of them are anything I remember clearly enough to give you a rationale for | 23:16 |
| cjwatson | not certain whether they're mine or not | 23:16 |
| infinity | cjwatson: I've backed out one that was vorlon testing things, and one that was me. | 23:16 |
| infinity | cjwatson: The rest seem like "if they work, they should probably be in bzr". Just trying to hunt down authors. :P | 23:16 |
| infinity | balloons: So... | 23:19 |
| infinity | balloons: wubi/ext4 ... Assuming it's cool with you, I'm going to spin up images somewhere in the area of "now", and make sure the builds go okay. | 23:20 |
| * skaet --> dinner, back to check on the cron builds later | 23:23 | |
| infinity | balloons: (Alternately, if you don't respond, I can probably safely assume you don't mind terribly if I do so while you're away) :P | 23:24 |
| skaet | infinity, I think he's away from terminal for a while | 23:26 |
| skaet | so go ahead. | 23:26 |
| cjwatson | I think I have a fix for bug 979350 now | 23:26 |
| ubot2 | Launchpad bug 979350 in ubiquity "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [High,Confirmed] https://launchpad.net/bugs/979350 | 23:26 |
| infinity | skaet: Oh, one more thing. If I take ownership of testing it, do you mind if I turn on ubuntu-core for powerpc, now that we have a faster PPC builder (it's a tiny/quick build anyway) | 23:27 |
| cjwatson | it only squeezes into memory if you don't run ubiquity from a live session | 23:27 |
| cjwatson | but given that constraint it seems to be working | 23:27 |
| infinity | cjwatson: So, it'll still fail is running from the desktop? | 23:28 |
| skaet | infinity, ok with it being in the dailies, but it hasn't participated in the betas, so shouldn't be part of release. | 23:28 |
| infinity | cjwatson: Is ubiquity smart enough to know if it's running under ubiquity-dm, and not offer options that might fail? ;) | 23:28 |
| cjwatson | infinity: it did in my tests, anyway | 23:28 |
| cjwatson | it doesn't have exact enough knowledge about memory constraints | 23:29 |
| infinity | skaet: It has, by virtue of being the base of everything else that's been in the betas. | 23:29 |
| cjwatson | One of the purposes of ubiquity-dm is to be a bit more memory-lean | 23:29 |
| * infinity nods. | 23:30 | |
| skaet | yeah, but not as its own image. From discussions earlier in the cycle it was agreed to ship, it must have been in a beta. | 23:32 |
| * skaet needs food.... l84 | 23:32 | |
| infinity | *sigh*... I won't enable it at all, then. Dailies are kinda pointless when they all get wiped out post-release. ;) | 23:33 |
| cjwatson | All due respect but this is a daft policy in this case. The Ubuntu Core "image" is a tarball ... | 23:35 |
| cjwatson | If tar is breaking we have bigger problems. | 23:35 |
| infinity | Indeed. | 23:37 |
| cjwatson | I agree that the policy makes sense in general; but this seems like a common-sense exception. | 23:37 |
| * ScottK votes the must be in the beta rule applies to images, not tarballs. | 23:37 | |
| * cjwatson tries this test again with a bug fixed so that it really enables the encrypted swap during installation. Not that it's vital, but it might let the test finish this century. | 23:55 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
