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

Re: Meet our brand new documentation! (Fwd: [31887] trunk/www/includes/common.inc)
by Simon Ruderich 11 Dec '07

11 Dec '07

On Tue, Dec 11, 2007 at 10:54:52AM -0800, William Siegrist wrote: > It is on a 12 hour cycle just like the "Available Ports" page is. Eventually > it will be handled upon each commit to the doc-new directory, but I need to > improve our svn hook architecture first. > > -Bill Hi Bill, thanks for your answer. Good to know. Also thank you for your help with macports homepage. Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229

1 0

ChangeLog, 1.6.0 and trunk versions
by Ryan Schmidt 11 Dec '07

11 Dec '07

I'd like to add something into the ChangeLog about the new "port load" and "port unload" commands, implemented in r31500 and fixed in r31771. The ChangeLog lists version 1.5.2's changes, and then above that, we have a whole bunch of changes classified "unreleased". "port load" and "port unload" are not in the 1.6.0 branch. Where do I add information about this to the changelog? And how do we know which of these unreleased changes in the ChangeLog will be released in 1.6.0 and which are still only in trunk? Related: The version of MacPorts in trunk should be updated to 1.7.0 and a 1.7.0 version should be added to Trac so we can file accurate bugs. For example, all the bugs about the missing "cd" command, which are currently assigned to the 1.6.0 version, should be changed to 1.7.0, since 1.6.0 now will have the "cd" command again.

2 2

Guide regen job
by Juan Manuel Palacios 11 Dec '07

11 Dec '07

Hey guys! I'm happy to announce that I'm now working with Bill to setup our guide on the Mac OS Forge servers as http://guide.macports.org. In doing that I'm also testing it's automated regen, so that we can trigger it as a post-commit hook against the trunk/doc-new sources. We're experiencing some errors and warnings, however: alpha:/tmp/mpdoctest root# make guide mkdir -p guide/html cp guide/resources/docbook.css guide/html/docbook.css cp guide/resources/images/* guide/html/ xsltproc --xinclude --stringparam html.stylesheet docbook.css -- stringparam section.autolabel 1 --stringparam toc.section.depth 1 -- stringparam generate.toc "book toc" --stringparam section.label.includes.component.label 1 --stringparam profile.condition "noman" --output guide/html/guide.html \ /opt/local/share/xsl/docbook-xsl/xhtml/profile-docbook.xsl guide/ xml/guide.xml WARNING: cannot add @xml:base to node set root element. Relative paths may not work. Error: no ID for constraint linkend: development.phases. Error: no ID for constraint linkend: reference.livecheck. Error: no ID for constraint linkend: reference.keywords.global. ID recommended on section: General ID recommended on section: Dependencies ID recommended on section: Port and Non-Port Dependencies ID recommended on section: Variants ID recommended on section: Livecheck / Distcheck ID recommended on section: Installation Phase Keywords ID recommended on section: A Word about Keyword List Modifiers (-ap... ID recommended on section: Common Uses for Keyword List Modifiers ID recommended on section: A Word about Keyword Argument Modifiers ... ID recommended on section: Fetch Phase Keywords ID recommended on section: Fetch from CVS ID recommended on section: Fetch from Subversion ID recommended on section: Checksum Phase Keywords ID recommended on section: Extract Phase Keywords ID recommended on section: Patch Phase Keywords ID recommended on section: Configure Phase Keywords ID recommended on section: Configure Universal ID recommended on section: Automake and Autoconf ID recommended on section: Build Phase Keywords ID recommended on section: Destroot Phase Keywords ID recommended on section: StartupItem Attributes ID recommended on section: Executable StartupItems ID recommended on section: Script StartupItems ID recommended on section: Loading / Unloading StartupItems into la... ID recommended on section: StartupItem Internals ID recommended on refentry: PORTGROUP ID recommended on refentry: PORTHIER Anyone care to comment on them? Regards,... -jmpp

2 5

Re: xinstall vs. file copy & file mkdir
by markd＠macports.org 10 Dec '07

10 Dec '07

