[00:22] <chrisccoulson_> would anyone object if i took http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=6f49c05ceb2a1935d07c49c2e100b5cf3cdf5f26 to fix bug 670128 for natty?
[00:22] <ubot4`> Launchpad bug 670128 in xdg-utils (Fedora) (and 4 other projects) "gnome-open uses firefox while it's not the preferred browser (affects: 23) (dups: 6) (heat: 155)" [Unknown,Unknown] https://launchpad.net/bugs/670128
[00:22] <chrisccoulson_> the default browser check in chromium is pretty broken without this
[00:22] <ScottK> chrisccoulson_: Please fix that.
[00:23] <ScottK> It's driving me nuts.
[00:23] <chrisccoulson_> ScottK - excellent, thanks
[00:23] <ScottK> broken in KDE too
[00:23] <ScottK> Maverick worked, so it's a regression.
[07:02] <lamont> there will be a brief disturbance in the i386 virtual builder pool
[10:06] <ev> I'd greatly appreciate someone having a look over bug 752372
[10:07] <ubot4`> Launchpad bug 752372 in ubiquity (Ubuntu) "UI Freeze exception for upgrade clarification (affects: 1) (heat: 8)" [Undecided,Fix committed] https://launchpad.net/bugs/752372
[10:07] <ev> thanks
[11:13] <Riddell> ev: I think string freeze exceptions should be approved by the translators (as well as release team)
[11:15] <ev> Riddell: I'd disagree as when we're this far along, any string freeze exception is likely to be to fix a critical bug, which is best evaluated by the release team.  But I'm not on the release team, so if you'd like me to ask permission on the translators mailing list, I shall.
[11:18] <Riddell> ev: I'm going by KDE practice here but if they can't re-translate it in time then it makes it less understandable for non English speakers so it just makes the situation worse
[11:18] <Riddell> ev: how about if I approve it from release team assuming you post to translators list and get no complaints by the end of the day?
[11:18] <ev> works for me, and an understandable point
[11:18] <ev> thanks
[11:22] <Riddell> hmm, no CD images today
[11:22] <davmor2> Riddell: weren't any yesterday either if it makes you feel better?
[11:24] <Riddell> yes, errors in the logs but I can't work out exactly what
[11:27] <ev> Riddell: mail to -translators sent and awaiting approval
[11:27] <ev> thanks
[11:30] <cjwatson> huh, that's a bizarre set of CD build failures
[11:31] <cjwatson> man hat livecd-rootfs geborken
[11:31] <cjwatson> http://kapok.buildd/~buildd/LiveCD/natty/kubuntu/current/livecd.kubuntu.kernel-generic:
[11:32] <cjwatson> 2011-04-07 05:52:38 ERROR 403: Forbidden.
[11:32] <davmor2> cjwatson: there are no Ubuntu lives either
[11:32] <cjwatson> I wouldn't expect this to be flavour-specific
[11:34] <cjwatson> oh scheisse
[11:34] <cjwatson> -rw------- root/root      1368 2011-04-05 20:25 ./boot/vmcoreinfo-2.6.38-8-generic
[11:34] <cjwatson> -rw------- root/root   4523328 2011-04-05 20:23 ./boot/vmlinuz-2.6.38-8-generic
[11:34] <cjwatson> -rw------- root/root   2654256 2011-04-05 20:23 ./boot/System.map-2.6.38-8-generic
[11:34] <cjwatson> somebody broke the kernel packages
[11:38] <cjwatson> vmcoreinfo and System.map were mode 0600 before, but vmlinuz being 0600 is new
[11:39] <cjwatson> hmm, apparently deliberate
[11:39] <cjwatson>   [ Kees Cook ]
[11:39] <cjwatson>   * [Config] packaging: adjust perms on vmlinuz as well
[11:41] <cjwatson> uploaded livecd-rootfs 1.166 with a workaround
[13:08] <ogra_> cjwatson, regarding bug 742430 ... we dont have even the initial bits for the new mx51 setup in debian-cd yet (so we cant u-boot based mx51 images yet), should the bug get a debian-cd task given we need to write all the bits from scratch first ?
[13:08] <ubot4`> Launchpad bug 742430 in linux-linaro-mx51 (Ubuntu) (and 1 other project) "FFe to start making mx51 images (affects: 1) (heat: 16)" [Undecided,Confirmed] https://launchpad.net/bugs/742430
[13:08] <cjwatson> ogra_: why isn't the existing imx51 code enough?
[13:09] <cjwatson> ogra_: anyway, shouldn't have a debian-cd task, bugs on the debian-cd instance we use in production go on the ubuntu-cdimage project
[13:09] <ogra_> because its only written for babbage and totally redboot centric
[13:09] <cjwatson> well, I'm not going to be writing the code, so do whatever is convenient
[13:09] <ogra_> efika and friends use u-boot and a totally different setup to boot
[13:09] <ogra_> (also we didnt have preinstalled images at babbage times)
[15:29] <cjwatson> rebuilding Ubuntu and Kubuntu desktop CDs
[15:30] <doko> cjwatson: do we remove the "development" in lsb_release before the beta?
[15:35] <cjwatson> doko: just before final release (https://wiki.ubuntu.com/ReleaseProcess)
[15:36] <cjwatson> ("Make sure that /etc/issue, /etc/issue.net, and /etc/lsb-release are correct", release minus 3 days)
[16:12] <tremolux> cjwatson: hi Colin, we have a very minor color-change we'd like to make in the Software Center UI, possibly does not rise to the level of UI freeze exception but I wrote one nevertheless
[16:12] <tremolux> cjwatson: it's bug 753620
[16:12] <ubot4`> Launchpad bug 753620 in software-center (Ubuntu) "UI freeze exception: Color change for review stars in details view and review dialog (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/753620
[16:20] <cjwatson> tremolux: see my comment
[16:21] <tremolux> cjwatson: thank you, yes, I will do that now
[16:43] <NCommander> skaet: cjwatson: what is your stance on having an unsupported mx51 image released at this point? (I have been told the topic been discussed here, but I havent noticed it before)
[16:45] <skaet> NCommander, it was discussed with ScottK,  as a tech preview effectively.   It was on the signup sheet for a couple of months, but has been in question whether the configs could be built or not in time.   I haven't heard any updates this week from ScottK or ogra_ on it.
[16:46] <cjwatson> I don't really have any stake in it either way
[16:48] <NCommander> skaet: I'm highly object to any images being pushed at this point of the game. As there is a non-trivial amount of code that has to be written to add a support for a new subarch, I don't even see how we could sanely have anything resemblign a tested image
[16:52] <ogra_> skaet, given that we got a huge and ugly patchset from TI to fix  bug 746023 my resources appaear to be bound atm
[16:52] <ubot4`> Launchpad bug 746023 in alsa-lib (Ubuntu) "No sound on omap4 (affects: 2) (heat: 14)" [Medium,New] https://launchpad.net/bugs/746023
[16:53] <ogra_> NCommander, just taking the omap boot script and modifying it for the efika setup should be trivial
[16:54] <ogra_> they use ext2 for booting and mount the partition in /boot but otherwise they should be the same
[16:54] <GrueMaster> ogra_: Problem is getting it tested.
[16:54] <ogra_> GrueMaster, not our issue
[16:54] <ogra_> thats why we have owners of images nowadays
[16:54] <ogra_> ;)
[16:55] <skaet> NCommander,  I agree its getting a bit late,  its not on the manifest at this point,  and given ogra_ 's comments,  it doesn't seem likely.  ScottK is the one signed up for coordinating the testing on it - but if the images aren't ready at this point.   I'm wondering how much testing and recovery of bugs it will really have.
[16:55] <ogra_> note that its not a new image, its just a new subarch
[16:55] <NCommander> ogra_: it is a new image by defintion.
[16:55] <ogra_> ScottK already agreed on just taking our headless image
[16:56] <ogra_> so userspace is identical to all other images we provide
[16:56] <ScottK> I'm fine with just doing a headless image.
[16:56] <ScottK> (also here now).
[16:56] <ogra_> the only bit missing is the support for the mx51 subarch on the image builder
[16:56] <GrueMaster> If it requires more than dropping a different kernel into the /boot, it is non-trivial.
[16:56] <ScottK> I was offline the last couple of days due to $WORK.
[16:57] <ogra_> GrueMaster, well, different kernel, different u-boot binary and other fs for the first partition, thats all
[16:57] <GrueMaster> Is the kernel in main?
[16:57] <NCommander> ScottK: while I would like to see efika support, and help get better community support in, I can't believe its sane to try and spin a completely new subarch less than three weeks from release
[16:57] <ogra_> it was approved by pitti for main
[16:57] <ScottK> No, but for a preinstalled image, it shouldn't be.
[16:57] <ScottK> ... shouldn't need to be.
[16:58] <ogra_> not sure who would do security support etc for it though
[16:58] <ogra_> but according to the bug pitti approved it
[16:59] <GrueMaster> My suggestion based on ogra_'s change requirements would be to have the community download and modify our esixting images as a proof-of-concept.
[16:59] <GrueMaster> Then we can pick it up in O
[17:00]  * ogra_ wouldnt mind implementing it (we did the same for omap in lucid) but wont have the time 
[17:00] <GrueMaster> Lucid had 2 months before release.
[17:01] <ogra_> thats why i asked if NCommander would like to do it, if he doesnt thats fine and we have to live with it
[17:01] <ogra_> lucid was also a lot more complex since we didnt have anything to derive the new subarch from
[17:02] <GrueMaster> lucid had members on our team with working hardware to fix with.
[17:03] <NCommander> ogra_: from what I've seen, the efria boards are different than the old imx51, and I can tell you from experience taht even though we have uboot support for omap/omap4/dove, its required quite a bit of tweaking across multiple board types. In addition, we also need changes to flash-kernel, libdebian-installer, livecd-rootfs, and the seeds
[17:03] <ogra_> NCommander, efika is very close to omap
[17:03] <ogra_> forget about babbage
[17:03] <NCommander> any change to livecd-rootfs is by nature disruptive to all image builds. f-k chnages are disruptive to all armel images.
[17:03] <ogra_> there are no changes to livecd-rootfs
[17:03] <GrueMaster> close only counts in horse shoes & hand grenades.
[17:04] <ogra_> the only thing you need to do is cp the omap post-boot script in debian-cd to mx51 and change a few lines
[17:04] <GrueMaster> Blaze is veryclose to panda, yet...
[17:04] <ogra_> and add a crontab entry
[17:04] <ogra_> GrueMaster, building blaze images would cost me 30min of work or even less
[17:05] <ogra_> i mean changuing the builder to create them
[17:05]  * NCommander notes he would have issues with spinning blaze images because of how close to release we are
[17:05] <ogra_> mx51/efika will be a bit more and require a bit of going back and forth between coder and tester indeed
[17:06] <NCommander> ogra_: and you really think we could push it three weeks from release, with final freeze around the corner?
[17:06] <ogra_> as i said i was planning to do it this week, but neither i nor ScottK had time yet
[17:06] <ogra_> and with the sound patches ahead that are high prio i wont have time
[20:02] <slangasek> cjwatson: pitti noted in bug #750585 that he would like your review as well before acking; do you think you'll have a chance to do so this week?
[20:02] <ubot4`> Launchpad bug 750585 in linux (Ubuntu) "[FFe] support for making linux-libc-dev coinstallable under multiarch (affects: 1) (heat: 14)" [Wishlist,New] https://launchpad.net/bugs/750585
[20:21] <bdrung> hi, can i update lintian from 2.5.0~rc1 to 2.5.0~rc2 without a FFe?
[20:27] <ScottK> bdrung: Assuming it's just bug fixes, yes.
[20:27] <ScottK> bdrung: Is it going to build this time?
[20:27] <bdrung> ScottK: yes. i managed to win against pkgbinarymangler
[20:27] <ScottK> Excellent.
[20:28] <bdrung> and it does it's job on my system for a few days
[21:31] <bdrung> ScottK: sadly it fails again due to multiarch: https://launchpadlibrarian.net/68599356/buildlog_ubuntu-natty-i386.lintian_2.5.0~rc2ubuntu1_FAILEDTOBUILD.txt.gz
[21:31] <ScottK> Maybe slangasek will save you then.
[21:32] <bdrung> slangasek: can you save me?
[21:32] <bdrung> lintian hates me :'(
[21:34] <slangasek> well, it's not due to multiarch, it's due to some strangeness lintian is trying to do with a multiarch field
[21:34] <slangasek> how did this work in a local build for you, or in Debian?
[21:35] <bdrung> slangasek: it did
[21:35] <slangasek> yes, but how
[21:35] <slangasek> trying to set Multi-Arch: bad is not allowed
[21:36] <slangasek> so how did this code pass for you locally with Ubuntu's dpkg?
[21:36] <bdrung> let me digg out the local build log
[21:39] <bdrung> slangasek: strange. this particular tests fail the same way but the build continues
[21:40] <slangasek> could it have to do with DEB_BUILD_OPTIONS=parallel=n?
[21:40] <slangasek> the test itself is wrong anyway since dpkg-deb will refuse to build a package containing an invalid field, so that should be fixed
[21:42] <bdrung> slangasek: but i restricted the parallelism to 1 (to make the build log clearer)
[21:42] <slangasek> in the package itself?  Because the buildds don't
[21:43] <bdrung> yes, in d/rules: PAR_ARGS=-j 1
[21:47] <slangasek> ok, no clue then.  I recommend just fixing the test to drop the package using 'bad' out of debian/control.in, and emptying t/tests/fields-multi-arch/tags
[21:50] <bdrung> k
[22:07] <cjwatson> slangasek: OK, I'll have a look tomorrow when I'm more sober
[22:08] <slangasek> cjwatson: ok, cheers :)
[22:09] <ScottK> FYI, builders are currently FUBAR, but lamont is on the job.
[22:11] <lamont> inter-datacenter comms burp from the ISP --> pain
[22:39] <lamont> or whatever it was...  that'll teach me to go run an errand for my kids