| === Ursinha-afk is now known as Ursinha | ||
| mlankhorst | infinity: so looks like from the table that the problems Riddell had were not caused by mesa 10.2 -> 10.3 | 07:01 |
|---|---|---|
| infinity | mlankhorst: Alright. Can you get him to sign off on your findings, and let's JFDI this upload once he has? | 07:02 |
| infinity | mlankhorst: If we have cause to respin, I might like to get it in the beta to get wider testing, but realistically, it would probably land right after. | 07:03 |
| elfy | infinity: if lightdm gets a fix for the vm issue will that likely cause a respin | 07:04 |
| infinity | elfy: Yeah. | 07:04 |
| elfy | hopes it gets fixed :) | 07:05 |
| mlankhorst | infinity: looks like he has | 07:05 |
| mlankhorst | according to comment #12 on bug 1364003 | 07:06 |
| ubot2 | bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New] https://launchpad.net/bugs/1364003 | 07:06 |
| infinity | mlankhorst: Alright, if you're willing to commit to fixing kwin/mesa issues (if there are any, which looks less and less likely), a fresh +1 from me. | 07:08 |
| mlankhorst | goodie | 07:08 |
| infinity | mlankhorst: There's no transition required or anything, right, just a regular ol' mesa upload? | 07:08 |
| infinity | elfy: Which bug is that? | 07:09 |
| mlankhorst | just a mesa upload | 07:09 |
| infinity | mlankhorst: Right, make sure you're happy with your current source and fire away, then. | 07:09 |
| infinity | elfy: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1371651 ? | 07:10 |
| ubot2 | Launchpad bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] | 07:10 |
| infinity | elfy: That looks like a bit of a blocker to me. Would certainly be a ship-stop RC for the final release, and I'm about 98% sure it should be for the beta too. | 07:11 |
| elfy | infinity: agreed | 07:12 |
| infinity | elfy: I mean, on the one hand, I don't care deeply about VMs, and neither do the majoriy of our actual users. | 07:12 |
| elfy | unless we move to systemd really quickly - seems to work ok with that :D | 07:12 |
| infinity | elfy: But, on the other hand, the majority of our QA processes revolve around VMs working right. :P | 07:13 |
| elfy | well yea - I'm off that opinion re vms - but as you say the majority of testing is done with vm | 07:14 |
| infinity | Or, rather, I don't care deeply about *desktop* VMs (except for the above mentioned QA concern). | 07:15 |
| infinity | Server VMs are a whole different story, but if you're running lightdm on a server, you should probably find a new job that doesn't involve being near servers. | 07:15 |
| elfy | infinity: I understood what you meant | 07:15 |
| mlankhorst | anyway mesa in unapproved now :P | 07:21 |
| infinity | mlankhorst: I'll review and pick it up in the morning, and then we can talk unblocking it for the beta. | 07:21 |
| mlankhorst | oke | 07:22 |
| jibel | the fact that it's reproducible on VMs doesn't mean it is not a problem on hardware too, until we know what causes it. | 07:32 |
| cyphermox | would it be possible to unblock wpa despite the freeze? I think it would benefit everyone, especially those who work in office buildings where the roaming issues are more likely to happen, and is critical for touch :) | 09:01 |
| jibel | seb128, could someone look at bug 1371651 ? it happens on all the flavours in vbox and qemu, I didn't try on hardware. | 09:10 |
| ubot2 | bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] https://launchpad.net/bugs/1371651 | 09:10 |
| seb128 | jibel, that would be one for robert_ancell but he already called it a day at this time I think | 09:11 |
| jibel | seb128, anyone else? looks like a race in the boot sequence. lightdm doesn't even try to start | 09:12 |
| seb128 | jibel, not sure, maybe jodh can help if an upstart job issue? | 09:13 |
| jamespage | please could the nova-compute-flex packages be rejected from the NEW queue - zul and I reviewed last night and we want to make some changes prior to acceptance into the archive | 09:16 |
| jibel | jodh, ^^ any idea about bug 1371651, I attached syslog with --debug enabled | 09:18 |
| ubot2 | bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] https://launchpad.net/bugs/1371651 | 09:18 |
| JackYu | hi, release team, who could help to look at the Critical bug #1372731? | 09:20 |
| ubot2 | bug 1372731 in Ubuntu Kylin "the slideshow for ubuntu kylin utopic beta-2 rc is ubuntu's slideshow" [Critical,Confirmed] https://launchpad.net/bugs/1372731 | 09:20 |
| JackYu | cjwatson, infinity, ping... | 09:25 |
| cjwatson | looks like livecd-rootfs is using the wrong live task | 09:32 |
| JackYu | cjwatson, thanks. Could you fix it? | 09:35 |
| cjwatson | usually when I make that kind of comment it's stream-of-consciousness on the way to fixing it :P | 09:35 |
| JackYu | cjwatson, great^ ! | 09:36 |
| cjwatson | stgraber: committing your livecd-rootfs change to bzr so that I can commit more stuff on top | 09:59 |
| cjwatson | infinity: ^- could you please review livecd-rootfs for ubuntukylin? | 10:11 |
| Laney | where do the actual sources.list buildd chroot overrides live? | 10:15 |
| Laney | Want to check how backports is handled | 10:15 |
| cjwatson | Laney: lp:launchpad, lib/lp/soyuz/adapters/archivedependencies.py | 10:32 |
| Laney | cjwatson: Cheers - I was hunting for https://bugs.launchpad.net/launchpad/+bug/888665/comments/27 which I found in the chroot itself | 10:37 |
| ubot2 | Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Fix released] | 10:37 |
| JackYu | cjwatson, hi, it seems that livecd-rootfs was updated, should we rebuild the iso for beta-2? | 11:24 |
| cjwatson | JackYu: No, it's still waiting for review in the queue. | 12:03 |
| cjwatson | JackYu: I can't (well, shouldn't) review my own change there, so can't help further right now. | 12:04 |
| Laney | Accepted | 12:14 |
| Laney | Don't know if you want a respin given the probably lightdm one | 12:15 |
| Laney | probable | 12:15 |
| JackYu | cjwatson, Laney, thanks. Let me try.. | 12:22 |
| Laney | It'll take a while to get into the release | 12:23 |
| cjwatson | you need to check "rmadison livecd-rootfs" before triggering builds | 12:23 |
| cjwatson | it must be >= 2.246 | 12:23 |
| cjwatson | specifically "rmadison -s utopic livecd-rootfs", in fact | 12:23 |
| JackYu | OK, I will check. | 12:26 |
| cjwatson | Laney: would you care to review python-apt and software-properties as well (mostly my changes so I can't review)? We want those in ubuntu-rtm sooner rather than later really | 12:28 |
| cjwatson | Bit of a stack behind them | 12:28 |
| Laney | cjwatson: 'kay, just disappearing for lunch though but after that | 12:29 |
| mlankhorst | xnox: hey is https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1242572 still important? | 12:35 |
| ubot2 | Launchpad bug 1242572 in xkeyboard-config (Ubuntu) "xkeyboard-config, console-setup, and ubiquity should use Super+Space for switching keyboard layouts" [Medium,Confirmed] | 12:35 |
| === superm1_ is now known as superm1 | ||
| === smow is now known as pfsmorigo | ||
| ypwong | JackYu, new livecd-rootfs ready | 13:57 |
| stgraber | cjwatson: oops, sorry about that, thanks for taking care of it! | 14:01 |
| JackYu | ypwong, thanks, rebuilding... | 14:13 |
| Laney | cjwatson: Accepted | 14:23 |
| Laney | Will be subject to the block | 14:23 |
| cjwatson | That at least gives me binaries to copy, thanks | 14:24 |
| stgraber | cjwatson, slangasek, infinity: hey, so I've been chatting with hallyn about an ipxe issue he's having when migrating VMs between precise and trusty. Apparently qemu is a bit retarded and requires that the option ROMs match perfectly on the source and target, otherwise VM restore fails. As a result, hallyn is looking for a way to get precise's ipxe on trusty. | 14:47 |
| stgraber | one of my suggestions is to have a ipxe-legacy package or something of the sort which at build time downloads and extracts the option roms from the past releases and then ships those inside its own binary package. Now the question is, is that something we can actually get into the archive, seeing how it wouldn't be entirely trivial to find the matching source? | 14:48 |
| stgraber | I guess the package could include the series and package version that was used as the source of each of the binaries so someone can then go fetch the source for that one either from archive.u.c or from old-releases.u.c or directly from LP, but not nearly as easy as it'd usually be | 14:49 |
| cjwatson | I can't think of a good answer for that | 14:50 |
| cjwatson | Is there really no way to relax qemu? | 14:51 |
| cjwatson | Alternatively, have the upgrade process take copies of the old files in the preinst until it's sure (somehow) that it doesn't need them any more; I think I've seen that done somewhere else and it would be simpler ... | 14:51 |
| stgraber | so apparently it's not just a pointless check in qemu, feeding it the wrong binary (say, padded with zeros at the end) makes it fail on reboot | 14:51 |
| cjwatson | After all you *only* need this on upgraded systems | 14:51 |
| stgraber | cjwatson: no, you don't. The use case is two hosts, one on precise, one on trusty, both fresh installed, then live migrate a VM between the two | 14:52 |
| cjwatson | Ugh | 14:52 |
| cjwatson | You would have to ship the source somehow; I don't know whether it's still possible to build it, maybe with an old compiler and just the right options | 14:53 |
| cjwatson | Shipping source that it isn't actually possible to build doesn't count as source IMO :P | 14:53 |
| stgraber | cjwatson: ok, so pointing to the precise source package isn't good enough then? because if you do run a precise system and build the binary on it, you will get the expected binary :) | 14:54 |
| cjwatson | It's a pretty grey area, but this feels on the dark side of grey to me | 14:55 |
| stgraber | ok | 14:55 |
| stgraber | hallyn: so preferred way would be to just ship the precise source in trusty, potentially tweaking it to use the same compiler and other bits to ensure we don't have any potential size difference or broken binary | 14:56 |
| hallyn | so yanking the prcise .deb and extracting the rom would be frowned upon then? | 14:57 |
| stgraber | hallyn: with the obvious and preferred alternative being to just fix qemu to be a bit more reasonable (say, just store the path in the migrate state and only read said file at boot time) | 14:57 |
| cjwatson | The benchmark for me is whether a user can actually make changes to the source we supply | 14:57 |
| cjwatson | If it's this picky it kind of feels to me as though the option ROMs should be stored in the migrate state ... | 14:58 |
| cjwatson | But I know little about qemu internals | 14:58 |
| hallyn | is building a container inside the package build to build the old packag in ok? :) | 14:59 |
| hallyn | agreed, and i think rharper has (this week) been discussing that with upstram | 14:59 |
| cjwatson | Only if you can do that unprivileged | 14:59 |
| hallyn | but that doesn't help the current case - which, fwiw, is to enable migration from precise->trusty | 14:59 |
| hallyn | what kernel are the buildds on? | 14:59 |
| stgraber | well, you don't need a container, fakeroot+fakechroot+debootstrap mostly works | 14:59 |
| cjwatson | hallyn: look at the top of any build log | 14:59 |
| stgraber | and we've got a few packages doing that kind of ugliness already | 14:59 |
| hallyn | i wasn't sure if they were all the same these days | 14:59 |
| cjwatson | they're the same across non-virt x86 | 15:00 |
| hallyn | but again - pulling the ro mfrom the precise package, which is build all from source, doesn't really violate the "user can make changes to the source we supply" bencmark | 15:00 |
| cjwatson | I dunno, I don't feel persuaded but I cannot currently properly articulate my counterarguments | 15:00 |
| cjwatson | sorry | 15:00 |
| hallyn | np, i'm just looking for the best way, don't parcticularly care what that ends up being | 15:01 |
| cjwatson | it feels like an RC bug of the form "can't rebuild this from source in the latest release" | 15:01 |
| hallyn | buildds ar eon 3.2, not good enough for unpriv containers ,so i'd have to go with regular fakeroot+ | 15:01 |
| hallyn | true | 15:01 |
| hallyn | tbh right now the precise package does build (with one change) in trusty just fine, so we don't (currently) need t oworry about the chrooting | 15:02 |
| cjwatson | oh well that sounds like the path of least resistance then | 15:02 |
| hallyn | until the next isolinux breaks the build a bit more | 15:03 |
| hallyn | so is it preferred that i 'pull-lp-source' the package fro mdebian/rules, or include the source in the trusty package source? | 15:03 |
| cjwatson | latter IMO | 15:03 |
| stgraber | hallyn: so I think so long as the only time we care about this is precise to trusty, just getting the precise source SRUed to trusty and then depend on it should do the trick. That's assuming qemu will be a bit more reasonable going forward and we won't run into that problem with every single Ubuntu release in the future. | 15:03 |
| cjwatson | with a "make update" or similar | 15:03 |
| cjwatson | I suspect you can't talk to the Launchpad webapp from the buildds anyway | 15:04 |
| hallyn | rharper: ^ do you think that in the next 6 months we may get reasonable handling of romfiles on migration? | 15:04 |
| cjwatson | only to the archive itself | 15:04 |
| hallyn | I don't know what 'make update' is | 15:04 |
| cjwatson | a hypothetical target to update the source from the archive on a developer's system | 15:05 |
| stgraber | either one source package with a make update as suggested by cjwatson or make a sed script which you can run against the ipxe source in precise to turn it into a new ipxe-legacy source package | 15:05 |
| stgraber | basically the exact same trick we do for HWE backports, except that one will be the other way around :) | 15:05 |
| hallyn | you mean just to make it so it builds ok in trusty? | 15:05 |
| cjwatson | yeah | 15:05 |
| cjwatson | ubiquity has to embed other source packages for different reasons and does this kind of thing | 15:05 |
| rharper | hallyn: upstream? I don't know; we'd need to provide a proposal; any change to migration (and savevm) format is going to be controversial | 15:06 |
| rharper | likely met with "it's a downstream" problem | 15:06 |
| hallyn | this isn't about the machine type, it's purely about needing versioned romfiles to migrate across versions | 15:07 |
| rharper | hallyn: it's a support issue w.r.t where the boundaries are w.r.t migration support | 15:07 |
| rharper | the only place you can be certain migration works (modulo bugs in the code) is between same architecture , same OS version, and same QEMU versions | 15:08 |
| rharper | as soon as you change one of those, the likelihood of failure is MUCH MUCH higher, and a vendor needs to validate that specific deviations work | 15:08 |
| rbasak | Could you pull it out of the scope of the archive? | 15:08 |
| rbasak | We already publish resources needed by other tools that are "trans-release", IYSWIM. | 15:08 |
| hallyn | stgraber: above you said "just getting the precise source SRUd to trusty and then depend on it" - that makes it sound like you're talking about a separate 'ipxe-legacy' package, as opposed to shipping the precise ipxe source under debian/legacy in the ipxe trusty source? | 15:09 |
| rbasak | MAAS needs installer images from multiple releases, for example. | 15:09 |
| cjwatson | possible; would probably require Launchpad work | 15:09 |
| rbasak | How about a simplestream feed of ROMs extracted from different releases? | 15:09 |
| stgraber | hallyn: correct. There are basically two ways of doing things, either a single source package with both source trees and an update script as suggested by cjwatson or just take the whole source package from precise, rename all occurences of ipxe to ipxe-legacy in there, apply your patch and upload as a new source. Then update ipxe to recommend ipxe-legacy. | 15:10 |
| hallyn | rbasak: what would guide the fetching and installing of those? (it coudl be a nicer solution than messing with the ipxe source) | 15:11 |
| rbasak | hallyn: we have simplestreams tools in the archive, so it shouldn't be too difficult. | 15:11 |
| hallyn | stgraber: i didn't think the latter would be possible for trusty as an sru | 15:12 |
| stgraber | hallyn: we've been introducing new packages as SRUs in the past, there's no technical issue with that but it's pretty rare | 15:13 |
| hallyn | rbasak: but it would require a whole new repo of roms | 15:13 |
| rbasak | True. | 15:13 |
| rbasak | That can be a fairly static web resource though. | 15:13 |
| stgraber | rbasak: you do ultimately get into the same problem though, you're shipping a binary for which the source is only available in an old, possibly out of support release and where you can't actually rebuild it to produce an identical binary (because of toolchain variations over time) | 15:14 |
| rbasak | stgraber: I think it's reasonable this way round though. | 15:14 |
| rbasak | You're publishing the binary out of a binary distribution for which the entire source is available. | 15:15 |
| rbasak | You can rebuild the binary using the release of the distribution from which it is from. | 15:15 |
| stgraber | rbasak: the exact same was true of the initially suggested idea of just having the package build in trusty grab the binary from precise, and that was deemed not good enough | 15:15 |
| rbasak | I think there's a difference here. | 15:16 |
| rbasak | It's assumed that all binaries in Trusty can be rebuilt entirely from Trusty sources. | 15:16 |
| cjwatson | it makes me uncomfortable so I don't think I'm prepared to say I'd accept it. I haven't actually vetoed it | 15:16 |
| rbasak | That assumption breaks in that case. | 15:16 |
| cjwatson | but certainly actually grabbing it from a precise-generated repo would be simpler in some ways | 15:16 |
| rbasak | OTOH, take it out of the scope of the archive, and that invariant still holds. | 15:16 |
| stgraber | rbasak: the other concern I've got with the out of the archive method is that any corporate environment will likely have a local mirror and firewall off external access, so they won't be able to get those binaries | 15:17 |
| rbasak | stgraber: true. simplestreams is a format designed to make it easy to mirror though. | 15:18 |
| stgraber | and that may be all fine as a solution going forward, but pushing that as a SRU would seem like a pretty severe regression to me | 15:18 |
| rbasak | MAAS and Juju have the same concern, and it's a unifying format for anything that needs to be mirrored and cryptographically verified. | 15:18 |
| rbasak | I agree it's not great in an SRU, but is it really a regression if the whole thing is broken already and the solution is that you need to mirror a binary? | 15:18 |
| stgraber | hmm, true, if the only thing we were to ship that way was the precise binary on trusty, that may be fine | 15:20 |
| rbasak | The only thing I'm suggesting publishing this way is the necessary binary. | 15:20 |
| rbasak | Nothing else. Everything else, including support code, can come via an SRU. | 15:20 |
| stgraber | I still think the best fix here is just get the precise source into trusty, solving the immediate problem withouth much more complexity, then fix qemu to be more reasonable, either by storing the ROM content in its state or by loading the blob entirely back from disk every time it needs it | 15:21 |
| rbasak | It does sound reasonable that qemu should send across the ROM contents during a live migration if it requires it on the other end. | 15:21 |
| rbasak | My suggestion is definitely a long term thing. Pointless if it's just a one-off. | 15:22 |
| ogra_ | is there a chance someone could let the HUD out of unapproved ? it has a touch only fix in it that blocks otehr landings | 15:22 |
| rbasak | Especially if the precise source will built on Trusty and generate the required binary there. Then just import the source into Trusty under a different name. | 15:22 |
| stgraber | we also have another problem here which thankfully we haven't ran into yet, if I was to SRU an iPXE bugfix in precise and that'd make the binary say 900 bytes larger somehow, then I'd be into the weird case where I'd have running VMs expecting the older smaller binary and some running with the new larger one, what happens when we try to migrate both of those set of VMs? | 15:22 |
| stgraber | rbasak: it currently does with just a small change to the source apparently, so we're lucky in that sense | 15:23 |
| hallyn | rbasak: so yeah lets keep that in mind for a longer term solution. bc i also expect more headaches inthe future from toolchain changes which make building the legacy version in modern releases. | 15:23 |
| rbasak | So with simplestreams, you could publish all the binaries. | 15:23 |
| hallyn | perhaps something to discuss at uds | 15:23 |
| rbasak | As long as the other end can figure out which one it wants, you could get it. | 15:23 |
| hallyn | so i'll work on a ipxe-legacy package this afternoon. thanks all. | 15:23 |
| rbasak | (by version, or sha256, or any other key) | 15:23 |
| stgraber | rbasak: except that qemu only knows about a single, non-versioned, path :) | 15:23 |
| rbasak | Try each until it doesn't fail :-P | 15:24 |
| rbasak | (yeah that's terrible I know) | 15:24 |
| stgraber | :) | 15:24 |
| hallyn | stgraber: true (single non-versoined path) and we need a libvirt change to handle that | 15:24 |
| hallyn | so this really does need to be handled in qemu source longer-term | 15:24 |
| stgraber | hallyn: have you tried live migrating an OVMF backed VM? surely the same will happen with the OVMF blob | 15:24 |
| hallyn | (libvirt has to pass an option to qemu to tell it to use the older file) | 15:24 |
| hallyn | stgraber: haha. no. haven't touched ovmf other than to push annoying papers away with those letters on them | 15:25 |
| stgraber | :) | 15:28 |
| hallyn | rharper was mentioning it yesterday though. sounded like it does not in fact handle that yet | 15:28 |
| rharper | OVF (not sure about OVMF) is just a container (tarball) libvirt doesnt run an OVF, some other mgmt tool needs to unpack, define, and start | 15:29 |
| cjwatson | OVMF is a UEFI BIOS image for VMs | 15:31 |
| cjwatson | entirely different :) | 15:31 |
| rharper | ah | 15:32 |
| rharper | stgraber: qemu/libvirt do not migrate any of the rom files associated with a VM; rather the assumption is the destination host is "compatible" with the source; that's a problem left up to the management application orchestrating the migration in the first place. | 15:33 |
| Odd_Bloke | rcj: o/ | 15:40 |
| mdeslaur | the bash update I just uploaded to utopic is a critical security fix | 15:49 |
| cjwatson | mdeslaur: thanks, reviewing | 16:04 |
| mdeslaur | cjwatson: thanks | 16:06 |
| cjwatson | infinity: we could make an argument for respinning the world for this bash vuln | 16:12 |
| cjwatson | maybe | 16:13 |
| === bladernr_ is now known as bladernr_30kFeet | ||
| zul | can yo ureject the nova-compute-flex again | 16:22 |
| ogra_ | mdeslaur, can we have it into rtm too ? | 16:24 |
| cjwatson | ogra_: how about I copy it directly? | 16:25 |
| * sil2100 is fine with that | 16:25 | |
| cjwatson | I think I need to wait for it to be published first though | 16:26 |
| mdeslaur | utlemming: you probably want new ec2 images for that bash update also | 16:30 |
| cjwatson | ogra_,mdeslaur,sil2100: copied to rtm now | 16:35 |
| mdeslaur | cjwatson: thanks | 16:35 |
| sil2100 | cjwatson: thanks! | 16:38 |
| utlemming | mdeslaur: ack, incidently our images will automagically respin once it hits the archive | 16:44 |
| utlemming | mdeslaur: but yeah, we'll have new images for that | 16:44 |
| mdeslaur | utlemming: sweet, wasn't sure if that was being done yet or not. glad to hear it is. | 16:44 |
| utlemming | mdeslaur: the only part that is manual for us is the promotion to calling it beta-2. Otherwise cloud images are automagically built on archive changes. | 16:46 |
| infinity | rbasak: FWIW, I wish people wouldn't recommend simplestreams as a knee-jerk response to distribution methods. :P | 16:51 |
| infinity | rbasak: While it's technically true that it's designed to be mirrored/mirrorable, every time you ask a customer/user to mirror Yet Another Repository, you've upped the complexity by a ton. | 16:52 |
| infinity | rbasak: Especially in a case like this qemu thing, where it's entirely non-obvious that they'd need to do so without, perhaps, reading some obscure README along the way. It's not like juju, where it kinda just fails to be useful until you've understood why. | 16:52 |
| infinity | Fundamentally, any time we do anything outside the archive.ubuntu.com FTP tree, there better be a really good reason for it, not just an "oh, this is hard in the archive, let's push the burden elsewhere, whee". | 16:53 |
| lool | Hey, so network-manager in unapproved improves the reporting of visible WiFis; changes were discussed with upstream and tested by Mathieu, HERE folks and myself | 16:56 |
| lool | basically too many / too old wifis were reported prior to this change | 16:57 |
| lool | mathieu tested on desktop | 16:57 |
| infinity | Hrm, that langpack upload timing was unfortunate. | 16:58 |
| cjwatson | stgraber: shouldn't ~ubuntu-archive/auto-accept have some kind of lock if it's going to run at * * * * * ? | 16:58 |
| infinity | cjwatson: Probably, though it shouldn't take longer than a minute. | 17:00 |
| infinity | (Maybe the langpack-fest has broken that assumption, though) | 17:00 |
| cjwatson | infinity: I just saw two running at once, which is why I asked. | 17:00 |
| stgraber | oh, that's the first time I hear of it taking more than a minute | 17:00 |
| infinity | stgraber: Probably owing to the 292 queue items. | 17:01 |
| jdstrand | fyi, cups just has some apparmor updates, no code changes | 17:02 |
| wxl | cjwatson: i figure you're probably the best contact on this subject. any idea what is amiss here? https://bugs.launchpad.net/ubuntu/+source/yaboot/+bug/1367448 | 17:19 |
| ubot2 | Launchpad bug 1367448 in yaboot (Ubuntu) "kernel 3.16.0-14-powerpc-smp won't boot" [Undecided,Confirmed] | 17:19 |
| rsalveti | stgraber: was planning to sync livecd-rootfs into rtm, but saw there's one big change regarding groups and so on that you pushed | 17:21 |
| rsalveti | stgraber: anything you want to test/validate first or do you think the sync should be fine? | 17:21 |
| infinity | wxl: Hrm, the kernel could have gotten too big for yaboot again. :/ | 17:24 |
| infinity | wxl: I meant to switch powerpc to grub this cycle, I probably should have found time for that. | 17:25 |
| wxl | infinity: didn't realize that was a common problem. any ideas on solutions? | 17:25 |
| wxl | infinity: it's sad that i've been trying hard as all get out to get ppc testers and it takes until beta 2 for people to finally start helping argh | 17:25 |
| infinity | wxl: Well, that's just a shot in the dark, but it's happened before. | 17:25 |
| wxl | infinity: who might i point this at that could better assess the situation? | 17:26 |
| infinity | wxl: Me or cjwatson, I suppose, but I'm not sure we'll be able to diagnose and fix for the beta. | 17:27 |
| wxl | infinity: well even if we could aim for the release that might be nice. at least looking into it would help and perhaps encourage our ppc testers to get off their you-know-whats next cycle :) | 17:28 |
| infinity | wxl: I have a yaboot-using PPC machine running trusty here, I can slap the utopic kernel on it and see if it explodes. | 17:28 |
| infinity | Ideally, though, we should ditch yaboot and move to grub2. But if this is what I think it is, it'll affect upgrades, which is a nastier problem. | 17:28 |
| infinity | This happened sometime between hardy and lucid too. | 17:29 |
| wxl | infinity: well that's good to know! | 17:30 |
| wxl | as far as grub2, yeah, i guess that deserves some discussion | 17:30 |
| wxl | i certainly like the notion of being more standardized | 17:30 |
| infinity | wxl: I think the only discussion required for grub2 is to decide on someone doing the work. :P | 17:31 |
| wxl | hahahah | 17:31 |
| wxl | i thought you were volunteering infinity :) | 17:31 |
| infinity | wxl: Well, and if we try to forcefully upgrade people's bootloaders, or just ship new installs with grub2 and let old ones stay yabooty on upgrade. | 17:31 |
| wxl | that seems like a legitimate approach | 17:31 |
| infinity | But letting old ones stay with yaboot implies making sure yaboot works. :P | 17:32 |
| wxl | yeah well that right there may be a good argument for forcefully changing | 17:32 |
| wxl | i mean the arch *IS* community supported. is it safe to assume that community can handle supporting yaboot ad infinitum? | 17:33 |
| infinity | wxl: IBM still uses yaboot internally, so it has an active upstream, but yeah, I don't think it's sane for us to pretend we can/will support it ourselves when things go wonky like this. | 17:34 |
| infinity | wxl: Oh, hrm, the two reports I can find are both 32-bit. I don't have any 32-bit hardware with yaboot. | 17:42 |
| infinity | wxl: I'll test on my 64-bit machine, but if that Just Works, then this'll be a bit more fun to diagnose. | 17:42 |
| wxl | infinity: yeah memory's a little different there, eh? bummer. | 17:42 |
| wxl | infinity: lars who reported it in iso testing is a Good Guy. he's always willing to help. i'm sure he could provide assistance where needed. | 17:43 |
| infinity | My 32-bit machine can't run yaboot, so that's less helpful. :P | 17:43 |
| stgraber | rsalveti: sync should be fine. The change will prevent the uid/gid changes and will fail your build and get you a diff if anything extra shows up. So it's perfectly safe to sync but you may need to tweak the included user and group lists if your next build fails. The provided diffs will make that pretty easy as you can basically just copy/paste from them if they make sense. | 17:45 |
| rsalveti | stgraber: great, will sync and trigger a new image then, thanks! | 17:46 |
| infinity | wxl: trusty yaboot and utopic kernel boot fine on 64-bit, FWIW. So, yeah, this'll need some deeper digging that I can't do locally. :/ | 17:52 |
| wxl | infinity: well let me know if you come up with anything else | 17:53 |
| infinity | wxl: I might be able to test/diagnose with qemu, but I certainly won't have time to do it in the next 24h. | 17:58 |
| wxl | infinity: yeah and my luck with virtualized ppc has not been great. it'll take 24h just to load up the OS :) | 18:00 |
| infinity | -CONFIG_KERNEL_START=0xc0000000 | 18:16 |
| infinity | -CONFIG_PHYSICAL_START=0x00000000 | 18:16 |
| infinity | +CONFIG_KERNEL_START=0xc2000000 | 18:16 |
| infinity | +CONFIG_PHYSICAL_START=0x02000000 | 18:16 |
| infinity | Could be this... | 18:16 |
| infinity | wxl: Do you have a machine that's affected by this, or are you just relaying for others? | 18:23 |
| wxl | infinity: relaying mostly. i have a 64 ppc and that's about it :( | 18:24 |
| wxl | infinity: but i'm happy to help coordinate. as the release manager for lubuntu, i'm trying REALLY hard to keep ppc alive.. | 18:24 |
| infinity | wxl: Well, I might spin up a test kernel later today, if you can find someone to test it. It won't get fixed for the beta, but if we know we have a fix in the pipe, we can just release the image with a caveat that it only works on 64-bit machines until the next daily that includes a new kernel. | 18:32 |
| wxl | infinity: can do | 18:32 |
| ogra_ | stgraber, rsalveti, oh, i thought cjwatson wanted the software-properties fixes landed before syncing livecd-rootfs | 18:38 |
| rsalveti | ogra_: that was published | 18:38 |
| ogra_ | oh, which did already happen | 18:38 |
| ogra_ | yeah, ignore me | 18:38 |
| * ogra_ hides in a corner | 18:38 | |
| mdeslaur | The nss update fixes a critical vulnerability | 19:04 |
| infinity | wxl: Okay, pretty sure we found the problem and fixed it blind. | 19:04 |
| mdeslaur | cjwatson: ^ | 19:04 |
| mdeslaur | cjwatson: also needs to be copied to rtm | 19:04 |
| wxl | infinity: what 't'was? | 19:04 |
| mdeslaur | (details: https://www.mozilla.org/security/announce/2014/mfsa2014-73.html) | 19:04 |
| infinity | wxl: See the tail end of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1363180 | 19:05 |
| ubot2 | Launchpad bug 1363180 in linux (Ubuntu Utopic) "utopic alternate install CD doesn't boot" [Medium,Confirmed] | 19:05 |
| infinity | wxl: Personally glad it didn't turn out to be a yaboot bug. Boot loaders being unable to load $nextseries kernels are an upgrade nightmare. :P | 19:06 |
| wxl | excellent thanks infinity. should i consider the other bug a dupe of this? | 19:06 |
| infinity | wxl: I already duped the other one. | 19:06 |
| wxl | ah wonderful thank you infinity ! | 19:06 |
| wxl | infinity: could you give me a heads up when the dailies have the fix in them? | 19:07 |
| infinity | wxl: I'll try to remember, but best to just subscribe to the bug and see when it's fixed. The next daily after the fixed kernel is in will work. | 19:09 |
| wxl | oh right, derp thanks :) | 19:10 |
| infinity | wxl: And you can just notify your testers that testing the beta on 32-bit kit is a lost cause, and just focus on 64-bit testing. | 19:11 |
| wxl | infinity: well, at least for release, yeah. working on it. | 19:11 |
| wxl | meanwhile i'm glad to see progress is being made on the lightdm, now upstream issue :) | 19:12 |
| rbasak | infinity: I'm just seeing a pattern here. So much stuff at the moment seems to be "trans-" release, IYSWIM. That doesn't fit well with the existing model. | 19:13 |
| infinity | rbasak: juju is a unique snowflake in this case, really. I'm not sure it's fair to say it's a common problem. | 19:14 |
| infinity | rbasak: The qemu thing can be treated as a one-off, I think. | 19:14 |
| infinity | rbasak: If it really does turn out to be a common problem going forward, I think it's worth discussing the simplestreams stuff being hosted under the archive.ubuntu.com tree. | 19:17 |
| infinity | rbasak: Cause it's wildly unintuitive and a bit hostile to people with longstanding Debian/Ubuntu backgrounds to suddenly require mirroring extra stuff just to make an internal mirror work. | 19:18 |
| infinity | rbasak: (It's possibly worth having that discussion just for the sake of juju, really, even if nothing else needs it) | 19:18 |
| mlankhorst | \o/ | 19:28 |
| mdeslaur | infinity: perhaps you could handle the critical nss release to utopic, and the copy to rtm? cjwatson didn't respond. | 19:29 |
| infinity | mdeslaur: I can certainly handle the former. | 19:29 |
| infinity | And only a 500k diff... | 19:30 |
| mdeslaur | infinity: new upstream, sorry | 19:30 |
| infinity | Hrm, how did that ppc64el patch ever work, I wonder? | 19:31 |
| infinity | It was testing for ppc64el, not ppc64le. | 19:31 |
| infinity | mdeslaur: Also, what's with the weird empty changelog entry? | 19:33 |
| infinity | +nss (2:3.17.1-0ubuntu1) utopic; urgency=medium | 19:33 |
| infinity | + | 19:33 |
| infinity | + * SECURITY UPDATE: update to 3.17.1 | 19:33 |
| infinity | + - see USN-2361-1 | 19:33 |
| infinity | + * debian/libnss3.symbols: updated for new version. | 19:33 |
| infinity | + * debian/patches/38_ppc64le.patch: removed, upstream. | 19:33 |
| infinity | + | 19:33 |
| infinity | + * | 19:33 |
| infinity | + | 19:33 |
| mdeslaur | infinity: we didn't get _any_ details on what the issue was | 19:33 |
| infinity | + -- Marc Deslauriers <marc.deslauriers@ubuntu.com> Wed, 24 Sep 2014 07:58:07 -0400 | 19:33 |
| mdeslaur | oh, wait, there's an extra line? | 19:33 |
| * mdeslaur looks | 19:34 | |
| mdeslaur | argh, wth | 19:34 |
| mdeslaur | infinity: I can re-upload if you want, didn't notice that | 19:34 |
| infinity | mdeslaur: Go ahead. :) | 19:34 |
| infinity | mdeslaur: I'm nothing if not a pointlessly anal-retentive jerk about these things. :P | 19:35 |
| mdeslaur | don't worry, that makes two of us :) | 19:35 |
| hallyn | hm, i was goign to call the legacy ipxe package 'ipxe-legacy', but i suppose calling it 'ipxe-precise' would be more future-proof? | 19:36 |
| infinity | hallyn: If we suspect we'll have to do this again in the future, yeah. | 19:37 |
| infinity | hallyn: I'd like to have to, mind you. | 19:37 |
| hallyn | yeah i've got a nasty feeling i'tll happen again | 19:37 |
| hallyn | you'd like to have to? do it again? | 19:38 |
| infinity | Err, not have to. | 19:38 |
| infinity | Fingers missed a word. | 19:38 |
| infinity | Riddell / ScottK: I assume the mess of KDE stuff in the queue is for post-beta? | 19:39 |
| infinity | Riddell / ScottK: Or were you planning to jam it all in and respin ASAP? | 19:39 |
| mdeslaur | lol "Rejected by Adam Conrad: spite" | 19:41 |
| infinity | mdeslaur: That might be my default rejection reason when I have nothing more constructive (and when I know the uploader). | 19:44 |
| infinity | I'm a little more polite with people who don't know me. :P | 19:44 |
| mdeslaur | hehe | 19:44 |
| infinity | I'm not sure how I'm meant to be productive with a purring ball of fluff attacking me. | 19:47 |
| stgraber | infinity: I'd recommend you let unity-settings-daemon through, that'll save you a bunch of space on the beta-2 media, the current version depends on a bunch of -dev packages for no good reason | 20:04 |
| infinity | stgraber: Ew. | 20:09 |
| infinity | zequence: Is anyone doing ubuntustudio beta testing? | 20:11 |
| zequence | infinity: I will be, yep | 20:15 |
| infinity | zequence: Kay, just wanted to make sure someone was, since I saw no results yet. | 20:17 |
| slangasek | infinity: so you're driving final beta - bash in utopic-proposed is a security update; can it be hinted through? | 21:24 |
| xnox | did i file an FFe bug correctly? I was hoping to land updated btrfs for beta, I guess that's a tad late for that https://bugs.launchpad.net/ubuntu/+source/btrfs-tools/+bug/1372367 | 22:20 |
| ubot2 | Launchpad bug 1372367 in btrfs-tools (Ubuntu Utopic) "FFe Upgrade btrfs-tools to 3.16" [Undecided,New] | 22:20 |
| xnox | but would be great for final. | 22:20 |
| xnox | there is a new point release however that I still need to package, so there will be another update after that. | 22:20 |
| xnox | I made it be blocked in proposed until release team approval. | 22:21 |
| Riddell | infinity: yeah post beta | 22:47 |
| infinity | slangasek: It can be, yeah. We'll pick it up on the respin, if/when that happens (I'd like to see a lightdm fix happen, but not sure if it will) | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!