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

Re: [27201] trunk/base/doc/portfile.7
by Ryan Schmidt 24 Jul '07

24 Jul '07

On Jul 24, 2007, at 04:26, source_changes(a)macosforge.org wrote: > Revision: 27201 > http://trac.macosforge.org/projects/macports/changeset/27201 > Author: mww(a)macports.org > Date: 2007-07-24 02:26:13 -0700 (Tue, 24 Jul 2007) > > Log Message: > ----------- > add destroot.violate_mtree documentation > > Modified Paths: > -------------- > trunk/base/doc/portfile.7 > > Modified: trunk/base/doc/portfile.7 > =================================================================== > --- trunk/base/doc/portfile.7 2007-07-24 09:17:40 UTC (rev 27200) > +++ trunk/base/doc/portfile.7 2007-07-24 09:26:13 UTC (rev 27201) > @@ -1031,6 +1031,17 @@ > .br > .Sy Example: > .Dl destroot.keepdirs ${destroot}${prefix}/var/log/mysql > +.It Ic destroot.violate_mtree > +Indicates if a port will violate the common directory structure. > Enables or disables tests for violations of mtree (e. g. non- > standard directories in ${prefix}) [snip] What is an "mtree"? What is "the common directory structure"?

2 1

Re: mpage file not found
by markd＠macports.org 23 Jul '07

23 Jul '07

>I try to use macports since some days, it's a usefull tool to get new >software up and running. > >Today I can't install mpage, because mpage-2.5.4.tgz is not available on >http://www.mesa.nl/pub/mpage/, >only mpage-2.5.5.tgz is available yet. >I find a copy of mpage-2.5.4.tgz on >http://ftp.uni-kl.de/pub/linux/gentoo/distfiles/ >or >http://ftp.tu-chemnitz.de/pub/linux/gentoo/distfiles. > >Hopefully this is the right way so send bugs, ... >regards, Lutz I updated it to 2.5.5. After a few hours do a selfupdate and try installing it again. It is better to use the macports-user list than macports-tickets. Mark

1 0

SoC: current status (Elias Pipping)
by Elias Pipping 23 Jul '07

23 Jul '07

