January 2008 - macports-dev - lists.macosforge.org

Call for help testing 1.6.1 revamped postflight script
by Juan Manuel Palacios 14 Jan '08

14 Jan '08

As some of you may have seen, I've been improving the postflight script in the release_1_6 branch with the feedback I've received so far, plus some other relevant fixes/improvements. The final product is what will be in the 1.6.1 pkg installer, which I plan to upload to our website to replace the buggy 1.6.0 installers. I've tested it locally on both virgin and customized accounts, extensively, and have found it to work reliably so far. I'd now like to openly call for some wider testing in case I'm missing bugs that my environment is not surfacing. If you're up for it, please grab the script off this URL [1] and take it for a hard ride on whatever environment you can think of. I've tried to bullet-proof it for straight forward functionality in a default environment and to be as polite and non-disruptive as possible in a non-default one. Standard disclaimer applies about this code potentially having bugs that may disrupt your working environment, so do not use on a production machine/account if you can't afford any errors. For those of you wondering what I'm considering as a default environment, have a read at: http://guide.macports.org/#installing.binary.postflight.details That, plus the fact that I only do it for bash and tcsh shells, and the latter only as legacy support for Jaguar and previous accounts. I'm somewhat considering removing such support because tweaking tcsh configuration file has proven a tad difficult: 1) It's not easy to invoke a non-interactive, login tcsh shell session. In a nutshell, so far it has proven impossible for me. This limits my ability to properly test the environment to figure out what I need to add and what I don't, which takes me onto 2) below 2) It's not entirely clear to me whether I should write to ~/.tchsrc, ~/.cshrc or ~/.login (I've heard solid claims for all of them), barring my inability to properly test the environment; 3) barring 2), the form of the settings to be written varies ("set foo = bar" Vs. "setenv foo bar"); 4) I'm by no means a tcsh user, so all I can do is *guess* the best approach in unpleasant tcsh debugging sessions ;-) Various instances of 4), plus very kind help from both Eric Hall and Wilfredo Sanchez at times, have lead me to a combination of ~/.tcshrc with "setenv foo bar" statements, which I think works fairly well. But still, I'd love some experienced tcsh using eyes if available to shed some more light on this aspect of the script (thinking a bit more about it, resolving 1) above would probably solve this entire problem). So, without any further ado, I'd appreciate as much help I can get in testing this script and, in case of failure, getting detailed reports if possible. Success reports are also of course welcomed! Regards,... -jmpp [1] http://trac.macports.org/projects/macports/browser/branches/release_1_6/bas…

1 1

Re: [32715] trunk/doc-new/guide/xml/portfile-keywords.xml
by Ryan Schmidt 14 Jan '08

14 Jan '08

On Jan 11, 2008, at 16:51, markd(a)macports.org wrote: > - <para>If an epoch is used it must must never be > decreased or reset > - to zero, because this would always cause a port version > comparison > - to be incorrect after a port upgrade.</para> > + <para>An epoch is not needed for most ports. If an epoch > is used it > + must never be decreased without updating the port's > version number; > + this will cause port version comparisons to be > incorrect.</para> I was led to believe that an epoch should never be decreased, ever, once it has been added to a portfile, even if the port's version is increased. I understood that the epoch takes precedence over the version. Do you have new information to the contrary?

2 1

New port needs commit
by Luis O'Shea 14 Jan '08

14 Jan '08

Could someone commit the new port for asymptote? See ticket #13249 (http://trac.macosforge.org/projects/macports/ticket/13249) Thanks, Luis

5 8

Re: [32697] trunk/dports/devel/icu/Portfile
by Ryan Schmidt 14 Jan '08

14 Jan '08

