Here's the change log: James Release 1.4.40 (7-May-2007, tagged at r24909 by jberry): - Note the bump in version naming. To leave ourselves lots of room in our versioning scheme, we've jumped from 1.4.3 to 1.4.40. The floating point represenation as reported by port version (1.440) will still be the same; we're just interpreting it differently. - variable tracing now works in a much better way and handles unsets properly. Similarly, ${option}-delete now works better. Depends validation no longer attempts to validate when the variable is unset. Additionally, the validation now actually validates each depspec instead of simply finding a single spec within the list that works (ticket #11868, eridius r24678). - macports infrastructure now easier to use from scripts. ui_prefix and ui_channels have default implementations, and all arguments to dportinit are now optional (ticket #11837, eridius r24460). - ln now accepts combined flags (ex. ln -sf foo bar) (eridius r24452) - default_variants now handles multiple values correctly (ticket #11828, eridius r24450). - ln uses new symlink command so it can create symlinks that point to files that don't actually exist (eridius r24444). - New bare-bones Pextlib command `symlink source target` (ticket #11840, eridius r24444). - delete reimplemented using fs-traverse (eridius r24435). - fs-traverse now uses the fts(3) family of functions instead of readdir/opendir. This fixes a couple behavioral oddities, and makes deleting during traversal work on 10.3 (ticket #11839, eridius r24423). - fs-traverse now takes a list of targets rather than a variable number of arguments (ticket #11836, eridius r24410). - Fixed a potential crasher in fs-traverse when showing error message (ticket #11827, eridius r24396, thanks sfiera). - Fixed a bug where livecheck failed on ports that do not define a homepage (ticket #11818, pguyot r24319). - Added the downloads section of our repo to the macports mirrors list (jmpp r24278). - Fixed a bug with the archive mode introduced with r23238 change (1.4.1) (pguyot r24273). - Trace mode now take dependencies into account when executing the activate phase. This fixes an unwanted warning when activating ports that depend on teTeX (pguyot r24199). - Support for mpwa submit through "port submit". This work is in progress. (jberry) - Expose autoconf XAR variable as portutil::autoconf::xar_path. (r24194). - Start to build portpkg.xar and meta data, hijacking Kevin's portsubmit.tcl. (r24195-24196). - Revise error messages in port image activation to use syntax that matches port(1). (jberry r24543, r24548). - Create new interp variable prefix_frozen, which is available to port phases even when the Portfile redefines prefix. (jberry r24848-r24849) - Search for prefix-relative commands in prefix_frozen rather than prefix. Affects port submit (xar) and port fetch (svn). (jberry r24849) - Always create a ~/.macports user directory if it doesn't yet exist. (jberry r24831) - Move port(1) readline history file to ~/.macports/history (jberry r24832, r24843)
On May 7, 2007, at 9:59 PM, James Berry wrote:
Here's the change log:
James
Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
James, Thanks for pushing this release out. Did the changes to bz2 make it in in the unarchive? I didn't see the revisions in this list. Also, I tried to figure out on branches/release_1_4 what's been merged in and there's no information in the log message on what revisions were merged from trunk. The one place that svn isn't great is in merge tracking support; without an explicit log message or other tool to keep track of what's been merged, there's no way to tell what's been merged. So I request we do the following: 1) Document the revisions merged into the branch in the log message. 2) Switch to using svnmerge.py for the next branch 1.5. This will allow us to see what revisions have been merged. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
Hi Blair, On May 7, 2007, at 11:10 PM, Blair Zajac wrote:
On May 7, 2007, at 9:59 PM, James Berry wrote:
Here's the change log:
James
Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
James,
Thanks for pushing this release out.
Did the changes to bz2 make it in in the unarchive? I didn't see the revisions in this list.
I do remember something about those, but it's bit foggy. Did the changes make it into trunk, or is there a particular ticket they were submitted on?
Also, I tried to figure out on branches/release_1_4 what's been merged in and there's no information in the log message on what revisions were merged from trunk. The one place that svn isn't great is in merge tracking support; without an explicit log message or other tool to keep track of what's been merged, there's no way to tell what's been merged. So I request we do the following:
1) Document the revisions merged into the branch in the log message. 2) Switch to using svnmerge.py for the next branch 1.5. This will allow us to see what revisions have been merged.
In recent releases (and until we can't) release_1_4 branch has just be tracking trunk, with all changes in trunk merged over. Its easy to merge and easy to document. But if there's failure to document something that goes into trunk, there's likewise failure to document what comes out the other end in release_1_4. Thanks for the suggestion of svnmerge.py. I haven't had time to even think about it. You want to become the release manager for MacPorts? James
Regards, Blair
-- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
On May 8, 2007, at 5:52 AM, James Berry wrote:
Hi Blair,
On May 7, 2007, at 11:10 PM, Blair Zajac wrote:
On May 7, 2007, at 9:59 PM, James Berry wrote:
Here's the change log:
James
Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
James,
Thanks for pushing this release out.
Did the changes to bz2 make it in in the unarchive? I didn't see the revisions in this list.
I do remember something about those, but it's bit foggy. Did the changes make it into trunk, or is there a particular ticket they were submitted on?
Yes, they made it into trunk and there's no ticket for them. I guess I need to merge my change in trunk over to the release_1_4 branch?
Also, I tried to figure out on branches/release_1_4 what's been merged in and there's no information in the log message on what revisions were merged from trunk. The one place that svn isn't great is in merge tracking support; without an explicit log message or other tool to keep track of what's been merged, there's no way to tell what's been merged. So I request we do the following:
1) Document the revisions merged into the branch in the log message. 2) Switch to using svnmerge.py for the next branch 1.5. This will allow us to see what revisions have been merged.
In recent releases (and until we can't) release_1_4 branch has just be tracking trunk, with all changes in trunk merged over. Its easy to merge and easy to document. But if there's failure to document something that goes into trunk, there's likewise failure to document what comes out the other end in release_1_4.
How are you doing the merge now? How are you keeping track of which revisions have been merged over?
Thanks for the suggestion of svnmerge.py. I haven't had time to even think about it. You want to become the release manager for MacPorts?
svnmerge.py will make life simplier, and there's a command 'svnmerge.py avail -l' that shows all unmerged changes. Also, 'svnmerge.py merge' creates a commit message file containing all the commits on the trunk, so there's almost no additional documentation work. And I'll pass on being the release manager :) Regards, Blair
On May 8, 2007, at 8:52 AM, James Berry wrote:
Hi Blair,
On May 7, 2007, at 11:10 PM, Blair Zajac wrote:
On May 7, 2007, at 9:59 PM, James Berry wrote:
Here's the change log:
James
Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
James,
Thanks for pushing this release out.
Did the changes to bz2 make it in in the unarchive? I didn't see the revisions in this list.
I do remember something about those, but it's bit foggy. Did the changes make it into trunk, or is there a particular ticket they were submitted on?
Archivemode supporting both creating and unpacking *bz[2] archives now works, both in trunk and in the 1.4.40 release. Blair fixed some bits and I fixed others, but I can't find the relevant commits for the live of me at the moment, But in any case, it should all Just Work, otherwise I'd be happy to look into it! Regards,... -jmpp
On May 15, 2007, at 11:56 PM, Ryan Schmidt wrote:
On May 7, 2007, at 23:59, James Berry wrote:
Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
Please add "1.4.40" to the list of MacPorts versions in Trac. Currently we jump from "1.4.3" to "1.5.0".
Will do, sorry for the overlook! -jmpp
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
participants (4)
-
Blair Zajac
-
James Berry
-
Juan Manuel Palacios
-
Ryan Schmidt