Small bug in ports.php
Sometimes transcripts are the best: [14:40] @<jmpp> there is a bug in ports.php by which multiple maintainers are listed as 'maintainer1maintainer2' [14:40] @<jmpp> but I'll look into it later [14:41] @<jmpp> I know where it originates [14:41] @<jmpp> I made a change to how the sql instructions are created in PortIndex2MySQL [14:41] @<jmpp> but I didn't adapt the ports.php client in turn [14:41] @<jmpp> but, again, I'll look into it later ;) That bug might also affect the categories. From PortIndex2MySQL: set primary 1 foreach category $categories { set category [sql_escape $category] puts $sqlfile_fd "INSERT INTO categories VALUES ('$portname', '$category', $primary);" incr primary } set primary 1 foreach maintainer $maintainers { set maintainer [sql_escape $maintainer] puts $sqlfile_fd "INSERT INTO maintainers VALUES ('$portname', '$maintainer', $primary);" incr primary } But it seems like I was mistaken in the assertion I made in the transcript above. I reverted the behavior of the primary key for categories and maintainers in r31415 and regenerated the database with the new script, but the behavior persists as shown by a simple query such as http://apollo.homeunix.net/macports/ports.php?by=cat&substr=lang I'd be grateful if anyone beats me to looking into this issue... Ryan? ;-) Regards,... -jmpp PS: In trunk/www/ports.php, the sections querying the db for maintainer and category information are clearly labeled /* MAINTAINERS */ and /* CATEGORIES */, respectively.
On Nov 22, 2007, at 13:09, Juan Manuel Palacios wrote:
Sometimes transcripts are the best:
[14:40] @<jmpp> there is a bug in ports.php by which multiple maintainers are listed as 'maintainer1maintainer2' [14:40] @<jmpp> but I'll look into it later [14:41] @<jmpp> I know where it originates [14:41] @<jmpp> I made a change to how the sql instructions are created in PortIndex2MySQL [14:41] @<jmpp> but I didn't adapt the ports.php client in turn [14:41] @<jmpp> but, again, I'll look into it later ;)
I believe I fixed it in r31443. I did not test it locally because I haven't looked into what's required to set up a local installation of the web site. But it's a very simple change and I believe it's correct. If there's a document telling me what to do to set up a local installation of the site, please let me know. I already have apache2, php5 and mysql5 installed and have no trouble administering them so as long as I just have to install a database and user that's no trouble.
That bug might also affect the categories.
Ports with multiple categories look fine.
From PortIndex2MySQL:
set primary 1 foreach category $categories { set category [sql_escape $category] puts $sqlfile_fd "INSERT INTO categories VALUES ('$portname', '$category', $primary);" incr primary }
set primary 1 foreach maintainer $maintainers { set maintainer [sql_escape $maintainer] puts $sqlfile_fd "INSERT INTO maintainers VALUES ('$portname', '$maintainer', $primary);" incr primary }
But it seems like I was mistaken in the assertion I made in the transcript above. I reverted the behavior of the primary key for categories and maintainers in r31415 and regenerated the database with the new script, but the behavior persists as shown by a simple query such as http://apollo.homeunix.net/macports/ports.php? by=cat&substr=lang
I'd be grateful if anyone beats me to looking into this issue... Ryan? ;-)
Regards,...
-jmpp
PS: In trunk/www/ports.php, the sections querying the db for maintainer and category information are clearly labeled /* MAINTAINERS */ and /* CATEGORIES */, respectively.
Thanks, those comments are good to have in the file. :) Made it easier to find.
On 24 Nov, 2007, at 5:58, Ryan Schmidt wrote:
I believe I fixed it in r31443. I did not test it locally because I haven't looked into what's required to set up a local installation of the web site. But it's a very simple change and I believe it's correct. If there's a document telling me what to do to set up a local installation of the site, please let me know. I already have apache2, php5 and mysql5 installed and have no trouble administering them so as long as I just have to install a database and user that's no trouble.
That bug might also affect the categories.
Ports with multiple categories look fine.
Indeed you did [1]. However, I'm now noticing that the order of those maintainers and categories is wrong. Do we not enforce any ordering in the SELECT statement? I don't believe MySQL guarantees any. [1] http://macports.sfiera.net/ports.php?by=name&substr=gnutls As for setting up a mirror of the website, it seems to have gotten much more complex to get the PortIndex2MySQL script working than it was when I set up my mirror. Maybe jmpp can enlighten us as to how to get /opt/local/share/macports/resources/portmgr to be created? However, the question makes me think: once the MacPorts website is moved over, we want to remove the "not official" notice. However, there's still a use for mirrors, for testing purposes. So, perhaps we should add an additional warning if !preg_match('(www.)?macports.org', $_SERVER['HTTP_HOST']) to the effect of "this is a mirror and may not contain up-to-date information". Regards, Chris
On Nov 24, 2007, at 12:42 PM, Chris Pickel wrote:
On 24 Nov, 2007, at 5:58, Ryan Schmidt wrote:
I believe I fixed it in r31443. I did not test it locally because I haven't looked into what's required to set up a local installation of the web site. But it's a very simple change and I believe it's correct. If there's a document telling me what to do to set up a local installation of the site, please let me know. I already have apache2, php5 and mysql5 installed and have no trouble administering them so as long as I just have to install a database and user that's no trouble.
That bug might also affect the categories.
Ports with multiple categories look fine.
Indeed you did [1]. However, I'm now noticing that the order of those maintainers and categories is wrong. Do we not enforce any ordering in the SELECT statement? I don't believe MySQL guarantees any.
Yes, we impose an ordering in our maintainers query: $nquery = "SELECT maintainer FROM $portsdb.maintainers WHERE portfile='" . mysql_real_escape_string($row['name']) . "' ORDER BY is_primary DESC, maintainer"; And the primary key is enforced by the PortIndex2MySQL script for categories and maintainers, so I don't really know what's at fault here. At first I thought that it had to be order in which addresses appear in your portfile (gnutls), but clicking on a single link reveals that's not it either. I'll investigate.
As for setting up a mirror of the website, it seems to have gotten much more complex to get the PortIndex2MySQL script working than it was when I set up my mirror. Maybe jmpp can enlighten us as to how to get /opt/local/share/macports/resources/portmgr to be created?
The website is very easy to mirror: pre-1) Setup your web server to work with php & mysql (I don't think we have any versioning requirements on any of those); 1) manually create a database for the site (just the DB entry, PortIndex2MySQL does all the tables and records): *) PortIndex2MySQL has parameters for write access to that DB, including its name, so adapt them as necessary (I standardized variable naming across the board in r31455 & r31456, so remember to svn up first); *) trunk/www/includes/common.inc has parameters for read access to the DB, including its name, so adapt them as necessary (I standardized variable naming across the board in r31455 & r31456, so remember to svn up first); 2) setup the PortIndex2MySQL script to run periodically; we provide both the script and a launchd plist, but their installation locations and run frequency are completely arbitrary: *) to craete the script off of its .tcl file you first have to run configure for your MacPorts base sources and then cd into portmgr/jobs and "make"; *) I use the ${prefix}/share/macports/resources/portmgr location simply because that's where the script used to be installed long ago, but we no longer do that (totally unnecessary to install that script, I believe, so I create the location manually); *) the $passwdfile variable in PortIndex2MySQL has to be adapted to point it to a file with the password for your $portsdb_name database, and it has to be an absolute path as otherwise the script will not be able to find the file when running off launchd (which seems to do a chdir to / for its jobs); *) I run the script twice a day, exactly an hour after the refreshed index comes in (no sense at all in running it more frequently, as it takes all of its information from the index), with its plist installed into /Library/LaunchDaemons; *) the $SPAM_LOVERS variable in the script is adapted to send mail to me locally in case something goes wrong, as it wouldn't make any sense at all having that information go to this list; 3) create a location for your webserver to access the appropriate files in trunk/www (which on my server it's just a symlink to precisely my trunk/www checkout); And that's it! It might seem like a long list for an "easy" setup, but if you read over it again you'll realize that I'm just being verbose in explanations (as always ;-), but the steps themselves are really short and easy.
However, the question makes me think: once the MacPorts website is moved over, we want to remove the "not official" notice.
Sure thing! I have this on my list as the last (victorious!) commit I'll make to those files right before we move the files over to the official web server :-D
However, there's still a use for mirrors, for testing purposes. So, perhaps we should add an additional warning if !preg_match('(www.)? macports.org', $_SERVER['HTTP_HOST']) to the effect of "this is a mirror and may not contain up-to-date information".
Very good suggestion indeed! Will add it once we go live with the website. Regards,.... -jmpp
On Nov 24, 2007, at 2:59 PM, Juan Manuel Palacios wrote: And because I always forget something no matter how many times I go over my mails before I send them.... sigh!
The website is very easy to mirror:
pre-1) Setup your web server to work with php & mysql (I don't think we have any versioning requirements on any of those);
The only one versioning requirement we have is for the PortIndex2MySQL script itself, which uses the new macports1.0 API for interface initialization and therefore does not work against pre-1.6 sources (one of the primary reasons why we haven't gone live with the new site on Mac OS Forge, as they rely on MacPorts itself for software management for all the projects there and, understandably so, are staying put on 1.5.2 until we release 1.6.0). Regards,... -jmpp
On Nov 24, 2007, at 12:59, Juan Manuel Palacios wrote:
On Nov 24, 2007, at 12:42 PM, Chris Pickel wrote:
On 24 Nov, 2007, at 5:58, Ryan Schmidt wrote:
I believe I fixed it in r31443. I did not test it locally because I haven't looked into what's required to set up a local installation of the web site. But it's a very simple change and I believe it's correct. If there's a document telling me what to do to set up a local installation of the site, please let me know. I already have apache2, php5 and mysql5 installed and have no trouble administering them so as long as I just have to install a database and user that's no trouble.
That bug might also affect the categories.
Ports with multiple categories look fine.
Indeed you did [1]. However, I'm now noticing that the order of those maintainers and categories is wrong. Do we not enforce any ordering in the SELECT statement? I don't believe MySQL guarantees any.
Yes, we impose an ordering in our maintainers query:
$nquery = "SELECT maintainer FROM $portsdb.maintainers WHERE portfile='" . mysql_real_escape_string($row['name']) . "' ORDER BY is_primary DESC, maintainer";
And the primary key is enforced by the PortIndex2MySQL script for categories and maintainers, so I don't really know what's at fault here. At first I thought that it had to be order in which addresses appear in your portfile (gnutls), but clicking on a single link reveals that's not it either. I'll investigate.
I can take a look too once I get a local environment set up.
As for setting up a mirror of the website, it seems to have gotten much more complex to get the PortIndex2MySQL script working than it was when I set up my mirror. Maybe jmpp can enlighten us as to how to get /opt/local/share/macports/resources/portmgr to be created?
The website is very easy to mirror:
pre-1) Setup your web server to work with php & mysql (I don't think we have any versioning requirements on any of those);
1) manually create a database for the site (just the DB entry, PortIndex2MySQL does all the tables and records): *) PortIndex2MySQL has parameters for write access to that DB, including its name, so adapt them as necessary (I standardized variable naming across the board in r31455 & r31456, so remember to svn up first); *) trunk/www/includes/common.inc has parameters for read access to the DB, including its name, so adapt them as necessary (I standardized variable naming across the board in r31455 & r31456, so remember to svn up first);
2) setup the PortIndex2MySQL script to run periodically; we provide both the script and a launchd plist, but their installation locations and run frequency are completely arbitrary: *) to craete the script off of its .tcl file you first have to run configure for your MacPorts base sources and then cd into portmgr/ jobs and "make"; *) I use the ${prefix}/share/macports/resources/portmgr location simply because that's where the script used to be installed long ago, but we no longer do that (totally unnecessary to install that script, I believe, so I create the location manually); *) the $passwdfile variable in PortIndex2MySQL has to be adapted to point it to a file with the password for your $portsdb_name database, and it has to be an absolute path as otherwise the script will not be able to find the file when running off launchd (which seems to do a chdir to / for its jobs); *) I run the script twice a day, exactly an hour after the refreshed index comes in (no sense at all in running it more frequently, as it takes all of its information from the index), with its plist installed into /Library/LaunchDaemons; *) the $SPAM_LOVERS variable in the script is adapted to send mail to me locally in case something goes wrong, as it wouldn't make any sense at all having that information go to this list;
3) create a location for your webserver to access the appropriate files in trunk/www (which on my server it's just a symlink to precisely my trunk/www checkout);
And that's it! It might seem like a long list for an "easy" setup, but if you read over it again you'll realize that I'm just being verbose in explanations (as always ;-), but the steps themselves are really short and easy.
Got the database created, a user created, edited the script to point to a password file, changed the spam lovers to me, ran make. Am now trying to run the script. $ env tclsh PortIndex2MySQL It tickles my hard drive for awhile, then ends with no output. $ echo $? 1 $ So it's failing but I don't know why. I see there should be ui_error output on failures. How can I see it?
However, the question makes me think: once the MacPorts website is moved over, we want to remove the "not official" notice.
Sure thing! I have this on my list as the last (victorious!) commit I'll make to those files right before we move the files over to the official web server :-D
However, there's still a use for mirrors, for testing purposes. So, perhaps we should add an additional warning if !preg_match ('(www.)?macports.org', $_SERVER['HTTP_HOST']) to the effect of "this is a mirror and may not contain up-to-date information".
Very good suggestion indeed! Will add it once we go live with the website.
Properly: <?php if (isset($_SERVER['HTTP_HOST']) && !preg_match('%(^|\.)macports\.org$ %', $_SERVER['HTTP_HOST'])) { echo "warning"; } ?> Some clients don't set $_SERVER['HTTP_HOST'] so you must test for its existence first. Fixed the regular expression to actually be a regular expression. Of course we already have a redirect in place from macports.org to www.macports.org so nobody will ever be accessing our web site as "http://macports.org/" (it'll always be "http://www.macports.org/").
On Nov 24, 2007, at 6:59 PM, Ryan Schmidt wrote:
Got the database created, a user created, edited the script to point to a password file, changed the spam lovers to me, ran make. Am now trying to run the script.
$ env tclsh PortIndex2MySQL
No need to do this, the script already has a "#!/usr/bin/env tclsh" shebang (you can run it as "./PortIndex2MySQL").
It tickles my hard drive for awhile, then ends with no output.
$ echo $? 1 $
So it's failing but I don't know why. I see there should be ui_error output on failures. How can I see it?
The script creates a /tmp/portsdb.log file where all runtime activity is logged and then piped to the /usr/sbin/sendmail program to get it through to $SPAM_LOVERS, so you might want to try to find that file. In any case, you should first run the script from the shell before installing it for launchd. Assuming I didn't introduce any bugs in my recent edits, all possible runtime failures should be in the contents of that log file and then in your mailbox (in the case of these "accounted for failures" --like a failure to connect to the mysqld server or no password file found--, the script cleans up after itself upon exit and removes everything it creates, including the log file); if I did introduce, say, a Tcl syntactic bug, then you should get a backtrace spill on your shell. Please let me know how it goes so that I can correct potential bugs.
Properly:
<?php
if (isset($_SERVER['HTTP_HOST']) && !preg_match('%(^|\.)macports\.org $%', $_SERVER['HTTP_HOST'])) { echo "warning"; }
?>
Some clients don't set $_SERVER['HTTP_HOST'] so you must test for its existence first.
Fixed the regular expression to actually be a regular expression.
Of course we already have a redirect in place from macports.org to www.macports.org so nobody will ever be accessing our web site as "http://macports.org/ " (it'll always be "http://www.macports.org/").
Thanks for this info Ryan, will code it in shortly! Regards,... -jmpp
On Nov 24, 2007, at 18:11, Juan Manuel Palacios wrote:
On Nov 24, 2007, at 6:59 PM, Ryan Schmidt wrote:
Got the database created, a user created, edited the script to point to a password file, changed the spam lovers to me, ran make. Am now trying to run the script.
$ env tclsh PortIndex2MySQL
No need to do this, the script already has a "#!/usr/bin/env tclsh" shebang (you can run it as "./PortIndex2MySQL").
I couldn't, because "make" does not set the execute bit on PortIndex2MySQL. "make" should probably do that, shouldn't it?
It tickles my hard drive for awhile, then ends with no output.
$ echo $? 1 $
So it's failing but I don't know why. I see there should be ui_error output on failures. How can I see it?
The script creates a /tmp/portsdb.log file where all runtime activity is logged and then piped to the /usr/sbin/sendmail program to get it through to $SPAM_LOVERS, so you might want to try to find that file.
In any case, you should first run the script from the shell before installing it for launchd. Assuming I didn't introduce any bugs in my recent edits, all possible runtime failures should be in the contents of that log file and then in your mailbox (in the case of these "accounted for failures" --like a failure to connect to the mysqld server or no password file found--, the script cleans up after itself upon exit and removes everything it creates, including the log file); if I did introduce, say, a Tcl syntactic bug, then you should get a backtrace spill on your shell. Please let me know how it goes so that I can correct potential bugs.
/tmp/portsdb.log was not present; it must've gotten cleaned up automatically. I caught it with tail -f while the script was running and it said: [snip] rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/.ChangeLog.Uw8VSO" failed: Permission denied (13) rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/config/.RELEASE_URL.hbE1ot" failed: Permission denied (13) rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/config/.dp_version.TYaMkG" failed: Permission denied (13) [snip] So it's trying to do a selfupdate and failing because it's not root. Running it as root got me past that, though I'd rather not have to run it as root. I'll selfupdate my MacPorts myself when I feel like it. :) Next error encountered was this: Error: CHILDSTATUS 17126 1: ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (61) True: I have networking support deliberately disabled on my MySQL so that only local connections are possible. Changing "set dbhost 127.0.0.1" to "set dbhost localhost" fixed it, and now I have the data in my MySQL database and will turn my attention to the PHP files. ("localhost" and "127.0.0.1" are not equivalent to MySQL. The former means "use the socket file and bypass the network stack" and is supposed to be faster, while the latter accesses the network stack as it would for any other IP address.)
On Nov 24, 2007, at 8:33 PM, Ryan Schmidt wrote:
On Nov 24, 2007, at 18:11, Juan Manuel Palacios wrote:
On Nov 24, 2007, at 6:59 PM, Ryan Schmidt wrote:
Got the database created, a user created, edited the script to point to a password file, changed the spam lovers to me, ran make. Am now trying to run the script.
$ env tclsh PortIndex2MySQL
No need to do this, the script already has a "#!/usr/bin/env tclsh" shebang (you can run it as "./PortIndex2MySQL").
I couldn't, because "make" does not set the execute bit on PortIndex2MySQL. "make" should probably do that, shouldn't it?
Cant exactly think of a way to do it without calling an installation routine (even if to the same directory, I really see no sense in installing this script anywhere else on a regular basis), as all I currently do in the Makefile is a reinplace: edit = sed \ -e 's,@TCL_PACKAGE_DIR@,$(TCL_PACKAGE_DIR),g' (...) PortIndex2MySQL: PortIndex2MySQL.tcl ${edit} $< > $@
/tmp/portsdb.log was not present; it must've gotten cleaned up automatically.
Expected behavior.
I caught it with tail -f while the script was running and it said:
What about in your inbox? Didn't the mailing functionality work?
[snip] rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/.ChangeLog.Uw8VSO" failed: Permission denied (13) rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/config/.RELEASE_URL.hbE1ot" failed: Permission denied (13) rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/config/.dp_version.TYaMkG" failed: Permission denied (13) [snip]
So it's trying to do a selfupdate and failing because it's not root. Running it as root got me past that, though I'd rather not have to run it as root. I'll selfupdate my MacPorts myself when I feel like it. :)
The script needs to refresh the ports tree in order to regen the db with up-to-date information, so a 'sync' operation fits the bill... and while at it, I thought why not go all the way and simply call out to "selfupdate" ;-). Depending on your setup, yes, you might need root powers to do that (either sync and/or selfupdate).
Next error encountered was this:
Error: CHILDSTATUS 17126 1: ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (61)
True: I have networking support deliberately disabled on my MySQL so that only local connections are possible. Changing "set dbhost 127.0.0.1" to "set dbhost localhost" fixed it,
The most recent version of the script in svn is using localhost, DuBois has taught me well so I changed that a while ago ;-) You must be using an outdated version.
and now I have the data in my MySQL database and will turn my attention to the PHP files.
Great, I'd love to have your PHP experienced eyes on them! Regards,... -jmpp
On 24 Nov 2007, at 14:05, Juan Manuel Palacios wrote:
The only one versioning requirement we have is for the PortIndex2MySQL script itself, which uses the new macports1.0 API for interface initialization and therefore does not work against pre-1.6 sources (one of the primary reasons why we haven't gone live with the new site on Mac OS Forge, as they rely on MacPorts itself for software management for all the projects there and, understandably so, are staying put on 1.5.2 until we release 1.6.0).
I had not known that we are eating our own dog food. That's very cool. Randall Wood rhwood@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."
On Nov 25, 2007, at 6:04 AM, Randall Wood wrote:
On 24 Nov 2007, at 14:05, Juan Manuel Palacios wrote:
The only one versioning requirement we have is for the PortIndex2MySQL script itself, which uses the new macports1.0 API for interface initialization and therefore does not work against pre-1.6 sources (one of the primary reasons why we haven't gone live with the new site on Mac OS Forge, as they rely on MacPorts itself for software management for all the projects there and, understandably so, are staying put on 1.5.2 until we release 1.6.0).
I had not known that we are eating our own dog food. That's very cool.
Yes, it is! ;-) -jmpp
On Nov 24, 2007, at 19:26, Juan Manuel Palacios wrote:
On Nov 24, 2007, at 8:33 PM, Ryan Schmidt wrote:
On Nov 24, 2007, at 18:11, Juan Manuel Palacios wrote:
On Nov 24, 2007, at 6:59 PM, Ryan Schmidt wrote:
$ env tclsh PortIndex2MySQL
No need to do this, the script already has a "#!/usr/bin/env tclsh" shebang (you can run it as "./PortIndex2MySQL").
I couldn't, because "make" does not set the execute bit on PortIndex2MySQL. "make" should probably do that, shouldn't it?
Cant exactly think of a way to do it without calling an installation routine (even if to the same directory, I really see no sense in installing this script anywhere else on a regular basis), as all I currently do in the Makefile is a reinplace:
edit = sed \ -e 's,@TCL_PACKAGE_DIR@,$(TCL_PACKAGE_DIR),g'
(...)
PortIndex2MySQL: PortIndex2MySQL.tcl ${edit} $< > $@
Adding chmod 755 $@ after that line seems to work.
/tmp/portsdb.log was not present; it must've gotten cleaned up automatically.
Expected behavior.
I caught it with tail -f while the script was running and it said:
What about in your inbox? Didn't the mailing functionality work?
I don't seem to have gotten any mail, no...
[snip] rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/.ChangeLog.Uw8VSO" failed: Permission denied (13) rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/config/.RELEASE_URL.hbE1ot" failed: Permission denied (13) rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/ release/base/config/.dp_version.TYaMkG" failed: Permission denied (13) [snip]
So it's trying to do a selfupdate and failing because it's not root. Running it as root got me past that, though I'd rather not have to run it as root. I'll selfupdate my MacPorts myself when I feel like it. :)
The script needs to refresh the ports tree in order to regen the db with up-to-date information, so a 'sync' operation fits the bill... and while at it, I thought why not go all the way and simply call out to "selfupdate" ;-). Depending on your setup, yes, you might need root powers to do that (either sync and/or selfupdate).
My feeling is that this is "PortIndex2MySQL". It's not "SelfUpdateThenPortIndex2MySQL". Especially on my local machine, where I just want any information about the ports in MySQL and don't care if it's up to date because I'm just testing the web site code, I don't want to be forced to sync or selfupdate every time, especially because that requires root (on my setup and I expect on most others), and a MySQL import script should not require root. I'll comment out the selfupdate step locally for now.
Next error encountered was this:
Error: CHILDSTATUS 17126 1: ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (61)
True: I have networking support deliberately disabled on my MySQL so that only local connections are possible. Changing "set dbhost 127.0.0.1" to "set dbhost localhost" fixed it,
The most recent version of the script in svn is using localhost, DuBois has taught me well so I changed that a while ago ;-) You must be using an outdated version.
Gah! I was on the release_1_6 branch. :)
On Nov 25, 2007, at 2:33 PM, Ryan Schmidt wrote:
PortIndex2MySQL: PortIndex2MySQL.tcl ${edit} $< > $@
Adding
chmod 755 $@
after that line seems to work.
Thanks for that hint, I'll give it a try.
The script needs to refresh the ports tree in order to regen the db with up-to-date information, so a 'sync' operation fits the bill... and while at it, I thought why not go all the way and simply call out to "selfupdate" ;-). Depending on your setup, yes, you might need root powers to do that (either sync and/or selfupdate).
My feeling is that this is "PortIndex2MySQL". It's not "SelfUpdateThenPortIndex2MySQL". Especially on my local machine, where I just want any information about the ports in MySQL and don't care if it's up to date because I'm just testing the web site code, I don't want to be forced to sync or selfupdate every time, especially because that requires root (on my setup and I expect on most others), and a MySQL import script should not require root. I'll comment out the selfupdate step locally for now.
The best route in that case is definitely to comment out selfupdate (or the equivalent sync), which is indeed what I do when I test the script over and over. But understand that on the website the ports information has to be always up to date, so, again, a sync operation fits the bill.
The most recent version of the script in svn is using localhost, DuBois has taught me well so I changed that a while ago ;-) You must be using an outdated version.
Gah! I was on the release_1_6 branch. :)
Yeah, I've been working on in on trunk and therefore what's in release_1_6 now is out of date. I'll be remerging soon. Regards,... -jmpp
On Nov 25, 2007, at 2:33 PM, Ryan Schmidt wrote:
PortIndex2MySQL: PortIndex2MySQL.tcl ${edit} $< > $@
Adding
chmod 755 $@
after that line seems to work.
Done in r31519.
What about in your inbox? Didn't the mailing functionality work?
I don't seem to have gotten any mail, no...
Very strange! Of all the times that I either made the script fail on purpose to test my error detection, or when it failed unexpectedly for whatever reason, I either got a backtrace dump on my terminal for the latter (mostly syntactic errors related) or a nice message in my inbox explaining what went wrong. Please do let me know if you find out why you didn't get mails for the failures you experienced, would love to fix lurking bugs if any! Regards,... -jmpp
participants (4)
-
Chris Pickel
-
Juan Manuel Palacios
-
Randall Wood
-
Ryan Schmidt