On Jan 11, 2008, at 10:25, nox(a)macports.org wrote: > Revision: 32697 > http://trac.macosforge.org/projects/macports/changeset/32697 > Author: nox(a)macports.org > Date: 2008-01-11 08:25:00 -0800 (Fri, 11 Jan 2008) > > Log Message: > ----------- > icu: Updated to 3.8.1. > > Modified Paths: > -------------- > trunk/dports/devel/icu/Portfile > > Modified: trunk/dports/devel/icu/Portfile > =================================================================== > --- trunk/dports/devel/icu/Portfile 2008-01-11 16:15:06 UTC (rev > 32696) > +++ trunk/dports/devel/icu/Portfile 2008-01-11 16:25:00 UTC (rev > 32697) > @@ -4,7 +4,8 @@ > > name icu > set my_name icu4c > -version 3.8 > +version 3.8.1 > +set doc_version [join [lrange [split ${version} .] 0 1] _] > categories devel > platforms darwin freebsd > maintainers nox > @@ -25,20 +26,36 @@ > distfiles [suffix ${distname}-src] > > checksums [suffix ${distname}-src] \ > - sha1 4370becc68eab7a01292db62e1649239b1732a5b \ > - md5 67cc2650fbcae4c8e3ba5ce4dda4b072 \ > - rmd160 e9a0105477b54e6d3f222bf7741a61058c70665b \ > - ${distname}-docs.zip \ > + md5 a827dbc9d909febd4ec39b90386868ba \ > + sha1 c2b933aee6741c28956f1b87dc514dee49b949aa \ > + rmd160 d297330ff0eb91bff5ac91e59188f1751f899032 \ > + ${my_name}-${doc_version}-docs.zip \ > + md5 677b218cbca2acc304b9771c63bd69bf \ > sha1 94b47b5dd88bce15dab608719efbbd405d15e912 \ > - md5 677b218cbca2acc304b9771c63bd69bf \ > rmd160 927f4466758722e958b90a2bae873b11da222e88 > > worksrcdir ${name}/source > set docdir ${prefix}/share/doc/${name}-${version} > > +post-patch { > + reinplace "s;install_name ;install_name ${prefix}/lib/;" $ > {worksrcpath}/config/mh-darwin > +} > + > +configure.cmd ./runConfigureICU MacOSX The portfile claims to work on the freebsd platform in addition to darwin. Is this configure.cmd appropriate on FreeBSD? > configure.args --mandir=${prefix}/share/man \ > --disable-samples > > +# ICU wants to build with -O3, let's do as it wants. > +configure.cflags-delete -O2 > + > +pre-configure { > + # The -delete statement above may lead to configure.cflags > variable being unset > + if {! [info exists configure.cflags]} { > + configure.cflags > + } > +} What you're doing here in the pre-configure phase, is this a MacPorts base bug that needs to be fixed?

2 1

Subject: [32751] net/dhcp startupitem
by markd＠macports.org 13 Jan '08

13 Jan '08

>Mark, > >It works fine if I use this: > >startupitem.create yes >startupitem.name dhcpd >startupitem.executable ${prefix}/sbin/dhcpd -f >startupitem.netchange yes > >How's that? The startupitem executable is preferred if it works automatically I think; but if it doesn't for some reason at that point I see no obligation to prefer a workaround using the executable type to using the "script" type startupitem. So I think leaving it as you had it is fine; I can't comment on whether starting in foreground mode is a good method, but as I said under the circumstances your current solution is perfectly fine in my opinion. > > >On Jan 13, 2008, at 12:36 PM, Blair Zajac wrote: > >> Hi Mark, >> >> The guild says this: >> >> "startupitem.executable. Specifies the name of the daemon to be run >> in the background. It may have multiple arguments, but they must be >> appropriate for a call to exec; arbitrary shell code may not be used." >> >> Should the actual daemon remain in the foreground so that the parent >> parent process can wait() on it? Should the daemon make a PID file >> in a known location? >> >> The guide could expand on this a bit. I hope James is listening out there and can comment on this. I think if one really wanted to use an executable startupitem, I think statupitem.pidfile could be used and that particular use isn't documented, but probably because I didn't expect the need for it to ever occur, as it has for dhcp. But as I said, if startupitm executable doesn't work in default setup, then I see no further advantage in using it as opposed to a "script" startupitem. Thanks for giving this attention. Mark

1 0

Subject: [32751] net/dhcp startupitem
by markd＠macports.org 13 Jan '08

13 Jan '08

Hi Blair, Executable startupitems are the preferred type. Daemondo can track pids automatically and reliably restart an application if it quits. See the guide on this: http://guide.macports.org/#reference.startupitems Given how startupitem executables work, I don't see an advantage to reverting to a "script" startupitem. Or is there something I am missing particular to dhcp? Mark >Log Message: >----------- >Use a startupitem method that uses dhcpd's PID file. >Modified Paths: >-------------- > trunk/dports/net/dhcp/Portfile > >Modified: trunk/dports/net/dhcp/Portfile >=================================================================== >--- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev >32750) >+++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev >32751) >@@ -4,7 +4,7 @@ > > name dhcp > version 3.1.0 >-revision 1 >+revision 2 > categories net > description ISC dhcpd server > long_description ISC's Dynamic Host Configuration Protocol >Distribution \ >@@ -40,8 +40,9 @@ > configure.pre_args > > startupitem.create yes >-startupitem.name dhcpd >-startupitem.executable ${prefix}/sbin/dhcpd >+startupitem.start "${prefix}/sbin/dhcpd" >+startupitem.restart "/bin/kill -HUP \$(/bin/cat >${prefix}/var/run/dhcpd.pid)" >+startupitem.stop "/bin/kill -15 \$(/bin/cat >${prefix}/var/run/dhcpd.pid)"

