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

Fwd: MacPorts using its own libs
by William Davis 08 Dec '07

08 Dec '07

Begin forwarded message: > From: Jeremy Huddleston <jeremyhu(a)berkeley.edu> > Date: December 7, 2007 9:40:12 PM EST > To: William Davis <frstan(a)bellsouth.net> > Cc: Adam Mercer <ramercer(a)gmail.com>, X11 List Mailing <x11-users(a)lists.apple.com > > > Subject: Re: Xquartz version change? > > > On Dec 7, 2007, at 18:09, William Davis wrote: > >> er...Adam, thats a feature, not a bug. ;) See the MacPorts FAQ via www.macports.org >> But that FAQ entry needs updating, and perhaps the policy itself >> needs review ..... In any event, it was felt that MacPorts was >> doing a better job keeping the libs up-to-date. I say this for >> information only. If you want to discuss this you find competent >> folks on the macport-dev mailing list. > > Well that's not the case as the macports version of render-proto is > out of date and causes xserver to not compile when it is used. > > Why not have it be a lib dependency like you do for libX11? > lib:libX11.6:xorg > > so port:fontconfig would become: > lib:libfontconfig.1:fontconfig > > You could easily do this with a smart sed script. > > --Jeremy William Davis frstanATbellsouthDOTnet Mac OS X.5.1 Darwin 9.1.0 X11.app 2.1.0 - X.org X11R7.2 Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non

1 0

Guide regen job
by Juan Manuel Palacios 08 Dec '07

08 Dec '07

Hey guys! I'm happy to announce that I'm now working with Bill to setup our guide on the Mac OS Forge servers as http://guide.macports.org. In doing that I'm also testing it's automated regen, so that we can trigger it as a post-commit hook against the trunk/doc-new sources We're running into an error and some warnings, however: alpha:/tmp/mpdoctest root# make guide mkdir -p guide/html cp guide/resources/docbook.css guide/html/docbook.css cp guide/resources/images/* guide/html/ xsltproc --xinclude --stringparam html.stylesheet docbook.css -- stringparam section.autolabel 1 --stringparam toc.section.depth 1 -- stringparam generate.toc "book toc" --stringparam section.label.includes.component.label 1 --stringparam profile.condition "noman" --output guide/html/guide.html \ /opt/local/share/xsl/docbook-xsl/xhtml/profile-docbook.xsl guide/ xml/guide.xml WARNING: cannot add @xml:base to node set root element. Relative paths may not work. Error: no ID for constraint linkend: development.phases. Error: no ID for constraint linkend: reference.livecheck. Error: no ID for constraint linkend: reference.keywords.global. ID recommended on section: General ID recommended on section: Dependencies ID recommended on section: Port and Non-Port Dependencies ID recommended on section: Variants ID recommended on section: Livecheck / Distcheck ID recommended on section: Installation Phase Keywords ID recommended on section: A Word about Keyword List Modifiers (-ap... ID recommended on section: Common Uses for Keyword List Modifiers ID recommended on section: A Word about Keyword Argument Modifiers ... ID recommended on section: Fetch Phase Keywords ID recommended on section: Fetch from CVS ID recommended on section: Fetch from Subversion ID recommended on section: Checksum Phase Keywords ID recommended on section: Extract Phase Keywords ID recommended on section: Patch Phase Keywords ID recommended on section: Configure Phase Keywords ID recommended on section: Configure Universal ID recommended on section: Automake and Autoconf ID recommended on section: Build Phase Keywords ID recommended on section: Destroot Phase Keywords ID recommended on section: StartupItem Attributes ID recommended on section: Executable StartupItems ID recommended on section: Script StartupItems ID recommended on section: Loading / Unloading StartupItems into la... ID recommended on section: StartupItem Internals ID recommended on refentry: PORTGROUP ID recommended on refentry: PORTHIER Care to comment on them? Regards,... -jmpp

1 0

Re: [31795] trunk/dports/security
by Ryan Schmidt 07 Dec '07

07 Dec '07

