[04:18] <pitti> good morning
[04:19] <pitti> gema, slangasek: no, that bug (Chinese images not being Chinese) is quite some months old already
[04:19] <slangasek> so I wonder why the testers didn't agree
[04:19] <pitti> we introduced it in https://launchpad.net/ubuntu/+source/language-selector/0.66
[04:20] <pitti> cjwatson: no worries; it doesn't matter if we release them a day after, I guess
[04:20] <pitti> I tested a local build yesterday, downloading http://china-images.ubuntu.com/precise/daily-live/20120426/ now
[04:41] <pitti> 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
[06:15] <skaet> 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] <skaet> 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] <skaet> 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] <skaet> I'll set up a blueprint on the subject for later today.
[06:30] <pitti> skaet: splendid, thanks
[06:31] <skaet> good morning pitti.
[06:31] <skaet> :)
[06:34] <pitti> hey skaet, how do you feel today?
[06:36] <skaet> pitti,  feeling good.   solid sleep helps wonderfully, as does knowing the release is out the door.  ;)
[06:36] <pitti> yay, didrocks-isms!
[06:36] <pitti> da man who never sleeps
[06:37] <skaet> :)
[06:37] <skaet> more goodness coming in,  SRU system ramps up for 12.04.  :)
[06:38] <skaet> re: didrocks,   +1!  :D
[06:38] <didrocks> \o/
[06:38] <didrocks> more goodness in the pipe :)
[06:40] <skaet> :)
[06:45] <didrocks> does anyone know what shold be the Multi-Arch tag for a -dbg package?
[06:45] <didrocks> 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] <slangasek> it "should" be whatever it is
[06:46] <slangasek> if the -dbg package ships files in a non-arch-qualified directory, it shouldn't be marked M-A: same
[06:47] <didrocks> 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] <slangasek> ;)  I overlooked bamfdaemon when I added it
[06:48] <didrocks> slangasek: no worry, will use this upload to fix it, thanks for confirming :)
[07:10]  * skaet --> breakfast then shifting to the office.   biab
[07:35]  * apw notes that the archive is suitibly slow today
[07:40] <micahg> isn't it always like that right after release?
[07:40] <tumbleweed> it is closed, after all
[07:41] <jibel> Riddell, I reproduced bug 989249, attached the logs and updated the tracker.
[07:41] <tumbleweed> oh, you mean access
[07:41] <ubot2> Launchpad bug 989249 in ubiquity "kubuntu amd64+mac crash in manual partitioner" [High,Confirmed] https://launchpad.net/bugs/989249
[09:16] <Riddell> thanks jibel
[09:30] <cjwatson> doko_: so can we copy a bunch more stuff from your PPA now?
[09:31] <doko_> cjwatson, just copied gcc-4.6 and gdc-4.6
[09:31] <doko_> I'll upload gcj-4.6 and gnat-4.6 directly. did mess up the gcc-defaults in the ppa
[09:31] <cjwatson> OK
[09:38] <cjwatson> doko_: oh, I guess you're using copy-package.py, so it didn't show up in the queue?
[09:41] <doko_> cjwatson, yes, I did. sorry, should I use something else?
[09:41] <cjwatson> ideally, something that's based on Archive.copyPackage in the API
[09:42] <cjwatson> 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] <pitti> note that copy-proposed-kernel in lp:u-a-t shoudl be fairly close to this
[09:42] <cjwatson> indeed
[09:43] <pitti> in fact, it doesn't really hardcode any package name, just the "canonical-kernel-team" PPA name
[09:43] <cjwatson> 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] <doko_> ok, noted
[09:43] <pitti> it'd be fairly simple to rename it to copy-ppa-ubuntu and add some options for PPA name and destination pocket
[09:43] <cjwatson> so maybe add an option to that script to select the PPA and rename it to copy-from-ppa
[09:43] <cjwatson> yeah
[09:44] <pitti> I'd still keep copy-proposed-kernel, but that can then become a tiny shell shim around that
[09:47] <doko> cjwatson, pitti: would you be ok with demoting gcc-4.5 from the start?
[09:47] <doko> even if it's still used by u-boot and mysql-5.1?
[09:47] <cjwatson> why?
[09:48] <pitti> we still carry mysql 5.1? I thought that was obsoleted by 5.5
[09:48] <cjwatson> mysql-5.5 actually
[09:48] <pitti> oh, 5.5
[09:48] <pitti> so, I'm generally for reducing duplication, just not sure how hard it is to fix u-boot-linaro
[09:48] <cjwatson> I'd rather those packages were fixed first
[09:48] <cjwatson> I guess I don't see the rush to demote it
[10:13] <cjwatson> doko: Any reason I shouldn't accept boost1.49 now?  AFAICS things that use the default compiler should be fine now
[10:14] <doko> cjwatson, sounds fine
[11:06] <infinity> 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] <Laney> er, the other thing
[11:06] <ogra_> lots of maybes in that sentence
[11:07] <Laney> we should clean that out too
[11:08] <micahg> 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] <infinity> ogra_: I only count two. :P
[11:08] <ogra_> enough though :)
[11:09] <micahg> well, and boost1.46, but that's going away :)
[11:11] <infinity> 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] <micahg> after it's demoted I think I'll just kill it (only a handful of universe rdeps)
[11:12] <micahg> ok, 2 handfuls :)
[11:12] <infinity> That's, I suspect, the plan.
[11:17] <doko> infinity, it's mysql 5.1 only, which maybe should be dropped
[11:17] <infinity> -- precise/main build deps on g++-4.5:
[11:18] <infinity> mysql-5.5
[11:18] <infinity> doko: I can't see that that changed in the last day...
[11:27] <doko> hmm
[11:30] <micahg> doko: here's what I think you're looking for: https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.20-0ubuntu2
[11:32] <infinity> 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] <infinity> There.  Go, server team, go.
[12:00] <doko> 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] <infinity> What's broken with multilib?
[12:01] <infinity> (Not that it matters greatly, except for a tiny subset of packages)
[12:02] <doko> config error, gcc-4.7 didn't build the -multilib packages
[12:02] <doko> so you'll just see unfulfilled b-d's, and can give back these later
[12:03] <cjwatson> doko: let's finish boost1.49 and boost-defaults first?
[12:03] <infinity> Please.
[12:03] <doko> ?
[12:03] <cjwatson> per ScottK on -devel
[12:03] <cjwatson> I wonder if we should merge debhelper
[12:03] <doko> ohh, I didn't mean to open now, but get uploads for dpkg, apt, etc ready
[12:03] <cjwatson> Oh, right.  dpkg is Hard this time.
[12:04] <doko> yes, and debhelper,. cdbs, ...
[12:04] <doko> should be independent from boost
[12:04] <cjwatson> 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] <cjwatson> And I don't think it's needed for opening.
[12:05] <infinity> Config migration should be fairly simple.  "should be". :/
[12:05] <micahg> Debian has started adding annoying deps on debhelper for various hardening features, so that would probably be good before the autosync
[12:05] <cjwatson> infinity: Be my guest. :-)
[12:05] <infinity> cjwatson: I don't mind doing the migration bit, I'm not sure I want to do the merge today.
[12:05] <cjwatson> I'll go and sort out debhelper now.
[12:05] <infinity> cjwatson: But I could do both next week.  I agree that we don't need it to open.
[12:06] <cjwatson> We don't have merge-o-matic yet, unfortunately.
[12:06] <infinity> MoM and I aren't often on speaking terms anyway.
[12:06] <cjwatson> Right, I wouldn't recommend it for dpkg in any case.  I meant in general.
[12:06] <infinity> apt 0.9.2 would be nice, not sure how large the delta there is.
[12:07]  * infinity has a look.
[12:12] <doko> infinity, are you tracking the upgrade of the arm buildds?
[12:12] <doko> when should that happen?
[12:12] <infinity> doko: Which upgrade?
[12:12] <doko> to precise
[12:12] <infinity> doko: To precise, you mean?  We want *all* buildds to do that, not just arm.
[12:12] <doko> I mean, there are more than 50% offline
[12:12] <infinity> doko: Timing on that, however, is out of my hands.
[12:13] <cjwatson> Hum
[12:13] <doko> is this an webops item?
[12:13] <infinity> It's an RT ticket, not sure who owns it currently.
[12:13] <cjwatson> 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] <infinity> But I'll make sure it comes up in calls and we get it done.
[12:14] <cjwatson> And the new dh_installinit has the effect of installing both Upstart jobs and init scripts, rather than our previous scheme
[12:14] <cjwatson> slangasek: ^- I'm not confident in my ability to do the debhelper merge accurately; do you think you could deal with it?
[12:14] <cjwatson> micahg: Build-deps aren't a problem, TBH, as they'll just dep-wait.
[12:14] <cjwatson> So I think we could open without debhelper, since it isn't trivial.
[12:15] <cjwatson> Though there are some flag handling features that might not have been build-depped on.
[12:17] <doko> pitti, cdbs merge?
[12:19] <infinity> +           // do not show ignoration warnings for directories
[12:19]  * infinity giggles at "ignoration".
[12:20] <micahg> automake?
[12:20] <doko> no new version
[12:21] <cjwatson> Yeah there is, just not in wheezy
[12:21] <doko> ahh
[12:22] <cjwatson> Shall I do that?  I have the last Ubuntu changes.
[12:22] <doko> sure
[12:22] <pitti> away -all
[12:22] <pitti> err
[12:23] <pitti> doko: can do
[12:26] <micahg> libreoffice ended up on sulfur, this should be interesting :)
[12:28] <pitti> why, I thought that one was faster than the older two?
[12:30] <micahg> yes, and with more cores, it should be interesting to see how fast it tears through it
[12:32] <cjwatson> ah, good, automake1.11 is a sync
[12:34] <micahg> is there any point in moving to lsb 4.1 before opening?
[12:35] <doko> micahg, I don't think so
[12:35] <cjwatson> Shouldn't be needed pre-opening
[12:36] <doko> I didn't track clang and fpc
[12:36] <doko> infinity, can you upload clang defaulting to armv5t on armel?
[12:37] <pitti> cjwatson, doko: is someone already handling the merging of debhelper?
 So I think we could open without debhelper, since it isn't trivial.
