=== jamie is now known as Guest97591 === Guest97591 is now known as JamieBennett === lukjad007 is now known as lukjad86 === The_Toxic_Mi1e is now known as The_Toxic_Mite === txwikinger2 is now known as txwikinger [14:02] #startmeeting [14:02] Meeting started at 08:02. The chair is NCommander. [14:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [14:02] Hello NCommander [14:02] hello [14:02] * ericm waves to all [14:02] * NCommander apologies for being tardy, laptop decided to fsck itself [14:02] * JamieBennett is here [14:03] * GrueMaster is present and/or accounted for. [14:03] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100406 [14:03] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100406 [14:03] [topic] Action Item Review [14:03] New Topic: Action Item Review [14:04] [topic] cooloney to get karmic-proposed imx51 kernel with NEON fix in [14:04] New Topic: cooloney to get karmic-proposed imx51 kernel with NEON fix in [14:05] No cooloney I guess [14:05] lets move on then [14:05] well [14:05] NCommander: does that include the backport FEC ethernet driver? [14:05] I know a bit about what was going on there [14:05] anmar: not sure [14:05] plars: if you want to fill us in [14:05] it's still in progress... there's a kernel in proposed, with the new FEC driver [14:06] however, there was a regression in this updated driver, that can have a performance impact under load [14:06] i am here [14:06] it does, however, fix the initial problem [14:06] sorry [14:06] cooloney: np [14:06] no worries, just filling them in on the imx51 karmic kernel that you are working on [14:06] plars: thanks a lot [14:07] you have anything to add? did that sound reasonable as a summary? [14:07] the kernel in proposed for karmic is ok for neon fix [14:08] and smb pinged the pitti to accept it. [14:08] but for fec driver performance impact [14:08] i am still working on that [14:08] [topic] NCommander to extend invite to ericm and amitk to report on kernel status [14:08] New Topic: NCommander to extend invite to ericm and amitk to report on kernel status [14:08] hmm, I marked it verification-failed because of the regression. I would not think we would want to accept it as is [14:09] ok, mlv-dove topics today [14:09] I forgot to ping amitk, but ericm is here [14:09] so c/o [14:09] [topic] plars to follow up with crimsun on the sound bug and report back [14:09] New Topic: plars to follow up with crimsun on the sound bug and report back [14:09] 1. Karmic X0 support, which I'd guess should be necessary for us to get it in right? [14:09] plars: right, i also found the same impact on lucid [14:09] done, but still in progress [14:09] NCommander: slow down [14:10] ericm: we'll go over the kernel status in the standing item later [14:10] NCommander, ok [14:10] plars: why is the sound bug still in progress? [14:10] so sound is still broken, but still being worked on [14:10] hmm... because it hasn't been fixed yet? :) [14:11] plars: oh, you were saying done to following up :-) [14:11] NCommander: right [14:11] crimsun and I have been working on this all last week. We now think it is related to arm specific code in pulseaudio. [14:11] crimsun is investigating further. [14:11] so removing .pulse seems to workaround a lot of the issues, but not all [14:11] GrueMaster: ARM specific code in pulse? Last time I looked there wasn't a lot, and that could easily be checked by forcing a fallback to the C code [14:12] Did that yesterday. [14:12] That's how we know it is arm specific code. [14:12] GrueMaster: ugh *grumble* [14:12] GrueMaster: keep us informed, we want a working pulse [14:12] yep [14:13] [action] GrueMaster and plars to continue to keep working with crimsun on ARM PulseAudio [14:13] ACTION received: GrueMaster and plars to continue to keep working with crimsun on ARM PulseAudio [14:13] [topic] asac to upload libplist with -marm [14:13] New Topic: asac to upload libplist with -marm [14:14] asac doesn't seem to be around, does anyone know if this was done? [14:14] * NCommander is looked at LP ATM [14:15] No, it wasn't [14:15] c/o [14:15] I don't see an outstanding bug for this either [14:15] [actoin] asac to upload libplist with -marm [14:15] [action] asac to upload libplist with -marm [14:15] ACTION received: asac to upload libplist with -marm [14:15] [topic] asac and dmart to get firefox rendering issue upstreamed [14:15] New Topic: asac and dmart to get firefox rendering issue upstreamed [14:16] hrm [14:16] no dmart [14:16] c/o [14:16] [action] asac and dmart to get firefox rendering issue upstreamed [14:16] ACTION received: asac and dmart to get firefox rendering issue upstreamed [14:16] [topic] Standing Items [14:16] New Topic: Standing Items [14:16] [link] http://people.canonical.com/~pitti/workitems/canonical-mobile.html [14:16] LINK received: http://people.canonical.com/~pitti/workitems/canonical-mobile.html [14:17] [link] http://people.canonical.com/~pitti/workitems/canonical-mobile-ubuntu-10.04-beta-2.html [14:17] LINK received: http://people.canonical.com/~pitti/workitems/canonical-mobile-ubuntu-10.04-beta-2.html [14:17] so beta 2 is upon us [14:17] ouch, beta-2 work items need some love [14:18] JamieBennett: indeed [14:18] webservice-for-email is the one thats really hurtting [14:19] [topic] Kernel Status (cooloney, ericm) [14:19] New Topic: Kernel Status (cooloney, ericm) [14:20] cooloney, you first [14:20] ok [14:20] actually, nothing important from my side these days [14:21] i just noticed fsl is pushing their code to their public git tree [14:21] what about hibernation? [14:21] not supported on imx51 [14:21] oh, fsl-imx51 does not support hibernation [14:21] Or suspend/resume? [14:21] i think you guys reported suspend/resume regression after new fec driver applied [14:21] yes [14:22] but i am still working on the performance impact [14:22] that's all from my side [14:22] ok, for dove [14:23] I've merged the latest LSP 5.1.0 from Marvell [14:23] yet it seemed to introduce a suspend/resume regression [14:23] I was verifying this with Marvell this afternoon and basically concluded this to be HW issue [14:24] ericm: so they no longer think it's uboot related? [14:24] I've borrowed a good board from them, everything works fine here [14:24] ericm: isn't the A0 out now? [14:24] plars, I'm now downgraded to 4.4.0, but it seemed not uboot related [14:25] ok :( [14:25] NCommander, not sure that A0 stepping [14:25] but, hibernation still failed [14:25] ericm: what is the rev of the board you borrowed? [14:25] plars, it's no newer than ours [14:26] then why does it work when ours don't? [14:26] plars, so I doubt there are some HW differences, e.g. ECOs we'd like to confirm with Marvell Israle site, yet they seem to be all on holidays this week [14:26] GrueMaster, I have no idea of the possible HW difference [14:27] ericm: ask what version of the BootROM they're using [14:27] ericm: that's been a source of odd behavior across otherwise identical boards [14:27] NCommander, ok - I'll follow up [14:28] NCommander, give me an AR to track the HW difference of the suspend/resume regression [14:28] [action] ericm to track HW/SW differences across Dove revisions for suspend/resume regressions [14:28] ACTION received: ericm to track HW/SW differences across Dove revisions for suspend/resume regressions [14:28] done [14:28] Bug #541399, NCommander, it seems to be an issue of mkimage command line [14:28] Launchpad bug 541399 in linux-mvl-dove "netboot image fails to boot." [Medium,Triaged] https://launchpad.net/bugs/541399 [14:28] ericm: saw that one, on my TODO [14:28] incorrect setting of Load Address and Entry point, should be easy to fix [14:29] ericm: thanks for looking into it, I think that bug dates to initial dove bringup since that was the first thing we implemented and I guess at some point it stopped getting regularly tested [14:29] make sure that gets fixed immediately as we are now in Beta 2 and images are present for testing. [14:29] GrueMaster: I suspect the fix will land after B2; I'll talk to cjwatson if he's willing to upload d-i [14:29] Bug #530432, it's actually a kernel bug yet the proposed patch in upstream seems not acceptable at the moment [14:29] Launchpad bug 530432 in linux-mvl-dove "suspend with sd card inserted fails to suspend, hangs, and loses USB" [High,Confirmed] https://launchpad.net/bugs/530432 [14:30] Yes, that one spans architectures iirc. [14:30] I'd recommend we implement a hook to umount the card before suspending [14:30] at the moment, until there is a clean patch merged [14:31] Bug #457536, it seems to be fixed in latest ubiquity [14:31] Launchpad bug 457536 in ubuntu-meta "Dove install will fail without network access" [High,Fix released] https://launchpad.net/bugs/457536 [14:31] [action] ericm to continue working on SD card suspend issue [14:31] ACTION received: ericm to continue working on SD card suspend issue [14:31] yes, that was fixed. Tested yesterday. [14:31] maybe we can close it [14:31] um [14:32] there some other bugs maybe we can close, e.g. Bug #451553 [14:32] Launchpad bug 451553 in linux-mvl-dove "Lots of errors during install on dove" [Medium,Confirmed] https://launchpad.net/bugs/451553 [14:32] iirc the real fix for that was never implemented [14:32] see bug comments [14:32] speaking of 457536 that is [14:32] plars, it seems to be uboot-mkimage is absent, and need to get from network [14:32] ericm: plars: we had that fixed [14:32] Some of these bugs are in karmic and fixed in recent lucid images. [14:33] Meaning they will still exist in karmic. [14:33] plars, cjwatson has made ubiquity depend on that so should be there in the ISO by default, right? [14:33] iirc, it was worked around, but slangasek mentioned in the bug that there was a better way that it should be fixed [14:33] * NCommander thought we fixed it by putting uboot-mkimage in the ship seed [14:33] looks someone needs to follow this up [14:33] get an AR for someone, anyone? [14:33] see the last couple of comments [14:33] NCommander, we also need to take a look into karmic [14:34] the recommendation was to fix it in the recommends on the kernel image package [14:34] [action] ericm, plars, NCommander to investigate uboot-mkimage breakage and offline dove installation [14:34] ACTION received: ericm, plars, NCommander to investigate uboot-mkimage breakage and offline dove installation [14:34] NCommander, ok thanks [14:34] plars: its already a recommends of initramfs-tools/flash-kernel I think [14:35] let's move on, plars, GrueMaster, there might be other bugs we can close, e.g. Bug #451553 [14:35] Launchpad bug 451553 in linux-mvl-dove "Lots of errors during install on dove" [Medium,Confirmed] https://launchpad.net/bugs/451553 [14:35] hmm, is that the one with the double bit errors? [14:35] I still get screenfuls of those [14:36] plars, it seems to be the one with unalignment faults [14:36] plars, double bit errors are actually warning, and we don't care about NAND, do we? [14:36] ericm: not this cycle, but I'm hoping to have something w.r.t. to NAND based installing for 10.10 [14:36] Interestingly I do not see this on my dove. [14:36] * NCommander hasn't seen it on his X0 either [14:37] plars: it might be that you need to reinitialize your NAND flash [14:37] GrueMaster: you don't see the double bit errors? [14:37] no [14:37] GrueMaster, this happens randomly as it's totally depending on the content of the NAND already there [14:37] GrueMaster: they usually should up in the dmesg [14:37] interesting [14:37] [action] NCommander and plars to work together to reinitialize plars's NAND flash on his X0 [14:37] ACTION received: NCommander and plars to work together to reinitialize plars's NAND flash on his X0 [14:37] :-) [14:37] GrueMaster, NCommander, a clean NAND is supposed not to issue any such warnings [14:37] sounds good [14:37] NCommander, ok [14:38] * plars has a dirty nand :( [14:38] plars: I think we can knock that one down to wishlist at the very least, NAND is a very much "we don't care" thing rightnow [14:38] move on, the last item, I'm thinking of getting X0 support back into Karmic [14:38] or low [14:38] will do [14:38] ericm: that just needs a kernel SRU (and a custom image respin) [14:38] as Karmic is still in it's supporting phase, yet the change might be BIG, so we do need to do a careful regression [14:38] test [14:38] ericm: the userland support side is fine; I ran karmic on the X0 witout issue once I forced a new kernel on it [14:39] NCommander, cool - as long as plars, GrueMaster have some time to do a QA, I'm fine to push it right away [14:40] Maybe end of week/early next week. This is release week. [14:40] NCommander, give me an AR, and I'm done with the status update [14:40] ericm: I think we can accept it into proposed, and if need be, I can spin a custom image with it and stuff it on p.c.c [14:40] [action] ericm to drop X0 enablement into karmic-proposed [14:40] ACTION received: ericm to drop X0 enablement into karmic-proposed [14:40] ok [14:40] [topic] ARM Application status (JamieBennett, dyfet) [14:40] New Topic: ARM Application status (JamieBennett, dyfet) [14:41] erm, did you skip us? [14:41] webservice-office-zoho is waiting on new icons, other than that nothing much to report [14:41] There will also be a new blueprint for this for lucid+1 [14:41] And we may re-introduce canola2 then if it looks supportable [14:41] but otherwise, yes, not much to report [14:42] GrueMaster: whoops, sorry, Still not caffinated (ENOCOFFEE) [14:42] JamieBennett: dyfet anything else? [14:42] [topic] QA Status (GrueMaster, plars) [14:42] New Topic: QA Status (GrueMaster, plars) [14:42] er [14:42] whoops [14:43] no move on [14:44] Between 3/23 and 4/3, there were no new images to test due to gtk library respin. [14:44] My focus shifted to app testing and debugging pulse audio issues. [14:44] Along with kernel testing. [14:44] oh, I thought they weren't done [14:45] iso tracker is updated with milestone images [14:45] so we have begun testing on that [14:45] TI kernel has improved greatly [14:46] the omap image boots to netbook desktop, and all, but no usb at the moment [14:46] * GrueMaster has no Ti system to test with (yet). [14:46] working on getting that sorted out, may be able to hand build an image today that should work when my kernel compile completes [14:46] and the sound problems were discussed earlier [14:47] plars: GrueMaster anything else? [14:47] I sent a list of bugs to ogra and asac that need some attention. [14:48] GrueMaster: was that the one you cc'd me on? [14:48] yes [14:48] GrueMaster: right, planning to go through the list and make sure those are appropriately set wrt importance, milestone, etc. If you know of any that need immediate fixing though, let me konw [14:49] [topic] ARM Porting/FTBFS status (NCommander, dyfet) [14:49] New Topic: ARM Porting/FTBFS status (NCommander, dyfet) [14:49] I had worked on some strange ftbfs packages, including basilisk and condor, but they were not arm specific issues [14:49] The major visible one that I can think of is the maximus bug. Bug 528887 [14:49] Launchpad bug 528887 in maximus "maximus does not give default focus to newly started apps in combination with efl launcher" [Medium,Triaged] https://launchpad.net/bugs/528887 [14:49] oh,*grumble* [14:49] [topic] QA Status (GrueMaster, plars) [14:49] New Topic: QA Status (GrueMaster, plars) [14:50] * plars has a flashback [14:50] I'm done. [14:50] GrueMaster: hrm, on #52887, I don't think I've had that issue on Dove [14:51] yes [14:51] it does [14:51] * NCommander must be misremembering or is clicking automatically out of habit [14:51] anyone, can I move on? [14:51] yes [14:51] It is an issue on both. The easiest way to reproduce it is to click on the terminal icon and then try to type in the window once the prompt comes up. [14:52] move on, please. [14:52] * plars notes that zoho is now in the images and needs testing :) [14:52] [topic] ARM Porting/FTBFS status (NCommander, dyfet) [14:52] New Topic: ARM Porting/FTBFS status (NCommander, dyfet) [14:52] So. OOo is broken. Again. [14:52] * NCommander twiches [14:53] I think I just commented on this one :) feeling dejavu... [14:53] dyfet: it's going around [14:53] Looks like it *might* be a buildd issue with the new babbage 3 buildds; I had issues with building OOo on my Babbage 3 (I got quite a bit of hardware stability, but that was written up to faulty board) [14:53] s/stability/instability [14:54] lamont ran a test build on the old lange based buildds, and I have one going on jocote (I'll have one running on my Dove post-beta if the jocote build fails) [14:54] [action] NCommander to coordinate with lamont on determining if OOo build failure is HW specific [14:54] ACTION received: NCommander to coordinate with lamont on determining if OOo build failure is HW specific [14:55] dyfet: anything else to add? [14:55] * NCommander notes he's also working on a fix and improvement for Dove netboot images [14:55] Only what I did earlier, that I had been looking at other ftbfs packages not arm specific though [14:55] [topic] ARM Image Status (ogra, persia) [14:55] New Topic: ARM Image Status (ogra, persia) [14:56] plars: zoho stuff has a few fixes already sitting in my bzr branch waiting for icons [14:57] * NCommander pokes persia and ogasawara [14:57] er [14:57] * NCommander notes we lost ogra [14:57] We're almost out of time so moving on [14:57] [topic] Any Other Business [14:57] New Topic: Any Other Business [14:58] Well, not hearing from them, I can state that the image builds were essentially down for gtk respin which took quite a while. [14:58] server images are in poor shape. netbook images look up-to-date. [14:58] persia: define poor shape [14:58] Last updated 3/23 [14:58] * persia will investigate more [14:59] persia: we can look at fixing and debugging the dove ones for B2/RC [14:59] Right. [14:59] [action] persia and NCommander to test and improve server image experience [14:59] ACTION received: persia and NCommander to test and improve server image experience [14:59] anything else? [15:00] #endmeeting [15:00] Meeting finished at 09:00. [15:00] Goodnight folks! [15:00] (or goodday :-)) [15:00] o/ [15:00] \o [15:01] * kees goes looking for sabdfl and cjwatson [15:01] Keybuk, mdz: you guys unidled? [15:01] I am here [15:03] here [15:03] kees: hi [15:03] hi all [15:03] cjwatson: weird, tab-completion didn't find you a moment ago [15:03] ok [15:03] #startmeeting [15:03] Meeting started at 09:03. The chair is kees. [15:03] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:03] kees: stealth mode [15:03] [TOPIC] action review [15:03] New Topic: action review [15:04] [link] https://wiki.ubuntu.com/TechnicalBoardAgenda [15:04] LINK received: https://wiki.ubuntu.com/TechnicalBoardAgenda [15:04] Riddell: any news on the KDE Updates Policy? [15:05] kees: mm, sorry, not yet [15:05] it never quite reaches the top of my todo [15:06] is it delegatable? [15:06] not that I'm always one to talk [15:07] not sure, it needs someone with the will to do it and close ties to KDE [15:07] Riddell: assuming it stays with you, when should we ping again? [15:08] worth bringing up with other Kubuntu developers perhaps? [15:08] kees: after beta 2 probably good [15:09] Riddell: okay, next TB meeting then. what is the next specific action that needs to be taken? [15:09] cjwatson: I think it needs to be led by someone who's a KDE developer, upstream aren't too interested in being led by downstream for that [15:09] kees: tidy up the draft and get final approval from KDE [15:10] ok, I thought we had some KDE developers among kubuntu-dev though [15:10] could Scott Kitterman have a stab? this either needs to get done, or dropped from the TB list [15:11] he could yes [15:12] ScottK: will you have time in the next 2 weeks to tidy up the KDE updates draft, and get approval from KDE? [15:12] perhaps Riddell could take this offline as an action? [15:12] kees: I can tidy it up. Hard to predict "KDE approval" [15:13] ScottK: heh, true [15:13] [ACTION] Riddell and ScottK to sort next steps of KDE Updates process [15:13] ACTION received: Riddell and ScottK to sort next steps of KDE Updates process [15:13] "sabdfl to write up minutes from 2010-03-09 meeting, or delegate" [15:14] i didn't, and don't foresee being able to do so [15:14] anybody have a url for the log? [15:14] I can take that - just wanted to know I wasn't duplicating [15:14] ok thanks very much colin! [15:15] [ACTION] cjwatson to write up 2010-03-09 meeting minutes [15:15] ACTION received: cjwatson to write up 2010-03-09 meeting minutes [15:15] [TOPIC] community bugs (none) [15:15] New Topic: community bugs (none) [15:15] [TOPIC] new issues? [15:15] New Topic: new issues? [15:15] anything else? our agenda is rather empty this time. [15:15] 10.10? [15:16] our website says that the technical board sets the direction for each Ubuntu release [15:16] is libfaac a TB issue? [15:16] in practice, this is virtually all done by more specialized teams [15:17] mdz: what was done by TB for 10.04? [15:17] james_w: what's the issue? [15:17] kees: in my capacity on the TB, I nagged the engineering managers to publish their plans to mailing lists etc. [15:17] and to make their planning process transparent to the community [15:18] the results were sort of mixed, and I think we ought to do better this time [15:18] mdz: can you do that again? sounds like you've got a template for it. [15:19] kees: bug 374900: libfaac appears to be undistributable. This has been discussed on the TB list (more than once?), so I don't want to disrupt any discussion by acting as a member of ~ubuntu-archive. [15:19] Launchpad bug 374900 in faac "Libfaac not LGPL" [High,Triaged] https://launchpad.net/bugs/374900 [15:19] kees: I will talk to robbiew about it; he is managing the planning process [15:20] mdz: I was going to suggest robbiew too, but thought maybe you wanted specifically a TB member to do it. [15:20] in addition to asking people to be transparent, is there anything else the TB should be doing with regard to 10.10? [15:21] james_w: if action by ubuntu-archive is not straight-forward for libfacc, can you write up a plan that TB would need to act on? [15:22] kees: (agenda) I'm also interested in checking in with the DMB (via cjwatson) to understand how things are going with the new regime [15:22] mdz: well, the only technical-ish thing I can think of for 10.10 is that we have to remind people to keep an eye out for breakage as we open the floodgates on unstable imports/merges. coming off an LTS can be a bit jarring. [15:22] kees: that's backwards from what I understand is happening, I started discussion in ~ubuntu-archive and was told that the TB was discussing the issue, so I'm following up to see if that is the case, and seeing if we can have a decision before release. [15:23] james_w: this is the first I've heard of it, but that is likely a commentary on my memory. :P [15:23] james_w: that is not the case (wrong verb tense) [15:23] from the ML archives, sabdfl had the lead on that one [15:23] there was a discussion (https://lists.ubuntu.com/archives/technical-board/2010-March/000115.html) but it died out [15:23] sorry, yes, discussed [15:24] sabdfl: ? [15:24] i'm lookin' [15:24] kees: has anyone floated the question of continuing to merge from testing vs. going back to unstable? [15:25] mdz: I don't think so; I prefer syncing from unstable, so the idea didn't even cross my mind. [15:26] like, keeping that for future releases, or a post-mortem of the approach for lucid? [15:26] pitti: the latter, followed by the former [15:26] I also had assumed we'd go back to unstable, since the LTS plan in the wiki mentions that for LTSes only [15:26] it's one of those things that people always suggest that we do [15:26] and we have good reasons for not doing it [15:27] but we're in a unique position now of being able to evaluate and see what the real differences were [15:27] and how we can apply lessons learned to future releases [15:27] I don't claim to have hard data, but my gut feeling is that lucid has been quite stable throughout the cycle (except for the things which we deliberately broke, such as nouveau/plymouth/etc.) [15:28] pitti: that's my gut feeling as well, and my conjecture is that this probably improved overall productivity for developers [15:28] That's not been the case in some areas. SDL is a particular example where things went very wrong. [15:28] sorry, I had an annoying connection issue there [15:28] I don't think we can productively evaluate it here, but I think it would be a good exercise [15:29] If the intent is to pull from testing, it may well be worth indicating that pulling from experimental has higher risk than it did in the past. [15:29] sounds like we need a port-mortem of testing-sync first, and we can go from there. who would like to drive that? [15:30] w.r.t. libfaac, the main issue appears to be a question about whether we can ship some very old code that was developed as part of the ISO standardisation process [15:30] regarding maverick direction, my impression so far is that we have the start of a product vision (e.g. http://www.markshuttleworth.com/archives/336) and a number of specific plans among teams, but not a lot in the way of a technical overview yet [15:30] perhaps it's putting the cart before the horse to try to construct that before teams have done more of their planning - not sure [15:30] +1 to including it [15:30] kees: I guess this amounts to discussing it on u-devel@ and collecting the results? [15:30] kees: I'm happy to start this off [15:31] pitti: that was my thought as well [15:31] i think we should express a preference for, and willingness to move to, a reimplementation once one is available [15:31] [ACTION] pitti to kick off post-mortem of sync-from-testing on u-devel@ [15:31] ACTION received: pitti to kick off post-mortem of sync-from-testing on u-devel@ [15:31] It might be nice to have some explicit lessons learned sessions at UDS like we did in Barcelona. [15:31] james_w: so, you can close that bug, my reading of the copyright is that we *can* ship it [15:32] pitti: thank you [15:32] have we had a lawyer's opinion? [15:32] cjwatson: not afaik [15:32] I'm concerned that upstream has threatened to sue, per that TB thread [15:33] sabdfl: the original license is distributable, so fine for multiverse, however the modifications are LGPLv2, which is not compatible with a non-free license when compiled in to a single library in my understanding. [15:33] right, it's a combination issue not an individual-distributability issue [15:33] upstream> sorry, upstream ffmpeg [15:33] which would make the resulting package undistributable due to the combination of licenses. [15:34] yes, there's a question of if we ship it, and then if we do, the question of if we link ffmpeg to it. [15:34] .c [15:35] hmm.. .can it not be structured to keep the different bits separate? [15:35] i don't see any issue with modifying ffmpeg so as to autodetect and adapt to its presence [15:35] that's not violating any copyright [15:36] my read on the threat to sue was that it was not based on any substantive complaint [15:36] if that's the case, it seems to me that we should be discussing it with upstream ffmpeg rather than Just Doing It :-) [15:37] except, if they are not rational, there is not a lot of value in the discussion [15:37] sabdfl: that seems a large presumption before starting the discussion ... [15:37] and starting out a conversation with an indiscriminate threat to sue is very, Schilling [15:37] I believe that the ffmpeg complaint would depend on your interpretation of the linking restrictions in the GPL. [15:38] starting> well, actually, it seems that this is coming part-way through a discussion [15:38] and that it got forwarded to us at that point [15:38]