Some comments... On Dec 7, 2007, at 13:12, ricci(a)macports.org wrote: > Added: trunk/dports/security/afflib/Portfile > =================================================================== > --- trunk/dports/security/afflib/Portfile > (rev 0) > +++ trunk/dports/security/afflib/Portfile 2007-12-07 19:12:12 UTC > (rev 31795) > @@ -0,0 +1,55 @@ > +# $Id$ > + > +PortSystem 1.0 There should be a newline after this line; see "port lint" (in MacPorts 1.6.0 and later). > +name afflib > +version 3.0.4 > +revision 0 0 is the default revision; you don't need to specify it. > +categories net The port is in the "security" directory but says its category is "net"? That doesn't match. > +maintainers opendarwin.org(a)darkart.com > +description The Advanced Forensic Format > +homepage http://afflib.org/ Probably "homepage http://www.aflib.org/" would have been better since "http://afflib.org/" redirects to that. > +platforms darwin > + > +long_description AFF(R) is an open and extensible file format > designed \ > + to store disk images and associated metadata. > + > +master_sites http://www.afflib.org/downloads/ Then you could just say "master_sites ${homepage}downloads/" here. > +checksums md5 60730870a313056ae85aa489141714e7 \ > + sha1 6b17e3297fb6825e3748a8f4aef6065b77a69291 > +## rmd160 dd5a0bb35bf27c2c16794580a6e9861fffe78ccc Why is the rmd160 checksum commented out? > +use_bzip2 no The default is not to use bzip2; you don't need to specify it. > +## depends_lib port:libewf \ Why is this dependency commented out? > +depends_lib \ > + port:openssl \ > + port:readline \ > + port:zlib > + > +configure.args --enable-fuse=no \ > + --enable-s3=no \ > + --with-ssl=${prefix} \ > + --with-zlib=${prefix} There's extra whitespace after this line, which "port lint" also mentions. > +variant s3 description { Enable the use of Amazon's S3 service } { > + configure.args-append --enable-s3=yes \ > + --with-curl=${prefix}/lib > + configure.args-delete --enable-s3=no > + depends_lib-append port:curl \ > + port:expat > +} > + > + > +## untested.... > +## variant fuse description { Access AFF data through FUSE } { > +## configure.args-append --enable-fuse=yes > +## configure.args-delete --enable-fuse=no > +## Extra white space after this line. > +## } > +## > + > +# > +##EOF We all know where the end of the file is; you don't need a comment for that. :) > Added: trunk/dports/security/libewf/Portfile > =================================================================== > --- trunk/dports/security/libewf/Portfile > (rev 0) > +++ trunk/dports/security/libewf/Portfile 2007-12-07 19:12:12 UTC > (rev 31795) > @@ -0,0 +1,30 @@ > +# $Id$ > + > +PortSystem 1.0 Missing newline here... > +name libewf > +version 20070512 > +revision 0 Is the default... > +categories net Category mismatch... > +maintainers opendarwin.org(a)darkart.com > +description Libewf is a library for support of the Expert Witness > Compression Format > +homepage https://www.uitwisselplatform.nl/projects/libewf/ > +platforms darwin > + > +long_description Libewf is a library for support of the Expert > Witness \ > + Compression Format (EWF), it support both the SMART \ > + format (EWF-S01) and the EnCase format (EWF-E01). \ > + Libewf allows you to read and write media information within the > EWF files. > + > +master_sites http://www.uitwisselplatform.nl/frs/download.php/303/ > + > +checksums md5 5c09ed6478eadd020d6de0ea61569a8e \ > + sha1 0fba1160cc42ca6f280fcca7ba2de84b49c86bdc > + > > +use_bzip2 no Is the default... > +## master_site uses a self-signed cert and appears to force the > use of SSL. > +## libcurl chokes on this, so disable cert. validation > +fetch.ignore_sslcert yes > + > +# > +##EOF Is unnecessary. :)

2 1

Re: Final steps for 1.6
by Juan Manuel Palacios 07 Dec '07

07 Dec '07

