Re: new mplayer 1.0pre7try2 package
On Sat, Jan 21, 2006 at 04:07:51PM +1000, Andrew Pollock wrote: On Sat, Jan 21, 2006 at 06:06:36AM +1000, Anthony Towns wrote: On Fri, Jan 20, 2006 at 12:08:39PM -0500, Nathanael Nerode wrote: aj@azure.humbug.org.au wrote: mplayer has had an explicit warning from upstream that it's patented; The proposed tarball for Debian has stuff excised left and right in order to guarantee legality. Just check that the patented stuff was excised, right? If you can demonstrate that there's nothing in there that's potentially patented, sure. That seems pretty unlikely, though. Aren't we in a similar situation with other stuff that is in main already? rsync springs to mind. The rsync related patents are, ttbomk, limited to syncing in a different manner to what rsync actually does, though rproxy or librsync might be affected. There are also prior art issues, and whether the rsync suite of programs is actually covered in the first place. The idea is to get an idea of what the patent claims are, to see how related they are, and to see whether the owner of the patent actually cares; not to prove beyond a doubt there's no possibility of any patent infringement. Though if you can do the latter, that's obviously good too. Cheers, aj signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
Andrew writes: Aren't we in a similar situation with other stuff that is in main already? rsync springs to mind. Don't forget the Linux kernel. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
Nathanael Nerode [EMAIL PROTECTED] writes: aj@azure.humbug.org.au: [...] Contrast rte, where the ftpmasters told Marillat exactly what he needed to remove to get the package in Debian, and he didn't do it, and declared that he would keep uploading it. Leaving *that* in limbo is totally reasonable. I've *never* received any e-mail saying that. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
On 10540 March 1977, Christian Marillat wrote: Contrast rte, where the ftpmasters told Marillat exactly what he needed to remove to get the package in Debian, and he didn't do it, and declared that he would keep uploading it. Leaving *that* in limbo is totally reasonable. I've *never* received any e-mail saying that. Right, you've got a list of reasons why it got rejected and half of that is still true. -- bye Joerg liw I'm kinky and perverse, but my illness is laziness -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
I wrote: Contrast rte, where the ftpmasters told Marillat exactly what he needed to remove to get the package in Debian, and he didn't do it, and declared that he would keep uploading it. Leaving *that* in limbo is totally reasonable. Christian Marillat wrote: I've *never* received any e-mail saying that. Perhaps I have misinterpreted the following message from the bug trail to bug 112699: From: Joerg Jaspert [EMAIL PROTECTED] To: Christian Marillat [EMAIL PROTECTED] Cc: Joerg Jaspert [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: rte_0.4-0.0_i386.changes REJECTED Date: Sat, 19 Mar 2005 14:32:55 +0100 On 10233 March 1977, Christian Marillat wrote: Yes, this is the reject of the rte package which was in NEW until now. Reasons: - It is an encoding thing, which encodes to formats which are patented, and the patent holder are actually enforcing their patents. Found some hits for this with a little question to google. Are you serious ? We have ffmpeg (and soon mencoder in the mplayer package)in Debian who does exactly what rte does and rte can't enter Debian ? ffmpeg should be removed then. Yes, ffmpeg encoding stuff shouldnt be there, and no, mplayer wont get in with mencoder included. I already talked with upstream about it, he will talk with Debian maintainer to exclude this thing, before we take a closer look at it. If this reasons are no longer true in the future feel free to re-upload it, but for now it is out. Done. I've uploaded 0.5.6-1 As written above: ENCODING is still an issue and therefore at least one reason is still true. So dont hope too much it will get through. -- bye Joerg Die d??mmsten H??hne haben die dicksten Eier. I read this as remove MPEG encoding and it will go in. Don't you? -- Nathanael Nerode [EMAIL PROTECTED] Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
Joerg Jaspert [EMAIL PROTECTED] writes: On 10540 March 1977, Christian Marillat wrote: Contrast rte, where the ftpmasters told Marillat exactly what he needed to remove to get the package in Debian, and he didn't do it, and declared that he would keep uploading it. Leaving *that* in limbo is totally reasonable. I've *never* received any e-mail saying that. Right, you've got a list of reasons why it got rejected and half of that is still true. I still don't see why rte can't enter in main, when ffmpeg is already in main and does the same. For the record rte is an mpeg encoder. Now from the ffmpeg package 0.cvs20050918-5.1 I see : , | $ ffmpeg -formats | grep -i mpeg | ffmpeg version CVS, build 3276800, Copyright (c) 2000-2004 Fabrice Bellard | configuration: --build i486-linux-gnu --enable-gpl --enable-pp --enable-zlib --enable-vorbis --enable-libogg --enable-theora --enable-a52 --enable-dts --enable-dc1394 --enable-libgsm --disable-debug --prefix=/usr | built on Jan 17 2006 23:46:35, gcc: 4.0.3 20060115 (prerelease) (Debian 4.0.2-7) | E dvd MPEG2 PS format (DVD VOB) | DE m4v raw MPEG4 video format | D mov,mp4,m4a,3gp,3g2 QuickTime/MPEG4 format | E mp2 MPEG audio layer 2 | D mp3 MPEG audio | DE mpegMPEG1 System format | E mpeg1video MPEG video | E mpeg2video MPEG2 video | DE mpegts MPEG2 transport stream format | D mpegvideo MPEG video | E svcdMPEG2 PS format (VOB) | E vcd MPEG1 System format (VCD) | E vob MPEG2 PS format (VOB) | DE yuv4mpegpipeYUV4MPEG pipe format | DEVSDT mpeg1video | DEVSDT mpeg2video | DEVSDT mpeg4 | D VSDT mpegvideo | DEVSD msmpeg4 | DEVSD msmpeg4v1 | DEVSD msmpeg4v2 ` D is for Decoding and E is for Encoding, so ffmpeg can encode in mpeg1video and mpeg2video. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
aj@azure.humbug.org.au wrote: mplayer has had an explicit warning from upstream that it's patented; The proposed tarball for Debian has stuff excised left and right in order to guarantee legality. Just check that the patented stuff was excised, right? Alternatively, I would be quite happy with the response We just can't trust mplayer's upstream enough to include mplayer; we suspect them of having done something underhanded and including illegal code we haven't spotted. ffmpeg has an explicit document in its packaging indiciating it's okay. A, the I stripped the patented parts comment in README.Debian. All right. Sorry! So, we have a solid summary, which could be a FAQ answer: mplayer should go in if it links to the ffmpeg library in Debian, and its own copies of any mp3 and AAC encoding stuff are removed. Right? Likewise xvidcap, I presume? And rte, as was already stated? (And sorry for not giving credit to Joerg there!) -- Nathanael Nerode [EMAIL PROTECTED] (Instead, we front-load the flamewars and grudges in the interest of efficiency.) --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
On 10540 March 1977, Christian Marillat wrote: Right, you've got a list of reasons why it got rejected and half of that is still true. I still don't see why rte can't enter in main, when ffmpeg is already in main and does the same. Two bads doesnt make one good, so we stay with one bad. Or Just because foo killed bar you dont go and kill baz. -- bye Joerg [EMAIL PROTECTED] Windows ME? Mit 13? Kann der nicht lieber Drogen nehmen wie andere Kinder in dem Alter? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
On Fri, 2006-01-20 at 22:29 +0100, Joerg Jaspert wrote: On 10540 March 1977, Christian Marillat wrote: Right, you've got a list of reasons why it got rejected and half of that is still true. I still don't see why rte can't enter in main, when ffmpeg is already in main and does the same. Two bads doesnt make one good, so we stay with one bad. Or Just because foo killed bar you dont go and kill baz. Sure it does, if you don't get punished for it. Other relevant phrases are precedent (for all the Progressives worried that Alito will turn the US into a fascist theocracy) and slippery slope (for Republicans remembering Sliding Towards Gomorrah). -- - Ron Johnson, Jr. Jefferson, LA USA A C program is like a fast dance on a newly waxed dance floor by people carrying razors. Waldi Ravens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
On Fri, Jan 20, 2006 at 12:08:39PM -0500, Nathanael Nerode wrote: aj@azure.humbug.org.au wrote: mplayer has had an explicit warning from upstream that it's patented; The proposed tarball for Debian has stuff excised left and right in order to guarantee legality. Just check that the patented stuff was excised, right? If you can demonstrate that there's nothing in there that's potentially patented, sure. That seems pretty unlikely, though. mplayer should go in if it links to the ffmpeg library in Debian, and its own copies of any mp3 and AAC encoding stuff are removed. Right? No, we have real problems with video codec stuff in Debian and they need to be resolved thoroughly, not expediently. Cheers, aj signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
On Sat, Jan 21, 2006 at 06:06:36AM +1000, Anthony Towns wrote: On Fri, Jan 20, 2006 at 12:08:39PM -0500, Nathanael Nerode wrote: aj@azure.humbug.org.au wrote: mplayer has had an explicit warning from upstream that it's patented; The proposed tarball for Debian has stuff excised left and right in order to guarantee legality. Just check that the patented stuff was excised, right? If you can demonstrate that there's nothing in there that's potentially patented, sure. That seems pretty unlikely, though. Aren't we in a similar situation with other stuff that is in main already? rsync springs to mind. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
* Anthony Towns aj@azure.humbug.org.au [2006-01-21 06:06:36]: No, we have real problems with video codec stuff in Debian and they need to be resolved thoroughly, not expediently. i was under the impression that the ftp-master team had started to work on that several month ago, shortly before the last mention of this on [EMAIL PROTECTED] is that the case? signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
[Eric Dorland] This has probably been covered ad nauseum, but where do we stand in respect to getting mplayer in Debian? [Nathanael Nerode] IIRC, the copyright issues were carefully worked out and solved after several years, finally reaching the approval of debian-legal. At which point it went into the NEW queue, to be silently ignored forever by the ftpmasters with no explanation. This is becoming an increasingly frequently asked question. What about making a wiki page explaining the status with links to the debian-legal thread and other relevant info? This way we would point people there to read the answer, and hopefully the ftpmasters might find useful information there too when they find time to make a decision? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
On Thu, Jan 19, 2006 at 11:08:42AM +0100, Petter Reinholdtsen wrote: [Eric Dorland] This has probably been covered ad nauseum, but where do we stand in respect to getting mplayer in Debian? [Nathanael Nerode] IIRC, the copyright issues were carefully worked out and solved after several years, finally reaching the approval of debian-legal. At which point it went into the NEW queue, to be silently ignored forever by the ftpmasters with no explanation. This is becoming an increasingly frequently asked question. What about making a wiki page explaining the status with links to the debian-legal thread and other relevant info? MJ Ray's already done such a summary; it's rather trivially inadequate, due to the information its summarising being equally inadequate. http://lists.debian.org/debian-devel/2005/12/msg00901.html This way we would point people there to read the answer, and hopefully the ftpmasters might find useful information there too when they find time to make a decision? Coming to a decision on inadequate information isn't particularly clever. Seriously, if you want something useful to happen about this, *thoroughly* investigate what's actually going on, with an open mind about the possibility of coming to the conclusion that, eg, it's just too much of a risk to include mplayer in Debian. Cheers, aj signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
aj@azure.humbug.org.au: MJ Ray's already done such a summary; it's rather trivially inadequate, due to the information its summarising being equally inadequate. http://lists.debian.org/debian-devel/2005/12/msg00901.html So the summary amounts to patents. Is that right? In other words, the previous (substantial) copyright issues *are* considered to be cleared up. Having it REJECTed with a needs to have algorithms covered by actively enforced patents identified and removed would be really helpful. Having a list of specific areas which are considered too dangerous (ffmpeg code, for instance) would be even better. Coming to a decision on inadequate information isn't particularly clever. Clever isn't the issue. I couldn't care less how clever the ftpmasters are. Too clever by half, perhaps, with the leave difficult packages in limbo policy. Coming to a decision on inadequate information is actually very helpful, when it's done in the form of This is the information we need before we can consider this package. I haven't seen that. Contrast rte, where the ftpmasters told Marillat exactly what he needed to remove to get the package in Debian, and he didn't do it, and declared that he would keep uploading it. Leaving *that* in limbo is totally reasonable. Seriously, if you want something useful to happen about this, *thoroughly* investigate what's actually going on, with an open mind about the possibility of coming to the conclusion that, eg, it's just too much of a risk to include mplayer in Debian. Hey, sure. Why is it too much of a risk? Can we get some background here? Originally it was too much of a risk because upstream was really bad about copyrights -- this was a FAQ. Like I said, some people spent literally years straightening that out. Hence the what the hell is wrong now? attitude. If it really is FFMPEG patent issues -- and I have no idea whether it is -- then I believe the packagers would be happy to just remove that code, because what some might call a crippled mplayer is still better than no mplayer. Incidentally, the current attitude of we won't include new packages with FFMPEG, but we will include FFMPEG is legally stupid. It doesn't get you anything if you do get sued; if anything, it helps prove that you knew you had a problem, and so were wilfully infringing. If this is really the issue, we should kick out the existing FFMPEG packages (and I'm happy to file the serious bugs, if that will get things started). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
Apologies to AJ and the ftpmasters. I found the *important* part of the thread, which I'd apparently missed during December, in which the ftpmasters... drumroll explain what would be needed for mplayer to go into Debian now, barring finding additional problems. Congrats Jeroen van Wolfellaar, ftpmaster extraordinare, not afraid to take on the difficult cases (he also managed the REJECT on rte IRRC). From http://lists.debian.org/debian-devel/2005/12/msg00888.html: (Jeroen) Basicly: Drop mpeg encoding from mplayer source package - definitely less problems getting through NEW. ... I suggest you upload stripping all the mpeg encoding stuff, pending answer to that difficult question. However, what you do, is your choice -- if you prefer to wait and are not planning to strip mpeg encoding support out of the source package, that's not something the ftp-master team will have any say on. ... I'm not aware of any fundamental reason why mplayer couldn't be in Debian. ... However, removing encoding stuff would bypass the main problem that we have with mplayer right now, and then the answer to this question can then be researched in parallel to an mplayer-with-only-mpeg-decoding being available from Debian. ... (A Menucc) 3) what other problems should we fix ? (please read http://people.debian.org/~mjr/legal/mplayer.html to know what has been already fixed ) (Jeroen) I don't know of any at this moment, but I also cannot promise there won't be any more problems that need fixing found between now and the package being checked in the NEW queue. And to reiterate: If Debian wants to be legally safe w.r.t. mpeg encoder patents, removing some mpeg encoders and not others -- when the others have been pointed out -- is really a bad idea. They should all be removed until the issue is settled one way or another. I see no way that leaving some in while excluding others for patent reasons is going to help Debian; if anything it can only make Debian's legal situation worse, because it can be used as evidence that Debian knew about the problems but left the patent-covered code in Debian. Which gets you the extra penalties for wilful infringement. Is there an objection, or shall I file a serious bug against ffmpeg?
Re: new mplayer 1.0pre7try2 package
On 10539 March 1977, Nathanael Nerode wrote: Congrats Jeroen van Wolfellaar, ftpmaster extraordinare, not afraid to take on the difficult cases (he also managed the REJECT on rte IRRC). Nope, he didnt reject rte. -- bye Joerg 16. What should you do if a security bug is discovered in one of your packages? 1) Notify [EMAIL PROTECTED] ASAP. 2) Notify upstream. 3) Try to create a patch. 4) Find out that Joey was faster. [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
On Jan 19, Nathanael Nerode [EMAIL PROTECTED] wrote: Is there an objection, or shall I file a serious bug against ffmpeg? Yes, I object to asking for removal of MPEG encoders because there is no good reason to do it. -- ciao, Marco signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
Le jeudi 19 janvier 2006 à 15:15 -0500, Nathanael Nerode a écrit : Is there an objection, or shall I file a serious bug against ffmpeg? The ffmpeg package doesn't include any faad, mp3, or other encoders for which patents are actively enforced. Therefore there is no reason to remove it from main. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: new mplayer 1.0pre7try2 package
On Thu, Jan 19, 2006 at 03:15:46PM -0500, Nathanael Nerode wrote: And to reiterate: If Debian wants to be legally safe w.r.t. mpeg encoder patents, removing some mpeg encoders and not others -- when the others have been pointed out -- is really a bad idea. Nathanael, stop trying to make decisions on inadequate information and pressuring others into adopting them. They should all be removed until the issue is settled one way or another. I see no way that leaving some in while excluding others for patent reasons is going to help Debian; if anything it can only make Debian's legal situation worse, because it can be used as evidence that Debian knew about the problems but left the patent-covered code in Debian. Which gets you the extra penalties for wilful infringement. mplayer has had an explicit warning from upstream that it's patented; ffmpeg has an explicit document in its packaging indiciating it's okay. If you want to get /actual legal advice/ for us, that would be great. Is there an objection, or shall I file a serious bug against ffmpeg? If you have actual information on why ffmpeg shouldn't be in main that's great. If you're just playing the ffmpeg and mplayer should be treated the same, but I don't know how they should be treated game, leave it alone. Cheers, aj signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
Eric Dorland [EMAIL PROTECTED] wrote: This has probably been covered ad nauseum, but where do we stand in respect to getting mplayer in Debian? IIRC, the copyright issues were carefully worked out and solved after several years, finally reaching the approval of debian-legal. At which point it went into the NEW queue, to be silently ignored forever by the ftpmasters with no explanation. You know where to bitch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
new mplayer 1.0pre7try2 package
hi everybody a new version of mplayer 1.0pre7try2 is available ; add either for the etch version, the line deb http://tonelli.sns.it/pub/mplayer/etch ./ or for the sarge version, the line deb http://tonelli.sns.it/pub/mplayer/sarge ./ to /etc/apt/source.list . a. signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
* A Mennucc ([EMAIL PROTECTED]) wrote: hi everybody a new version of mplayer 1.0pre7try2 is available ; add either for the etch version, the line deb http://tonelli.sns.it/pub/mplayer/etch ./ or for the sarge version, the line deb http://tonelli.sns.it/pub/mplayer/sarge ./ to /etc/apt/source.list . This has probably been covered ad nauseum, but where do we stand in respect to getting mplayer in Debian? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
On Mon, Jan 16, 2006 at 06:27:40PM +0100, A Mennucc wrote: hi everybody a new version of mplayer 1.0pre7try2 is available ; add either for the etch version, the line deb http://tonelli.sns.it/pub/mplayer/etch ./ or for the sarge version, the line deb http://tonelli.sns.it/pub/mplayer/sarge ./ to /etc/apt/source.list . Interesting... For a proposed-to-go-into-Debian-archive-build, there's no sid version? -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpM32BJIqp8H.pgp Description: PGP signature
Re: new mplayer 1.0pre7try2 package
A Mennucc wrote: hi everybody a new version of mplayer 1.0pre7try2 is available ; add either for the etch version, the line deb http://tonelli.sns.it/pub/mplayer/etch ./ Hi! Now we have mplayer in this repositories: http://tonelli.sns.it/pub/mplayer/etch ftp://ftp.nerim.net/debian-marillat/ http://apt.cerkinfo.be ...and probably in more. This could confuse users and lead to dependency problems. Solution is to have only one repository for every piece of software that can't be packaged in debian (i.e. non DFSG-free software and software with patent problems). There is already such a repository, with lots of packages: http://debian-unofficial.org/ Could you, or someone else, put mplayer (and xvidcap, rte,...) there, and notify people that run other repositories with mplayer to remove it or help you to maintain it? Regards, Vedran Furač
