January 2009 - macports-tickets - lists.macosforge.org

[MacPorts] #15515: "port provides" broken in trunk
by MacPorts 20 Dec '09

20 Dec '09

#15515: "port provides" broken in trunk -------------------------------------+-------------------------------------- Reporter: ryandesign(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Keywords: | -------------------------------------+-------------------------------------- "`port provides`" seems to be broken in trunk (@37376). Not sure yet when this problem appeared. This is with Mac OS X 10.4.11 and Xcode 2.4.1 on Intel. {{{ $ /mp/bin/port provides foo list must have an even number of elements while executing "array set portspec { foo }" ("uplevel" body line 1) invoked from within "uplevel 1 "array set portspec { $portspec }"" (procedure "foreachport" line 6) invoked from within "foreachport $portlist { set file [compat filenormalize $portname] if {[file exists $file]} { if {![file isdirectory $file]..." (procedure "action_provides" line 9) invoked from within "$action_proc $action $portlist [array get global_options]" (procedure "process_cmd" line 86) invoked from within "process_cmd $remaining_args" invoked from within "if { [llength $remaining_args] > 0 } { # If there are remaining arguments, process those as a command # Exit immediately, by default, unless..." (file "/mp/bin/port" line 3165) $ }}} -- Ticket URL: <http://trac.macports.org/ticket/15515> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #15488: wrap text to terminal width
by MacPorts 20 Dec '09

20 Dec '09

#15488: wrap text to terminal width -------------------------------------+-------------------------------------- Reporter: ryandesign(a)macports.org | Owner: raimue(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Keywords: | -------------------------------------+-------------------------------------- MacPorts base in trunk now wraps output to 80 characters, but the terminal window is not necessarily 80 characters wide. It may be wider or narrower. As a first step, I'd like to see the wrap-to width moved into a variable/constant that's defined only once. Magic numbers in source are bad. Next step would be to wrap to the actual terminal width (if output is to a terminal) or not wrap at all (if output is to a file or pipe). Rainer, since you've been working on some stuff near this the past few days, maybe you could at least take care of abstracting the wrap-to width into a variable? -- Ticket URL: <http://trac.macports.org/ticket/15488> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 7

[MacPorts] #15485: RFE: Use distfiles mirror and fallback also for URLs with tags
by MacPorts 20 Dec '09

20 Dec '09

#15485: RFE: Use distfiles mirror and fallback also for URLs with tags ---------------------------------------+------------------------------------ Reporter: raimue(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: ports | Version: 1.7.0 Keywords: distfiles mirror fallback | ---------------------------------------+------------------------------------ If a URL in `master_sites` has a tag, the distfiles mirror and the fallback sites are not considered. For example: {{{ master_sites http://foo.example.org/:tag1 http://bar.example.org/:tag2 distfiles foo:tag1 bar:tag2 }}} In this example, `foo` should be downloaded from `foo.example.org`, `tag2` from `bar.example.org`. But the distfiles mirror and the fallback site are not added. -- Ticket URL: <http://trac.macports.org/ticket/15485> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #15433: RFE: Eliminate duplicates in portlist
by MacPorts 19 Dec '09

19 Dec '09

#15433: RFE: Eliminate duplicates in portlist ---------------------------------+------------------------------------------ Reporter: raimue(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: 1.6.0 Keywords: | ---------------------------------+------------------------------------------ See the following output: {{{ $ port echo name:vim or description:vim p5-text-vimcolor vim vim-app vim2html p5-text-vimcolor vim-app vim2html }}} It should be avoided to list ports twice or more times here. -- Ticket URL: <http://trac.macports.org/ticket/15433> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #15426: BUG: py25-* fail with parallel building enabled
by MacPorts 19 Dec '09

19 Dec '09

#15426: BUG: py25-* fail with parallel building enabled ---------------------------------+------------------------------------------ Reporter: raimue(a)macports.org | Owner: afb(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Keywords: parallel | ---------------------------------+------------------------------------------ There was a new bug introduced while fixing #15295. {{{ ---> Building py25-bz2 with target build DEBUG: Executing org.macports.build (py25-bz2) DEBUG: port allows a parallel build DEBUG: Environment: "MACOSX_DEPLOYMENT_TARGET"='10.5' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_raim_src_macports_trunk_dports_python_py25-bz2/work/Python-2.5.2/Modules" && /opt/local/bin/python2.5 setup.py build' usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option -j not recognized Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_Users_raim_src_macports_trunk_dports_python_py25-bz2/work/Python-2.5.2/Modules" && /opt/local/bin/python2.5 setup.py build -j3" returned error 1 }}} The python port groups just set build.cmd (and do not overwrite build.type), so [build_getmaketype] still assumes this is a standard make. With the previous implementation overwriting build.cmd was enough. -- Ticket URL: <http://trac.macports.org/ticket/15426> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #15405: xcode.project variable handles strings as lists
by MacPorts 19 Dec '09

19 Dec '09

