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

xinstall examples in guide
by Ryan Schmidt 10 Dec '07

10 Dec '07

In the xinstall section of the new guide, several examples are shown to copy files into "${destroot}${prefix}/share/doc/${name}". nox has been on a mission to make ports install their documentation into "$ {destroot}${prefix}/share/doc/${name}-${version}". Could the examples be changed to that instead?

2 1

Re: [30263] trunk/dports/devel/omake
by Ryan Schmidt 18 Nov '07

18 Nov '07

On Oct 23, 2007, at 01:05, source_changes(a)macosforge.org wrote: > Revision: 30263 > http://trac.macosforge.org/projects/macports/changeset/30263 > Author: erickt(a)macports.org > Date: 2007-10-22 23:05:28 -0700 (Mon, 22 Oct 2007) > > Log Message: > ----------- > version bump > > Modified Paths: > -------------- > trunk/dports/devel/omake/Portfile > > Added Paths: > ----------- > trunk/dports/devel/omake/files/ > trunk/dports/devel/omake/files/stdin_stdout.bin > > Modified: trunk/dports/devel/omake/Portfile > =================================================================== > --- trunk/dports/devel/omake/Portfile 2007-10-23 05:35:49 UTC (rev > 30262) > +++ trunk/dports/devel/omake/Portfile 2007-10-23 06:05:28 UTC (rev > 30263) > @@ -2,7 +2,7 @@ > > PortSystem 1.0 > name omake > -version 0.9.8-2 > +version 0.9.8.5-3 > categories devel > maintainers erickt(a)dslextreme.com > description OMake is a build system designed for > scalability and portability > @@ -12,12 +12,14 @@ > homepage http://omake.metaprl.org > master_sites http://omake.metaprl.org/downloads > > -worksrcdir ${name}-0.9.8 > +worksrcdir ${name}-0.9.8.5 [snip] You might want to apply the attached patch, so you don't have to keep changing the worksrcdir with every version. You might want to change your maintainer address to your macports.org address (also on the caml-menhir, gtk-canvas and tre ports).

2 1

GTK2 2.12.0 Portfile for testing
by Randall Wood 12 Nov '07

12 Nov '07

ALCON: Attached is the Portfile and patch files for GTK 2.12.0. Can you please test before I release it into the wild. Randall Wood rhwood(a)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."

3 3

Re: [27772] trunk/dports/sysutils/logrotate/Portfile
by N_Ox 12 Nov '07

12 Nov '07

Le 14 août 07 à 06:57, source_changes(a)macosforge.org a écrit : > Revision 27772 Author markd(a)macports.org Date 2007-08-13 21:57:36 > -0700 (Mon, 13 Aug 2007) Log MessageMake port conform to mtree > standards properly.Modified Paths > trunk/dports/sysutils/logrotate/Portfile > Diff > <snip> > + xinstall -d ${destroot}${prefix}/share/man/man8 > + xinstall -m 755 ${worksrcpath}/logrotate.8 ${destroot}${prefix}/ > share/man/man8 > <snip> > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes By the way, manpage permissions should be 444, and as share/man/man8 is already in mtree, it is useless to install it beforehand. -- Anthony Ramine, the infamous MacPorts Trac slave. nox(a)macports.org

3 7

Re: Speed up build phase with "make -j"
by Weissmann Markus 05 Nov '07

05 Nov '07

On 28.10.2007, at 23:52, js wrote: > On 10/29/07, Anders F Björklund <afb(a)macports.org> wrote: >>>> Note that some ports will fail to build, when using "make -j 2" >>> >>> What causes the build erorr? is it for bad Makefile or problem of >>> "-j" >>> option itself? >> >> Bad makefiles, usually missing dependencies. > > So, in a way, using -j encourage us to find wrong makefiles:) Well, if you're lucky -- parallel builds get non-deterministic, so software _may_ build correctly. You may (!) even end up with a successful build that created "bad" installations with misbehaving software; An intermediate step that makes changes to a file may get scheduled after the last step compiles an object file from this file; this way you might get a successful build but w/o the changes from step 2. Those are extremely hard to trace bugs and maintainers might reject bug reports if builds got made parallel this way -- after all they cannot reproduce failing builds due to the non-determinism. I'd rather encourage a mechanism for port that provides a mechanism for port authors to know how many processors there are and to enable parallel builds if they know this to work. Perhaps a switch "use_parallel_build [yes|no]" that will add "-j 2*CPUS" to build.args. -Markus --- Markus W. Weissmann http://www.mweissmann.de/

6 19

Buildfarm try
by Simon Ruderich 04 Nov '07

04 Nov '07

