May 2007 - macports-dev - lists.macosforge.org

New "file delete" implementation breaks ncurses
by Guido Soranzio 08 May '07

08 May '07

After the changes to the "file delete" implementation, the installation of ncurses fails because it tries to follow the target of a symbolic link. By reversing the order of the arguments from delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/terminfo into delete ${destroot}${prefix}/lib/terminfo ${destroot}${prefix}/share ncurses installs correctly (lib/terminfo is a symbolic link to ../ share/terminfo). I have already submitted a bug report through Trac (http://trac.macosforge.org/projects/macports/ticket/11878) but it doesn't have been reviewed for too long.

6 11

Re: [24922] trunk/dports/PortIndex
by James Berry 08 May '07

08 May '07

On May 8, 2007, at 6:06 AM, source_changes(a)macosforge.org wrote: > Revision > 24922 > Author > dluke(a)macports.org > Date > 2007-05-08 06:06:26 -0700 (Tue, 08 May 2007) > Log Message > > Total number of ports parsed: 3911 > Ports successfully parsed: 3907 > Ports failed: 4 > > > Failed to parse file devel/libxfcegui4/Portfile: can't set > "depends_lib": invalid depspec: port::libxfce4util > Failed to parse file math/cadabra/Portfile: can't set > "depends_lib": invalid depspec: port:pcre++ > Failed to parse file perl/p5-html-scrubber/Portfile: can't set > "depends_lib": invalid depspec: port:port:p5-html-parser > Failed to parse file perl/p5-text-quoted/Portfile: can't set > "depends_lib": invalid depspec: port:p5-text-tabs+wrap Okay, who changed the parsing of the dep spec? Two of those actually are bad, two of them actually are good. James

5 7

Re: [24932] trunk/dports/math/cadabra
by Juan Manuel Palacios 08 May '07

08 May '07

Hi Gregory! On May 8, 2007, at 12:14 PM, source_changes(a)macosforge.org wrote: >> > depends_lib port:modglue \ > port:pcre \ > - port:pcre++ \ > + port:pcrexx \ > port:gmp \ > port:LiE Does the pcrexx port really exist? I couldn't find it with a simple search. If that's just a workaround for the + sign causing failures, James introduced a fix for that in trunk/base seconds ago. Doesn't an installation attempt fail if a dependency on a non-existent port is listed....? Regards,... -jmpp

1 0

Re: [24905] trunk/base/ChangeLog
by Ryan Schmidt 08 May '07

08 May '07

On May 7, 2007, at 22:33, source_changes(a)macosforge.org wrote: > Revision: 24905 > http://trac.macosforge.org/projects/macports/changeset/24905 > Author: jberry(a)macports.org > Date: 2007-05-07 20:33:26 -0700 (Mon, 07 May 2007) > > Log Message: > ----------- > Update ChangeLog in preparation for release 1.4.40. > > Modified Paths: > -------------- > trunk/base/ChangeLog > > Modified: trunk/base/ChangeLog > =================================================================== > --- trunk/base/ChangeLog 2007-05-08 03:28:22 UTC (rev 24904) > +++ trunk/base/ChangeLog 2007-05-08 03:33:26 UTC (rev 24905) > @@ -6,6 +6,13 @@ > > (unreleased): > > +Release 1.4.40 (7-May-2007): > + > + - Note the bump in version naming. To leave ourselves lots of > room in our versioning > + scheme, we've jumped from 1.4.3 to 1.4.40. The floating > point represenation as > + reported by port version (1.440) will still be the same; > we're just interpreting > + it differently. > + > - variable tracing now works in a much better way and handles > unsets properly. > Similarly, ${option}-delete now works better. Depends > validation no longer > attempts to validate when the variable is unset. > Additionally, the validation Out of curiosity, why are we using these weird version numbers? The standard in the unix software world (which is the world of software that MacPorts installs so it's not unreasonable to make the comparison) would be that you have 1.4.0, 1.4.1, 1.4.2 etc up to 1.4.9, then 1.4.10, 1.4.11, etc. Simply count up the last number, until it's time to increment the middle number and reset the last number back to zero. But this change log entry seems to describe a rather different version strategy for MacPorts. In particular, it seems to mean that the version after 1.4.9 must be 1.5.0; that there is no room for a 1.4.10 or any larger version (unless you say that "1.491" corresponds to 1.4.10, "1.492" to 1.4.11, etc., which would be a mess). Is there a reason why we are intentionally limiting ourselves with this numbering scheme? Is this a reason for wanting to do fewer releases -- so that we don't have to prematurely come to version 1.5.0 which might then not be substantially different from 1.4.9?

2 1

Ticket 7050 can be closed
by Olaf Foellinger 07 May '07

07 May '07

Hi, I've checked the ticket http://trac.macports.org/projects/macports/ticket/7050 and it can be closed now(see my comment in the ticket). Gruss Olaf

1 0

Maintainer but not committer with update: Submitted a Trac ticket, now I just wait?
by Mark Evenson 07 May '07

07 May '07

I am the maintainer of 'lang/slime' for which I have submitted a ticket to Trac [1], attaching it to the Milestone "Port Updates". Now I just wait for a committer to notice this, or should I bring it to some email address's attention? The Wiki has the start [2] of guide to these questions, but no answers, for which it would be good to fill in even provisional answers to the procedure. 1: http://trac.macports.org/projects/macports/ticket/11902 2: http://trac.macosforge.org/projects/macports/wiki/MaintainingAPort

6 5

Re:--pretend & --fetch-all options
by Glen Whitney 07 May '07

07 May '07

Quoting from macports-users 20 Feb 2007: >> That said, it still remains second to the first idea >> of mel who started this thread, to implement a dry >> run feature. Maybe, dry run would just be half of >> the implementation of prefetch. > > Due to the reason above, I'd prefer the the dry run feature > to be implemented first, because I think in the long run > it will help to improve port's variants feature. I have submitted a patch (dry.3.patch attached to http://trac.macports.org/projects/macports/ticket/11892) against the current svn version (r24893) which adds a -y option for dry run. (I chose -y since it's the only letter left from "dry" which was not already an option.) It turns out to be a pretty simple patch, only touching one tcl source file except for documentation and parsing the switch. I now use it all the time for checking out recursive dependencies and the behavior of different variants. Perhaps it will catch the eye of someone who can incorporate it into the development version of MacPorts. Hope this is helpful, Glen Whitney

1 0

New port for ruby-dbi with odbc support
by Tim Lucas 07 May '07

07 May '07

There's two port files, rb-dbd-pg and db-dbd-mysql that currently just extend rb-dbi with a few configure args. They should probably use variants, but I digress. I've created another Portfile, in the spirit of these two, so you can install ruby-dbi with odbc support via macports, just like you can with mysql or postgres. It's a dead- simple Portfile. How can I get this added to the ports tree? (feel free to point me to an FAQ... the macports site+docos are excruciating, have spent ages looking already) -- tim

2 2

New Port (cgdb)
by Jens Frederich 07 May '07

07 May '07

Hi all, I¹m new here. I would add a new port for the ncurses based debugger frondend cgdb. What must I do, for accepting the port? Jens Port File: # $Id$ PortSystem 1.0 name cgdb version 0.6.4 categories devel platforms darwin maintainers jfrederich(a)gmail.com description A curses-based interface to the GNU Debugger (GDB). long_description \ CGDB is a curses-based interface to the GNU Debugger (GDB). \ The goal of CGDB is to be lightweight and responsive; not \ encumbered with unnecessary features. \ homepage http://cgdb.sourceforge.net master_sites sourceforge checksums md5 bddcaaee7b20ab2c17f1f4e197db74c0 \ sha1 5f1246d151dc419aa08890291175b4b2094e62c9 depends_lib port:ncurses port:readline configure.type gnu configure.args --infodir=${prefix}/share/info \ --mandir=${prefix}/share/man \

2 1

Re: [24832] trunk/base/src/port/port.tcl
by Randall Wood 06 May '07

06 May '07

On 5 May 2007, at 20:41, source_changes(a)macosforge.org wrote: > Revision 24832 Author jberry(a)macports.org Date 2007-05-05 17:41:51 > -0700 (Sat, 05 May 2007) Log MessageStore readline history in > ~/.macports/.history instead of ~/.port_history Why ~/.macports/.history and not ~/.macports/history (why a .file in a .dir)? And while I'm asking why not use ~/Library/Application Support/ Macports instead of ~/.macports? Isn't it the Apple way to use the Library instead of .dirs? > Modified Paths > trunk/base/src/port/port.tcl > Diff > Modified: trunk/base/src/port/port.tcl (24831 => 24832) --- trunk/ > base/src/port/port.tcl 2007-05-06 00:35:02 UTC (rev 24831) +++ > trunk/base/src/port/port.tcl 2007-05-06 00:41:51 UTC (rev 24832) @@ > -2434,13 +2434,14 @@ proc process_command_file { in } { global > current_portdir + global darwinports::autoconf::macports_user_dir # > Initialize readline set isstdin [string match $in "stdin"] set name > "port" set use_readline [expr $isstdin && [readline init $name]] - > set history_file [file normalize "~/.${name}_history"] - + set > history_file [file normalize "${macports_user_dir}/.history"] + # > Read readline history if {$use_readline} { rl_history read > $history_file > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood rhwood(a)mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

4 3