Re: 1.6.0 rc2 created (Was Re: [31193] branches/release_1_6/base/src)
Juan Manuel Palacios wrote: The HACKING file is still present, and the README file is still missing... ? All our documentation will definitely be moved to the guide, including the usual INSTALL, README, HACKING and similar text files found in open source projects. We already have some of these and we lack others, some are already in the guide and some still in our sources, but they will all eventually end up there, as our documentation authors manage to get to each of them. So does that means that it is now hands-off for everyone else, like with the manual pages ? Nevertheless, I say we keep the usual suspects in our sources but only as placeholders pointing readers to the relevant sections in the guide. What do you suggest we put in a README file? Just a dozen lines or so describing what it is, where it is, what it does and who did it. Like in http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ distpractice.html#README Not sure if you wanted http://trac.macports.org/projects/macports/ticket/13141 to be in 1.6, That would be sweet! Do you have any ETC/deliverables? I added a small comment to the ticket which might be of help. Nah, myself I just thought the available pkg information should be better. or just http://trac.macports.org/projects/macports/ticket/12779 This relating only to the guide, it would be great to have it for the time we release 1.6.0 too, but I don't think we need to tie ourselves to it; it can happen at any moment (the guide is regenerated nightly). Guide and Website, it was. As in: wherever the Download link is presented. http://trac.macports.org/projects/macports/ticket/13145 as well (preflight stuff) Though I'm not incredibly happy with the state of this issue, it is a matter of fact that dealing with paths containing spaces can turn into a major headache for us (and I'm not just referring to MacPorts itself here, I can't imagine the thousands of ports that we distribute that might hide this type of bugs in their configurations and/or Makefiles uuughhh!). I tried bootstrapping MacPorts into a path with spaces and couldn't even get through our own configuration script, let alone get to my dp2mp-move upgrading rules to try to bullet-proof them. I know the original poster's problems creeps up when I try to upgrade his personal configuration file, as it's the path to his home dir what contains spaces and not MacPorts' prefix, but it's basically the same situation. I'm not suggesting that paths with spaces should be supported. I just wanted *volumes* with spaces in their names to be supported, while still installing in the usual /opt/local prefix locally on the volume... The original poster mentioned that a manual install works just fine, it's just the preflight script in the package that is referring to things with /Volumes/Litter Box prefixed to the regular paths ? I know someone else wanted to install in their home folder, while it was located on a path with spaces, but that is an issue for later... I probably won't be updating MP 1.6 to RPM 4.5 and Python 2.5 for the rpm packaging targets/ports, as I had originally intended. (It'll still use RPM 4.4 / Python 2.4) Not a problem, whenever you're ready! Since RPM 4.5 has not been released yet and since not all of the other ports work with Python 2.5 yet, it won't be a priority this year. Besides, RPM 5.0 is where the development happens - and it is currently in alpha testing. The only major casualty of sticking with 4.4/2.4 is the Smart GUI, since it needs GTK+ and the py-gtk2 port isn't available anymore. Then again the Smart text interface is still working OK, once python24 is made to limp along. The current RPM ports should be more than enough to sort out the other problems that MacPorts has with binary package (rpm) building - at the moment it looks like doing binary archives (tlz) would be a better alternative ? --anders ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 1.6.0 rc2 created (Was Re: [31193] branches/release_1_6/base/src)
Juan Manuel Palacios wrote: Will make a MacPorts-1.6.0RC2.tar.b2 tarball for testing other platforms tonight. Great! Let us know of status. Source code tarball, and BSD / GNU binary packages posted at: http://trac.macports.org/projects/macports/browser/users/afb/RC/ Built and tested (ehum) with FreeBSD CURRENT and Fedora Rawhide. i.e. as in http://www.freebsd.org and http://fedoraproject.org/ Package build scripts are in portmgr/freebsd and portmgr/fedora, respectively. (one for the Ports collection, one for Yum repos) On the TODO list is how to install the basic system (OS + MP), and what requirements are needed beyond the basic GCC and X11... platformsdarwin freebsd linux --anders ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Trac emails -- how to stop getting them
James Berry wrote: I think the best behavior would be to turn off the notifiers feature. Then it's essentially opt-in: if you want to get updates for a ticket then you put yourself in the cc field, right? That seems perfect. But reporter and assignee should be notified by default, otherwise it would be possible for some committer to never realize there actually is a open ticket assigned to him. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 1.6.0 rc2 created (Was Re: [31193] branches/release_1_6/base/src)
Hi Juan, On Nov 18, 2007, at 10:35 AM, Juan Manuel Palacios wrote: On Nov 18, 2007, at 5:23 AM, Ryan Schmidt wrote: On Nov 18, 2007, at 00:20, Juan Manuel Palacios wrote: And while we're at it, I just created an rc2 tag for 1.6.0, differing from rc1 only in James' turning readline support into an optional configuration (r31139-31139 and merged into the release_1_6 branch in r31190) and in the Tcl cd command hiding reversion thing (r31193 only in the release_1_6 branch). Every developer/committer should reinstall MacPorts off this tag and test as extensively as possible! Apparently the lack of readline is making interactive mode very strange. Note how the prompt doesn't appear until after the thing I typed. We were missing a flush after the prompt was output, before the get operation. I added that single line in r31338:31339. Hope that can get into 1.6. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Hypothetical port load, port unload commands (and turn script)
Hi Ryan, On Nov 20, 2007, at 9:01 AM, Ryan Schmidt wrote: I've written many replies on this list explaining to people how to use launchctl to start and stop various services installed by MacPorts. Every time I do, I have to refer back to my notes to remember the exact launchctl command and the exact path to the plist. Admit it: sudo launchctl load -w /Library/LaunchDaemons/org.macports.foo.plist is not easy to remember, and it's a lot to type. On my system, I wrote a script turn to simplify things for me. I can say things like: turn foo on or turn off bar and it knows where to look for the plist and how to execute the appropriate launchctl command. It's short and easy to remember. It also prints helpful messages if you try to turn something on when it's already on, or off when it's already off. It would be nice to have easier-to-remember commands included with MacPorts, but a script called turn hardly seems to fit in with the rest of the project. But what about: sudo port load foo and sudo port unload bar ? That's pretty easy to remember in my opinion. What do you think? I like this. We could look for a startupitem in the port, get the name, and put the proper command together for launchctl. Very nice. Do we have any other conceivable uses for the words load and unload that this might conflict with? James This proposed syntax limits us to one launchctl plist per port. However, we already have that limit, so I don't consider it a big problem at this time. P.S: I'm including my turn script for others to examine and try out and even use, if they like. But I'm not suggesting that this script be incorporated as-is into MacPorts. I would fully intend for the hypothetical port load and port unload commands to be properly implemented in Tcl. turn___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Hypothetical port load, port unload commands (and turn script)
I've written many replies on this list explaining to people how to use launchctl to start and stop various services installed by MacPorts. Every time I do, I have to refer back to my notes to remember the exact launchctl command and the exact path to the plist. Admit it: sudo launchctl load -w /Library/LaunchDaemons/org.macports.foo.plist is not easy to remember, and it's a lot to type. On my system, I wrote a script turn to simplify things for me. I can say things like: turn foo on or turn off bar and it knows where to look for the plist and how to execute the appropriate launchctl command. It's short and easy to remember. It also prints helpful messages if you try to turn something on when it's already on, or off when it's already off. It would be nice to have easier-to-remember commands included with MacPorts, but a script called turn hardly seems to fit in with the rest of the project. But what about: sudo port load foo and sudo port unload bar ? That's pretty easy to remember in my opinion. What do you think? This proposed syntax limits us to one launchctl plist per port. However, we already have that limit, so I don't consider it a big problem at this time. P.S: I'm including my turn script for others to examine and try out and even use, if they like. But I'm not suggesting that this script be incorporated as-is into MacPorts. I would fully intend for the hypothetical port load and port unload commands to be properly implemented in Tcl. turn Description: Binary data ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
unexpected error from port variant when port is not found
Hi
I was just looking at the available variants for a port, I mistyped
the name of the port and received the following error message:
$ port variants misspelled_port
No port misspelled_port found.
can't read portinfo(porturl): no such element in array
while executing
set porturl $portinfo(porturl)
(uplevel body line 15)
invoked from within
uplevel 1 $block
(procedure foreachport line 16)
invoked from within
foreachport $portlist {
# search for port
if {[catch {mportsearch $portname no exact} result]} {
global errorInfo
...
(procedure action_variants line 4)
invoked from within
$action_proc $action $portlist [array get global_options]
(procedure process_cmd line 60)
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 /opt/local/bin/port line 2651)
$
I would expect the initial error of No port misspelled_port found,
but not the rest. This is with base from the top of the release_1_6
branch. Is this the expected behaviour?
Cheers
Adam
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [31218] trunk/dports/sysutils/kernel-tools/Portfile
On Nov 18, 2007, at 11:39, [EMAIL PROTECTED] wrote:
Revision: 31218
http://trac.macosforge.org/projects/macports/changeset/31218
Author: [EMAIL PROTECTED]
Date: 2007-11-18 09:39:33 -0800 (Sun, 18 Nov 2007)
Log Message:
---
Excise `cd`; move manpages to share/man; default_variants universal
Modified Paths:
--
trunk/dports/sysutils/kernel-tools/Portfile
Modified: trunk/dports/sysutils/kernel-tools/Portfile
===
--- trunk/dports/sysutils/kernel-tools/Portfile 2007-11-18 17:14:49
UTC (rev 31217)
+++ trunk/dports/sysutils/kernel-tools/Portfile 2007-11-18 17:39:33
UTC (rev 31218)
@@ -18,6 +18,8 @@
checksums md5 e47e75b43211a9094875d60502cc4e35
platforms darwin
+default_variants universal
The correct syntax would be:
default_variants +universal
But that doesn't work:
$ sudo port install kernel-tools
Error: Error executing universal: Default universal variant only
works with ports based on configure
Error: Unable to open port: Error evaluating variants
$
Perhaps you want to do this (as I do in e.g. the isightcapture port):
Index: Portfile
===
--- Portfile(revision 31348)
+++ Portfile(working copy)
@@ -18,7 +18,9 @@
checksums md5 e47e75b43211a9094875d60502cc4e35
platforms darwin
-default_variants universal
+# The files installed by kernel-tools are universal, so let's
advertise that.
+default_variants +universal
+variant universal {}
use_configure no
build {}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: unexpected error from port variant when port is not found
On Nov 20, 2007, at 13:38, Adam Mercer wrote:
I was just looking at the available variants for a port, I mistyped
the name of the port and received the following error message:
$ port variants misspelled_port
No port misspelled_port found.
can't read portinfo(porturl): no such element in array
while executing
set porturl $portinfo(porturl)
(uplevel body line 15)
invoked from within
uplevel 1 $block
(procedure foreachport line 16)
invoked from within
foreachport $portlist {
# search for port
if {[catch {mportsearch $portname no exact} result]} {
global errorInfo
...
(procedure action_variants line 4)
invoked from within
$action_proc $action $portlist [array get global_options]
(procedure process_cmd line 60)
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 /opt/local/bin/port line 2651)
$
I would expect the initial error of No port misspelled_port found,
but not the rest. This is with base from the top of the release_1_6
branch. Is this the expected behaviour?
Yeah, that's pretty messy! Sure would be nice not to have all that
cruft.
port info misspelled_port doesn't have this problem.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Trac emails -- how to stop getting them
On Nov 20, 2007, at 11:48 AM, James Berry wrote: Hi Juan, On Nov 19, 2007, at 5:54 AM, Juan Manuel Palacios wrote: On Nov 19, 2007, at 9:13 AM, N_Ox wrote: As Ryan said, with the new configuration anyone who had participated in the ticket (even just to change some properties) gets notified afterwards. We should only notify the reporter and the assignee by default, shouldn't we? That's Trac's notify updaters feature in action, with which anyone who's ever updated a ticket gets, m, notified ;-) I think the best behavior would be to turn off the notifiers feature. Then it's essentially opt-in: if you want to get updates for a ticket then you put yourself in the cc field, right? That seems perfect. James Good point! Will make it happen as soon as I get a hold of Bill. Thanks for the feedback! -jmpp ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: unexpected error from port variant when port is not found
On Nov 20, 2007, at 6:04 PM, Ryan Schmidt wrote: On Nov 20, 2007, at 13:38, Adam Mercer wrote: ---snip--- I would expect the initial error of No port misspelled_port found, but not the rest. This is with base from the top of the release_1_6 branch. Is this the expected behaviour? Yeah, that's pretty messy! Sure would be nice not to have all that cruft. port info misspelled_port doesn't have this problem. It's not expected behavior, and I just fixed it in r31358. Output is now limited to the expected Port not found and an exit status of 1, just as for the info action. Regards,... -jmpp ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 1.6.0 rc2 created (Was Re: [31193] branches/release_1_6/base/src)
On Nov 20, 2007, at 4:02 AM, Anders F Björklund wrote: Juan Manuel Palacios wrote: The HACKING file is still present, and the README file is still missing... ? All our documentation will definitely be moved to the guide, including the usual INSTALL, README, HACKING and similar text files found in open source projects. We already have some of these and we lack others, some are already in the guide and some still in our sources, but they will all eventually end up there, as our documentation authors manage to get to each of them. So does that means that it is now hands-off for everyone else, like with the manual pages ? No, not at all! The contents of all our documentation will eventually be sorta hands off rather than *completely* hands off because we want to keep a limited set of eyes and hands working on it, so that the overall result is more coherent than if just anyone who happens to walk by tosses his/her bit of information in it, which leads to disorganization and unreadability. But that by no means implies that others can't contribute, make suggestions, submit patches, discuss with Mark || Simon || Maun Suang, etc. Everyone should feel free to do so, please! Our guide and man pages are in this sorta hands off state 'cause they are already in hands of our writers, but docs like README, HACKING and others aren't yet, so feel free to claim it your own if you intend to ;-) As stated previously, we do intend for all those to eventually end up in the guide and therefore in this sorta hands off mode, but that's still in the future. Nevertheless, I say we keep the usual suspects in our sources but only as placeholders pointing readers to the relevant sections in the guide. What do you suggest we put in a README file? Just a dozen lines or so describing what it is, where it is, what it does and who did it. Like in http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/distpractice.html#README I know what the file is about... I was wondering if you had a draft for it ;-) Not a terrible thing if you don't, though, wont stop 1.6 ;-) Not sure if you wanted http://trac.macports.org/projects/macports/ticket/13141 to be in 1.6, That would be sweet! Do you have any ETC/deliverables? I added a small comment to the ticket which might be of help. Nah, myself I just thought the available pkg information should be better. I'm sorry, I didn't follow that comment. Mind elaborating? In any case, can you please take a look at what Ryan Maun Suang and I discussed on that ticket? A *.pkg/Contents/Resources/VolumeCheck script parsing the output of sw_vers(1) might do the trick for us, but you've been working on the pkg targets lately so you're probably much more fit than any of us to tell how we could achieve our goal on Tiger/ Leopard with traditional/flat pkg formats. Pretty please? ;-) or just http://trac.macports.org/projects/macports/ticket/12779 This relating only to the guide, it would be great to have it for the time we release 1.6.0 too, but I don't think we need to tie ourselves to it; it can happen at any moment (the guide is regenerated nightly). Guide and Website, it was. As in: wherever the Download link is presented. Ack! Will advise Mark on that one when he's available again. http://trac.macports.org/projects/macports/ticket/13145 as well (preflight stuff) Though I'm not incredibly happy with the state of this issue, it is a matter of fact that dealing with paths containing spaces can turn into a major headache for us (and I'm not just referring to MacPorts itself here, I can't imagine the thousands of ports that we distribute that might hide this type of bugs in their configurations and/or Makefiles uuughhh!). I tried bootstrapping MacPorts into a path with spaces and couldn't even get through our own configuration script, let alone get to my dp2mp- move upgrading rules to try to bullet-proof them. I know the original poster's problems creeps up when I try to upgrade his personal configuration file, as it's the path to his home dir what contains spaces and not MacPorts' prefix, but it's basically the same situation. I'm not suggesting that paths with spaces should be supported. I just wanted *volumes* with spaces in their names to be supported, while still installing in the usual /opt/local prefix locally on the volume... The original poster mentioned that a manual install works just fine, it's just the preflight script in the package that is referring to things with /Volumes/Litter Box prefixed to the regular paths ? I know someone else wanted to install in their home folder, while it was located on a path with spaces, but that is an issue for later... OK, will definitely try to fix it for that scenario. However, my recommendation still stands: avoid paths with spaces in them if possible! I
Re: 1.6.0 rc2 created (Was Re: [31193] branches/release_1_6/base/src)
On Nov 20, 2007, at 11:50 AM, James Berry wrote: Hi Juan, We were missing a flush after the prompt was output, before the get operation. I added that single line in r31338:31339. Hope that can get into 1.6. Sure it will! I'll only wait a bit more in case there's something more to merge to do it all at once. -jmpp ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
