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

libmd vs. openssl
by Chris Pickel 04 Jun '07

04 Jun '07

(having thought about it, if I want to ask the developers something, it's better to mail this list than to put the question in the footer of a -users message) Since it stopped shelling out for md5, MacPorts has supported two libraries for checksums: libmd and libcrypto. It prefers to compile with libmd support, but apparently this doesn't always work [1]. The reasons for preferring libmd are pretty obvious: it supports the algorithms we want and doesn't have any more unnecessary bloat. The reasons against libmd are a) that Apple doesn't provide it, b) MacPorts officially supports only Apple, and b) apparently it doesn't always work. So, a couple of questions: 1. Has anyone successfully compiled MacPorts against libmd recently? 2. Would it be desirable to prefer libcrypto? 3. Would it be desirable to bundle libmd with MacPorts? It's a pretty lightweight library (152K compressed), so it would not be unreasonable to go with #3. Chris [1] http://lists.macosforge.org/pipermail/macports-users/2007-June/ 003691.html

1 0

Ticket #12042 (NEW AtomicParsley port)
by Cédric Luthi 04 Jun '07

04 Jun '07

It seems nobody committed the new AtomicParsley port I submitted a few days ago :-( http://trac.macosforge.org/projects/macports/ticket/12042 Cédric Luthi

2 1

UPDATE: take maintainership of sysutils/duplicity
by Adam Mercer 04 Jun '07

04 Jun '07

Hi Just tried submitting a ticket for this but when I try to log onto Trac I get the following error: Login to trac failed! Message was "". Anyway heres a patch that adds me as the maintainer to sysutils/duplicity port, could someone with commit access take a look at this and commit it to SVN? Cheers Adam

3 4

Re: [25842] trunk/dports/audio/esound/Portfile
by Randall Wood 04 Jun '07

04 Jun '07

Forgot to mention a whitespace change in the patchfiles list unrelated to any other changes. Sorry about that. On 3 Jun 2007, at 10:20, source_changes(a)macosforge.org wrote: > Revision 25842 Author rhwood(a)macports.org Date 2007-06-03 07:20:41 > -0700 (Sun, 03 Jun 2007) Log MessageUpgrade to version 0.2.38 Add > md5 and rmd160 checksums Claim maintainership Change dependencies > into port:-style dependencies Add some dependencies based on trace > output (and then accidentally delete my logs so that I don't get > all of the dependencies) Add explicit --enable-local-sound > configure argument Fix variant puredarwin to account for --enable- > local-sound (should this variant be a platform statement instead?) > Comment out pre-configure commands since they don't seem to have > any effect (please correct me if I'm wrong)Modified Paths > trunk/dports/audio/esound/Portfile > Diff > Modified: trunk/dports/audio/esound/Portfile (25841 => 25842)--- > trunk/dports/audio/esound/Portfile 2007-06-03 14:18:20 UTC (rev > 25841) +++ trunk/dports/audio/esound/Portfile 2007-06-03 14:20:41 > UTC (rev 25842) @@ -2,25 +2,35 @@ PortSystem 1.0 name esound - > version 0.2.37 +version 0.2.38 revision 1 categories audio - > maintainers nomaintainer(a)macports.org +maintainers > rhwood(a)macports.org openmaintainer(a)macports.org description > Enlightened Sound Daemon homepage http://www.tux.org/~ricdude/ > EsounD.html platforms darwin master_sites gnome:sources/esound/0.2 > use_autoconf yes use_bzip2 yes -depends_lib lib:audiofile. > 0:audiofile -depends_build path:${prefix}/bin/aclocal:automake \ - > path:${prefix}/bin/glibtool:libtool -checksums sha1 > f5fd4a138598b01471907cd758077513c45a0dc4 -configure.args --enable- > ipv6 --with-audiofile -patchfiles patch-esd.conf patch-esd_config.c > +depends_lib port:audiofile +checksums sha1 > 29133b0acd17ddac10c3a6769afa40a7cb596c91 \ + md5 > 1c48c100b450d617b58dacb59837d34f \ + rmd160 > d12605bcd24b697a5525b0e266d2bbca43edea32 +configure.args \ + -- > enable-ipv6 \ + --with-audiofile \ + --enable-local-sound > +patchfiles \ + patch-esd.conf \ + patch-esd_config.c > +build_depends \ + port:autoconf \ + port:perl5.8 \ + > port:pkgconfig variant puredarwin { - configure.args-append -- > disable-local-sound + configure.args-delete --enable-local-sound + > configure.args-append --disable-local-sound } long_description > EsounD, the Enlightened Sound Daemon, is a server \ @@ -30,9 +40,7 > @@ sound-related event from ICQ, the two applications won't \ have > to jockey for the use of your sound card. -pre-configure { cd $ > {worksrcpath} - system "env LIBTOOLIZE=${prefix}/bin/glibtoolize > autoreconf -vif" - } +#pre-configure { cd ${worksrcpath} +# > system "env LIBTOOLIZE=${prefix}/bin/glibtoolize autoreconf -vif" > +# } - - > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes 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 2

Two ports with name libgda
by James Berry 03 Jun '07

03 Jun '07

Hey guys, Investigating a discrepancy between port count numbers between PortIndex and db.macports.org, I see that we have two ports with the same name: The ports with file names libgda and libgda3 both carry port name libgda. I assume libgda3 should be named libgda3? James

2 2

Re: [25728] trunk/dports/python/py-numpy
by Jochen Küpper 03 Jun '07

03 Jun '07

On 30.05.2007, at 05:06, source_changes(a)macosforge.org wrote: > updated to py-numpy version 1.0.3 swapped dependency from gcc41/ > gcc42 to g95, much to the joy of everyone Not for me! I very much prefer gfortran over g95 for various reasons -- performance and political ones. Why don't you create variants for either fortran compiler, or use the one that is already installed? Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen- Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll

2 1

Re: [25283] trunk/base/src
by Ryan Schmidt 03 Jun '07

03 Jun '07

On May 16, 2007, at 23:57, James Berry wrote: > > On May 16, 2007, at 9:44 PM, source_changes(a)macosforge.org wrote: > >> Revision 25283 Author jberry(a)macports.org Date 2007-05-16 21:44:07 >> -0700 (Wed, 16 May 2007) Log MessageRemove workdir variable. * >> Placement of the work symlink in the portdir is now optional based >> on the place_worksymlink key in ports.conf. This defaults to yes. >> * New command Can't map the URL 'file://.' to a port description >> file ("Could not find Portfile in /Users/jberry/Projects/macports/ >> trunk/base/src"). Please verify that the directory and portfile >> syntax are correct. To use the current port, you must be in a >> port's directory. (you might also see this message if a pseudo- >> port such as > > This should have read "New command 'port work' prints the path to > the workdir, if there is one." > > I was foiled by command expansion inside of my svn -m. I corrected your log message in the repository. I'm a little concerned that I was allowed to do this. Is every committer really allowed to change any other committer's log messages? At the very least, an email should be sent to the changes list when revision properties are altered. Unfortunately, I cannot find any indication that svnnotify will do this. Other notification scripts, like commit-email.pl, will. >> outdated or installed expands to no ports). prints the path to the >> workdir, if there is one. These changes make it possible to have a >> port repository that is entirely readonly and not written to >> during build, etc. Note that by keeping place_worksymlink at its >> default value of yes, no behavior should be changed for the user/ >> developer. (until we decide to default this to no ;). There exists >> about three ports that use workdir, and these will need to be >> modified to use workpath instead. Looks like ten ports are affected: $ grep '{workdir}' */*/Portfile | cut -d ':' -f 1 | uniq aqua/AssignmentTrackerX/Portfile aqua/Lingon/Portfile aqua/MorsX/Portfile aqua/Smultron/Portfile devel/perforce/Portfile irc/infobot/Portfile net/arpwatch/Portfile news/nnap/Portfile x11/gtk-extra/Portfile x11/gtk2-extra/Portfile

2 1

Startupitems don't work as advertised
by markd＠macports.org 01 Jun '07

01 Jun '07

It has come to my attention that startupitems are not disabled by default. Yet they were intended to be as shown by the message: ########################################################### # A startup item has been generated that will aid in # starting XXXX with launchd. It is disabled # by default. Execute the following command to start it, # and to cause it to launch at startup: # # sudo launchctl load -w /Library/LaunchDaemons/org.macports.XXXX.plist ########################################################### Yet startupitems have this by default: <key>Disabled</key><false/> Can anyone shed light on this behavior? Mark

6 7

configure script of "macports" should not link against "/usr/local/"
by markd＠macports.org 01 Jun '07

01 Jun '07

Could someone with more programming skills than I comment on this ticket? A user thinks there should be a global fix to the problem we have with a manually installed readline. I think this must be done on a case-by-case basis. Am I missing something? http://trac.macports.org/projects/macports/ticket/12041 Mark

2 1

(no subject)
by Juan Manuel Palacios 01 Jun '07

01 Jun '07

Good afternoon everyone! At long last, I consider the work on my dp2mp-move branch almost 100% done, 99.99% lets say ;-) Here's a doc explaining all the implications moving to these sources has: http://trac.macports.org/projects/macports/wiki/MacPortsRenaming I'd love to get as much feedback as possible on all the renaming and moves, and an overall opinion of how things look like in a standard MacPorts installation after upgrading to this branch. I ask because this branch moves stuff like "/opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports" to "/opt/local/var/ macports/sources/rsync.macports.org/release/ports", as explained in the wiki doc, so if the chosen new paths are not what the majority regards as the best choice, corrections could be easily made before these sources are distributed to the masses. It is my intention to merge all of the branch back into trunk ASAP, after consensus is reached on best "new conventions", since people writing code against current trunk will surely have to rewrite some parts of it after this is merged, albeit changes will hopefully be small. Nevertheless, I'd very much like to minimize this negative (and quite hateful, I understand) side effect. And finally, I say "almost 100%" and not "100%" because there are still a couple of small pending things, detailed in the "Pending" section of the doc. Taking care of them shouldn't take too long at all (remaining 0.01% ;-) Regards,.... -jmpp PS: The branch mirrors trunk minus sfiera's latest commit, which we could easily merge. Therefore merging should be painless, other than the drawback detailed above. Also, branch has been tested extensively and everything works "as expected", but please do not hesitate to send me any feedback/error reports. Thanks!

1 0