November 2008 - macports-tickets - lists.macosforge.org

Re: [MacPorts] #13879: mpeg4ip activation fails
by MacPorts 08 Nov '08

08 Nov '08

#13879: mpeg4ip activation fails --------------------------------------+------------------------------------- Reporter: yanjingfeng(a)hotmail.com | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: mpeg4ip | --------------------------------------+------------------------------------- Comment(by devans(a)macports.org) Well, faac doesn't work to replace mpeg4ip. Although both have versions of libmp4v2, the separate libmp4v2 distribution has additional functions that easytag and others need. But faac can be configured with a --without-mp4v2 switch in which case it builds fine against libmp4v2 (or mpeg4ip). Since libmp4v2 is reputed to be free of mpeg4ip's patent infringement issues, I suggest that it be used as a replacement for mpeg4ip and then build faac with the --without-mp4v2 option to avoid a conflict. Have created a new port libmp4v2 (committed in r41643) and updated easytag (committed in r41643) with good results. If faac and the others can be modified to use libmp4v2 (which is what they now seem to prefer) then mpeg4ip can be deleted. -- Ticket URL: <http://trac.macports.org/ticket/13879#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #4103: BUG: Ruby incompatibility /w non-MP openssl
by MacPorts 08 Nov '08

08 Nov '08

#4103: BUG: Ruby incompatibility /w non-MP openssl -----------------------------------+---------------------------------------- Reporter: purestorm(a)ggnore.net | Owner: kimuraw(a)macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: Resolution: | Keywords: Port: ruby | -----------------------------------+---------------------------------------- Comment(by kimuraw(a)macports.org) I cannot reproduce the problem with current MacPorts ruby 1.8.7-p72_2. * ruby and libruby not linking openssl * extention module openssl.bundle linking ${prefix}/lib/libssl,libcrypt {{{ % otool -L /opt/local/bin/ruby /opt/local/lib/libruby.1.8.7.dylib /opt/local/lib/ruby/1.8/i686-darwin9/openssl.bundle /opt/local/bin/ruby: /opt/local/lib/libruby.dylib (compatibility version 1.8.0, current version 1.8.7) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libruby.1.8.7.dylib: /opt/local/lib/libruby.dylib (compatibility version 1.8.0, current version 1.8.7) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1) /opt/local/lib/ruby/1.8/i686-darwin9/openssl.bundle: /opt/local/lib/libruby.dylib (compatibility version 1.8.0, current version 1.8.7) /opt/local/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) }}} -- Ticket URL: <http://trac.macports.org/ticket/4103#comment:13> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #13879: mpeg4ip activation fails
by MacPorts 08 Nov '08

08 Nov '08

#13879: mpeg4ip activation fails --------------------------------------+------------------------------------- Reporter: yanjingfeng(a)hotmail.com | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: mpeg4ip | --------------------------------------+------------------------------------- Comment(by devans(a)macports.org) Referring to the homepages for aacgain, cmus and easytag all claim to be dependent now on libmp4v2, a subset of the functionality of mpeg4ip which avoids potential patent problems with the full mpeg4ip. It is available here: [http://resare.com/libmp4v2] However, it appears that port faac comes with libmp4v2 embedded which is the reason for the conflict. It looks possible that the solution is to get rid of port mpeg4ip and have the ports that currently depend upon it depend upon faac instead. I'm going to try this with easytag which currently has no maintainer and see if this works. -- Ticket URL: <http://trac.macports.org/ticket/13879#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #12914: "cd" TCL procedure should not be used in Portfiles anymore
by MacPorts 07 Nov '08

07 Nov '08

#12914: "cd" TCL procedure should not be used in Portfiles anymore -------------------------------+-------------------------------------------- Reporter: nox(a)macports.org | Owner: ryandesign(a)macports.org Type: defect | Status: new Priority: High | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: | -------------------------------+-------------------------------------------- Comment(by markd(a)macports.org) These ports are false positives because 'cd' is used within ui_msg statements: net/monarch net/nagios net/nedi net/netmrg net/network-weathermap net/nrg net/rancid net/smokeping net/zabbix -- Ticket URL: <http://trac.macports.org/ticket/12914#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

[MacPorts] #17125: new port for libemf
by MacPorts 07 Nov '08

07 Nov '08

#17125: new port for libemf -------------------------------+-------------------------------------------- Reporter: jjstickel(a)vcn.com | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Submissions Component: ports | Version: 1.6.0 Keywords: libemf pstoedit | Port: -------------------------------+-------------------------------------------- Here is a new port for libemf, needed to allow pstoedit to convert to enhanced metafile format. Perhaps this should be made a dependency for pstoedit. -- Ticket URL: <http://trac.macports.org/ticket/17125> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

Re: [MacPorts] #13879: mpeg4ip activation fails
by MacPorts 07 Nov '08

07 Nov '08

