| infinity | cjwatson: Is there a reason your user-setup has been stuck in the queue for 8 hours, or has it just not had a review? | 00:56 |
|---|---|---|
| cjwatson | the latter, but it's about to have another upload anyway | 00:57 |
| cjwatson | soon as I've stopped mucking up the tests | 00:58 |
| infinity | Heh, kay. | 00:58 |
| cjwatson | and the one in the queue is actually wrong, it's passing the wrong args to mkswap/swapo | 00:58 |
| cjwatson | missing /dev/mapper/ | 00:58 |
| cjwatson | n | 00:58 |
| infinity | Ahh, there's not enough context in the diff to make that ovious. | 00:58 |
| infinity | Nor obvious. | 00:58 |
| infinity | In fact, I'm missing context entirely here, cause from the small bit above, it seems like you should just be mkswapping $device. | 00:59 |
| cjwatson | $device is the unencrypted one | 01:00 |
| cjwatson | /dev/mapper/$name is the encrypted one | 01:00 |
| infinity | Blowing away the physical volume backing an excrypted volume doesn't upset the higher level bits? | 01:00 |
| cjwatson | Nothing's doing anything withit yet | 01:01 |
| * infinity is woefully ignorant about how all this works, I guess. I would have assume magic blocks or something. | 01:01 | |
| infinity | s/assume/assumed/ | 01:01 |
| infinity | cjwatson: Well, yeah, it's obviously not mounted, I just meant "there's nothing actually there?" | 01:01 |
| infinity | Like, if this were a raid volume, "mkraid && zero physical && mkfs raid" would end badly. | 01:02 |
| cjwatson | ah, um, *cough*, I think something needs to call cryptsetup | 01:03 |
| cjwatson | sigh, this is going to be a late night isn't it | 01:03 |
| infinity | Maybe I should read the code instead of the 5 lines of context. ;) | 01:03 |
| cjwatson | it needs to be more like mkswap && cryptsetup && swapon | 01:03 |
| cjwatson | err | 01:03 |
| cjwatson | zero physical && cryptsetup && mkswap && swapon | 01:03 |
| infinity | zero && cryptsetup && mkswap && swapon | 01:04 |
| infinity | Yeah, that. ;) | 01:04 |
| infinity | cjwatson: I assume it's prohibitively expensive to zero the crypt device? | 01:08 |
| infinity | Cause that would actually be more secure. Encrypted zeroes would do a ton more unrecoverable damage to the underlying data. | 01:08 |
| cjwatson | Maybe I should be using cryptdisks.functions here. | 01:09 |
| cjwatson | AFAICT it's a myth that the kind of data you write makes any difference. | 01:09 |
| infinity | On magnetic media, it's fairly provable, isn't it? Writing pure zeroes can still keep the old ones ghosted. | 01:10 |
| cjwatson | There's an unclaimed prize for anyone who can actually do it. | 01:10 |
| infinity | Writing randomly doesn't eliminate ghosting, but it sure makes it tougher to figure out what's "old". | 01:10 |
| infinity | But this is probably NSA level recovery we're talking about, not average joe plugging in a hard drive and fishing. | 01:11 |
| infinity | Like, you'd have to tear apart the physical disks and examine them. | 01:11 |
| infinity | So, probably a non-issue. :P | 01:12 |
| cjwatson | There was a paper a few years ago which gave the probability of recovering any single bit as 56%. | 01:13 |
| infinity | That's bigger than zero! | 01:13 |
| infinity | And therefor, not in the realm of CSI image enhancement. | 01:13 |
| cjwatson | Now exponentiate ... | 01:13 |
| infinity | But more in the realm of "really, really hard". | 01:13 |
| cjwatson | Now where was the good article I found about this | 01:14 |
| infinity | I agree, in practice, however, that being anal about how you shred disks is probably pointless. | 01:14 |
| infinity | I just brought it up because I know there are anal people out there. :P | 01:14 |
| infinity | That said, those anal folks probably shred their disks before installing. | 01:14 |
| cjwatson | Possibly http://www.infosecisland.com/blogview/16130-The-Urban-Legend-of-Multipass-Hard-Disk-Overwrite.html | 01:15 |
| * infinity will read this when he's done with sulfur. | 01:16 | |
| cjwatson | the WRIG08 citation there (which I haven't followed) is summarised as "a single overwrite using an arbitrary data value will render the original data irretrievable even if MFM and STM techniques are employed" | 01:17 |
| infinity | lamont: Can you put openssl in precise-proposed through some abuse? I know you were one of the people who had previous issues. | 01:20 |
| infinity | cjwatson: Sure, but that "arbitrary" almost seems to imply random. | 01:20 |
| infinity | cjwatson: I'm not disputing that multipass is silly, I'm claiming that writing pure zeroes will leave obvious ghosting. That's simple electrical theory. | 01:21 |
| cjwatson | My reading of the summary is that no matter what value you pick the probability of recovering anything useful is negligible. | 01:22 |
| infinity | Hrm. There's no sane way to parallelise the livefs log mirroring without making the script a lot more clever. :/ | 01:30 |
| infinity | Oh, wait. It doesn't delete. I guess it doesn't need to be clever. | 01:31 |
| ScottK | Should the user-setup in the queue be rejected then? | 01:38 |
| cjwatson | yeah | 01:40 |
| skaet | infinity, am spotting most of the builds not working from the daily cron. Can you look into it? | 01:42 |
| skaet | srv/cdimage.ubuntu.com/bin/find-live-filesystem: 104: Syntax error: ")" unexpected (expecting ";;") | 01:42 |
| infinity | Woo. | 01:42 |
| infinity | Go me. | 01:42 |
| infinity | I tested buildlive, but not find-live. Fixing. :P | 01:42 |
| skaet | Thanks | 01:42 |
| infinity | Oh, lolz. | 01:43 |
| cjwatson | Heh, I was just fixing that | 01:43 |
| infinity | I beat you to it. :/ | 01:44 |
| infinity | Unless you found more than the 4 spots I missed? | 01:44 |
| cjwatson | nope | 01:44 |
| * cjwatson misses one checkbox and has to redo a ten-minute test | 01:46 | |
| cjwatson | gah | 01:46 |
| cjwatson | ^- reverts problem infinity spotted, introduces new paths which are a no-op without a ubiquity change to add a magic environment variable but are a prereq for fixing bug 979350 | 01:51 |
| ubot2 | Launchpad bug 979350 in ecryptfs-utils "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [Undecided,Fix released] https://launchpad.net/bugs/979350 | 01:51 |
| skaet | Riddell, ScottK, am still missing support timeframe for some of the Kubuntu images in the manifest. Could I get you to update please and signoff that the plubishing locations/etc. are correct. | 02:02 |
| skaet | https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest | 02:02 |
| infinity | skaet: Oh, did you catch backscroll, re: core? | 02:06 |
| infinity | skaet: http://paste.ubuntu.com/936297/ | 02:07 |
| infinity | Also, sulfur's alive as a 3rd PPC buildd. Should try to aim large/scary packages at it, as it's got twice the CPU power as the other two. | 02:08 |
| skaet | infinity, looking forward to seeing a speedup on those PPC builds. If I trigger some manual runs, will pull the timings | 02:09 |
| cjwatson | skaet: It's not a livefs builder. It turned out not to speed things up, unfortunately. | 02:10 |
| infinity | Yeah, what he said. | 02:10 |
| cjwatson | skaet: So infinity's made it another package builder instead, since it actually is faster at that. | 02:10 |
| infinity | I did test runs of sulfur against royal, and they both did ubuntu-live within ~30s of each other, so opted to make it a distro builder instead, where the CPU and RAM won't go to waste. | 02:10 |
| slangasek | rejecting that first user-setup that seems to have not actually been rejected yet | 02:10 |
| cjwatson | A disappointment, but there you go. | 02:10 |
| cjwatson | And a third package builder will certainly help in a number of cases. | 02:11 |
| slangasek | infinity: CPU and RAM> heh, but not enough to put the whole build on a ramdisk? | 02:11 |
| skaet | re: PowerPC core images - lets just look at it as an option for 12.10. Don't have a good feel there is demand/need for 12.04 and enough things broken I'd rather focus on getting fixed. | 02:12 |
| infinity | slangasek: Only 4G... Not sure what the biggest PPC image is, pre-compression, but I know that wouldn't cut it for x86. | 02:12 |
| * skaet looks at http://iso.qa.ubuntu.com/qatracker/milestones/204/builds/15572/testcases/1186/results/ | 02:12 | |
| infinity | skaet: It's a 7-char patch to a file I'm already looking at, and I'm committing my own time to "testing" (which for core, is about 30 seconds) it. | 02:13 |
| skaet | infinity, yes, but there is the tracking, documenting, etc. associated with it. Haven't heard who will use it either.... | 02:13 |
| infinity | Docume... What? | 02:14 |
| infinity | We have one doc for core, it's not per-arch. | 02:14 |
| skaet | UbuntuCore is a product set | 02:14 |
| infinity | Yes...? | 02:14 |
| skaet | whether it should be or not.... probably need revisiting | 02:14 |
| cjwatson | What's a "product set"? | 02:15 |
| infinity | As for "who would use it", it's the same group as use core for other arches. Which is "amost nobody, until someone realises they really, really want it." | 02:15 |
| skaet | What's on the manifest | 02:15 |
| skaet | is a product set in my mind. | 02:15 |
| skaet | https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest | 02:16 |
| skaet | There's already armel for 12.04 | 02:16 |
| cjwatson | I guess I'm not sure how that has any bearing on adding powerpc to it. | 02:16 |
| infinity | I would just add powerpc to the armel set there. And both should be unsupported, not 18 months. | 02:17 |
| infinity | And I should probably be the signoff for both, since I'll be the one testing them anyway. :P | 02:17 |
| skaet | Please go update it to mark it as unsupported | 02:17 |
| infinity | Will do. | 02:17 |
| slangasek | infinity: is bug #985258 something that warrants fixing? Smells like it might be a product of the preinstall images having a pre-populated apt cache | 02:17 |
| ubot2 | Launchpad bug 985258 in tasksel "[omap4] tasksel shows seeds unavailable in the preseed image" [Undecided,New] https://launchpad.net/bugs/985258 | 02:17 |
| infinity | If I accidentally misspell unsupported as "powerpc || unsupported", is that cool? ;) | 02:18 |
| infinity | slangasek: It's an involved fix. | 02:18 |
| infinity | slangasek: Honestly, I've heard not a single customer tell me that the preinstalled pool was useful to them, I'm almost tempted to just drop it and make the server image small. | 02:18 |
| skaet | infinity, find me someone who will use it, and then you can make your spelling mistake | 02:18 |
| infinity | slangasek: (Lots of people complain about the size, no one praises the package pool). | 02:19 |
| infinity | skaet: Me. | 02:19 |
| slangasek | infinity: it doesn't make sense for armel to be regarded as a community architecture when there's no community for it... we're carrying it for our own purposes | 02:19 |
| cjwatson | So these preinstalled images use oem-config for the "installation", right? Just trying to understand bug 985305 | 02:19 |
| ubot2 | Launchpad bug 985305 in ubiquity "[omap4] /etc/network/interfaces not created on a no-network installation" [High,New] https://launchpad.net/bugs/985305 | 02:19 |
| infinity | slangasek: There's actually a reasonably large community for it (though, true, I hope they all move to armhf some day) | 02:20 |
| slangasek | cjwatson: yes | 02:20 |
| skaet | infinity, but I know you can build it directly any time you need. ;) Someone else please. | 02:20 |
| infinity | skaet: I could build it on Canonical infrastructure, sure. A bit harder to build it locally when I'm suffering from chicken/egg issues of a machine that can't use installer/boot media and needs a rootfs to make a rootfs. | 02:22 |
| slangasek | infinity: there's a user community, but that's not what I mean; we kept armel as an arch for nefarious purposes, not due to community demand | 02:22 |
| jbicha | nefarious? | 02:23 |
| infinity | skaet: (This isn't theoretical, I just used a PPC rootfs to reinstall one of my systems yesterday, and I had to use a launchpad chroot tarball...) | 02:23 |
| slangasek | jbicha: best to assume everything involving ARM is nefarious, it's simpler that way ;) | 02:23 |
| infinity | slangasek: Sure. I'm not sure what we're arguing about, though. That we should list armel-core as supported? | 02:23 |
| slangasek | infinity: yah | 02:24 |
| infinity | Not everything "done by Canonical" is "supported", but alright. If you know something I don't about why we want to give core 18mo. :P | 02:24 |
| slangasek | I don't know anything you don't, just framing the question differently | 02:26 |
| cjwatson | bug 985280 - if this is release-critical then somebody with omap4 stuff set up is going to have to fix it | 02:28 |
| ubot2 | Launchpad bug 985280 in ubiquity "[omap4] Package installation completely fails silently if no network is available" [High,New] https://launchpad.net/bugs/985280 | 02:28 |
| slangasek | I'm skeptical of that being RC | 02:28 |
| slangasek | what kind of server has no network? | 02:29 |
| cjwatson | dunno, I said "if" :) | 02:29 |
| slangasek | yep :) | 02:29 |
| cjwatson | bug 985309 - how did this use to work? Was there some component that sorted out fstab? I don't think oem-config has ever done so | 02:29 |
| ubot2 | Launchpad bug 985309 in ubiquity "[omap4] /etc/fstab still has warning "UNCONFIGURED FSTAB FOR BASE SYSTEM", and is inconsistent with options" [Medium,New] https://launchpad.net/bugs/985309 | 02:29 |
| cjwatson | I vaguely recall some kind of refactoring ... | 02:30 |
| slangasek | infinity: how does the preinstalled package pool relate to tasksel showing tasks that aren't available? | 02:30 |
| cjwatson | I'm going to upload ubiquity now with user-setup 1.42ubuntu3 included, since I can't really wait any longer before bed, and it's closely tied up with a fix there | 02:30 |
| slangasek | ack | 02:31 |
| infinity | slangasek: Oh, erk, I only half-read the bug. It doesn't at all. | 02:31 |
| cjwatson | for source consistency, they should go together or not at all, although there's no run-time or build-time relationship | 02:31 |
| infinity | slangasek: Actually, I'm really confused by what's happening here at all. | 02:31 |
| slangasek | cjwatson: user-setup accepted now anyway | 02:32 |
| infinity | slangasek: He claims it's a server image. The server image has confusingly weird task issues (generally, the lack of tasks, not new ones) | 02:32 |
| cjwatson | thanks | 02:33 |
| cjwatson | kinda sounds like a missing apt-get update or something | 02:33 |
| infinity | slangasek: Right, so I re-read the bug. Basically, he's complaining that live images have the archive's Packages files. I'm having a hard time considering that a bug. | 02:35 |
| slangasek | don't we prune the archive's Package files from all the other live images? | 02:35 |
| slangasek | I thought we generally regard them as a waste of space until proven networked | 02:36 |
| slangasek | hmm, nope | 02:38 |
| slangasek | -rw-r--r-- 1 root root 8099662 Mar 24 22:43 /mnt/install/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise_main_binary-i386_Packages | 02:38 |
| slangasek | so yeah, that seems not-a-bug? | 02:38 |
| infinity | They may be a waste of space, but redownloading them is a waste of time and bandwidth. Take your pick. | 02:38 |
| slangasek | if you configure a different mirror than the default, it becomes a waste of all three ;) | 02:39 |
| slangasek | but yes | 02:39 |
| infinity | (And on a release image, they should be identical to the archive) | 02:39 |
| * slangasek nods | 02:39 | |
| infinity | Assuming no mirroring, yeah. | 02:39 |
| infinity | I dunno, cleaning those might be a good thing, but I don't want to know what breaks a week and a day before release. | 02:39 |
| infinity | We probably used to in the livecd-rootfs days. | 02:39 |
| slangasek | I'm not proposing that as a change now, no | 02:40 |
| infinity | Yeah, we cleaned those in livecd.sh. | 02:40 |
| slangasek | I was only asking about consistency with the other live images | 02:40 |
| infinity | So, another thing to look at "later". | 02:40 |
| infinity | But there's nothing inconsistent here, except that it's inconsistent with d-i images. | 02:40 |
| cjwatson | I think I explicitly talked about that during the switch to lb | 02:40 |
| infinity | Which is unavoidable, I imagine. | 02:40 |
| slangasek | cjwatson: as a feature or a bug? | 02:41 |
| cjwatson | feature | 02:41 |
| slangasek | ok | 02:41 |
| cjwatson | having trouble finding anything concrete though | 02:42 |
| cjwatson | Can't find it. Maybe it was a hallucination. | 02:44 |
| cjwatson | But I've a feeling that other space tradeoffs meant that live-build was still a space win, and that this meant software-center worked more gracefully. | 02:45 |
| cjwatson | Because it could display more things without needing an update first. | 02:45 |
| * slangasek nods | 02:45 | |
| infinity | Yeah, having things in s-c/apt-cache seems like a win. | 02:50 |
| infinity | And tasksel offering offline tasks is fine. | 02:50 |
| infinity | But the bug about tasksel silently pretending everything went fine when you have no network sounds like a legit bug. | 02:50 |
| cjwatson | Yes. | 02:59 |
| slangasek | ubiquity accepted | 03:11 |
| ScottK | skaet: I'm not sure I know all the answers. I'll try to confer with Riddell on it tomorrow. | 03:15 |
| skaet | thanks. :) | 03:17 |
| ScottK | skaet: It seems likely that we'll have some significant post-release updates to improve how Kubuntu Active is working. I'd like to ask to get Kubuntu Active done for 12.04.1 as well even though it's not LTS. We did it similarly for Kubuntu Netbook for 10.04.1 and we have testers. | 03:32 |
| ScottK | Riddell: ^^^ | 03:32 |
| slangasek | infinity: did wubi happen? | 03:35 |
| slangasek | infinity: doesn't seem to've, I don't see anything new in wubi/ | 03:35 |
| infinity | slangasek: Oh, I can spin it now. | 03:36 |
| slangasek | thanks | 03:36 |
| slangasek | want to make sure that's ready for balloons' testers | 03:36 |
| infinity | slangasek: Though, it dailifies in 3.5 hours. | 03:36 |
| infinity | Unless we're turning off cron before then. | 03:37 |
| balloons | slangasek, fyi.. 4 reported good on iso tracker I see | 03:37 |
| infinity | (I should spin a test build anyway) | 03:37 |
| balloons | for wubi | 03:37 |
| slangasek | balloons: cool | 03:37 |
| slangasek | infinity: I'd do it now anyway, so anyone testing gets the new one | 03:37 |
| infinity | slangasek: Check. Doing. | 03:38 |
| infinity | ... and this is where I find out that kapok and cadamom still don't support ext4, just wait for it. | 03:42 |
| infinity | ^-- slangasek, balloons | 04:25 |
| slangasek | infinity: could you escort that over to 'daily' by hand from 'pre-release', so that the testers are going to find it? | 04:25 |
| infinity | slangasek: Err, oh, we're mangled out publishing? I missed that memo. | 04:26 |
| infinity | Oh, just the iso tracker. | 04:26 |
| infinity | Right. | 04:26 |
| slangasek | yes | 04:26 |
| slangasek | doko_: in case you didn't know already, the architecture changes for bug #934593 are insufficient to make python-dev usable for cross-building | 04:31 |
| ubot2 | Launchpad bug 934593 in python-defaults "python-all-dev, python-dev must be Arch: any for multiarch" [Medium,Fix committed] https://launchpad.net/bugs/934593 | 04:31 |
| slangasek | doko_: doesn't hurt to have them Arch: any though, and that needs to be done eventually... so the main thing is to ensure we've got proper upgrades from lucid | 04:31 |
| ScottK | ^^^ was me. | 04:32 |
| ScottK | I shouldn't have synced it (didn't realize it was seeded) | 04:33 |
| ScottK | slangasek: We also need to do something to provide /usr/bin/python2 since doko removed it from python2.7 (where upstream provides it) with the intent to provide it from python-defaults. | 04:34 |
| micahg | ScottK: thanks for that :), it's not needed anyways | 04:34 |
| ScottK | (yes, which I also failed to check) | 04:34 |
| * micahg should've commented on the RC page | 04:34 | |
| * micahg does that now | 04:34 | |
| slangasek | ScottK: that's the relevant part of the python-defaults in -proposed | 04:34 |
| ScottK | It's marked not important already, but if you'd fix the comment, that would be good. | 04:34 |
| micahg | ScottK: I don't think I can | 04:35 |
| slangasek | ScottK: so if someone verifies that it upgrades cleanly from lucid, I'll happily copy that to -release | 04:35 |
| ScottK | slangasek: There's also the bug you assigned to doko dealing with having the new pycompile available. | 04:35 |
| ScottK | IIRC doko was going to do that. | 04:35 |
| micahg | ScottK: without bugging someone to run SQL, won't matter anyways as we have no diff | 04:35 |
| slangasek | yeah; that one appears to need a python2.7 upload though | 04:35 |
| ScottK | slangasek: Are we getting to the point where I should start leaving one unseeded package in queue to stimulate a publisher run if needed? | 04:36 |
| slangasek | hmm, I'm not sure if that's still needed | 04:37 |
| ScottK | OK. | 04:37 |
| slangasek | cjwatson: ^^ how much have your publisher changes from this cycle made this a non-issue? | 04:37 |
| ScottK | It'd be good to know. | 04:37 |
| ScottK | I'll leave accerciser there for now in case. | 04:37 |
| ScottK | Time for me to go to sleep. | 04:37 |
| infinity | The last run didn't publish any binaries, but still updated all the metadata. | 04:39 |
| infinity | Did this really not work in the past? | 04:39 |
| slangasek | yes, it really didn't | 04:39 |
| infinity | Oh, wait, no. I lied. | 04:39 |
| infinity | It still doesn.t | 04:39 |
| slangasek | ok | 04:39 |
| infinity | It generated some random uninteresting metadata. :P | 04:39 |
| slangasek | then the only improvement is that we only need one package instead of two :) | 04:39 |
| infinity | ... and I have no idea why. | 04:39 |
| infinity | It should be borderline trivial to just make it unconditionally regenerate for devel/frozen releases. | 04:41 |
| infinity | Then again, a lot of things that should be trivial in soyuz turn out not to be.... | 04:44 |
| pitti | Good morning | 04:48 |
| pitti | skaet: apport> see wiki, I found that this is quicker (and it could already build) | 04:49 |
| * infinity rearranges arm image builders again to account for timings of certain arches. | 04:52 | |
| * pitti wonders what we'll do with the remaining uploads now -- can we still accept good ones, or is everything going to be an SRU now? | 05:06 | |
| slangasek | that's meant to be taken case-by-case, surely? | 05:07 |
| pitti | of course, but I'm still unsure how strict skaet wants to take the "yesterday's images are candidates" | 05:10 |
| pitti | for example, the indicator-datetime fix looks perfectly reasonable | 05:11 |
| micahg | can someone look at the cairo-dock-plug-ins upload? it fixes an upgrade | 05:11 |
| pitti | libnfsidmap, too | 05:11 |
| infinity | pitti: We might be entering the "queue up reasonable updates, and accept them with urgent ones" phase. | 05:11 |
| pitti | *nod* | 05:12 |
| infinity | pitti: Where I'm sure indicator-datetime will probably get in anyway, but best to make sure it's getting in with something more awesome. :P | 05:12 |
| slangasek | pitti: yesterday's images aren't candidates, though | 05:25 |
| slangasek | apport was accepted in the past 24h | 05:25 |
| pitti | slangasek: ah, I thought skaet wanted to spin images in her evening | 05:46 |
| pitti | but seems she didn't | 05:46 |
| slangasek | I believe they've been left to be done by the cronjob | 05:46 |
| slangasek | pitti: anyway, there's a ubiquity in -proposed right now, so real candidates should certainly wait until we publish that... so if you think some stuff in the queue is borderline on whether it would block the release, now's probably a good time to accept | 05:49 |
| pitti | indicator-datetime and libnfsidmap both look good to me | 05:49 |
| pitti | slangasek: do you know the current status of python-defaults? | 05:50 |
| slangasek | pitti: someone needs to do an upgrade test with it; but that's somewhat blocked right now by bug #983981 | 05:52 |
| ubot2 | Launchpad bug 983981 in python2.7 "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,Triaged] https://launchpad.net/bugs/983981 | 05:52 |
| slangasek | ubiquity published | 05:54 |
| pitti | should we push openssl, too? or keep for SRU? | 05:55 |
| slangasek | see the pad | 05:55 |
| slangasek | er, the wiki | 05:55 |
| slangasek | https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus | 05:55 |
| pitti | right | 05:55 |
| micahg | do we have any need for gcc-4.7 patches in precise? | 06:13 |
| pitti | micahg: at this point IMHO they pose more risk than good | 06:28 |
| micahg | pitti: figured as much, thanks | 06:29 |
| micahg | pitti: do manpage updates qualify for SRUs? | 06:49 |
| pitti | micahg: fine for me | 06:49 |
| micahg | it's for mountall :) | 06:50 |
| micahg | https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/100305 | 06:50 |
| micahg | pitti: ^^ if that's ok, can I upload now to -proposed or should I just leave a note to upload after release? | 06:52 |
| pitti | micahg: it's ok to upload to -proposed now | 06:52 |
| micahg | k, thanks | 06:52 |
| micahg | pitti: wait, that'll be an SRU then, right? | 06:54 |
| * micahg wants to know whether or not to open a bug task :) | 06:54 | |
| pitti | yes, isn't that what you asked about? | 06:54 |
| pitti | right, you'll need a bug to track it | 06:54 |
| micahg | it has a bug, I'll take care of it, thanks | 06:55 |
| micahg | do we need UIFe's post release for SRUs? | 07:30 |
| Riddell | micahg: yes, same rationale as before release | 07:34 |
| pitti | micahg: yes, feature and UI freeze are never lifted again | 07:34 |
| micahg | ok | 07:34 |
| stgraber | good morning | 07:39 |
| * micahg wonders why the casper bzr history is weird | 07:49 | |
| * infinity grumps at https://bugs.launchpad.net/ubuntu/+source/apt/+bug/985452 | 07:50 | |
| ubot2 | Launchpad bug 985452 in apt "apt-ftparchive fails on scanning large repositories" [Critical,New] | 07:50 |
| stgraber | micahg: can you define "weird"? | 08:01 |
| stgraber | micahg: I think I'm touched-it-last, so I'm interested ;) | 08:02 |
| micahg | stgraber: http://paste.ubuntu.com/936574/ | 08:02 |
| micahg | stgraber: let's move this to -devel | 08:02 |
| Cimi | pitti, ping | 08:38 |
| pitti | hello Cimi | 08:38 |
| Cimi | ciao Martin | 08:38 |
| Cimi | there's a regression in unity 5.10.0 which causes a slow slow dash, especially fullscreen | 08:39 |
| pitti | right, I saw the discussion in scrollback | 08:39 |
| Cimi | ok | 08:39 |
| pitti | I thought it was already settled for SRU? | 08:40 |
| Cimi | yes | 08:40 |
| pitti | I don't see why it shouldn't be fixed, there will certainly be more fixes to Unity anyway | 08:40 |
| Cimi | but after seeing the regression live, I thought this should have been in 12.04 not in the SRU | 08:40 |
| Cimi | the fix is again a revert of the broken commit | 08:40 |
| Cimi | and a queue_draw on the right widget | 08:41 |
| pitti | the first time you open the dash it indeed takes very long, but that's hardly new? | 08:41 |
| Cimi | can be related to this bug as well | 08:41 |
| pitti | it's been like that since natty at least | 08:41 |
| Cimi | surely with this bug takes _longer_ than it should | 08:42 |
| Riddell | pitti: calligra-l10n in unapproved for your reviewing pleasure if you can | 08:43 |
| Cimi | pitti, this is the commit I'd definitely cherry-pick https://code.launchpad.net/~andyrock/unity/fix-980924/+merge/102200 | 08:43 |
| pitti | Riddell: AFAICS it's not on any image? (at least that's what seeded-in-ubuntu says, just in "supported") | 08:43 |
| Riddell | pitti: well next step is to get the language-pack-kde-xx to depend on calligra-l10n-xx | 08:44 |
| Riddell | so it will be after next language pack update | 08:44 |
| pitti | Riddell: NB that we don't add dependencies to langpacks usually, we have this handled by check-language-support | 08:44 |
| pitti | like libreoffice-l10n-* and friends | 08:45 |
| Riddell | or that yes | 08:45 |
| pitti | Riddell: is there a libcalligra or calligra-common or some appropriate "trigger" package which should cause c-l10n-* to be installed? | 08:46 |
| pitti | Riddell: oh, calligra-libs ? | 08:46 |
| Riddell | pitti: yes calligra-libs | 08:46 |
| pitti | Riddell: ah, we already have it | 08:47 |
| pitti | tr::calligra-libs:calligra-l10n- | 08:47 |
| Riddell | oh ok, cool | 08:47 |
| pitti | ^ /usr/share/language-selector/data/pkg_depends | 08:47 |
| pitti | Riddell: kubuntu-meta will mean a respin, you'll take the bullets? | 08:48 |
| ev | skaet: signed and fixed wubi is in place | 08:48 |
| pitti | skaet's upload blocker might not apply to derivatives | 08:49 |
| Riddell | pitti: should be fine, we have no test results anyway | 08:49 |
| pitti | Riddell: ok, please mark images for rebuild | 08:49 |
| Riddell | voila | 08:51 |
| Cimi | pitti, ping me back when you have finished with kde | 08:56 |
| pitti | Cimi: I have | 08:56 |
| Cimi | cool :) | 08:56 |
| pitti | Cimi: so, it seems fine to upload to -proposed now and have a 0-day SRU | 08:57 |
| pitti | then it can already be built, etc. | 08:57 |
| Cimi | pitti, I think this is not a SRU | 08:57 |
| pitti | if we will have a rebuild, there is a chance to pick it up into the release, but that needs to get past skaet | 08:57 |
| Cimi | it should be in the precise package | 08:57 |
| pitti | Cimi: well, it needs to go via -proposed either way | 08:57 |
| Cimi | I know, so what do I need to do now? | 08:58 |
| pitti | as we build everything non-arch-all in the staging area | 08:58 |
| Cimi | wait kate? | 08:58 |
| pitti | as I said, you can prepare the upload with didrocks | 08:58 |
| pitti | (NB that it needs a linked bug in teh changelog) | 08:58 |
| pitti | and we can accept it already | 08:58 |
| pitti | then you can try and talk skaet into moving it to -release when we do another respin | 08:58 |
| pitti | but that'll be a lot easier than uploading it at that point | 08:59 |
| pitti | and in -proposed it can also be more easily tested in a live system | 08:59 |
| Cimi | ok, thanks for exaplaining | 08:59 |
| didrocks | I don't really have the time to deal with this one now. I'm not really happy as well as this was due to a late merge in 5.10 for changing some design thingy | 09:00 |
| pitti | which once again proves why these late requests shouldn't be done :) | 09:00 |
| didrocks | I agree and that's what I'm trying to prevent since Tuesday :) | 09:01 |
| Cimi | didrocks, it won't be like that next cycle | 09:01 |
| stgraber | can I get a respin of Edubuntu? our last build failed because of infinity ;) | 09:01 |
| didrocks | especially that this was past unnoticed from 2 weeks of testing, and it's just a perf regression in the dash for 2 weeks | 09:01 |
| didrocks | Cimi: don't promess such things :) | 09:01 |
| Cimi | didrocks, I wouldn't really care that much if that was not such an important LTS | 09:02 |
| didrocks | so as it took 2 weeks of noticing it, I still think that it doesn't worth the risk | 09:02 |
| didrocks | can be fixed in a SRU | 09:02 |
| Cimi | didrocks, SRU would be fine for another release, but this is an LTS | 09:02 |
| didrocks | after a proper week of testing | 09:02 |
| Cimi | didrocks, it took 1 or 2 days for noticing | 09:02 |
| didrocks | Cimi: I personnaly have work to do now | 09:03 |
| Cimi | didrocks, I will create a branch for you | 09:03 |
| didrocks | not again arguing on yet another issue that is not important enough IMHO | 09:03 |
| didrocks | Cimi: no | 09:03 |
| didrocks | Cimi: I don't have the time to build it and again, won't sponsor something I'm not confident | 09:03 |
| Riddell | stgraber: I can do that | 09:03 |
| didrocks | I want a week of testing first | 09:03 |
| didrocks | as it took 2 weeks for you to notice the slowliness | 09:03 |
| Cimi | didrocks, you had months, this commit is a *revert* | 09:03 |
| Riddell | stgraber: Edubuntu isn't in the iso tracker for "Precise Pre-release" is that just a box that needs ticked somewhere? | 09:03 |
| didrocks | Cimi: it's not | 09:03 |
| Cimi | it is | 09:04 |
| didrocks | Cimi: no | 09:04 |
| didrocks | Cimi: see the merge proposal | 09:04 |
| didrocks | there is still a new fix | 09:04 |
| Cimi | https://code.launchpad.net/~unity-team/unity/unity.fix-bottom-right-dash-decoration-corner | 09:04 |
| Cimi | revert of that | 09:04 |
| pitti | at least from here it doesn't look much differetn performance-wise | 09:04 |
| Cimi | plus removed queue_draw | 09:04 |
| didrocks | pitti: agreed | 09:04 |
| pitti | the dash has always taken very long to open the first time | 09:04 |
| didrocks | yeah, same here | 09:04 |
| pitti | (and yes, that's very confusing) | 09:04 |
| Cimi | pitti, open the dash fullscreen | 09:04 |
| pitti | so if we can fix it, I'm all for it | 09:04 |
| Riddell | Edubuntu rebuilding | 09:04 |
| pitti | Cimi: how do I do that? | 09:04 |
| didrocks | pitti: it won't change the perf you experience before 5.10 | 09:05 |
| Cimi | pitti, top left | 09:05 |
| didrocks | experienced* | 09:05 |
| Cimi | didrocks, what are you saying | 09:05 |
| Cimi | didrocks, it's a commit in 5.10.0 | 09:05 |
| pitti | Cimi: ah, the maximize button -- didn't know that this worked | 09:05 |
| didrocks | right | 09:05 |
| didrocks | but | 09:05 |
| didrocks | the revert as another fix | 09:05 |
| didrocks | has* | 09:05 |
| Cimi | the glitch is that in 5.10.0 the dash is *constantly redrawing* | 09:05 |
| pitti | maximizing dash is basically instant here | 09:05 |
| Cimi | on my macbook air (1000$), is *slow* | 09:06 |
| didrocks | and this can be fixed in a SRU | 09:06 |
| Cimi | pitti, move between items, or lenses | 09:06 |
| Cimi | pitti, it's a bit sluggish | 09:06 |
| pitti | I see some flicker there, yes | 09:06 |
| Cimi | pitti, do you have a good computer? | 09:06 |
| didrocks | Cimi: can I argue that on my computer it already took more than 6 seconds for the dash to show? | 09:06 |
| pitti | Cimi: yes, I think so; ThinkPad X201, quad-core i5 | 09:06 |
| didrocks | Cimi: so we shouldn't release because of that? | 09:07 |
| Cimi | pitti, imagine on slower machines, it's worse | 09:07 |
| pitti | and still it takes some 5 seconds to open the dash first time | 09:07 |
| Cimi | didrocks, we should fix | 09:07 |
| stgraber | Riddell: it'll appear on the tracker with the first build | 09:07 |
| didrocks | Cimi: so blocking the release? because it's a LTS? | 09:07 |
| Cimi | didrocks, we have a safe fix | 09:07 |
| didrocks | Cimi: this won't fix my 6 seconds issue everytime I open the dash | 09:07 |
| Cimi | didrocks, but will improve at least | 09:07 |
| didrocks | Cimi: and what Mirco did and that you approve was a "safe fix" | 09:07 |
| Cimi | didrocks, because it asks less redraws | 09:07 |
| didrocks | not in any noticeable manner | 09:08 |
| Cimi | didrocks, the difference is that *I* approved | 09:08 |
| Cimi | didrocks, while this *gord approved* | 09:08 |
| didrocks | still, it took 2 weeks for you to notice it | 09:08 |
| Cimi | and marco | 09:08 |
| Cimi | and andyrock | 09:08 |
| didrocks | and nobody reported sluginess | 09:08 |
| didrocks | no bug report | 09:08 |
| Cimi | didrocks, no no no | 09:08 |
| Cimi | they did :) | 09:08 |
| Cimi | on monday | 09:08 |
| Cimi | mhr3 | 09:08 |
| didrocks | Cimi: ? can you point me on it? | 09:08 |
| didrocks | Cimi: I meant, users | 09:09 |
| Cimi | ask him | 09:09 |
| Cimi | didrocks, it was easter | 09:09 |
| Cimi | didrocks, I didn't really played with it | 09:09 |
| didrocks | Cimi: we got a week of testing, and it's a week since this version is released in precise | 09:10 |
| Cimi | didrocks, omer did notice a slowdown | 09:10 |
| didrocks | SRU-0 seems still fine to me | 09:10 |
| Cimi | andyrock did as well | 09:10 |
| Cimi | a still lot of people don't upgrade | 09:10 |
| didrocks | 11:10:56 mhr3 | Cimi, not really, i just saw it's repainting all the time, it didn't really feel like it's much slower though | 09:11 |
| didrocks | doesn't seem to impact him then ^ | 09:11 |
| Cimi | didrocks, read below | 09:11 |
| pitti | so, given how the last "urgent last fix" broke this in the first place, and I prefer a known small regression over an unknown one, I think it's totally fine to just wrap this into the next regular SRU | 09:12 |
| pitti | so I agree with skaet and didrocks here | 09:12 |
| Cimi | pitti, didrocks only quoted part of what that guy said | 09:13 |
| didrocks | Cimi: what? | 09:13 |
| Cimi | pitti, that guy has an nvidia card, rendering is so fast he can't spot difference in speed | 09:13 |
| didrocks | so that's the "don't count"? | 09:13 |
| Cimi | pitti, intel cards are affected | 09:13 |
| pitti | I have intel here | 09:13 |
| Cimi | especially not the newest | 09:13 |
| didrocks | I just pasted what was told at the *same time* | 09:13 |
| pitti | I'm not denying it's a regression and a problem | 09:14 |
| didrocks | Cimi: stop making accusation, this really isn't the positive way, and still won't help | 09:14 |
| pitti | I'm saying the benefit/risk ratio is not nearly high enough to warrant squeezing this into final | 09:14 |
| stgraber | pitti: hmm, so if we want real RC today, I guess I should upload base-files? it's marked as release - 3 days on the wiki but without it, we don't have actual RC images... | 09:14 |
| Cimi | pitti, it's a revert, risk is 0... | 09:14 |
| didrocks | agreed with pitti, what I'm trying to argue with him since the other day | 09:15 |
| pitti | stgraber: yes, I agree | 09:15 |
| Cimi | high benefit / 0 = infinite | 09:15 |
| pitti | except that the risk is never 0 | 09:15 |
| Cimi | infinite ratio :) !! | 09:15 |
| pitti | and there was a reason for introducing the patch in the first place, so you'll rip something else open again | 09:15 |
| pitti | mvo: ^ err... | 09:16 |
| pitti | mvo: can this please go to -proposed? | 09:16 |
| Cimi | pitti, I read code and I know what stuff did and why was done in that way, so I am absolutely confident of this commit so unity developers are | 09:17 |
| Cimi | at the same time, I learnt how SRU, even 0, are useless for our target | 09:17 |
| Cimi | people don't really upgrade as we do, new users don't care of upgrades | 09:17 |
| Cimi | they just install, test, slow -> drop | 09:18 |
| stgraber | pitti: uploaded | 09:19 |
| Cimi | especially Windows users see upgrades like they were "security fixes" for windows (windows update), I have seen friends and my parents not upgrading because they were thinking it only would caused problems | 09:19 |
| Cimi | for an LTS, delivering a smooth experience in the cd is absolutely crucial | 09:19 |
| stgraber | pitti: I guess we'll update everything for the Q codename as SRU then ... unless sabdfl feels like blogging real soon... | 09:20 |
| pitti | stgraber: yeah, at this point we can't update vim and friends any more, too intrusive | 09:20 |
| Cimi | on unity, we aren't because of a regression, but we have a safe fix now | 09:20 |
| pitti | stgraber: even lintian is on ubuntu-server and kubuntu for some reason | 09:21 |
| micahg | pitti: for Q we can make that all use distro-info :) | 09:21 |
| mvo | pitti: sure | 09:21 |
| mvo | pitti: please reject and I will re-upload to proposed | 09:21 |
| pitti | mvo: done, thanks | 09:21 |
| Cimi | pitti, didrocks: did you read what I mean? | 09:22 |
| pitti | Cimi: yes, I did | 09:22 |
| didrocks | Cimi: I read it | 09:22 |
| Cimi | I think we are underestimating the problem, SRU is not a solution | 09:23 |
| pitti | but what shall I say, I can't magically make it appear in precise-proposed, I stated my opinion, and I don't want to second- and third-guess didrocks and skaet | 09:23 |
| pitti | the installer fetches updates, and we offer to install them; if SRUs were pointless, we wouldn't need to do them, and given how many people even respond to SRU bugs they clearly are useful | 09:24 |
| pitti | and the SRUs will be wrapped into 12.04.x, too | 09:24 |
| pitti | so eventually they will all go into the official media | 09:24 |
| Cimi | pitti, we are targeting to a wider audience | 09:24 |
| Cimi | pitti, audience which I think, won't install upgrades as we do | 09:25 |
| Cimi | and we are forgetting all people from India without network | 09:26 |
| Cimi | and other countries | 09:26 |
| Cimi | where only the official media matters | 09:26 |
| seb128 | Cimi, somewhat the people who want a rocking stable lts will wait 12.04.1 anyway and have updated medias | 09:26 |
| pitti | well, again -- before it is even _possible_ to consider this, this needs an upload | 09:26 |
| Cimi | seb128, these are not our target, we are targeting to *new users*, not experienced users who know that ubuntu will release a 12.04.1 | 09:27 |
| Cimi | users see the new version and just download it | 09:27 |
| Cimi | pitti, I need a sponsor then, will see if someone is keen to support a proposed package I'll build | 09:27 |
| Cimi | pitti, and I will make sure skaet approves | 09:28 |
| didrocks | I just want to underline that the fix is *not* a revert, it introduce a new call for redraw | 09:28 |
| didrocks | compare https://code.launchpad.net/~andyrock/unity/fix-980924/+merge/102200 and https://code.launchpad.net/~unity-team/unity/unity.fix-bottom-right-dash-decoration-corner/+merge/101089 | 09:28 |
| Cimi | didrocks, before we were drawing the focus on the lens bar, now it is drawn on the icons of the lens bar | 09:29 |
| didrocks | Cimi: so, it's not a "revert" as you told more than once | 09:29 |
| Cimi | didrocks, thus andy removed all the redrawings of the lens bar, and added a queue_draw to the icon | 09:29 |
| Cimi | didrocks, it's a revert plus removing useless calls | 09:29 |
| Cimi | and calling the redraw to the right widget | 09:30 |
| didrocks | and adding some calls | 09:30 |
| didrocks | so please don't change the reality | 09:30 |
| Cimi | one call, not "some" | 09:30 |
| didrocks | and again, I remind you that was a late change on Friday before closing 5.10. a "safe" one | 09:30 |
| didrocks | and it's not impacting everyone, and it's fixable in a SRU, and it's not making the product useless | 09:31 |
| didrocks | so I made my point after too much discussion already and still against it | 09:31 |
| Cimi | didrocks, we are on a totally different wavelength | 09:31 |
| Cimi | didrocks, since you being the sponsor, I can't really get this in 12.04 | 09:32 |
| didrocks | now call who you want again, but keep pushing when 3 people: 2 members of the release team and the stack holder tells "no", you should listen to them | 09:32 |
| Cimi | didrocks, I think this time you are wrong, but I will stop discussing | 09:32 |
| didrocks | thanks :) | 09:32 |
| Cimi | didrocks, who are the two members saying no? | 09:32 |
| didrocks | skaet and pitti? see above | 09:32 |
| Cimi | didrocks, skaet didn't reply | 09:33 |
| didrocks | she told me that she answered no to it | 09:33 |
| Cimi | didrocks, pitti asked to propose the package before | 09:33 |
| Cimi | didrocks, when? | 09:33 |
| Cimi | she's not here now | 09:33 |
| didrocks | 11:12:07 pitti | so, given how the last "urgent last fix" broke this in the first place, and I prefer a known small regression over an unknown one, I think it's totally fine to just wrap this into the nex regular SRU | 09:33 |
| didrocks | on that channel | 09:33 |
| didrocks | Cimi: yesterday? when you started this discussion? | 09:33 |
| Cimi | didrocks, maybe I was offline? | 09:34 |
| didrocks | I don't think so | 09:34 |
| didrocks | but again, no need for further discussion, I have work to do | 09:34 |
| Cimi | I will speak again with skaet | 09:35 |
| * stgraber points the auto upgrade tester to the pre-release milestone | 09:35 | |
| Cimi | I guess it was a misunderstanding | 09:35 |
| Adri2000 | I think the README.files in the cloud tarballs has a mistake | 09:53 |
| Adri2000 | for the .img file, it says "It can be bundled, uploaded and registered to EC2 or UEC as a Amazon Machine Image (aki/eki)." | 09:53 |
| Adri2000 | should be ami/emi | 09:54 |
| ogra_ | is there a reason why none of the arm desktop images show up on the tracker ? | 09:54 |
| ogra_ | (i see them in daily but not in pre-release) | 09:54 |
| cjwatson | slangasek,ScottK: my attempt to move germinate handling into the database failed - it turned out to be much too slow, and I didn't have time to figure out how to make it faster - so that hack is as relevant as it ever was | 10:10 |
| cjwatson | slangasek,ScottK: that said, don't sweat too much over it; things like changing a package's section override would also suffice to poke the publisher into action | 10:12 |
| === doko_ is now known as doko | ||
| ScottK | cjwatson: OK. Thanks. | 10:51 |
| cjwatson | I've uploaded partman-target, and it'll need a ubiquity upload to pick it up. The fix for bug 979350 caused a non-obvious chain of events that caused an occasional regression, bug 985526. | 10:57 |
| ubot2 | Launchpad bug 979350 in user-setup "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [High,Fix released] https://launchpad.net/bugs/979350 | 10:57 |
| ubot2 | Launchpad bug 985526 in partman-target "exit with error if encryption is selected" [Undecided,New] https://launchpad.net/bugs/985526 | 10:57 |
| stgraber | cjwatson: looking at partman-target now | 11:02 |
| stgraber | cjwatson: looks good | 11:03 |
| cjwatson | stgraber: thanks, accepted | 11:36 |
| cjwatson | ogra_: today's arm desktop build failed for some reason - I'll retry | 11:38 |
| ogra_ | hmm | 11:39 |
| cjwatson | IOW the previous build was before .isotracker.conf was changed to point to RC | 11:39 |
| === greyback is now known as greyback|lunch | ||
| cjwatson | ooh | 11:50 |
| * cjwatson demotes defoma | 11:50 | |
| cjwatson | testing-ports/precise_outdate.txt cleared as of next publisher run | 11:55 |
| cjwatson | I'll start working through removals after an extremely belated breakfast | 11:56 |
| ScottK | FYI, the maas upload in queue needs to come in to fix the MIR requirements for it, but the diff is sufficiently huge, I'll leave it for someone else to consider. | 11:58 |
| ScottK | pitti: re gnome-online-accounts - In the bug you said it should be an SRU (facebook support). Since we're clearly respinning everything, do you still think SRU (it's a new feature, not technically SRU material) or can it go in? | 12:04 |
| Adri2000 | who can do something about what I said earlier? (mistake in the README.files of the cloud tarballs) | 12:20 |
| Adri2000 | or can I file a bug in LP maybe? | 12:21 |
| cjwatson | I'm not sure, ask Daviey or smoser | 12:22 |
| ogra_ | and you can always file a bug in LP :) | 12:24 |
| pitti | ScottK: hm, though question; there is still no confirmation of testing in the bug, so I'd still prefer an SRU TBH | 12:25 |
| ScottK | OK. | 12:25 |
| ScottK | I see python-defaults is still in proposed. | 12:26 |
| Adri2000 | ogra_: tell me what's the right LP project for this and I'll do :) | 12:26 |
| === greyback|lunch is now known as greyback | ||
| === rsalveti` is now known as rsalveti | ||
| mvo | pitti: quick question, all uploads go to -proposed at this point, right? I have a small squid-deb-proxy fix ready | 12:38 |
| cjwatson | It doesn't hurt to use -proposed. | 12:38 |
| mvo | ta | 12:44 |
| ScottK | pitti: Since you're both on the release team and the SRU team, I would appreciate it if you would review bugs 980773 and give feedback on what can/can't be done now. | 12:49 |
| ubot2 | Launchpad bug 980773 in fcitx "Sync fcitx 1:4.2.2-2 (universe) from Debian unstable (main)" [Wishlist,Won't fix] https://launchpad.net/bugs/980773 | 12:49 |
| pitti | ScottK: TBH that sounded really scary, updating umpteen packages and adding new ones | 12:51 |
| pitti | with noone in the Ubuntu developer team to test this stuff | 12:51 |
| * pitti follows up in the bug rather | 12:51 | |
| ScottK | pitti: Agreed. | 12:52 |
| ScottK | Since I'm not on the SRU team, I don't feel I should give a verdict on that. | 12:52 |
| pitti | sent to bug report | 12:53 |
| pitti | TBH I don't know much about input support at all, so I default to being conservative there without more information | 12:53 |
| skaet | thanks ev. :) we'll get it in with the next respin. | 13:29 |
| ev | yay | 13:29 |
| pitti | hey skaet | 13:29 |
| skaet | hiya pitti, read the backscroll. | 13:29 |
| skaet | or reading rather.... | 13:29 |
| pitti | skaet: question about the lightdm upload -- the patch looks perfectly safe to me and should make derivatives/OEM's life easier; do you want some papertrail around it, or can I accept it for the next respin? | 13:30 |
| skaet | Cimi, putting it in -proposed as an SRU target is what's needed now. | 13:32 |
| skaet | pitti, re: lightdm - assume there's some bug numbers? | 13:33 |
| * skaet needs to go dig | 13:33 | |
| pitti | skaet: just a merge proposal | 13:33 |
| pitti | skaet: that's where the "papertrail" question comes in | 13:33 |
| skaet | pitti, yeah, would prefer something documenting it, and tied to, in case we need to revert. | 13:34 |
| skaet | thanks | 13:34 |
| pitti | skaet: ok, I told robert his morning; this will become an SRU then | 13:34 |
| jdstrand | skaet: fyi, I will probably be doing an openssl upload today | 13:35 |
| seb128 | pitti, I can open a bug for lightdm if you want, but SRU looks fine for that change, it's not really required in the release | 13:37 |
| pitti | seb128: sure, sounds good | 13:37 |
| pgraner | anyone else seeing 503 errors with the archive? | 13:48 |
| * ScottK just had 404 errors, but that's because I can't spell updates correctly (working for me). | 13:51 | |
| cjwatson | jdstrand: based on precise or on precise-proposed? | 13:52 |
| cjwatson | The reports in 965371 suggests that the version in precise-proposed is at the very least no worse (which my own testing bore out too) and appears to be an improvement for some sites, although it still doesn't fix everything. Should we promote it? I think I'd like to. | 13:54 |
| * ogra_ wonders whats the issue with the arm livefs builders ... the preinstalled build seems to have failed again | 13:54 | |
| jdstrand | cjwatson: I was going to ask you about that. which do you prefer-- I need to respin for an upstream change anyway | 13:54 |
| cjwatson | ogra_: I'll look shortly | 13:54 |
| cjwatson | jdstrand: inclined to prefer -proposed. what's the upstream change? | 13:54 |
| jdstrand | cjwatson: I just assume use the -proposed one-- you got a lot of positive feedback | 13:54 |
| jdstrand | http://www.openssl.org/news/secadv_20120419.txt | 13:55 |
| jdstrand | http://cvs.openssl.org/chngview?cn=22439 | 13:55 |
| cjwatson | Of the Chinese translation bugs filed today, I've committed easy fixes for bug 985605 and bug 985614; the rest are fairly hard. Are these worth uploading for? | 13:55 |
| ubot2 | Launchpad bug 985605 in console-setup "The keyboard config page should be translated into Chinese" [Undecided,Fix committed] https://launchpad.net/bugs/985605 | 13:55 |
| ubot2 | Launchpad bug 985614 in debian-installer "Something wrong in the keyboard layout selection page" [Medium,Fix committed] https://launchpad.net/bugs/985614 | 13:55 |
| * ScottK is doing a lucid -> precise update test to test the new python-defaults. | 13:55 | |
| cjwatson | jdstrand: ok | 13:56 |
| jdstrand | cjwatson: ok, so I will rebuild with -proposed, retest and upload to where, -proposed (since this could provide skew)? | 13:57 |
| skaet | jdstrand, ack. | 13:57 |
| cjwatson | Perhaps we could promote the existing package from -proposed to the release pocket first, if other release folks agree? | 13:57 |
| ScottK | Seems reasonable. | 13:58 |
| stgraber | sounds good | 13:58 |
| jdstrand | skaet: I updated FrozenArchiveStatus | 13:58 |
| cjwatson | ok, copied | 13:59 |
| cjwatson | can somebody review ubiquity, please? | 14:00 |
| stgraber | sure | 14:00 |
| stgraber | cjwatson: looks good | 14:01 |
| cjwatson | accepted then, thanks | 14:01 |
| pitti | ah, stgraber beat me to it | 14:02 |
| cjwatson | ogra_: fixed | 14:10 |
| ogra_ | what was it ? | 14:10 |
| cjwatson | case error | 14:12 |
| cjwatson | - case $subarch in | 14:12 |
| cjwatson | + case $SUBARCH in | 14:12 |
| ogra_ | oh | 14:15 |
| cjwatson | ogra_: ac100 was still broken, fixed for the next build | 14:23 |
| ogra_ | thanks ! | 14:23 |
| cjwatson | just tedious case rearrangement | 14:23 |
| NCommander | morning | 14:24 |
| skaet | Thanks jdstrand | 14:24 |
| cjwatson | skaet: did you see my Chinese translation questions above? | 14:27 |
| * balloons bringing up the pae / non-pae kernel issue again.. I take it we also don't have a non-pae kernel on the dvd's right? | 14:27 | |
| cjwatson | balloons: we do not currenty | 14:27 |
| cjwatson | *currently | 14:27 |
| jbicha | stgraber: you should probably take a look at the gnome-session proposed upload | 14:29 |
| ScottK | Would someone please promote kdepimlibs5 back to Main. It's needed for Lucid -> Precise upgrades. I just pushed the corresponding seed change. | 14:30 |
| * NCommander is reminded he has to tell omap4 lucid->precise upgrades :-/ | 14:31 | |
| stgraber | jbicha: ok, will do | 14:31 |
| cjwatson | ScottK: done | 14:31 |
| ScottK | cjwatson: Thanks. | 14:31 |
| cjwatson | Not seeing the seed change though | 14:32 |
| ScottK | The push failed. Let me fix. | 14:32 |
| ScottK | Worked that time. | 14:33 |
| stgraber | jbicha: right, so that means we basically end up having to support cups-pk-helper for 5 years, though there's no Ubuntu delta and the code seems fairly simple | 14:34 |
| cjwatson | gotcha, thanks | 14:34 |
| stgraber | jbicha: is that what everyone else (other distros) are using for gnome-shell/gnome-fallback? | 14:34 |
| cjwatson | Is somebody on top of all the remaining stuff on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ? | 14:34 |
| cjwatson | It all looks like Daviey's team | 14:35 |
| * ScottK agrees. | 14:35 | |
| ScottK | cjwatson: It's possible that accepting maas would help that. | 14:35 |
| * ScottK however looked at the diff and decided EWAYTOOLONG. | 14:36 | |
| infinity | cjwatson: Err, oops on the subarch case sensitivity thing in find-live. :/ | 14:36 |
| jbicha | stgraber: I thought every other GNOME3 distro was using GNOME's printer panel, in Unity we use system-config-printer instead | 14:36 |
| cjwatson | infinity: np | 14:37 |
| * cjwatson fixes the lag on component-mismatches generation | 14:37 | |
| jbicha | perhaps it should be fixed by telling GNOME Fallback to use s-c-p too? | 14:37 |
| jbicha | but I'm not sure how to do that, the OnlyShowIn: doesn't differentiate between GNOME Shell and GNOME Classic | 14:37 |
| infinity | cjwatson: But... Doesn't moving the LIVECD="${LIVECD:-...} above all the cases make them no-ops? | 14:38 |
| stgraber | jbicha: yeah, both of them showing with the same name is getting a bit annoying ;) OnlyShowIn=fallback would be handy | 14:38 |
| ScottK | jbicha: Earlier I was discussing what to do about gnome-online-accounts with pitti and he pointed out there's still no reports of successful testing on Ubuntu. So I think it needs that before it goes anywhere. | 14:38 |
| cjwatson | infinity: oops | 14:39 |
| stgraber | jbicha: I guess for 12.04, the easiest is to use cups-pk-helper, if it blows up completely, we can try to revert and get s-c-p in that case in an SRU | 14:39 |
| cjwatson | infinity: should be at the bottom then, sorry, will move | 14:39 |
| infinity | cjwatson: The only reason that appeared to work is because celbalrai has a (stale) copy of every image. ;) | 14:39 |
| stgraber | jbicha: it's not our default session, it's just an install time option, so we can probably do some changes there as SRU if we feel the gnome3 dialog + cups-pk-helper won't work for the LTS | 14:40 |
| cjwatson | it didn't appear to work, that change was after the most recent build | 14:40 |
| infinity | Ahh. | 14:40 |
| infinity | Well, it would have appeared to work anyway. | 14:40 |
| stgraber | jbicha: for now, I'd just accept that new gnome-session | 14:40 |
| cjwatson | so no harm done | 14:40 |
| infinity | Oh, that's why my brain got the case wrong. It's lower-case in buildlive. | 14:42 |
| infinity | Yay consistency. | 14:42 |
| stgraber | pitti: can you accept gnome-session based on discussion above? | 14:44 |
| pitti | stgraber: is that scheduled for release or SRU? | 14:44 |
| pitti | in the latter case it needs a bug | 14:44 |
| stgraber | pitti: release | 14:44 |
| pitti | (as above discussion says "SRU") | 14:44 |
| pitti | ok, thanks, that wasn't entirely clear to me | 14:45 |
| cjwatson | infinity: quite | 14:45 |
| stgraber | pitti: without it you don't get a working printing dialog in Edubuntu when using gnome-session-fallback (install time option) | 14:45 |
| pitti | ack | 14:45 |
| pitti | stgraber: accepted, will copy to release when built | 14:45 |
| stgraber | pitti: thanks | 14:45 |
| stgraber | jbicha: thanks for spotting and fixing it | 14:45 |
| pitti | accepted apt, too, and sent call for testing | 14:46 |
| jbicha | stgraber: someone in the Ubuntu+1 forum mentioned it, I hadn't seen it before since I usually get GNOME Classic for free by installing GNOME Shell which already had the cups-pk-helper recommends | 14:47 |
| pitti | we can then fold into release or SRU as appropriate | 14:47 |
| infinity | pitti: If that's the fix I think it is, SRU is too late. | 14:47 |
| infinity | pitti: It's breaking image builds. | 14:47 |
| pitti | infinity: FD leak | 14:47 |
| infinity | Yeah. | 14:47 |
| infinity | That's breaking ARM server. | 14:47 |
| pitti | infinity: either way, better to have it available for testing earlier than later | 14:47 |
| pitti | infinity: ok, there goes our test case :) | 14:47 |
| pitti | s/goes/is/ | 14:48 |
| infinity | Test case is simple, I'll test it as soon as it's built. | 14:48 |
| cjwatson | so, we've got a week to clean up precise_outdate_all.txt, right? :) | 14:58 |
| * cjwatson has a go | 14:58 | |
| infinity | Doesn't look too bad. | 14:59 |
| ScottK | Cleaning up libreoffice-l10n would be a reasonably big chunk of it. | 15:00 |
| * infinity nods. | 15:00 | |
| cjwatson | I think I just cleaned up libreoffice, at least. | 15:00 |
| cjwatson | It's mostly individual not-built-any-more binaries that hold everything else in. | 15:00 |
| cjwatson | yeah, that wasn't -l10n's fault at all, it was stale base-related binaries on armhf. | 15:01 |
| skaet | sorry cjwatson, missed it in the multiplexing... upload those you have fixes for to -proposed. (as long as no risk of regression on non-chinese) Rest will need to be SRU. | 15:02 |
| skaet | We'll ask victor to check it out overnight, and if solid, move it to -release for subsequent respin. | 15:03 |
| cjwatson | I'll have to tweak d-i to build out of -proposed. | 15:03 |
| cjwatson | I don't know how Victor will check it out without a respin. | 15:04 |
| cjwatson | I guess he could grab the netboot images from the archive. | 15:04 |
| cjwatson | console-setup on its way; that ought to get a ubiquity reupload at some point ... | 15:05 |
| infinity | pitti: Confirmed that apt fixes the bug, FWIW. | 15:11 |
| ScottK | cjwatson: Are the template errors in http://paste.debian.net/163820/ something that ought to have a bug report (this is Lucid -> Precise). | 15:12 |
| skaet | cjwatson, hmm... maybe better flow we need to figure out then. | 15:12 |
| stgraber | cjwatson: console-setup looks good (ignoring all the .gitignore changes) | 15:13 |
| cjwatson | ScottK: lucid's debconf didn't support the @ there, but I think it's noisy rather than harmful | 15:15 |
| ScottK | cjwatson: OK. Thanks. | 15:15 |
| cjwatson | stgraber: accepted, thanks | 15:15 |
| cjwatson | ScottK: (precise's definitely does, I think it was I who fixed that) | 15:15 |
| cjwatson | yeah, debconf 1.5.34 | 15:16 |
| ScottK | Thanks for checking. | 15:16 |
| cjwatson | not sure why the cheese copy from -proposed went wrong last time, but this should fix it | 15:16 |
| pitti | infinity: yay | 15:17 |
| pitti | infinity: arm builds still in accepted, we can copy after next publisher | 15:19 |
| === Ursinha` is now known as Ursinha | ||
| pitti | bbiab | 15:20 |
| infinity | pitti: And I can go back to trying to fix the actual bugs that this blocked. ;) | 15:21 |
| slangasek | cjwatson: ack, thanks | 15:31 |
| jdstrand | skaet: fyi, I am going to build openssl in the security ppa and then pocket copy from there when I am done testing. I'll talk to you before doing it, but this will allow it to build on all archs before the copy while still allowing me to finish qa | 15:40 |
| skaet | jdstrand, sounds good. | 15:41 |
| jdstrand | skaet: it's win/win! :) | 15:41 |
| skaet | understood. | 15:41 |
| skaet | :) | 15:41 |
| phillw | How is the spinning going? I see kubuntu is being re-spun according to the page, no sign of lubuntu yet... | 15:46 |
| cjwatson | There are enough installer changes that I think everything's being respun | 15:47 |
| phillw | thanks, well hopefully that is one big gremlin out of the way :) | 15:47 |
| cjwatson | quickly LGTM, accepting | 15:49 |
| stgraber | yeah and we have things like gnome-session that was accepted earlier that even though it only affects edubuntu (gnome-session-fallback) would probably be good to have up to date everywhere (if only to avoid a pointless update post-install) | 15:49 |
| stgraber | speaking of which, can someone copy gnome-session? looks like it's built everywhere | 15:51 |
| NCommander | ogra_: infinity: where do we have it documented that omap4 server images must use serial to install? | 15:51 |
| slangasek | cjwatson, stgraber: do you know where we are with the python2.7-minimal bug? | 15:52 |
| slangasek | seems to still be open | 15:52 |
| slangasek | and that's going to be CD-impacting | 15:53 |
| slangasek | (unless we opt to SRU it I guess, since it's lucid->precise upgrades only...) | 15:53 |
| cjwatson | stgraber: doing | 15:53 |
| ogra_ | NCommander, no idea, i never touched the server documentation, you and GrueMaster maintained the wikipage in the past | 15:53 |
| stgraber | cjwatson: thanks | 15:53 |
| ogra_ | NCommander, if thats missing in the wiki, just add it ;) | 15:53 |
| stgraber | 11:12 <doko> so the solution which should work is to include the new pycompile into the python2.7-minimal package, ugly solution, but this way we can make sure it's present when used for the first time | 15:54 |
| NCommander | slangasek: when doing release upgrading though, isn't it valid to upgrade to only precise/precise-security? (we don't require to have updates available) | 15:54 |
| stgraber | slangasek: ^ that was from doko earlier today regarding that bug | 15:54 |
| GrueMaster | NCommander: https://wiki.ubuntu.com/ARM/Server/Install | 15:54 |
| slangasek | skaet: ^^ bug #983981 is one that potentially impacts all CDs since it's in the python2.7 package; it *can* be done in SRU, but definitely needs release-noted in that case to give extra discouragement to lucid users trying to upgrade to precise before the fix is in. Do we want to try to get that on the CDs, or should we target -updates? | 15:55 |
| ubot2 | Launchpad bug 983981 in python2.7 "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,Triaged] https://launchpad.net/bugs/983981 | 15:55 |
| slangasek | stgraber: I'm not sure why the Breaks I suggested on the bug is insufficient? | 15:55 |
| slangasek | oh, because Breaks doesn't enforce unpack order | 15:56 |
| slangasek | duh | 15:56 |
| * skaet looking | 15:56 | |
| jibel | slangasek, doko uploaded a version of python2.7 to a ppa for testing. I'll do the verification with this package tonight. | 15:58 |
| slangasek | jibel: right, thanks - now the question is just whether we think we want this on the CDs | 15:59 |
| NCommander | slangasek: upgrading with an alternate CD with no internet is a supported usecase | 15:59 |
| slangasek | NCommander: as for it being valid to upgrade without -updates enabled, sure. It's also valid to tell users who do this that they can keep both pieces when the upgrade bails in the middle due to $random_bug that we didn't get fixed before release | 15:59 |
| slangasek | especially when it *will* be on the CD for .1, which is when we start recommending LTS->LTS upgrades | 16:00 |
| skaet | slangasek, what is likelyhood of regression on this one? | 16:02 |
| ScottK | slangasek: I tested Lucid -> Precise with the python-defaults in precise-proposed three times and had no errors. I also had the right default python version and python2 was there. I'd suggest copy it over. | 16:03 |
| ScottK | (the python2.7 question is a different one) | 16:03 |
| slangasek | skaet: moderate, but easily mitigated by testing + review | 16:03 |
| skaet | slangasek, ok, lets try as long as we can manage the risk. | 16:03 |
| slangasek | skaet: I'm not concerned about regressions here as I think our process is adequate for that, just asking if you think it meets our criteria for a must-respin fix | 16:04 |
| slangasek | ScottK: thanks | 16:04 |
| slangasek | skaet: ^^ see above as well for python-defaults; I think we should copy this from precise-proposed to precise, is that ok? Where are we currently with ISO spinning? | 16:04 |
| ScottK | Since Ubiquity was just accepted 15 minutes ago, I think there's a lot of respins to do. | 16:05 |
| slangasek | aha | 16:05 |
| slangasek | skaet: in that case since we're respinning anyway I'll just copy python-defaults over, ok? | 16:06 |
| stgraber | right, we have ubiquity + console-setup that will require respins of desktop and alternate images anyway | 16:06 |
| cjwatson | console-setup wants another new ubiquity ideally | 16:06 |
| cjwatson | for synciness | 16:06 |
| cjwatson | anyone noticed anything else RC that would require a ubiquity upload? | 16:07 |
| skaet | slangasek | 16:07 |
| skaet | ok. | 16:07 |
| stgraber | nope, I've been running a bunch of pretty complex Edubuntu install to try and stress ubiquity into crashing but couldn't find any problem so far | 16:07 |
| slangasek | skaet: python-defaults copied | 16:08 |
| skaet | thank you | 16:10 |
| ScottK | doko: ^^^ re python-defaults. | 16:13 |
| rsalveti | infinity: ogra_: http://cdimage.ubuntu.com/ubuntu-core/daily/current/precise-core-armhf.tar.gz | 16:14 |
| rsalveti | it's actually armel | 16:14 |
| rsalveti | var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_precise_main_binary-armel_Packages | 16:15 |
| infinity | rsalveti: ! | 16:16 |
| ogra_ | ts | 16:16 |
| infinity | Oh, bother. | 16:16 |
| infinity | I know why that is. | 16:16 |
| infinity | Can't do two arches on the same machine, silly me. | 16:16 |
| infinity | Well, not without some mangling I'm not going to do today. | 16:17 |
| rsalveti | http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-core/20120419/livecd-20120419-armhf.out | 16:17 |
| infinity | And it all seemed so clever yesterday too. | 16:17 |
| rsalveti | yeah, armel | 16:17 |
| infinity | Actually, wait. No, now I'm confused. | 16:18 |
| cjwatson | doko: do you know what's happening with bug 935121? | 16:18 |
| ubot2 | Launchpad bug 935121 in gnat-4.4 "gnat-4.4 version 4.4.6-5ubuntu1 FTBFS on i386 in precise" [High,New] https://launchpad.net/bugs/935121 | 16:18 |
| * infinity looks closer. | 16:18 | |
| pitti | infinity: copying apt to -release, FYI | 16:19 |
| cjwatson | infinity: are you still working on gnat-4.6 for the linker change? it doesn't look desperately happy | 16:20 |
| infinity | cjwatson: In what way doesn't it look happy? | 16:20 |
| cjwatson | fails to build | 16:21 |
| infinity | cjwatson: On armhf? That's expected. | 16:21 |
| infinity | cjwatson: It's not bootstrapped. | 16:21 |
| cjwatson | armel too. https://launchpad.net/ubuntu/+source/gnat-4.6/4.6.3-1ubuntu2/+build/3410800 | 16:21 |
| infinity | Oh, on armel too.. | 16:21 |
| * infinity looks. | 16:21 | |
| cjwatson | which makes it show up on precise_outdate_all, since it used to build. | 16:21 |
| infinity | Oh, ugh. | 16:22 |
| infinity | Looks like someone (doko?) enabled multilib for gnat-4.6 | 16:22 |
| infinity | So it fails on armel for the same reason it fails on armhf (not bootstrapped for armhf) | 16:22 |
| cjwatson | remotely fixable for precise? it has a bunch of reverse-deps | 16:22 |
| infinity | If I can find where it was introduced. | 16:23 |
| infinity | Great, in the 4.6.2->4.6.3 bump. Fun diff. | 16:26 |
| GrueMaster | infinity: Just fyi: It was good on 20120315 (last image I officially tested). | 16:27 |
| infinity | GrueMaster: "it"? | 16:27 |
| GrueMaster | precise-core-armhf.tar.gz | 16:28 |
| infinity | Oh, yeah. I know, I broke it last night. | 16:28 |
| infinity | I'm just trying to decide how, and how best to unbreak it. | 16:28 |
| ogra_ | intresting | 16:28 |
| GrueMaster | Ah. | 16:28 |
| ogra_ | looking at the code it should theoretically only build armhf | 16:28 |
| infinity | ogra_: Eh? | 16:29 |
| ogra_ | in buildlive you have no ubuntu-core case for armel | 16:29 |
| ogra_ | but you have it for armhf | 16:29 |
| ogra_ | pointing to annonaceae.buildd | 16:29 |
| infinity | ogra_: It doesn't need a case. | 16:29 |
| ogra_ | ah, k | 16:29 |
| infinity | ogra_: armel and armhf both point it at the same machine, that's the problem. | 16:29 |
| ogra_ | yeah | 16:30 |
| NCommander | skaet: ubuntu server armhf+omap4 is missing from the ISO tracker | 16:30 |
| infinity | ogra_: (That *shouldn't* be a problem, but we never thought of using the same machine for two arches, so the directories stomp on each other, and that's way too much effort to fix during release crunch) | 16:30 |
| infinity | ogra_: So, I'll just move one to another box, but I need to sort out how that affects my precious parallelisation pipeline. ;) | 16:30 |
| ogra_ | so just s/annonaceae/araceae/ in the armhf case | 16:30 |
| infinity | cjwatson: Something like http://paste.ubuntu.com/937076/ looks correct. | 16:42 |
| infinity | cjwatson: Completely untested. | 16:42 |
| cjwatson | I'll take your word for it, I don't know gnat at all | 16:44 |
| infinity | That's more "knowing GCC packaging". | 16:44 |
| infinity | But given that it takes 4 hours to fail on a panda... | 16:44 |
| * infinity tries to rustle up a faster machine to test on. | 16:44 | |
| * NCommander screams in horror at the idea of trying to compile gnat | 16:44 | |
| skaet | NCommander, may still be building. Has anyone checked if the cron has kicked it out yet? | 16:45 |
| NCommander | Not sure | 16:45 |
| infinity | It may have suffered an earlier oops. | 16:46 |
| infinity | I'll just do a manual spin. | 16:47 |
| ogra_ | skaet, teher are no builds of omap4 server for today yet so all is fine | 16:48 |
| skaet | thanks ogra_. | 16:49 |
| highvoltage | stgraber: anything we need to say for edubuntu-live... on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/EdubuntuDesktop ? | 16:49 |
| skaet | NCommander, ^ | 16:49 |
| stgraber | highvoltage: no, I think the existing LTSP entry is enough | 16:51 |
| highvoltage | skaet: may I fix this sentence? normal people won't be able to parse it. "Until Ubuntu 11.10, the Unix group for administrators with root privileges through sudo had been admin. Starting with Ubuntu 12.04 LTS, it is now sudo, for compatibility with Debian and sudo itself. However, for backwards compatibility, admin group members are still recognized as administrators." | 16:52 |
| skaet | highvoltage +1 (and thanks) | 16:53 |
| ogra_ | wow, what a sentence :) | 16:53 |
| * skaet hoping to get editorial help from docs team.... (I know my limitations) | 16:54 | |
| ogra_ | well, its a tricky problem to describe ... | 16:54 |
| highvoltage | heh, I'm struggling with it too | 16:58 |
| highvoltage | I got it to: | 16:58 |
| highvoltage | """Up until Ubuntu 11.10, root access using the sudo tool is granted via the "admin" Unix group. In Ubuntu 12.04 and hence forth sudo access will be granted via the "sudo" group. This makes Ubuntu more consistent with Debian and how it's implemented upstream.""" | 16:59 |
| slangasek | s/and hence forth// | 16:59 |
| * highvoltage was unsure about that :) | 16:59 | |
| ogra_ | you forgot to mention that admin is still supported though | 16:59 |
| NCommander | infinity: re: package pool in livecd-rootfs. It has to be fixed in the installer. I reproduced on x86 with a server CD | 16:59 |
| ScottK | Is that something users actually care about (admin/sudo)? | 16:59 |
| cjwatson | it'd be "henceforth" anyway, but I agree that removing that is better | 16:59 |
| slangasek | how about "This makes Ubuntu more consistent with the implementation upstream and in Debian"? | 16:59 |
| highvoltage | ogra_: ah nice catch | 16:59 |
| slangasek | ogra_, highvoltage: does that part need to be in the release note though? | 17:00 |
| ogra_ | ScottK, only the ones that use visudo at times i guess | 17:00 |
| pitti | highvoltage: thanks for fixing my broken English :) | 17:00 |
| infinity | NCommander: "it" | 17:00 |
| infinity | NCommander: Which "it" did you reproduce? | 17:00 |
| ogra_ | slangasek, i think ScottK has a point | 17:00 |
| NCommander | infinity: rebuilding package cache | 17:00 |
| ogra_ | not really necessary | 17:00 |
| slangasek | it's a significant behavior change to a core bit of the system; if we think users are going to notice, it's worth release-noting | 17:01 |
| ScottK | If you use visudo, don't you also know enough to look in /etc/group and see what's up? | 17:01 |
| slangasek | even if they don't care about sudo | 17:01 |
| infinity | NCommander: Erm, what? d-i CDs and preinstalled server CDs bear no resemblance here. | 17:01 |
| NCommander | If you install with an alternate CD, after install, the cache isn't updated, so taskssel doesn't show any tasks until updated. I accidently broke my test environment but I think there are several more bugs lurking here that I need to flush out | 17:01 |
| highvoltage | slangasek: it's in there at the moment. if it has to be in there I guess it has to be at least somewhat readable | 17:01 |
| highvoltage | """Up until Ubuntu 11.10, root access using the sudo tool is granted via the "admin" Unix group. In Ubuntu 12.04 sudo access will be granted via the "sudo" group. This makes Ubuntu more consistent the upstream implementation and with Debian.""" | 17:01 |
| highvoltage | (oops, I forgot about the compatibility part again) | 17:01 |
| slangasek | highvoltage: I was only saying to not mention the fact that "admin" is still supported, since I don't think that adds anything useful | 17:01 |
| phillw | How's "with the release of 12.04, the inconsistancy with normal sudo rules have been addressed. New administrators will be part of the sudo group. To ensure backwards compatibility, the existing administrators will automatically be assigned to this group." | 17:01 |
| phillw | ? | 17:01 |
| infinity | NCommander: Doesn't show any tasks, or doesn't show any new (ie: from the network) tasks? | 17:02 |
| ogra_ | what are "normal sudo rules" ? | 17:02 |
| ogra_ | :) | 17:02 |
| slangasek | phillw: not a useful release note unless we actually say what the rules are | 17:02 |
| NCommander | infinity: only shows tasks that were installed during installation | 17:02 |
| NCommander | (plusmanual package selection) | 17:02 |
| highvoltage | """Up until Ubuntu 11.10, root access using the sudo tool is granted via the "admin" Unix group. In Ubuntu 12.04 sudo access will be granted via the "sudo" group. This makes Ubuntu more consistent the upstream implementation and with Debian. For compatibility purposes, the "admin" group will continue to provide sudo/administrator access in 12.04.""" | 17:02 |
| infinity | NCommander: Okay, that's Yet Another Bug then, that doesn't relate at all to me fixing the local pool being broken. | 17:03 |
| highvoltage | or maybe "sudo" should just be mentioned just once and "administrator" for the rest. that would make it slightly less jargonny and technical people will still know what it means. | 17:03 |
| ogra_ | highvoltage, how about s/root/administrator/ in the beginning of the sentence | 17:03 |
| ogra_ | for consistency | 17:03 |
| ogra_ | heh, snap | 17:03 |
| phillw | with the release of 12.04, the inconsistancy with normal sudo rules from debian [1] have been addressed. New administrators will be part of the sudo group. To ensure backwards compatibility, the existing administrators will automatically be assigned to this group. [1] - Link to rules, for those bothered to read :) | 17:03 |
| highvoltage | yeah :) | 17:03 |
| infinity | NCommander: Also, a bit of a weird-sounding one. Can you verify that from an unbroken x86 (ie: fresh install), and report against tasksel, and make it clear it's not yet another ARM bug? :P | 17:04 |
| cjwatson | "inconsistency" | 17:04 |
| highvoltage | I have it to this now but phillw's looks fine too: | 17:05 |
| highvoltage | """Up until Ubuntu 11.10, administrator access using the sudo tool is granted via the "admin" Unix group. In Ubuntu 12.04, administrator access will be granted via the "sudo" group. This makes Ubuntu more consistent the upstream implementation and with Debian. For compatibility purposes, the "admin" group will continue to provide sudo/administrator access in 12.04.""" | 17:05 |
| phillw | cjwatson: I'm typing in a sticky note - no spell checker :) | 17:05 |
| NCommander | infinity: I had reproduced before I broke my environment by connecting the internet | 17:05 |
| ogra_ | highvoltage, This makes Ubuntu more consistent *with* the upstream implementation and with Debian. | 17:06 |
| infinity | highvoltage: s/tool is/tool was/ and s/consistent/consistent with/ | 17:06 |
| ogra_ | beyond that i like it | 17:06 |
| highvoltage | infinity: ah right. temporal language differences. In Afrikaans if you say "The admin tool was granted up until 11.04" it would mean it used to do that in those versions but it doesn't anymore :) | 17:07 |
| ogra_ | well, 11.10 still is used, i wouldnt have used past tense there either | 17:08 |
| infinity | Until foo, X was the situation. In product foo, X is the situation. There's the temporal difference. | 17:08 |
| ogra_ | but grammar isnt necessarily logical :) | 17:08 |
| ogra_ | yeah, its the "until" | 17:09 |
| highvoltage | ogra_: I believe Afrikaans inherited that from German so we're possibly just trained to think the same way about tense like that | 17:09 |
| infinity | But I prefer to keep the current syntax and s/is/was/, because it's important to discuss it as past versus present/future. Easier for people to grasp the New World Order. | 17:09 |
| ogra_ | we should just convince the americase to follow us then :) | 17:09 |
| ogra_ | *americas | 17:10 |
| infinity | ogra_: I vill nefer do eet! | 17:10 |
| highvoltage | infinity: I changed it on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure - edit at will! | 17:10 |
| ogra_ | LOL | 17:10 |
| phillw | he he, where's pedro when you need him :P | 17:12 |
| infinity | cjwatson: Testbuilding gnat-4.6 on one of OEM's speedier machines. Will upload if it doesn't explode. | 17:12 |
| highvoltage | does the ubuntu project has a position on serial commas? (and would that be pedantic?) | 17:13 |
| * ogra_ only cares about serial ports ... as long as these work ... | 17:14 | |
| infinity | I'm not sure the project has positions on grammar at all. | 17:14 |
| pitti | Daviey: will horizon be unseeded again, or will there still be a newer version with less dependencies? (http://people.canonical.com/~ubuntu-archive/component-mismatches.svg) | 17:14 |
| infinity | highvoltage: Should you feel the need to do an UbuntuStrunk flavour, let me know. | 17:14 |
| pitti | Daviey: I suppose python-coverage should be droppable, if the test suite can just deal with it not being present | 17:14 |
| highvoltage | the confusing double negatives when it comes to smp support continues to amuse me :) | 17:15 |
| jbicha | I split April's Tuesday events to separate lines in https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule I think it makes it more clear when things actually happen | 17:17 |
| phillw | oh, btw, thanks for the 1st lubuntu alternates. It'll keep them occupied for a while :) | 17:17 |
| pitti | good night everyone | 17:18 |
| skaet | good night pitti | 17:18 |
| infinity | pitti: *wave* | 17:19 |
| highvoltage | good night pitti! | 17:19 |
| skaet | jbicha, please revert. Its using the syntax agreed to at UDS. We can revisit this for Q. | 17:20 |
| skaet | Try it out on Q/ReleaseSchedule and we can discuss at upcoming feedback on P cycle at UDS | 17:21 |
| phillw | skaet: this being the format that caused all the issues with translations? I do hope it is addressed at UDS-Q | 17:21 |
| skaet | phillw, agreed. | 17:24 |
| skaet | https://blueprints.launchpad.net/ubuntu/+spec/other-q-prior-release-feedback | 17:25 |
| jbicha | skaet: ok, it's been reverted | 17:26 |
| NCommander | infinity: I think I found the root of the tasksel problem: https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/985737 | 17:26 |
| ubot2 | Launchpad bug 985737 in tasksel "Tasks selected in oem-config are downloaded, but not installed, or configured ..." [High,New] | 17:26 |
| skaet | phillw, jbicha ^^ is the catch all for problems we've seen with processes, frustrations, etc. Add concerns there, so it goes on the agenda. If a topic is too involved (like weekly release meeting was last time), it will be spun out to separate session. | 17:26 |
| infinity | NCommander: Commented. | 17:30 |
| NCommander | infinity: commentedback | 17:30 |
| ogra_ | .oO(you guys have a weird way of communicating) | 17:31 |
| infinity | ogra_: Well, the paper trail in the bug is vaguely important. | 17:32 |
| ogra_ | indeed :) | 17:32 |
| stgraber | ogra_: kind of like people phoning you to see if you received their e-mail ;) | 17:32 |
| infinity | ogra_: So, it's either talk on IRC and copy and paste, or comment on the bug and ping in IRC. | 17:32 |
| infinity | ogra_: And who wants to talk to NCommander? | 17:32 |
| ogra_ | stgraber, haha, that was *exactly* what i had in mind | 17:32 |
| ogra_ | infinity, true :) | 17:32 |
| slangasek | did you get that thing I sent ya | 17:33 |
| * NCommander hits infinity with a big pointy stick | 17:33 | |
| ogra_ | *g* | 17:33 |
| infinity | slangasek: I got two, I think one might have been meant for your wife, though? | 17:33 |
| infinity | slangasek: It doesn't fit *me*, at any rate. | 17:33 |
| ogra_ | NCommander, i would compare the Packages files from archive and local pool | 17:33 |
| infinity | ogra_: Why? I already know they're broken. :P | 17:33 |
| NCommander | ogra_: right after I finish filing an installer bug on x86 | 17:33 |
| ogra_ | infinity, do we know how ? | 17:34 |
| infinity | NCommander: Don't bother debugging. | 17:34 |
| infinity | ogra_: Yes. | 17:34 |
| NCommander | infinity: different bug | 17:34 |
| ogra_ | ah, k | 17:34 |
| NCommander | install CD isn't added to sources.list after installation | 17:34 |
| infinity | NCommander: Which different bug? | 17:34 |
| NCommander | (server/precise/i386) | 17:34 |
| infinity | NCommander: No, no, I meant don't bother debugging local pool versus archive, as ogra suggested. ;) | 17:34 |
| NCommander | heh | 17:35 |
| slangasek | infinity: http://www.metacafe.com/watch/1572395/that_thing_i_sent_you/ | 17:35 |
| * NCommander should probably start doing the workload testing so I can file more bugs | 17:35 | |
| NCommander | :-) | 17:35 |
| infinity | Hrm. | 17:35 |
| infinity | Sound stuttering in flash. | 17:35 |
| infinity | Joy. | 17:35 |
| NCommander | infinity: I would think you'd use a nice FOSS alternative like gnash/swfdec/lightspark | 17:36 |
| * NCommander ducks | 17:36 | |
| infinity | NCommander: I'm not sure I parse the word "nice" in that sentence. | 17:36 |
| infinity | If any of those actually work sanely these days, I'm all ears. | 17:37 |
| ogra_ | WebM works | 17:37 |
| ogra_ | i just accidentially noticed that on my ac100 | 17:38 |
| infinity | ogra_: Sure, but not everything is webemmy. | 17:39 |
| ogra_ | yeah, else my surfing experience would be a lot more multimedial on my arm bedbook :) | 17:40 |
| NCommander | sure you don't mean medival? | 17:40 |
| balloons | skaet, what was the mac bug you mentioned? can you link to it? | 17:42 |
| NCommander | .oO(where's my omap4 image) | 17:44 |
| ogra_ | NCommander, not built yet | 17:45 |
| infinity | NCommander: Patience. | 17:49 |
| cjwatson | ^- skaet acked debian-installer going to release rather than -proposed | 17:49 |
| infinity | NCommander: It's squirting our as fast as it can. | 17:49 |
| infinity | cjwatson: I assume your previous d-i component that went to -proposed has been copied? :P | 17:50 |
| infinity | Whatever it was... | 17:50 |
| infinity | user-setup? console-setup? | 17:50 |
| infinity | My brain is mush. | 17:50 |
| cjwatson | infinity: console-setup, and yes | 17:50 |
| * NCommander liquid-cools infinity's brain back into sometihng solid | 17:51 | |
| ogra_ | NCommander, you mean you want to turn his brain into a brick ?!? | 17:53 |
| NCommander | ogra_: meh, we could replace it under warrenty | 17:54 |
| NCommander | I'm pretty sure the PO for infinity included a 10,000 bugs guarantee | 17:54 |
| infinity | cjwatson: Accepted, under the assumption that all the gobbleygook I can't read was obviously valid and sane translation updates. :P | 17:55 |
| infinity | cjwatson: (The bits I understood looked fine) | 17:55 |
| cjwatson | Meh, you're supposed to speak every language on the planet in order to be an Ubuntu developer. | 17:56 |
| cjwatson | (ta) | 17:56 |
| NCommander | .oO(LP needs to add a real-time translation module to Rosetta) | 17:57 |
| NCommander | ok, good, tasksel properly prompts for a CD when its not present | 18:03 |
| NCommander | https://bugs.launchpad.net/ubuntu/+source/apt-setup/+bug/985791 - CD not added after install on i386. I think apt-setup is responsible but I'm not sure | 18:04 |
| ubot2 | Launchpad bug 985791 in apt-setup "After installation from cdrom, apt-setup comments out the CD from installation" [Undecided,New] | 18:04 |
| ogra_ | NCommander, ^^^ | 18:04 |
| NCommander | \o/ | 18:05 |
| * NCommander goes and adds his ten bugs to it | 18:05 | |
| skaet | cjwatson, ack. | 18:11 |
| NCommander | bargh | 18:29 |
| NCommander | Most of the tomcat6 examples seem broken EXCEPT the ones on the workload testing page | 18:29 |
| micahg | hmm, is there an easy way to sync something to proposed? | 18:46 |
| micahg | syncpackage seems to want to show every changelog entry | 18:46 |
| infinity | Rebuilding ubuntu-core undo the previous oops with assigning two arches to the same buildd. | 18:47 |
| infinity | micahg: Do a --no-lp sync to precise, then 's/Distribution: precise/Distribution: precise-proposed/' in the .changes, sign, upload. | 18:48 |
| micahg | infinity: heh, ok | 18:48 |
| infinity | micahg: (And no, that's not the answer you were looking for, but I'm not sure the internal tools handle it right) | 18:48 |
| micahg | infinity: ooh, you can do -r precise-proposed with --no-lp and it seems to DTRT | 18:51 |
| infinity | micahg: Including the right -V? | 18:52 |
| infinity | micahg: Curious. | 18:52 |
| micahg | infinity: doesn't need -v in this case :) | 18:52 |
| micahg | well, an earlier -v | 18:52 |
| infinity | micahg: Ahh, that's probably why it appears to DTRT. ;) | 18:52 |
| micahg | ^^ re kadu, I sent it to proposed as it's a longish build with arch:all packages, the only questionable thing I can see is a new binary depends on libqt4-svg, but I'm guessing that was just missing before | 18:59 |
| CareBear\ | can I still get a new libusb package in? :) | 19:03 |
| CareBear\ | if available like soon | 19:04 |
| infinity | CareBear\: Addressing which bug(s)? | 19:05 |
| ogra_ | skaet, so we had what we thought was a gtk-window-decorator bug in arm compiz/unity ... it turns out that the bvase branch the arm compiz patch was created from didnt contain the quilt patches the ubuntu package carries though, thats the cause of the decorator issue ... i would like to do a zero day SRU for this but i'm not sure how to proceed | 19:07 |
| ogra_ | (since that will indeed require a rebuild of more than just compiz) | 19:07 |
| ogra_ | i will discuss with didrocks tomorrow but want to give you a heads up warning | 19:08 |
| skaet | ogra_ coordinate it with didrocks. We'll pick a window for it to land (Tues/Wednesday). | 19:08 |
| skaet | :) | 19:08 |
| infinity | ogra_: Do you have new packages prepared already that we can look at diffs for? | 19:08 |
| ogra_ | infinity, no, we just discovered it and i dont trust my concentration to do it now, i will do it tomorrow monring first thing though | 19:08 |
| infinity | ogra_: *nod* | 19:08 |
| infinity | ogra_: Well, get it sorted, then ask. ;) | 19:09 |
| slangasek | CareBear\: not unless it fixes a critical bug... no such bugs have been on our radar up to this point? | 19:09 |
| ogra_ | will do :) | 19:09 |
| ogra_ | infinity, btw, see #ac100 :) | 19:09 |
| infinity | ogra_: If it's pretty broken, and obviously only affects ARM, we can probably get it in via proposed->release->rebuild. If it's risky-looking, SRU. | 19:09 |
| ogra_ | seems srwarren treis to roll the hf binaries right now :) | 19:09 |
| ogra_ | yeah, its arm only | 19:09 |
| ogra_ | the quilt patch we use sits on top of all other quilt patches ... and reverts all the others :P | 19:10 |
| infinity | D'oh. :/ | 19:11 |
| infinity | Respinning armhf desktop images for benchmarking purposes (and to resurrect ac100) | 19:14 |
| slangasek | resurrect? | 19:15 |
| CareBear\ | slangasek : what constitutes critical? there are several bugfixes | 19:16 |
| slangasek | CareBear\: a bug that renders Ubuntu uninstallable or causes an upgrade to fail or to cause data loss through normal use on install would be critical. "several bugfixes" is probably not in that grouping... | 19:17 |
| infinity | slangasek: Thinko in the cdimage scripts made it disappear slightly. ;) | 19:17 |
| slangasek | infinity: heh | 19:18 |
| CareBear\ | slangasek : a future upgrade might fail, because the current package in Ubuntu was packaged by debian from an RC which was on a development branch and one public API has changed since that time. this is also the main reason I would want a non-rc version included. | 19:20 |
| slangasek | "might fail" - that sounds like speculation, not a bug report | 19:20 |
| slangasek | we certainly are well versed in dealing with API changes when they happen | 19:21 |
| CareBear\ | slangasek : it *will* fail if someone starts using the incorrect API, and then an upgrade is done to a real release of the package which doesn't have that API any longer | 19:21 |
| slangasek | that's not how it works | 19:21 |
| CareBear\ | it could happen? | 19:23 |
| slangasek | this is the same upstream version of libusb that was shipped in the past *two* LTS releases; we're not going to pull in a new upstream version of a library the week before release because it *might* save trouble for people writing new code against 12.04 | 19:23 |
| CareBear\ | it is not the same version | 19:23 |
| slangasek | and if APIs are dropped, that means an ABI bump, which is certainly not in the cards | 19:24 |
| CareBear\ | the two last LTS have 1.0.8 with patches. currently you have 1.0.9-rc3 | 19:24 |
| slangasek | hardy: 2:0.1.12-8 precise: 2:0.1.12-20 | 19:24 |
| slangasek | what packge are you talking about? | 19:24 |
| CareBear\ | no, no ABI bump, because the rc3 was from development branch | 19:24 |
| CareBear\ | libusb1 | 19:24 |
| CareBear\ | I guess you call it? | 19:24 |
| slangasek | there's no such package in Ubuntu | 19:24 |
| slangasek | and the libusb package is at version 0.1.12 | 19:24 |
| CareBear\ | yes, no, that's the wrong package :) | 19:25 |
| * slangasek searches | 19:25 | |
| CareBear\ | hold on - let me find it! | 19:25 |
| micahg | libusb-10 | 19:25 |
| CareBear\ | ah thanks! | 19:25 |
| micahg | libusb-1.0 | 19:25 |
| CareBear\ | yes | 19:25 |
| micahg | it's still on images | 19:25 |
| slangasek | right | 19:25 |
| ogra_ | and has rdeps | 19:25 |
| slangasek | (blah, why do we have libusb besides then) | 19:25 |
| CareBear\ | slangasek : libusb and libusb10 provide different API and can coexist | 19:25 |
| micahg | slangasek: too many rdeps for a transition | 19:25 |
| ogra_ | (upower for example) | 19:26 |
| slangasek | CareBear\: yes, but we don't like having different libs with different APIs for the same thing ;) | 19:26 |
| micahg | even a partial transition | 19:26 |
| ogra_ | and cupy :) | 19:26 |
| ogra_ | *cups | 19:26 |
| micahg | luckily it's only ~50k | 19:26 |
| CareBear\ | slangasek : oh I don't like it either. libusb-0.1 (your libusb package) is deprecated since many years and unmaintained, but some packages still have not upgraded to the new API | 19:26 |
| CareBear\ | slangasek : at upstream we also provide libusb-compat-0.1 which uses libusb-1.0 to emulate the old libusb-0.1 | 19:27 |
| slangasek | CareBear\: can you give me a pointer to an explanation of this API change? (or a diff) | 19:27 |
| ogra_ | hmm, we use both of them ? | 19:27 |
| ogra_ | libusb-0.1-4 is in minimal ... libusb-1.0-0 is in standard | 19:28 |
| ogra_ | (sounds liek something to clean up one day) | 19:28 |
| slangasek | CareBear\: unfortunately, the answer is probably still going to be "no"; I would have been glad to get this done had it come to our attention earlier, but it's probably still too much churn to take at this stage | 19:28 |
| ogra_ | *like | 19:28 |
| CareBear\ | slangasek : it's pretty simple, but still. rc3 adds a libusb_has_capability() function which checks for named capabilities in the library. the first (and only) capability changed name from LIBUSB_CAN_GET_DEVICE_SPEED in rc3 to LIBUSB_CAP_HAS_CAPABILITY in current master | 19:31 |
| CareBear\ | slangasek : I did join here some time ago to somehow prepare for the change, but then there were interrupts and now it looks like it's too late then | 19:32 |
| ogra_ | is there a diff/patch somewhere to look at ? | 19:32 |
| CareBear\ | I'm happy to help clarify anything about 0.1 vs. 1.0 you may want to know | 19:32 |
| CareBear\ | ogra_ : hold on | 19:32 |
| ogra_ | CareBear\, 0.1 vs. 1.0 and moving to only one of them sounds like a great plan for 12.10 :) | 19:33 |
| slangasek | CareBear\: right... sorry about that :/ | 19:33 |
| slangasek | CareBear\: my ISP seems to be giving me fits today and I'm not able to get to libusb.org; is there somewhere else I can look for the code/ | 19:33 |
| Laney | where does queuebot's code live? | 19:34 |
| CareBear\ | hold for links | 19:34 |
| CareBear\ | slangasek : http://git.libusb.org/ | 19:34 |
| Laney | found it | 19:34 |
| CareBear\ | ogra_ slangasek : rc3 has this commit: http://git.libusb.org/?p=libusb.git;a=commitdiff;h=69045343 master has this: http://git.libusb.org/?p=libusb.git;a=commitdiff;h=e1680513 | 19:34 |
| slangasek | mmk, can't get to git.libusb.org either, blah | 19:34 |
| CareBear\ | ogra_ slangasek : rc3 was tagged on a development branch that was since rewritten before getting into master. rc3 was meant for internal review, but was too eagerly pushed into debian. | 19:35 |
| CareBear\ | I'll pastebin | 19:35 |
| slangasek | understood | 19:36 |
| slangasek | have you spoken with the Debian maintainer, by chance? | 19:36 |
| CareBear\ | yes | 19:36 |
| CareBear\ | rc3:http://dpaste.com/734359/ master:http://dpaste.com/734360/ | 19:36 |
| slangasek | grr, I can't reach that site *either* | 19:37 |
| ogra_ | phew, thats half a year old | 19:37 |
| ogra_ | Mon, 17 Oct 2011 16:23:54 +0200 | 19:37 |
| CareBear\ | yes, that may be when I started talking about it in here | 19:37 |
| CareBear\ | slangasek : what *can* you reach? :) | 19:38 |
| NCommander | Do we have any tomcat gurus here? | 19:38 |
| CareBear\ | slangasek : any other pastebin? | 19:38 |
| slangasek | buggeredifIknow | 19:38 |
| slangasek | let's see | 19:38 |
| ogra_ | paste.ubuntu.com ? | 19:38 |
| slangasek | CareBear\: paste.ubuntu.com is working for me... for the moment | 19:38 |
| CareBear\ | ok! | 19:38 |
| ogra_ | NCommander, there is that #ubuntu-server channel :) | 19:39 |
| * NCommander can access the dpaste.com if someone wants a repost | 19:39 | |
| CareBear\ | slangasek : rc3: http://paste.ubuntu.com/937357/ master: http://paste.ubuntu.com/937359/ | 19:40 |
| CareBear\ | ogra_ : the 0.1 vs. 1.0 thing is important if one application wants to use both versions through different plugins or libraries. then the separate implementations can easily conflict, but in those cases using the compat library to get 0.1 API is the right solution. that's why it's there | 19:41 |
| slangasek | CareBear\: does the libusb_get_device_speed API exist in master? | 19:42 |
| CareBear\ | slangasek : yes | 19:42 |
| slangasek | ok | 19:42 |
| ogra_ | CareBear\, well, i just dont like to have two versions of the same thing twice on our images and would like to see how we solve that for the future, nothing for now though | 19:42 |
| slangasek | so this is an entirely non-ABI-breaking API change | 19:42 |
| slangasek | it will break compiles, but anything built against the old version won't fail to run with the released version | 19:42 |
| CareBear\ | slangasek : correct! | 19:43 |
| CareBear\ | slangasek : thanks for the clarity | 19:43 |
| CareBear\ | I understand this is not critical | 19:43 |
| slangasek | still, from an upstream perspective you would obviously like developers to not have to hack around this when building on Ubuntu | 19:43 |
| CareBear\ | nod | 19:43 |
| slangasek | we could cherry-pick that one commit, which would be a lot easier for us to squeeze in than reviewing a full upstream diff for the new release, at this point | 19:44 |
| CareBear\ | so revert the old and add the new? | 19:44 |
| slangasek | CareBear\: if we could make that happen, would that be ok? | 19:44 |
| slangasek | yes | 19:44 |
| CareBear\ | that would be lovely! | 19:44 |
| CareBear\ | can I help? | 19:44 |
| slangasek | well, we still need to check to make sure nothing in the Ubuntu archive is already using that old API | 19:44 |
| slangasek | so that we don't regress buildability | 19:45 |
| CareBear\ | I can make a branch off the rc3 with revert+new commit | 19:45 |
| slangasek | CareBear\: it's a short enough fix that I don't think you should bother | 19:45 |
| slangasek | micahg: any chance you could help with this? | 19:46 |
| CareBear\ | revert conflicts, I'll fix it and show you | 19:46 |
| CareBear\ | trivial but still | 19:46 |
| slangasek | micahg: 27 revdeps, we'd want a source scan for LIBUSB_CAN_GET_DEVICE_SPEED... I assume you're well-versed in the security team tools that do this :) | 19:46 |
| micahg | slangasek: I wish I was, you need someone with a local mirror, jdstrand could probably help with that or give someone with a local mirror pointers | 19:47 |
| jdstrand | micahg: are you calling me a tool? | 19:48 |
| ogra_ | lol | 19:48 |
| slangasek | skaet: ^^ and just to confirm, do we have room in the schedule for this minimal library change that affects all images? | 19:48 |
| micahg | jdstrand: I suppose it could be read that way ;) | 19:48 |
| jdstrand | what is needed? it usually takes several hours | 19:49 |
| infinity | slangasek: I can do a source scan. | 19:49 |
| slangasek | infinity, jdstrand: we only need a scan on the 27 packages build-depending on libusb-1.0-0-dev | 19:50 |
| infinity | Oh, that's much simpler. :P | 19:50 |
| * infinity does that now. | 19:50 | |
| * jdstrand has no context for this conversation, but gladly lets infinity do 'it' | 19:51 | |
| infinity | slangasek: LIBUSB_CAN_GET_DEVICE_SPEED is definitely the offensive bit? | 19:52 |
| CareBear\ | yes | 19:52 |
| infinity | slangasek: If so, it's not found in any of those sources. | 19:53 |
| slangasek | infinity: did you do a proper source scan with crazy-security-team-unpacking logic? | 19:53 |
| CareBear\ | I pushed the branch off rc3 to here: http://git.libusb.org/?p=libusb-stuge.git;a=shortlog;h=u1204 revert: http://paste.ubuntu.com/937377/ fix: http://paste.ubuntu.com/937378/ | 19:53 |
| slangasek | (tarball in tarball; tarball in watermelon; tarball on goofballs; etc) | 19:53 |
| infinity | slangasek: I'm not sure how necessary that is, unless you think a debian/rules patch is cleverly doing a 's/CHEESEBURGER/SPEED/' in the source just to screw with me. | 19:54 |
| ogra_ | dput has watemelon support ? | 19:54 |
| infinity | Oh, I suppose there's tarball in tarball. I can quickly check for that. :P | 19:54 |
| * ogra_ notes that down for the summer | 19:54 | |
| slangasek | infinity: this is why I was asking the security team, they have standard scanning tools | 19:54 |
| infinity | It's only a few sources. :P | 19:55 |
| infinity | And no tarballs. | 19:55 |
| infinity | It's all normal. | 19:55 |
| slangasek | ok | 19:55 |
| CareBear\ | amazing. thanks all! | 19:58 |
| slangasek | infinity: thanks - can you grab that fix CareBear\'s offered us, and push it to -proposed today? | 19:58 |
| infinity | Sure. | 19:58 |
| skaet | slangasek, we'll pull it in today then. | 19:59 |
| infinity | CareBear\: Is there a Launchpad bug for this? | 20:09 |
| CareBear\ | infinity : no, but I can create one if you want? | 20:09 |
| infinity | Not necessary. | 20:09 |
| CareBear\ | ok | 20:09 |
| infinity | slangasek / skaet: Uploaded. | 20:16 |
| jdstrand | hrmm | 20:16 |
| infinity | Err, and rejecting. | 20:16 |
| infinity | Cause I forgot to update-maintainer. | 20:16 |
| infinity | La la la. | 20:16 |
| ogra_ | tsk, paperwork | 20:17 |
| jdstrand | cjwatson: so, it turns out that your ubuntu2 upload causes qrt test failures (test_rfc5746(), test_rfc5746_dtls()) in test-openssl.py. I haven't looked at it yet | 20:17 |
| infinity | Fixed and re-uploaded. | 20:17 |
| CareBear\ | what's the -2 part? | 20:18 |
| ogra_ | comes from debian | 20:18 |
| CareBear\ | ok | 20:18 |
| jdstrand | cjwatson: ubuntu1 is ok, ubuntu2 is not and by extension, my ubuntu3 is not | 20:18 |
| ogra_ | we only add ubuntuX usually | 20:18 |
| skaet | slangasek, infinity - crontab disabled now, we're manual from here on out. | 20:18 |
| CareBear\ | got it | 20:18 |
| infinity | skaet: Check. That coincides nicely with me getting IS to mangle some live builders, since I don't have to disable things myself. :P | 20:27 |
| skaet | infinity, we're waiting for a few more things to land before the respins. Let us know when #IS is done. | 20:32 |
| jdstrand | skaet: ok, ready to copy openssl. my testing showed no regressions over ubuntu2 (which is already in the archive) | 20:39 |
| slangasek | libusb-1.0 accepted for building | 20:39 |
| skaet | thanks jdstrand | 20:39 |
| jdstrand | skaet: 1.0.1-4ubuntu3 pocket copied | 20:42 |
| skaet | infinity, slangasek, http://pad.ubuntu.com/ubuntu-release as been updated | 20:51 |
| skaet | if there's anything else that needs to be waited for that I've missed, before the full rebuild is triggered. | 20:53 |
| jdstrand | skaet: not we need a publisher run before openssl is ready | 20:54 |
| jdstrand | s/not/note/ | 20:54 |
| skaet | jdstrand, yup, but we have to wait for libusb-1.0 first, so,... figured that would happen. Have clarified though. | 20:56 |
| infinity | The builder mangling will be the blocker anyway for preinstalled images. | 20:58 |
| infinity | skaet: When we're ready, I'd like to do the preinstaller trigger myself, so I can get timings out of it. | 21:01 |
| infinity | skaet: Trying to get the pipeline as short as I can with what I have to work with. :P | 21:01 |
| infinity | preinstalled* | 21:01 |
| skaet | infinity, ok, take over the respins. (I'm interested in your timings.... can you post when done?) | 21:03 |
| * skaet would like to compare to the ones she took with beta2 | 21:03 | |
| infinity | Some images will be quite a bit slower (older hardware), but the overall "rebuild the world" should be quite a bit faster. | 21:04 |
| infinity | Or, that's my hope. | 21:04 |
| * skaet crosses fingers | 21:05 | |
| phillw | infinity: what sort of server do you need to assist in builds & what does it have to have to have installed? | 21:07 |
| phillw | -have | 21:07 |
| infinity | phillw: It has to be in our datacenter, so I suspect that's a non-starter for you donating cycles. | 21:08 |
| phillw | okaym infinity - just seems a waste of an idle server :/ | 21:08 |
| skaet | phillw, some of the localized image producers from the community might want to take you up on it, if there's an idle server sitting there. ;) | 21:09 |
| skaet | http://localized-iso.qa.ubuntu.com/qatracker/milestones/209/builds - is where those images will be landing eventually. Just the italian's have started at this point | 21:10 |
| phillw | skaet: I've put a request in via balloons to ask if Canonical would sponsor 4 IP addresses (12 GBP / IP address / year) for me to put Virtual Machines onto the server. | 21:11 |
| skaet | k, will follow up on it next week (when in london), if balloons doesn't have it sorted first. | 21:12 |
| phillw | cheers, skaet . TheSII (upstream team) do not need the capacity of the 16G model of http://www.kimsufi.co.uk/ So it sits there at 0.1% cpu time! | 21:17 |
| infinity | cnd: Was this xorg upload something you were hoping to get into release? | 21:27 |
| cnd | infinity, I didn't think it had critical fixes, and we're well into final freeze, so I figured I'd prepare it as a 0day SRU | 21:28 |
| cnd | I can propose it for the release if you think that's better | 21:28 |
| infinity | cnd: No, no. If you're cool with it festering until release, I'll leave it in the queue, and you can deal with the SRU team instead of me. :P | 21:29 |
| cnd | :) | 21:29 |
| infinity | cnd: But if any of it is kinda key to a not-shit user epxerience, we can/should discuss picking it up. | 21:30 |
| cnd | infinity, if everyone used touchscreens I would say yes | 21:30 |
| cnd | but in reality, there aren't *that* many ubuntu touchscreen users | 21:30 |
| infinity | Yeah, all two of them. | 21:30 |
| infinity | Check. | 21:30 |
| cnd | and those that are can use a mouse to get an SRU | 21:30 |
| cnd | though that reminds me I need to add a note in the release notes | 21:30 |
| infinity | I'll let it sit in the queue for now, then. | 21:30 |
| infinity | Though, if this is something you feel is important enough to Release Note it, we should go back to discussing fixing it. :P | 21:31 |
| infinity | Release Noting things we HAVE a clear fix for, when we're still a week out, feels wrong to me. | 21:31 |
| * skaet --> errands, back in a few hours. | 21:31 | |
| skaet | infinity, you have the baton. ;) | 21:31 |
| cnd | well, I was told to release note anything that might be broken in the release | 21:31 |
| cnd | anything that was note worthy | 21:31 |
| slangasek | libusb-1.0 copied to release | 21:32 |
| infinity | Noteworthy is a matter of opinion. ;) | 21:32 |
| cnd | even if it will be fixed by a 0 day SRU | 21:32 |
| skaet | thanks slangasek | 21:32 |
| infinity | If we noted every bug, the notes would be long and very unreaable. ;) | 21:32 |
| cnd | I agree :) | 21:32 |
| cnd | but someone suggested I note it | 21:32 |
| infinity | slangasek: Again? | 21:32 |
| infinity | I guess we can never have too many. | 21:33 |
| cnd | infinity, if you want, take a look at the bug report and let me know what you think we should do | 21:33 |
| infinity | cnd: Sure, when my tuits get a bit rounder tonight, I'll have a closer look. | 21:33 |
| cnd | ok | 21:33 |
| cnd | thanks :) | 21:33 |
| slangasek | infinity: did you do this already? | 21:34 |
| slangasek | it hadn't been published yet :) | 21:34 |
| slangasek | ah, 'No packages copied', so. | 21:34 |
| jbicha | I wouldn't expect hardware to magically work with updates, I'd just assume that version of Ubuntu didn't support the device if it didn't work from the Live CD/USB | 21:34 |
| slangasek | then my statement is no less correct ;) | 21:34 |
| infinity | slangasek: I think I accepted it before queubot had a chance to announce. | 21:35 |
| infinity | jbicha: Except for explicit hardware enablement backporting, that's probably a fair assessment of the average user impression, yes. | 21:35 |
| infinity | jbicha: On the flipside, we probably have all of 2.3 touchscreen users right now, and 12.04.1 will be out long before we have a ton more. | 21:36 |
| * infinity takes this opportunity to accept lightdm, so people can stop waffling about it, based on /lastlog not telling me that anyone actually has concerns. :P | 21:38 | |
| infinity | ^--- Those are all broken, buyer beware. | 21:40 |
| infinity | slangasek: Do you know the magic for just marking every image in the tracker invalid? We're going to respin soon (fsvo "soon") anyway. | 21:40 |
| slangasek | infinity: seb128 had said it was fine for SRU, so please don't accept lightdm into release if we don't need it | 21:40 |
| slangasek | infinity: sure, I can do that | 21:41 |
| slangasek | actually, if there's no bug number for lightdm, then it's an invalid SRU candidate | 21:41 |
| slangasek | so that should have been a reject | 21:41 |
| infinity | slangasek: To be fair, it was heavily discussed as being useful to derivatives. | 21:41 |
| slangasek | and needed for .0? | 21:42 |
| infinity | (Which would include people mangling images, I'd guess, but maybe not) | 21:42 |
| slangasek | disablenated | 21:43 |
| slangasek | not added, you cod | 21:43 |
| infinity | queuebot: Oh shut up, can't you tell a tentative test click when you see one? | 21:44 |
| infinity | Oh lord, and it's going to list all of the rest. | 21:44 |
| infinity | I must not have made the cutoff. | 21:44 |
| GrueMaster | infinity: Can you (when you get a chance) remove my gruemaster email from the CD Image failure reporting? Thanks. | 21:47 |
| infinity | GrueMaster: Done. | 21:49 |
| stgraber | slangasek: oops, for some reason I forgot that this message is printed whenever something affects >= 25 entries and not just when adding entries as it did initialy, message updated to reflect that now :) | 21:54 |
| slangasek | stgraber: :) | 21:54 |
| stgraber | infinity: you were close, would just have needed an extra 7 entries to trigger the spam protection ;) | 21:55 |
| infinity | I still think your threshold's too high. ;) | 21:56 |
| infinity | "More than 0 entries changed, go find out for yourself." | 21:57 |
| slangasek | thing happened; see Internet for details | 21:57 |
| infinity | ^ | 21:57 |
| infinity | exec update-initramfs.REAL "$@" | 21:58 |
| infinity | Err. | 21:58 |
| infinity | Thanks for whatever paste buffer had THAT in it... | 21:58 |
| infinity | http://lmgtfy.com/?q=what+happened%3F | 21:59 |
| stgraber | so what exactly are we doing for the upgrades on the tracker? are we resetting them everyday? | 22:05 |
| stgraber | I'm wondering because they're currently all marked for rebuild which prevented the auto upgrade tester from publishing its results a few minutes ago (which basically is, edubuntu => OK, kubuntu => OK, mythbuntu and xubuntu => FAIL) | 22:06 |
| infinity | Oh. They're all disabled because they're all about to be respun. | 22:06 |
| infinity | But what our normal practice will be for the rest of the week, I don't know. | 22:06 |
| infinity | Probably not that. :P | 22:07 |
| stgraber | I tend to prefer having a single upgrade "build" for the release week and let people add more pass/fail results to it as things evolve, but that's just personal preference based on the fact that it takes pretty much a day to get the automated upgrades done so we can't get an accurate view of the upgradability of the archive | 22:10 |
| stgraber | in theory, any upload to the archive should trigger a bump of that product on the tracker, but I doubt it's reasonable considering how long it takes to run them ;) | 22:10 |
| infinity | Alright, respinning the world, unless there are objections. | 22:23 |
| slangasek | depends | 22:23 |
| slangasek | do you want eglibc first? | 22:23 |
| slangasek | (critical upgrade issue for kubuntu...) | 22:24 |
| infinity | *blink* | 22:24 |
| infinity | What did I break? | 22:24 |
| slangasek | nothing | 22:24 |
| slangasek | bug #985735 | 22:24 |
| ubot2 | Launchpad bug 985735 in eglibc "update-manager restarts KDM and interrupts update process" [High,Incomplete] https://launchpad.net/bugs/985735 | 22:24 |
| infinity | Oh, fun. | 22:26 |
| infinity | Hasn't it been like this for the last 7 years? | 22:26 |
| infinity | One would assume not, I guess. | 22:27 |
| slangasek | infinity: so this seems to be the first report of the problem all cycle | 22:29 |
| slangasek | which means I'm not inclined to rush in a fix | 22:29 |
| slangasek | infinity: you want to go ahead and respin the world then? | 22:29 |
| infinity | Sure. Incoming twirly world. | 22:30 |
| infinity | Oh, oops. This does me no good for timings, since I meant to also change the shell madness. | 22:33 |
| infinity | Oh well. | 22:33 |
| infinity | Twirly anyway. | 22:33 |
| slangasek | so I'm looking now to see if this is a regression from 2.15-0ubuntu7 | 22:36 |
| infinity | Seems possible. | 22:37 |
| slangasek | eglibc uploaded. sigh and grr. | 22:54 |
| slangasek | skaet: much apologizings for the above eglibc upload; it fixes a kubuntu-only regression introduced a week ago that was tricky to spot in the source diff, so I'm not surprised it didn't get caught in review | 22:56 |
| slangasek | infinity, skaet: I think we have to get this into -release due to the horrid impact on upgrades, but there's no need to respin just for this since it's *only* an upgrade issue - we should plan to include it in the next respin, whenever there is one | 22:57 |
| slangasek | well, let me think about that | 22:58 |
| slangasek | is it ok to have this as a 0-day SRU? | 22:58 |
| slangasek | skaet, infinity: alright, I've convinced myself this should be a target of opportunity: if we're respinning a substantial portion of the images after the current run, we should take eglibc and make it a global respin, otherwise we should 0-day SRU it | 23:01 |
| stgraber | slangasek: 0-day SRU would break for people using kubuntu alternate as a pool for their upgrade. | 23:02 |
| stgraber | but that's a very limited subset of people | 23:02 |
| slangasek | now see, you're talking me out of it again | 23:02 |
| slangasek | ok | 23:02 |
| slangasek | anyway, it's on the pad now | 23:02 |
| infinity | Get 60 more bytes in your diff and I'll accept it. | 23:03 |
| slangasek | ? | 23:04 |
| infinity | diff from 2.15-0ubuntu9 to 2.15-0ubuntu10 (606 bytes) | 23:05 |
| infinity | Anyhow, reading more context to make sure the 1-line diff makes sense to me. | 23:05 |
| * slangasek nods | 23:06 | |
| infinity | That's wildly unintuitive with the inline script substitution. | 23:09 |
| infinity | Could probably do with a short "check goes in, services comes out" comment, or something. :P | 23:09 |
| slangasek | could do with a few things | 23:10 |
| slangasek | do you want me to reupload with that comment added? :) | 23:10 |
| infinity | Kerosene? | 23:10 |
| infinity | No, but if you could add said comment to debian's svn and ubuntu's bzr, that would be snazzy. :P | 23:10 |
| infinity | Cause without it, I have a hard time blaming you for breaking it. | 23:11 |
| infinity | Or any future person who breaks it similarly. :P | 23:11 |
| slangasek | adding in bzr; will worry about debian svn later since it's not a clean merge | 23:15 |
| infinity | Not even remotely, no. | 23:20 |
| infinity | I want to try to get them more in line with each other next cycle to reduce my headaches. | 23:20 |
| * infinity goes to grab a snack. | 23:21 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