>What's the difference between "xinstall" and "file copy" and "copy"? >Here's what I've found: > >- xinstall has the -W option so you can say "xinstall -W src a b c d >dst" to copy a whole bunch of named files from src to dst. It doesn't >look like file copy can do that. >- file copy can copy directories. It doesn't look like xinstall can >do that. >- file copy preserves modification dates. xinstall does not. >- copy is the same as file copy. > >What's the difference between "xinstall -d" and "file mkdir"? I don't >know. And if there's a reason to use "file mkdir", should there be an >alias "mkdir" for it? > >The guide should explain these differences, and when one should >prefer one option over the other. Ryan, I agree fully, and this is on my TODO list but it is going to be challenging to document. Because there are a number of these types of issues revolving around Tcl code (and shell) use, such as when should I use "file copy / "eval xinstall glob" / "system cp -R ..", which are recursive, etc. This is a hurdle that new port authors must face, and few simple answers even if you ask the list because I think most of us know how to work around the issues more than we understand them. I'll make an attempt to provide guidelines about what to use and why as soon as I can, and at least it will be a starting place. But it will probably be after we get a few more urgent issues taken care of in the guide. But I am fully aware of these longstanding glaring deficiencies, and I consider some basic user guidance like that critical to the new guide so users can have a basic understanding of where to start before needing to ask the list. Mark

1 0

xinstall vs. file copy & file mkdir
by Ryan Schmidt 10 Dec '07

10 Dec '07

What's the difference between "xinstall" and "file copy" and "copy"? Here's what I've found: - xinstall has the -W option so you can say "xinstall -W src a b c d dst" to copy a whole bunch of named files from src to dst. It doesn't look like file copy can do that. - file copy can copy directories. It doesn't look like xinstall can do that. - file copy preserves modification dates. xinstall does not. - copy is the same as file copy. What's the difference between "xinstall -d" and "file mkdir"? I don't know. And if there's a reason to use "file mkdir", should there be an alias "mkdir" for it? The guide should explain these differences, and when one should prefer one option over the other.

3 2

Re: [31868] trunk/dports/science/molden/Portfile
by Ryan Schmidt 10 Dec '07

10 Dec '07

On Dec 10, 2007, at 11:06, jochen(a)macports.org wrote: > Modified: trunk/dports/science/molden/Portfile > =================================================================== > --- trunk/dports/science/molden/Portfile 2007-12-10 16:18:31 UTC > (rev 31867) > +++ trunk/dports/science/molden/Portfile 2007-12-10 17:06:00 UTC > (rev 31868) > @@ -12,13 +12,14 @@ > > name molden > version 4.6 > -revision 1 > +revision 2 > categories science graphics > maintainers openmaintainer jochen > master_sites ftp://ftp.cmbi.ru.nl/pub/molgraph/molden > distname molden${version} > -checksums md5 ab47e1c440c1b445eade07004f93efd8 \ > - sha1 e512d0e9f8e4b93938b63e10f18a9719299eb4e3 > +checksums md5 b52d66fc61f3d85abba94e36c14b5d85 \ > + sha1 2faeea9f970d5430ab0d2863a7f59c1780c56d3e \ > + rmd160 c21b9359e30f24942baa6e3b0dd412c793e3ad17 Anyone who already had molden @4.6_1 installed with the old distfile will get a message that the checksums don't match when trying to upgrade. Since the distfile name didn't change (right?), it'll keep using the old distfile which has the older checksum. You should chastise the developers for releasing a stealth-upgrade. Then you should work around the problem in the portfile by defining a different download directory, like this, for example: dist_subdir ${distname}/${version}_${revision} If the developers frequently release stealth upgrades like this, this could be left in the portfile. If not, it could be removed when the next distfile with a new filename is released.

2 2

MacPorts version specific milestones, no more!
by Juan Manuel Palacios 10 Dec '07

10 Dec '07