Hi all, I tried creating a small "buildfarm" using my MacBook Pro. I already have some results, but it's just a small test, so please be not too strict with it ;-) You can find the results here: http://ruderich.com/simon/macports/ But the results are some days old, so it may be possible a port is already fixed. I'm sorry but at the moment I don't have any dates. It would be nice if some of you could use these results to fix broken ports. I separated fetch failures from build/other failures so they should be easy to fix. If you have any suggestions/improvements/bugs or questions please tell me. Thanks, Simon

8 18

Re: [30536] trunk/dports/irc/xchat/Portfile
by Rainer Müller 31 Oct '07

31 Oct '07

source_changes(a)macosforge.org wrote: > Revision > 30536 <http://trac.macosforge.org/projects/macports/changeset/30536> > Author > ryandesign(a)macports.org > Date > 2007-10-30 16:27:20 -0700 (Tue, 30 Oct 2007) > > > Log Message > > xchat: turn livecheck off since this is ancient software (#12927) Why do we still keep it in the tree if it is ancient? Rainer

2 2

Re: [MacPorts] #13020: fortune doesn't build under Mac OS X 10.5 Leopard
by Anders F Björklund 31 Oct '07

31 Oct '07

> Changes (by ryandesign(a)macports.org) > > * summary: fortune doesn't build under leopard => fortune doesn't > build > under Mac OS X 10.5 Leopard > * owner: macports-dev(a)lists.macosforge.org => afb(a)macports.org > * cc: => afb(a)macports.org, mordeth(a)bitbucket.be What was wrong with "leopard" in the Trac descriptions ? "Mac OS X 10.5 Leopard" not only looks long and bulky, but it's also redundant since 10.5 == Leopard anyway... Actually a keyword would be better, but I guess Trac is enough challenged as it is without adding platforms. --anders

2 1

commit request: trac 12756 (was: Re: destroot.violate_mtree doesn't work?)
by Julian Dunn 31 Oct '07

31 Oct '07

All is better now with destroot.violate_mtree under MacPorts 1.5.2, so I'm requesting that someone commit Trac #12756. - Julian -- -- Julian C. Dunn, P.Eng. <Julian_Dunn(a)cbc.ca> -- Analyst, Media Production Support, CBC Technology -- Digital Programming and Business Development -- Office: 2C310-N * Tel.: (416) 205-3311 x6988 >>> Ryan Schmidt <ryandesign(a)macports.org> 10/29/07 1:40 AM >>> On Oct 29, 2007, at 00:33, Julian Dunn wrote: > Anders F Björklund wrote: > >> Julian Dunn wrote: >> >>> I'm still trying to port Amanda (www.amanda.org) to Macports. Amanda >>> wants to install its own dumper in /opt/local - not great, but it >>> does >>> this under FreeBSD too. In order to accommodate this I wanted to >>> set: >>> >>> destroot.violate_mtree yes >>> >>> per the Macports guide at http://geeklair.net/new_macports_guide/. >>> However, 'port' doesn't seem to like this directive: >>> >>> Can't map the URL 'file://.' to a port description file ("invalid >>> command name "destroot.violate_mtree""). >>> >>> Any idea what I'm doing wrong? >> >> Maybe your version of port is outdated, the Violator wasn't in 1.5.0 >> AFAIK ? > > Thanks - is there any way to not do selfupdate over rsync? My company > firewall doesn't permit egress rsync. If you can't use selfupdate (which only works over rsync), you'll have to download the source and build it yourself, each time MacPorts base is updated. The 1.5.2 source is here: http://trac.macports.org/projects/macports/browser/distfiles/MacPorts Download it, decompress it, and run ./configure, make and sudo make install in the decompressed directory.

1 0

php category
by Ryan Schmidt 31 Oct '07

31 Oct '07

"port lint" informs me that there isn't a category php: $ sudo port lint pear-base ---> Verifying Portfile for pear-base Error: Unknown category: php ---> 1 errors and 0 warnings found. $ But these ports want to be in that category: $ grep php */*/Portfile | grep categories www/mediawiki/Portfile:categories www php www/pear-base/Portfile:categories www php lang www/php4/Portfile:categories lang php www www/php5-devel/Portfile:categories lang php www www/php5/Portfile:categories lang php www www/phpbb/Portfile:categories www php www/phpicalendar/Portfile:categories www php www/phpmyadmin/Portfile:categories php www databases www/squirrelmail/Portfile:categories www mail php x11/php5-gtk/Portfile:categories x11 lang php www $ I presume we should remove "php" from the categories of each of these ports? I don't see why we would need a "php" category. The php software itself is a language that's often used for web sites, so "lang" and "www" are good categories. And webapps developed with php belong in "www"; nobody should care what language they were made with.

4 7