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

[MacPorts] #15514: reinplace should warn if nothing got replaced
by MacPorts 30 Aug '14

30 Aug '14

#15514: reinplace should warn if nothing got replaced -------------------------------------+-------------------------------------- Reporter: ryandesign(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: base | Version: 1.6.0 Keywords: | -------------------------------------+-------------------------------------- What's always bugged me about reinplace is that you get no notification if nothing got replaced, which will probably bite you later. If you use a patchfile to modify a file, and the patch is out of date, the patch fails to apply and the port command exits with an error. This is good; it alerts the port author to the situation and they can fix it by changing or removing the patch. But with reinplace, if the underlying file you're modifying has changed such that the reinplace no longer causes anything to change, you get no warning and the port command proceeds. I think the correct behavior might ultimately be to error out entirely if a reinplace doesn't change a file, just like we do with failed patches. But as a first step, to get port authors used to this change, it might be friendlier to just print a warning for now. The attached patch adds a warning if a reinplace doesn't change the underlying file. -- Ticket URL: <http://trac.macports.org/ticket/15514> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 19

[MacPorts] #22819: Unladen Swallow
by MacPorts 28 Aug '14

28 Aug '14

#22819: Unladen Swallow ---------------------------------------------+------------------------------ Reporter: anand.prabhakar.patil@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: ---------------------------------------------+------------------------------ Would it be possible to make a port of Unladen Swallow, http://code.google.com/p/unladen-swallow/ ? Thanks very much, Anand -- Ticket URL: <http://trac.macports.org/ticket/22819> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #17455: mplayer doesn't build universal
by MacPorts 26 Aug '14

26 Aug '14

#17455: mplayer doesn't build universal -----------------------------------+---------------------------------------- Reporter: jeremyhu@… | Owner: ecronin@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: MPlayer -----------------------------------+---------------------------------------- configure complains about unknown arg: --disable-dependency-tracking ... deleting this from configure.args results in a single-platform binary -- Ticket URL: <http://trac.macports.org/ticket/17455> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #17799: mplayer @1.0rc2 No OSD/subtitle font after installation
by MacPorts 26 Aug '14

26 Aug '14

#17799: mplayer @1.0rc2 No OSD/subtitle font after installation -----------------------------------------+---------------------------------- Reporter: shreevatsa.public@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.7.0 Keywords: | Port: mplayer -----------------------------------------+---------------------------------- After installing mplayer, there is no OSD font by default: can't see subtitles, volume, position, etc. [Yes, I did install it with osd variant (#14864) although that should probably be default anyway.] Fix: Copy or symlink a ttf font into $PREFIX/share/mplayer/subfont.ttf as per http://www.mplayerhq.hu/DOCS/HTML/en/fonts-osd.html Not attaching a patch because my choice of font may not be best :) [I think /Library/Fonts/Arial.ttf is a good choice, but any of the fonts from http://en.wikipedia.org/wiki/List_of_fonts_in_Mac_OS_X which are distributed as .ttf should be fine, or Macports might want to distribute its own font specifically for Mplayer.] -- Ticket URL: <http://trac.macports.org/ticket/17799> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #25554: Dillo port is very old
by MacPorts 26 Aug '14

26 Aug '14

#25554: Dillo port is very old --------------------------------+------------------------------------------- Reporter: perry@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Keywords: | Port: dillo --------------------------------+------------------------------------------- Dillo 2.2 is now out, and the highest version in ports is 0.8.6 which is many years old -- Ticket URL: <http://trac.macports.org/ticket/25554> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #24708: p5-libxml-enno and p5-xml-dom conflict
by MacPorts 25 Aug '14

25 Aug '14