#13879: mpeg4ip activation fails --------------------------------------+------------------------------------- Reporter: yanjingfeng(a)hotmail.com | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: mpeg4ip | --------------------------------------+------------------------------------- Changes (by devans(a)macports.org) * cc: milosh(a)macports.org, bytestorm(a)gmail.com (added) Comment: The following ports also have variants that depend on mpeg4ip: {{{ cmus +aac easytag +mp4 easytag-devel +mp4 }}} Cc'ing their maintainers as well. -- Ticket URL: <http://trac.macports.org/ticket/13879#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #9420: Carbon XEmacs is infringing various copyrights
by MacPorts 07 Nov '08

07 Nov '08

#9420: Carbon XEmacs is infringing various copyrights ---------------------------------+------------------------------------------ Reporter: stephen(a)xemacs.org | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: High | Milestone: Port Bugs Component: ports | Version: Resolution: | Keywords: carbon Port: xemacs | ---------------------------------+------------------------------------------ Changes (by devans(a)macports.org) * keywords: => carbon * port: => xemacs Old description: > I wish to bring to your attention the fact that Andrew Choi has removed > the GPL permissions notice and the copyright notices of the original > authors from the file src/carbon-console.c. A comment by Choi says that > "All functions in this file are taken from console-qt.cpp", so this is > clearly in violation of the terms of the GPL. Although the authors have > so far declined to take action, they have not yet granted Choi any > license other than the GPL. Choi has been notified of the problem and > has twice refused to put the notices in the file. > > I ask that you restore the notice to the file in your distribution, > either by patch or in a separate README. The GPL boilerplate can be > copied from any of the other source files, or simply referred to briefly. > The deleted copyright notice is > > Copyright (C) 1996 Ben Wing. > > Note that the following authorship is given on console-qt.cpp. > > Ben Wing: January 1996, for 19.14. > Sam Magnuson: April 2002, for 21.5 (Qt version) > > This probably means that Sam Magnuson, who was a TrollTech employee, has > copyright in that file, and therefore in src/console-carbon.c. We have > not yet contacted Magnuson or TrollTech to determine their legal interest > or attitude toward Choi's deliberate infringement. > > Upon request, I will provide a copy of console-qt.cpp, or you can check > out the DEV_QT branch of XEmacs from XEmacs CVS. > > I would also like to provide the following context. > > It is my belief as a non-lawyer with substantial interest in intellectual > property law as it applies to open source that a substantial majority of > the Carbon XEmacs port by Choi is derivative of code that he copied from > other parts of the XEmacs sources. That is not a threat, or anything > like it; I simply want to bring it to your attention that Choi's code > uses the "object-oriented" macros developed by Ben Wing (and possibly > others) throughout, and therefore is arguably derivative. None of the > files Choi has added bear the copyright notices or GPL permissions > notices that are required if my interpretation is correct. > > Please do not consider this a "demand" or a "threat". At present the > XEmacs Review Board (the project's governing body, a self-selected cabal > of core developers; nonetheless, membership is fairly open and we > regularly add new members) trying to find a way to satisfy both our > obligations to our copyright holders who have licensed their code to us > under the GPL, and Choi's desire to put no restrictions whatsoever on his > code. Although we are all sympathetic in greater or lesser degree to > Choi's opposition to copyleft licenses, the largest block of our > copyright is held by the Free Software Foundation. Thus we have to be > very careful to dot i's and cross t's---that is why we have not > incorporated Choi's code into the mainline of XEmacs yet. > > We have found no way to legally include his code "as is" (ie, without > restoring the GPL to the code we add to XEmacs), but he has publicly and > privately bashed us for following the law as we understand it, even > though we added notices that his code is public domain, and provided > verbatim copies of his patches under his permissions notices. So we are > currently at an impasse. > > The main copyright holder in the code that Choi has clearly copied is Ben > Wing. Ben is currently reserving judgment. His stated desire is to > maximize distribution of both his code and Choi's code, as long as his > role in creating the code is acknowledged. It is my belief that > downstream distributors of Choi's code are at no risk of legal action by > XEmacs, and because Ben holds the known relevant copyrights the FSF > (which might be more aggressive) has no standing. New description: I wish to bring to your attention the fact that Andrew Choi has removed the GPL permissions notice and the copyright notices of the original authors from the file src/carbon-console.c. A comment by Choi says that "All functions in this file are taken from console-qt.cpp", so this is clearly in violation of the terms of the GPL. Although the authors have so far declined to take action, they have not yet granted Choi any license other than the GPL. Choi has been notified of the problem and has twice refused to put the notices in the file. I ask that you restore the notice to the file in your distribution, either by patch or in a separate README. The GPL boilerplate can be copied from any of the other source files, or simply referred to briefly. The deleted copyright notice is Copyright (C) 1996 Ben Wing. Note that the following authorship is given on console-qt.cpp. Ben Wing: January 1996, for 19.14. Sam Magnuson: April 2002, for 21.5 (Qt version) This probably means that Sam Magnuson, who was a TrollTech employee, has copyright in that file, and therefore in src/console-carbon.c. We have not yet contacted Magnuson or TrollTech to determine their legal interest or attitude toward Choi's deliberate infringement. Upon request, I will provide a copy of console-qt.cpp, or you can check out the DEV_QT branch of XEmacs from XEmacs CVS. I would also like to provide the following context. It is my belief as a non-lawyer with substantial interest in intellectual property law as it applies to open source that a substantial majority of the Carbon XEmacs port by Choi is derivative of code that he copied from other parts of the XEmacs sources. That is not a threat, or anything like it; I simply want to bring it to your attention that Choi's code uses the "object-oriented" macros developed by Ben Wing (and possibly others) throughout, and therefore is arguably derivative. None of the files Choi has added bear the copyright notices or GPL permissions notices that are required if my interpretation is correct. Please do not consider this a "demand" or a "threat". At present the XEmacs Review Board (the project's governing body, a self-selected cabal of core developers; nonetheless, membership is fairly open and we regularly add new members) trying to find a way to satisfy both our obligations to our copyright holders who have licensed their code to us under the GPL, and Choi's desire to put no restrictions whatsoever on his code. Although we are all sympathetic in greater or lesser degree to Choi's opposition to copyleft licenses, the largest block of our copyright is held by the Free Software Foundation. Thus we have to be very careful to dot i's and cross t's---that is why we have not incorporated Choi's code into the mainline of XEmacs yet. We have found no way to legally include his code "as is" (ie, without restoring the GPL to the code we add to XEmacs), but he has publicly and privately bashed us for following the law as we understand it, even though we added notices that his code is public domain, and provided verbatim copies of his patches under his permissions notices. So we are currently at an impasse. The main copyright holder in the code that Choi has clearly copied is Ben Wing. Ben is currently reserving judgment. His stated desire is to maximize distribution of both his code and Choi's code, as long as his role in creating the code is acknowledged. It is my belief that downstream distributors of Choi's code are at no risk of legal action by XEmacs, and because Ben holds the known relevant copyrights the FSF (which might be more aggressive) has no standing. -- Comment: I think this is no longer an issue as the carbon variant (and thus the offending code) has been removed from xemacs. Port description clearly indicates that GPL applies. Can this be closed? -- Ticket URL: <http://trac.macports.org/ticket/9420#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #13879: mpeg4ip activation fails
by MacPorts 07 Nov '08

