MacPorts 1.4.2 has been released for selfupdate. It should hit the rsync servers in an hour or so. 1.4.2 is a minor bug fix release, cut quickly because 1.4.1 didn't build properly on panther (Mac OS X 10.3.x). ChangeLog entries: Release 1.4.2 (16-Apr-2007): - New logic for variants overload that basically yields to listing only variant +universal on ports that redefine it (pguyot in 24100). - Implement brand new fs-traverse command in Pextlib. See portfile.7 for documentation (eridius in r24079, r24080, and r24112). - Add per-user preferences in ~/.macports/user.conf. This will be used for submitter information. Simplify selection of ports.conf file: - ~/.portsrc is no longer supported. - Search order for ports.conf is now: - PORTSRC - ~/.macports/ports.conf - ${prefix}/etc/ports.conf Only the first file found will be parsed and used. (jberry r24071, r24113, r24114) - Improvements on livecheck: fixed a report bug, improved ruby group default behavior (pguyot in r24026 and r24018) - Remove xar from the build. xar doesn't build on panther due to a libxml2 lib too old for xar requirements. We'll find another way to deal with xar, perhaps by requiring users to install the xar port when they need its services. (jberry r24107:r24108) - Remove configure switch for building launchd support. (jberry r24107:r24108) - Remove compatibility upgrade for conf files from darwinports 1.1 to 1.2. (jberry r24106).
James Berry wrote:
MacPorts 1.4.2 has been released for selfupdate. It should hit the rsync servers in an hour or so.
1.4.2 is a minor bug fix release, cut quickly because 1.4.1 didn't build properly on panther (Mac OS X 10.3.x).
$ sudo port selfupdate DarwinPorts base version 1.400 installed Downloaded MacPorts base version 1.420 Configuring, Building and Installing new MacPorts base selfupdate done! $ sudo port -f clean --all all ---> Cleaning ngrep nhc98 is not supported on OS X i386 yet I'm new to this port system and may be missing something. Dave
On Apr 17, 2007, at 00:05, David Liontooth wrote:
$ sudo port selfupdate DarwinPorts base version 1.400 installed Downloaded MacPorts base version 1.420 Configuring, Building and Installing new MacPorts base selfupdate done!
Great! You got MacPorts 1.4.2.
$ sudo port -f clean --all all ---> Cleaning ngrep nhc98 is not supported on OS X i386 yet
I'm new to this port system and may be missing something.
Why do you want to clean *all* ports? Is there a specific problem you're trying to solve by running that command? The target "all" means all ports that exist, not just those installed on your system. So "all" includes nhc98, which prints the message you saw, and also exits, when it's invoked on an Intel Mac. Perhaps you meant to clean only the *installed* ports. But I'm still not clear why. I think MacPorts automatically cleans each port after it's installed, so you really shouldn't need to clean the installed ports.
Citando Ryan Schmidt :
Perhaps you meant to clean only the *installed* ports. But I'm still not clear why. I think MacPorts automatically cleans each port after it's installed, so you really shouldn't need to clean the installed ports.
port automatically cleans the work (build) directory, but not the distfiles and the archives, which port clean --all does. So it is a way to gain some disk files as distfiles can begin to pile up if there are frequent updates. Uninstalling inactive ports frees a lot of room too. Emmanuel
On Apr 17, 2007, at 04:24, Emmanuel Hainry wrote:
Citando Ryan Schmidt :
Perhaps you meant to clean only the *installed* ports. But I'm still not clear why. I think MacPorts automatically cleans each port after it's installed, so you really shouldn't need to clean the installed ports.
port automatically cleans the work (build) directory, but not the distfiles and the archives, which port clean --all does. So it is a way to gain some disk files as distfiles can begin to pile up if there are frequent updates. Uninstalling inactive ports frees a lot of room too.
Ahhh yes. Yes indeed. So it would probably be better for the nhc98 port (and any others that do it that way) not to do a ui_msg and exit simply when an auto- selected variant is set. Rather, that should be moved to the pre- configure phase, maybe.
Emmanuel Hainry wrote:
Citando Ryan Schmidt :
Perhaps you meant to clean only the *installed* ports. But I'm still not clear why. I think MacPorts automatically cleans each port after it's installed, so you really shouldn't need to clean the installed ports.
port automatically cleans the work (build) directory, but not the distfiles and the archives, which port clean --all does. So it is a way to gain some disk files as distfiles can begin to pile up if there are frequent updates. Uninstalling inactive ports frees a lot of room too.
Wouldn't it be useful in that case to have the "port clean --all" command tolerate a failed request to clean a package that's not available? $ sudo port -f clean --all all ---> Cleaning ngrep nhc98 is not supported on OS X i386 yet It's not a critical discovery that nhc98 is not yet supported; the script should just move on. David
Hi David, On Apr 17, 2007, at 9:47 AM, David Liontooth wrote:
Emmanuel Hainry wrote:
Citando Ryan Schmidt :
Perhaps you meant to clean only the *installed* ports. But I'm still not clear why. I think MacPorts automatically cleans each port after it's installed, so you really shouldn't need to clean the installed ports.
port automatically cleans the work (build) directory, but not the distfiles and the archives, which port clean --all does. So it is a way to gain some disk files as distfiles can begin to pile up if there are frequent updates. Uninstalling inactive ports frees a lot of room too.
Wouldn't it be useful in that case to have the "port clean --all" command tolerate a failed request to clean a package that's not available?
$ sudo port -f clean --all all ---> Cleaning ngrep nhc98 is not supported on OS X i386 yet
It's not a critical discovery that nhc98 is not yet supported; the script should just move on.
I'll certainly agree that the nhc98 port is misbehaving in this case. It should make such a complaint on destroot or configure, or something, but not when the portfile is opened. I believe that if you pass the -p flag to port, that this error (and any others) in a particular port will be ignored. The -p flag basically says that, while processing multiple ports (such as those furnished by all) that an error in one should be ignored. James
James Berry wrote:
Hi David,
On Apr 17, 2007, at 9:47 AM, David Liontooth wrote:
Emmanuel Hainry wrote:
Citando Ryan Schmidt :
Perhaps you meant to clean only the *installed* ports. But I'm still not clear why. I think MacPorts automatically cleans each port after it's installed, so you really shouldn't need to clean the installed ports.
port automatically cleans the work (build) directory, but not the distfiles and the archives, which port clean --all does. So it is a way to gain some disk files as distfiles can begin to pile up if there are frequent updates. Uninstalling inactive ports frees a lot of room too.
Wouldn't it be useful in that case to have the "port clean --all" command tolerate a failed request to clean a package that's not available?
$ sudo port -f clean --all all ---> Cleaning ngrep nhc98 is not supported on OS X i386 yet
It's not a critical discovery that nhc98 is not yet supported; the script should just move on.
I'll certainly agree that the nhc98 port is misbehaving in this case. It should make such a complaint on destroot or configure, or something, but not when the portfile is opened.
I believe that if you pass the -p flag to port, that this error (and any others) in a particular port will be ignored. The -p flag basically says that, while processing multiple ports (such as those furnished by all) that an error in one should be ignored. Hi James,
I just upgraded to your hot-off-the-stove 1.4.3 flawlessly, and then tried sudo port -f clean -p --all all It stumbled here: Error: Unable to open port: couldn't change working directory to "/opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/x11/gtk26": no such file or directory The gtk26 maintainer just requested the package be removed, and Maun Suang reported, "Done in r24129." I found /opt/local/etc/ports/sources.conf, where it seems port is downloading a fresh list -- what's the design feature that throws up this disagreement? This time I created a fake directory and portfile and got past that point, only to stumble again on the same package as when I was not using the -p flag: nhc98 is not supported on OS X i386 yet I would much prefer you were correct that the -p flag would inspire port to take such troubles in its stride, but alas, it fell on its face again. Cheers, Dave
On Apr 17, 2007, at 7:27 PM, David Liontooth wrote:
I believe that if you pass the -p flag to port, that this error (and any others) in a particular port will be ignored. The -p flag basically says that, while processing multiple ports (such as those furnished by all) that an error in one should be ignored. Hi James,
I just upgraded to your hot-off-the-stove 1.4.3 flawlessly, and then tried
sudo port -f clean -p --all all
This command should have been: sudo port -f -p clean --all all which would have ignored the problem with gtk26 no longer being present.
It stumbled here:
Error: Unable to open port: couldn't change working directory to "/opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/x11/gtk26": no such file or directory
The gtk26 maintainer just requested the package be removed, and Maun Suang reported, "Done in r24129." I found /opt/local/etc/ports/sources.conf, where it seems port is downloading a fresh list -- what's the design feature that throws up this disagreement?
That's due, unfortunately, to the PortIndex being generated at a lower frequency than the sync of the subversion tree to the rsync repository. So the PortIndex is slightly out of date with respect to the rest of the rsync files.
This time I created a fake directory and portfile and got past that point, only to stumble again on the same package as when I was not using the -p flag:
nhc98 is not supported on OS X i386 yet
I would much prefer you were correct that the -p flag would inspire port to take such troubles in its stride, but alas, it fell on its face again.
Yeah, even -p (properly placed) won't get you past this one. The port author was calling exit, on i386, whenever the Portfile was opened. I've checked in a revision to that port (r24159) which defers the error report until build time, and then does so in a somewhat nicer fashion. Thanks for the report. James.
James Berry wrote:
<snip> The port author was calling exit, on i386, whenever the Portfile was opened. I've checked in a revision to that port (r24159) which defers the error report until build time, and then does so in a somewhat nicer fashion.
Thanks! In my book, port is already much nicer than the OSX dmg method. Dave
participants (4)
-
David Liontooth
-
Emmanuel Hainry
-
James Berry
-
Ryan Schmidt