Re: orphaned my ports

On 2011-12-21 00:34:48 -0600, Ryan Schmidt wrote: > I've marked you as retired on the list of MacPorts developers: > > https://trac.macports.org/wiki/MacPortsDevelopers#retired > > And I'll unassign your one remaining ticket: > > https://trac.macports.org/ticket/25151 OK. Thanks, -- Vincent L

orphaned my ports

Hi, This is just to inform you that I've orphaned my ports in r88158 as I will no longer be able to maintain them: the liquid of the cooling system of my Power Mac G5 (my only Mac OS X machine) has leaked, leading to random sleep, and since the machine is old and no longer supported, I won't try t

Re: bin:* dependencies and searched directories

On 2011-08-22 11:34:31 +0200, Rainer Müller wrote: > On 2011-08-22 02:01, Vincent Lefevre wrote: > > I got the following bug report: > > > > https://trac.macports.org/ticket/30922 > > > > The problem is that some directories in $PATH, like /usr/texbin,

bin:* dependencies and searched directories

I got the following bug report: https://trac.macports.org/ticket/30922 The problem is that some directories in $PATH, like /usr/texbin, are not searched by MacPorts. Shouldn't this be a change in base? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blo

Re: Upcoming Subversion 1.7

On 2011-07-16 15:03:05 -0700, Blair Zajac wrote: > On Jul 16, 2011, at 2:28 PM, Ryan Schmidt wrote: > >Users who want Subversion 1.6 can still do so by following the how-to: > > > >https://trac.macports.org/wiki/howto/InstallingOlderPort > > > >Or they can use the svn client built into Snow Leopard

Re: Changes for pari 2.5.0

Hi Jeremy, On 2011-07-03 17:31:46 -0700, Jeremy Huddleston wrote: > Hey vincent, > > I noticed that the banner printed in pari incorrectly identifies the compiler > when building with clang. > > I is being reported as "gcc-3.0": > >

Re: Changes for pari 2.5.0

