[00:22] would anyone object if i took http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=6f49c05ceb2a1935d07c49c2e100b5cf3cdf5f26 to fix bug 670128 for natty? [00:22] 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] the default browser check in chromium is pretty broken without this [00:22] chrisccoulson_: Please fix that. [00:23] It's driving me nuts. [00:23] ScottK - excellent, thanks [00:23] broken in KDE too [00:23] Maverick worked, so it's a regression. === smspilla|zzz is now known as smspillaz [07:02] there will be a brief disturbance in the i386 virtual builder pool [10:06] I'd greatly appreciate someone having a look over bug 752372 [10:07] 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] thanks [11:13] ev: I think string freeze exceptions should be approved by the translators (as well as release team) [11:15] 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] 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] 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] works for me, and an understandable point [11:18] thanks [11:22] hmm, no CD images today [11:22] Riddell: weren't any yesterday either if it makes you feel better? [11:24] yes, errors in the logs but I can't work out exactly what [11:27] Riddell: mail to -translators sent and awaiting approval [11:27] thanks [11:30] huh, that's a bizarre set of CD build failures [11:31] man hat livecd-rootfs geborken [11:31] http://kapok.buildd/~buildd/LiveCD/natty/kubuntu/current/livecd.kubuntu.kernel-generic: [11:32] 2011-04-07 05:52:38 ERROR 403: Forbidden. [11:32] cjwatson: there are no Ubuntu lives either [11:32] I wouldn't expect this to be flavour-specific [11:34] oh scheisse [11:34] -rw------- root/root 1368 2011-04-05 20:25 ./boot/vmcoreinfo-2.6.38-8-generic [11:34] -rw------- root/root 4523328 2011-04-05 20:23 ./boot/vmlinuz-2.6.38-8-generic [11:34] -rw------- root/root 2654256 2011-04-05 20:23 ./boot/System.map-2.6.38-8-generic [11:34] somebody broke the kernel packages [11:38] vmcoreinfo and System.map were mode 0600 before, but vmlinuz being 0600 is new [11:39] hmm, apparently deliberate [11:39] [ Kees Cook ] [11:39] * [Config] packaging: adjust perms on vmlinuz as well [11:41] uploaded livecd-rootfs 1.166 with a workaround [13:08] 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] 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] ogra_: why isn't the existing imx51 code enough? [13:09] 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] because its only written for babbage and totally redboot centric [13:09] well, I'm not going to be writing the code, so do whatever is convenient [13:09] efika and friends use u-boot and a totally different setup to boot [13:09] (also we didnt have preinstalled images at babbage times) === seb128_ is now known as seb128 [15:29] rebuilding Ubuntu and Kubuntu desktop CDs === doko_ is now known as doko [15:30] cjwatson: do we remove the "development" in lsb_release before the beta? [15:35] doko: just before final release (https://wiki.ubuntu.com/ReleaseProcess) [15:36] ("Make sure that /etc/issue, /etc/issue.net, and /etc/lsb-release are correct", release minus 3 days) === robbiew1 is now known as robbiew [16:12] 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] cjwatson: it's bug 753620 [16:12] 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] tremolux: see my comment [16:21] cjwatson: thank you, yes, I will do that now [16:43] 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] 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] I don't really have any stake in it either way [16:48] 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] 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] Launchpad bug 746023 in alsa-lib (Ubuntu) "No sound on omap4 (affects: 2) (heat: 14)" [Medium,New] https://launchpad.net/bugs/746023 [16:53] NCommander, just taking the omap boot script and modifying it for the efika setup should be trivial [16:54] they use ext2 for booting and mount the partition in /boot but otherwise they should be the same [16:54] ogra_: Problem is getting it tested. [16:54] GrueMaster, not our issue [16:54] thats why we have owners of images nowadays [16:54] ;) [16:55] 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] note that its not a new image, its just a new subarch [16:55] ogra_: it is a new image by defintion. [16:55] ScottK already agreed on just taking our headless image [16:56] so userspace is identical to all other images we provide [16:56] I'm fine with just doing a headless image. [16:56] (also here now). [16:56] the only bit missing is the support for the mx51 subarch on the image builder [16:56] If it requires more than dropping a different kernel into the /boot, it is non-trivial. [16:56] I was offline the last couple of days due to $WORK. [16:57] GrueMaster, well, different kernel, different u-boot binary and other fs for the first partition, thats all [16:57] Is the kernel in main? [16:57] 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] it was approved by pitti for main [16:57] No, but for a preinstalled image, it shouldn't be. [16:57] ... shouldn't need to be. [16:58] not sure who would do security support etc for it though [16:58] but according to the bug pitti approved it [16:59] 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] 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] Lucid had 2 months before release. [17:01] thats why i asked if NCommander would like to do it, if he doesnt thats fine and we have to live with it === smspillaz is now known as smspillaz|zzz [17:01] lucid was also a lot more complex since we didnt have anything to derive the new subarch from [17:02] lucid had members on our team with working hardware to fix with. [17:03] 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] NCommander, efika is very close to omap [17:03] forget about babbage [17:03] any change to livecd-rootfs is by nature disruptive to all image builds. f-k chnages are disruptive to all armel images. [17:03] there are no changes to livecd-rootfs [17:03] close only counts in horse shoes & hand grenades. [17:04] 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] Blaze is veryclose to panda, yet... [17:04] and add a crontab entry [17:04] GrueMaster, building blaze images would cost me 30min of work or even less [17:05] 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] mx51/efika will be a bit more and require a bit of going back and forth between coder and tester indeed [17:06] ogra_: and you really think we could push it three weeks from release, with final freeze around the corner? [17:06] as i said i was planning to do it this week, but neither i nor ScottK had time yet [17:06] and with the sound patches ahead that are high prio i wont have time === charlieS_ is now known as charlieS [20:02] 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] 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] hi, can i update lintian from 2.5.0~rc1 to 2.5.0~rc2 without a FFe? [20:27] bdrung: Assuming it's just bug fixes, yes. [20:27] bdrung: Is it going to build this time? [20:27] ScottK: yes. i managed to win against pkgbinarymangler [20:27] Excellent. [20:28] and it does it's job on my system for a few days [21:31] 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] Maybe slangasek will save you then. [21:32] slangasek: can you save me? [21:32] lintian hates me :'( [21:34] well, it's not due to multiarch, it's due to some strangeness lintian is trying to do with a multiarch field [21:34] how did this work in a local build for you, or in Debian? [21:35] slangasek: it did [21:35] yes, but how [21:35] trying to set Multi-Arch: bad is not allowed [21:36] so how did this code pass for you locally with Ubuntu's dpkg? [21:36] let me digg out the local build log [21:39] slangasek: strange. this particular tests fail the same way but the build continues [21:40] could it have to do with DEB_BUILD_OPTIONS=parallel=n? [21:40] 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] slangasek: but i restricted the parallelism to 1 (to make the build log clearer) [21:42] in the package itself? Because the buildds don't [21:43] yes, in d/rules: PAR_ARGS=-j 1 [21:47] 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] k [22:07] slangasek: OK, I'll have a look tomorrow when I'm more sober [22:08] cjwatson: ok, cheers :) [22:09] FYI, builders are currently FUBAR, but lamont is on the job. [22:11] inter-datacenter comms burp from the ISP --> pain [22:39] or whatever it was... that'll teach me to go run an errand for my kids