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

Re: [26883] trunk/dports/devel/autoconf/Portfile
by Ryan Schmidt 11 Jul '07

11 Jul '07

On Jul 10, 2007, at 22:02, source_changes(a)macosforge.org wrote: > Revision: 26883 > http://trac.macosforge.org/projects/macports/changeset/26883 > Author: boeyms(a)macports.org > Date: 2007-07-10 20:02:27 -0700 (Tue, 10 Jul 2007) > > Log Message: > ----------- > devel/autoconf: > * Add port:m4 to depends_lib (Autoconf README states GNU m4 >= > 1.4.7 is > required, but Tiger only has 1.4.2); > * Correct the name of one of the commands that autoreconf calls so > that it will > actually work with the MacPorts libtool port. Doesn't that mean that autoconf should also depend on the libtool port?

2 1

Error updating MacPorts
by Randall Wood 10 Jul '07

10 Jul '07

Error updating macports from 1.5.0-rc1 to 1.5.0: Getafix:~ rhwood$ sudo port selfupdate MacPorts base version 1.5 installed Error: /opt/local/bin/port: selfupdate failed: couldn't open "/opt/ local/var/macports/sources/rsync.macports.org/release/base/config/ mp_version": no such file or directory Getafix:~ rhwood$ sudo port -dv selfupdate DEBUG: Rebuilding the MacPorts base system if needed. DEBUG: Synchronizing ports tree(s) Synchronizing from rsync://rsync.macports.org/release/ports/ DEBUG: /usr/bin/rsync -rtzv --delete-after rsync://rsync.macports.org/ release/ports/ /opt/local/var/macports/sources/rsync.macports.org/ release/ports receiving file list ... done sent 74 bytes received 269017 bytes 19932.67 bytes/sec total size is 14713580 speedup is 54.68 Synchronizing from file:///Users/rhwood/Developer/MacPorts/WorkingPorts DEBUG: MacPorts base dir: /opt/local/var/macports/sources/ rsync.macports.org/release/base DEBUG: Setting user: root MacPorts base version 1.5 installed DEBUG: Updating using rsync receiving file list ... done config/ sent 73 bytes received 4957 bytes 1437.14 bytes/sec total size is 2093103 speedup is 416.12 DEBUG: couldn't open "/opt/local/var/macports/sources/ rsync.macports.org/release/base/config/mp_version": no such file or directory while executing "open [file join $mp_base_path config mp_version] r" (procedure "macports::selfupdate" line 45) invoked from within "macports::selfupdate [array get global_options]" Error: /opt/local/bin/port: selfupdate failed: couldn't open "/opt/ local/var/macports/sources/rsync.macports.org/release/base/config/ mp_version": no such file or directory 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."

2 1

flagpoll Portfile for consideration in MacPorts
by Doug McCorkle 10 Jul '07

10 Jul '07

Hello, Attached is a Portfile for flagpoll https:// realityforge.vrsource.org/view/FlagPoll . Please let me know if there is anything else that needs to be done for its inclusion in MacPorts. Thanks. Doug

2 1

Prevent removal of configured files after Portfile change
by Simon Ruderich 09 Jul '07

09 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, is it possible to prevent the complete removal of all configured/compiled data if the Portfile was changed. I'm just updating configuration parameters but port completely removes the project data and starts again. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGkUCpYRX4BO+zMikRCmqJAKDB0nlMLlpEi3/PMkEx9nXShkrucgCgrcF7 N67UPiiRSCankBTt8s9i1t8= =SOD+ -----END PGP SIGNATURE-----

4 6

Q: variants specified in dependencies
by Jyrki Wahlstedt 09 Jul '07

09 Jul '07

I remember there has been discussion about this, i.e. variants specified in dependencies. I wonder what the current status is, as I noticed the ticket about this (#126, the oldest one open, I believe) was milestoned to 1.5. At least in one earlier discussion there were objections to do this due to the difficulty in implementing, but I would like to see this, e.g. because mpkg is based on very short trial useless without this capability (and mpkg is something that I could use). If this means that I should dive into the deep core of MacPorts, I would be willing to give it a try. ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386

3 2

Re: [26771] trunk/dports/devel/git-core
by Ryan Schmidt 08 Jul '07

08 Jul '07

On Jul 6, 2007, at 16:41, source_changes(a)macosforge.org wrote: > Revision: 26771 > http://trac.macosforge.org/projects/macports/changeset/26771 > Author: mgrimes(a)macports.org > Date: 2007-07-06 14:41:49 -0700 (Fri, 06 Jul 2007) > > Log Message: > ----------- > Update to git-core 1.5.2.3 > > - Add p5-error (Fix #12240) > - Refresh and rename patch files to literal naming conventions instead > of functional. > - Add darwin_9 variant to workaround ticket #12245. > - whitespace fixes It would be better if you could commit whitespace changes separately from functional changes. This makes it much easier to tell by glancing at a diff what functional changes have been made in a given revision.

2 1

1.5 rc1 tag created ([26762] tags/release_1_5_0-rc1/)
by Juan Manuel Palacios 07 Jul '07

07 Jul '07

Evening everyone! I'm happy to announce that I'm almost done with the preparations for the 1.5 release, available time being the sole constraint, as always. I believe the release branch is almost ready to ship so I created a first and hopefully only release candidate tag in r26762 below, which we should all take for a test drive ;-) I will wait for two more things: 1) final word on http://trac.macports.org/projects/macports/ticket/ 12231, whether that's a final solution to the issue or just an advice to leave it out of the release for the time being; 2) final word on whether or not I should merge Anders' r26737. After that I'll start preparations for the final release, including creating the ports tree archive, the dmg installer, release announcement and whatever else is relevant, finally! In short, do speak up quick if you have anything to report ;-) Regards,... -jmpp Begin forwarded message: > From: source_changes(a)macosforge.org > Date: July 6, 2007 1:16:29 AM GMT-04:00 > To: macports-changes(a)lists.macosforge.org > Subject: [26762] tags/release_1_5_0-rc1/ > Reply-To: macports-dev(a)lists.macosforge.org > > Revision 26762 Author jmpp(a)macports.org Date 2007-07-05 22:16:29 > -0700 (Thu, 05 Jul 2007) Log Message Tagging a first and hopefully > only release candidate of the 1.5 branch. Added Paths > tags/release_1_5_0-rc1/ > Diff > Copied: tags/release_1_5_0-rc1 (from rev 26761, branches/release_1_5) > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes

3 3

The fetch command in Portfiles
by Doug McCorkle 06 Jul '07

06 Jul '07

Hello, I would like to use: fetch.ignore_sslcrt in my Portfile or: fetch.args in my Portfile but I get an error about the commands not being recognized. Is there a new way to work with the fetch target? Thanks. Doug

1 0

Release 1.5 branch created
by Juan Manuel Palacios 06 Jul '07

06 Jul '07

Evening everyone! I finally created the release_1_5 branch wherefrom we'll start cutting the 1.5.x releases, really soon now I hope! For those willing to help around in sanitizing, please reinstall off this branch and test as thoroughly as posible, reporting any findings you may come by. I'll rework the roadmap to move open tickets in the 1.4 milestone to 1.5, as well as those that were fixed in it but not released to users (committed to trunk, which as of r26608 is the same as release1_5) but not to the release_1_4 branch. Any new ticket on the base component should be submitted to the 1.5 milestone, consider 1.4 closed! As said previously, I'm mainly interested in reports on upgrading existing 1.4.x installations to 1.5 through any mean (selfupdate, make, binary -- I know there's no dmg up yet, but you can always build your own ;-). Even though I haven't received a single one to date (and supposedly "no news is good news), I'd still love to hear whatever you, the tester, have to say about it. Thanks to all for the help and attention, thanks to those who've put so much into improving the MacPorts core! Regards,... -jmpp

8 21

Re: deploying pre-build ports with macports
by Boyd Waters 06 Jul '07

06 Jul '07

On Jul 5, 2007, at 1:11 PM, Barry Wark wrote: > Boyd, > > It sounds like you've been down this road already, then :) > >> From your answer, it sounds like things won't work. I'm a bit > confused, though. I thought that macports would keep receipts for the > installed ports (e.g. hdf5) (in /opt/local/var/db/dports/?) and that > those receipts would do the trick on the client machine as well. I > planned to compile the dependencies (e.g. hdf5) using "port install > XXX"--a source install--, then to make an installer that has it's root > at /opt/local and with an install target of /opt/local. Wouldn't the > client macports still have those receipts? > > Sorry for my confusion. Wow, you don't need to be sorry -- I think it is confusing. The binary package created with "port pkg" won't write that receipt to ${prefix}/var/db/dports/? I'm talking about binary packages created with MacPorts -- via the "port pkg" command -- they cause me no end of trouble. My opinion. I'd like to find the time to fix the MacPorts package-creation stuff, but my Tcl skills may not be adequate. Anyway. I created a large collection of packages - one for each port - via the "port pkg" command. I gave these to my fellow developers, and many scientists, who also had Macports installed. They double-click the pkg file, which launches the Apple installer, and installs the libraries, binaries, under /opt/local. Great. Then later they want to go build some MacPorts that need the packages that they've already installed with the bianry installer. Example: I gave them the fortran compiler as a binary package created from MacPorts, and they want to install (from source) a package that needs this compiler. When they say "port build fortran-thing", MacPorts *ignores* the binary-installed fortran compiler -- even though it came from a MacPorts-created binary package -- and goes ahead and builds every last little thing. Which may take hours. And may fail, depending upon which MacPorts tree they have. MacPorts packages that I have created have another nasty nasty bug, in that they cannot handle symbolic links in directory paths. The example I gave earlier on this list was MacPorts emacs -- which all of our users assumed they needed (they don't know that OS X already has it). The emacs package wants to add a file to /etc/X11. But /etc is a symlink to /private/etc. Since the MacPorts installer doesn't handle that, it *deletes* the symlink to /private/etc, creates a new, blank directory at /etc, and then write its file, and claims that installation completed successfully. Rendering the Macintosh unusable in the process. So I gave up on distributing binary packages created from MacPorts, and I just rely upon MacPorts on my developer-build box, and roll a tarball "by hand" for our scientific application. The tarball includes its own distribution of Python, Qt, etc. Since we roll out the application to people in different institutions, different configurations, this is the most robust: we try to assume as little as possible about what might already be set up on the end- users' Macs. Hope this helps! Some.. - boyd

2 1