[01:59] cjwatson: I'd ask Daviey. I haven't been following dovecot stuff. [03:55] Good morning [04:02] if anyone is awake, I uploaded glib2.0 2.29.92, as part of GNOME 3.1.92 which is due today. I tested it a bit last night and now, and compared to our git snapshot from Thursday it only fixes a couple of more bugs. We already had the big bug fix backported [04:02] if we want it in the beta, it would be better to accept it now, as the test suite takes a while on armel [04:03] but an armel FTBFS doesn't cause arm images to become uninstallable, so it's reasonably safe [04:03] (the current version FTBFSed as well, need to investigate this) [04:16] infinity, NCommander: ^ WDYT about the glib update? it's not really critical for b2, but would be good to have the current libs for .92; the apps will follow today, and some might depend on .92 [04:17] +GLIB_NEW_REQUIRED=2.29.2 [04:18] ah, there we go already, just packaging anjuta [04:18] ignore me, .2 != .92 [05:30] pitti: I'm fine with it. [05:32] pitti: Accepted. [05:32] infinity: ok, cheers [05:32] so http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html doesn't look too bad, although the recent nova upload seems to have broken [05:32] Daviey: ^ is that critical for the server images? [06:11] rejecting at-spi2-atk, needs fixing; told TheMuso [06:32] hello all. could I draw your attention to bug #844049 and bug #841885 ; one of these reverts the "power-cog" icon in the top-right back to an earlier single item design. This should not impact screenshots much if it's not covered. The other change enlarges the percentage coverage for the desktop.svg icons. This shouldn't impact screenshots significantly either, because it's the same thing, just enlarged [06:32] Launchpad bug 844049 in ubuntu-mono (Ubuntu) (and 1 other project) "UIFe: Indicators - Device indicator icon looks like it has an emblem (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/844049 [06:32] Launchpad bug 841885 in ubuntu-mono (Ubuntu) (and 1 other project) "UIFe: New show-desktop icon looks too small (affects: 4) (heat: 24)" [Undecided,Confirmed] https://launchpad.net/bugs/841885 [06:33] these are none-code updates and existing svg icons, and should be low impact === seb128_ is now known as seb128 [08:13] pitti: I believe that the nova issue is due to components-mismatch of socat. [08:14] Daviey: right, that would be it [08:16] cjwatson: I do not believe dovecot has undergone any documented testing in oneiric to date, which means that by testing a new upstream version /works/, it's an improvement on the current known status. :) [08:16] pitti: blocked on security review btw. [08:22] sladen: followed up to both bugs [08:23] pitti: ta [08:28] Daviey: this is dovecot-metadata-plugin rather than dovecot, for clarity [08:32] cjwatson: Ah. === chrisccoulson_ is now known as chrisccoulson [09:24] rmadison should be up to date again, thanks to sysadmin (re discussion last night) [10:51] cjwatson, could your live-bvuild and seed changes to support usb key builds have had any unexepected sideeffects ? for daily-preinstalled we seem to only get 1.6G big iso images suddenly [10:52] i could understand how the format changed to iso, but i definitely dont get why a seed seems to be used that makes us end up with 1.6G content [11:00] ogra_: unexpected side-effects are always possible, but if I were you I would trace the problem step by step rather than trying to guess at a cause [11:01] well, i dont see changes in debian-cd/cdimage that could have any influence on live-build's behavior in that regard [11:05] skaet: can you track bug #840593 [11:05] Launchpad bug 840593 in indicator-datetime (Ubuntu) (and 1 other project) "Indicator-datetime month/year navigation does not work [regression] (affects: 12) (dups: 4) (heat: 74)" [Undecided,Confirmed] https://launchpad.net/bugs/840593 [11:06] hmm, so the isos are not on the live builders at least ... but the ext3 images are still 1.5G [11:07] * ogra_ thinks there are two probs [11:27] sladen, it is a dupe of bug 807509 which is already tracked [11:27] Launchpad bug 807509 in ido (Ubuntu Oneiric) (and 3 other projects) "Cannot click on Calendar to select another day, month or year (affects: 44) (dups: 7) (heat: 248)" [High,Triaged] https://launchpad.net/bugs/807509 [11:33] skaet: when you're around... would you like freshened oneiric chroot tarballs before or after beta2? [11:33] I notice that the dist-upgrade time has become significant again [11:35] jibel: double plus good++ [11:35] lamont: how long does that take? it's fairly quiet right now, so we can do with some partial buildd outage right now [11:35] pitti: it's no outage at all - it's just uploading new tarballs to launchpad [11:35] lamont: the "OMGneedthisbuilt" phase usually starts later in the day/tomorrow, at that point faster chroots would certanily be appreciated [11:36] OTOH, the lp-buildd rollout that's going to happen this morning, that's a rolling outage. [11:36] lamont: ah, I thought you are asking because you have to take down buildds for that [11:36] nah - it's just a change, and y'all are near a deadline, so I like to check rather than jfdi [11:36] the lp-buildd rollout was discussed here friday [11:36] seems fine to me [11:42] I think you can JFDI at the moment [11:54] cjwatson: ok. being vanguard this week so I'll sneak it in after I get done w/ the current triage pass, in all likelihood [12:21] right. world on manual for a lp-buildd upgrade then [12:21] ] [12:21] ops [12:23] linux-powerpc64-smp: Depends: linux-image-powerpc64-smp (= 2.6.35.24.18) but 2.6.35.30.23 is installed [12:23] not amused [12:48] * ogra_ cries ... i dont seem to be able to find out why we have 1.5G images, the livefs build logs dont install anything unusal, the seeds seem fine but still we have 1.5G images on the livefs builders [12:48] i dont get wheer the extra gig comes from [12:52] hmm, they are probably not to big at all ... just not compressed [12:54] * ogra_ slaps forehead [12:56] ogra_: all good then, or is the lack of compression a bug by itself? [12:56] the lack of compression is a debian-cd bug, just looking nto it === Ursinha is now known as Ursinha-brb [13:27] ^ rejecting ltsp as per stgraber's request (broken) [13:33] pitti: uploaded another one that should fix everything wrap-and-sort messed up [13:35] * pitti starts working on https://bugs.launchpad.net/~ubuntu-archive, should help to reduce the FTBFS bug list, too [13:39] good morning [13:40] hey skaet [13:41] heya pitti, all the bits for gnome uploaded? [13:41] skaet: some, tarballs still being wrapped upstream [13:41] skaet: we package them as they come in [13:42] pitti, fair enough. What's still left? [13:42] skaet: evolution-data-server currently being packaged, otherwise most apps didn't get an update yet [13:43] pretty harmless so far (translation updates and minor bugs), though, except for glib2.0 which got some nice fixes for critical bugs [13:43] * skaet nods [13:44] from the backscroll, looks like there are still some concerns on the ARM side. [14:23] skaet: Just got the e-mail from the tracker telling me Edubuntu got added. We'll want that new ltsp for beta2 so I won't even bother testing the current builds (I tested yesterday's and they were fine) [14:24] stgraber, fair enough, marking them pending ltsp upload for rebuild. [14:26] skaet: thanks === bdmurray_ is now known as bdmurray === Ursinha-brb is now known as Ursinha [16:23] skaet: Yea, we're gearing up for another respin. Issues with the image build/publish scripts have apparently plagued us since Beta 1 (I was doing server testing so didn't notice daily build issues). [16:26] anyone here using the nouveau drivers? [16:26] hey slangasek, how are you [16:26] * slangasek waves to pitti [16:26] slangasek: ah, still no feedback on nvidia? darn [16:26] I was hoping we could put that change into b2 [16:27] yes, I would really like that change in b2 [16:27] I think I am, can maybe test in 4 hours [16:27] and if we're not going to get it, I should at least upload the *other* plymouth changes that I have staged, which are needed to have logging working again [16:27] (I'd really like plymouth to be debuggable in beta2...) [16:38] cjwatson: Around? [16:39] yes [16:39] CXXFLAGS += -O9 ... # things that inspire confidence [16:39] cjwatson: Could use a sanity-check review of 'bzr diff /home/adconrad/debian-cd/' on antimony. [16:40] i.e. "don't gzip things that are already gzipped"? [16:40] cjwatson: Sanity tested the syntax in /srv/cdimage.ubuntu.com/scratch/ubuntu/daily-preinstalled/debian-cd/armel+ac100/Makefile [16:40] cjwatson: Yeah. [16:40] lose the second and third @ (the ones inside the if), and put 'set -e; ' before the if [16:40] but otherwise LGTM [16:41] cjwatson: Oh, fair enough. I was annoyed already that I did it in shell, until I realised there seems to be no make anywhere in that Makefile. [16:41] oh and I'd use grep -q rather than redirecting [16:41] but nits [16:43] cjwatson: re-review? [16:44] infinity: is giving dpkg an internal copy of dpkg.cfg.d/multiarch still on your radar for this cycle, or should I take a look myself? [16:44] my usual idiom is 'set -e; if ...' or 'set -e; for ...', but that's fine too [16:44] (I don't think it matters in the if cas) [16:44] *case [16:45] cjwatson: In the if case, set -e would do nothing, so yeah. [16:45] cjwatson: (Or if it did, I'd be deeply concerned) [16:45] slangasek: Erk. If you have the time, please do. I'm still happy to look at it, though. [16:46] in the for case I'm never quite sure and prefer to avoid the question rather than looking it up :) [16:46] infinity: I will try to make the time so we can get it in before beta2... we're still getting bug reports from folks saying nspluginwrapper doesn't work, where the answer is "you didn't read the assigned reading" [16:46] much like the way I only ever change IFS according to a strictly defined idiom I decided was safe after much thought once [16:49] cjwatson: I try (ish) to fit whatever I see in the target sources. But debian-cd's "make" (and I use that term loosely) made me throw my hands in the air and just type. [16:49] It's deceptive. It starts out looking a lot like a makefile too. [16:52] it's much better upstream nowadays, it's just that the merge is a nightmare [16:52] I can imagine. [16:52] and obviously breaking cdimage is not high on my list of things to do [17:06] infinity: sorry to bother you, are you writing up some information about the live build process? [17:08] scott-work: Well, the spec is assigned to me. Currently, there's been little done with it, though. Perhaps we'll actually figure out what information people want/need and try again soon. :/ [17:10] infinity: i ask because ubuntu studio would like to move to a live image and shnatsel in particular though this would be extremely helpful [17:10] infinity: has the process changed recently? [17:11] s/though/thought [17:11] scott-work: The underlying way we build livefses changed this cycle (from livecd-rootfs to live-build), but otherwise, it's business as usual. [17:12] It hardly matters since the process for derivatives that we build centrally is "ask the CD image team to switch things over and give a good explanation". [17:12] (But we aren't going to do it for Oneiric!) [17:12] scott-work: The problem with the documentation of it all is that it bounces between either docs that say "1) learn to program 2) grab the code and mangle it" and "Here's a nice list of people to contact about how to get things done". I suspect we need some happy medium. [17:13] infinity: speaking of live-build, want me to backport the patch for bug 803547? [17:13] Launchpad bug 803547 in live-build (Ubuntu Oneiric) (and 2 other projects) "live-build lacks EXT4 support for binary image types (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/803547 [17:13] cjwatson: haha, no we aren't planning this for oneiric! heavens no [17:14] cjwatson: Oo. ext4 performs a lot better on flash, AIUI, it might be shiny. Not sure if switching our images a few weeks before release is sane, but has anyone accused ubuntu-arm of sanity before? [17:14] well, it's a beta-2 milestoned bug which is why I noticed [17:15] if that's not sane, I don't object to you pushing it back and we'll get it in a merge for P [17:15] but one or the other :) [17:15] cjwatson: Yeah, if you can merge cleanly, I think we'd be all over it. [17:15] mkay [17:15] * cjwatson has a go at that then [17:16] I *think* we sprinkled enough s/ext3/ext3|ext4 in other tools to make it kinda work if we decide to swap, but I should double-check that. [17:16] cjwatson: by "cd image team" i believe you mean the team who is responsible for that derivative, i.e. in this case ubuntu studio? [17:17] scott-work: I believe he was referring to ~ubuntu-cdimage [17:18] cjwatson: Oh, hah. I should probably be re-added to that team, BTW. :P [17:18] cjwatson: Having my LP membership reflect UNIX permissions might be sane. [17:18] hmm [17:18] cjwatson: in bug #853738, the submitter says a clean beta1 install did not give him multiarch support [17:18] Launchpad bug 853738 in nspluginwrapper (Ubuntu) "nspluginviewer is missing in amd64 (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/853738 [17:19] slangasek: That's disconcerting. [17:20] hence me flagging it :) [17:20] merp [17:20] scott-work: yeah, what infinity said [17:20] The dpkg conffile would sort of paper over that anyway. But if the installer really isn't consistently writing the file, that's unpleasant. [17:20] as in the team that actually has power to do something about this [17:21] infinity: oh yes. Reactivated [17:21] cjwatson: Danke. [17:22] slangasek: asked for more info [17:28] cjwatson, infinity: hmmm, i believe i'm confused about the process for moving ubuntu studio to a live image, i had viewed this as we needed to do all the leg work on package and seed manipulation based on previously used processes, is this not the case? [17:29] no; somebody would need to prepare appropriate live and ship-live seeds, granted, but the task of actually switching to build a live image falls to ubuntu-cdimage [17:31] infinity: uploaded. dinnertime now [17:31] it sounds like we should do some homework to know what changes we need to make and then perhaps talk to someone wiht ~ubuntu-cdimage [17:31] with [17:31] good night everyone [17:31] cjwatson: Cheers. [17:39] pitti, are all the gnome bits that are planned to be uploaded, done? [17:40] Daviey: Would you mind re-uploading backuppc using -v with dpkg-buildpackage so all the relevant changelog entries get into .changes? [17:40] cron up there is a bugfix-only change; not at all critical for beta, but wanted for final [17:41] slangasek, ack [17:44] infinity, NCommander, daily builds have been disabled now. [17:45] skaet: Kubuntu will need to be respun for qtwebkit, quassel, and image sizing. [17:46] skaet: Kay. I'm spinning some armel stuff to shake out all the image-building bugs we've had over the last few weeks. [17:46] skaet: Everything should be shiny once this is done. :P [17:48] ScottK: ah, good catch. [17:49] :-) [17:49] Daviey: I'll reject the current one. [17:49] ta [17:50] infinity, ack, did ogra_ 's fix to debian-cd get resolved or is that still pending? [17:52] skaet: I fixed up debian-cd and cdimage, we should be good. [17:56] infinity, coolio. [17:56] skaet: where do we sit on candidate images? I have verification that turning on flicker-free for lightdm passes smoke testing, so I'd really like this plymouth upload in for beta2 so we get further testing of that, as well as fixes for logging support [17:57] slangasek, we haven't started spinning the candidates yet. Smoke testing only until now. [17:57] If the fixes are ready, ok to upload and we'll pull them in. [17:59] ack [18:08] plymouth uploaded [18:15] Daviey: There's a lot to review for backuppc. Given there's a security fix in there, I'm inclined to just push it in. Has anyone on server team tested this package? [18:22] Actually it's not so bad. [18:33] skaet: the main one we are still waiting for is gnome-control-center; the bulk is in, though [18:34] pitti: care to review plymouth? [18:35] I can look. [18:36] slangasek: looks fine, accepted [18:36] I love it when the changelog is more verbose than the changes. [18:37] live-build accepted, too [18:38] wow @ five-digit bug (in cron) [18:38] skaet: Verified that my debian-cd/cdimage fixes DTRT, removing point [5] from the etherpad. [18:38] slangasek: ^ do you think the cron update is important for b2? or was that just queueing up the fix? [18:39] slangasek: ah, you said in backscroll, nevermind [18:39] pitti: not important for b2, just queuing; but if there's a window, we might as well take it now [18:39] IMHO [18:39] (very low risk) [18:39] (famous last words) [18:39] pitti, so, ok to start rebuilds from your perspective. [18:39] ? [18:40] ScottK: Allison is the unoffical lover of that package. [18:40] skaet: not yet, some stuff is still building/publishing [18:40] skaet: Waiting on plymouth, at least. [18:40] pitti, http://pad.ubuntu-uk.org/ubuntu-release [18:40] ScottK: If it does blow up, she will glue it back together, i'm sure. [18:41] * pitti asks rodrigo about control-center [18:41] infinity, ack. :) just trying to find out if the gnome stuff [2] is satisfied, which sounds like not. [18:42] skaet: e-d-s done, pad updated [18:44] pitti, thanks [18:44] Daviey - so you want spins without socat? [18:45] ev: Thanks for the f-k catch. [18:46] I guess we'll need a d-i rebuild to pick that up for omap netinst. :/ [18:47] skaet: we just got another bunch from GNOME, working on them now [18:47] pitti, thanks! [18:47] skaet: is it super-urgent yet that we have to do the "cut off point"? [18:47] pitti, seb128: have pushed fixes to the upstart jobs for gdm and lightdm to bzr; I haven't heard any reports that can conclusively be linked to this, but a change early in oneiric reverted pitti's fix for bug #615549 from maverick without explanation [18:47] Launchpad bug 615549 in kdebase-workspace (Ubuntu Maverick) (and 5 other projects) "gdm/kdm starting too early for DRM modules to load, no video (affects: 66) (dups: 10) (heat: 131)" [High,Fix released] https://launchpad.net/bugs/615549 [18:48] pitti, seb128: since I don't know of any bug reports related to this, it's hard to evaluate the risk of taking this change - but it does seem to be an accidental change that may cause regressions vs. natty, so I'm inclined to say we should have this in for release [18:49] slangasek, no objection from me to get it in [18:49] seb128: have you seen any bug reports that look like they might be related to this (i.e., a resurgence of 615549)? [18:50] not that I can remember no [18:50] these look just fine to me [18:51] infinity: don't thank me, thank ubiquity's shell syntax checking on build [18:53] pitti, re: cut off point. Yes, we're running out of time to recover from accidental regressions, so need to start getting the formal candidates built. [18:53] infinity: we'll need one anyway - stgraber stpotted an IPv6 problem in netcfg [18:53] wretched executable bits [19:01] plymouth's kernel commandline handling makes baby Jesus cry [19:01] also me [19:08] skaet: thanks [19:14] I've been pinged by a lubuntu tester, there is no image available in http://cdimage.ubuntu.com/lubuntu/daily-live/20110919/ but images are on the tracker. [19:19] jibel: have you checkd the build logs? [19:20] reading the ubiquity diff doesn't tell me much, but I guess we want that [19:21] * ScottK thinks we do. [19:22] cjwatson, the following error appears in cd-build-logs [19:22] make: *** [apt-update] Error 100 [19:22] ERROR WHILE BUILDING OFFICIAL IMAGES !! [19:22] in http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/oneiric/daily-live-20110919.log [19:23] transient then. I'll kick a rebuild [19:23] ok thanks [19:29] anything I can help reviewing right now? [19:42] skaet: It really doesn't matter either way, the nova issue is server-ship only. [19:43] skaet, infinity: I updated the [2] condition in the pad for the packages we are waiting for (currently being worked on by seb128 and rodrigo) [19:43] what's the status of bug #851659? [19:43] Launchpad bug 851659 in jenkins (Ubuntu) (and 4 other projects) "[FFE] Sync asm3 3.3.2-1 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/851659 [19:44] thanks pitti [19:59] Any respins happening for server stuff after 20110919 ? About to start testing the iso's.. [20:00] Think so. [20:00] so hold off? :-/ [20:00] Testing is always good. [20:01] that RAID1 test takes 45 minutes because of all the reboots and re-syncs .. I only want to do it 2 more times (this one and RC) ;) [20:11] SpamapS: We have nothing urgent requring a respin? [20:21] there'll be a new netcfg to fix ipv6 [20:21] infinity, skaet: nautilus uploaded, that was the last one we care about which we can get [20:22] the others will trickle in tomorrow (but are not that visible in the desktop), and control-center is blocked [20:22] I updated the pad with the version to wait for (building, publishing) [20:22] thanks for the update pitti. [20:22] I'd like to hit the sack now, anything else you need from me? [20:23] pitti, nothing comes to mind, sleep weel. [20:23] pitti: Go sleep. [20:23] well even [20:23] so, good night! [20:23] :) [20:24] lubuntu desktop 20110919.1 posted to the tracker [20:35] slangasek: Want to give a quick sanity review to that jasper upload? [20:36] slangasek: http://paste.ubuntu.com/693316/ for the diff. [20:40] thanks jibel [20:40] slangasek: Or just accept it blind, because I'm oh so pretty. [20:40] slangasek: I'm game for either. [20:43] the combination of netcfg and isc-dhcp I'm uploading now has been tested in a whole bunch of IPv4/IPv6 combinations by stgraber [20:43] it'll need a debian-installer upload after [20:45] infinity: looks sane to me, accepting [20:49] I'd've used blkid instead these days, but meh [20:49] less likely to be removed in future [20:49] cjwatson: fstype is used all over initramfs-tools anyway. If and when that changes, jasper can too (or, maybe it'll be gone by then anyway... A man can dream) [20:51] initramfs-tools uses fstype in three places and blkid -s TYPE in four [20:51] I was going with the claim in comments that fstype was somehow "more robust" or some such. [20:51] And it works for this use-case. [20:51] yeah, it's fine for now [20:51] But I'm happy to switch it out. [20:51] nah, leave it if you've tested it [20:51] * infinity nods. [20:51] just a comment for the future [20:51] I didn't mean I'd switch it out before the next publisher run. Just "sometime". [20:52] I think blkid used to suck more than it does now [20:59] slangasek: multiarch> oh bugger [20:59] guess what apt-setup-udeb's Architecture line is [21:00] I suppose I'd better make that Arch any [21:00] Oh, d'oh. It was building on i386 and skipping some amd64 special-casing? [21:01] yup [21:01] I guess that somehow beats the opposite, where every arch would now have i386 as a foreign arch. :P [21:09] ^ would be nice to still get that gnome-control-center in if we can, I think pitti is off for the night so if anyone wants to ack it [21:09] then we are done for desktop updates [21:10] seb128: Done. [21:10] infinity, thanks [21:18] cjwatson: Accepted. [21:20] Oh look, canonical-kernel-team/ppa is eating the buildds again. :/ [21:21] skaet: I won't be able to get chromium in until late tonight, so I'd say not to hold up for it, but pick it up if there's a respin [21:21] micahg, gotcha, thanks for the clarification. [21:23] Anyone looking into the ubiquity FTBFS? [21:23] cjwatson: heh, doh [21:25] Ugh, indicator SOVER bump? [21:25] Or something? [21:40] If no one's fixing ubiquity already, I can. Looks like a missing build-dep. [21:40] Yes. Please. [21:41] You might check in #ubuntu-installer first to make sure though. [21:48] skaet: I've targeted bug #779382 to beta-2; it prevents users who use a 2d Ubuntu desktop and who have opted in to an update-notifier option that figured prominently in the Lucid release notes from receiving any further notifications on their desktop about package updatse [21:48] Launchpad bug 779382 in update-notifier (Ubuntu Oneiric) (and 8 other projects) "update-notifier not visible under unity (affects: 13) (dups: 2) (heat: 68)" [Medium,Confirmed] https://launchpad.net/bugs/779382 [21:49] skaet: since this is a behavior change between beta-1 and beta-2 (nominally a bugfix in unity-2d to bring its behavior in line with unity-3d), I think it's critical that we get this fixed in the archive for beta-2 so that anyone upgrading to beta-2 doesn't get stuck there [21:49] slangasek, understood. should it be medium priority then? [21:50] skaet: that's the bug bot being arbitrary - the task on unity is marked 'Critical' :) [21:50] slangasek, ok, that makes more sense. :) [21:56] Testing the build-dep fix for ubiquity locally. If this passes, I'll upload. [21:57] infinity, thanks. [21:57] Looks like ev already fixed it in bzr and forgot to upload. :P [21:57] So, I'll just upload his (identical) fix, if this passes. [21:57] * infinity taps his foot while the build grinds. [21:58] Maybe I should eat something while this is going on. [22:02] Oh, well, that's pleasant. Fixing the build-dep issue just leads to the testsuite failing later. [22:02] That might be why ev hasn't uploaded yet. :P [22:03] * ScottK wonders why the failing one got uploaded. [22:05] Please can someone review dnsmasq, introduces a new binary package. [22:05] I uploaded it. [22:15] (the dnsmasq is blocking another bug.) [22:15] argh, should've tested apt-setup building with -B [22:18] cjwatson: lacking a binary-arch target? :/ [22:18] well, similar, it's a bit different with dh(1) [22:19] Initiating build ca0a9b23ee55ba8966f57b9c3e65bcf9c423c28f with 0 processor cores. [22:19] That seems oddly appropriate for an ARM system. [22:36] Daviey: +ifeq ($(DEB_BUILD_ARCH_OS),linux) - technically wrong :) should be DEB_HOST_ARCH_OS... [22:39] slangasek: Ah! Well spotted, Stolen directly from the Debian package, is it worth changing that cherrypick for something which seems to provide the same end result? [22:40] only if you were planning on cross-building the package using a kfreebsd system [22:40] Daviey: nah, it makes no difference at all for us, it only matters for those who are cross-building from Linux to non-Linux ports (of which the latter, we have none :) [22:40] or vice versa, yes [22:40] Daviey: You might want to inform the Debian maintainer that it's wrong. For us, it probably doesn't matter. [22:40] The best part is, we don't really care about !linux arch :) [22:40] right, what infinity said [22:40] it's good to be in the habit of remembering the build/host distinction though [22:41] * Daviey adds it to his todo to raise a Debian bug tomorrow. [22:44] dnsmasq debian/rules makes me sad [22:46] Daviey: why does dnsmasq-utils Conflicts: dnsmasq (<<2.40)? [22:47] +Requires dnsmasq 2.40 or later and may not work with other DHCP servers. [22:47] maybe that's why. But then shouldn't it be a depends? [22:48] or at least Breaks [22:48] hello all. Based on conversations with Mark I've filed https://bugs.launchpad.net/ubuntu-font-family/+bug/854264 I haven't subscribed ubuntu-release as there is nothing to actually review yet [22:48] Launchpad bug 854264 in ubuntu-font-family "UVFe & FFe: New upstream version of Ubuntu Font Family ~0.80 (affects: 1) (heat: 6)" [Undecided,New] [22:50] slangasek: "may not work with"... I guess they think it could possibly, if you will it to? [22:57] hey, anything's possible :) [22:58] sladen: is adding new font files the main difference for this new upstream version? Is there an estimated disk space impact for these new files? [22:58] if they're not going to be enabled in the default experience, we should presumably not break our backs making room for them on the CD... [22:59] slangasek: my estimate is 900 kB compressed. Obviously if CD space is that tight(tm) it would have an impact on viability of the request, which I could then convey back up the chain [23:00] space is always that tight :) [23:00] slangasek: I also haven't uploaded the community wallpapers yet, so there's always the option of trading 3-4 of those for the space [23:01] slangasek: which is horse-trading that could be done internally within the Product Stategy Dept. [23:02] sladen: I'm going to start recommending rather soon that anyone asking for more CD space figure out what should be removed to make room [23:03] We can just remove English. [23:03] sladen: so if you could figure out a trade-off, that would be good [23:04] infinity: -.-- --- ..- / ..-. .. .-. ... - [23:04] sladen: right now, any "free" space you see is essentially by luck [23:04] I don't speak morse, but I'm going to assume that was rude and assure you that I'm currently flipping off my monitor. [23:05] cjwatson: yeah, can do, but wouldn't want to accidently volunteer up that space prematurely such that it gets vacuumed by other stuff ;-) [23:05] well, it's not like it's super-strictly audited, but sure [23:08] could somebody review netcfg and isc-dhcp, please? [23:11] slangasek: Yeah, not quite sure.. I wondered if 2.40 provided the binary or something.. either way, didn't seem to be an issue for us. [23:11] slangasek: it is on my todo to poke that. [23:13] netcfg looks sane... [23:13] slangasek: you'll also notice i included the manpages without patching, or putting them in debian/ .. I didn't want to introduce a patch system, and also wanted to keep it as similar to the debian package as possible [23:13] (new upstream version ships the manpages) [23:14] <-- keeping life simple for future merge/sync. [23:14] cjwatson: Does that "keep old nameservers" logic exist in netcfg for v4 as well? [23:15] cjwatson: (I notice you added it for v4 and v6 to isc-dhcp, but only v6 in netcfg..) [23:15] who uses v4 these days? :) [23:15] Everyone? [23:22] infinity: isc-dhcp's dhclient-script deals with that bit [23:23] we only need to deal with it for v6 in netcfg because we override the dhclient-script in the v6 case [23:23] Daviey: given that versioned conflicts are a major source of upgrade problems, I would prefer to see that turned into a Depends: instead before I accept it [23:23] cjwatson: Ah-ha. Then both look reasonable to me. [23:25] slangasek: if people are upgrading from prior to hardy to oneiric directly, they deserve pain. [23:26] infinity: thanks [23:26] Daviey: oh, I hadn't noticed that 2.40 was that old. ack, accepting then - that just goes in the bucket of "issues that should be flagged to the Debian maintainer" [23:27] slangasek: along with buring debian/rules [23:27] Thanks! [23:29] \o/ [23:29] er, though now that I look more closely I'm not sure if I should actually accept the binaries out of new before beta-2 [23:29] since dnsmasq-base is a recommends: of network-manager [23:29] slangasek: well, i wanted it on beta2 - due to the new upload of nova we are planning tommorow. [23:29] (which seems dubious to me, but there it is; the package impacts the desktop CDs) [23:30] well it's essentially a no-change rebuild for the desktop, right? [23:30] skaet: ^^ are we in a window where dnsmasq can be accepted for beta-2, which requires a rebuild of the desktop? server team is rather keen to have this new package in for beta-2 [23:31] Desktop still needs rebuilds anyway. [23:31] so if desktop don't respin before then, it's ok - if they do - it should be no-change. [23:31] infinity: ah. what's the trigger for those? [23:31] slangasek, opportunistic at this point. waiting for d-i update from cjwatson before the rebuilds start. [23:31] slangasek: Right now, I'd say the LCD is ubiquity building. [23:32] (And d-i for alternates) [23:32] So, y'know. Installers. No big whoop. [23:32] Who needs those? [23:32] :P [23:32] ah, ubiquity not fixed yet? ok [23:32] Colin's abusing it. [23:32] * slangasek nods [23:32] Because Irish people don't sleep. [23:33] Or maybe that's Cambridge grads. [23:33] I had another stab at libproxy and it works now. Needs some fixes still (what to do with the external modules? separate binary packages?); further eyes appreciated git://anonscm.debian.org/users/laney/libproxy.git [23:34] So, I suspect we can replace all our triggers in the Pad with just two "ubiquity and debian-installer", and if people can get minor fixes in before those big two land, fine. :P [23:35] What I won't say out loud is that, while I'm waiting on those to filter through, I'm toying with changing the default FS on the ARM images. [23:35] *cough* [23:36] Cambridge certainly did bad things to my sleep cycle [23:36] I've got the ubiquity tests passing; what I need to check now is whether my changes to upower integration still actually work [23:39] * skaet notes remark about default FS... sighs heavily. [23:40] infinity: Changing it to? And on the arm server deliverables aswell? [23:41] Daviey: ext4, and across the board. It's a more tested codepath these days. Assuming the installers DTRT, which we're smoketesting right now. [23:41] If they don't, I can roll it back in a matter of seconds. No archive turnaround. [23:43] infinity: I'm sure it won't make IO speed on the pandaboards any worse.. what could? [23:43] *smirk* [23:44] I believe the unsupported arm cloud images deliverable is already ext4 btw. [23:45] cjwatson: I assume we have no urge to change the wubi target to ext4? [23:46] bug 854189 probably needs release noting.. macbooks are not playing well with the default of using EFI, requires manual steps to use legacy BIOS mode. [23:46]