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

/Applications/DarwinPorts -> /Applications/MacPorts
by Randall Wood 30 Jan '07

30 Jan '07

If no one has any objections, I would like to complete the following no later than 14 Feb 2007: Change every reference to /Applications/DarwinPorts to /Applications/ MacPorts in every relevant Portfile. I would like to begin working on this on 11 Feb 2007. Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

5 6

darwinports_fastload source iteration
by Kevin Ballard 30 Jan '07

30 Jan '07

I was just poking around and in darwinports_fastload.tcl.in I discovered the following: # I could iterate on the directory, but the only way I know in Tcl involves a # native function we provide in pextlib. set dir [file join "@prefix_expanded@" share darwinports Tcl port1.0] catch {source [file join $dir pkgIndex.tcl]} set dir [file join "@prefix_expanded@" share darwinports Tcl package1.0] catch {source [file join $dir pkgIndex.tcl]} set dir [file join "@prefix_expanded@" share darwinports Tcl pextlib1.0] catch {source [file join $dir pkgIndex.tcl]} set dir [file join "@prefix_expanded@" share darwinports Tcl registry1.0] catch {source [file join $dir pkgIndex.tcl]} It's actually rather trivial to do this iteration - that block can be replaced with: foreach dir [glob -directory "@prefix_expanded@" -join share darwinports Tcl *] { catch {source [file join $dir pkgIndex.tcl]} } Should I go ahead and commit this change? Incidentally, this will source darwintrace1.0/pkgIndex.tcl (which the manual sourcing doesn't), but I looked in that file and it's just comments, so it won't make a difference. I am curious as to what darwintrace1.0 is for, since it doesn't provide any packages in pkgIndex.tcl. -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

3 5

Re: [21585] trunk/base/src/darwinports1.0/darwinports_fastload.tcl.in
by Mark Duling 29 Jan '07

29 Jan '07

