| darkxst | stgraber, are you able to add ubuntuGNOME to the dailies iso tracker? | 02:44 |
|---|---|---|
| === tkamppeter__ is now known as tkamppeter | ||
| knome | release team: bluesabre just filed LP 1156555, can you look at it and preferably give an ACK for FFe? the reason for the completely new version is that the old version refuses to run on raring... | 11:10 |
| ubot2 | Launchpad bug 1156555 in Catfish "[FFe] New Catfish version" [Undecided,New] https://launchpad.net/bugs/1156555 | 11:10 |
| knome | if you need any more information, comment on the bug or ask bluesabre on irc. | 11:11 |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| stgraber | highvoltage, knome, Riddell, ScottK, zequence, phillw, (whoever else I forgot): Please make sure any slideshow change is in lp:ubiquity-slideshow-ubuntu by Wednesday 21:00 UTC. I'll review and upload on Thursday before UIF. | 13:16 |
| knome | stgraber, will do. cheers! | 13:16 |
| phillw | stgraber: okies | 13:18 |
| xnox | stgraber: there is a request from U1 team to update U1 slide, but it's not yet in patch form =) requested assets to update the slide, hopefully we will make it. | 13:18 |
| stgraber | xnox: you can tell them that I'm not planning on granting them a UIFe this time around (the Ubuntu slideshow has always been updated post-freeze and it's starting to annoy me), so they have it by Wednesday 21:00 UTC or we ship without it | 13:20 |
| highvoltage | stgraber: not sure if I'd have the final one done by then, but I'll have something that can at least represent 90%+ of the final slides | 13:21 |
| highvoltage | hmm, actually I might be able to do a bit of it tonight as well | 13:21 |
| xnox | stgraber: If only I news who to tell though. As for example is quetzal everywhere and not raring. I only have some artwork for the u1 page. | 13:22 |
| stgraber | xnox: yeah, I'm e-mailing Dylan too, he's been doing most of the Ubuntu updates the past few cycles. | 13:22 |
| stgraber | highvoltage: what I said for Ubuntu applies for flavours too, I really have no intention in granting UIFe for slideshow changes that do more than fix something critical | 13:23 |
| stgraber | highvoltage: the main reason being that I want us to ship something that's more than 20% translated for a change | 13:23 |
| cjwatson | public-private cdimage diff: 189 lines ... | 13:26 |
| stgraber | cjwatson: wow, nice! | 13:30 |
| stgraber | cjwatson: does that mean we have a python publish-release now? | 13:30 |
| cjwatson | No, that's still in shell | 13:31 |
| cjwatson | I didn't feel it necessary to block on converting the things that were already (largely) public | 13:32 |
| cjwatson | I rewrote the grotty Chinese edition code in Python this morning though, getting rid of a pile of publication duplication | 13:32 |
| stgraber | oh that's good, that one always felt weird to me | 13:34 |
| stgraber | (though I was hoping we'd just get rid of it entirely after the last 12.04 point release, now that we have Kylin) | 13:34 |
| cjwatson | I expect we can stop building it at some point, sure | 13:36 |
| cjwatson | Probably oughta get PES consent | 13:36 |
| zequence | stgraber: Yep. Ubuntu Studio is good. Thanks | 13:38 |
| cjwatson | Exactly one logical change remaining (production-specific proxy configuration). Time to get coffee supplies before tackling that | 13:54 |
| bjf | infinity, i have a bunch of kernels i'd like to go from -proposed to -updates | 14:24 |
| cjwatson | lp:ubuntu-cdimage is now identical to the deployed branch | 15:46 |
| cjwatson | (woo) | 15:46 |
| Laney | \o/ | 15:47 |
| cjwatson | I've e-mailed committers with details of changed procedures | 15:47 |
| stgraber | cjwatson: awesome! | 15:58 |
| ogra_ | to sad janimo isnt around now ... | 16:08 |
| * ogra_ remembers two years of moaning about private branches :) | 16:08 | |
| infinity | bjf: I have the technology to make that happen. | 16:17 |
| infinity | ogra_: Jani's still around... | 16:19 |
| ogra_ | just not here, yeah | 16:19 |
| ogra_ | (see -devel) | 16:19 |
| * xnox ponders what we will do with crap stuck in raring-proposed at release time? move it to s-proposed & declare raring-proposed for SRU from that point onwards? | 17:14 | |
| xnox | that is considering the s-series codename is public early enough. | 17:14 |
| slangasek | well, we'd rather like to not have crap stuck in raring-proposed at release time | 17:23 |
| xnox | like all of haskell =) | 17:24 |
| xnox | the other alternative is to force migrate stuff...... | 17:25 |
| Laney | Er, or fix it? | 17:26 |
| cjwatson | Yeah, I'd prefer to just make it a target to fix it all | 17:27 |
| cjwatson | I don't think that's especially unachievable | 17:27 |
| xnox | ok. | 17:29 |
| micahg | xnox: I see worst case as removing what's left unfixed to allow migration as a last resort, no need to force anything, but it seems that it should be fixable without that | 17:41 |
| Laney | I'd rather people helped than cook up schemes to deal with brokenness | 17:41 |
| micahg | Laney: I think I can do both ;) | 17:42 |
| Laney | :P | 17:43 |
| stgraber | so jbicha reminded me of https://lists.ubuntu.com/archives/ubuntu-release/2012-December/002140.html, does anyone have an objection with me doing a no-change upload of lintian 2.5.11ubuntu2 as 2.5.11.0ubuntu1? | 17:44 |
| xnox | Laney: despite trying a couple of times haskell FTBFS on armhf but not other arches still confuse me and I have no clue what to do with them. And I'm constantly put-off by accidently triggering a new wave of migrations. | 17:44 |
| stgraber | I'm not too familiar with lintian's versioning in Debian, but looking at rmadison, it looks like any bugfix release on the current lintian would be 2.5.11.1 so 2.5.11.0 should be safe to use | 17:44 |
| Laney | xnox: don't look at those - they are targets for removal on the bad arches (compiler bug usually) | 17:45 |
| Laney | look at the ones that are bad on all arches | 17:45 |
| Laney | if you don't upgrade any lower down library you'll be safe | 17:45 |
| xnox | Laney: ack. | 17:46 |
| cjwatson | stgraber: Or 2.5.11ubuntu13 would do, wouldn't it? | 17:47 |
| stgraber | cjwatson: yep, that'd work too | 17:48 |
| cjwatson | I'd suggest going for that as the more conservative option | 17:48 |
| stgraber | fair enough, will re-upload as 2.5.11ubuntu13 then | 17:48 |
| infinity | xnox: AFAIUI, ghc on armhf is still a bit goofy. | 17:50 |
| Laney | correct | 17:50 |
| Laney | vastly better than it was but still somewhat wonkalicious | 17:50 |
| === rsalveti_ is now known as rsalveti | ||
| === Ursinha_ is now known as Ursinha | ||
| infinity | xnox: As far as "stuff stuck in proposed near release", I concur with everyone, that "just fix it" is the right thing to do, though if one or two things remain broken, emptying the pocket right before release would be the sane last resort. | 17:51 |
| infinity | xnox: Force-migrating stuff is a non-option, IMO. | 17:51 |
| infinity | xnox: Since what we're testing for release is the release pocket, not some random combination with proposed. | 17:52 |
| jbicha | stgraber: can't you just do 2.5.11ubuntu13? | 17:54 |
| jbicha | nm | 17:54 |
| blitzkrieg3 | Is there anything more I need to do in order to get bug 445872 suitable for SRU? | 18:05 |
| ubot2 | Launchpad bug 445872 in OEM Priority Project precise "disable-disconnect-notification option ignored" [High,In progress] https://launchpad.net/bugs/445872 | 18:05 |
| blitzkrieg3 | Another network manager bug | 18:05 |
| === blitzkrieg3 is now known as jmleddy | ||
| cjwatson | Laney: haskell-conduit/armhf doesn't seem to be in the usual run of ARM build failures. Is it fixable? It'd be nice to avoid removing it, since it has a lot of reverse-deps | 18:27 |
| Laney | cjwatson: Hmm, that might be the same thing - just that loading modules in GHCi doesn't crash the whole thing, maybe | 18:34 |
| Laney | let me try a test build | 18:35 |
| cjwatson | I removed some of the easy ones just now | 18:39 |
| Laney | persistent is an annoying stack, and llvm I think needs some porting | 18:40 |
| Laney | agda I will solve via Debian when I get a chance to sort out its deps | 18:41 |
| Laney | bah, it's definitely broken - I can't ghci Data.Conduit.Binary (interpreted) without getting that same error, but if I compile some of the source files it loads fine | 19:02 |
| * Laney heads foodwards | 19:03 | |
| infinity | Laney: I suppose it's too much to ask that someone just fix the compiler? :/ | 19:05 |
| tgm4883 | Is there something special that needs to be done in order to have arm builds in the repo? We've got arm builds apparently happening (see https://launchpad.net/ubuntu/+source/mythtv/2:0.26.0+fixes.20121118.340b5d4-0ubuntu1/+build/3994497 ) but they apparently never get copied over to http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mythtv/ | 19:32 |
| xnox | tgm4883: armhf & powerpc are hosted separately, They are here: http://ports.ubuntu.com/ubuntu-ports/pool/multiverse/m/mythtv/ | 19:34 |
| tgm4883 | xnox, slightly confusing, but good to know that it is working. Thanks | 19:35 |
| xnox | tgm4883: less frequently architectures are hosted on ports, to make our primary (widely-mirrored) archive smaller. | 19:36 |
| tgm4883 | xnox, I suppose that makes sense | 19:36 |
| xnox | tgm4883: same as cdimages.ubuntu.com and releases.ubuntu.com images are slip in a similar fashion. | 19:36 |
| === Ursinha is now known as Ursinha-afk | ||
| cjwatson | The layout is documented here: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Architectures | 19:40 |
| darkxst | stgraber, are you able to add ubuntuGNOME to the dailies iso tracker? | 19:41 |
| stgraber | darkxst: I saw the last 10 pings or so, it's on my list ;) | 19:44 |
| darkxst | stgraber, ok cool, thanks! | 19:45 |
| === Ursinha-afk is now known as Ursinha | ||
| xnox | the haskell transition tracker would look nicer as a graphviz .dot tree, as some of the lines are actually leaf-nodes despite being half-way in the dependency level # | 20:05 |
| tumbleweed | xnox: have you seen Laney's haskall transition graphs? a list is much saner | 20:07 |
| xnox | only this: http://people.canonical.com/~ubuntu-archive/transitions/ghc.html | 20:07 |
| xnox | tumbleweed: links? | 20:07 |
| ScottK | stgraber: since the new Unity stack is already sabdfl'ed in after UIF, I suspect slide show updates are pretty unavoidable. | 20:07 |
| xnox | ScottK: there is no "unity" per se slides. and the u1 slide is updated with the "new spread" mockup ;-) | 20:08 |
| ScottK | k | 20:08 |
| xnox | (probably dash is the right terms instead of the spread....) | 20:08 |
| stgraber | right, I checked that this morning, the new unity won't affect the slideshow. | 20:08 |
| stgraber | and I'm not planning on accepting any extra text/slide after Thursday, so they'd have to go through the whole escalation again if they want that | 20:09 |
| xnox | infinity: https://launchpad.net/~xnox/+archive/scratch/+build/4379839 why is panda building amd64? | 21:02 |
| infinity | It's not. | 21:02 |
| cjwatson | It's not a Panda | 21:02 |
| infinity | That's a Xen guest. | 21:02 |
| xnox | unless the names are confusing for giggles =) | 21:02 |
| infinity | With a silly name. | 21:02 |
| cjwatson | It can build any of i386/amd64/armhf | 21:03 |
| xnox | ok, giggles then.... | 21:03 |
| stgraber | darkxst: Ubuntu GNOME added to the list of products on the tracker. Next daily build should show up on there. | 21:05 |
| stgraber | darkxst: you'll want to talk to balloons to get some test cases setup though | 21:05 |
| darkxst | stgraber, thanks | 21:05 |
| darkxst | sure, will do | 21:05 |
| balloons | darkxst, :-) | 21:06 |
| === Ursinha_ is now known as Ursinha | ||
| === rsalveti_ is now known as rsalveti | ||
| darkxst | balloons, Hey, so too start off with can you just copy the install (auto-resize, entire disk and manual) testcases from Ubuntu Desktop | 21:27 |
| balloons | darkxst, sure thing | 21:29 |
| ScottK | infinity: Does making LTS -> Current a supported upgrade patch need a TB decision or can we JFDI? | 21:29 |
| infinity | ScottK: It might need the weight of the TB to become project-wide policy though, honestly, if Foundations is on board, we have a pretty big lever to use on others. | 21:30 |
| cjwatson | It kind of seems like a "we should suck less" thing, although it might not hurt to have a TB decision to point to when people say "this isn't supported" | 21:30 |
| stgraber | ScottK: I think it's fine to JFDI and then have the release team do the job of advertising it as a supported upgrade path | 21:30 |
| infinity | And I can't imagine anyone in Foundations being against it. | 21:30 |
| cjwatson | (Which they always do) | 21:30 |
| ScottK | We can take it as an implied result of the shortened support window ... | 21:30 |
| infinity | Anyhow, I think we (Foundations and Release) can JFDI, tell the world about it, and *then* bring it to the TB to formalize if needed. | 21:30 |
| cjwatson | We'll need QA, but I think we've discussed this with them ... | 21:31 |
| infinity | We have. | 21:31 |
| infinity | jibel was on board. | 21:31 |
| infinity | And I think was already going to set things up? | 21:31 |
| darkxst | balloons, also "Live Session" and Upgrade test cases | 21:32 |
| cjwatson | Right, good | 21:33 |
| xnox | ScottK: one thing to support it, another thing to enable the jumps in upgrade-manager / do-release-upgrade directly for the unsuspecting users. | 22:03 |
| cjwatson | My argument here has always been that if we *don't* aggressively make upgrades to current from anything-supported work, then we just end up trying to put the pieces back together in a few months before the LTS | 22:04 |
| infinity | Exactly. | 22:05 |
| cjwatson | And history suggests that we find out about a lot of the problems when the first batch of not-us users upgrade | 22:05 |
| infinity | We're doing ourselves a favour by doing it right in the first place. | 22:05 |
| cjwatson | Obviously, not that we shouldn't continuously improve our ability to detect things in advance, but ... | 22:05 |
| stgraber | right, we'll likely have to spend a tiny bit more resources to test this mess though, but that's mostly automated resources | 22:05 |
| stgraber | the gain being much more reliable upgrades and less pain when we reach the next LTS | 22:06 |
| infinity | stgraber: The resouces spent by testing all the upgrade paths pay for themselves when we don't have to fix the LTS in a mad rush. | 22:06 |
| infinity | It's amazing the bitrot you get when people ignore a problem for 2 years. | 22:06 |
| stgraber | infinity: sure, I'm just saying that on paper, we'll be spending more resources (money in hardware) testing all the combinations (because there will be double the tests to do) but that leads to a reduced human resource cost when preparing the LTS. So definitely worth it. | 22:08 |
| infinity | doko: Speaking of opening new releases in PPAs, I won't be joining you for the 13.10 opening, since glibc 2.18 isn't released until June. | 22:08 |
| infinity | stgraber: *nod* | 22:09 |
| doko | infinity, I don't care about 13.10 | 22:09 |
| infinity | doko: ;) | 22:09 |
| xnox | doko: cjwatson: i was hoping to open with boost1.53 by default. | 22:13 |
| ScottK | xnox: First thing to a newer boost by default being a "good" idea is to get Debian to move to a newer default. Go fix RC bugs so Wheezy gets released. | 22:52 |
| * xnox goes to file ffe to sync boost1.53 into raring. | 22:54 | |
| xnox | ScottK: seriously I look at the current set of RC bugs and they either have lengthy debates on how to best fix it among a few DDs or they are mostly licensing/brokeness issues that have been around from a few releases back or security bugs. | 22:57 |
| xnox | not much i can help with =( | 22:57 |
| xnox | debian should just release. | 22:58 |
| xnox | also i'm confused how security bugs are RC, considering that they will be finding and fixing CVEs all throughout wheezy's timespan anyway. | 22:58 |
| ScottK | python3-defaults migrated to wheezy last night, so I'm ready ... | 22:59 |
| Laney | infinity: I think that's a big "just". I've been trying to get someone to look at it—beyond my skills and time—but no luck yet. | 22:59 |
| infinity | Laney: Yeah, I know. If I cared even remotely about ghc, I'd waste some weekends on it but, frankly, I don't. I'd be just as happy punting haskell from the archive. | 23:00 |
| Laney | Still, I'm continuing to hope and occasionally pester | 23:00 |
| infinity | Then again, I'd be happy punting python too, so my opinions might not matter. | 23:00 |
| Laney | I'm pleased that some people found some time/funding/whatever it was to get ghc to its current state on arm, TBH | 23:00 |
| infinity | C, C++, Perl, make, and a POSIX shell are all I need. | 23:00 |
| Laney | it was fairly dire before | 23:00 |
| infinity | Laney: Well, with any luck, the armhf-specific bugs might get shaken out as a side-effect of people doing an arm64 port (which I assume someone will). | 23:03 |
| infinity | Laney: Since, IIRC from Q, most of the compiler segfaults and miscompilations we're seeing were armhf-specific, and armel worked just fine. So probably just some bad register arithmetic or similar. | 23:04 |
| Laney | Hopefully it'll turn out to be something easy for someone who knows all that stuff | 23:05 |
| infinity | Well, it's easy to stab in the dark at probably causes (and probably even be right), but a bit harder to fix since I don't know thing one about ghc. | 23:05 |
| infinity | Really, what you need is someone who knows ARM things inside out to sit down with someone who knows GHC inside out, so person A can tell person B "your probablem is probably X", and person B can translate X to ghc-specific Y. | 23:06 |
| infinity | s/probablem/problem/ | 23:06 |
| infinity | Could be as simple as the armhf port being vfpv3 instead of vfpv3-d16, thus making any call with enough arguments to overflow registers land said arguments in la-la land. | 23:08 |
| Laney | Jani did fix some stuff around that before | 23:08 |
| infinity | Which would explain why it only happens sometimes. | 23:08 |
| Laney | I wonder if he has any brain state in that area left | 23:08 |
| Laney | Bed. If I get some time tomorrow I'll chop this 589 line reproducer down some | 23:09 |
| infinity | Laney: Is it something that reproduces a compiler segv, or something that causes the compiler to generate code that segvs? | 23:10 |
| infinity | Laney: The former would be beyond what I can debug without knowing ghc really well, but the latter would be interesting to disassemble and go "oh, well, duh." | 23:10 |
| Laney | It's something that the interpreter fails to load, which I reckon will turn out to be a very similar bug | 23:11 |
| Laney | The general form of the problems is the former though - I haven't come across any programs that have compiled successfully then fail to work | 23:11 |
| Laney | Also useful to note is that it's using an LLVM backend on armhf. It's not generating native code. | 23:15 |
| Laney | Real bed. | 23:15 |
| infinity | Oh, hrm, if it's using LLVM, I may well have a clue as to where the bug lies. | 23:16 |
| infinity | I'll have to find a round tuit and poke later. | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!