So, long after realizing that having MacPorts version specific milestones up on the Trac Roadmap doesn't work one bit unless we have a defined set of goals for each release (as was naturally concluded from Jordan's "Objection your Honor, Counselor is leading the witness!" type of question last week), I finally got my act together and closed/deleted such milestones. I closed the 1.5 milestone as I'm sure we can consider that release set already over, and deleted the 1.6 milestone, retargetting all tickets in both as either base bugs or base enhancements. Further tickets against base should be filed as either one of those, bugs or enhancements, just as we have for ports. Version specific milestones can be brought back to life once we start defining clear and specific goals for each release, but not before as all they add is confusion. One thing we can do in the mean time, I'd suggest, is create a version specific milestone for a particular set of releases after such is considered over (that is, when we start another one, e.g. 1.7 and leave 1.6 behind), and reclassify tickets that were closed in the relevant timeframe into it... if such work flow does not prove to be too much of a hassle. Mark, Simon, Maun Suang, could you guys amend the #project.tickets section of the guide as appropriate to reflect this new workflow? Thanks! Regards,... -jmpp

1 0

ticket 13504: update coreutils to 6.9.90
by Kirk Kelsey 10 Dec '07

10 Dec '07

I've checked in a Portfile patch to upgrade coreutils to the new "non- unstable" version 6.9.90; could someone please commit it? This is the first Portfile change I've made, so extra scrutiny might be wise. https://svn.macosforge.org/projects/macports/ticket/13504 Thanks, Kirk

1 0

Re: [31857] trunk/doc-new/guide/xml/portfileref.xml
by Ryan Schmidt 10 Dec '07

10 Dec '07

On Dec 10, 2007, at 05:50, ryandesign(a)macports.org wrote: > Modified: trunk/doc-new/guide/xml/portfileref.xml > =================================================================== > --- trunk/doc-new/guide/xml/portfileref.xml 2007-12-10 08:52:25 UTC > (rev 31856) > +++ trunk/doc-new/guide/xml/portfileref.xml 2007-12-10 11:50:36 UTC > (rev 31857) > @@ -322,10 +322,10 @@ > <variablelist> > <varlistentry> > <term>eval xinstall [-o owner] [-g group] [-m > mode] [glob > - regexp] directory</term> > + pattern] directory</term> > > <listitem> > - <para>Install the file(s) matching the glob > expression to a > + <para>Install the file(s) matching the glob > pattern to a > destination directory.</para> > </listitem> > </varlistentry> There needs to be a way in the guide to indicate which parts should be typed verbatim and which are placeholders which should be replaced. Manpages, for example, use bold for things to be typed verbatim, and underline for things to be replaced. Someone reading the above might think that "glob pattern" should be replaced with the glob pattern, when in fact "glob" is the function name and should be typed verbatim while "pattern" is to be replaced with the pattern.

2 1

Re: propchange - r31472 svn:log
by Ryan Schmidt 10 Dec '07

10 Dec '07

Ok, so propchange emails are working! Great! Some suggestions though: On Nov 27, 2007, at 06:53, jmpp(a)macports.org wrote: > From: jmpp(a)macports.org > Date: November 27, 2007 06:53:55 CST > To: macports-changes(a)lists.macosforge.org > Subject: propchange - r31472 svn:log > Reply-To: macports-dev(a)lists.macosforge.org, jmpp(a)macports.org > > Author: ryandesign(a)macports.org > Revision: 31472 > Property Name: svn:log > > New Property Value: > > * Rename "check_referer" function to "print_warnings" and move all > of its contents into a new trunk/www/includes/warnings.inc file; > * Remove the warning about not being the official website out of > trunk/www/includes/header.inc and put it into the new warnings.inc > file. > With the 'if' conditional suggested by Ryan on the dev list, > this warning should "just work" and disappear when the site is run > from the > official web server, at which time we'll reword it to something > different (from claiming we're a temporary installation to a mirror). Remove the Author: line. Instead, make the propchange email come from the author, instead of the original committer. Also, put the author's address in the Reply-To, not the committer's. Also, we need to see what the old property value was, not just what the new value is. Ideally, it would be nice to see a Trac-style colored diff of the changes, just like we have for the post-commit emails. But the whole point of these mails is that if someone screws up badly and obliterates a property, the old value of the property is in the mail so anyone can repair it. Without this, there's no way to repair it, unless someone magically knows what the property value should be. I looked into this before and couldn't find any way for svn-notify (which we currently use for post-commit mails) to produce post- revprop-change emails. We may wish to switch mail scripts entirely to one that can support both types of mail.

2 2