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

SVK issue with properties when dp2mp went into trunk?
by Glen Whitney 19 Jun '07

19 Jun '07

To those of you who have an SVK mirror of the macports Subversion repository: I noticed today that properties are missing on the files in the src/ macports1.0 directory in my SVK mirror, even though they are there in the macports Subversion repository: $ svk info //mirror/macport/src/macports1.0/macports.tcl Depot Path: //mirror/macport/src/macports1.0/macports.tcl Revision: 2466 Last Changed Rev.: 2458 Mirrored From: https://svn.macosforge.org/repository/macports/trunk/ base, Rev. 26188 $ svk proplist //mirror/macport/src/macports1.0/macports.tcl # Note no output $ svn proplist -r 26188 https://svn.macosforge.org/repository/ macports/trunk/base/src/macports1.0/macports.tcl Properties on 'https://svn.macosforge.org/repository/macports/trunk/ base/src/macports1.0/macports.tcl': svn:keywords svn:eol-style But properties on previously-existing files are OK: $ svk proplist //mirror/macport/src/port/port.tcl Properties on //mirror/macport/src/port/port.tcl: svn:eol-style svn:keywords I suspect an SVK bug when I did the "svk sync //mirror/macports" command that went across revision 26177, whereby the properties on these new files were not mirrored. Anybody else notice this issue? Even if not, any suggestions how I might get the mirror really properly in sync? I wanted to check with some folks more experienced in SVK before I tried to reproduce the problem and/or open an SVK ticket (I don't know how many projects I can try to hack on at once :-)). Thanks for any pointers, Glen

2 1

New Port: x11/php-gtk
by Anant Narayanan 19 Jun '07

19 Jun '07

Hi, I submitted a ticket for a new port [1]. Would be nice to have this in the tree. Thanks! -- Anant Narayanan http://www.kix.in/ gpg --recv-keys 0EF6914E <anant(a)kix.in,gentoo.org,php.net> [1] http://trac.macports.org/projects/macports/ticket/12138

1 0

Re: [26283] trunk/dports/audio/openal/Portfile
by Ryan Schmidt 18 Jun '07

18 Jun '07

On Jun 18, 2007, at 06:27, source_changes(a)macosforge.org wrote: > Revision: 26283 > http://trac.macosforge.org/projects/macports/changeset/26283 > Author: mww(a)macports.org > Date: 2007-06-18 04:27:22 -0700 (Mon, 18 Jun 2007) > > Log Message: > ----------- > use macports.org as mirror for snapshot > > Modified Paths: > -------------- > trunk/dports/audio/openal/Portfile > > Modified: trunk/dports/audio/openal/Portfile > =================================================================== > --- trunk/dports/audio/openal/Portfile 2007-06-18 11:26:10 UTC (rev > 26282) > +++ trunk/dports/audio/openal/Portfile 2007-06-18 11:27:22 UTC (rev > 26283) > @@ -13,7 +13,7 @@ > applications. > > homepage http://www.openal.org/ > -master_sites http://www.opendarwin.org/~mww/files/ > +master_sites http://svn.macports.org/repository/macports/distfiles/ > mww/ > #svn.url http://opensource.creative.com/repos/openal/tags/ > MacOSX1-2_Spec1-0/ > checksums sha1 156d26e6369b13efe9a525cb0db9e6078ecb05a9 > use_bzip2 yes Shouldn't that be: master_sites macports:mww ?

1 0

Update net/pidgin to version 2.0.2
by Simon Ruderich 18 Jun '07

18 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I just installed version 2.0.2 of Pidgin and it worked. It would be nice if you could update the Portfile, here is the patch. - --- Portfile 2007-05-10 18:20:27.000000000 +0200 +++ Portfile 2007-06-18 16:38:30.000000000 +0200 @@ -2,7 +2,7 @@ PortSystem 1.0 name pidgin - -version 2.0.0 +version 2.0.2 categories net maintainers nomaintainer(a)macports.org description AIM message service client with a gtk2 interface @@ -17,9 +17,9 @@ master_sites sourceforge - -checksums md5 132355d7e236d9c2820a2668621eef43 \ - - sha1 7bfe348abc25307845e8de1d0fe2b761293ab071 \ - - rmd160 1e387bb098bb985c5aa46deedc5eb4450579ae4e +checksums md5 613a357b2b1e030433fdfa680483d00f \ + sha1 7f5cdc3e8fb8b8af9646bb0635b2852c24f7e059 \ + rmd160 d1b6d30b5c8e68c55c8ef8b8118c7041b6d67348 use_bzip2 yes Thanks in advance, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGdqHTYRX4BO+zMikRCrwAAJ0eBMtzJCnw5gLqgcpjCRrGOZ2l1gCg1td+ qMXXxbMzwbZCbpDQ8rkZpjo= =PcbP -----END PGP SIGNATURE-----

