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

New port pidgin-otr
by Thomas Reifferscheid 30 Dec '07

30 Dec '07

Dear list, there is a new port called pidgin-otr which is an encryption plugin for the instant messanger "pidgin". Please see the attached file and commit it to the svn. Kind regards Thomas Reifferscheid

1 0

Upgrade R port to version 2.6.1
by Kjell Konis 30 Dec '07

30 Dec '07

Could someone commit this upgrade to the R port: #13497: Upgrade R port to version 2.6.1 Thanks. Kjell Begin forwarded message: > From: David Ruau <david.ruau(a)rwth-aachen.de> > Date: December 29, 2007 4:22:00 AM PST > To: konis(a)stats.ox.ac.uk > Subject: About macport port of R > > Hi, > > I use the R version 2.5.1 from macport and I wanted to know when the > new R 2.6.1 will be available through macport? > If you need any help I would be glad to participate in the > maintenance of port. > > All the best and happy new year, > David > > --- > David Ruau > Institute for Biomedical Engineering > RWTH Aachen > >

2 1

Re: git-core hard link
by Boey Maun Suang 29 Dec '07

29 Dec '07

On Sat, December 29, 2007 11:23 pm, jt wrote: > On Dec 29, 2007 11:53 AM, Boey Maun Suang <boeyms(a)macports.org> wrote: >> Aren't those all those ${prefix}/bin/git-* files hard links to >> ${prefix}/bin/git already? The Makefile in the git source tarball sure >> looks to me like that's what it's creating, and the link count reported >> for each of those files by the second column of 'ls -l' is 2. > > Then the link count should be 70 (if there are 70 identical files) and not > 2. > A "du -c git*" will also show that those files are not hard linked. In that case, it might be worth checking with the upstream maintainers to see if what occurs in the MacPorts installation should be occurring, and if not, whether it is something that they should fix or that our port maintainer should fix. No sense wasting space if it can be avoided. Thanks for the heads-up. Kind regards, Maun Suang -- Boey Maun Suang Email: boeyms(a)macports.org

1 0

Re: Meet our brand new documentation! (Fwd: [31887]
by markd＠macports.org 29 Dec '07

29 Dec '07

>It is still not true that installing on other systems requires using >the source code, but of course that's an option just like on Mac OS X. > >It does require MP packages to be built, though. I thought it did. So how do you install MP on other systems without installing from source? Mark

3 2

epochs
by markd＠macports.org 29 Dec '07

29 Dec '07

I was refining the guide part about epochs, and after gleaning information from the FreeBSD ports collection documentation I followed their lead and wrote the final part below for our guide. But do we consider this a good practice? Or is it only a FreeBSD thing? "An epoch is not needed for most ports, and good use of a port's version can make using an epoch unnecessary even for application distributions without official version numbers. For example, if an application version 1.5 is superseded by a snapshot release 20081022, the new release could be given version number 1.5.20081022, rather than 20081022, so the newer release will have a numericaly greater value." Mark

2 1

git-core hard link
by jt 29 Dec '07

29 Dec '07

Hello, Just installed macports and git-core on 10.5 . I can see that lots of generated bin are just the same file: cd /opt/local/bin; for i in git-*; do diff -qs $i git-tag; done | grep identical | wc Some "cp" could be replaced by "ln" in the build process. Thanks for the port! -- jt

3 2

Re: [32364] trunk/base/src/macports1.0/macports.tcl
by Boey Maun Suang 29 Dec '07

29 Dec '07

Hi Juan, > My current idea is to create a base/config/macports_version file holding > something like 1.6.1, but the selfupdate > logic of reading the latter over base/config/mp_version has to be > thoroughly thought out: 600 (from base/config/mp_version's 1.600) > is greater than 6, so if we flat out select base/config/macports_version > to read the new version we will break > selfupdating for everyone, as rpm-vercomp will not see 1.6.1 as greater > than 1.600. Why don't we just hold off on applying this fully until we decide to release 2.0, whenever that may be? Surely we just avoid this problem then. Kind regards, Maun Suang

2 1

Lint and remote patches
by Pierre Queinnec 28 Dec '07

28 Dec '07

Hey all, Could it be possible to turn off lint warnings for patches that do not follow the naming convention (patch-*.diff) but are fetched using patch_sites? What do you think about that? -- Pierre

2 1

Make 1.6.0 the default version for new tickets
by Ryan Schmidt 28 Dec '07

28 Dec '07

When filing a new ticket, the default MacPorts version is still 1.5.2. Since 1.6.0 has been released, this should be changed to 1.6.0.

5 9

platform darwin 8 { configure.compiler gcc-4.0 }
by Ryan Schmidt 28 Dec '07

28 Dec '07

These lines in a portfile are useless now, right? platform darwin 8 { configure.compiler gcc-4.0 } Ever since default compilers were set in MacPorts base, gcc-4.0 is the default compiler on darwin 8 anyway, so we can remove these lines from all portfiles, right? I'm happy to do it, I just want to make sure this is correct before I do.

2 1