| slangasek | Laney, xnox, ScottK: the systemd RC bug is resolved now (bug #1154813) | 02:22 |
|---|---|---|
| ubot2 | Launchpad bug 1154813 in initramfs-tools (Ubuntu) "Boot broken with initramfs-tools 0.103ubuntu0.5b1 - wait-for-root doesn't wait" [Critical,Fix released] https://launchpad.net/bugs/1154813 | 02:22 |
| xnox | slangasek: I also noticed pitti's comment on the FFe "block is in place until after beta1 is shipped" | 02:22 |
| * xnox would like the block lifted, but I guess Laney/pitti should be lifting it. | 02:23 | |
| xnox | 38 packages held. | 02:24 |
| xnox | Laney: wasn't chromium-browser was supposed to be let through even without up to date armhf build?! | 02:24 |
| ScottK | slangasek: OK. At this point I'm not sure I want to be the one that let libudev1 into raring on Friday, so I'll wait for Laney to remove the block. | 03:40 |
| infinity | xnox: chromium-browser isn't being held up because of armhf. | 03:53 |
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| tumbleweed | aah, unity was sabdfl'ed | 07:54 |
| jamespage | Daviey, we need to push a point release of python-quantumclient to raring for the upcoming rc's of openstack core projects | 09:10 |
| jamespage | 2.1.2 -> 2.2.0 | 09:10 |
| jamespage | we have been using this in the CI lab for some time - I've also been testing with trunk of everything for the last four days and I've seen no issues with the new client version | 09:11 |
| jamespage | Daviey, do we need a FFe? | 09:11 |
| Daviey | jamespage: is 2.1.2 not compatible ?! | 09:11 |
| Daviey | jamespage: Compatibility aside, before the client broke out - we'd have tracked it to final.. so 2.2.0 is the version we should be carrying. I think you should proceed. | 09:13 |
| jamespage | Daviey, it does not have support for newer bits and pieces in quantum that landed since 2.1.2 | 09:13 |
| jamespage | Daviey, ack | 09:14 |
| Laney | xnox: repeated pinging at 02:20 isn't likely to get it done | 09:23 |
| Laney | it was a block for pitti so I was waiting for pitti to ask me to lift it himself, which came this morning | 09:24 |
| xnox | Laney: ack. \o/ yeah, stuff I care about has migrated ;-) | 09:36 |
| === yofel_ is now known as yofel | ||
| cjwatson | stgraber: I fixed up ownership of various files, which was the source of your 'cp -al www www.prev' problem; not sure why that didn't happen last time | 09:42 |
| cjwatson | stgraber: I *thought* I'd preserved the oversizedness note; I don't have a specific test case for it, though, so I'll look into that | 09:44 |
| cjwatson | slangasek: So I wrote in https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview that people need to upgrade to 12.10 first, and this was largely just from inertia; do we want to declare that you can upgrade directly from 12.04 LTS, to avoid encouraging further upgrades via 12.10? | 10:22 |
| seb128 | cjwatson, don't we only support LTS to LTS+1 et <n> to <n+1>? | 10:27 |
| seb128 | et->and | 10:27 |
| seb128 | cjwatson, e.g do we do any testing for 12.04->13.04? | 10:27 |
| cjwatson | Well, sure, right now, but we can't continue that practice if we're going to be de-emphasising non-LTS releases | 10:42 |
| cjwatson | jibel: ^- How hard would it be to set up precise-to-raring upgrade tests in jenkins? I don't see any right now | 10:44 |
| jibel | We don't test this ATM, but it shouldn't be hard if it is supported by the upgrader. I'll have a look. | 10:49 |
| infinity | cjwatson: Given that we need to support 12.04->14.04 anyway, I think it's the Right Thing to always make sure that we support LTS->current, it makes our jobs MUCH easier when prepping the next LTS if we haven't been ignoring it for two years. | 10:52 |
| infinity | cjwatson: So, I'm all in favour of a QA and culture shift there. | 10:52 |
| cjwatson | That was much my thought | 10:52 |
| cjwatson | It's in our interest regardless of any release cycle changes; and it should be in users' interests | 10:53 |
| infinity | *nod* | 10:53 |
| cjwatson | jibel: Also, has the Content-Type of jenkins autopkgtest logs changed, or something? e.g. when I try to view logs from https://jenkins.qa.ubuntu.com/view/Raring/view/All/job/raring-adt-bzr/ARCH=i386,label=adt/ in firefox, I now get told that it's a "BIN file" and I only have the choice to cancel or save to disk, which is rather less convenient than it showing up as text in my browser | 11:13 |
| infinity | cjwatson: Not that it changes the fact that jenkins is spewing bogus headers and should be fixed, but you really want http://spasche.net/openinbrowser/ | 11:20 |
| infinity | cjwatson: It's made my life so much more pleasant. | 11:20 |
| cjwatson | ah, cool | 11:20 |
| cjwatson | thanks :) | 11:21 |
| jibel | cjwatson, it didn't change AFAIK, when did you notice this change? | 11:25 |
| cjwatson | jibel: I haven't looked at autopkgtest output for *ages* until today | 11:25 |
| cjwatson | So just today, but that doesn't tell you much | 11:25 |
| Laney | I've noticed that behaviour for a long time | 11:26 |
| infinity | It could be that the Content-Type never changed, but Fifefox got stricter about how it deals with it. | 11:26 |
| cjwatson | Or I guess it could be that my new laptop has a different browser configuration somehow (though I did sync over my profile | 11:27 |
| cjwatson | ) | 11:27 |
| jamespage | please can an someone reject d2to1 from precise-proposed - forgot to add the ppa target to the upload | 11:36 |
| jamespage | doh! | 11:36 |
| cjwatson | jamespage: done | 11:36 |
| jamespage | cjwatson: ta | 11:36 |
| jamespage | Daviey, I also need to upgrade python-django-compressor to 1.2 to fixup horizon with firefox (see bug 1130610) | 12:30 |
| ubot2 | Launchpad bug 1130610 in python-django-compressor (Ubuntu Raring) ""SyntaxError: invalid increment operand" when parsing JavaScript using Firefox" [High,In progress] https://launchpad.net/bugs/1130610 | 12:30 |
| jamespage | 1.1.2 -> 1.2 | 12:30 |
| jamespage | I confirmed it fixes the issue; only rdepends is horizon | 12:31 |
| cjwatson | stgraber: Well, I'm confused. The oversized handling looks right and I even just added a test for it. Where's it supposed to show up on iso.qa? | 12:32 |
| === mmrazik is now known as mmrazik|lunch | ||
| cjwatson | stgraber: Ah, wait, it's broken for non-Ubuntu flavours | 12:35 |
| === mmrazik|lunch is now known as mmrazik | ||
| cjwatson | stgraber: Fixed, with a better test case - thanks for the report | 12:37 |
| Daviey | jamespage: Nothing else uses this, and 1.2 seems to have had more upstream exposure to this, please carry on. | 12:40 |
| jamespage | Daviey, ack | 12:41 |
| Daviey | jamespage: surprised it's still not in debian? | 12:41 |
| jamespage | Daviey, I suspect its in the experimental new queue | 12:41 |
| Daviey | ah, yes. | 12:41 |
| jamespage | Daviey, yeah - its in git.debian.org but not accepted | 12:45 |
| stgraber | cjwatson: thanks for tracking the bug down and fixing! | 13:19 |
| stgraber | cjwatson, infinity: who's our webteam contact? I've had multiple reports that we ought to update http://www.ubuntu.com/testing | 13:22 |
| infinity | stgraber: That's a good question that I'm not sure I have the answer to. | 13:39 |
| infinity | I also didn't know that page existed until today... | 13:40 |
| stgraber | infinity: I pinged #web-team on the internal IRC, hopefully someone will react | 13:41 |
| stgraber | infinity: the link was added in the announcement "template" since alpha-2 apparently | 13:42 |
| infinity | stgraber: If all else fails, bugging Peter Mahnke might get it done. But I'm not sure who we're "supposed" to bug. | 13:43 |
| infinity | stgraber: But, ideally, everything after "Thank you" should probably just be removed, so it can remain static content. | 13:44 |
| infinity | stgraber: And the wiki updated with whatever bits we think it should have. | 13:44 |
| stgraber | infinity: yeah, I tried to ping Peter first (per Daviey's suggestion) but he appears to be offline at the moment. Anyway, I agree that the list of releases isn't terribly useful and we could probably just have that removed and keep the page static. | 13:46 |
| cjwatson | stgraber: I think Peter and/or that channel is correct | 14:21 |
| infinity | cjwatson: Hrm. Seems like a misfeature on britney's part that it cares about outdates for an arch that's already outdated. | 15:03 |
| infinity | (Though, maybe I should just put some time in today to fix chromium-browser on ARM instead of continuing to fudge it) | 15:04 |
| cjwatson | Possibly, yeah | 15:11 |
| cjwatson | (On both counts :) ) | 15:11 |
| cjwatson | NOTE: I'm changing the buildlive interface to be a bit more standard in cdimage terms, so the project and series should now be passed in through the environment (e.g. DIST=precise for-project ubuntu buildlive daily-live') | 15:11 |
| cjwatson | I've also made most of cron.* have --live options, so normally, you can just adjust expectations as follows: | 15:12 |
| cjwatson | -31 7 * * * buildlive ubuntu daily-live && for-project ubuntu cron.daily-live | 15:12 |
| cjwatson | +31 7 * * * for-project ubuntu cron.daily-live --live | 15:12 |
| cjwatson | Some of the odder builds (wubi, livecd-base, core, chinese-edition) still call buildlive directly in crontab | 15:12 |
| infinity | I wonder if there's still any value in livecd-base. | 15:18 |
| cjwatson | This also means that you don't have to remember about cases where the livecd-rootfs project is called *-dvd, so the direct buildlive call for Edubuntu would go from 'buildlive edubuntu-dvd dvd' to 'for-project edubuntu buildlive dvd' | 15:18 |
| infinity | It used to really just be a good, quick "is the machinery working as expected?" test, but core does that just as well. | 15:18 |
| cjwatson | And it means that buildlive is now in the public cdimage branch at long last | 15:19 |
| cjwatson | infinity: Originally, it was a request from lamont (but of more general utility) to provide a squashfs base for customisation | 15:19 |
| cjwatson | I don't know whether core is just as good for that; maybe it is | 15:19 |
| infinity | Yeah, I know what it was *originally*, but I doubt anyone uses it for that. | 15:19 |
| infinity | I could be wrong, though. | 15:20 |
| infinity | It's not like it eats a ton of resources. | 15:20 |
| * infinity shrugs. | 15:20 | |
| lamont | I'd be happy with core | 15:20 |
| infinity | cjwatson: So, I notice that, like me, you've avoided NEWing libgmpada, I assume for the same reason (-dev seemed to bump SOVER, but library package didn't, WTF?) | 15:21 |
| infinity | cjwatson: Were you chasing that up with the Debian maintainer(s) at all? Should I? | 15:21 |
| cjwatson | livecd-base> Yeah, it's a little hard to say | 15:22 |
| cjwatson | infinity: I hadn't put any thought into it, actually :) | 15:22 |
| cjwatson | I tend to routinely NEW anything that new-binary-debian-universe supports - anything else rather less frequently | 15:22 |
| infinity | cjwatson: Ahh, I just assumed you were avoiding it intentionally, since you seem to do a lot of binNEW batch processing (as do I). | 15:22 |
| cjwatson | So I haven't chased it up at all | 15:22 |
| infinity | Let me have a poke at the actual contents of those binaries to see WTF is up. | 15:23 |
| cjwatson | The -dev does look weird | 15:23 |
| infinity | Cause the weird bump on -dev but not lib is confusion. | 15:23 |
| infinity | confusing, too. | 15:23 |
| infinity | It's not the first one, either. The previous version had lib2 and lib3-dev :P | 15:23 |
| infinity | I think the Debian maintainer may be very confused about libraries. | 15:23 |
| === greyback is now known as bzoltan-smells | ||
| === bzoltan-smells is now known as greyback | ||
| === Ursinha_ is now known as Ursinha | ||
| === rsalveti_ is now known as rsalveti | ||
| infinity | cjwatson: So, that bizarre -dev package version comes from Debian ADA policy. It's doesn't relate to the ABI of the library at all, but some magic ADA-only API rev. | 15:53 |
| infinity | cjwatson: Vomitously icky, and I wish I hadn't read it. At least working on chromium will now seem like an improvement on my day. | 15:53 |
| cjwatson | How bizarre. Fortunately I have managed to avoid ada. | 15:58 |
| slangasek | cjwatson: good question. Will the upgrade machinery *allow* us to upgrade users from 12.04 to 13.04? | 16:35 |
| infinity | slangasek: We can make it allow us. I think the original point was in making sure it's possible, however. | 16:50 |
| infinity | slangasek: Or, rather, that it doesn't break when attempted. | 16:50 |
| ScottK | For Kubuntu, we supported upgrades from 8.04 -> 8.10, 8.04 -> 9.04, 8.04 -> 9.10, and 8.04 -> 10.04 because the early KDE4 releases were so rough. It wasn't that difficult to do. | 16:52 |
| ScottK | Mostly it was just added upgrade testing. | 16:52 |
| infinity | Indeed. | 16:52 |
| ScottK | infinity: Someone should reply to the TB thread proposing this be part of the new release model .... | 16:53 |
| infinity | And as Colin and I were both agreeing on last night, even if we weren't changing support cycles, making sure LTS->current works is always a good thing anyway, so we don't have that sille LTS->LTS "hey, nothing works" panic due to people ignoring upgrade paths for 18-24 months in between. | 16:53 |
| ScottK | Yeah. | 16:53 |
| * infinity doesn't read the TB list, but is positive that he and Colin are very much on the same page here, and Colin's on the TB, so... | 16:54 | |
| ScottK | It also gives a way out in the new model for someone who's on LTS and a year later decides they want current. | 16:54 |
| micahg | ScottK: I'd prefer we don't have it officially part of the new release model as that will require backports go through the intermediate releases again | 16:54 |
| infinity | micahg: Eh? | 16:54 |
| micahg | if there's an upgrade path, you need the backport through it | 16:54 |
| ScottK | micahg: With the proposed shorter support lifetime, it greatly simplifies that. | 16:55 |
| infinity | ^ | 16:55 |
| ScottK | The path becomes ~ LTS and current. | 16:55 |
| infinity | And the argument from Colin and I is that we should be making sure the upgrade path WORKS, regardless of if we need to support it. | 16:55 |
| micahg | sure, but current might not be valuable | 16:55 |
| slangasek | infinity: cjwatson's original question was whether to change the tech overview, and I think the answer to that is yes + get it autotested, provided we can make update-manager DTRT | 16:55 |
| infinity | Though, with the shorter support cycles, we would need to support it, I think. | 16:55 |
| infinity | micahg: I'm not sure what you mean by "current might not be valuable". | 16:56 |
| micahg | infinity: in terms of backporting certain software | 16:56 |
| infinity | micahg: If all backports are from current, and the only supported release other than current is an LTS, you only backport from current to LTS, and done. | 16:56 |
| micahg | infinity: it's common to want to backport from the development series | 16:57 |
| infinity | micahg: I thought you had a policy of not backporting from devel, because it makes post-backport support a nightmare? | 16:57 |
| micahg | infinity: I was not aware of such a policy where the version being backported was a stable one | 16:57 |
| ScottK | infinity: No. The requirement is it has to be in the archive. Devel series is fine. | 16:58 |
| infinity | ScottK: Ahh, kay. I misunderstood somewhere along the way. | 16:58 |
| ScottK | The support model is if a backport is broken, backport the newer thing that fixes the broken. | 16:58 |
| infinity | So, sure, you might need to backport to $current and $latest_lts, if your ultimate target is $latest_lts, that shouldn't be a big deal, mind you. | 16:58 |
| ScottK | Considering the testing standard is builds/installs/runs, it's not hard. | 16:59 |
| micahg | infinity: it just means you need to find someone with interest on $current to test, that can be problematic sometimes | 16:59 |
| ScottK | It gets hard for libraries, but then it's supposed to be hard ... | 16:59 |
| ScottK | infinity: I think we'll also want to adjust SRU policy too, but it can wait until the details of the larger plan are sorted. I'm thinking for non-LTS releases, only SRU regressions from the previous release. For other things hit the development series and last LTS. The regular release user can get the fix when they upgrade after the next release. | 17:05 |
| infinity | ScottK: Again, preaching to the choir. | 17:07 |
| infinity | ScottK: Many of us think lots of these things are somewhat self-evident, so I suspect we might be able to just have a Release Team pow-wow about it all and present a unified front on a few things like this. | 17:07 |
| ScottK | Agreed. | 17:08 |
| ScottK | FWIW, Kubuntu (as a project) had a meeting on the topic and I just sent the project feedback to the TB list. | 17:08 |
| infinity | Yeah, I'm catching up with the list archives now. | 17:12 |
| ScottK | It would be nice to have a version of http://people.canonical.com/~ubuntu-archive/proposed-migration without Laney's haskell stuff in it. | 17:25 |
| ogra_ | poor Laney, nobody likes his haskell | 17:26 |
| ogra_ | (though i usually complain about the -changes spam) | 17:26 |
| Laney | There's a good way to get it clear of haskell stuff. | 17:26 |
| Laney | If you say "remove it" you get a Stern Look | 17:27 |
| infinity | remove-package ghc? | 17:27 |
| infinity | Jinx. | 17:27 |
| micahg | I think if someone doesn't find time in the next 2 weeks, anything haskell package with no rdeps that's blocking the transition should be removed, that can be done recursively, then a handful will be left that hopefully someone has time to fix | 17:36 |
| cjwatson | I've already been removing some binaries that are broken on non-primary architectures | 17:37 |
| Laney | I think if all of the ppc/armhf busticacted ones are removed then the remaining list looks a lot more tractable | 17:44 |
| Laney | I've already ported a few packages for 7.6 too and hope to get to as many of the rest as possible | 17:45 |
| Laney | In some cases I've been syncing older versions of stuff (syncpackage -V) and also undoing ports to new APIs to avoid starting new sub transitions | 17:46 |
| jokerdino | hey, i know you guys are super busy and stuff but, can one of you spare some time and help us review the unity-tweak-tool stuck in the new queue. :'( | 18:15 |
| jokerdino | i will be grateful. | 18:15 |
| infinity | jokerdino: It's still on my TODO. I guess since I managed to pass chromium off to chrisccoulson, I can look at it this afternoon. | 18:17 |
| jokerdino | infinity: oh thank you very much. it just feels a little dejected getting no response for quite some time now. | 18:18 |
| jokerdino | and i feel low having to nag :( | 18:18 |
| rtg_ | infinity, new raring kernel crack headed your way. I remembered the orig tarball this time. | 18:20 |
| infinity | rtg_: Mmm, crack. | 18:26 |
| xnox | infinity: sometimes I'm not sure when you are joking ;-) | 19:46 |
| infinity | xnox: In reference to? | 19:55 |
| ogra_ | crack ? | 19:56 |
| infinity | ogra_: Well, it's either crack or wearing floral prints to work. I'm not sure what his context is. | 19:56 |
| ogra_ | oh, you waer floral prints ? | 19:57 |
| xnox | ogra_: no, i do. | 19:57 |
| ogra_ | tsk ... that hangout thing | 19:57 |
| xnox | anyway. turns out my PC woes was the beginners mistake of using PSU that is bundled with the case.... | 19:57 |
| * ogra_ would rather call it a mistake to buy a bundle :) | 19:59 | |
| infinity | Unless it's an Antec, yeah. | 20:01 |
| ogra_ | do they have special silent fans ? | 20:02 |
| infinity | The lovely PSU company that realized they could triple their profit margins by wrapping their power supplies in pretty aluminum. | 20:02 |
| infinity | ogra_: They have pretty much anything you can imagine. | 20:02 |
| ogra_ | ah, cool | 20:02 |
| infinity | (I tend to buy my Antec cases and PSUs separately anyway, to mix and match what I want, but you probably wouldn't go wrong with a bundle, as long as you don't stupidly underspec your power draw) | 20:03 |
| ogra_ | well, if the case suits me :) | 20:03 |
| infinity | I've been using these ones a lot lately. Ridiculously cheap, well made, nice to work with, and somewhat pretty: http://www.memoryexpress.com/Products/MX37673 | 20:04 |
| ogra_ | getting a PSU thats powerful enough and quiet for that case http://www.silverstonetek.com/product.php?pid=291wasnt so easy | 20:04 |
| infinity | Ahh, you like yours a bit more compact, I see. :) | 20:05 |
| ogra_ | yeah, and in some atypical shape | 20:05 |
| infinity | I'm still an old skool overclocker and modder at heart, even though I don't do either anymore. But I still purchase as if I might. | 20:06 |
| ogra_ | i would have bought it in a bigger size if they had it | 20:06 |
| ogra_ | still enough for playing steam games on my triple head setup :) | 20:06 |
| xnox | This is what I got: http://www.ebuyer.com/235611-coolermaster-elite-430-all-black-case-with-elite-500w-psu-rc-430-kwp500 | 20:07 |
| xnox | it even has blue LED front fan | 20:07 |
| ogra_ | heh | 20:08 |
| infinity | Kids these days. | 20:08 |
| ogra_ | thats what made alienware a success :) | 20:08 |
| infinity | xnox: CM isn't known for their quality. Just trading on a silly "overclocking friendly" brand that never measured up, sadly. | 20:08 |
| ogra_ | siny LEDs on the cases | 20:08 |
| ogra_ | *shiny | 20:08 |
| infinity | xnox: Not that quality matters for a case, if you think it's pretty and it doesn't slice all your fingers open. But it matters for the power, as you've found out. | 20:09 |
| ogra_ | it shouldnt rattle all the time ... so minor quality is required | 20:09 |
| infinity | Heh, fair point. | 20:09 |
| xnox | infinity: yeah. First troubleshooting step: take the motherboard out of the case. | 20:09 |
| * xnox was all *sigh* about that. | 20:09 | |
| infinity | But you can fix that with a bit of puffy double-sided tape in the right spots, if you REALLY like the look of it. | 20:09 |
| ogra_ | yeah, or cardboard | 20:10 |
| infinity | Heh. | 20:10 |
| infinity | I still have a laptop with one of Thom's business cards embedded in it. | 20:11 |
| infinity | Replaced a shim between the case switch and the internal power switch that broke off. | 20:11 |
| ogra_ | my basement is fully equipped with tools to build a case ... one day i might build my own | 20:11 |
| ogra_ | haha | 20:11 |
| ogra_ | wow, that must be old | 20:11 |
| ogra_ | like 7 years or so | 20:12 |
| infinity | Did the repair in Sydney. | 20:12 |
| infinity | Whenever that was... 2005, I guess. | 20:13 |
| infinity | ogra_: Dude, we're old. | 20:13 |
| infinity | ogra_: Well, I'm old. You're really old. | 20:14 |
| * slangasek passes out canes | 20:15 | |
| ogra_ | hahaha, yeah | 20:15 |
| * infinity misread passes as pisses and was really confused. | 20:15 | |
| ogra_ | LOL | 20:16 |
| ScottK | infinity: For power supplies, I'm either for Antec or PC Power and Cooling (although I think it's been close to a decade since I bought from them). | 20:25 |
| ScottK | Actually no. I bought one recently. | 20:25 |
| ScottK | I replaced a circe 2005 PP&C supply that failed. I was happy enough though that it failed safe so it was just a matter of dropping a new power supply in. | 20:26 |
| Noskcaj | just don't buy Aywun power supplies | 20:39 |
| Noskcaj | ocz make good PSUs too. | 20:42 |
| infinity | OCZ has good warranties. The part where I know that makes me shy away from them, but I could have just had bad luck. | 20:43 |
| Noskcaj | my ModXtream works great, just mmy cooling isn't enough for my OC so my PC is near unuseable | 20:44 |
| * infinity decides to go to the pharmacy to get some drugs, and hopes the channel will get back on topic in his absence. | 20:45 | |
| ogra_ | heh | 20:45 |
| Noskcaj | infinity, won't happen | 20:52 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha-afk is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!