2 1

MP removes /tmp symlink
by markd＠macports.org 17 Jun '07

17 Jun '07

I've seen this before, but now I think I have a better idea why it happens. It only happens when building new portfiles when the portfiles fail. When files get placed in /tmp and the portfile terminates because of errors, then the /tmp symlink gets wiped when the port is cleaned using "port clean --all". I know how to duplicate the problem now. Mark

1 0

Fwd: PostgreSQL and MySQL
by N_Ox 16 Jun '07

16 Jun '07

Début du message réexpédié : > De : N_Ox <n.oxyde(a)gmail.com> > Date : 16 juin 2007 22:23:10 HAEC > À : James Berry <jberry(a)macports.org> > Objet : Rép : PostgreSQL and MySQL > > > Le 16 juin 07 à 22:06, James Berry a écrit : > >> >> On Jun 16, 2007, at 7:55 AM, N_Ox wrote: >> >>> Hello, >>> >>> For consistency's sake, wouldn't it be nicer to make mysql5 >>> server variant its own port, >>> as postgresql82-server port? >>> This way, ports could even depend on the mysql5 server without fail. >> >> Since server basically just adds the startupitem, I think we >> should just make server the default. The startupitem should be >> harmless unless explicitly loaded, and surely the couple of extra >> small files is relatively no impact. >> >> Any objections? >> >> James > > I agree, that's even better! > But we should do the same in mysql5, then =). > > -- > Anthony Ramine, a lazy french student. > nox(a)macports.org > > -- Anthony Ramine, a lazy french student. nox(a)macports.org

3 2

PostgreSQL and MySQL
by N_Ox 16 Jun '07

16 Jun '07

Hello, For consistency's sake, wouldn't it be nicer to make mysql5 server variant its own port, as postgresql82-server port? This way, ports could even depend on the mysql5 server without fail. -- Anthony Ramine, a lazy french student. nox(a)macports.org

3 2

Suggestions on failure of 'make test'?
by Glen Whitney 16 Jun '07

16 Jun '07

I am just about ready to check in the patch to resolve ticket 11891, having recently obtained my commit rights. Of course, I wanted to make sure that all was well with 'make test' before the check in. But I get this output: ===> making test in config make[1]: Nothing to be done for `test'. ===> making test in doc make[1]: Nothing to be done for `test'. ===> making test in src ===> making test in src/darwinports1.0 make[2]: Nothing to be done for `test'. ===> making test in src/port1.0 ===> making test in src/port1.0/resources ===> making test in src/port1.0/resources/package make[4]: Nothing to be done for `test'. ===> making test in src/port1.0/resources/fetch make[4]: Nothing to be done for `test'. ===> making test in src/port1.0/resources/group make[4]: Nothing to be done for `test'. /usr/bin/tclsh tests/portutil.tcl couldn't read file "./../portutil.tcl": no such file or directory while executing "source [file dirname [info script]]/../portutil.tcl" invoked from within "$workername eval $body" (procedure "test_depends_lib-delete" line 19) invoked from within "$proc" ("foreach" body line 2) invoked from within "foreach proc [info procs test_*] { $proc }" (in namespace eval "::tests" script line 214) invoked from within "namespace eval tests { proc test_delete {} { set root "/tmp/macports-portutil-delete" # use file delete -force to kill the test directory if ..." (file "tests/portutil.tcl" line 13) make[2]: *** [test] Error 1 make[1]: *** [test] Error 1 make: *** [test] Error 1 I can see the line of code in src/port1.0/tests/portutil.tcl which is failing: source [file dirname [info script]]/../portutil.tcl at line 73, but it's the same as a line of code earlier in the file (line 9) which ran fine, and I don't see that the current directory changed before hitting this line. Also, since I didn't touch portutil.tcl, I don't think my changes have caused this failure. On the other hand, I of course don't want to check in anything when "make test" is not working. Any suggestions? Thanks for any help or ideas, Glen

2 1

universal syntax like livecheck?
by Ryan Schmidt 16 Jun '07

16 Jun '07