On 2011-07-02 05:16:27 -0500, Ryan Schmidt wrote: > There may be legitimate cases for overriding the default variant description, > to provide more info (like pari and perhaps glew). Not sure what we should > do. Either leave things the way they are (and let the port author get a lint > warning

Re: Changes for pari 2.5.0

On 2011-07-01 04:18:56 -0500, Ryan Schmidt wrote: > We had decided years ago that we wanted standard variants to have > standard descriptions, hence the global variant descriptions file. > Do we really want to override the description of the x11 variant > here (or anywhere)? I assumed we would not.

Re: Changes for pari 2.5.0

On 2011-06-30 21:21:39 -0500, Ryan Schmidt wrote: > On Jun 30, 2011, at 20:27, Vincent Lefevre wrote: > > $ port lint pari > > ---> Verifying Portfile for pari > > Warning: Variant x11 overrides global description > > ---> 0 errors and 1 warnings found. > &

Re: Changes for pari 2.5.0

On 2011-06-29 09:56:13 -0700, Jeremy Huddleston wrote: > On Jun 29, 2011, at 7:18 AM, Vincent Lefevre wrote: > > For the description of x11, I could say: > > > > Build with X11 support for the high-resolution plotting functions > > Yeah, that sounds good. ditto f

Re: gcc invocation and -dylib_compatibility_version vs -compatibility_version

On 2011-06-29 09:59:55 -0700, Jeremy Huddleston wrote: > The command line options are -current_version and -compatibility_version. > They have been that way for as long as I've been in the Appleverse. OK, so I'll apply a patch to use them for all Mac OS X versions. > What problem are you seeing o

gcc invocation and -dylib_compatibility_version vs -compatibility_version

When testing pari 2.5.0, I got the following problem: http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1210 In short, with Mac OS X 10.4, the -dylib_compatibility_version and -dylib_current_version options should be written -compatibility_version and -current_version in the gcc invocati

Re: Changes for pari 2.5.0

On 2011-06-28 13:03:15 -0700, Jeremy Huddleston wrote: > Does the new version of pari use a native API for rendering plots > now, or wound -x11 just result in loss of that functionality? If the > latter, that should be mentioned in the x11 variant description. The various options are: --graphic

Changes for pari 2.5.0

Hi, PARI 2.5.0 is out and I plan to do the following changes in the Portfile: 1. Remove the gmp variant: PARI will always use GMP (and depend on it), as advised by the PARI developers (I don't see any reason not to use GMP: it is much better than PARI's native implementation, and probabl

Re: [78781] trunk/dports/perl/p5-libvorbis-perl/Portfile

On 2011-05-21 18:17:44 -0500, Ryan Schmidt wrote: > There are more steps than this needed to make a port replaced. Please see: > > https://trac.macports.org/wiki/PortfileRecipes#replaced-by > > Or: > > http://guide.macports.org/chunked/development.practices.html#development.practices.rename-repl

Remove p5-libvorbis-perl port?

I was at the origin of the creation of the p5-libvorbis-perl port. However this port is buggy and no longer supported upstream (last updated in 2004). Some of its features are provided by the p5-ogg-vorbis-header-pureperl port, which I added a few days ago. Should p5-libvorbis-perl be removed? --

Re: Error validating server certificate for 'https://svn.macosforge.org:443'

On 2011-05-01 14:08:21 -0700, William Siegrist wrote: > > On May 1, 2011, at 11:55 AM, Ryan Schmidt wrote: > > > When trying to commit a port update today, I get: > > > >> Error validating server certificate for 'https://svn.macosforge.org:443': > >> - The certificate is not issued by a trusted

Re: [75554] trunk/dports/tex/latexmk/Portfile

On 2011-01-30 13:25:23 +1100, Joshua Root wrote: > While I'm sure this works, setting distname to "." doesn't really make > sense. If anything you'd want to set worksrcdir, but really you probably > want to set 'extract.mkdir yes' instead. > > Also, instead of setting distfiles with a hardcoded ve

Re: libpng transition?

On 2011-01-22 09:43:20 +0100, Emmanuel Hainry wrote: > Citando Jack Howarth : > > > > On Fri, Jan 21, 2011 at 05:25:46PM -0800, Bradley Giesbrecht wrote: > > > > > > Putting your local repository ahead of rsync in sources.conf provides a > > > valuable method of preventing software from being upg

Re: 1.9.2

On 2010-08-05 12:46:04 -0700, Scott Webster wrote: > Could a command line switch be used to disable the locking > functionality where desired? My guess is that most users don't run > more than one port command at a time. I can understand why some would > want to though. I've never done it for fe

Re: CPATH versus -I

On 2010-06-19 02:26:00 +1000, Joshua Root wrote: > This is a risky change, which is why compiler.cpath and > compiler.library_path have only been in trunk until the 1.9.0 release. > Adding them doesn't seem to have broken much, but now we have to find > out whether removing -I${prefix}/include from

"sudo port -v selfupdate" fails with error code 25

A selfupdate seemed to be successful, but failed with the following error code: Congratulations, you have successfully installed the MacPorts system. To get the Portfiles and update the system, add /opt/local/bin to your PATH and run:

Re: MPFR in MacPorts

On 2010-06-10 21:37:53 -0700, Toby Peterson wrote: > I don't understand what you're trying to say. Do you mean a design > deficiency in MacPorts itself? If so, that makes no sense - ports > can install files anywhere. I think the point is that a single build (compilation) cannot install several po

Re: MPFR in MacPorts

On 2010-06-10 11:50:46 -0700, Toby Peterson wrote: > On Jun 10, 2010, at 11:26 AM, Jack Howarth wrote: > > Yes, but that is tangential to the fact that any soversion bump for > > a support library in MacPorts currently forces a mass migration to > > the new version since there is no support for co-

Re: MPFR in MacPorts

On 2010-06-10 11:50:49 -0400, Jack Howarth wrote: > Exactly the point. MacPorts sorely needs the same sort of split-off > feature as fink where a libmpfr2-shlibs/libmpfr3-shlibs split-off > package could contain the required runtime shared libraries which > can co-exist but the main libmpfr2/libmpf

Re: MPFR in MacPorts

On 2010-06-10 10:09:18 -0400, Jeremy Lavergne wrote: > We can easily make an mpfr3 port, which would result in the same > functionality. > > Naively, since the libraries have different versions in their names they > ought not conflict. > mpfr.0.dylib > mpfr.1.dylib But files like mpfr.h would c

MPFR in MacPorts

FYI, GNU MPFR 3.0.0 has just been released, but it is normal that I haven't updated the port yet: this new version is *not* binary compitible with the previous ones, and there are some dependencies that must be resolved first. For instance, the current Math::MPFR Perl module is not compatible with

Re: [63519] trunk/dports/devel/gmp/Portfile

On 2010-02-14 08:43:48 -0700, Marcus Calhoun-Lopez wrote: > At the web page http://gmplib.org/gmp5.0.html, the developers of GMP claim: > "GMP 5.0 is upwardly source and binary compatible with 4.x, and 3.x versions" It doesn't say that exactly. I read: "GMP 5.0 is upwardly source and binary com

Re: [63519] trunk/dports/devel/gmp/Portfile

Hi, On 2010-02-06 18:27:12 -0800, mcalh...@macports.org wrote: > Revision: 63519 > http://trac.macports.org/changeset/63519 > Author: mcalh...@macports.org > Date: 2010-02-06 18:27:10 -0800 (Sat, 06 Feb 2010) > Log Message: > --- > gmp: Update version 4.3.2 --> 5.0.1. [...]

Re: executable LaunchDaemons plist

On 2010-01-26 22:42:00 -0800, Michael Crawford wrote: > Just for grins I just tried the following on Ubuntu: > > $ cat runme.plist > > > This is some text > But this isn't > > > $ chmod +x runme.plist > $ ./runme.plist > ./runme.plist: line 1: syntax error near unexpected token `newline' > ./r

Re: executable LaunchDaemons plist

On 2010-01-26 16:33:01 -0800, Scott Haneda wrote: > On Jan 26, 2010, at 3:14 PM, Vincent Lefevre wrote: > > Similarly, org.freedesktop.avahi-daemon.plist and > > org.freedesktop.avahi-dnsconfd.plist are also executable. > > These are usually symbolic links, and not the actu

executable LaunchDaemons plist

With smartmontools @5.39_0+darwin, I can see: -rwxr-xr-x 2 root admin 404 2010-01-26 23:48:21 /Library/LaunchDaemons/net.sourceforge.smartmontools.smartd.plist Is it normal that this file is executable? Similarly, org.freedesktop.avahi-daemon.plist and org.freedesktop.avahi-dnsconfd.plist are a

Re: [61530] trunk/dports/gnome/liferea/Portfile

On 2009-12-13 19:52:12 -0600, Ryan Schmidt wrote: > I put the epoch line back in the portfile, because the epoch line > can never be removed from a portfile; the epoch can only ever > increase, otherwise MacPorts will not report the port as being > outdated. I put the epoch line above the version l

Re: MacPorts 1.8.1 has been released

On 2009-10-28 08:27:15 +1100, Joshua Root wrote: > Yes, that's . Thanks. If it is not fixed in the next version, I think that the upgrade instructions should mention this bug. -- Vincent Lefèvre - Web: 100% accessible validated (X)

Re: MacPorts 1.8.1 has been released

On 2009-09-29 09:50:00 +1000, Joshua Root wrote: > If you already have MacPorts installed, the preferred method for > updating is to run: > > sudo port selfupdate On Tiger: [...] ===> making install in src/programs ===> making install in src/programs/daemondo mkdir -p build /usr/bin/install -c

Re: The opendarwin .com debacle

On 2009-10-22 13:58:01 -0400, Jeremy Lavergne wrote: > Search for "pspp mac" and you'll find dp.com sitting at #4 or #5. > This demonstrates at least one way people are finding it: searching > for the open source project they want and "mac". In my example, > simply searching for "pspp" will not b

Re: The opendarwin .com debacle

Hi, (I've been quite busy these times and still am.) On 2009-10-14 20:14:54 -0600, Bryan Blackburn wrote: > Note that there really isn't any kind of actionable violation, as MacPorts > uses the BSD license, and the web page there looks to be his own creation... But is DarwinPorts a trademark? In

Re: --disable-dependency-tracking

On 2009-09-02 01:57:27 -0500, Ryan Schmidt wrote: > They do point out indirectly that not all software supports this > configure argument. For software that doesn't, your solution is > fine. But I would not characterize it as a problem with MacPorts to > be worked around; rather, it's simply a diff

use_xz?

Does MacPorts have a use_xz variable? Some tarballs are now distributed in both gz and xz compression format, and xz is significantly smaller than gz. For instance, for the coreutils 7.4: .tar.gz 9.3 MB .tar.xz 3.9 MB -- Vincent Lefèvre - Web: 100% accessible va

Re: emacs 23.1

On 2009-08-05 15:53:17 -0400, Jeremy Lavergne wrote: > I believe one can deactivate emacs 22 and install emacs 23. If a > revert is necessary, deactivate the new version and reactivate the > old one. No need for an extra port that will only be around for a > version. I meant *without having to de

Re: emacs 23.1

On 2009-08-05 14:23:37 -0400, Jeremy Lavergne wrote: > They could also choose to not upgrade -- no one forces them. But it would be nice if they could be installed side by side, like under Debian. It's difficult to guess whether one would find annoying bugs in the new version during the following

Re: macports website

On 2009-07-14 06:58:50 -0400, Jeremy Lavergne wrote: > Future work? I wonder, what were the advantages of going with XHTML > to begin with? One can use XML tools on it. I sometimes do that on the bug database to see if I haven't missed anything and so on. -- Vincent Lefèvre - Web:

Re: macports website

On 2009-07-14 16:13:46 -0400, Kristofer Henriksson wrote: > As a side note, such divergent error handling makes it a shame that > there is no debug-type option for error handling to be set in > browsers, with XHTML-style failure when debugging is enabled and > silent HTML-style perseverance when di

Re: Lint Spam

On 2009-05-15 09:30:10 +0200, Rainer Müller wrote: > On 2009-05-15 08:40, Anders F Björklund wrote: > > Lots of lint reports for the latest email obfuscations > > and the false positives from the version number checks... > > Does it still hit many false positives? Could you please give some > exam

Re: [50984] trunk/dports

On 2009-05-14 14:08:45 -0700, and.dam...@macports.org wrote: > Revision: 50984 > http://trac.macports.org/changeset/50984 > Author: and.dam...@macports.org > Date: 2009-05-14 14:08:43 -0700 (Thu, 14 May 2009) > Log Message: > --- > Maintainer email change, second batch, mail

Re: perl5.8 fixup

On 2009-03-16 15:07:19 -0700, Bradley Giesbrecht wrote: > I tried this earlier using > ./Configure ... -man1ext=1perl5.8 -man3ext=3perl5.8 I don't think it is a good idea to use a dot in the extension, as this can be very confusing (this would probably make completion fail or behave in a strange w

Re: perl5.8 fixup

On 2009-03-16 09:33:18 -0700, Bradley Giesbrecht wrote: > This could be good. Just not have perl5.8 install man pages. If perl > users don't use them why waste effort. I frequently use the Perl-related man pages. In practice, for the modules, they give the same information as perldoc (when the i

Re: perl5.8 fixup

On 2009-03-12 23:22:15 +, Eric Hall wrote: > Again, see /etc/man.conf, in particular the MANSECT line. But if you're using "man" from MacPorts, the config file is: /opt/local/etc/man.conf -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: <

Re: Duplicate Perl 5.8 libraries

On 2009-03-09 05:19:35 +, Marcus Calhoun-Lopez wrote: > Vincent Lefevre writes: > > > On 2009-03-08 18:22:46 +0100, Rainer Müller wrote: > > > Adam Byrtek wrote: > > > > When playing with dependencies for a new port that requires certain > > > &

Re: Duplicate Perl 5.8 libraries

On 2009-03-08 18:22:46 +0100, Rainer Müller wrote: > Adam Byrtek wrote: > > When playing with dependencies for a new port that requires certain > > CPAN libraries I found out that there are multiple p5 ports containing > > libraries already included in perl5.8. I had this problem with the > > follo

p5-image-exiftool

There's somthing strange: $ port cat p5-image-exiftool # $Id: Portfile 38454 2008-07-21 13:51:06Z bl...@macports.org $ PortSystem 1.0 PortGroup perl5 1.0 perl5.setup Image-ExifTool 7.37 maintainers blair openmaintainer description Perl interface to EXIF

Re: Ports recommending other ports

On 2009-02-10 09:02:15 -0500, Jeremy Lavergne wrote: > Would running into collisions be easily solved with that "we recommend" > messages? For example, some program may want PHP +apache2 and another > could want PHP +no_web. One should never recommend a port with a negative variant. This does n

Re: Ports recommending other ports

On 2009-02-09 13:10:06 +0100, Rainer Müller wrote: > Ryan Schmidt wrote: > > It might be nice if a port could recommend the user install another > > port in addition, via some new keyword. For example, graphviz could > > recommend the user install graphviz-gui as well. postgresql83 could > >

gtk2 x11 category and quartz variant

Is it normal that gtk2 is still in the x11 category, though there's now a quartz variant, that doesn't depend on X11 at all? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire

charset.alias bug

At least 5 ports installed a broken ${prefix}/lib/charset.alias file: http://trac.macports.org/ticket/11474 http://trac.macports.org/ticket/11968 http://trac.macports.org/ticket/16152 http://trac.macports.org/ticket/17084 Since this seems to be a more or less global problem, shouldn't the

Re: p5-getopt-long requires force (was: Re: Can't install gnucash)

On 2008-08-07 15:53:08 -0500, Ryan Schmidt wrote: > The current situation is an inconvenience, but things can be made to > work. > > When installing p5-getopt-long (and some others), use the -f flag to > force it to overwrite files from the perl5.{8,10} port. > > When upgrading perl, it will

Re: lzma tarball support

On 2008-08-04 11:26:12 +0200, Anders F Björklund wrote: > Added as http://trac.macports.org/changeset/38960 > > To install the "lzma" program, see port lzmautils. So, should the port build-depend on lzmautils? -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible

lzma tarball support

Hi, Some packages are now distributed with lzma compression instead of bzip2, e.g. texinfo 4.12: http://ftp.gnu.org/gnu/texinfo/ Going back to gzip would be a regression, in particular there is a big size difference (here 2.4 MB for gzip, 1.3 MB for lzma). What changes does a Portfile need to

Re: unison and protocol breakage

On 2008-02-17 09:15:47 -0500, Kevin Ballard wrote: > Right now we're providing the official, released, stable version. That's > what we should provide. I agree that it should be provided. What I was requesting is that 2.13 be provided as well (but 2.27 would still be the default). And I don't thi

Re: unison and protocol breakage

On 2008-02-17 08:36:37 -0500, Kevin Ballard wrote: > No, the solution here is to not do anything. Anybody using 2.13 needs to > upgrade if they want to work with 2.27. We are not in the business of > providing old port versions, and we *should not* be. So, what about these old db, qt and automak

unison and protocol breakage

The unison port has recently been upgraded from 2.13 to 2.27. The problem is that the protocol has changed between these versions, and unison 2.13 can't talk to unison 2.27: http://trac.macosforge.org/projects/macports/ticket/14172 The only solution that can work in every case (because users ma

Re: *-devel ports

On 2008-02-07 09:47:45 -0500, Daniel J. Luke wrote: > On Feb 7, 2008, at 9:03 AM, Emmanuel Hainry wrote: >> Seeing that there are 5 different postgresql port (7, >> 80, 81, 82, 83) makes me quite puzzled, which one is considered >> stable? > > Each postgres version in macports has an on-disk form

Re: *-devel ports

On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote: > 2008/2/7, Ryan Schmidt <[EMAIL PROTECTED]>: > >It was proposed that -devel ports should be updated to the latest > >stable version, if the latest stable version is newer than the latest > >development version. If we act on this proposal, then

Re: *-devel ports

On 2008-02-07 23:00:14 +0900, js wrote: > If the developer call it as stable and the other's development, > Let' follow it. > Anyone who like to use newer can easily choose -devel one. However this may be confusing for the end user, as depending on the developers, "unstable" doesn't always mean th

Re: *-devel ports

On 2008-02-07 14:50:03 +0100, Vincent Lefevre wrote: > It happens for tin almost each time a new stable version is released > (because it is released before new development work starts). [...] Here I meant a new stable branch (not just a bug-fix stable version), i.e. a new version of the fo

Re: *-devel ports

On 2008-02-07 22:08:57 +0900, js wrote: > I agree with you, > but I think that the situation that devel-ver < stable-ver is very > rare. I've never seen it. (By newer, you means the version number is > greater, right?) It happens for tin almost each time a new stable version is released (because i

Re: *-devel ports

On 2008-02-06 22:58:56 -0600, Ryan Schmidt wrote: > It's not really the place of a MacPorts port maintainer to second-guess > the developer of the software regarding what version is stable enough for > a user to use. The following may be useful to decide: * read the development mailing-list;

Re: *-devel ports

On 2008-02-05 13:57:30 +0100, Thomas de Grivel wrote: > Then we would have to warn new users about -latest not being so stable > because intuitively I would like the latest version to be installed > but what retains me the the previous one is that "it just works". For > the sake of stability I woul

Re: *-devel ports

On 2008-02-04 11:27:24 -0600, Ryan Schmidt wrote: > Regarding the suggestion to rename all *-devel ports to *-latest, in > light of the above change, the name "latest" would indeed seem to be > clearer. It would also remove any potential confusion with the RPM - > devel packages, which IMHO wo

Re: *-devel ports

On 2008-02-04 07:52:44 -0600, Ryan Schmidt wrote: > On Feb 4, 2008, at 06:51, js wrote: >> What's happen after -devel port get officially released? >> are they removed from svn? > > Some maintainers do that. I think most just leave the -devel ports > around. I think that both choices are a bad i

Re: tetex/texlive dependencies

On 2008-01-11 10:09:21 +0100, Anders F Björklund wrote: > Not sure if that is a great example. For now, _only_ perl5.8 provides > the ${prefix}/bin/perl program and perl5.10 doesn't provide it. Should > it follow the lead of python24/python25, where _none_ of the ports > supplies ${prefix}/bi

Re: Should /opt/local/bin/perl be deleted too ?

On 2007-12-21 10:34:00 -0500, robert delius royar wrote: > I compiled perl 5.10.0 with the same configuration that macports 5.8.8 > used. [I have the perl5.8 port set as the primary perl interpretor and > have created links in /usr/local/[bin|lib|share] to make it so that > other software fi

Re: Should /opt/local/bin/perl be deleted too ?

On 2007-12-20 11:52:21 -0700, Boyd Waters wrote: > On Dec 20, 2007, at 2:09 AM, Vincent Lefevre wrote: >> Is there a need for two different ports? > > Since you can't specify a version when you install a port, or use a > port in a dependency, then I've been told t

Re: Should /opt/local/bin/perl be deleted too ?

On 2007-12-20 12:52:48 -0500, Mark Gardner wrote: > There are some incompatible changes (see > http://search.cpan.org/~rgarcia/perl-5.10.0-RC2/pod/perl5100delta.pod#Incompatible_Changes), > so some might want to stick with 5.8. I'd say that very few modules or scripts should be affected (if any),

Re: Should /opt/local/bin/perl be deleted too ?

On 2007-12-20 10:00:24 +0100, Anders F Björklund wrote: > http://trac.macports.org/projects/macports/ticket/13641 > > Perl 5.10.0 has now been released, so there are now two > stable port versions available: "perl5.8" and "perl5.10" Is there a need for two different ports? -- Vincent Lefèvre <[E

Re: Ion3 license and possible removal

On 2007-12-14 15:26:12 +0100, Markus Weissmann wrote: > thanks for bringing this up here: Mr. Valkonen's license is absolutely > unbearable. > As an alternative: Perhaps you can bring the port back to the last sane > licensed version - don't know if this is useful and/or possible. > Either that

Re: Final steps for 1.6

On 2007-12-07 13:38:26 -0400, Juan Manuel Palacios wrote: > Adding our setting to MANPATH *only-if-it-already-exists* *and* if > we're not already in there was agreed here to be the "lesser evil" for > the time being, so that's what we're doing. If MANPATH does not exist at > all (differe

Re: Final steps for 1.6

On 2007-12-07 00:17:04 -0400, 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 ap

Re: New website done!

On 2007-11-23 17:32:01 -0400, Juan Manuel Palacios wrote: > In any case, I've been playing with X11 on Leopard lately but haven't > been able to experience this functionality, if I unset the DISPLAY > variable I simply can't open X11 programs from Terminal.app AFAIK, unsetting DISPLAY is

Re: New website done!

On 2007-11-22 15:38:50 -0400, Juan Manuel Palacios wrote: > On Nov 22, 2007, at 3:28 PM, William Davis wrote: >> More important, further down the page has: >> >> Add an appropriate X11 DISPLAY environment variable to run X11 >> dependent programs. >> >> Im not sure you wish to do that with Leopar

Re: Change in commit mails format

On 2007-11-19 19:00:45 -0400, Juan Manuel Palacios wrote: > What difference does it make to impose a "Reply-To" header at > the post-commit hook level or at the mailing list level? The overall > effect is the same. Well, this was a general rule. If someone (who is not the post-commit hook) s

Re: Change in commit mails format

On 2007-11-18 02:13:04 -0400, Juan Manuel Palacios wrote: > I still have to find where that header is being set, since the > relevant field on the mailing list administration page doesn't have > any value (i.e. Mailman itself doesn't seem to be setting the > Reply-To we currently have on thos

Re: Change in commit mails format

On 2007-11-17 01:51:59 -0400, Juan Manuel Palacios wrote: > If we remove that reply-to field and you reply to a commit mail, your > message will go directly to the committer and you'll miss this list (a > valid case scenario). If you reply-all then you get the committer and > changes... So

Re: Speed up build phase with "make -j"

On 2007-10-31 15:57:56 +0100, Markus Weissmann wrote: > So the discussion has narrowed to: > 1.) disabled by default on an "per-installation" option: > Can be toggled system-wide (with default "off"); ports have to actively > deny a parallel build attempt; > > 2.) disabled by default on a per-port

Re: Speed up build phase with "make -j"

On 2007-10-31 15:04:45 +0100, Markus Weissmann wrote: > On 31.10.2007, at 12:36, Vincent Lefevre wrote: > >> On 2007-10-31 12:26:44 +0100, Markus Weissmann wrote: >>> On 31.10.2007, at 05:13, Vincent Lefevre wrote: >>>> I disagree. Port maintainers should test th

Re: Speed up build phase with "make -j"

On 2007-10-31 12:26:44 +0100, Markus Weissmann wrote: > On 31.10.2007, at 05:13, Vincent Lefevre wrote: >> I disagree. Port maintainers should test their port to see if they >> work with "make -j". > > Well, you cannot reliably test this. If you're lucky it migh

Re: Speed up build phase with "make -j"

On 2007-10-30 16:20:18 +0100, Markus Weissmann wrote: > On 30.10.2007, at 13:52, Vincent Lefevre wrote: >> The bug could also be reported upstream, so that a ".NOTPARALLEL:" >> is added to the Makefile. > > Well, this simply is not going to work -- this has to be an

Re: Speed up build phase with "make -j"

On 2007-10-30 12:43:52 +0100, Anders F Björklund wrote: > Weissmann Markus: >> Yes, but I meant this to be a per-Portfile choice so a maintainer can mark >> his/her port as being able to build in parallel. Doing this with the >> sledgehammer for all ports that use 'make' might be a bit too much.

Re: gcc42 fails to build with texinfo 4.11

On 2007-10-01 14:32:54 +1000, Boey Maun Suang wrote: > So, as a workaround, would there be any problems in recommending > deactivating texinfo before installing affected ports, and then > reactivating texinfo after? (I'm assuming that Mac OS X >= 10.2.0 have > makeinfo installed with the BSD su

Re: gcc42 fails to build with texinfo 4.11

On 2007-10-01 10:59:48 +1000, Boey Maun Suang wrote: > I can confirm that I get the same problem trying to build port:gcc41. I > haven't the time to read the upstream mailing list just now (thanks for the > link), but, assuming that this is considered a bug in Texinfo that will be > fixed, I'd

Re: gmp port upgrade to 4.2.2?

On 2007-09-13 15:06:13 -0500, Ryan Schmidt wrote: > I am on 32-bit Intel and I have gmp 4.2.1_4 installed, as a dependency of > gcc42. I have no idea how to test whether it's working properly. Well, I > could run "port test" I guess. I think that most problems are build failure, but "port test"

gmp port upgrade to 4.2.2?

GMP 4.2.2 has been released. The gmp port is nomaintainer, but there are known problems with Mac OS X[*], in particular on x86, and I don't have an x86 Mac OS X machine to try. As I don't want to introduce problems on x86, could someone who has both kinds of machines try the upgrade? [*] http://gm

Re: [28902] trunk/dports/devel/ossp-cfg/Portfile

On 2007-09-11 01:26:28 -0700, [EMAIL PROTECTED] wrote: > --- trunk/dports/devel/ossp-cfg/Portfile 2007-09-11 08:16:38 UTC (rev > 28901) > +++ trunk/dports/devel/ossp-cfg/Portfile 2007-09-11 08:26:27 UTC (rev > 28902) > @@ -3,16 +3,21 @@ > PortSystem 1.0 > > name ossp

Re: Newbie Port Creator Questions

On 2007-09-04 00:38:15 +0200, Rainer Müller wrote: > GPLv2 is not necessarily incompatible with GPLv3. It is. > GPL lets the original author choose how new versions apply to the > software. See paragraph 9 of the GPLv2 [1]. > > --snip-- > | Each version is given a distinguishing version number.

Problem with the repository: bogus date

I've noticed the following error: $ svn log -r2 https://svn.macosforge.org/repository/macports svn: Bogus date -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Are

Re: Problem with patchfiles (same name for different versions)

On 2007-09-03 12:18:29 -0500, Ryan Schmidt wrote: > I also don't know if patchfiles/distfiles can be renamed after > download. In the absence of that feature, I recommend: > > dist_subdir ${name}/${version} > > (Instead of the default dist_subdir ${name}) Thanks, this solves the problem. -- Vinc

Re: zsh and zsh-devel

On 2007-09-03 12:22:17 -0500, Ryan Schmidt wrote: > What portname suffix would you propose instead of "-devel"? "-devel" seems > ok to me -- it indicates that this will install the version currently being > developed by the developers, as opposed to the version that is stable and > has already b

Re: Problem with patchfiles (same name for different versions)

On 2007-09-03 16:39:35 +0200, Vincent Lefevre wrote: > Upstream patches are versioned: they are in different subdirectories. > But MacPorts doesn't care, unless I've missed something to have the > subdirectory taken into account. Also, I tried specifying the directory after pa

Re: Problem with patchfiles (same name for different versions)

On 2007-09-03 16:20:04 +0200, Anders F Björklund wrote: > N_Ox wrote: >>> Usually the patch files are overwritten along with the Portfile. >>> So you have one set of Portfile + files for each version/release. >>> And when you add the new distfile for the new version of the port, >>> the old distfil

Re: Doc directory (was: [28480] trunk/dports/archivers/p7zip)

On 2007-09-03 15:57:47 +0200, N_Ox wrote: > Recent autotools-based package doc directories default to > ${name}-${version} (see libogg and libvorbis). But why did they do such a change? Note that this is a setting that comes from these particular packages, not from the autotools: libogg-1.1.3/do

  1   2   >