Hi, here's the status: merge.rb is a tool that's designed to merge an arbitrary amount of single-architecture directory-trees into a single universal tree. So, given the Coreutils scenario we have four directories - ppc, ppc64, i386, and x86_64, each holding a destroot whose architecture matches its name. Here's where merge.rb comes into play. It's invoked via merge.rb ppc ppc64 i386 x86_64, you can pass an architecture more than once (doesn't matter) or leave one out (does matter), pass -v or --verbose for verbose output, perform a dryrun, change input and output directories, etc. That's all documented[1]. There are also a couple of test cases, among them Coreutils, the others include OpenSSL and LibPNG - again, all documented[1]. merge.rb is written in Ruby. That's a good thing because it makes the code easy to read (even if one does not know Ruby at all) and maintain. The code is concise, flexible and extensible. It's not a bad thing because it does not (need to) use MacPorts internals, it could even be used if MacPorts was completely rewritten and none of its current API remained. I've set up a separate subversion repository[2] for merge.rb, from time to time I also sync it with /users/pipping in the MacPorts repository. The code is made available under the MIT license.[3] [1] merge.rb's wiki: http://elias.binera.de/dokuwiki/doku.php [2] merge.rb's repo: http://elias.svn.binera.de/bin/cgi/viewvc.cgi/ [3] merge.rb's license: http://www.opensource.org/licenses/mit-license.php ====== Up until now I've been working on merge.rb; I think it does what it's supposed to do and it does it well. Testing is appreciated. If you've been asking yourself where those 'ppc', 'x86_64', etc. directories are supposed to come from, that's part two. merge.rb could run on a server, clients could upload their trees (built via MacPorts) to the server, etc. - the infrastructure needs to be controlled/used somehow. There are a lot of open questions and that's why I'm asking for feedback. Given merge.rb would run on a server, how would it communicate/interact with clients? Who would initiate merges or what would they be triggered by, etc. What would you want to be able to do with it? Looking forward to hearing your ideas. Kind regards, Elias Pipping

4 5

Re: [27155] trunk/dports/python/py-psyco/Portfile
by Ryan Schmidt 23 Jul '07

23 Jul '07

On Jul 22, 2007, at 18:34, Landon Fuller wrote: > On Jul 22, 2007, at 1:10 PM, Rainer Müller wrote: > >> I see no reason why checking for darwin i386 could be wrong. Do we >> really need to take care of other Operating Systems than Mac OS X? I >> mean, it's called MacPorts now and is targeted on users of Mac OS >> X. Who >> is using it on another system? > > That's no reason to -intentionally- box yourself (or others) into a > corner. The requirement is for 'x86', not for darwin, and as such, > expressing a much broader dependency is incorrect. That's all that I meant to say. The software does not require darwin, so the test should not be in a "platform dawrin" section. Test for what you mean to test for. >> And also see the wine port again, LDFLAGS like "-framework" won't >> work >> on other platforms... As platform is set to "darwin", I think this is >> okay, but contrary to your statement above. I personally have no idea what -framework in LDFLAGS does. It's only in the portfile because that's how it was submitted to our issue tracker, and the port seemed to somewhat work in that state, so I committed it. I only have access to Macs to test on so I have no information about what this flag does on other platforms. If someone were to report a bug that a port doesn't work on another platform, and submitted a patch to fix the problem, I'd be happy to commit it. Your message is the first I've heard of this issue with the wine port.

1 0

Re: [27155] trunk/dports/python/py-psyco/Portfile
by Ryan Schmidt 22 Jul '07

22 Jul '07

On Jul 21, 2007, at 23:00, source_changes(a)macosforge.org wrote: > Revision: 27155 > http://trac.macosforge.org/projects/macports/changeset/27155 > Author: erickt(a)macports.org > Date: 2007-07-21 21:00:51 -0700 (Sat, 21 Jul 2007) > > Log Message: > ----------- > make sure we set that the platform only works on intel macs > > Modified Paths: > -------------- > trunk/dports/python/py-psyco/Portfile > > Modified: trunk/dports/python/py-psyco/Portfile > =================================================================== > --- trunk/dports/python/py-psyco/Portfile 2007-07-21 20:37:30 UTC > (rev 27154) > +++ trunk/dports/python/py-psyco/Portfile 2007-07-22 04:00:51 UTC > (rev 27155) > @@ -5,7 +5,7 @@ > > name py-psyco > version 1.5.2 > -revision 1 > +revision 2 > categories python > platforms darwin > maintainers erickt(a)macports.org > @@ -34,3 +34,5 @@ > ${destroot}${prefix}/share/doc/${name} > file copy ${worksrcpath}/doc ${destroot}${prefix}/share/ > doc/${name}/ > } > + > +platform darwin i386 {} There was no need to upgrade the revision: if somebody already had it installed, they were obviously already on a compatible architecture. Nothing is gained from forcing them to rebuild it. You may also wish to check for compatible architecture in a different way. Your way currently handles only on Intel Mac OS X, but according to the project's web site, it works on any OS so long as it's the _86 architecture. Consider doing it the way I've done it in the wine port: http://trac.macosforge.org/projects/macports/browser/trunk/dports/x11/ wine/Portfile

4 3

variant or platform
by Yves de Champlain 22 Jul '07

22 Jul '07

Hi I'm in a normalizing mood. I found out that 87 ports use variant darwin 10 ports use variant puredarwin 10 ports use variant freebsd 3 ports use variant powerpc 3 ports use variant x86 Now, that should be "platform", shouldn't it ? Should I go on and change everything ? yves

5 12

Adding myself to the cc field of a trac ticket
by Adam Mercer 20 Jul '07

20 Jul '07

Hi I need to add myself to the cc field of a trac ticket, but am unable to do so with the trac permissions setup as they are. This problem has come up in the past and I can remember being told that it was being worked on, so what is the current status of this? Cheers Adam

2 1

Re: [27043] trunk/base/portmgr
by markd＠macports.org 18 Jul '07

18 Jul '07

macports-dev(a)lists.macosforge.org on Monday, July 16, 2007 at 10:59 AM -0800 wrote: >--- trunk/base/portmgr/mprsyncup 2007-07-16 15:35:59 UTC (rev 27042) >+++ trunk/base/portmgr/mprsyncup 2007-07-16 17:59:44 UTC (rev 27043) >@@ -5,11 +5,25 @@ > # release tag (as determined by the base/config/RELEASE_URL file) and a >ports > # tree from trunk (ToT), and then export and sync all of them to the > # ${REPOROOT} location, wherefrom the rsync modules are fed to the `sync' >-# and `selfupdate' routines in port(1). >-# Read the base/portmgr/rsync.repos file for more information on both the >-# necessary rsync modules and filesystem level paths, which this script >-# bootstraps. >+# and `selfupdate' routines in port(1). Read the base/portmgr/rsync.repos >+# file for more information on both the necessary rsync modules and >filesystem >+# level paths, which this script bootstraps. > # >+# Whatever server uses this script to mirror the MacPorts rsync >repositories >+# should simply adapt the ${REPOROOT} path variable as necessary >(keeping it >+# in sync with the equally named variable in base/portmgr/rsync.repos) >and >+# install it on cron/launchd with a suitable periodicity, previously >discussed >+# with the portmgr@ team (macports-mgr(a)lists.macosforge.org) >Repositories >+# themselves are detailed & served by base/portmgr/rsync.repos, as >stated above >+# (that is, no manual intervention what-so-ever is needed, other than >installing >+# this script and adding the repositories detailed in >base/portmgr/rsync.repos >+# to a local rsyncd.conf file). >+# >+# Lastly, it is required of every 3rd party mirrors to keep track of >this script >+# and the base/portmgr/rsync.repos file and always maintain local copies >in as >+# close sync as possible. If I understood this better perhaps I could write it up in the new guide. When did this function become available? What do we call it? Remote repository? Is it basically an internal macports repository for the enterprise? Are the comments in mprsyncup and rsync.repos the only documentation we have? Mark

2 5

Re: livecheck.regex problems due to r26041?
by Ryan Schmidt 18 Jul '07

18 Jul '07

On Jul 17, 2007, at 19:28, Kevin Ballard wrote: > On Jul 17, 2007, at 1:12 PM, Ryan Schmidt wrote: > >> Could our recent livecheck regex issues (where regexes that we >> thought worked before suddenly are requiring additional escaping) >> be due to r26041? >> >> http://trac.macosforge.org/projects/macports/changeset/26041 >> >> The log message reads "Fix livecheck to properly de-escape >> livecheck.url" and the revision does indeed do that. But it also >> changes the processing of livecheck.regex without explaining why. > > Apparently, yes. I thought the amount of backslash escaping would > be the same, but what I didn't realize was that the join command > does a level of backslash interpretation. I changed it because we > should avoid using even where we don't need it. Also since > livecheck.regex really is a list using join is better than concat. I'll bet that's iPhone's incredible word substitution there. "Did you mean 'even'?" "No, blast it, I typed 'eval' and I meant 'eval.'" > Anyway, the solution is to add the -nobackslashes switch to subst. > This should restore handling of escapes to the former behavior. > Please go ahead and do it for me since I'm at work and don't have a > MacPorts checkout handy. > > Sent from my iPhone Tested -- it works! Committed: http://trac.macosforge.org/projects/macports/changeset/27079

1 0

Always print livecheck regex
by Ryan Schmidt 17 Jul '07

17 Jul '07

I've noticed that when "sudo port -dv livecheck" fails to match the regex against the contents of the URL, it prints: DEBUG: Port (livecheck) version is THEVERSION DEBUG: Fetching THEURL DEBUG: regex is >THEREGEX< DEBUG: url is >THEURL< Error: cannot check if THEPORT was updated (regex didn't match) But if the regex does match, it prints: DEBUG: Port (livecheck) version is THEVERSION DEBUG: Fetching THEURL DEBUG: The regex matched >THEMATCH< THEPORT seems to be up to date I propose that the line "DEBUG: url is >THEURL<" is superfluous and can be removed, and that I would like the regex to be printed in any case, especially now that we have either problems with or at least different behavior from the regex processor. Would the attached patch be acceptable to everyone?

1 0