2 3

Fwd: New port needs commit
by Rolf Würdemann 13 Jan '08

13 Jan '08

Anfang der weitergeleiteten E-Mail: > Von: Rolf Würdemann <rowue(a)digitalis.org> > Datum: 13. Januar 2008 20:03:18 MEZ > An: Luis O'Shea <loshea(a)gmail.com> > Betreff: Re: New port needs commit > > > Am 13.01.2008 um 19:59 schrieb Luis O'Shea: > >> On Jan 13, 2008, at 9:30 AM, Simon Ruderich wrote: >>> On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote: >>>> Could someone commit the new port for asymptote? See ticket #13249 >>>> (http://trac.macosforge.org/projects/macports/ticket/13249) >>>> >>>> Thanks, >>>> >>>> Luis >>> >>> Hi, >>> >>> I just committed it [1] with one minor change. I added a post- >>> activate hook with >>> calls mktexlsr to make sure asymptote is found. >> >> Thanks. >> >> Now that the port is committed I wanted to make sure it worked, >> but I have run into a problem. >> >> After the commit, I uninstalled asymptote, removed the reference >> to my local port hierarchy from sources.conf, and did a >> selfupdate. However port seemed to not find the new asymptote port: >> >> % port info asymptote >> Error: Port asymptote not found >> >> But ${prefix}/var/macports/sources/rsync.macports.org/release/ >> ports/graphics/asymptote/Portfile does exist. I tried deleting $ >> {prefix}/var/macports/sources/rsync.macports.org/release/ports/ >> PortIndex and doing another selfupdate, but that did not help. >> >> What am I doing wrong? > > The Portindex is updated every 12 Hours, > so it will take a little time to see your Port in Macports ;) > >> >> Thanks, >> >> Luis >> > > Reg's > > Rolf >> _______________________________________________ >> macports-dev mailing list >> macports-dev(a)lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev > > -- > Security is an illusion - Datasecurity twice > Rolf Würdemann - private: rowue(a)digitalis.org - office: > rowue(a)crew-gmbh.de > GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 > 31B6 67F0 D02F > jabber: rowue(a)digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF > 53C3E932 > > -- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue(a)digitalis.org - office: rowue(a)crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue(a)digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932

1 0

Port Change (gtkglext) needs to get committed
by Rolf Würdemann 13 Jan '08

13 Jan '08

Hi ... the Changes of the Portfile for gtkglext needs to get committed. #13624 http://trac.macports.org/projects/macports/ticket/13624 The Maintainer seems to doesn't respond. After this is done, #13517 (http://trac.macports.org/projects/ macports/ticket/13517) can be closed (dealing with the same issue - gtkglext on leopard) Thanks, Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue(a)digitalis.org - office: rowue(a)crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue(a)digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932

1 0

Port update (qucs) needs to get commited
by Rolf Würdemann 13 Jan '08

13 Jan '08

Hi Could someone commit the update of qucs to 0.0.13? See Ticket: #13826 http://trac.macports.org/projects/macports/ticket/13826 Thanks, Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue(a)digitalis.org - office: rowue(a)crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue(a)digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932

1 0

apache mirrors
by Ryan Schmidt 13 Jan '08

13 Jan '08

In base/src/port1.0/resources/fetch/mirror_sites.tcl we define the apache mirror sites this way: set portfetch::mirror_sites::sites(apache) { http://www.apache.org/dist/ http://archive.apache.org/dist/ http://apache.planetmirror.com.au/dist/ ftp://ftp.planetmirror.com/pub/apache/dist/ ftp://ftp.is.co.za/Apache/dist/ ftp://ftp.infoscience.co.jp/pub/net/apache/dist/ } But at http://www.apache.org/dist/ it says in bold letters Please do not download from apache.org! And at http://www.apache.org/dist/httpd/ it says Download from your nearest mirror site! Do not download from www.apache.org. Please use a mirror site to help us save apache.org bandwidth. There are dozens of mirrors available. Should we add these to our apache mirror sites list? They provide a randomized or perhaps load-balanced download CGI, e.g.: http://www.apache.org/dyn/closer.cgi/apr/apr-0.9.17.tar.bz2 but that doesn't redirect you to the file; it returns an HTML page which contains a link to download the file. We could write a wrapper PHP script for this and stick it on www.macports.org and use that as the first apache mirror download location. This would make better use of the available mirrors and only fall back to www.apache.org and the rest if the script fails for some reason. I'd be happy to write that script if it's decided it's a good idea.

1 0