Something occurred to me. I recently added livecheck to all my ports. For those who (like me until a little while ago) hadn't quite grasped what livecheck does, it lets you type (the rather unwieldy) "port echo maintainer:yourname | sudo xargs -n 1 port livecheck" and see which of your ports have new versions available, so that you know which ones you need to update. And livecheck has a number of different ways it can check for this. It can check sourceforge or freshmeat, or whether a regex matches the contents of a web page, or whether a distfile is newer than the portfile. It uses reasonable defaults but often needs help. For some ports, like expat, livecheck already worked just fine -- expat already downloaded from sourceforge, and the sourceforge livecheck worked correctly. I added "livecheck.check sourceforge" anyway, to remind myself that I had checked the livecheck functionality and that it worked properly. For other ports, like sleepwatcher, I had to set it up to check the project's homepage with "livecheck.check regex". For one project, tidy, I even turned livecheck off with "livecheck.check none", since I couldn't figure out a way to do it, and also since the project hasn't released a tarball in years. Now take a look at the situation we have with universal binaries in MacPorts. Currently, all ports automatically get the default universal variant, but it doesn't work for all ports. Some ports, like libid3tag, seem to build fine, but then the end result isn't universal after all. Others, like cairo, will complain during the configuration phase (and will need a build-twice-and-lipo approach to build correctly). Still others, like pdftk, don't use autoconf, which the default universal variant requires. Finally, ports like minivmac don't need any help building universal at all, because their Xcode project files already take care of it. What if we used a similar syntax to the one we use for livecheck to describe a port's universal abilities? Let me see if I can remember what our current syntax for universal functionality looks like... - The default universal variant shows up automatically. - If the software can't build universal (at least not yet), then you're supposed to add "universal_variant no" to the portfile. - If the software builds universal all by itself, I've been saying "default_variants +universal" and then "variant universal {}" (The point is that "port installed foo" would show the +universal variant, letting the user know that it is, in fact, universal.) - If you want different universal build behavior, you override the universal variant. What if we changed it like this... - There's a new variable "universal.method" (universal's analog of "livecheck.check") which has several possible values, described next. - "universal.method autoconf" is the current all-at-once "-arch ppc - arch i386" method suitable for many autoconf-based projects. - "universal.method lipo" would be a new universal method which causes the port to automatically configure and build multiple times, once for each architecture, and then have the result stuck together with lipo at the end, much like (or possibly even using) the "unify" script from the Mozilla project that I talked about on this list some months ago. - "universal.method none" would replace the current "universal_variant no" syntax. I don't know if "universal_variant no" currently does this, but it might be nice, if you tried to "port install +universal" such a port, if it would print out a message advising that universal won't work. Also, "universal" should not show up in "port info" and "port variants" for such ports. - "universal.method implicit" would correspond to the "don't mind me, I'm already universal" disposition. - The default value would be "universal.method unknown" which is the same as "universal.method autoconf" but prints a warning that universal functionality has not been verified for that port, possibly inviting the maintainer to set "universal.method autoconf" if it is found to work properly. - Addendum to the preceding: "universal.method unknown" would correspond to "universal.method none" if the port says "use_configure no". We shouldn't advertise a universal variant if we can already determine it won't work. - Another addendum: alternately, if the port says "use_configure no", "universal.method unknown" could correspond to "universal.method lipo", but again with the warning that it might not work. Comments on this syntax or the new functionality it implies? While researching for this email I discovered (or possibly rediscovered; I forget) the functions lipo() and backup() in portutil.tcl... I believe these are only used by the openssl port, and it is my hope that the implied new code in MacPorts base for "universal.method lipo" would be able to handle openssl, cairo and similar ports automatically.

5 5

Re: sudo port -d selfupdate errors
by Juan Manuel Palacios 15 Jun '07

15 Jun '07

I changed a lot of stuff on our base sources on svn last night and worked on the new rsycn server, so I expect a little turmoil before things settle down again and start working seamlessly. I guess the main issue is that DNS entries still haven't propagated from the old rsync server to the new one. I'll see to that personally but I'm sure once that's through everything should be fine again! Give us some time and we'll post with a status update on the problem, thanks for your patience! Regards,... -jmpp On Jun 15, 2007, at 12:31 PM, paul beard wrote: > > On Jun 15, 2007, at 6:16 AM, Bill Hernandez wrote: > >> Any ideas, what I need to do to correct these errors other than >> not use the "-d" flag ? > > I don't think that would correct them: that would be akin to > sticking black tape over the warning lights in your car ;-) > > Your output should look something like this: > > white:~ root# port -d selfupdate > DEBUG: Rebuilding the MacPorts base system if needed. > DEBUG: Synchronizing dports tree(s) > > <snip> > > sent 77 bytes received 263980 bytes 16003.45 bytes/sec > total size is 14730546 speedup is 55.79 > DEBUG: MacPorts base dir: /opt/local/var/db/dports/sources/ > rsync.rsync.darwinports.org_dpupdate1/base > DEBUG: Setting user: root > DarwinPorts base version 1.442 installed > DEBUG: Updating using rsync > receiving file list ... done > ./ > <snip> > > sent 22803 bytes received 13465 bytes 5579.69 bytes/sec > total size is 2093103 speedup is 57.71 > Downloaded MacPorts base version 1.442 > The MacPorts installation is not outdated and so was not updated > DEBUG: Setting ownership to root > selfupdate done! > > -- > Paul Beard > words: http://paulbeard.org/wordpress > pictures: http://www.flickr.com/photos/pdb206/ > Are you trying to win an argument or solve a problem? > > > _______________________________________________ > macports-users mailing list > macports-users(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-users

1 1