[04:18] good morning [04:19] gema, slangasek: no, that bug (Chinese images not being Chinese) is quite some months old already [04:19] so I wonder why the testers didn't agree [04:19] we introduced it in https://launchpad.net/ubuntu/+source/language-selector/0.66 [04:20] cjwatson: no worries; it doesn't matter if we release them a day after, I guess [04:20] I tested a local build yesterday, downloading http://china-images.ubuntu.com/precise/daily-live/20120426/ now [04:41] stgraber, cjwatson: http://china-images.ubuntu.com/precise/daily-live/20120426/ is now actually chinese; stgraber, can you please add them to the tracker? I disabled the previous ones, but I still can't add new ones === bkerensa is now known as Tester === Tester is now known as TesterBlah123 === TesterBlah123 is now known as bkerensa === RAOF is now known as RAOF_ === RAOF_ is now known as RAOF [06:15] pitti, slangasek, stgraber, cjwatson - http://localized-iso.qa.ubuntu.com/qatracker/milestones/217/builds has been created and chinese images added to it. [06:17] Since the images were based on a final version of 12.04, rather than the pre-release ones, it seemed a new milestone was appropriate. [06:20] stgraber, we probably need to figure out some conventions for the transition between pre-release and after the Ubuntu release comes out, and get it documented. [06:20] I'll set up a blueprint on the subject for later today. [06:30] skaet: splendid, thanks [06:31] good morning pitti. [06:31] :) [06:34] hey skaet, how do you feel today? [06:36] pitti, feeling good. solid sleep helps wonderfully, as does knowing the release is out the door. ;) [06:36] yay, didrocks-isms! [06:36] da man who never sleeps [06:37] :) [06:37] more goodness coming in, SRU system ramps up for 12.04. :) [06:38] re: didrocks, +1! :D [06:38] \o/ [06:38] more goodness in the pipe :) [06:40] :) [06:45] does anyone know what shold be the Multi-Arch tag for a -dbg package? [06:45] as bamf-dbg is Multi-Arch: same and of course, I'm getting: E: bamf-dbg: arch-dependent-file-not-in-arch-specific-directory usr/lib/debug/usr/lib/bamf/bamfdaemon [06:45] it "should" be whatever it is [06:46] if the -dbg package ships files in a non-arch-qualified directory, it shouldn't be marked M-A: same [06:47] slangasek: ok, as bzr annotate points you as doing this addition I didn't dare removing it without having a confirmation from someone with some clue on this :) thanks! [06:48] ;) I overlooked bamfdaemon when I added it [06:48] slangasek: no worry, will use this upload to fix it, thanks for confirming :) [07:10] * skaet --> breakfast then shifting to the office. biab === smb` is now known as smb [07:35] * apw notes that the archive is suitibly slow today [07:40] isn't it always like that right after release? [07:40] it is closed, after all [07:41] Riddell, I reproduced bug 989249, attached the logs and updated the tracker. [07:41] oh, you mean access [07:41] Launchpad bug 989249 in ubiquity "kubuntu amd64+mac crash in manual partitioner" [High,Confirmed] https://launchpad.net/bugs/989249 [09:16] thanks jibel [09:30] doko_: so can we copy a bunch more stuff from your PPA now? [09:31] cjwatson, just copied gcc-4.6 and gdc-4.6 [09:31] I'll upload gcj-4.6 and gnat-4.6 directly. did mess up the gcc-defaults in the ppa [09:31] OK [09:38] doko_: oh, I guess you're using copy-package.py, so it didn't show up in the queue? [09:41] cjwatson, yes, I did. sorry, should I use something else? [09:41] ideally, something that's based on Archive.copyPackage in the API [09:42] I don't think we actually have a proper general tool for it right now; you can either write one :-) or use lp-shell [09:42] note that copy-proposed-kernel in lp:u-a-t shoudl be fairly close to this [09:42] indeed [09:43] in fact, it doesn't really hardcode any package name, just the "canonical-kernel-team" PPA name [09:43] it's on the remove-archive-admin-shell-access list to write a general API tool to replace everything we do with copy-package.py [09:43] ok, noted [09:43] it'd be fairly simple to rename it to copy-ppa-ubuntu and add some options for PPA name and destination pocket [09:43] so maybe add an option to that script to select the PPA and rename it to copy-from-ppa [09:43] yeah [09:44] I'd still keep copy-proposed-kernel, but that can then become a tiny shell shim around that === doko_ is now known as doko [09:47] cjwatson, pitti: would you be ok with demoting gcc-4.5 from the start? [09:47] even if it's still used by u-boot and mysql-5.1? [09:47] why? [09:48] we still carry mysql 5.1? I thought that was obsoleted by 5.5 [09:48] mysql-5.5 actually [09:48] oh, 5.5 [09:48] so, I'm generally for reducing duplication, just not sure how hard it is to fix u-boot-linaro [09:48] I'd rather those packages were fixed first [09:48] I guess I don't see the rush to demote it [10:13] doko: Any reason I shouldn't accept boost1.49 now? AFAICS things that use the default compiler should be fine now [10:14] cjwatson, sounds fine [11:06] doko: I'll push Linaro harder to get u-boot working with 4.6 (or 4.7, ideally), MySQL will take some testing. We tried to switch it once and its world exploded. Maybe 4.7 will treat it better, or maybe MySQL needs some love. [11:06] * Laney switches ben to precise [11:06] er, the other thing [11:06] lots of maybes in that sentence [11:07] we should clean that out too [11:08] do we still need 4.4 for anything (texlive-bin and libusb++-dev seem to be the only things that require it in main) [11:08] ogra_: I only count two. :P [11:08] enough though :) [11:09] well, and boost1.46, but that's going away :) [11:11] micahg: 4.4 demotion seems like a much more solvable issue, though examining WHY things still want it is always a sane first step. [11:11] after it's demoted I think I'll just kill it (only a handful of universe rdeps) [11:12] ok, 2 handfuls :) [11:12] That's, I suspect, the plan. [11:17] infinity, it's mysql 5.1 only, which maybe should be dropped [11:17] -- precise/main build deps on g++-4.5: [11:18] mysql-5.5 [11:18] doko: I can't see that that changed in the last day... [11:27] hmm [11:30] doko: here's what I think you're looking for: https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.20-0ubuntu2 [11:32] SpamapS: Can you waste a bit of time on testing MySQL with g++-4.7 and see if maybe we can finally ditch 4.5 (or even blow some time on finding and fixing the issues?) [11:32] There. Go, server team, go. === yofel_ is now known as yofel === greyback is now known as greybacklunch === greybacklunch is now known as greyback|lunch [12:00] cjwatson, infinity, pitti, micahg: I think we are ready for *ish uploads. toolchain is in place, but the -multilib packages are still broken on arm. I don't expect these to be available before tomorrow. [12:01] What's broken with multilib? [12:01] (Not that it matters greatly, except for a tiny subset of packages) [12:02] config error, gcc-4.7 didn't build the -multilib packages [12:02] so you'll just see unfulfilled b-d's, and can give back these later [12:03] doko: let's finish boost1.49 and boost-defaults first? [12:03] Please. [12:03] ? [12:03] per ScottK on -devel [12:03] I wonder if we should merge debhelper [12:03] ohh, I didn't mean to open now, but get uploads for dpkg, apt, etc ready [12:03] Oh, right. dpkg is Hard this time. [12:04] yes, and debhelper,. cdbs, ... [12:04] should be independent from boost [12:04] I'd be inclined to leave it for a bit rather than rush it. It'll need care to get multiarch config migration working properly. [12:04] And I don't think it's needed for opening. [12:05] Config migration should be fairly simple. "should be". :/ [12:05] Debian has started adding annoying deps on debhelper for various hardening features, so that would probably be good before the autosync [12:05] infinity: Be my guest. :-) [12:05] cjwatson: I don't mind doing the migration bit, I'm not sure I want to do the merge today. [12:05] I'll go and sort out debhelper now. [12:05] cjwatson: But I could do both next week. I agree that we don't need it to open. [12:06] We don't have merge-o-matic yet, unfortunately. [12:06] MoM and I aren't often on speaking terms anyway. [12:06] Right, I wouldn't recommend it for dpkg in any case. I meant in general. [12:06] apt 0.9.2 would be nice, not sure how large the delta there is. [12:07] * infinity has a look. [12:12] infinity, are you tracking the upgrade of the arm buildds? [12:12] when should that happen? [12:12] doko: Which upgrade? [12:12] to precise [12:12] doko: To precise, you mean? We want *all* buildds to do that, not just arm. [12:12] I mean, there are more than 50% offline [12:12] doko: Timing on that, however, is out of my hands. [12:13] Hum [12:13] is this an webops item? [12:13] It's an RT ticket, not sure who owns it currently. [12:13] The debhelper merge has a conflict in dh_installinit which is tied in with Steve's efforts to merge proper Upstart handling into Debian [12:13] But I'll make sure it comes up in calls and we get it done. [12:14] And the new dh_installinit has the effect of installing both Upstart jobs and init scripts, rather than our previous scheme [12:14] slangasek: ^- I'm not confident in my ability to do the debhelper merge accurately; do you think you could deal with it? [12:14] micahg: Build-deps aren't a problem, TBH, as they'll just dep-wait. [12:14] So I think we could open without debhelper, since it isn't trivial. [12:15] Though there are some flag handling features that might not have been build-depped on. [12:17] pitti, cdbs merge? [12:19] + // do not show ignoration warnings for directories [12:19] * infinity giggles at "ignoration". [12:20] automake? [12:20] no new version [12:21] Yeah there is, just not in wheezy [12:21] ahh [12:22] Shall I do that? I have the last Ubuntu changes. [12:22] sure [12:22] away -all [12:22] err [12:23] doko: can do === wgrant_ is now known as wgrant [12:26] libreoffice ended up on sulfur, this should be interesting :) [12:28] why, I thought that one was faster than the older two? [12:30] yes, and with more cores, it should be interesting to see how fast it tears through it [12:32] ah, good, automake1.11 is a sync [12:34] is there any point in moving to lsb 4.1 before opening? [12:35] micahg, I don't think so [12:35] Shouldn't be needed pre-opening [12:36] I didn't track clang and fpc [12:36] infinity, can you upload clang defaulting to armv5t on armel? [12:37] cjwatson, doko: is someone already handling the merging of debhelper? [12:39] So I think we could open without debhelper, since it isn't trivial. [12:40] pitti, so I assume no [12:42] pitti: 13:13 The debhelper merge has a conflict in dh_installinit which is tied in with Steve's efforts to merge proper Upstart handling into Debian [12:42] 13:14 And the new dh_installinit has the effect of installing both Upstart jobs and init scripts, rather than our previous scheme [12:43] 13:14 slangasek: ^- I'm not confident in my ability to do the debhelper merge accurately; do you think you could deal with it? [12:43] cjwatson: thanks [12:43] pitti: If you think you can deal with this accurately - that is, if you know authoritatively which way we should be handling init scripts - be my guest, but I don't [12:44] I have 45 minutes left before I leave for the train station, so I'd rather not attempt that today then [12:44] I'm on the fence about opening without debhelper. It might be better to wait until we hear from slangasek (who's on holiday) rather than rushing. === greyback|lunch is now known as greyback [12:46] there are quite a number of changed compiler flag handling, these do look significant [12:46] Yeah [12:46] my gut feeling is that we probably want to keep our version of dh_installinit instead of Debian's "install both", but I agree, let's wait for Steve for this [12:47] I don't think we ever want to support sysvinit in Ubuntu again [12:47] Sure; still, the merge wasn't obvious to me anyway [12:49] doko: Do the gcc-4.6 entries on http://people.canonical.com/~ubuntu-archive/nbs.html indicate a problem, or are those waiting for builds to finish? [12:50] cjwatson, problems, working on that [12:50] cjwatson, infinity, pitti, micahg: I think we are ready for *ish uploads. toolchain is in place, but the -multilib packages are still broken on arm. I don't expect these to be available before tomorrow. [12:51] Oh, that [12:51] NP [12:58] doko: Sure. Does llvm need a sane default target too? [13:00] doko: Actually, we should probably snag llvm-3.1 and clang_3.1 from experimental... [13:01] sure, why not [13:01] * infinity nods. [13:01] I'll look at merging and/or syncing those, then. [13:01] After I smoke. ;) [13:01] I'm currently not using llvm for shark/openjdk [13:17] "The Unapproved queue is empty. " [13:17] take that, didrocks! [13:17] *hug* [13:17] * didrocks hugs pitti [13:18] pitti: you were fast! ;) [13:18] pitti: if only my laptop didn't burn, I would be doing zg now and you would be in a worse shape! :) [13:18] I've become pretty acquainted with /^--- and skipping over autoconf noise :) [13:19] héhé ;) [13:21] skaet, cjwatson: FYI, I'll be on holiday on Monday, and there is a national holiday on Tuesday [13:21] doko: Oh, and I wouldn't worry too much about fpc, I probably need to do an fpc transition first thing next week anyway, so it'll sort itself. [13:21] so be back on Wed [13:22] Righto [13:22] Have fun :) [13:22] pitti, cjwatson, I'll be flying on monday, then taking a couple of days off. Will send out email when I know which ones. [13:22] enjoy your long weekend pitti. [13:31] doko: Oh, ocaml might need love too... [13:31] doko: cdbs uploaded [13:32] syncing perl - our only outstanding changes are Conflicts on pre-12.04 versions [13:32] train time, see you next Wed! You can call my mobile for emergencies [13:34] doko: Or maybe ocaml will just magically fix itself on rebuild. Handy. [13:36] bah, quantal only just opened and we already have the first 3 ftbfs [13:36] (on arm that is) [13:37] ogra_: ? [13:37] ogra_: If it's toolchain packages failing due to multilib, ignore it. [13:38] And indeed, it is. [13:38] yeah, i wasnt seriously complianing a day after opening :) [13:41] Is ocaml pre-opening? [13:41] Yes. [13:41] Bam. [13:53] cjwatson: I think it's probably safe to assume that anything that looks kinda like a compiler is pre-opening. [13:54] Heh [13:54] Just like to check [14:31] doko: I assume you've noticed, but your gcc-4.7 in the PPA seems sad. [14:47] https://bugs.launchpad.net/ubuntu/+source/apport/+bug/989779 - skaet [14:47] Launchpad bug 989779 in apport ""Problem already known" alert and Launchpad page still open post-release" [Undecided,New] [14:49] pitti, can you look into ^ [14:49] ? [14:49] skaet, he's not online [14:49] skaet, he is gone until wed. [14:50] skaet, and off until wednesday [14:57] seb128, ogra_ thanks. didn't realize he'd eod. [14:57] ev or cjwatson, can either of you handle? [15:00] I don't know apport or the error tracker design well enough to be comfortable with doing that in a rush [15:01] cjwatson, ack. ev just said he'll tackle. Thanks. [15:01] cool [15:04] cjwatson: Going to be uploading/syncing some llvm* stuff, not to be accepted until the current publisher run is done. [15:04] OK [15:04] Oh, boost-defaults can go now, can't it [15:05] infinity, yes, known [15:24] infinity: llvm* ready to go now? The publisher's in cron.germinate, so should be enough for buildds. [15:25] cjwatson: Yep. [15:26] * cjwatson accepts [15:26] * infinity grabs the one in new. [15:26] Go for it. [15:27] Oh, I think I'll let distro-info-data in too. [15:27] cjwatson: The kernel sync from -updates would be fine too. [15:27] Good point. [15:29] In fact all the syncs from -updates are fine. [15:30] skaet: any objection to marking both pre-release and final milestones as released on the tracker? [15:31] stgraber, no objection. Thanks! :) [15:32] skaet: done. I'll keep all the precise ones as released until we get the first quantal daily. I'll then archive them all [15:32] infinity: I'll definitely give it a shot. [15:33] stgraber, sounds good. Thanks. I'll add it as a task to the checklist for day+1 tasks. [15:35] fix for bug 989799 uploaded to precise-proposed [15:35] Launchpad bug 989799 in nova "create instance min/max count defaulting logic is reversed in EC2 and native OS APIs " [Undecided,New] https://launchpad.net/bugs/989799 [15:36] err bug 989779 [15:36] Launchpad bug 989779 in apport ""Problem already known" alert and Launchpad page still open post-release" [Undecided,New] https://launchpad.net/bugs/989779 [15:36] thanks ev [15:37] gema, jibel - are either of you online now? we need to figure out a plan for quickly testing this apport fix. [15:38] please reject [15:38] need to rework that [15:38] * skaet doing [15:38] skaet, pong [15:43] hiya jibel [15:43] when ev gets the apport package uploaded, would you be able to do some checking that its doing the right thing now, and not causing side effects? [15:43] (next version ;)) [15:44] skaet, sure. do you have an ETA ? my plan was not to stay late tonight [15:45] jibel, ev's working on the revised version now. [15:45] hopefully within the hour, but if not, could you hand off to hggdh? [15:45] we'd like to get this fix out there, ASAP. [15:46] skaet, ack. within the hour is fine. [15:46] I'll ask hggdh if it's unverified when I'll leave. [15:46] * hggdh is aware, and waits [15:47] * jibel leaves now then ;) [15:47] * hggdh runs [15:54] Thanks hggdh, jibel :) [15:57] ^ skaet please accept that one. The additional changes weren't actually needed in the end, but make the check it's doing more consistent (not assuming certain things are set in /etc/apport/crashdb.conf). [15:58] ev, will do, waiting for the diff. [15:58] doko: The clang merge might not happen until I get home, it's a bit entertaining. clang's rdep list is tiny, I'll just rebuild it later when I'm happy with my local builds. (want to fix some armhf stuff at the same time anyway) [15:58] cjwatson: ^ [15:58] hggdh, version you're going to need to wait to be built in -proposed, and test with is apport 2.0.1-0ubuntu7 [15:59] skaet: ack [15:59] infinity: *nod* [15:59] cjwatson: And I'll be doing an fpc porting/transition bit earlier next week too so, for me, I'm done with toolchain bits until Monday. [16:00] Anything else you care about pre-opening? [16:00] cjwatson: When do you plan to mass-sync universe? I'd like it to happen after I land fpc, so I don't have to transition twice. [16:00] The only thing on my list right now is (?)debhelper. [16:00] infinity: Right after opening. [16:00] ev, you made apport native in that upload [16:00] cjwatson: Oh well. I'll transition fpc twice if I have to, not world-ending. ;) [16:00] ev, i.e not diff.gz, but a plan tarball [16:01] cjwatson: Might have to anyway, if the build-deps aren't all sane, since we may end up syncing in a weird order that breaks it all, so meh. I'll wait for the world to settle and then fix fpc properly. [16:01] infinity: Might take us until early next week before we open anyway [16:02] fpc doesn't have many rdeps, does it? [16:02] (Ideally, I'd get a new fpc in right now, but that requires a bootstrap...) [16:02] Actually, wait. No, I can fudge it. [16:02] I can sync Debian's fpc now, and then do the armhf bootstrap later. [16:02] skaet, ev: not sure if apport should be reuploaded with a diff.gz? [16:02] I'll do that. [16:02] In fact, it seems to be just lazarus? [16:03] fp-compiler [16:03] Should be a lot more than lazarus. [16:04] seb128: eep, sorry about that [16:04] Ah, yes [16:04] Anyhow, synced fpc as a pre-open thing. [16:04] ev: Rejected that one then [16:05] accepted fpc [16:05] There. That should be happy for everything but clang, and I'll deal with clang on Monday. [16:05] Their beautiful misunderstanding of multiarch makes me want to be a bit more careful with it. [16:06] (testing for /lib/triplet/ as a way to determine the host arch is *brilliant*) [16:06] * cjwatson blinks [16:06] I shit you not. [16:09] cjwatson: Also, I don't want to alarm you, but no one's done the inaugural vim merge yet. Are we slipping in our old age? [16:09] cjwatson: cheers [16:11] Oh, not even a merge in this case, just a bump to add quantal. [16:11] * infinity does that. [16:13] infinity: heh, go for it ... [16:22] ev: Looks good to me. [16:22] yay [16:30] And, of course, the no-change rebuild of llvm-2.8 fails. [16:30] Tempted to just remove it. [16:30] * infinity goes rdep hunting. [16:30] Hah, and 2.9 also fails, and we use that one. [16:31] Thanks, gcc-4.7. [16:31] Might be time to just switch to 3.0 or even 3.1 and drop all the old ones, but I don't have the time tonight to look into that pain. [16:31] (Have to be out of here in ~30m) [16:38] cjwatson: on vacation, but not staying away from the archive ;) I'm happy to do that merge today [16:38] cjwatson: btw, do we have dpkg flags behavior restored to match Debian's now? [16:41] cjwatson: Right. New plan. llvm-2.x sucks, I'm going to move llvm-py and llvm-defaults to 3.0 and bounce out 2.x completely. [16:42] cjwatson: But I have about 15 minutes left to do that, so... That's a "when I get home" thing, to make sure I test it a bit before I do it. [16:43] slangasek: No, I was thinking about that but have been too scared :-) [16:43] Scared, or scarred? [16:43] Yes. [16:43] ;) [16:43] That would be an easy change in advance of the merge, I suppose. Are we sure we'll have enough effort to restore hardening flags everywhere for 12.10? [16:43] :) [16:43] Anyhow, as above, don't worry too much about all things llvm/clang, I'll sort it all when I land. [16:43] Noted [16:44] we did say we were going to revert that after 12.04 [16:44] We did [16:44] how much effort do we expect it to be to restore the flags? [16:44] I can imagine about half an hour per package + whatever it takes to set up something to scan for the problem [16:45] Which I suppose can be a lintian check on lintian.ubuntuwire.org [16:45] so we don't really have a package count at this point [16:45] Not AFAIK [16:45] ok [16:45] well, IIRC from the first time around it was a fairly small percentage of packages [16:45] and should be smaller now due to Debian uptake [16:45] In fact, to find out how many we *would* have to change, we'd have to test-rebuild everything and then run hardening-check against them [16:47] Um, isn't it everything that doesn't use dpkg-buildflags? [16:47] I thought it was only things that explicitly overrode flags in debian/rules without checking dpkg-buildflags? [16:48] maybe that was a subset of the problem [16:48] Those were the ones that broke due to the earlier iteration of our workaround, I think [16:48] cjwatson: boost1.49 binaries got accepted into Universe. They need to be in Main or boost-defaults won't build. [16:49] ScottK: boost1.48 was in universe, though [16:49] cjwatson: Yes, but this is replacing 1.46 [16:49] Oh, I missed that [16:50] Promoted, thanks - I expect some of the binaries will want to fall back to universe later, but this will do for now [16:50] It's a bit of an odd situation where we got 1.48 and an updated defaults via autosync after we decided to stick with 1.46 for oneiric. [16:51] cjwatson: hmm, there are some unpleasant trade-offs with this apport change [16:51] That should do it. We'll want to give main users a chance to convert before dropping stuff back. [16:51] (skaet just tagged me to follow through on it) [16:51] Oh? It looked roughly in line with previous code [16:52] cjwatson: it may indeed have been... but does this affect bug patterns? [16:52] That I'm not sure [16:52] Has ev already left? I don't know this code as well as I should. [16:52] because we explicitly put in some bug patterns pointing to pages with documentation to help users fix their upgrade issues [16:52] (And I have to finish up soon) [16:53] It's in -proposed, I guess v-failed will do for now if it's breaking stuff ... [16:53] in the short term I'm happy to err in the direction of less interaction, but would like to follow through on the bug patterns question [16:57] cjwatson, pitti: btw, as far as the debhelper merge is concerned, over the longer term I do want to get us back in sync with debian on dh_installinit so we *would* have the init scripts installed and lying dormant; but a prereq for this would be LSB header fixes so we could use insserv as intended [16:57] so that's pretty low priority [16:57] * cjwatson looks for a package he can test against new dpkg [16:57] (the only real benefit is further reducing delta with Debian, in terms of both packaging and behavior) [16:57] Or I mean the proposed dpkg change [16:58] I think I need something that (a) doesn't set CFLAGS/LDFLAGS itself and (b) doesn't use dpkg-buildflags [16:59] And (c) doesn't use hardening-includes or similar [16:59] Perhaps man-db 2.5.7-4 is close enough [17:03] Annoyingly, lintian.uw.org isn't running a new enough version of lintian for the hardening checks yet [17:04] Ah, because it isn't released yet [17:05] Oh and (d) actually still builds, bah [17:13] aren't the hardening flags enabled in gcc anyway? [17:13] ev, I verified apport 2.0.1-0ubuntu7, it fixes 989779. I also created 2 crashes that don't exist in the crashdb (a syntax error and an import error in update-manager) Is there a way to verify that the reports have been uploaded ? [17:14] jibel, ev's left the building right now. slangasek, thoughts? [17:15] sorry, I don't know [17:15] debfx: some, not all; I don't remember the precise details of what blew up last time we tried to stop force-setting dpkg-buildflags [17:20] skaet, I'll update the report with my verification but will set to verified once there is a confirmation that reports are still uploaded. [17:21] skaet: what is this change about? [17:21] why is it going in so late? [17:21] or is this for 12.04.1? [17:22] slangasek: I thought you were off! [17:22] in fact, I thought I was off too :/ [17:22] jibel: if you have a .upload stamp file in /var/crash, that should be sufficient verification [17:23] gema: "off" is a funny concept ;) [17:23] it just means I'm not answerable to my manager for anything I do today ;) [17:24] uhmmmm... I am watching you, slangasek :P [17:24] slangasek, it's there. verification-done :) thanks [17:26] jibel: great, thanks - yeah, that's sufficient because whoopsie does the actual uploading and is an entirely separate package [17:36] hggdh: jibel already tested apport, so I've copied it to -updates now [17:36] hggdh: so you're off the hook :) [17:36] slangasek: roj, thank you [17:37] thanks slangasek [17:38] * skaet --> out of millbank === bulldog98_ is now known as bulldog98 [17:53] torrent for Kubuntu i386 desktop gives an error: [17:53] rejected by tracker - Requested download is not authorized for [17:53] use with this tracker. [17:54] file downloads but doesn't seed [17:54] * ScottK pointed ^^^ since he recalled issues with the Ubuntu torrents yesterday. [17:54] where would the best place to report that? All other torrents seem fine [17:55] here - I'll have a look shortly [17:55] Ok thanks! [17:58] claydoh: should be fixed soon, sorry about that [17:59] I need to scan for these properly when I'm not supervising kids [18:00] cjwatson: thanks! [18:36] Would someone please de-New boost-defaults? [19:01] ScottK: done [19:02] three nested screen levels wasn't at all confusing there. took me two goes to detach the right one afterwards. [19:03] Thanks. [19:28] ^a aa ^a ^a a [19:30] cjwatson: wrt dpkg-buildflags: http://outflux.net/ubuntu/hardening/ [19:33] maybe I should learn how to use canonistack so I can do comparison test rebuilds in it [19:45] cjwatson: I'm having difficulty actually working out why we needed dpkg-buildflags to do the exports at all in Ubuntu... is there a specific subset of these flags that aren't being set by default in gcc? [19:45] I found the rationale for the debhelper compat hack, but not for the dpkg-buildflags part itself [20:05] slangasek: since the packaging might modify the output? [20:06]