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

portname based distfiles directory
by Juan Manuel Palacios 15 Aug '07

15 Aug '07

Up until now we've uploaded tarballs and other distfiles to our distfiles section in svn to user named directories, together with a / distfiles/general dir for unmaintained ports. It's been discussed that using port name based directories is more natural and straight forward for the purpose of the /distfiles directory, so I wanted to poll you all on making such move. Other than logical organization, other benefits would be not needing the general dir any longer and the fetch proc finding the distfiles on the first hit, as seen by the following example: -> pwd trunk/dports/net/libpcap -> grep master_sites Portfile #master_sites ${homepage}release/ master_sites macports -> port -df fetch ---snip--- ---> Fetching libpcap DEBUG: Executing org.macports.fetch (libpcap) ---> libpcap-0.9.5.tar.gz doesn't seem to exist in /opt/local/var/ macports/distfiles/libpcap ---> Attempting to fetch libpcap-0.9.5.tar.gz from http:// svn.macports.org/repository/macports/distfiles/libpcap % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 423k 100 423k 0 0 26031 0 0:00:16 0:00:16 --:--:-- 22644 Moving to port name based directories would still allow us to use user named ones as they currently exist, if need be, thanks to the "macports:<user>" syntax for our distfiles in the fetch proc. So, what says you'all? Regards,... -jmpp

5 9

Re: MacPorts 1.5.11 (Fwd: [27780] branches/release_1_5/base)
by Juan Manuel Palacios 15 Aug '07

15 Aug '07

On Aug 14, 2007, at 5:12 PM, Chris Pickel wrote: > On 14 Aug, 2007, at 16:01, Juan Manuel Palacios wrote: >> And as a side (but relevant) note, notice that our version number >> is really just a floating point number (as defined by base/config/ >> mp_version) that we simply interpret in the more common x.y.z way, >> so that gives some more leeway there. I would, however, love to >> switch our practice to the common software versioning scheme, but >> that implies using the internal rpm-vercomp function in the >> selfupdate proc in macports1.0 (which currently only does a simple >> $old_version < $new_version? mathematical comparison). That's a >> future project of mine, but if anyone is interested in beating me >> to it, then by all means! ;-) > > As a side-note to your side-note, it might be better to use the > `package vcompare` command. This is a Tcl built-in so we wouldn't > have to worry about pextlib. Unlike rpm-vercomp, it only handles > numeric components, but fortunately, we only release MacPorts with > sane version numbers. macports1.0 already loading pextlib1.0, what benefits would vmcompare buy us over rpm-vercomp? Not retorting, just curious. I'd be inclined to use rpm-vercomp given that we can tweak it however we like if we so need. > >> So, in a nutshell, I could go either way with 1.5.2 or 1.5.11, >> whatever people prefer. I would just love to know the final status >> of the mtree validation feature to asses if I should release *now* >> or wait for some further debugging/developments. Markus...? >> >> I guess setting the deadline for tomorrow morning (GMT -4) is not >> too drastic... Regards,... >> >> >> -jmpp >> >> PS: I just noticed that the sole introduction of rpm-vercomp in >> selfupdate, to be able to use the x.y.z version format, would >> itself place some stricter rules on our versioning practices. We >> humans would recognize that 1.5.11 is a very small release only >> meant to correct very specific errors in 1.5.1, and therefore we >> would easily if not immediately realize (I believe) that 1.5.2 is >> a progression over the former... but not so in rpm-vercomp's >> words: 11 < 2 is *not* true in anyone's book, neither in rpm- >> vercomp's ;-) Anyone wanting to work on this should take a time to >> propose some versioning guidelines and discuss them openly for >> general adoption. > > I'm not sure I agree with your statement about 1.5.11; that's not a > proper way of indicating a minor change to 1.5.1, but an > incremental change after 1.5.8, 1.5.9, 1.5.10. The proper > representation would be "1.5.1.1". Both rpm-vercomp and package > vcompare understand 1.5.1 < 1.5.1.1 < 1.5.2. OK, so, due to popular demand I'm gonna push the next release as MacPorts 1.5.2 ;-) And I'm figuring it'll be tomorrow, given that some users are quite desperate about the mtree violations errors and not much else has been said about it here. > > What is problematic is that 1.511 > 1.6.0, so there would have to > be special handling in order to upgrade to a version that did > proper version comparison. Probably the easiest thing would be to > change the path to the version number and leave the old one for > legacy support. We will definitely need a migration path for selfupdating users once we move to proper version numbers in trunk, but I don't think moving the version number file around will be a requirement. We could, for example, code up the feature in trunk and release it as 1.6 (floating point just as 1.520), which current installations would pick up (plain mathematical comparison, so remember that 1.6 > 1.5999999999999999). We would then release 1.6.1 (proper version number) and have at-that-moment existing installations also pick it up 'cause {rpm-vercomp | vcompare} already in them would recognize 1 == 1, 6 == 6 and NULL < 1. That of course leaves the question of straggles (who'll attempt a direct move from 1.520 to 1.6.1) open, so I guess my strategy could also see some improvements In any case, I'm just brain storming over this whole thing and not even proposing we move straight from 1.520 up to 1.6.0 (properly named). If it happens, great! But in any case it's not something I'm requesting ;-) We need a proper migration path first so lets get it together before we attempt anything. Ideas? > > Chris Regards,... -jmpp

