darkxststgraber, are you able to add ubuntuGNOME to the dailies iso tracker?02:44
=== tkamppeter__ is now known as tkamppeter
knomerelease 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
ubot2Launchpad bug 1156555 in Catfish "[FFe] New Catfish version" [Undecided,New] https://launchpad.net/bugs/115655511:10
knomeif 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
stgraberhighvoltage, 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
knomestgraber, will do. cheers!13:16
phillwstgraber: okies13:18
xnoxstgraber: 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
stgraberxnox: 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 it13:20
highvoltagestgraber: 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 slides13:21
highvoltagehmm, actually I might be able to do a bit of it tonight as well13:21
xnoxstgraber: 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
stgraberxnox: yeah, I'm e-mailing Dylan too, he's been doing most of the Ubuntu updates the past few cycles.13:22
stgraberhighvoltage: 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 critical13:23
stgraberhighvoltage: the main reason being that I want us to ship something that's more than 20% translated for a change13:23
cjwatsonpublic-private cdimage diff: 189 lines ...13:26
stgrabercjwatson: wow, nice!13:30
stgrabercjwatson: does that mean we have a python publish-release now?13:30
cjwatsonNo, that's still in shell13:31
cjwatsonI didn't feel it necessary to block on converting the things that were already (largely) public13:32
cjwatsonI rewrote the grotty Chinese edition code in Python this morning though, getting rid of a pile of publication duplication13:32
stgraberoh that's good, that one always felt weird to me13: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
cjwatsonI expect we can stop building it at some point, sure13:36
cjwatsonProbably oughta get PES consent13:36
zequencestgraber: Yep. Ubuntu Studio is good. Thanks13:38
cjwatsonExactly one logical change remaining (production-specific proxy configuration).  Time to get coffee supplies before tackling that13:54
bjfinfinity, i have a bunch of kernels i'd like to go from -proposed to -updates14:24
cjwatsonlp:ubuntu-cdimage is now identical to the deployed branch15:46
cjwatsonI've e-mailed committers with details of changed procedures15:47
stgrabercjwatson: awesome!15:58
ogra_to sad janimo isnt around now ...16:08
* ogra_ remembers two years of moaning about private branches :)16:08
infinitybjf: I have the technology to make that happen.16:17
infinityogra_: Jani's still around...16:19
ogra_just not here, yeah16: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
xnoxthat is considering the s-series codename is public early enough.17:14
slangasekwell, we'd rather like to not have crap stuck in raring-proposed at release time17:23
xnoxlike all of haskell =)17:24
xnoxthe other alternative is to force migrate stuff......17:25
LaneyEr, or fix it?17:26
cjwatsonYeah, I'd prefer to just make it a target to fix it all17:27
cjwatsonI don't think that's especially unachievable17:27
micahgxnox: 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 that17:41
LaneyI'd rather people helped than cook up schemes to deal with brokenness17:41
micahgLaney: I think I can do both ;)17:42
stgraberso 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
xnoxLaney: 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
stgraberI'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 so should be safe to use17:44
Laneyxnox: don't look at those - they are targets for removal on the bad arches (compiler bug usually)17:45
Laneylook at the ones that are bad on all arches17:45
Laneyif you don't upgrade any lower down library you'll be safe17:45
xnoxLaney: ack.17:46
cjwatsonstgraber: Or 2.5.11ubuntu13 would do, wouldn't it?17:47
stgrabercjwatson: yep, that'd work too17:48
cjwatsonI'd suggest going for that as the more conservative option17:48
stgraberfair enough, will re-upload as 2.5.11ubuntu13 then17:48
infinityxnox: AFAIUI, ghc on armhf is still a bit goofy.17:50
Laneyvastly better than it was but still somewhat wonkalicious17:50
=== rsalveti_ is now known as rsalveti
=== Ursinha_ is now known as Ursinha
infinityxnox: 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
infinityxnox: Force-migrating stuff is a non-option, IMO.17:51
infinityxnox: Since what we're testing for release is the release pocket, not some random combination with proposed.17:52
jbichastgraber: can't you just do 2.5.11ubuntu13?17:54
blitzkrieg3Is there anything more I need to do in order to get bug 445872 suitable for SRU?18:05
ubot2Launchpad bug 445872 in OEM Priority Project precise "disable-disconnect-notification option ignored" [High,In progress] https://launchpad.net/bugs/44587218:05
blitzkrieg3Another network manager bug18:05
=== blitzkrieg3 is now known as jmleddy
cjwatsonLaney: 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-deps18:27
Laneycjwatson: Hmm, that might be the same thing - just that loading modules in GHCi doesn't crash the whole thing, maybe18:34
Laneylet me try a test build18:35
cjwatsonI removed some of the easy ones just now18:39
Laneypersistent is an annoying stack, and llvm I think needs some porting18:40
Laneyagda I will solve via Debian when I get a chance to sort out its deps18:41
Laneybah, 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 fine19:02
* Laney heads foodwards19:03
infinityLaney: I suppose it's too much to ask that someone just fix the compiler? :/19:05
tgm4883Is 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
xnoxtgm4883: armhf & powerpc are hosted separately, They are here: http://ports.ubuntu.com/ubuntu-ports/pool/multiverse/m/mythtv/19:34
tgm4883xnox, slightly confusing, but good to know that it is working. Thanks19:35
xnoxtgm4883: less frequently architectures are hosted on ports, to make our primary (widely-mirrored) archive smaller.19:36
tgm4883xnox, I suppose that makes sense19:36
xnoxtgm4883: 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
cjwatsonThe layout is documented here: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Architectures19:40
darkxststgraber, are you able to add ubuntuGNOME to the dailies iso tracker?19:41
stgraberdarkxst: I saw the last 10 pings or so, it's on my list ;)19:44
darkxststgraber, ok cool, thanks!19:45
=== Ursinha-afk is now known as Ursinha
xnoxthe 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
tumbleweedxnox: have you seen Laney's haskall transition graphs? a list is much saner20:07
xnoxonly this: http://people.canonical.com/~ubuntu-archive/transitions/ghc.html20:07
xnoxtumbleweed: links?20:07
ScottKstgraber: since the new Unity stack is already sabdfl'ed in after UIF, I suspect slide show updates are pretty unavoidable.20:07
xnoxScottK: there is no "unity" per se slides. and the u1 slide is updated with the "new spread" mockup ;-)20:08
xnox(probably dash is the right terms instead of the spread....)20:08
stgraberright, I checked that this morning, the new unity won't affect the slideshow.20:08
stgraberand 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 that20:09
xnoxinfinity: https://launchpad.net/~xnox/+archive/scratch/+build/4379839 why is panda building amd64?21:02
infinityIt's not.21:02
cjwatsonIt's not a Panda21:02
infinityThat's a Xen guest.21:02
xnoxunless the names are confusing for giggles =)21:02
infinityWith a silly name.21:02
cjwatsonIt can build any of i386/amd64/armhf21:03
xnoxok, giggles then....21:03
stgraberdarkxst: Ubuntu GNOME added to the list of products on the tracker. Next daily build should show up on there.21:05
stgraberdarkxst: you'll want to talk to balloons to get some test cases setup though21:05
darkxststgraber, thanks21:05
darkxstsure, will do21:05
balloonsdarkxst, :-)21:06
=== Ursinha_ is now known as Ursinha
=== rsalveti_ is now known as rsalveti
darkxstballoons, Hey, so too start off with can you just copy the install (auto-resize, entire disk and manual) testcases from Ubuntu Desktop21:27
balloonsdarkxst, sure thing21:29
ScottKinfinity: Does making LTS -> Current a supported upgrade patch need a TB decision or can we JFDI?21:29
infinityScottK: 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
cjwatsonIt 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
stgraberScottK: I think it's fine to JFDI and then have the release team do the job of advertising it as a supported upgrade path21:30
infinityAnd I can't imagine anyone in Foundations being against it.21:30
cjwatson(Which they always do)21:30
ScottKWe can take it as an implied result of the shortened support window ...21:30
infinityAnyhow, 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
cjwatsonWe'll need QA, but I think we've discussed this with them ...21:31
infinityWe have.21:31
infinityjibel was on board.21:31
infinityAnd I think was already going to set things up?21:31
darkxstballoons, also "Live Session" and Upgrade test cases21:32
cjwatsonRight, good21:33
xnoxScottK: one thing to support it, another thing to enable the jumps in upgrade-manager / do-release-upgrade directly for the unsuspecting users.22:03
cjwatsonMy 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 LTS22:04
cjwatsonAnd history suggests that we find out about a lot of the problems when the first batch of not-us users upgrade22:05
infinityWe're doing ourselves a favour by doing it right in the first place.22:05
cjwatsonObviously, not that we shouldn't continuously improve our ability to detect things in advance, but ...22:05
stgraberright, we'll likely have to spend a tiny bit more resources to test this mess though, but that's mostly automated resources22:05
stgraberthe gain being much more reliable upgrades and less pain when we reach the next LTS22:06
infinitystgraber: 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
infinityIt's amazing the bitrot you get when people ignore a problem for 2 years.22:06
stgraberinfinity: 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
infinitydoko: 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
infinitystgraber: *nod*22:09
dokoinfinity, I don't care about 13.1022:09
infinitydoko: ;)22:09
xnoxdoko: cjwatson: i was hoping to open with boost1.53 by default.22:13
ScottKxnox: 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
xnoxScottK: 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
xnoxnot much i can help with =(22:57
xnoxdebian should just release.22:58
xnoxalso 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
ScottKpython3-defaults migrated to wheezy last night, so I'm ready ...22:59
Laneyinfinity: 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
infinityLaney: 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
LaneyStill, I'm continuing to hope and occasionally pester23:00
infinityThen again, I'd be happy punting python too, so my opinions might not matter.23:00
LaneyI'm pleased that some people found some time/funding/whatever it was to get ghc to its current state on arm, TBH23:00
infinityC, C++, Perl, make, and a POSIX shell are all I need.23:00
Laneyit was fairly dire before23:00
infinityLaney: 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
infinityLaney: 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
LaneyHopefully it'll turn out to be something easy for someone who knows all that stuff23:05
infinityWell, 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
infinityReally, 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
infinityCould 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
LaneyJani did fix some stuff around that before23:08
infinityWhich would explain why it only happens sometimes.23:08
LaneyI wonder if he has any brain state in that area left23:08
LaneyBed. If I get some time tomorrow I'll chop this 589 line reproducer down some23:09
infinityLaney: Is it something that reproduces a compiler segv, or something that causes the compiler to generate code that segvs?23:10
infinityLaney: 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
LaneyIt's something that the interpreter fails to load, which I reckon will turn out to be a very similar bug23:11
LaneyThe general form of the problems is the former though - I haven't come across any programs that have compiled successfully then fail to work23:11
LaneyAlso useful to note is that it's using an LLVM backend on armhf. It's not generating native code.23:15
LaneyReal bed.23:15
infinityOh, hrm, if it's using LLVM, I may well have a clue as to where the bug lies.23:16
infinityI'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!