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

Re: [23628] trunk/dports/lang/scala/Portfile
by Elias Pipping 05 Apr '07

05 Apr '07

> Log Message > > =========== > > Tabify. Why?

2 1

Could a base committer comment on #11012?
by markd＠macports.org 05 Apr '07

05 Apr '07

http://trac.macosforge.org/projects/macports/ticket/11012 Can someone give some feedback on this one? Good idea, bad, invalid? Thanks. Mark

1 0

An idea for distributing ports
by Randall Wood 05 Apr '07

05 Apr '07

This is one of those while doing something unrelated ideas that suddenly crystalizes while (classically) in the shower or attending a meeting... The idea is this: Stable and Unstable Ports trees available via both rsync and http Port currently works by grabbing info out of the port registry and PortIndex file(s) on the local system and by looking at Portfiles in the source trees whenever it is going to change the state of the system by installing/uninstalling/activating/deactivating/whatever a port. I see no reason to change that except to allow for http-based syncing of the source tree, which could work the following way: 1) port sync/selfupdate download the PortIndex 2) when a port operation that changes the system state is done, if the requested port is in the PortIndex and either the Portfile does not exist or the version of the Portfile is not equal to the version in the PortIndex, then the portfile archive (portname.tgz as generated by portindex -a) is downloaded, extracted, and used. Http syncing would allow users who are having to maintain the tree in svn because they can not rsync do to firewall/proxy restrictions to no longer have to live in our working area, and would allow port to do the syncing in that case once again. The Stable/Unstable port branches: This is conceptually pretty simple, and I hope technically simple as well. The current rsync sources would remain in place to support users of MacPorts versions that do not support the concept of stable/unstable branches before being turned off sometime after a version of port is released that understands the ides of stable/unstable branches or how to use the port.tgz files Unstable: This branch would be a new rync tree, generating its own PortIndex. It would be synced againt the svn source code repository multiple times daily, grabbing all changes in the repository. It would serve both rsync and http-based sync operations. Stable: This branch would be a new rsync tree, generating its own PortIndex. When this branch is started it would be a verbatim copy of the unstable branch, becoming stable as other rules are met. This branch would sync off the unstable branch only those files that have stayed in the unstable branch without changing within the past 2 weeks and would be synced daily. It would serve both rsync and http-based sync operations. The idea behind the stable branch is this: When a portfile fails to parse in the unstable branch and causes port installation/upgrades to simply fail (like happened during the recent zlib problem) or causes other ports to break (like happened in the last gettext and libgtkhtml3 upgrades), it would be noticed by users of the unstable branch, and repair activities would prevent it from being picked up by the stable branch, so that once working changes were introduced and the port is left alone more than 2 weeks, it then becomes an upgrade in the stable branch. Obviously, an rsync-based port sync operation would have to ignore the port.tgz files in the stable/unstable branches. It would also be nice to be able to have the source line in sources.conf read like {$sync.protocol}server/path/{$sync.branch} or something similar instead of having 4 different lines in there with only 1 not commented out. Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

4 3

depends_lib-delete
by Yves de Champlain 05 Apr '07

05 Apr '07

Is that the right syntax ? DEBUG: can't set "depends_lib": invalid depspec: while executing "set depends_lib [ldelete ${depends_lib} $val]" (procedure "depends_lib-delete" line 5) invoked from within "depends_lib-delete port:gimp2" (procedure "variant-without_gimp" line 7) invoked from within "variant-without_gimp" invoked from within "catch "variant-${name}" result" Error: Error executing without_gimp: can't set "depends_lib": invalid depspec: Error: Status 1 encountered during processing. yves

2 2

(Chagrined) Could someone with commit rights apply my patch to my port?
by Boey Maun Suang 05 Apr '07

05 Apr '07

Hi everyone, Sorry to bother you with this, but I submitted a ticket (#11666) to update tor-devel, which I currently maintain, but forgot to CC macports-dev@ so that someone with commit rights could apply it. Would one of you mind helping me out? Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Mobile: +61 403 855 677 Email: boeyms(a)fastmail.fm

2 1

depends_lib-delete broken ?
by Yves de Champlain 05 Apr '07

05 Apr '07

Could anyone verify what is going on here (or am I going nuts) ? DEBUG: can't set "depends_lib": invalid depspec: while executing "set depends_lib [ldelete ${depends_lib} $val]" (procedure "depends_lib-delete" line 5) invoked from within "depends_lib-delete port:gimp2" (procedure "variant-without_gimp" line 7) invoked from within "variant-without_gimp" invoked from within "catch "variant-${name}" result" Error: Error executing without_gimp: can't set "depends_lib": invalid depspec: Error: Status 1 encountered during processing. yves

1 0

Please close ticket #11661 (link enclosed)
by Andre Stechert 04 Apr '07

04 Apr '07

I committed, in revision 23568, the patch in http://trac.macports.org/projects/macports/ticket/11661 for Mark Moll (mmoll(a)cs.rice.edu) because he doesn't have commit rights, but I can't close the bug because I don't have TRAC rights. Thanks, Andre p.s. Is there some way for me to get the rights to close a bug?

2 1

Uninstall an obsolete from another (conflicting) port
by Randall Wood 04 Apr '07

04 Apr '07

What's the best way to do this? I have seen calls in ports doing this in the past like: pre-install { system "port -f uninstall xxx" } Which is not really the way to do it. Clearly the best way would be loop the list of versions of the port and uninstall each one using the MacPorts API, but given the state of the docs... Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

3 2

portindex -a
by Randall Wood 04 Apr '07

04 Apr '07

Are there any mechanisms in place to take advantage of the portindex - a option? Or if I have a collection of the archives created with that option how would I use them? Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

2 1

MPWA
by Randall Wood 04 Apr '07

04 Apr '07

What is this intended to be? Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

2 1