Re: [153110] trunk/dports/python

Thank you for pointing this out. I should not have left py26-twisted-web2 in a broken state. Python 2.6 support was dropped from py-twisted in 15.5 (http://labs.twistedmatrix.com/2015/12/twisted-155-released.html). I therefore put py26-twisted-web2 in the python graveyard (r153112). -Marcus > O

Re: [149057] trunk/dports/math

As far as I can tell, both libicns and makeicns allow for the creation of icns files, which is what the octave Portfile requires. I do not know, however, if there are any reasons to choose one over the other. -Marcus > On Sep 5, 2016, at 10:55 PM, Ryan Schmidt wrote: > > Is this different from

Help resolving #51424

In the octave port, I have the following code: set appName Octave.app ... foreach {key value} ${values} { system "/usr/bin/defaults write ${worksrcpath}/${appName}/Contents/Info ${key} ${value}” } where values is a list. /usr/bin/defaults exists and is working. The foreach loop seems to be

Dependences of textinfo

Concerning https://trac.macports.org/ticket/46105 textinfo currently has the following dependencies: Full Name: texinfo @6.0_1 Extract Dependencies: xz Build Dependencies: help2man Library Dependencies: gettext, libiconv, ncurses, perl5.2

Re: qt5-qtwebkit on < 10.9 (without libc++ being default)

It was not so much intentional breakage as a reflection of what was happening anyway. By default, qmake (the build system of qtwebkit) ignores the MacPorts build environment. Some care must be taken to mimic what MacPorts expects. Prior to the recent changes, you were probably building qtwebkit

Re: [144442] trunk/dports/aqua/qt5

r15 (https://trac.macports.org/changeset/15) is the change that broke things. Hopefully, it is fixed in r144467 (https://trac.macports.org/changeset/144467). Sorry for the inconvenience. -Marcus > On Jan 9, 2016, at 8:25 AM, Craig Treleaven wrote: > >> On Jan 8, 2016, at 6:50 PM, mca

Re: Python Portgroup modification

Such a thing would indeed be very helpful. Sorry. https://trac.macports.org/ticket/49948 <https://trac.macports.org/ticket/49948> -Marcus > On Dec 9, 2015, at 5:58 AM, Aljaž 'g5pw' Srebrnič wrote: > > Ticket # (and/or link to ticket)? :) > > On 9 dicembre 2

Python Portgroup modification

I filed a ticket with a proposed modification to python-1.0.tcl. Since this PortGroup affects so many other ports (many of which I do not have installed), can I get some feedback before I commit the change? Essentially, it seems that port destroot and port build && port destroot will result in di

Re: Warning: All compilers are either blacklisted or unavailable

The Qt compiler is set using files in the mkspecs directory (macs-clang or macx-clang-32). Clang is the only compiler currently supported (http://doc.qt.io/qt-5/supported-platforms.html ), which is the reason for compiler.whitelist clang. In the s

Re: [141094] trunk/dports/python/py-sphinx_rtd_theme/Portfile

You are absolutely correct. Thank you for catching this. The only difference in terms of what is installed is the file "SOURCES.txt" (see below). The source directory from github, however, has many additional files including screenshots. I will revert to using the smaller file from pypi. -Marcus

Feedback on Portfile design

A while back, I tried to create a small subport of qt5-mac to install Qt3D (see #48006). I now have a Portfile that installs all of the individual components of Qt 5 as separate installations. It is 1321 lines long and has 33 subports. It have not run into any problems yet, but I wanted to seek fe

Could dbus possible be doing damage?

Recently, a user reported having his root account deleted after installing the port dbus (Ticket #45737). I do not see how it is possible, but I though that we can not risk such a catastrophic result for anyone else. Can anyone image how such a situation could come about? Thanks, Marcus ___

Re: Question regarding qt5-mac

, but I am not an expert in it. As you say, you might get better information in a more Qt centered environment. -Marcus On Jul 7, 2014, at 2:57 PM, Marko Käning wrote: > Hi Marcus, > > On 07 Jul 2014, at 15:27 , Marcus Calhoun-Lopez wrote: > >> I am afraid I know very little a

Re: Question regarding qt5-mac

I am afraid I know very little about either KDE or the Continuous Integration System. As for Qt5, freetype, glib2, icu, pcre, libiconv, were added as dependencies because Qt5 supports them. Support for freetype, glib, icu, and iconv can be disabled (-no-freetype, -no-glib, -no-icu, and -no-icon

Re: [120845] trunk/dports

Thanks for pointing this out. Is it best to revert the unnecessary changes or simply note the problem for future reference? -Marcus On Jun 9, 2014, at 6:37 PM, Ryan Schmidt wrote: > On Jun 9, 2014, at 4:14 PM, mcalh...@macports.org wrote: > >> Revision >> 120845 >> Author >> mcalh...@macports

Re: [119187] trunk/dports/graphics/freeimage/Portfile

In r119199, I used configure.optflags-delete -Os Thanks for the improvement. I did not set -O3 because FreeImage sets its own optimization levels in the Makefile. -Marcus On Apr 19, 2014, at 8:47 PM, Ryan Schmidt wrote: > > On Apr 19, 2014, at 08:57, mcalh...@macports.org wrote: > >> Revis

Re: [118513] trunk/dports/devel/dbus

I see your point. I would be happy to remove it if such warnings are distracting and/or unhelpful. Does if {[variant_isset startupitem]} ever return true if there is NO variant startupitem { ? -Marcus On Apr 3, 2014, at 12:24 PM, Clemens Lang wrote: > Hi, > >> [118513]

Re: [118041] trunk/dports/databases/mysql56

On Mar 20, 2014, at 5:19 PM, Ryan Schmidt wrote: >> >> Some possible solutions were: >> 1) Blacklist clang for 32-bit builds, in which case MacPorts would fallback >> to llvm-gcc42. >> Since llvm-gcc42 is not working on Mavericks (#42849), this did not >> seem like an optimal choice. >

Re: [118041] trunk/dports/databases/mysql56

I submitted the patch that was committed in r118041. I will try to explain my tortured logic. mysql was already silently using g++ as the C++ compiler for 32-bit builds. Apparently, clang caused a problem at some point (See #42943 for more details). Some possible solutions were: 1) Blacklist clan

Reason for r37370 of qt4-mac

In http://trac.macports.org/changeset/37370, the plugin behavior of qt4-mac was changed "to prevent a resource leak." I have a port of QT Creator, but r37370 is an impediment. Without r37370, the port is trivial. The person who made the changes was removed as a maintainer (http://trac.macports.or

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

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" Is this the bug you were referring to? -Marcus On Sun, Feb 7, 2010 at 6:53 PM, Vincent Lefevre wrote: > > Hi, > > On 2010-02-06 18:27:12 -080

Re: [54368] trunk/base/src/port1.0

Ryan Schmidt writes: > > > On Jul 25, 2009, at 12:03, mcalh...@... wrote: > > > Revision: 54368 > > http://trac.macports.org/changeset/54368 > > Author: mcalh...@... > > Date: 2009-07-25 10:03:12 -0700 (Sat, 25 Jul 2009) > > Log Message: > > --- > > Wait, what? In this

Re: [53388] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

Jeremy Huddleston writes: > > > On Jul 4, 2009, at 12:49, Marcus Calhoun-Lopez wrote: > > > -arch was used over -m once before (see > http://lists.macosforge.org/pipermail/macports-dev/2009-April/008158.html) > > , but was changed back > > due to the reasons

Re: [53388] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

-arch was used over -m once before (see http://lists.macosforge.org/pipermail/macports-dev/2009-April/008158.html) , but was changed back due to the reasons given in the message. Is there a compelling reason -arch should be preferred now? -Marcus On Jul 4, 2009, at 10:38 AM, j...@macports.org

Re: [52182] trunk/dports/graphics/libart_lgpl

I was the one with "bright idea" to make the "insane" changes you found objectionable. Please allow me to explain my reasoning. 1) Getting a universal binary wrong (e.g. wrong sizeof(long)) can cause a very hard to track down bug. 2) Finding all the places where "#ifdef {__LP64__, i386, ppc

universal_sysroot

Forgive me if there was a discussion of this already, but why is universal_sysroot being removed? http://trac.macports.org/changeset/51905 http://trac.macports.org/changeset/51907 http://trac.macports.org/changeset/51894 http://trac.macports.org/changeset/51911 http://trac.macports.org/changeset/5

Re: [50487] trunk/dports/x11/xorg-cf-files/Portfile

Bryan Blackburn writes: > Since this changes the installed site.def should this have a revision > increase as well? > > Bryan > Thanks for catching this. Fixed in http://trac.macports.org/changeset/50517/trunk/dports/x11/xorg-cf-files/Portfile. _

Re: +system_x11 to bite the dust

Jeremy Huddleston writes: > > You bring up a good point, but I don't think it's as big a concern as > you might think. > > The client side (which is what is mainly > important) is almost identical to what is used on every other > platform. The upkeep at this point is mainly just updating

Re: qt4-x11 and x11prefix

Jeremy Huddleston writes: > > qt4-x11's qmake is causing built applications to use /usr/X11 instead > of /opt/local for X11... This has caused some problems here, and I'm > sure others might see it too: > > ... > > So to summarize, the qt libs themselves are linked against /opt/local/ > l

Re: +system_x11 to bite the dust

Jeremy Huddleston writes: > > So, the MacPorts-provided X11 libs should be regression free over what > is installed in any x11prefix. The hardware-rendering libGL was the > last nail, and that's been fairly stable for the past 1-2 months. > > Can we successfully nuke the backwards-compatib

Re: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

Ryan Schmidt writes: > > I still think rather than devote a lot of energy to this mechanism, > we should instead focus on building binaries, and let the server > merge them together -- or even let the user download both the powerpc > and intel binaries and have the user's macports merge th

Re: [MacPorts] #19232: RFE: Have gdbm use the muniversal PortGroup

Rainer Müller writes: > In my opinion there is no point in using muniversal if the existing > default variant already works. What would be the benefit of using that? > It just clutters the Portfile and makes it less readable. The default universal variant works for gdbm as far as I can tell, but

Re: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

Rainer Müller writes: > By the way, what is the current status of muniversal? I see you are > converting more and more ports to use it. Is it ready yet to be > integrated into base? I have already attempted to create some patches to be incorporated into the base. One stumbling block is my unfami

Re: [49117] trunk/dports/print/freetype/Portfile

Ryan Schmidt writes: > > +if { ${os.arch}=="i386" } { > > +if { ${os.major}>=10 } { > > +set merger_configure_env(ppc) CC_BUILD=${configure.cc} > > +} > > +set merger_configure_env(ppc64) CC_BUILD=${configure.cc} > > +} else { > > +set merger_configure_env(i386)CC_BU

Re: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

On Apr 4, 2009, at 3:31 PM, t...@macports.org wrote: > Message > More fixes to handle recent base change. > Also, remove insanity from muniversal_get_arch_flag > Modified Paths > • trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl > ... > > proc muniversal_get_arch_flag {arch} { > -

Redundant p5- libraries

Now that the very useful change of reversing @INC has been made r48955, will there be a rule of thumb for p5 dependencies already provided by perl5? Option 1: Only have the dependency if the newer version is needed. Option 2: If the package is needed, included it as a dependency even if the

Re: lcms update r48768

Joshua Root writes: > > The checksums don't match for lcms after r48768. > > - Josh > Apparently it depends on which sourceforge mirror the file is download from. The server http://voxel.dl.sourceforge.net/lcms seems to be fast but wrong so a bad file keeps being downloaded. I will remove so

Re: [48644] trunk/dports/python/py25-pydb/

Jeremy Lavergne writes: > > Watch out guys, you two are doing opposites of each other. > > We need to decide if we're doing py25-db or py25-pydb. > > On Mar 26, 2009, at 3:55 PM, mcalh...@... wrote: > > > revision48644authormcalh...@... > 12:55:35 > > -0700 (Thu, 26 Mar 2009)Log Message > >

Re: Universal and binary builds

Joshua Root writes: > Once again, I don't believe that the vast majority of users really want > universal, they are just using it as a hack to get x86_64. There may be > a few sharing builds between an i386 and a ppc machine, but they would > be better served by binaries. If the vast majority of

Re: Universal and binary builds

Joshua Root writes: > > Universal, however, should be limited to 32/64-bit universal as soon as > > possible. > > I see no reason to limit the functionality. Changing the default archs, > sure. Granted, but the extra functionality comes with a price, especially in Portfile creation and maintenan

Re: Universal and binary builds (was: Re: Is isysroot useful for non-universal?)

Ryan Schmidt writes: > I'm getting really burned out on universal. ... > > The new muniversal portgroup aims to solve this but has other severe > problems, in that the configure phase runs once for each > architecture, and some configure scripts are written wrong so they > try to run a pro

Re: Is isysroot useful for non-universal?

Daniel J. Luke writes: > Also, the last time I checked, with isysroot you only get the stuff in > the SDK so while it would fix looking in /usr/local, it would also > prevent looking in ${prefix} for headers and libraries, which we don't > want. There may be a way to work-around that though

Re: Is isysroot useful for non-universal?

Ryan Schmidt writes: > > > On Mar 21, 2009, at 21:34, Marcus Calhoun-Lopez wrote: > > > It is mentioned in http://trac.macports.org/ticket/17356#comment:6 > > that universal builds do not suffer from bad .la files because of - > > isysroot. > > That tic

Is isysroot useful for non-universal?

It is mentioned in http://trac.macports.org/ticket/17356#comment:6 that universal builds do not suffer from bad .la files because of -isysroot. Perhaps -isysroot could be used to solve other problems as well. If I understand the behavior, any compiler call with -isysroot would not see /usr/local/i

Re: KDE and qt4-mac

Ryan Schmidt writes: > > I propose the port be called qt44-mac. > I do not feel strongly about this, but I thought qt4-kde might be better since there was an indication in the previous thread (http://thread.gmane.org/gmane.os.apple.macports.devel/7504) that there were some KDE specific changes

KDE and qt4-mac

I would like to upgrade qt4-mac to version 4.5.0 (making it the same as qt4-mac-devel). It was indicated in another thread that this might not be entirely compatible with KDE (http://thread.gmane.org/gmane.os.apple.macports.devel/7504). I did not want to break all of KDE without some warning. If K

Re: [47969] trunk/dports/graphics/jpeg/Portfile

Ryan Schmidt writes: > > > + > > +# Reorder link flags so that so that local -L options come > > first (especially before -L${prefix}/lib) > > +# (see http://trac.macports.org/ticket/16411). > > +reinplace "s|\\(.*\\)\\(\$(LDFLAGS)\\)\\(.*\\)\\(\$(LDLIBS)\\)\ > > \(.*\\)|\\1\\4

Re: perl5.8 fixup

Eric Hall writes: > > On Tue, Mar 10, 2009 at 01:19:12AM +, Marcus Calhoun-Lopez wrote: > > > > Although I do not feel strongly about it, I would still vote for the order > > site, perl base/core, vendor. > > It seems that the smaller the change, the better

Re: perl5.8 fixup

Eric Hall writes: > Given that MP installs (most) modules into vendor_perl, > I think the order should be: > > site, vendor, then perl base/core. > > I like the line(s) you have for showing the directory ordering > in the patch, I'll incorporate those. > > I have a diff

Re: perl5.8 fixup

Eric Hall writes: > > On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote: > > I have played around with my perl5.8 port and I have what appears to > > me to be a solution to the path collision/registry issue. > > > > I modified my perl5.8 Portfile like so: > > > > configure.a

port commit not making it into rsync server

Earlier, I committed a change to gmp (http://trac.macports.org/changeset/47853). It has been many hours, and the change has not shown up when I run port sync. I do not see the change to graphviz-devel either (http://trac.macports.org/changeset/47862). Can anyone guess why this might be happening

Re: Duplicate Perl 5.8 libraries

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 > > > CPAN libraries I found out that there are multiple p5 ports containing > > > libraries already included in perl5.8

Re: [47866] trunk/dports/aqua

On Mar 8, 2009, at 7:39 PM, illogic...@macports.org wrote: > revision47866authorillogic...@macports.orgdate2009-03-08 16:39:51 -0700 > (Sun, 08 Mar 2009) >Log Message > Add Qt 4.5.0 as unstable portfile. > KDE 4.2.0 is reportedly more stable with Qt 4.4 so > we'll keep that as > main dependency now

Re: perl5.8 fixup

Bradley Giesbrecht writes: Thank you for the clarification. > > If I understand what is being discussed (please correct me if I'm > > wrong), > > we would > > * copy perl5.8 -> perl5.8-core. > > * create a port which installs all the core p5 ports. > > * make perl5.8 do nothing except de

Re: perl5.8 fixup

Ryan Schmidt writes: > On Mar 7, 2009, at 15:49, Bradley Giesbrecht wrote: > > > I don't know how useful perl is with no modules but it sounds good > > to me to be able to install perl without them. > > perl5.8-core sounds appealing. > > I don't think there's a desire to allow perl5 to be ins

Re: perl5.8 fixup

Eric Hall writes: > Ah, another case where that can fail is if module Y requires > module X at a particular version. If a calling script already imported > module X (at a lower-than-required version), I don't think module Y > will re-import the "right" version. This seems to be correct.

Re: perl5.8 fixup

Eric Hall writes: > > I think removing perl module ports that *currently* conflict > with and match modules installed by the perl5 port is a bad idea. > In particular, until perl5.8 @5.8.9, there were several perl modules > installed by perl5.8 (@5.8.8 here, File::Temp for example) that wer

Re: MacPorts 1.7.1

Rainer Müller writes: > > Ryan Schmidt wrote: > > > - Add mkdtemp Tcl command to create temporary directories. > > (#17181, perry) > > Is there anything using this? This is base internal code, so I don't > think it is reasonable to merge this without merging code which uses it. I would

Re: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

Joshua Root writes: > There's the hw.cpu64bit_capable sysctl variable, on Leopard. Just what I was looking for. Thank you. I only have Leopard machines to test on, however. Does anyone know if the code: if { [exec "/usr/sbin/sysctl" "-n" "hw.cpu64bit_capable"] != "1" } { . . . } works on all pl

Re: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

Ryan Schmidt writes: > Shouldn't care also be taken so that if one is on a 32-bit computer > (PowerPC G3 or G4, or Intel Core), the 64-bit architectures are removed? As far as I know, there is no way to get this information from MacPorts. Is there a command available on all these system which w

Re: A PortGroup for building more 32/64-bit universal packages

robert delius royar writes: > If any -arch is used and the system is > MAC_OS, it sets ac_cv_c_bigendian=universal. In the merge_universal PortGroup, -m32 and -m64 are used instead -arch ... if possible. Would these same problems arise with -m...? __

Re: A PortGroup for building more 32/64-bit universal packages

Ryan Schmidt writes: > I think we need to give the port the freedom to do things in post- > configure or other pre- and post- phases, per arch. As it stands now, any port which uses post-configure, pre-build, post-build, or pre-destroot will have to be modified to work with the merge_universal

Re: A PortGroup for building more 32/64-bit universal packages

Ryan Schmidt writes: > I decided to start with pkgconfig because it has no dependencies and > has issues building 64-bit with the old way. I got pkgconfig and merge_universal to build with the following addition if { ${os.arch}=="i386" } { set universal_archs_supported "ppc i386 x86_64

xorg-*proto ports and system_x11

Why do the xorg-* ports which have a system_x11 variant still pull in xorg-*proto ports? If I need to install install Xft2 +system_x11 (for tk), I still get header files from xorg-xproto. I am far from an expert on X11, but it seems to me that we either need to add a system_x11 variant to the prot

A PortGroup for building more 32/64-bit universal packages

I have a need of more 32/64-bit universal packages. To facilitate this, I would like to propose a PortGroup with a different universal build mechanism than the default. See http://trac.macports.org/ticket/17972. It is intended to be an improvement of the merge function. Any feedback would be grea

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

Ryan Schmidt writes: > > There is no "platform ppc"; it's "platform powerpc". > Thank you for pointing this out. It was fixed in r45254. -Marcus ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/lis

universal_variant depending on universal_archs

Recently, the universal variant of libffi was disabled (http://trac.macports.org/changeset/44994/trunk/dports/devel/libffi/Portfile). After a little experimentation, it seems getting full universal to work would be an unpleasant undertaking. Building a 32/64 bit universal seems to work fine though

Re: Restructuring Python ports?

Akira Kitada writes: > So it's going to remain the same: all-in-one python26 port and other > sliced python ports. > No intentional breakages are introduced. For what it's worth, I was a proponent of getting rid of disabled_module_list in python26 (http://trac.macports.org/changeset/42841). Most

Moving the location of a port

The package qtoctave-mac is located in x11 with categories x11 math. Since it does not use X11 in any way, it seems to me it would be better to place it in in aqua with categories aqua math. Does renaming a directory cause any problems with MacPorts (svn mv x11/qtoctave-mac aqua/)? -Marcus _

Re: Which python to use in glib2

Ryan Schmidt writes: > Does gtester-report need a specific version of python? Does it need > any python modules? The configure script requires that the version >= 2.4. The script itself calls import sys, re, xml.dom.minidom I believe they are standard. ___

Re: [43674] trunk/dports/audio/esound/Portfile

Ryan Schmidt writes: > Just out of curiosity, why replace patchfiles with reinplace calls? You make a good case for patchfiles, but, just as a personal preference, I default to reinplace. Usually, I find them easier to understand as I read, line by line, through a Portfile. Of course, in either c

Which python to use in glib2

I would like to submit a patch to glib2 which forces its python script to use a MacPorts python (see http://trac.macports.org/ticket/17530). I do not use the script in question (gtester-report), so I can not say with certainty which python to use. Might anyone who uses gtester-report be able to co

Re: [43102] trunk/dports/python

Adam Mercer <[EMAIL PROTECTED]> writes: > I was under the impression from upstream that numpy will not be fully > compatible with python26 on Mac OS X until 1.3.0, which is currently > scheduled for around Christmas, what testing have you done with this? You are correct. /opt/local/bin/python2.6

Re: py26 ports

Ryan Schmidt <[EMAIL PROTECTED]> writes: > > I see a lot of py26 ports being added. It looks like we've given up > on the consolidation idea? > > http://trac.macports.org/ticket/16723 > > I still think consolidation is a good idea, but, as noted in the ticket, it would be very difficult to

Re: [43004] trunk/dports/graphics/netpbm

Ryan Schmidt <[EMAIL PROTECTED]> writes: > Shouldn't the closing bracket be after the asterisk instead? Thank you for pointing this out. It was fixed in r43012. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.or

Re: [42732] trunk/dports/x11/xrender/Portfile

Ryan Schmidt <[EMAIL PROTECTED]> writes: > We had been on a push to switch ports from unversioned to versioned > documentation directories. If you want to undo that now, it would be > good to first discuss it on the list and reach a consensus, and then > apply it consistently in all ports.

Re: [42686] trunk/dports/math/metis/Portfile

Ryan Schmidt <[EMAIL PROTECTED]> writes: > That doesn't work if someone says > > sudo port configure metis > sudo port install metis Thank you for pointing out my oversight. It should be fixed in r42730 (http://trac.macports.org/changeset/42730). -Marcus ___

Re: [42457] trunk/dports/aqua/aquaterm/Portfile

nox <[EMAIL PROTECTED]> writes: > The custom variant will have to be removed when 1.7.0 is released. I will make a note of it in the Portfile and hopefully remember to remove the variant after 1.7.0 is released. ___ macports-dev mailing list macpor

Re: [41581] trunk/dports/devel/libidl/Portfile

Ryan Schmidt <[EMAIL PROTECTED]> writes: > > On Nov 6, 2008, at 07:40, [EMAIL PROTECTED] wrote: > > > Revision: 41581 > > http://trac.macports.org/changeset/41581 > > Author: [EMAIL PROTECTED] > > Date: 2008-11-06 05:40:00 -0800 (Thu, 06 Nov 2008) > > Log Message: > > ---

Re: [41395] trunk/dports/devel/autoconf/Portfile

Eric Hall <[EMAIL PROTECTED]> writes: > > Why do we have a perl5 port alongside the perl5.8 and perl5.10 > ports? If its breaking things it seems to me we shouldn't have a plain > 'perl5' port until we're ready to make an proper switch to it. > > -eric > > Both the perl5

Making changes to portgroups

Sometime in the future (after discussion is complete), I was hoping to commit a change to the perl5 portgroup based on the discussion in #16830. (http://trac.macports.org/ticket/16830) I was also hoping to commit a python26 portgroup I have based on the discussion in #16334. (http://trac.macports.

Re: [39093] trunk/dports/databases/freetds

Ryan Schmidt <[EMAIL PROTECTED]> writes: > Looks like previously the patches were applied only for darwin 7, 8, > and 9. Now you're applying the changes to all operating systems. Are > these changes appropriate for operating systems other than Mac OS X? > Did you determine why the patches w

Re: [39091] trunk/dports/x11/gtk-engines2/Portfile

Randall Wood <[EMAIL PROTECTED]> writes: > > Is there a reason you bumped this to an unstable development version? > GTK/GNOME versions are in the form x.y.z where an even y is stable and > an odd y is unstable. > Sorry about that. I inadvertently used a development patch. I meant to upgrade to

Meaning of "Not a directory"

I am experimenting with a local version of graphviz. During the activation phase, I get the error: Error: Target org.macports.activate returned: Not a directory Does anyone know the meaning of this error? The previous message is DEBUG: Adding link to file_map: /opt/local/Library/Frameworks/ Pyth

Re: py25-paramiko going back in time?

Looking at the port history, this appears to be an intentional change in response to problems with version 1.7.3. rollback: http://trac.macports.org/projects/macports/changeset/35415 bug report: http://trac.macports.org/projects/macports/ticket/14805 -Marcus On Mar 29, 2008, at 7:34 PM, Dougl

Re: destroot and (build && destroot) yield different results

Rainer Müller wrote: > Could you try to provide a minimal test Portfile which can be used > to track this down? I don't want to test with mzscheme or boost. It is difficult to construct a small Portfile for this problem. MacPorts runs make, and make calls another program (jam for boost and a

destroot and (build && destroot) yield different results

A few days ago, I submitted a ticket outlining situations in which it takes two runs of the port command for correct installation (http://trac.macosforge.org/projects/macports/ticket/14687 ). Is this a known behavior? I have attempted to track down the problem myself, but it has been slow g