07 Nov '08

#13879: mpeg4ip activation fails --------------------------------------+------------------------------------- Reporter: yanjingfeng(a)hotmail.com | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: mpeg4ip | --------------------------------------+------------------------------------- Changes (by blb(a)macports.org) * cc: tristan(a)cs.dartmouth.edu (added) Comment: Replying to [comment:5 devans@…]: > Actually their download page [http://mpeg4ip.sourceforge.net/downloads/index.php] says the current tar ball is corrupt and they can't regenerate it. I > vote to delete the port. I agree, however, aacgain appears to depend on it currently, so that will have to be updated to use an alternative if possible. Cc'ing aacgain's maintainer. -- Ticket URL: <http://trac.macports.org/ticket/13879#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

[MacPorts] #17122: sqlite3 3.6.4 - build fails while attempting to pipe into -f
by MacPorts 07 Nov '08

07 Nov '08

#17122: sqlite3 3.6.4 - build fails while attempting to pipe into -f -----------------------------------+---------------------------------------- Reporter: harry.weppner(a)gmx.net | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Low | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: sqlite3 -----------------------------------+---------------------------------------- {{{ ---> Building sqlite3 with target all Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_sqlite3/work/sqlite-3.6.4" && gnumake all " returned error 2 Command output: sort -n -b -k 3 opcodes.h | -f ./mkopcodec.awk >opcodes.c /bin/sh: -f: command not found gnumake: *** [opcodes.c] Error 127 }}} Something's off with the make script as it forgets to insert an appropriate command in the pipe. The weird thing is that I reattempted to install a short while later and it worked!? Cheerio, Harry. -- Ticket URL: <http://trac.macports.org/ticket/17122> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

Re: [MacPorts] #13930: Intermittent failures building Python modules: unable to execute -DNDEBUG
by MacPorts 07 Nov '08

07 Nov '08

#13930: Intermittent failures building Python modules: unable to execute -DNDEBUG ----------------------------+----------------------------------------------- Reporter: wiml(a)hhhh.org | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: closed Priority: Normal | Milestone: MacPorts 1.7.0 Component: base | Version: 1.6.0 Resolution: fixed | Keywords: Port: | ----------------------------+----------------------------------------------- Comment(by blb(a)macports.org) Replying to [comment:33 afb@…]: > Were you able to actually add it to the test case too ? Test case for this added in r41638. The issue where {{{info exists env(somevar)}}} returned true even after {{{unsetenv somevar}}} fixed in r41639. -- Ticket URL: <http://trac.macports.org/ticket/13930#comment:34> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0