#15405: xcode.project variable handles strings as lists ---------------------------------+------------------------------------------ Reporter: rhwood(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Keywords: | ---------------------------------+------------------------------------------ The xcode.project portfile variable treats strings as lists. The variable takes a single project file as an argument to be passed to xcode, but if a space is in the name, it passes the name wrapped in curly braces. Expected result: setting {{{xcode.project "Chat Core.xcodeproj"}}} does not lead to an error Returned result: {{{ --> Building ChatCore Error: Target org.macports.build returned: shell command "cd "/opt/local/var/macports/build/_Users_Shared_Developer_MacPorts_Repository_trunk_dports_irc_ChatCore/work/trunk" && xcodebuild -project {Chat Core.xcodeproj} -target "ChatCore (Application)" -configuration Release build OBJROOT=build/ SYMROOT=build/ " returned error 1 Command output: xcodebuild: Error: the project name {Chat does not have a valid extension. }}} Note that '''''{'''Chat Core.xcodeproj'''}''''' is passed instead of ''Chat Core.xcodeproj'' This issue is covered in #12429 which I did not reopen due to its commentary. I found at least one portfile (source:trunk/dports/aqua/IcyJuice/Portfile) that has workarounds in it to address this behavior. -- Ticket URL: <http://trac.macports.org/ticket/15405> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #16817: BUG: 'port cat' appends blank line to svn version of Portfile
by MacPorts 16 Dec '09

16 Dec '09

#16817: BUG: 'port cat' appends blank line to svn version of Portfile ---------------------------------+------------------------------------------ Reporter: devans(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: High | Milestone: MacPorts base bugs Component: ports | Version: 1.7.0 Keywords: | Port: MacPorts ---------------------------------+------------------------------------------ When using the command 'port cat port_name' to obtain a copy of a given port's Portfile, the text returned has a blank line appended relative to the svn repository version. This can be verified as follows: {{{ cp `port dir port_name` Portfile.repo // get repo copy port cat port_name > Portfile.cat // get port cat copy diff -u Portfile.repo Portfile.cat // compare them }}} Using libgweather as an example the result is {{{ --- Portfile.repo 2008-10-10 15:05:03.000000000 -0700 +++ Portfile.cat 2008-10-10 15:05:32.000000000 -0700 @@ -26,3 +26,4 @@ post-activate { system "${prefix}/bin/scrollkeeper-update" } + }}} This is a problem because if you use 'port cat' to get a presumed copy of a port's Portfile, edit it and then make a patch file for upload to Trac, the patch file will fail when applied to svn if the effect of the patch is to append additional script lines to the end of the original Portfile. If you're not appending to the end, the patch works fine. And, of course, the patch always appears to work fine locally. This apparently random on again, off again failure mode can cause you to question your sanity (as I was) if you don't recognize the pattern! I'm using MacPorts built from latest trunk. Haven't tried this with 1.6.0. -- Ticket URL: <http://trac.macports.org/ticket/16817> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #17090: apr 1.3.3 doesn't compile universal x86_64+i386
by MacPorts 14 Dec '09

14 Dec '09

#17090: apr 1.3.3 doesn't compile universal x86_64+i386 ---------------------------------+------------------------------------------ Reporter: pguyot(a)kallisys.net | Owner: dluke(a)geeklair.net Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.7.0 Keywords: | Port: apr ---------------------------------+------------------------------------------ When compiling apr +universal with the default targets set to i386 and x86_64, I get the following compilation error: {{{ strings/apr_snprintf.c: In function 'conv_os_thread_t': strings/apr_snprintf.c:500: error: duplicate case value strings/apr_snprintf.c:498: error: previously used here strings/apr_snprintf.c: In function 'conv_os_thread_t_hex': strings/apr_snprintf.c:671: error: duplicate case value strings/apr_snprintf.c:669: error: previously used here }}} In fact, I'm wondering if apr compiles on 64bits at all. The lines go like this: {{{ case sizeof(apr_int32_t): return conv_10(u.u32, TRUE, &is_negative, buf_end, len); case sizeof(apr_int64_t): return conv_10_quad(u.u64, TRUE, &is_negative, buf_end, len); }}} This is on 10.5.5/x86. -- Ticket URL: <http://trac.macports.org/ticket/17090> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 44

[MacPorts] #17397: wxgtk not installable
by MacPorts 13 Dec '09

13 Dec '09

#17397: wxgtk not installable -------------------------------+-------------------------------------------- Reporter: vlatro@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: wxgtk | Port: wxgtk -------------------------------+-------------------------------------------- ---> Fetching jpeg ---> droppatch.tar.gz doesn't seem to exist in /opt/local/var/macports/distfiles/jpeg ---> Attempting to fetch droppatch.tar.gz from http://sylvana.net/jpegcrop/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 Error: Target org.macports.fetch returned: fetch failed Warning: the following items did not execute (for jpeg): org.macports.activate org.macports.fetch org.macports.extract org.macports.checksum org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: The following dependencies failed to build: gtk2 jasper jpeg pango Xft2 xorg-xproto shared-mime-info intltool gnome-common p5-xml-parser perl5.8 perl5 libxml2 tiff Error: Status 1 encountered during processing. bash-3.2# -- Ticket URL: <http://trac.macports.org/ticket/17397> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #16383: gnustep portgroup should use destroot.violate_mtree yes
by MacPorts 12 Dec '09

12 Dec '09

#16383: gnustep portgroup should use destroot.violate_mtree yes -------------------------------------+-------------------------------------- Reporter: ryandesign(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Keywords: | -------------------------------------+-------------------------------------- When using the gnustep layout, the gnustep portgroup should indicate that it intends to violate the mtree by using the `destroot.violate_mtree yes` keyword. -- Ticket URL: <http://trac.macports.org/ticket/16383> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4