2 1

MacPorts 1.5.11 (Fwd: [27780] branches/release_1_5/base)
by Juan Manuel Palacios 15 Aug '07

15 Aug '07

Hello everyone! I just merged revisions r27709, r27710, r27711, r27719, r27720, r27773, r27779, comprising the latest work on mtree violations, into the release_1_5 branch in r27780, to make up for 1.5.11 very soon now. So soon that I could go ahead and release right now (all that's pending is just tagging and re-pointing the base/ config/RELEASE_URL file), but I want to make sure we have this thing nailed down and done right before going for 1.5.11 in order to avoid having to tell users to upgrade a third time (1.5.11 will be the second ;-) So, what's our status? I like the mtree violations feature a lot, dubbing it the trace mode compliment for cleanly building & installing ports, but it does seem a bit harsh to me to make its efect fatal errors (as expressed to mww on IRC yesterday). Are we gonna stay with warnings in the long run or just temporarily (until we see our ports tree cleansed of weird installation paths)? Also, are we gonna stick with a whitelist of "allowed paths" or go for a black one of "forbidden paths", as Landon suggested in a recent post? In short, are we good to go for 1.5.11 for the time being? (even if its fixes are only temporary). Regards,... -jmpp

5 8

Xcode universal
by Ryan Schmidt 15 Aug '07

15 Aug '07

nox, I've seen you do this a lot recently: -use_configure no +# Dummy configure to enable universal variant +use_configure yes +configure {} And this: +if {! [variant_isset universal]} { + set arch ${os.arch} + if {! [string compare ${arch} powerpc]} { + set arch ppc + } + + xcode.build.settings-append ARCHS=${arch} + xcode.destroot.settings-append ARCHS=${arch} +} I see those blocks in 9 ports so far, and I'm concerned about the duplication of code. Would it make sense to move this kind of thing into MacPorts base or the Xcode portgroup? Perhaps relevant is this existing ticket: http://trac.macosforge.org/projects/macports/ticket/11881 If there is a way that we can sanely support universal and non- universal builds for ports in the Xcode portgroup automatically, then we should do so automatically, rather than individually in each port.

2 1

Some new trac tickets
by Simon Ruderich 14 Aug '07

14 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I found some more Trac tickets which should be resolved: - - http://trac.macports.org/projects/macports/ticket/12407 Small fix for no longer working url. - - http://trac.macports.org/projects/macports/ticket/12404 Maintainer update. - - http://trac.macports.org/projects/macports/ticket/12403 +universal update, works fine for me on PowerPC and Intel. - - http://trac.macports.org/projects/macports/ticket/12402 +universal update, works fine for me on PowerPC and Intel. - - http://trac.macports.org/projects/macports/ticket/12398 Should be closed, was already fixed in r27503. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGuzUAYRX4BO+zMikRChOZAKCyaE4O/J4IiJhbY/Ng3Z4mKxhsCgCfY5J+ oh743cp2T4LPstyDyXc4XcA= =TFCu -----END PGP SIGNATURE-----

3 5

Re: [27824] trunk/base/portmgr
by Juan Manuel Palacios 14 Aug '07

14 Aug '07

I forgot to mention, the user I added to the dev list rooster is mp- user(a)geeklair.net. Hope I'm not out of line with this change ;-) -jmpp On Aug 14, 2007, at 4:41 PM, source_changes(a)macosforge.org wrote: > Revision > 27824 > Author > jmpp(a)macports.org > Date > 2007-08-14 13:41:52 -0700 (Tue, 14 Aug 2007) > Log Message > > There's nothing super sekret about index and guide regen, so make - > dev@ the primary recipeint of error > messages so that a wider audience can take a look at them if > anything goes south. > This implies adding the sender to the list rooster so that posts > make it through, which I just did > with the nomail flag set (pressumably no one will read anything at > that address). > Modified Paths > > trunk/base/portmgr/GuideRegen.sh > trunk/base/portmgr/IndexRegen.sh > Diff > > Modified: trunk/base/portmgr/GuideRegen.sh (27823 => 27824) > > --- trunk/base/portmgr/GuideRegen.sh 2007-08-14 20:34:53 UTC (rev > 27823) > +++ trunk/base/portmgr/GuideRegen.sh 2007-08-14 20:41:52 UTC (rev > 27824) > @@ -17,7 +17,7 @@ > # MP group. > MP_GROUP=mp-user > # e-mail address to spam in case of failure. > -SPAM_LOVERS=macports- > mgr@lists.macosforge.org,dluke@geeklair.net,markd@macports.org > +SPAM_LOVERS=macports- > dev@lists.macosforge.org,dluke@geeklair.net,markd@macports.org > > # Other settings (probably don't need to be changed). > SVN_CONFIG_DIR=${ROOT}/svnconfig > Modified: trunk/base/portmgr/IndexRegen.sh (27823 => 27824) > > --- trunk/base/portmgr/IndexRegen.sh 2007-08-14 20:34:53 UTC (rev > 27823) > +++ trunk/base/portmgr/IndexRegen.sh 2007-08-14 20:41:52 UTC (rev > 27824) > @@ -18,7 +18,7 @@ > # MP group. > MP_GROUP=mp-user > # e-mail address to spam in case of failure. > -SPAM_LOVERS=macports-mgr@lists.macosforge.org,dluke@geeklair.net > +SPAM_LOVERS=macports-dev@lists.macosforge.org,dluke@geeklair.net > > # Other settings (probably don't need to be changed). > SVN_CONFIG_DIR=${ROOT}/svnconfig > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes

1 0

Update Trac tickets with the new priority and type lists
by N_Ox 14 Aug '07

14 Aug '07

As I've got nothing to do these last days, I got tired of waiting for someone to install Trac and test the SQL requests needed for automatic update of Trac tickets. So I've began to update them manually. Here is a little status about where I am and what I've still to do. * Documentation: Milestone cleaned! * MacPorts 1.5: Milestone cleaned! * MacPorts base bugs: Milestone cleaned! * MacPorts base enhancements: Milestone cleaned! * Port Bugs: * Closed tickets: * Still 278 tickets with an invalid priority field. * Active tickets: * Still 110 tickets with an invalid priority field. * Port Enhancements: * Closed tickets: * Still 36 tickets with an invalid priority field. * Port Requests: Milestone cleaned! * Port Submissions: * Closed tickets: * Still 13 tickets with an invalid type field. * Port Updates: * Closed tickets: * Still 195 tickets with an invalid priority field. * Still 15 tickets with an invalid type field. I'll clean Port Enhancements, Port Submissions and Port Updates now. Feel free to clean Port Bugs, maybe I'll got tired of this task once I get to it ;) -- Anthony Ramine, a lazy french student. nox(a)macports.org

3 4

selfupdate with GNUstep
by Anders F Björklund 14 Aug '07

14 Aug '07

When using "port selfupdate" on platforms other than Mac OS X (such as Darwin, FreeBSD, Linux and probably most others too) it fails to find Foundation unless you set the environment up: checking for Apple Objective-C runtime... no checking for GNU Objective C runtime... yes configure: Using GNU Objective-C runtime checking for Apple Foundation library... no configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your environment, preventing the use of GNUstep's Foundation library configure: error: Could not find a working Foundation implementation Can we source {/usr,/usr/local}/GNUstep/System/Library/Makefiles/GNUstep.sh, as part of the "selfupdate" target, so that it works without configuration ? ("gnustep-base" is required to provide Foundation, for the tclobjc1.0 module) --anders PS. Ironically enough, GNUstep is not support on Darwin OS... But it works out of the box on FreeBSD and most Linux distros. For now I just set it up as part of the MP installation package.

3 6

Re: [27700] trunk/dports/devel/distract/Portfile
by Ryan Schmidt 14 Aug '07

14 Aug '07

On Aug 12, 2007, at 05:59, source_changes(a)macosforge.org wrote: > Revision: 27700 > http://trac.macosforge.org/projects/macports/changeset/27700 > Author: gwright(a)macports.org > Date: 2007-08-12 03:59:12 -0700 (Sun, 12 Aug 2007) > > Log Message: > ----------- > Add dependency on monotone and update other dependencies. You also: * Updated the port version * Reformatted all the whitespace * Changed the long description * Changed the destroot phase * Changed the master_sites URL * Removed the Id header (I put it back in r27760) * Did not indicate who authored these changes You may wish to amend your commit message with: $ svn propedit --revprop -r 27700 svn:log http://svn.macosforge.org/ repository/macports/trunk At the very least, you should describe everything you do in your commit messages, but it would be better in the future to separate these into several logically-grouped commits. In particular, whitespace changes should be made on their own, with no functional changes made at the same time. Otherwise it becomes very difficult to tell by glancing at a diff what functional changes have been made in a given revision. Mark, I'm afraid I haven't read most of the new guide yet, but if there's nothing in there yet about this, it would be useful to add. > Modified Paths: > -------------- > trunk/dports/devel/distract/Portfile > > Modified: trunk/dports/devel/distract/Portfile > =================================================================== > --- trunk/dports/devel/distract/Portfile 2007-08-12 10:34:35 UTC > (rev 27699) > +++ trunk/dports/devel/distract/Portfile 2007-08-12 10:59:12 UTC > (rev 27700) > @@ -1,24 +1,24 @@ > -# $Id$ > - > PortSystem 1.0 > -name DisTract > -description A distributed bug tracking system based on > monotone > -long_description DisTract is a distributed bug tracking system. > It uses \ > - Firefox as frontend for the user and the > monotone version \ > - control system as backend, which provides data > storage and \ > - network synchronization. > -version 0.2.3 > -homepage http://www.distract.wellquite.org > -master_sites ${homepage}/downloads/ > -categories devel > -maintainers me(a)thomaskeller.biz > -checksums md5 07d098c51755433ef11f886923d16cec > +name DisTract > +version 0.2.5 > +categories devel > +maintainers me(a)thomaskeller.biz > +description A distributed bug tracking system based on monotone > +long_description \ > + DisTract is a distributed bug tracking system. It uses \ > + the Firefox browser as frontend for user interaction and \ > + the monotone version control system as backend, which \ > + provides data storage and network services. > > -depends_build port:ghc\ > - port:haskell-chunks\ > - port:haskell-hinstaller\ > - port:haskell-parsedate > +homepage http://www.distract.wellquite.org/ > +master_sites http://www.distract.wellquite.org/downloads/ > +checksums md5 c806002ec1f73bf860bbb3164e2042dd > > +depends_build port:ghc \ > + port:hs-chunks \ > + port:hs-hinstaller > +depends_run port:monotone > + > configure { > cd ${worksrcpath}/haskell > system "runghc Setup.hs configure" > @@ -30,7 +30,7 @@ > } > > destroot { > - cd ${worksrcpath}/haskell/dist/build/DisTractInstaller > - system "cp DisTractInstaller ${destroot}/${prefix}/bin" > + cd ${worksrcpath}/haskell > + system "runghc Setup copy --copy-prefix=${destroot}${prefix}" > }

4 4

Fwd: Re: The mtree and man pages
by Anders F Björklund 14 Aug '07

14 Aug '07

Stupid, stupid, stupid Reply rules on this list... Forwarded message: (from me) > Boey Maun Suang wrote: > >> In addition, it's not much trouble at all to make a port install man >> pages into ${prefix}/share/man; in most cases, we either pass >> --mandir=${prefix}/share/man to configure or copy it ourselves. (I >> suspect that most of the ports that install man pages into >> ${prefix}/man are using configure script generated by autoconf < >> 2.59c, as it was only at that revision that it changed its default >> mandir to ${prefix}/share/man.) Consequently, I think we should >> stick with installing man pages into ${prefix}/share/man. > > Seems very redundant to have that --mandir in each and every little > Portfile. Might as well have the definition next to the default > --prefix=${prefix}, so that it would automatically add > --mandir=${prefix}/share/man --infodir=${prefix}/share/info ? Since > that is now the mandatory location, might as well make it the default > configure arguments as well... > > Some ports that install into ${prefix}/man either use their own build > system or plain have it hardcoded in their Makefiles. For example, > MacPorts have hardcoded the location of ${prefix}/share/man in > doc/Makefile, no matter what ${mandir} is ? The main reason why it > didn't used to be such a big fuzz, was because of the ${prefix}/man -> > share/man symlink. > > --anders

2 4