[12:50] <klaidas_> @schedule Vilnius
[12:50] <Ubugtu> Schedule for Europe/Vilnius: 02 Jan 22:00: Technical Board | 03 Jan 22:00: Edubuntu | 04 Jan 00:00: Xubuntu | 04 Jan 18:00: Ubuntu Development Team | 09 Jan 17:00: LoCo Team | 09 Jan 18:00: Forum Council
[12:55] <freeflying|away> @schedule shanghai
[12:55] <Ubugtu> Schedule for Asia/Shanghai: 03 Jan 04:00: Technical Board | 04 Jan 04:00: Edubuntu | 04 Jan 06:00: Xubuntu | 05 Jan 00:00: Ubuntu Development Team | 09 Jan 23:00: LoCo Team | 10 Jan 00:00: Forum Council
[12:58] <freeflying|away> @schedule shanghai
[12:58] <Ubugtu> Schedule for Asia/Shanghai: 03 Jan 04:00: Technical Board | 04 Jan 04:00: Edubuntu | 04 Jan 06:00: Xubuntu | 05 Jan 00:00: Ubuntu Development Team | 09 Jan 23:00: LoCo Team | 10 Jan 00:00: Forum Council
[06:17] <siretart> @schedule Europe/Berlin
[06:17] <Ubugtu> Schedule for Europe/Berlin: 02 Jan 21:00: Technical Board | 03 Jan 21:00: Edubuntu | 03 Jan 23:00: Xubuntu | 04 Jan 17:00: Ubuntu Development Team | 09 Jan 16:00: LoCo Team | 09 Jan 17:00: Forum Council
[09:00] <siretart> TB Meeting anyone?
[09:00] <Keybuk> Never Fear, I Is Here
[09:00] <siretart> hey Keybuk  :)
[09:00] <Keybuk> do we have mdz, mjg59 or sabdfl?
[09:01] <ogra> doesnt look like
[09:01] <siretart> mjg59 seems to be on #ubuntu-devel, no idea about mdz and sabdfl
[09:02] <siretart> Keybuk: did my inquiry arrive on techical-board@l.u.c? I didn't get any response yet
[09:02] <Keybuk> it did, yes
[09:02] <siretart> okay
[09:02] <Keybuk> the lack of response is almost certainly related to the holiday season
[09:02] <siretart> I thought so, no problem
[09:02] <siretart> I wasn't sure about correct arrival either
[09:03] <mjg59> Tch. I was sure I had this on autojoin.
[09:05] <Keybuk> ok
[09:05] <Keybuk> let's get started
[09:05] <Keybuk> mdz is on holiday, and has no internet access
[09:05] <Keybuk> so it's just the two of us today
[09:05] <mjg59> Right
[09:05] <Keybuk> first, some administrivia
[09:05] <mjg59> Anyone for core-dev?
[09:05] <mjg59> Ah, ok
[09:06] <Keybuk> people will note that it's been two years since we started using LP to track developers
[09:06] <Keybuk> so we're starting to get people's team membership expire
[09:06] <Keybuk> if you're an active developer, you'll be renewed automatically
[09:06] <Keybuk> if you haven't been active for a while, you may need to reapply via TB meeting again
[09:07] <siretart> how is the 'activeness' measured? by a human or by soyuz looking at the last upload?
[09:07] <Keybuk> human
[09:07] <siretart> k
[09:08] <Keybuk> one of the TB members will react to the "seb128 has expired!" e-mail, and renew the membership :)
[09:08] <ogra> do trhe users get them too ?
[09:08] <Keybuk> yes
[09:08] <ogra> to have the ability to raise their hands  ?
[09:08] <ogra> ah, cool
[09:09] <ogra> i had some for edubuntu recently
[09:09] <Keybuk> anyway, onwards
[09:09] <Keybuk> core-dev
[09:09] <Keybuk> I have nobody in my list
[09:09] <Keybuk> is there anybody here who's applied for core-dev membership and thinks they should be?
[09:10] <Keybuk> clearly not
[09:10] <Keybuk> good
[09:11] <Keybuk> ubuntu-dev
[09:11] <Keybuk> again, I have nobody in my l.ist
[09:11] <Amaranth> https://launchpad.net/people/ubuntu-core-dev/+members shows 4 people
[09:11] <Keybuk> is there anybody here who's applied for ubuntu-dev membership and thinks they should be?
[09:11] <ogra> why is kylem on there ?
[09:11] <Keybuk> Amaranth: we only consider people who applied since the last TB meeting
[09:11] <Amaranth> ah, i see
[09:11] <ogra> he should be uploading already, shouldnt he ?
[09:12] <Keybuk> those that applied before are people who were turned down at a previous meeting with a "later"
[09:12] <Keybuk> ogra: playing "join all teams", I expect
[09:12] <ogra> heh
[09:13] <Keybuk> ok
[09:13] <Keybuk> nobody for ubuntu-dev today then
[09:13] <kylem> ogra, i didn't read far enough that core-dev implied -dev.
[09:13] <Keybuk> dholbach isn't around, so I assume we will not be discussing Council Greyskull today
[09:13] <ogra> well, no quorum anyway
[09:14] <Keybuk> siretart: you have an agenda item, the floor is yours
[09:14] <Keybuk> ogra: we have Q
[09:14] <ogra> two is enough ?
[09:14] <ogra> ah, right, its TB :) not CC
[09:14] <Keybuk> ogra: yes, TB Q has always been two
[09:14] <siretart> well, status update: I have contacted the techincal board again, this time via email about the ffmpeg issue
[09:14] <Keybuk> we assume a three man team, and require a simple majority
[09:15] <siretart> I filed a MIR about ffmpeg, requested it to be reapproved for main
[09:15] <Keybuk> yes
[09:15] <Keybuk> I didn't get the context of the e-mail
[09:15] <siretart> I'm still not sure what codecs are exactly problematic
[09:16] <siretart> until that issue is resolved, I'm proposing an interim solution: let's upload xine-lib with its internal partial copy of ffmpeg with no mpeg2 encoding capabilities
[09:16] <siretart> to main that is
[09:16] <Keybuk> what uses xine-lib?
[09:16] <mjg59> Ok. So I've a couple of questions about this, to begin with.
[09:16] <siretart> since we already have packages like libmad, I'd like to know what issues are to resolve
[09:17] <siretart> Keybuk: most notable kubuntu (amarok) and xubuntu
[09:17] <mjg59> 1) Is mpeg2 the only actively-enforced-patent-encumbered codec in ffmpeg?
[09:17] <ogra> Keybuk, totem-xine
[09:18] <mjg59> We're getting very close to the point where we should drop totem-xine, but that's not strictly important
[09:18] <siretart> mjg59: 1) I refer to debian/patents.txt quoted on https://wiki.ubuntu.com/MainInclusionFFmpeg. Sam (and me neither) don't know about any further
[09:18] <Keybuk> ogra: don't we support totem-gstreamer instead?  and the theory of ffmpeg-in-main was that some of the ugly codecs could be in main too?
[09:18] <siretart> Keybuk: gxine as well
[09:18] <ogra> Keybuk, right, totem-xine isnt in main either, sorry
[09:19] <siretart> Keybuk: xine uses ffmpeg not only for codecs. some plugins use the 'libpostproc' library, which has nothing to do about decoding. I expect some other packages as well
[09:19] <mjg59> siretart: I'm not sold on the "libmad is in main, so ffmpeg should be"
[09:19] <mjg59> It's equally plausible that libmad being in main is an error
[09:20] <mjg59> We quite clearly don't ship a useful mp3 player in main, and that's defined as policy
[09:20] <siretart> mjg59: demotion of libmad would cause quite some trouble, looking at the reverse build-deps
[09:20] <Keybuk> http://people.ubuntu.com/~cjwatson/germinate-output/feisty/rdepends/libmad/libmad0
[09:21] <siretart> mjg59: anyway, if the decision is to demote libmad, then I'd request to demode xine-lib as well. this would however deeply annouy kubuntu and xubuntu users
[09:21] <Keybuk> I'm not sure why it's still a build-depend
[09:21] <Mithrandir> mjg59: *cough*; xmms *cough*
[09:21] <zul> Mithrandir: er...its still kind of brroken
[09:21] <mjg59> Mithrandir: Seriously? That can't be deliberate.
[09:22] <Mithrandir> mjg59: done so since warty.
[09:22] <mjg59> Sigh.
[09:22] <mjg59> Ok.
[09:22] <Keybuk> note that main != CD
[09:22] <mjg59> Let's just ignore the current state of reality. It clearly isn't useful.
[09:22] <Mithrandir> it might very well be an error, but we quite clearly do, just not in a default install.
[09:22] <Keybuk> we certainly don't ship any MP3 players on the CD
[09:22] <Keybuk> that's definitely legally naughty
[09:23] <mjg59> Right. So.
[09:23] <Keybuk> on the FTP site is legally wishy-washy because users initiate the download
[09:23] <siretart> as mentioned, I have already prepared new xine 1.1.3 packages, with the ffmpeg plugin split out to libxine1-ffmpeg. Xine loads its plugins at runtime using dlopen, which makes this convinient
[09:23] <mjg59> Keybuk: Do we have legal advice on that?
[09:23] <Keybuk> mjg59: that's my understanding, otherwise we wouldn't ship them in universe
[09:23] <siretart> so even if we promote ffmpeg and xine-lib uses that, we don't need to put ffmpeg on the CD
[09:23] <Keybuk> my understanding is that main vs. universe is legally no different, but CD vs. FTP is
[09:24] <siretart> this was an argument in my email, right
[09:24] <mjg59> Keybuk: Ok. You're in a better position to check that than I am - is it possible to verify that, just to make sure that we're not doing it unwittingly?
[09:24] <Keybuk> main vs. universe is simply a matter of which team (core-dev vs. dev) supports the package
[09:24] <mjg59> Right, clearly there's no legal distinction between main, universe and multiverse
[09:25] <Riddell> people may assume that since main is supported it can be freely used without worrying about getting a patent licence
[09:25] <Riddell> (or they may not)
[09:25] <mjg59> So based on current practice, providing a xine-lib including ffmpeg would be fine for main, just not for ship
[09:25] <Keybuk> mjg59: previous legal issues have been somewhat clouded by people shouting "WE'RE GOING TO JAIL!" over the top of sensible discourse  ;)
[09:25] <Keybuk> mjg59: assuming that xine-lib, xmms, etc. aren't in main by mistake :p
[09:26] <Keybuk> none of them are seeded, so I'd be willing to believe an FTP master was especially asleep one day
[09:26] <Riddell> we need xine-lib
[09:26] <mjg59> Keybuk: Well, that pretty much definitely would be "aren't on the FTP server by mistake"
[09:26] <Riddell> and xmms is orders of sabdfl I believe
[09:26] <Keybuk> but yes, given that xmms and libmad are in main, I don't see the reason that ffmpeg isn't
[09:26] <mjg59> I'm going to attempt to summarise this, and propose the next step.
[09:27] <Keybuk> siretart has filed an MIR, that's a request for the archive admins to promote it
[09:27] <siretart> xmms and ffmpeg are pretty unrelated. xmms uses libmad, which bring in the same legal concers as ffmpeg though
[09:27] <Keybuk> actually
[09:27] <Keybuk> sorry
[09:27] <Keybuk> that's a request for the security team to review it
[09:27] <Keybuk> so the next step is for pitti or keescook to review the source to determine whether we can provide security support for ffmpeg
[09:27] <mjg59> (*) Current policy appears to be that patent-encumbered code may be distributed in main, but not in ship.
[09:27] <Keybuk> if they approve it, then it's a request for the archive admins to promote it once it has been seeded
[09:27] <Keybuk> anyone in core-dev can modify the seeds
[09:28] <Keybuk> mjg59: that is my understanding, yes
[09:28] <mjg59> (*) Based on this, it would be reasonable for a version of xine-lib containing ffmpeg code to be in main. However, any package that becomes part of ship must *not* contain this code.
[09:28] <siretart> I don't think anyone not in the desktop team dares to touch the seeds ;)
[09:28] <Keybuk> siretart: hmm, most of core-dev have touched them ?
[09:29] <siretart> aha? - interesting :)
[09:29] <mjg59> (*) Therefore, assuming the accuracy of the first observation, the TB has no reason to deny the inclusion of ffmpeg code in main *providing* that the technical implementation allows the ffmpeg code to be split from the core xine-lib binary package
[09:30] <Keybuk> it may be worth posting that as a summary, and requesting the Community Council's input
[09:30] <siretart> mjg59: I assume you mean 'binary code' and not 'source code' here
[09:30] <mjg59> (This is predicated upon the accuracy of the first observation. The TB should also internally determine that adequate legal advice has been obtained by Canonical)
[09:30] <mjg59> siretart: Either
[09:31] <Keybuk> I would also add:
[09:31] <Mithrandir> having stuff in main we can't ship on the CDs is a bit bad since people can easily end up including it by mistake by promoting something else.
[09:32] <mjg59> Mithrandir: This situation already exists. We should ensure that it is hard.
[09:33] <mjg59> If you feel it's practical, I'd be happy for us to suggest that it be a requirement that the archive allow packages to be tagged as "not ship", or something similar
[09:33] <Keybuk> (*) This constitutes a recommendation of the TB, however this recommendation is not binding and the Archive Administrators are permitted to deny this.
[09:33] <siretart> like putting the binary package 'ffmpeg' (ffmpeg command line utilities) and libxine1-ffmpeg
[09:33] <siretart> to universe?
[09:33] <mjg59> Having libxine1-ffmpeg in main should be fine
[09:34] <Keybuk> why would having ffmpeg in main be not fine?
[09:34] <mjg59> It's just important that it never somehow end up in ship
[09:34] <Keybuk> they're useful utilities
[09:34] <siretart> indeed, they are
[09:35] <mjg59> Keybuk: Do you want to mail this to people, or shall I?
[09:35] <Keybuk> mjg59: can you
[09:35] <mjg59> Ok
[09:35] <mjg59> Anyone have anything else to add?
[09:35] <siretart> yes
[09:35] <Keybuk> siretart: your next step, anyway, is to talk to pitti and keescook and have the MIR approved
[09:35] <siretart> I'd like an answer to my interim proposal
[09:35] <Keybuk> regardless of any patent issues, you need their approval
[09:35] <Keybuk> I don't see how your interim proposal helps anything?
[09:35] <siretart> read: upload xine-lib and make it use the internal (decoding only) copy
[09:36] <siretart> Keybuk: it allows having xine-lib 1.1.3 sooner in the archive
[09:36] <Keybuk> is there a critical or urgent bug this fixes?
[09:36] <siretart> allowing Riddell to upload a newer amarok
[09:36] <mjg59> siretart: Given what we've concluded, I don't see any reason for that to be something we need to cover here
[09:36] <siretart> and buying us additional testing
[09:36] <mjg59> Do whatever you think is best
[09:36] <mjg59> With the previous proviso of ensuring that ffmpeg code never appears in ship
[09:36] <Keybuk> amarok is shipped
[09:37] <siretart> I think uploading with ffmpeg is best for ubuntu, so we finally get goodies like WMV9 on amd64 :)
[09:37] <Keybuk> it's part of ubuntu-desktop
[09:37] <Keybuk>              ^
[09:37] <Keybuk>              k
[09:37] <Keybuk> so that's forbid, under our current reading
[09:37] <mjg59> siretart: Would the ffmpeg code be in a separate binary package?
[09:37] <siretart> Keybuk: that's no problem. the ffmpeg code in libxine1-ffmpeg does not need to be in ship. amarok just depends on libxine1
[09:37] <mjg59> I believe you implied it would be
[09:37] <siretart> mjg59: yes, I already have such packages ready
[09:37] <mjg59> Yes, then that's fine. Just ensure that nothing depends on libxine1-ffmpeg.
[09:38] <siretart> as seen in https://code.launchpad.net/people/siretart/+branch/xine-lib/xine-lib.ubuntu.1.1.3
[09:38] <siretart> yepp, willdo
[09:38] <mjg59> Ok. I think we're done with this.
[09:38] <siretart> thanks
[09:38] <Keybuk> you may want to check the new source with pitti/keescook
[09:38] <Keybuk> especially if it contains a complete copy of ffmpeg
[09:39] <Keybuk> just to make sure it wasn't removed for security reasons
[09:39] <Keybuk> ok, that's the end of the agenda on my screen
[09:39] <Keybuk> any other business?
[09:40] <Keybuk> ok, done
[09:40] <Keybuk> unless we hear a scream from elmo at this point
[09:41] <mjg59> Right. I'll email a summary.
[09:41] <Keybuk> thanks
[09:41] <Keybuk> I'd mail it to the TB and CC
[09:42] <siretart> well, he (as debian ftpmaster) has approved it for debian/main
[09:42] <mjg59> Keybuk: Do I want to mail archive admins?
[09:42] <siretart> at least, he didn't object
[09:42] <Keybuk> can do
[09:42] <Keybuk> siretart: the Debian package has had all of the encoding ripped out, no?
[09:42] <mjg59> Do we have a list for them?
[09:43] <Keybuk> ubuntu-archive@lists.ubuntu.com
[09:43] <siretart> Keybuk: not all. the 'problematic' ones (to the best knowledge of the package maintainer)
[09:43] <Robot101> siretart: as a slight aside, do you know how this list of "problematic" encoders was arrived at?
[09:44] <siretart> Robot101: see my mir. the files README.Debian and patents.txt do have a nice summary
[10:19] <Keybuk> mjg59: nice summary
[10:19] <Keybuk> personally I'd like to just enable mp3 support in main once and for all :)
[10:19] <somerville32> :] 
[10:20] <mc44> Keybuk: only have to wait till 2011 :)
[10:26] <siretart> Keybuk: mp3 encoding or decoding support?