=== RAOF_ is now known as RAOF
[02:39] <ScottK> slangasek: I'm all for killing unsupportable stuff.  You'll get no argument from me.
[02:40] <ScottK> Laney: Self approval is explicitly OK for backports.  It's a benefit of being a member.
[02:40] <ScottK> (you do still need to meet the test criteria)
=== doko__ is now known as doko
[08:29] <tumbleweed> slangasek: don't we also need a multiarch-friendly nspluginwrapper for flash?
[08:30] <slangasek> tumbleweed: ah; yes, but that part I consider a bugfix :)
[08:30] <slangasek> I could upload that nowish, I guess
[08:31] <tumbleweed> good to hear :) I have no intentions of installing ia32-libs again on my machine
[08:33] <slangasek> actually, I guess I'd rather hold off on tha nspluginwrapper upload until we have multiarch enabled for amd64 users on upgrade to oneiric
[08:44] <slangasek> tumbleweed: are you inclined to ack that FFe request?
[08:44] <slangasek> I've spoken with doko; he hasn't started the rebuild test yet, and he says he can wait for them to upload/build before starting it
[08:45] <slangasek> so if we're going to include bug #826601, now's the time to do it
[08:45] <ubot4> Launchpad bug 826601 in rtmpdump (Ubuntu) (and 2 other projects) "FFe: multiarch dependencies of libcurl, needed for proper functioning of flashplugin-installer (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/826601
[08:46] <slangasek> or if that's putting you too much on the spot, I can ask pitti or cjwatson :)
[08:47]  * doko is waiting to pull the trigger ...
[08:48] <doko> pitti: please no gnome/gtk uploads before this ^^^ (seb128 didn't yet show up)
[08:48] <tumbleweed> yeah, holding abck on nspluginwrapper seems sensible. I'm inclined to ACK it, because it's something I'd like to see. I do feel hesitant, because I'm new around here, but I do trust you to sort out any issues resulting from it :)
[08:48] <pitti> doko: this == libcurl multiach?
[08:48] <pitti> "arch"
[08:48] <doko> yes
[08:49] <pitti> noted
[08:53] <pitti> slangasek: is there a known fix for php5?
[08:53] <slangasek> pitti: yes, attack the build system with a rusty spoon
[08:53] <slangasek> (it's certainly fixable, it just requires hand-hacking for each library that transitions)
[08:53] <pitti> i. e. hand-hack the -L paths or something like that?
[08:54] <slangasek> rather, they have custom autoconf .m4 macros to do library detection
[08:54] <slangasek> so for each dependency that's multiarched, the build system has to be updated
[08:54] <pitti> eww
[08:54] <slangasek> but really, that's the easy case
[08:55] <slangasek> because we know about it... it's the "what else might break" that we don't know :)
[08:55] <tumbleweed> yeah, at least that's obvious and FTBFS-triggering
[08:56] <pitti> let's do that then
[08:57]  * pitti approves above bug
[08:57] <slangasek> cool, thanks
[09:00] <pitti> doko: FYI, today is a national holiday for seb128, so he won't get online
[09:00] <pitti> (actually, for me as well, oops)
[09:00] <doko> ahh, then I'm safe!
[09:01] <slangasek> openssl uploaded
[09:01] <doko> bah, bavaria
[09:34] <cjwatson> slangasek: I was planning to pull in the openssl098 source, BTW - I just hadn't done so yet because it requires reapplying Ubuntu customisations rather than just being a simple sync
[09:34] <cjwatson> slangasek: partly because, even if we do manage to fix everything in the archive, libssl seems like the sort of thing people are not unlikely to have local binaries built against
[09:34] <slangasek> ah, sure
[09:35] <cjwatson> (and incidentally I'm not planning to multiarchify openssl098 ;-) )
[09:37] <slangasek> :-)
[09:46] <slangasek> doko: ok, openldap also uploaded
[09:46] <slangasek> and I'm off to bed, 'night :)
[11:49] <tumbleweed> slangasek: it appears we need cyrus-sasl2 too (for libldap)
[13:12] <ScottK> tumbleweed: I think we need heimdal promoted before we can build that again.
[13:12] <cjwatson> I thought it already had been
[13:12] <cjwatson>    heimdal | 1.5~pre2+git20110804-1ubuntu2 |       oneiric | source
[13:27] <ScottK> Ah.  I missed that.  Thanks.
[13:30] <ScottK> cjwatson: If you aren't going to have time for a sync run today (of if you already did it), I'd appreciate it if you could go ahead and do Bug 826725.  If you're planning on doing syncs at some point today, no rush.
[13:30] <ubot4> Launchpad bug 826725 in icecc (Ubuntu) "Sync icecc 0.9.7-2 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/826725
[13:31] <cjwatson> ScottK: in general I'm holding off the sync queue at the moment in order to keep hold of test cases for LP native syncing, but I'll do icecc now
[13:31] <ScottK> cjwatson: Thanks.
[13:34] <Laney> cjwatson: if that's the case, then please also do mono (it's from exp so isn't a candidate for native syncing anyway)
[13:35] <cjwatson> actually it should be surely
[13:35] <Laney> I thought that only supported one parent (i.e sid)
[13:35] <cjwatson> oh bloody hell
[13:35] <Laney> happy to be wrong
[13:36] <cjwatson> it should be able to sync any gina-imported version
[13:36] <Laney> perhaps that's just the UI
[13:36] <cjwatson> oh bloody hell> that was a reaction to https://launchpad.net/debian/+source/mono only showing stable testing unstable, but actually, if you look closely, it has version 2.10.4-2 which is the version in experimental
[13:36] <cjwatson> so it should be syncable using the API and I'd like to have that as a test case
[13:37] <Laney> ack
[13:37] <cjwatson> the API takes source_name, version, from_archive, to_pocket, to_series, include_binaries
[13:37] <Laney> that's good actually — I thought multiple parents were required for exp syncing
[13:38] <Laney> :-)
[13:38] <cjwatson> it's probably strictly more capable than the UI
[15:58] <robbiew> skaet: ping
[15:59] <skaet> robbiew, yup?
[16:00] <robbiew> skaet: do we have a FinalFreeze date for Universe?
[16:00] <robbiew> or is it the same as in the past
[16:00] <robbiew> i.e.  a few days before release
[16:02] <skaet> robbiew,  it probably needs a good discussion,  since unseeded universe is different than seeded.   So Universe is ambiguous.
[16:02] <robbiew> good point
[16:02] <skaet> robbiew,  will start a discussion off on ubuntu-release mail list,  and see if there's some other data points that need to be considered too.
[16:03] <skaet> thanks for raising it,   will see if we can get closure and updates before beta1.
[16:04] <robbiew> skaet: cool, thx
[16:04] <skaet> s/updates/updates to the WIKI pages/
[16:04] <skaet> :)
[16:04] <cjwatson> "seeded" is ambiguous too - what really matters is whether the package is on an image or not
[16:04] <robbiew> cjwatson: right...so for packages *not* on an image
[16:05] <SpamapS> robbiew: like, say, ensemble. ;)
[16:05] <robbiew> heh
[16:12] <Daviey> cjwatson: What about just 'supported' seed?
[16:21] <cjwatson> Daviey: the very definition of supported is that it includes random stuff not on an image
[16:22] <cjwatson> given that what we mean is "don't get in the way of image builds", we should say that rather than waffling about seeds
[16:23] <Daviey> cjwatson: Okay.
[16:24] <mterry> skaet, hello, where do the 11.10 release notes live?  Is that OneiricOcelot/TechnicalOverview?  I have a workitem to make sure there's a blurb for the new backup program
[16:25] <skaet> mterry,   use the TechnicalOverview for now,  will use that as the basis for the offical release notes.
[16:26] <mterry> skaet, OK, I'll look at adding a little something then.  Thanks!
[16:26] <skaet> mterry,  Thanks!
=== kklimonda is now known as Guest71858