On Dec 7, 2007, at 12:26 AM, Jordan K. Hubbard wrote: > I'm just curious, and I hope you'll pardon my attack of manager- > ness here, but what [hopefully documented] list of objectives > drives each release? In other words, how do you know when you're > "done" for 1.6 or, perhaps more importantly, 1.7? Is it your > personal TODO list, as you note below, or is there a more global > project TODO list driving the release parameters? > > Thanks, > > - Jordan It is no secret that our releases don't follow a documented plan and/ or set of goals, but I still defend what they add to our final product (because it's also no secret that you've adversed us doing releases in the first place ;-), even if only on the organizational front. Projects usually cut releases of their products because: a) They need to break backwards compatibility in some way. This is not our case nor is there anything in our sources currently pressing us to do something like that. Nevertheless, the 1.6.0 release will contain a small but important API change I introduced to make MacPorts scripting much much easier; now, writing a script for the macports1.0 API is as easy as loading the appropriate TCL package and then calling "mportinit", nothing more. That paved the way for the revival of the regularly updated http://www.macports.org/ports.php page, but this time round *way* improved with proper error detection and reporting for the DB updating job (precisely why I introduced the API changes, cf. http://trac.macports.org/projects/macports/browser/ trunk/base/portmgr/jobs/PortIndex2MySQL.tcl , which will not work with pre-1.6 sources). I hope it'll also pave the way for many more and simpler scripts that will help us achieve more things (hint: build farms!). b) A documented plan and/or set of goals has been completed, which probably can't be applied to us under strict formality either. This is likely why a set of Trac milestones to organize our "base" development on our Roadmap has hitherto been less than satisfactory, I know. This would, I agree, basically render our releases (and release numbers, for that matter) as largely arbitrary. Nevertheless, it is still not a personal TODO list of mine what has been driving each release to this moment, but rather public discussion on this list that I always try to encourage. Every so often after a release has been put out the door, we gather here to discuss the code delta existing between the latest release and trunk, and based on that we decide as a group what should be handed out to users and what should be kept in for further testing and polishing. It was my feeling that a lot of already-well-tested code and resulting improvements to MacPorts on many many fronts (cf. http:// trac.macports.org/projects/macports/browser/trunk/base/NEWS , all of it pertaining to the 1.6.0 release) had accumulated in trunk since the 1.5.2 release, and therefore I pushed for 1.6.0. Added to that, but certainly by no means "least" as they say, is our 100% refreshed website (which drives us back to point a) above) and our new guide at http://geeklair.net/macports_guide/ , next to be moved to Mac OS Forge servers with automatic regen in place (just as the new website). All these new goodies seemed to me like a good set of things to package with a new release, even if the release itself has been delayed due to testing and polishing. So, all in all, do we have an official and formal roadmap driving the planning and putting together of our releases? Certainly not. On the other hand, are our releases little more than self-indulging treats....? The above explanations help me say "certainly not" too ;-) I do hope to improve the current situation, however, and will try to put a more formal roadmap for 1.7. After reviving our website and documentation, which was my number 1 *top* priority, I plan to devote to logging support in port(1) and/or macports1.0 (cf. http:// trac.macports.org/projects/macports/wiki/LoggingProposal) and based on that start the work on automated builds that can be properly traced and logged (worth also mentioning too is that 1.6.0 will contain Eugene Pimenov's GSoC work on a much improved trace mode, which will help us even further in creating clean builds in automated fashion). So, here's hoping this reply didn't come off as much of a retort but rather an explanation of what we're doing... ;-) Regards,... -jmpp > > On Dec 6, 2007, at 8:17 PM, Juan Manuel Palacios wrote: > >> >> My list of outstanding TODOs for the 1.6 release is almost empty >> after finishing what I committed in r31774, directly to the >> release branch: a rethought and rewritten postflight script to add >> PATH and MANPATH settings as appropriate to the user's shell >> configuration file. Please read the commit log and test the >> script, reporting any findings you have. >> >> The only things that remain are selectively resyncing the branch >> with trunk and updating the proper License.html, ReadMe.rtf and >> postflight files in the files dir of the MacPorts port dir, for >> pkg installer creation. I plan to use svn:externals off of the >> release tag (once I create it) for the latter, rather than >> needlessly keep on duplicating those files across the repo. As for >> the former, selectively resyncing the release branch and trunk, I >> think there's nothing outstanding other than working out the >> differences between the postfight script on release and its trunk >> guise: on release we're still tweaking user shell configuration >> files and in trunk we're discussing James' additions to the /etc/ >> [man]paths.d/ directories, so those two fronts will likely remain >> decoupled for the time being. There's also James' "load" & >> "unload" new port(1) targets, which James explicitly requested >> remain only in trunk until further tested (which rules out the >> merger of Ryan's r31771, which if I understand correctly is a >> regression fix against the new targets). Am I correct? Anything >> I'm missing? >> >> Thanks for your help in getting 1.6 out ASAP (it's been delayed >> enough already ;-). Regards,... >> >> >> -jmpp >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev(a)lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev >

1 0

Re: Final steps for 1.6
by Ryan Schmidt 07 Dec '07

07 Dec '07