macports-dev(a)lists.macosforge.org on Monday, January 29, 2007 at 2:39 PM -0800 wrote: >Revision >[ http://trac.macosforge.org/projects/macports/changeset/21585 ]21585 >Author >eridius(a)macports.org >Date >2007-01-29 14:39:37 -0800 (Mon, 29 Jan 2007) > >Log Message > >Iterate in darwinports_fastload using glob instead of hardcoding the >library names > > >Modified Paths > > [ >fcp://@bubbs.biola.edu,%235000280/Mailbox/%23197606511#trunkbasesrcdarwinports10darwinports_fastloadtclin >]trunk/base/src/darwinports1.0/darwinports_fastload.tcl.in How do I go about getting the updated portfile.7 mapage committed? http://trac.macosforge.org/projects/macports/ticket/4905 Mark

1 0

${perl5.lib}
by Mark Duling 29 Jan '07

29 Jan '07

Can I use variable ${perl5.lib} in portfiles? I could just try it but I'm curious and I don't have time to test it right now. If so I can add it to the port man page after x11prefix in the RUNTIME VARIABLES section. Mark

3 10

seeking example for port who moves only some files
by Olaf Foellinger 28 Jan '07

28 Jan '07

Hi, I'm looking for an example of a port that only extracts and installs some files. I want to add cleanscore which consists of a perl script and some documentation but nothing to compile. Please tell me the name of a port which has a similar source. Gruss Olaf

5 9

Please make postmaster@macports.org a valid email address
by Ryan Schmidt 26 Jan '07

26 Jan '07

Please make postmaster(a)macports.org a valid email address. See the failure message below for the consequences of not doing this, when trying to send messages to SourceForge email addresses. Begin forwarded message: > From: MAILER-DAEMON(a)smtprelay08.ispgateway.de > Date: January 26, 2007 14:48:28 CST > To: ryandesign(a)macports.org > Subject: failure notice > > Hi. This is the qmail-send program at smtprelay08.ispgateway.de. > I'm afraid I wasn't able to deliver your message to the following > addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > <patrikjj(a)users.sourceforge.net>: > 66.35.250.206 does not like recipient. > Remote host said: 550-Postmaster verification failed while checking > <ryandesign(a)macports.org> > 550-Called: 17.254.17.105 > 550-Sent: RCPT TO:<postmaster(a)macports.org> > 550-Response: 550 <postmaster(a)macports.org>: Recipient address > rejected: User unknown in virtual alias table > 550-Several RFCs state that you are required to have a postmaster > 550-mailbox for each mail domain. This host does not accept mail > 550-from domains whose servers reject the postmaster address. > 550 Sender verify failed > Giving up on 66.35.250.206. [snip]

1 0

Fwd: Fink FUSE interface to the package tracker
by Dr. Ernie Prabhakar 26 Jan '07

26 Jan '07

Hi all, I found this pretty intriguing -- anyone up for attempting something similar with MacPorts? -- Ernie P. Begin forwarded message: > From: Brendan Cully <bcully(a)users.sourceforge.net> > Date: January 25, 2007 11:12:43 PM PST > To: fink-devel(a)lists.sourceforge.net > Subject: [Fink-devel] [ANNOUNCE] FUSE interface to the package tracker > > Hi all, > > I've written an experimental (very raw) FUSE interface to the package > tracker. You can get a copy from its mercurial repository: > > http://hg.kublai.com/fink/trackerfs/archive/tip.tar.gz > > You'll need to have fuse-pyXX and beautifulsoup-pyXX installed too. To > run, try > > mkdir tracker > python trackerfs.py tracker > ... > umount tracker > > rmdir will flush the cache for the directory you attempt to remove. > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Fink-devel mailing list > Fink-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fink-devel

1 0

Massive property update - PLEASE READ
by Kevin Ballard 26 Jan '07

26 Jan '07

At this very moment I am committing a bunch of changes to properties. Unfortunately it's going to come across as... wow, 39 commits (assuming there are changes in every category, which there probably are). That's because I'm committing once per category because of issues I had trying to commit the entire thing at once. In any case, here's the change log: Massive update to svn properties on files: All patchfiles have svn:eol-style removed. All files that are not in fact able to be executed have svn:executable removed All binary files have svn:eol-style removed (and are probably corrupt) All binary files have svn:mime-type set to application/octet-stream All files which are not patchfiles or binary files have svn:eol-style set to native All Portfiles have svn:eol-style set to native and svn:executable removed In the future, please try and use the right properties. svn:eol-style native belongs on files which are line-ending-agnostic, like text files, shell scripts, tcl scripts, and other source files. Patchfiles must *NOT* have svn:eol-style set, as line endings are important in them. Additionally, be careful about svn:executable - there were some patch files with that set. Only set it if your file really needs to be executable. There are still a bunch of svn:executable shell scripts, but not all of them need it (most of them, for example, are passed as an argument to bash). I didn't bother removing it from scripts, but I did remove it from the patchfiles. Oh, and when adding patches, please don't create a folder structure like you can find in lang/gwydion-dylan/files. If you need to specify path, do something like patch-dir_dir2_dir3_filename. All patchfiles should be at the top level of the files/ folder. Oh, and this is a biggie. There are a handful of binary files in there that had svn:eol-style set. They are probably corrupt. I looked at 2 of them (both pngs) and those 2 definitely were corrupt, but I haven't checked any of the others. I don't know if there's any possibility of recovering these files, it depends on if the svn history has a copy of them before svn:eol-style was applied. When adding a binary file to the repository, make sure it does *NOT* have svn:eol-style set, and please do set svn:mime-type to application/ octet-stream (or you can use a more specific mime type if you know it). Speaking of mime types, when adding non-binary files I would recommend against setting the mime type. If you must, go with text/ plain. Setting something like e.g. application/x-tcl on a Portfile will probably prevent svn from display linewise diffs (svn is documented as treating all non-text/* mime types as binary, with known exceptions, but it doesn't list what the exceptions are). -Kevin Ballard -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

4 8

svn:eol-style property
by Kevin Ballard 25 Jan '07

25 Jan '07

There are a ton of files in the dports tree that have svn:eol-style set to native. In theory this would be a good thing, yes? Unfortunately, it's actually not. In the specific case of patchfiles (by far the most common type of file in the files/ directories), line endings cannot be modified or the patch utility will refuse to apply the chunks. In the more general case of anything in the files/ directories, I would assume that these files all were meant to work with their original line endings, and that, depending on the type of file in there, flipping the line endings could cause issues. The only type of file in which one could make a case for native line endings is *.txt files (of which there are a small handful). As for the Portfiles themselves, I assume Tcl doesn't care about line endings, so I see no problem with native eol-style on those. Does anybody have any objects to my removal of svn:eol-style on all files in the files/* directories (with the possible exception of *.txt files)? -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

4 14

Re: [patch] Postfix port
by Mark Duling 25 Jan '07

25 Jan '07

Sbranzo <sbranzo(a)gmail.com> on Friday, January 19, 2007 at 7:23 AM -0800 wrote: >Additionally the patch bumps version to 2.3.6, remove a broken download >link and uses sha1 instead of md5. > >After installation 2 files must be deleted, >/opt/local/var/spool/postfix/public/.turd_postfix and >/opt/local/var/spool/postfix/maildrop/.turd_postfix >But if I try to remove them in post-destroot or post-install >installation fails because they don't exist yet...in what phase do those >files get created? > >Please apply this patch. I removed troublesome .turd files in a port of mine at post-activate phase. I think it is ugly but I don't know of a better way. Does anyone else? I attached your patch to to http://trac.macports.org/projects/macports/ticket/10679. I want to see if anyone has a better idea and if you want to try to deal with the .turd files before committing. Mark

2 1