#24708: p5-libxml-enno and p5-xml-dom conflict -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: narf_tm@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.2 Keywords: | Port: p5-libxml-enno, p5-xml-dom -------------------------------------+-------------------------------------- p5-libxml-enno and p5-xml-dom conflict; indeed the description of p5 -libxml-enno says it provides XML::DOM. We should have only a single port for this software, whichever is the latest. -- Ticket URL: <http://trac.macports.org/ticket/24708> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #16373: svn fetch type should maintain a persistent working copy
by MacPorts 20 Aug '14

20 Aug '14

#16373: svn fetch type should maintain a persistent working copy -------------------------------------+-------------------------------------- Reporter: ryandesign(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: 1.7.0 Keywords: | -------------------------------------+-------------------------------------- "`fetch.type svn`" is inefficient in that it checks out a new working copy every time, directly to the work area. That would be like a normal port downloading the distfile every time. Instead, we should check out a working copy to that port's distpath, and then in the extract phase we should `svn export` it to the work area. Some checks will be needed in the fetch phase to ensure that an existing working copy: * has no modifications: check `svn status`. Ideally we would try to clean up the working copy, for example by `svn revert`ing modified or added or deleted files, and then in a second `svn status` run, delete any unversioned files. But it's already an improvement if we just discard the working copy if `svn status --ignore-externals` produces any output. * is from the right URL: check `svn info`: check if the "URL" is the one we want. If not, check that the "Repository Root" is a substring of the repository we want. If yes, try to `svn switch` to the URL and revision we want; if not, discard the working copy. So the fetch phase would go something like... {{{ if {working copy exists} { if {working copy has modifications} { delete working copy } } if {working copy exists} { if {working copy url is the one we want} { svn update to the desired revision } else { if {working copy repository root matches beginning of desired url} { try to svn switch to the desired url and revision if {an error occurred} { delete working copy } } else { delete working copy } } } if {working copy doesn't exist} { check out working copy } }}} And the extract phase is simply to `svn export` the working copy from the distpath to the worksrcpath. (There is [http://subversion.tigris.org/issues/show_bug.cgi?id=2429 one problem] if the working copy has externals and the user is using Subversion earlier than 1.5, for example Subversion 1.4.whatever which is included with Leopard. But rather than spend time working around this in base, I think this is a case where the port should depend on MacPorts subversion.) -- Ticket URL: <http://trac.macports.org/ticket/16373> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 21

[MacPorts] #26743: googlecl @0.9.10_0, osxutils @1.7_1 attempt to install conflicting bin/google
by MacPorts 20 Aug '14

20 Aug '14

#26743: googlecl @0.9.10_0, osxutils @1.7_1 attempt to install conflicting bin/google -----------------------------------+---------------------------------------- Reporter: jpenney@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Keywords: | Port: googlecl osxutils -----------------------------------+---------------------------------------- googlecl and osxutils both install attempt to install bin/google, causing whichever port is activated second to fail. I'd like to have both of these packages installed. Could a +no_google variant be added to osxutils perhaps? -- Ticket URL: <https://trac.macports.org/ticket/26743> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #27176: Airpwn
by MacPorts 20 Aug '14

20 Aug '14

#27176: Airpwn ------------------------------+--------------------------------------------- Reporter: jkru08@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: MacPorts 1.9.2 Component: ports | Version: 1.9.1 Keywords: airpwn | Port: airpwn ------------------------------+--------------------------------------------- There is a utility for linux that lets you inject packets and modify web pages that a client is viewing it is located here: is there a possibility of making a port for that? -- Ticket URL: <https://trac.macports.org/ticket/27176> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #29883: lingon: fix homepage in About box
by MacPorts 20 Aug '14

20 Aug '14

#29883: lingon: fix homepage in About box -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: bfulgham@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: lingon -------------------------------------+-------------------------------------- The About box of the Lingon app lists the homepage as !http://tuppis.com/lingon but that domain name seems to be owned by a domain name squatter now. Consider patching the app so that it lists a viable homepage in the About box (for example ${homepage}). -- Ticket URL: <https://trac.macports.org/ticket/29883> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6