On Dec 6, 2007, at 22:26, Jordan K. Hubbard wrote: > I'm just curious, and I hope you'll pardon my attack of manager- > ness here, but what [hopefully documented] list of objectives > drives each release? In other words, how do you know when you're > "done" for 1.6 or, perhaps more importantly, 1.7? Is it your > personal TODO list, as you note below, or is there a more global > project TODO list driving the release parameters? Releases seem pretty arbitrary to me. In the case of 1.6, I think the important feature was: - added startupitem.netchange boolean flag (#12931, N_Ox in r30086). because I think we were seeing more of these failures on Leopard, though I haven't seen many lately on the list so maybe that was a false diagnosis. I thought there was another thing we were eager to release but looking through the ChangeLog I'm not reminded what it was. The release of "port lint" is important to me because it means we can finally write that post-commit hook that emails information from "port lint" to commiters and/or maintainers. I know you've argued in the past for abandoning "releases" as such. I guess we're just continuing with the existing strategy for now.

1 0

Re: [31762] trunk/dports/sysutils/memcached/Portfile
by Ryan Schmidt 07 Dec '07

07 Dec '07

On Dec 6, 2007, at 09:15, brett(a)macports.org wrote: > Modified: trunk/dports/sysutils/memcached/Portfile > =================================================================== > --- trunk/dports/sysutils/memcached/Portfile 2007-12-06 14:28:01 > UTC (rev 31761) > +++ trunk/dports/sysutils/memcached/Portfile 2007-12-06 15:15:38 > UTC (rev 31762) > @@ -2,7 +2,7 @@ > > PortSystem 1.0 > name memcached > -version 1.2.2 > +version 1.2.4 > revision 1 Don't do it now, but in the future remember to delete the revision line when upgrading a port's version. The revision should start at zero.

1 0

tickets mailing list
by Adam Mercer 07 Dec '07

07 Dec '07

Hi Is there a problem with the macports-tickets mailing list? As I've haven't received any emails from it for a couple of days even though there has been ticket activity. Cheers Adam

2 1

Can't find unassigned tickets anymore
by Ryan Schmidt 07 Dec '07

07 Dec '07

How do I find "unassigned" tickets in Trac now? I used to be able to do a custom query for "Owner is macports- dev(a)lists.macosforge.org" but that address does not appear in that menu anymore.

2 1

Ticket instructions
by Ryan Schmidt 07 Dec '07

07 Dec '07

So I've been referring people to this URL for instructions on filing tickets: http://trac.macosforge.org/projects/macports/wiki/TracTicketing But that now includes a link to "our official ticketing guidelines" here: http://geeklair.net/new_macports_guide/#project.tickets If the official guidelines are in the guide, can the wiki page content be completely replaced with a link to the guide? Or is there still information in the wiki page that has not been migrated to the guide? (If so, why hasn't it been migrated?)

2 1

Re: Final steps for 1.6
by Ryan Schmidt 07 Dec '07

07 Dec '07

On Dec 6, 2007, at 20:45, Juan Manuel Palacios wrote: > My list of outstanding TODOs for the 1.6 release is almost empty > after finishing what I committed in r31774, directly to the > release branch: a rethought and rewritten postflight script to add > PATH and MANPATH settings as appropriate to the user's shell > configuration file. Please read the commit log and test the script, > reporting any findings you have. > > The only things that remain are selectively resyncing the branch > with trunk and updating the proper License.html, ReadMe.rtf and > postflight files in the files dir of the MacPorts port dir, for pkg > installer creation. I plan to use svn:externals off of the release > tag (once I create it) for the latter, rather than needlessly keep > on duplicating those files across the repo. As for the former, > selectively resyncing the release branch and trunk, I think there's > nothing outstanding other than working out the differences between > the postfight script on release and its trunk guise: on release > we're still tweaking user shell configuration files and in trunk > we're discussing James' additions to the /etc/[man]paths.d/ > directories, so those two fronts will likely remain decoupled for > the time being. There's also James' "load" & "unload" new port(1) > targets, which James explicitly requested remain only in trunk > until further tested (which rules out the merger of Ryan's r31771, > which if I understand correctly is a regression fix against the new > targets). Am I correct? Anything I'm missing? > > Thanks for your help in getting 1.6 out ASAP (it's been delayed > enough already ;-). Regards,... Yes, r31771 is just a followup to the initial implementation of port load and port unload in r31500. Let's keep this feature in trunk a little longer, in case more little issues are found.

1 0