[12:40] <doko> pitti, so I assume no
[12:42] <cjwatson> pitti: 13:13 <cjwatson> 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] <cjwatson> 13:14 <cjwatson> And the new dh_installinit has the effect of installing both Upstart jobs and init scripts, rather than our previous scheme
[12:43] <cjwatson> 13:14 <cjwatson> slangasek: ^- I'm not confident in my ability to do the debhelper merge accurately; do you think you could deal with it?
[12:43] <pitti> cjwatson: thanks
[12:43] <cjwatson> 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] <pitti> I have 45 minutes left before I leave for the train station, so I'd rather not attempt that today then
[12:44] <cjwatson> 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.
[12:46] <pitti> there are quite a number of changed compiler flag handling, these do look significant
[12:46] <cjwatson> Yeah
[12:46] <pitti> 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] <pitti> I don't think we ever want to support sysvinit in Ubuntu again
[12:47] <cjwatson> Sure; still, the merge wasn't obvious to me anyway
[12:49] <cjwatson> 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] <doko> cjwatson, problems, working on that
 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] <cjwatson> Oh, that
[12:51] <cjwatson> NP
[12:58] <infinity> doko: Sure.  Does llvm need a sane default target too?
[13:00] <infinity> doko: Actually, we should probably snag llvm-3.1 and clang_3.1 from experimental...
[13:01] <doko> sure, why not
[13:01]  * infinity nods.
[13:01] <infinity> I'll look at merging and/or syncing those, then.
[13:01] <infinity> After I smoke. ;)
[13:01] <doko> I'm currently not using llvm for shark/openjdk
[13:17] <pitti> "The Unapproved queue is empty. "
[13:17] <pitti> take that, didrocks!
[13:17] <pitti> *hug*
[13:17]  * didrocks hugs pitti
[13:18] <didrocks> pitti: you were fast! ;)
[13:18] <didrocks> pitti: if only my laptop didn't burn, I would be doing zg now and you would be in a worse shape! :)
[13:18] <pitti> I've become pretty acquainted with /^--- and skipping over autoconf noise :)
[13:19] <didrocks> héhé ;)
[13:21] <pitti> skaet, cjwatson: FYI, I'll be on holiday on Monday, and there is a national holiday on Tuesday
[13:21] <infinity> 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] <pitti> so be back on Wed
[13:22] <cjwatson> Righto
[13:22] <cjwatson> Have fun :)
[13:22] <skaet> 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] <skaet> enjoy your long weekend pitti.
[13:31] <infinity> doko: Oh, ocaml might need love too...
[13:31] <pitti> doko: cdbs uploaded
[13:32] <cjwatson> syncing perl - our only outstanding changes are Conflicts on pre-12.04 versions
[13:32] <pitti> train time, see you next Wed! You can call my mobile for emergencies
[13:34] <infinity> doko: Or maybe ocaml will just magically fix itself on rebuild.  Handy.
[13:36] <ogra_> bah, quantal only just opened and we already have the first 3 ftbfs
[13:36] <ogra_> (on arm that is)
[13:37] <infinity> ogra_: ?
[13:37] <infinity> ogra_: If it's toolchain packages failing due to multilib, ignore it.
[13:38] <infinity> And indeed, it is.
[13:38] <ogra_> yeah, i wasnt seriously complianing a day after opening :)
[13:41] <cjwatson> Is ocaml pre-opening?
[13:41] <infinity> Yes.
[13:41] <cjwatson> Bam.
[13:53] <infinity> cjwatson: I think it's probably safe to assume that anything that looks kinda like a compiler is pre-opening.
[13:54] <cjwatson> Heh
[13:54] <cjwatson> Just like to check
[14:31] <infinity> doko: I assume you've noticed, but your gcc-4.7 in the PPA seems sad.
[14:47] <ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/989779 - skaet
[14:47] <ubot2> Launchpad bug 989779 in apport ""Problem already known" alert and Launchpad page still open post-release" [Undecided,New]
[14:49] <skaet> pitti,  can you look into ^
[14:49] <skaet> ?
[14:49] <seb128> skaet, he's not online
[14:49] <ogra_> skaet, he is gone until wed.
[14:50] <seb128> skaet, and off until wednesday
[14:57] <skaet> seb128, ogra_ thanks.  didn't realize he'd eod.
[14:57] <skaet> ev or cjwatson,  can either of you handle?
[15:00] <cjwatson> I don't know apport or the error tracker design well enough to be comfortable with doing that in a rush
[15:01] <skaet> cjwatson, ack.    ev just said he'll tackle.   Thanks.
[15:01] <cjwatson> cool
[15:04] <infinity> cjwatson: Going to be uploading/syncing some llvm* stuff, not to be accepted until the current publisher run is done.
[15:04] <cjwatson> OK
[15:04] <cjwatson> Oh, boost-defaults can go now, can't it
[15:05] <doko> infinity, yes, known
[15:24] <cjwatson> infinity: llvm* ready to go now?  The publisher's in cron.germinate, so should be enough for buildds.
[15:25] <infinity> cjwatson: Yep.
[15:26]  * cjwatson accepts
[15:26]  * infinity grabs the one in new.
[15:26] <cjwatson> Go for it.
[15:27] <cjwatson> Oh, I think I'll let distro-info-data in too.
[15:27] <infinity> cjwatson: The kernel sync from -updates would be fine too.
[15:27] <cjwatson> Good point.
[15:29] <cjwatson> In fact all the syncs from -updates are fine.
[15:30] <stgraber> skaet: any objection to marking both pre-release and final milestones as released on the tracker?
[15:31] <skaet> stgraber,  no objection.   Thanks!  :)
[15:32] <stgraber> 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] <SpamapS> infinity: I'll definitely give it a shot.
[15:33] <skaet> stgraber,  sounds good.   Thanks.   I'll add it as a task to the checklist for day+1 tasks.
[15:35] <ev> fix for bug 989799 uploaded to precise-proposed
[15:35] <ubot2> 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] <ev> err bug 989779
[15:36] <ubot2> 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] <skaet> thanks ev
[15:37] <skaet> gema, jibel - are either of you online now?    we need to figure out a plan for quickly testing this apport fix.
[15:38] <ev> please reject
[15:38] <ev> need to rework that
[15:38]  * skaet doing
[15:38] <jibel> skaet, pong
[15:43] <skaet> hiya jibel
[15:43] <skaet> 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] <skaet> (next version ;))
[15:44] <jibel> skaet, sure. do you have an ETA ? my plan was not to stay late tonight
[15:45] <skaet> jibel, ev's working on the revised version now.
[15:45] <skaet> hopefully within the hour,  but if not,  could you hand off to hggdh?
[15:45] <skaet> we'd like to get this fix out there, ASAP.
[15:46] <jibel> skaet, ack. within the hour is fine.
[15:46] <jibel> 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] <skaet> Thanks hggdh, jibel   :)
[15:57] <ev> ^ 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] <skaet> ev,  will do,  waiting for the diff.
[15:58] <infinity> 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] <infinity> cjwatson: ^
[15:58] <skaet> 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] <hggdh> skaet: ack
[15:59] <cjwatson> infinity: *nod*
[15:59] <infinity> 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] <cjwatson> Anything else you care about pre-opening?
[16:00] <infinity> 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] <cjwatson> The only thing on my list right now is (?)debhelper.
[16:00] <cjwatson> infinity: Right after opening.
[16:00] <seb128> ev, you made apport native in that upload
[16:00] <infinity> cjwatson: Oh well.  I'll transition fpc twice if I have to, not world-ending. ;)
[16:00] <seb128> ev, i.e not diff.gz, but a plan tarball
[16:01] <infinity> 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] <cjwatson> infinity: Might take us until early next week before we open anyway
[16:02] <cjwatson> fpc doesn't have many rdeps, does it?
[16:02] <infinity> (Ideally, I'd get a new fpc in right now, but that requires a bootstrap...)
[16:02] <infinity> Actually, wait.  No, I can fudge it.
[16:02] <infinity> I can sync Debian's fpc now, and then do the armhf bootstrap later.
[16:02] <seb128> skaet, ev: not sure if apport should be reuploaded with a diff.gz?
[16:02] <infinity> I'll do that.
[16:02] <cjwatson> In fact, it seems to be just lazarus?
[16:03] <infinity> fp-compiler
[16:03] <infinity> Should be a lot more than lazarus.
[16:04] <ev> seb128: eep, sorry about that
[16:04] <cjwatson> Ah, yes
[16:04] <infinity> Anyhow, synced fpc as a pre-open thing.
[16:04] <cjwatson> ev: Rejected that one then
[16:05] <cjwatson> accepted fpc
[16:05] <infinity> There.  That should be happy for everything but clang, and I'll deal with clang on Monday.
[16:05] <infinity> Their beautiful misunderstanding of multiarch makes me want to be a bit more careful with it.
[16:06] <infinity> (testing for /lib/triplet/ as a way to determine the host arch is *brilliant*)
[16:06]  * cjwatson blinks
[16:06] <infinity> I shit you not.
[16:09] <infinity> 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] <ev> cjwatson: cheers
[16:11] <infinity> Oh, not even a merge in this case, just a bump to add quantal.
[16:11]  * infinity does that.
[16:13] <cjwatson> infinity: heh, go for it ...
[16:22] <cjwatson> ev: Looks good to me.
[16:22] <ev> yay
[16:30] <infinity> And, of course, the no-change rebuild of llvm-2.8 fails.
[16:30] <infinity> Tempted to just remove it.
[16:30]  * infinity goes rdep hunting.
[16:30] <infinity> Hah, and 2.9 also fails, and we use that one.
[16:31] <infinity> Thanks, gcc-4.7.
[16:31] <infinity> 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] <infinity> (Have to be out of here in ~30m)
[16:38] <slangasek> cjwatson: on vacation, but not staying away from the archive ;) I'm happy to do that merge today
[16:38] <slangasek> cjwatson: btw, do we have dpkg flags behavior restored to match Debian's now?
[16:41] <infinity> 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] <infinity> 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] <cjwatson> slangasek: No, I was thinking about that but have been too scared :-)
[16:43] <infinity> Scared, or scarred?
[16:43] <cjwatson> Yes.
[16:43] <infinity> ;)
[16:43] <cjwatson> 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] <slangasek> :)
[16:43] <infinity> Anyhow, as above, don't worry too much about all things llvm/clang, I'll sort it all when I land.
[16:43] <cjwatson> Noted
[16:44] <slangasek> we did say we were going to revert that after 12.04
[16:44] <cjwatson> We did
[16:44] <slangasek> how much effort do we expect it to be to restore the flags?
[16:44] <cjwatson> I can imagine about half an hour per package + whatever it takes to set up something to scan for the problem
[16:45] <cjwatson> Which I suppose can be a lintian check on lintian.ubuntuwire.org
[16:45] <slangasek> so we don't really have a package count at this point
[16:45] <cjwatson> Not AFAIK
[16:45] <slangasek> ok
[16:45] <slangasek> well, IIRC from the first time around it was a fairly small percentage of packages
[16:45] <slangasek> and should be smaller now due to Debian uptake
[16:45] <cjwatson> 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] <cjwatson> Um, isn't it everything that doesn't use dpkg-buildflags?
[16:47] <slangasek> I thought it was only things that explicitly overrode flags in debian/rules without checking dpkg-buildflags?
[16:48] <slangasek> maybe that was a subset of the problem
[16:48] <cjwatson> Those were the ones that broke due to the earlier iteration of our workaround, I think
[16:48] <ScottK> cjwatson: boost1.49 binaries got accepted into Universe.  They need to be in Main or boost-defaults won't build.
[16:49] <cjwatson> ScottK: boost1.48 was in universe, though
[16:49] <ScottK> cjwatson: Yes, but this is replacing 1.46
[16:49] <cjwatson> Oh, I missed that
[16:50] <cjwatson> Promoted, thanks - I expect some of the binaries will want to fall back to universe later, but this will do for now
[16:50] <ScottK> 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] <slangasek> cjwatson: hmm, there are some unpleasant trade-offs with this apport change
[16:51] <ScottK> That should do it.  We'll want to give main users a chance to convert before dropping stuff back.
[16:51] <slangasek> (skaet just tagged me to follow through on it)
[16:51] <cjwatson> Oh?  It looked roughly in line with previous code
[16:52] <slangasek> cjwatson: it may indeed have been... but does this affect bug patterns?
[16:52] <cjwatson> That I'm not sure
[16:52] <cjwatson> Has ev already left?  I don't know this code as well as I should.
[16:52] <slangasek> because we explicitly put in some bug patterns pointing to pages with documentation to help users fix their upgrade issues
[16:52] <cjwatson> (And I have to finish up soon)
[16:53] <cjwatson> It's in -proposed, I guess v-failed will do for now if it's breaking stuff ...
[16:53] <slangasek> 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] <slangasek> 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] <slangasek> so that's pretty low priority
[16:57]  * cjwatson looks for a package he can test against new dpkg
[16:57] <slangasek> (the only real benefit is further reducing delta with Debian, in terms of both packaging and behavior)
[16:57] <cjwatson> Or I mean the proposed dpkg change
[16:58] <cjwatson> I think I need something that (a) doesn't set CFLAGS/LDFLAGS itself and (b) doesn't use dpkg-buildflags
[16:59] <cjwatson> And (c) doesn't use hardening-includes or similar
[16:59] <cjwatson> Perhaps man-db 2.5.7-4 is close enough
[17:03] <cjwatson> Annoyingly, lintian.uw.org isn't running a new enough version of lintian for the hardening checks yet
[17:04] <cjwatson> Ah, because it isn't released yet
[17:05] <cjwatson> Oh and (d) actually still builds, bah
[17:13] <debfx> aren't the hardening flags enabled in gcc anyway?
[17:13] <jibel> 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] <skaet> jibel, ev's left the building right now.    slangasek,  thoughts?
[17:15] <slangasek> sorry, I don't know
[17:15] <slangasek> 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] <jibel> 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] <gema> skaet: what is this change about?
[17:21] <gema> why is it going in so late?
[17:21] <gema> or is this for 12.04.1?
[17:22] <gema> slangasek: I thought you were off!
[17:22] <gema> in fact, I thought I was off too :/
[17:22] <slangasek> jibel: if you have a .upload stamp file in /var/crash, that should be sufficient verification
[17:23] <slangasek> gema: "off" is a funny concept ;)
[17:23] <slangasek> it just means I'm not answerable to my manager for anything I do today ;)
[17:24] <gema> uhmmmm... I am watching you, slangasek  :P
[17:24] <jibel> slangasek, it's there. verification-done :) thanks
[17:26] <slangasek> jibel: great, thanks - yeah, that's sufficient because whoopsie does the actual uploading and is an entirely separate package
[17:36] <slangasek> hggdh: jibel already tested apport, so I've copied it to -updates now
[17:36] <slangasek> hggdh: so you're off the hook :)
[17:36] <hggdh> slangasek: roj, thank you
[17:37] <skaet> thanks slangasek
[17:38]  * skaet --> out of millbank
[17:53] <claydoh> torrent for Kubuntu i386 desktop gives an error:
[17:53] <claydoh> rejected by tracker - Requested download is not authorized for
[17:53] <claydoh> use with this tracker.
[17:54] <claydoh> file downloads but doesn't seed
[17:54]  * ScottK pointed ^^^ since he recalled issues with the Ubuntu torrents yesterday.
[17:54] <claydoh> where would the best place to report that? All other torrents seem fine
[17:55] <cjwatson> here - I'll have a look shortly
[17:55] <claydoh> Ok thanks!
[17:58] <cjwatson> claydoh: should be fixed soon, sorry about that
[17:59] <cjwatson> I need to scan for these properly when I'm not supervising kids
[18:00] <claydoh> cjwatson: thanks!
[18:36] <ScottK> Would someone please de-New boost-defaults?
[19:01] <cjwatson> ScottK: done
[19:02] <cjwatson> three nested screen levels wasn't at all confusing there.  took me two goes to detach the right one afterwards.
[19:03] <ScottK> Thanks.
[19:28] <slangasek> ^a aa ^a ^a a
[19:30] <slangasek> cjwatson: wrt dpkg-buildflags: http://outflux.net/ubuntu/hardening/
[19:33] <cjwatson> maybe I should learn how to use canonistack so I can do comparison test rebuilds in it
[19:45] <slangasek> 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] <slangasek> I found the rationale for the debhelper compat hack, but not for the dpkg-buildflags part itself
[20:05] <micahg> slangasek: since the packaging might modify the output?
[20:06] <slangasek> micahg: I don't follow
[20:07] <micahg> don't some packages now expect dpkg-buildflags output and then add modifications on top of it?
[20:07] <slangasek> what if they do?  if those flags are already part of the gcc defaults, how does that hurt anything?
[20:07] <cjwatson> micahg: I think that's mostly unrelated, although there are perhaps some packages that will misbehave if *FLAGS isn't set in the environment, but I'd expect rather few since Debian doesn't do that
[20:07] <micahg> or would they get the same modifications if dpkg-buildflags did nothing since they're our default compiler
[20:07] <slangasek> yeah, that's what I would expect
[20:07] <cjwatson> How about -Wl,-Bsymbolic-functions?  I don't think the linker sets that by default
[20:08] <cjwatson> -fstack-protector is default; is --param=ssp-buffer-size=4?
[20:08] <slangasek> I'm not at all sure
[20:08] <cjwatson> -D_FORTIFY_SOURCE=2 is default
[20:09] <slangasek> kees thought only -Werror=format-security was affected
[20:09] <cjwatson> -Wformat and -Wformat-security are default; -Werror=format-security is not documented as such
[20:09] <cjwatson> -Wl,-z,relro is not documented as default
[20:10] <cjwatson> DEB_BUILD_OPTIONS handling would change a bit in the absence of exporting, but that doesn't affect our default builds
[20:10] <slangasek> where are you finding the documentation of the defaults?
[20:11] <cjwatson> info gcc-4.6
[20:11] <cjwatson> and looking in info ld for the -Wl,* ones
[20:11] <cjwatson>      NOTE: In Ubuntu 8.10 and later versions, for LDFLAGS, the option
[20:11] <cjwatson>      `-Wl,-z,relro' is used.  To disable, use `-Wl,-z,norelro'.
[20:12] <cjwatson> aha, that's in gcc-4.6
[20:12] <cjwatson> still need to figure out how to check for -Wl,-Bsymbolic-functions, though
[20:14] <ScottK> cjwatson: On a different topic (when you have some spare context) - Since I won't be at UDS, would you be willing to lead a session on changing build priority bases on seeded/packagesets as I proposed on ubuntu-devel a few weeks ago?  I can draft up a spec, but I think someone who'll be at UDS ought to lead the discussion.
[20:14] <cjwatson> Yes, I guess so; you think it needs a UDS session and not just a bug?
[20:15] <ScottK> If you think a bug is enough, I'm happy with that.
[20:15] <ScottK> There's plenty to do at UDS without inventing sessions that aren't needed.
[20:15] <cjwatson> Let me have a quick hunt for where this is implemented
[20:16]  * cjwatson doesn't know the buildmaster code that well
[20:17] <kees> hrm, did I push --param=ssp-buffer-size=4 into Ubuntu's gcc? I thought I did...
[20:18] <cjwatson> Ah, here we go, lib/lp/soyuz/model/buildpackagejob.py:BuildPackageJob.score()
[20:18] <cjwatson> That's actually relatively readable
[20:18] <kees> hrm, looks like I didn't. So --param=ssp-buffer-size=4 is only in dpkg-buildflags
[20:19] <kees> (as is -Werror=format-security). relro, as you found, has been in Ubuntu gcc for a while.
[20:19] <kees> https://wiki.ubuntu.com/ToolChain/CompilerFlags <- so I don't think this is lying
[20:19] <cjwatson> ScottK: Did we think it should be different for different packagesets, or just a bonus for being in a packageset at all?  (The latter is a lot easier since I don't have to figure out where to put the scores.)
[20:20] <ScottK> I think it's got to be specific packagesets get a bonus.
[20:20] <cjwatson> Drat.
[20:21] <ScottK> There are pakcagesets like mono that are completely unrelated to this question.
[20:21] <cjwatson> In that case it probably needs a session, but only if at least one Launchpad developer who knows anything at all about buildmaster can be there.
[20:21] <cjwatson> Or soyuz.
[20:21] <ScottK> That would be wgrant or who?
[20:21] <cjwatson> Maybe StevenK or bigjools or jtv.
[20:21] <ScottK> OK.  I'll ask around and see who's going to be there.
[20:21]  * cjwatson peers at the attendance list.
[20:22] <ScottK> Oh.  Good point.  Forgot there was one of those.
[20:22] <slangasek> kees: what does the ssp-buffer-size=4 mean?  That one's always been opaque to me
[20:22] <slangasek> if some packages start building without it, is that a big deal?
[20:22] <cjwatson> No sign of any of those people.  Maybe we'd be better off figuring it out on IRC.
[20:22] <cjwatson> kees: Do you happen to know if there's a way to tell if a given library has been built with -Wl,-Bsymbolic-functions?
[20:23] <cjwatson> I seem to remember that that was a performance improvement and I'd hate for it to gradually drift away.
[20:23] <cjwatson> ScottK: It might be as simple as adding a score column to Packageset, defaulting to zero, and adding an API method to set it.
[20:24] <cjwatson> That wouldn't be desperately hard.
[20:24] <ScottK> OK.  Maybe wgrant will pop up and some point and we can discuss.  He'll at least have the backscroll.
[20:25] <cjwatson> Then we could tweak the scores fairly freely and it wouldn't have to be analysed all that carefully in advance.
[20:26] <Laney> why packagesets and not seeded?
[20:26] <cjwatson> Launchpad knows about packagesets.  It doesn't know about seeds.
[20:26] <Laney> but it knows about packages and we know about packages in seeds
[20:26] <cjwatson> And I really don't want to put weeks or months of effort into the latteer.
[20:26] <cjwatson> *latter
[20:26] <cjwatson> It's irrelevant what we know.  It needs to be something in the Launchpad database.
[20:27] <cjwatson> I think packagesets would be good enough most of the time.  This doesn't need to be perfect (and probably can't be).
[20:27] <Laney> I am suggesting that the new priority column could be per-package.
[20:27] <cjwatson> It's not impossible, but I think it'd be overkill.
[20:28] <ScottK> Would it be simpler to make a need packageset called 'seeded' and bonus that one alone?
[20:28] <cjwatson> I don't want to hardcode any more Ubuntu-specific naming into Launchpad.
[20:29] <cjwatson> I'd rather it were entirely agnostic about packageset names.
[20:29] <cjwatson> (And I don't think it'd be particularly simpler, no)
[20:31] <cjwatson> I'd also rather change a relatively little-used table like Packageset than a table that gets hit all the time like DistributionSourcePackage ...
[20:31] <ScottK> OK.
[20:31] <cjwatson> But maybe wgrant will tell me that's unnecessary paranoia
[20:32] <ScottK> Is there such a thing as unnecessary paranioa with respect to Soyuz?
[20:32] <kees> slangasek: when gcc decided whether or not to add the ssp prefix/suffix to a function, it looks for any function with a character array of ssp-buffer-size bytes or more. The default is 8, but there are some things that are still a bit in danger, so gentoo had initially suggested the change, and RH and SuSE followed, and I tended to agree so I added it to Debian with the hopes of getting it into Ubuntu as well.
[20:33] <kees> slangasek: it's not a big deal to build without it. just marginally less "safe", though those numbers are, I'm sure, just hand-waving.
[20:33] <kees> cjwatson: -Wl,-Bsymbolic-functions I don't know about, unfortunately. that was all doko :)
[20:34] <cjwatson> It's impossible to google for since the results are full of build logs :-(
[20:35] <ScottK> There should be some special character sequence that is in all build logs that you could use to exclude them from results.
[20:35] <cjwatson> kees: So, I don't know, it's an odd trade-off.  Removing our band-aid would probably encourage us to push dpkg-buildflags patches up to Debian faster, but there's a risk of some regressions in the meantime.
[20:36] <cjwatson> And, from this discussion, regressions that aren't actually terribly easy to detect.
[20:37] <cjwatson> We'd lose ssp-buffer-size=4, some format-security errors would stop failing builds, and we might have changes to symbol binding in shared libraries.
[20:38] <cjwatson> The hardening options in DEB_BUILD_OPTIONS would probably start behaving differently by default, and I'm not sure how much you care.
[20:38] <cjwatson> And there'd be subtle changes due to *FLAGS being no longer set in the environment by default, which has some non-obvious effects on make's behaviour (although on the whole it would probably result in fewer annoying failures).
[20:41] <cjwatson> Maybe this is worth it; it doesn't sound immediately perilous.  I'd like to have some notion that we'll be able to scan for the differences, though.
[20:41] <kees> cjwatson: I don't feel strongly about it. I'd like to move ssp-buffer-size into the gcc patch regardless.
[20:42] <cjwatson> We can't be failing that many builds due to format-security right now anyway, since there aren't that many failures.
[20:42] <kees> when I added -Werror=format-security in Debian, I did so under the impression that Ubuntu wasn't force-exporting that into all builds. :P
[20:42] <cjwatson> Heh, the whole thing is confusing and perhaps reducing confusion is a bigger benefit that anything else.
[20:42] <kees> so, really, I'd prefer not having that explicit export. but that breaks stuff doko was wanting to have exported.
[20:42] <cjwatson> And our current dpkg-buildpackage patch is certainly awful.
[20:43] <cjwatson> Well, only really -Wl,-Bsymbolic-functions, unless there's stuff that needed CFLAGS='-g -O2' in order to behave correctly.
[20:43] <cjwatson> But FFS it's 2012.
[20:43] <kees> hah
[20:44] <kees> my stance on the ubuntu compiler-hardening has always been about making sure even non-package-builds get the options enabled.
[20:44] <kees> I continue not to be able to make time to get the option upstreamed to gcc as a configure option, though. Zorry (gentoo dev) has been working on it, though.
[20:47]  * jdstrand would add that this is a differentiating security feature for Ubuntu that we would like to maintain
[20:48] <jdstrand> hi kees! :)
[20:48] <cjwatson> jdstrand: The compiler changes or the dpkg-buildpackage export change?
[20:48] <jdstrand> to be clear, we want our non-package-builds to have the options enabled. where that happens or whether that happens in Debian or Ubuntu doesn't matter to me
[20:49] <cjwatson> Right, AFAIK nobody is talking about backing out the compiler changes
[20:49] <jdstrand> cool
[20:49] <cjwatson> Just trying to evaluate the effect of backing out the awful dpkg-buildpackage change
[20:51] <kees> hi jdstrand ! :)
[20:52] <kees> cjwatson: fwiw, from my compiler-hardening perspective, I am in favor of dropping the dpkg-buildpackage change.
[20:53] <cjwatson> Because it obscures compiler behaviour?
[20:55] <kees> cjwatson: well, because it creates, for me, unexpected behaviors (packages not expecting -Werror=format-security are getting those options)
[20:56] <cjwatson> Hm, I thought you were generally in favour of stuff failing rather than building insecurely
[20:57] <cjwatson> Aha, I just remembered that we don't automatically export -Werror=format-security anyway
[20:57] <cjwatson> So that's moot
[20:58] <cjwatson>         # While -Werror=format-security does catch many real bugs, it also
[20:58] <cjwatson>         # causes many build failures and causes a number of configure tests
[20:58] <cjwatson>         # to silently fail.  It was not exported to the environment in any
[20:58] <cjwatson>         # released version of Ubuntu.
[20:58] <cjwatson>         $build_flags->strip($flag, '-Werror=format-security', undef);
[21:05] <kees> yeah
[21:06] <micahg> should we revert that change for quantal?
[21:15] <cjwatson> micahg: Well, that's what we were discussing for the last hundred lines or so :-)  But not just that bit, the whole export block around it
[21:16]  * micahg needs to stop trying to help on 4 hours of sleep :)
[21:49] <kees> cjwatson: correction -> ubuntu _is_ already running with ssp-buffer-size=4. I missed where I'd patched it.
[22:05]  * ScottK would appreciate it if a "C" archive admin would do the backport in Bug #990140.
[22:05] <ubot2> Launchpad bug 990140 in precise-backports "Please backport debootstrap 1.0.40 from quantal to precise" [Wishlist,In progress] https://launchpad.net/bugs/990140
[22:06] <slangasek> kees, cjwatson: right, I think it's better to reduce the confusion... if we're wrong about having the resources to fix things up this cycle, it's not grave
[22:06]  * kees nods
[22:07] <ScottK> Ah.  slangasek: Would you please take care of the debootstrap backport? ^^^
[22:07] <kees> I've just opened 990141 with a patch to document the ssp-buffer-size change, btw (first done in 10.10)
[22:07] <slangasek> ScottK: looking
[22:07] <ScottK> Thanks.
[22:14] <slangasek> ScottK: done
[22:14] <ScottK> slangasek: Thanks.
[23:11] <slangasek> hmm, failure trying to submit a merge proposal for quantal: bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/mirrors/00/09/60/5f'
[23:12] <slangasek> oh, possibly a wrong branch state
[23:13] <slangasek> yeah
[23:20] <cjwatson> OK, I'm building everything in main in a canonistack instance with a chroot with the flags export hack deleted from dpkg-buildpackage; may not need to complete that run, but I'll see how it does over the weekend
[23:20] <cjwatson> least sophisticated buildd ever, it's a for loop around sbuild ;-)
[23:22]  * slangasek grins
[23:29] <Daviey> rebuildd, whilst not that cleanly written.. is great for this.. i had it running across 3 different machines before, sharing the same dispatcher.
[23:29] <Daviey> took some changes to make it work with sbuild.. and a seperate *.py for adding jobs.. but that along with lpapi worked really nicely.
[23:31] <cjwatson> yeah, I might try something a bit more packaged when I have a bit more time.  mini-buildd looked promising too.
[23:32] <Daviey> ISTR mini-buildd was single host?  you couldn't dispatch the jobs to multi-hosts?
[23:32] <cjwatson> It looks smarter than that to me, but I didn't look very hard
[23:33] <cjwatson> Its package description talks about an autobuilder network
[23:33] <cjwatson> And judging by its dependencies it already works with sbuild
[23:34] <Daviey> Ah, groovy.. I must have been thinking of another tool.
[23:46] <Daviey> cjwatson: The thing i liked about rebuildd was that i could use the sqlalchemy orm to produce reports on pass/fail/dep-wait.. doesn't seem mini-buildd is db backed.
[23:47] <cjwatson> heh, I'm just doing grep ^Status: ;-)
[23:47] <cjwatson> (sure, I suspect the second go-around I'll do something more sophisticated)
[23:48] <Daviey> heh
[23:52] <wgrant> ScottK, cjwatson: There's going to be a Launchpad dev at UDS, but nobody who knows anything about Soyuz. I'd go with the priority on packageset.
[23:52] <wgrant> Pretty simple.
[23:53] <ScottK> wgrant: Is a bug enough for this?
[23:53] <wgrant> Yes, particularly if cjwatson does the work, otherwise it won't be done for 2 years
[23:53] <ScottK> Sigh.
[23:55] <cjwatson> I can do the work, that's fine
[23:55] <wgrant> It's not a particularly big piece of work
[23:56] <cjwatson> You reckon my assessment above (add column on packageset, export on webservice, add in .score) is about right?
[23:56] <cjwatson> Aha, -Wl,-Bsymbolic-functions is detectable in the output of 'objdump -R'
[23:57] <cjwatson> So I think I'll build main, extract libraries, objdump -R, compare with real archive
[23:59] <wgrant> cjwatson: Yeah