Re: Removing mport:// sources (Was: Re: Removing port submit)

On 2013-08-22 06:47, Ryan Schmidt wrote: > > On Aug 20, 2013, at 19:33, Joshua Root wrote: >> On 2013-8-20 20:48 , Clemens Lang wrote: >>> On Tue, Aug 20, 2013 at 09:20:39AM +1000, Joshua Root wrote: Please revert the part that breaks the ability to install directly from a remote archive

Re: distfiles fetched via get variables

On 2013-08-14 19:12, Bradley Giesbrecht wrote: > name pcsxr > version 1.9.92 > > Fetch via curl: > curl > "http://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=pcsxr&DownloadId=140521&FileTime=12925482962180&Build=20686"; > -o pcsxr-1.9.92.tar.bz2 > > Are there fetch variabl

Re: [109338] trunk/dports/archivers/lzip/Portfile

On 2013-08-15 10:08, Ryan Schmidt wrote: >> Modified Paths: >> -- >>trunk/dports/archivers/lzip/Portfile > >> +checksums rmd160 cab15b04900c9355e4b2f6eec3c07c756046195d \ >> +sha256 >> 7ff5cc521560edb2a0a6cdf258cf3afdaeb1dbcc354d96d011d0dd7ec584cbe7

Re: [PATCH] Force build from source if macports.conf sets delete_la_files

On 2013-07-22 16:50, Jeremy Huddleston Sequoia wrote: > If delete_la_files doesn't match the default value, built packages won't > match what we expect. I think this was what caused > https://trac.macports.org/ticket/39767 > > I think this is the correct change, but I wanted to get a review bef

Re: I botched a checkin (bibtex2html) but am not sure why / how to fix

On 2013-07-22 00:44, John Owens wrote: > First, I apologize, but I'm not sure what I did wrong. > > I checked in the following: > > http://tinyurl.com/ly297tb > > When i then upgrade "bibtex2html", I get: > > Error: Unable to open port: couldn't change working directory to > "/opt/local/var/ma

Re: Macports Tcl

On 2013-07-07 20:51, Mark Anderson wrote: > Mainly because of my troubles with a certain OSX that is not to be named > or the fiery NDA demons will smite me. There are ways to communicate such problems to Apple for those who have such troubles. The common measure seems to be the more reports they

Re: Macports Tcl

On 2013-07-10 00:01, Clemens Lang wrote: > On Tue, Jul 09, 2013 at 07:21:41PM +0200, Gustaf Neumann wrote: >> It certainly needs an update in the macports base, but i would not >> expect this to be painful. Let me know, if i can help. > > At the moment there's not much we can do, before we have a

Re: [107528] trunk/dports/textproc/intltool/Portfile

On 2013-07-02 07:30, Jeremy Huddleston Sequoia wrote: >> I am not sure that we want to do this. > > Without doing this, it's nearly impossible to build ports if you have any > non-default perl selected. > > With this change, everything in my default set (which includes 2249 ports) > built with

Re: Switching to Perl 5.16

On 2013-07-01 18:30, Jeremy Huddleston Sequoia wrote: > So then is this the correct approach we should be taking: > > Index: Portfile > === > --- Portfile (revision 107485) > +++ Portfile (working copy) > @@ -2,9 +2,11 @@ > # $Id$

Re: Two different copies of MacPorts on the same system?

On 2013-07-01 07:12, Ryan Schmidt wrote: > > On Jul 1, 2013, at 00:06, Blair Zajac wrote: > >> Yes, definitely. We've had 3 different copies of MacPorts installed at the >> same time. >> >> I always set --prefix=$PREFIX --with-tclpackage=$PREFIX/lib/tcl/macports to >> ensure that each copy ins

Re: remove port package from MacPorts repository

On 2013-06-29 00:53, Ryan Schmidt wrote: > On Jun 28, 2013, at 10:57, Bradley Giesbrecht wrote: > >> Is there a recipe for removing, without replacing, a port package from the >> MacPorts repository? >> >> I see replacing here but there is no package to replace the package I want >> to remove: >

Re: Reinstalling Macports fails

On 2013-06-27 15:25, Vincent Habchi wrote: > /usr/bin/tclsh src/upgrade_sources_conf_default.tcl "/opt/local" > /usr/bin/tclsh src/images_to_archives.tcl "/opt/local/share/macports/Tcl" > dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10): Symbol > not found: ___strlcpy_chk > Ref

Re: port list confusion

On 2013-06-20 01:31, Ryan Schmidt wrote: > The `port list` command is confusing to many users: > https://trac.macports.org/wiki/FAQ#portlist > > I don't think I've ever used it myself to actually find out anything. > If I'm searching for a port, I use `port search`. And if I already > know what po

Re: modern Tcl and correct quoting

On 2013-06-13 00:18, Poor Yorick wrote: > Putting [expr] arguments in braces can result in much better performance as it > allows Tcl to cache a byte-coded version of the expression. It can also > avoid unintended processing that might occur via double substitution. Ref > http://wiki.tcl.tk/102

Re: modern Tcl and correct quoting

Hello, On 2013-06-12 08:05, Poor Yorick wrote: > macport.tcl appears to have originally been written prior to Tcl 8.5, which > was > released in 2007, and uses idioms that are now considered obsolete. There are > also instances where curly brackets are used in combination with variable > interpo

Re: problem with MacPorts under Mavericks/Xcode5

On 2013-06-12 09:06, Artemio González López wrote: > Thanks a lot for your help. I tried installing from trunk (with svn), > but in the configure phase I got the following error message: > > checking for Tcl configuration... configure: error: Can't find Tcl > configuration definitions I guess it'

Re: Certificate Authorities: curl-ca-bundle, certsync, keychain

Hey Landon, On 2013-05-14 03:39, Landon Fuller wrote: > Over the weekend I whipped up (and added a port for) 'certsync'; it's a small > tool that fetches all trusted certificates from the Mac OS X system keychain, > and then spits them out as OpenSSL-readable pem-encode certificate bundle. > >

Re: [104258] trunk/base/src/port1.0/portconfigure.tcl

On 2013-05-05 14:11, Andrea D'Amore wrote: > On Sun, May 5, 2013 at 11:53 AM, Ryan Schmidt wrote: >>> (I've been passing options to ld 134.9 on purpose to test this), >>> should we make that line >>>default configure.ldflags {"-L${prefix}/lib >>> -headerpad_max_install_names"} >>> instead?

Re: SoC Idea

Hello, On 2013-04-24 16:01, Justin Herald wrote: > I am thinking about submitting a proposal for SoC and wanted to run the > ideas by the mailing list. > > I thought it kind of made sense to roll the ideas for (a) interactive > mode, (b) package cleaning (reclaim disk space), and (c) shell > envi

Re: GSoC 2013: Binaries Idea

On 2013-04-15 14:09, Joshua Root wrote: > On 2013-4-14 14:37 , Marcelo Galvão Póvoa wrote: >> I think binary packages could benefit from some other useful perks such >> as: prior disk space requirement information and being able to query >> port contents such as in [1]. >> >> [1] https://wiki.archl

Re: sysctl ???

On 2013-04-17 12:31, vincent habchi wrote: >> There is no "standard Tcl ‘sysctl’ call". The sysctl proc you can call >> from portfiles is defined in src/macports1.0/sysctl.c. It's just a thin >> wrapper around sysctlbyname(3) to make it available from Tcl. Why is this wrapper in macports1.0 and no

Re: Accept to GSoC 2013

On 2013-04-09 16:36, Eric A. Borisch wrote: > Can we finally get some usage reporting (downloads from the packages > site, if nothing else) implemented so we know what ports are used > frequently/infrequently. This can help with pruning in the future (if a > package is broken, and no one is using i

Re: Accept to GSoC 2013

On 2013-04-08 21:16, Jeremy Lavergne wrote: > MacPorts has been accepted to GSoC 2013. > > Kudos to Clemens (cal), Rainer (raimue) and Lawrence (larryv) for their > continued assistance and leadership this year. > > We're looking for additional mentors and ideas to help make this a success > fo

Automatic lint reports (was: Re: [MacPorts] SummerOfCode modified)

Hello, On 2013-03-25 08:54, Ryan Schmidt wrote: > On Mar 24, 2013, at 07:07, Rainer Müller wrote: >> On 2013-03-22 01:29, MacPorts wrote: >>> Page "SummerOfCode" was changed by c...@macports.org >>> Diff URL: >>> <https://trac.macports.org/wiki/S

Re: [MacPorts] SummerOfCode modified

On 2013-03-22 01:29, MacPorts wrote: > Page "SummerOfCode" was changed by c...@macports.org > Diff URL: > > Revision 202 > Comment: Delete task that is 1. very easy to implement using a cronjob and a > script, 2. referencing a

Re: Feature request: "subscribing" to tickets of specific ports

On 2013-03-20 14:03, Mojca Miklavec wrote: > When someone submits a ticket, the maintainer gets CC-ed (if not by > submitter, by the first one who sees that ticket). That is fine, but > that excludes anyone else who might be interested in following > maintenance of that port. Automatically assigni

Re: blacklist all flavors of a GCC version

On 2013-03-20 14:30, Leo Singer wrote: > Are changes like this to port1.0/ reflected by 'sudo port selfupdate'? Changes to base/ first require a new release of MacPorts itself and then they will be available with a selfupdate. Also note that there are different branches. At the moment, trunk/base

Re: GSoC 2013: Call for Mentors

On 2013-03-20 07:29, Joshua Root wrote: > Note that "A disappearing mentor has not happened to us" is not actually > true; in 2008 I had to take over a student after the mentor disappeared > (temporarily), and the student ended up failing the midterm evaluation. > > I'm not sure if you want to ment

Re: GSoC 2013: Call for Mentors

On 2013-03-18 22:45, Jeremy Lavergne wrote: > I am going to submit an application on behalf of The MacPorts Project > for the Google Summer of Code (GSoC) program 2013. I think most of > you have already heard of it: Google pays students to work on various > Open Source projects over the summer. It

Re: Divorcing MacPorts from Xcode

On 2013-03-19 18:00, Jeremy Lavergne wrote: > We should probably revisit replacing a lot of our base logic that > depends on Xcode, or at least isolating it so we can operate without > Xcode and alert the user when it's actually needed. I not sure what you mean with this as I see two separate goal

Re: Neither curl / curl-ca-bundle ports include mk-ca-bundle.pl

On 2013-03-19 15:33, Ryan Schmidt wrote: > The curl port runs "make install". The curl developers didn't include the > mk-ca-bundle.pl script in the files that get installed when running "make > install" which is why it doesn't end up getting installed by the port. At least the man page and docs

Re: doxygen/gdbm license conflict

On 2013-03-16 07:06, Lawrence Velázquez wrote: > I'd like to mark perl5 as license_noconflict in doxygen, since its dependency > gdbm is blocking distribution of doxygen packages. I think perl is only used > for running some build scripts, but I'm not really sure. Can someone with a > clue take

Re: user manuals

On 2013-03-07 12:40, Ian Wadham wrote: > On 07/03/2013, at 7:03 PM, mk-macpo...@techno.ms wrote: >> On Mar 7, 2013, at 4:57 AM, Ian Wadham wrote: >>> I looked at the main.log for ticket 37620, but there is a lot of >>> concurrency and it is hard… >> Concurrency?! I wasn't aware of that, actually.

Re: Finding the machine CPU arch

Hello, On 2013-03-06 20:43, Vincent Habchi wrote: >> Couldn't we just select variants like +sse, +sse2, etc. based on the >> current architecture? > > I know you are fundamentally against auto-configuration. I see, however, a > few reasons why it is a good choice in case of Atlas: > > 1. From m

Re: Finding the machine CPU arch

On 2013-03-06 18:27, Ryan Schmidt wrote: >> The following command can be used to check which features with the >> matching command line flags will be selected by -march=native on the >> current hardware: >> gcc-mp-4.7 -Q --help=target -march=native > > The earliest time you can be guaranteed that

Re: Finding the machine CPU arch

On 2013-03-06 16:19, Ryan Schmidt wrote: > Atlas seems to be one of those performance-critical ports that could > benefit by being compiled for the user's specific processor instead > of using a pre-compiled binary that might have been build for a > slightly different processor. To that end, Vincen

Re: Proposal to introduce "port select ruby"

Hello, I appreciate this effort! On 2013-03-04 13:22, kimura wataru wrote: > - avoid conflicts between port:ruby and port:ruby19 > - add suffix "1.8" to commands of port:ruby. (bin/ruby1.8) As soon as this is merged we need to ensure that all ports use bin/ruby1.8 that were using bin/ruby be

Re: [103579] trunk/dports/devel/libftdi/Portfile

On 2013-03-01 23:21, s...@macports.org wrote: > Revision: 103579 > https://trac.macports.org/changeset/103579 > Author: s...@macports.org > Date: 2013-03-01 14:21:52 -0800 (Fri, 01 Mar 2013) > Log Message: > --- > libftdi: update to 1.0 > > Modified Paths: > --

Re: [103464] trunk/dports/math/atlas/Portfile

On 2013-02-27 08:53, Vincent Habchi wrote: > True, but there is no PPC buildbot AFAIK, and that’s the only case of > mono-processor Apple machines; even the first x86 machines were > CoreDuo based, if I’m not mistaken. We already have debated about > Atlas – personally, I think the best solution wo

Re: distfiles in URL in mirror_sites.tcl

Keeping discussions about changes to base in a separate thread: On 2013-02-24 13:13, Rainer Müller wrote: > Notwithstanding possible changes to base to accommodate such an URL in a > better way [...] A possible way to handle file names in the middle of an URL would be to introduce var

Re: distfiles in URL in mirror_sites.tcl

On 2013-02-23 15:19, Ryan Schmidt wrote: > Can I have ${distfiles} within a URL defined in a fetch group? > > I have been informed [1] by the PHP people that instead of downloading from > e.g.: > > http://us2.php.net/distributions/php-5.4.12.tar.bz2 > > they want us to download from: > > h

Re: [MacPorts] howto/bash-completion modified

On 2013-02-23 07:54, Lawrence Velázquez wrote: > On Feb 23, 2013, at 1:50 AM, MacPorts wrote: > >> Page "howto/bash-completion" was changed by c1653...@rmqkr.net >> Diff URL: >> >> Revision 8 >> Comment: Add /opt/local/

Re: [103165] trunk/dports/devel/fossil

On 2013-02-18 07:08, Ryan Schmidt wrote: > > On Feb 16, 2013, at 16:26, ciserl...@macports.org wrote: > >> Revision: 103165 >> https://trac.macports.org/changeset/103165 >> Author: ciserl...@macports.org >> Date: 2013-02-16 14:26:55 -0800 (Sat, 16 Feb 2013) >> Log Message: >> -

Re: Detect opportunistic linking and unnecessary dependencies

On 2013-02-16 05:51, Ryan Schmidt wrote: > It would be great if MacPorts would automatically detect dependency problems > when installing ports. > > > For example, if a port links with a library but does not declare a dependency > on it, I'd love to see a warning: > > Warning: /opt/local/bin/f

Re: RFC: Support for future compilers in base

On 2013-02-15 21:18, Sean Farley wrote: > > Rainer Müller writes: >> This change makes sense as the features supported by the gcc and clang >> compilers shipped in ports are almost homogenous at the moment; in the >> past there were differences as not all gcc4* shipped gfo

Re: RFC: Support for future compilers in base

On 2013-02-15 09:10, Jeremy Huddleston Sequoia wrote: > I'd like to update base trunk such that future versions of clang, dragonegg, > and gcc "just work", so we don't need to wait for newer versions of base to > depend on newer compilers. > > I've taken a first pass at portconfigure.tcl and her

Re: Is it worth persevering with Macports_Framework?

On 2013-02-14 06:40, Ian Wadham wrote: > The idea of putting markers in port(1) outpu is nice. If that became > necessary, > would patches for review be acceptable to Macports developers? Of course! The message classification currently happens through a handful of procs such as ui_error, ui_war

Re: Callback registration mechanism

On 2013-02-12 02:49, Clemens Lang wrote: > On Tue, Feb 12, 2013 at 12:28:08AM +0100, Rainer Müller wrote: >> I like the idea, but I also have some bad feelings with this. The >> callbacks are run after the Portfile is evaluated, so the end result >> cannot be influenced

Re: Duplicate py27-pyusb-devel

On 2013-02-12 17:27, William Siegrist wrote: > Rainer, I think your commit is at fault: > > https://trac.macports.org/changeset/103036 Oh, I missed that there was a py27-pyusb-devel, but no corresponding py27-pyusb. I deleted the non-unified version in r103042. Rainer ___

Re: Is it worth persevering with Macports_Framework?

On 2013-02-10 18:51, Kevin Walzer wrote: > On 2/10/13 1:39 AM, Ian Wadham wrote: >> Should I persevere with Macports_Framework? It's been a while since I >> worked with threads and concurrent processes and Apple's way of doing >> things, in Objective C, OS X and Xcode is all new to me. I enjoy a

Re: Is it worth persevering with Macports_Framework?

On 2013-02-12 05:29, Guido Soranzio wrote: > On 11/02/2013, Ian Wadham wrote: > >> I see that Cocoa has NSTask and NSPipe classes and that Guido's >> Guigna app is using them in its GuignaAgent class. I also like this approach >> because there is loose binding between the processes. > > A more c

Re: Is it worth persevering with Macports_Framework?

Hello Ian, thank you for your interest in MacPorts.framework. I will try to give some insight into the state of this framework and the MacPorts GUI, which will hopefully explain the state of the project. On 2013-02-10 10:59, Ian Wadham wrote: > > On 10/02/2013, at 8:11 PM, Ryan Schmidt wrote: >>

Callback registration mechanism (was: Re: [102932] trunk/base/src)

On 2013-02-11 03:01, c...@macports.org wrote: > Revision: 102932 > https://trac.macports.org/changeset/102932 > Author: c...@macports.org > Date: 2013-02-10 18:01:56 -0800 (Sun, 10 Feb 2013) > Log Message: > --- > Automatically add dependency on MacPorts-provided compilers,

Re: [102860] trunk/dports/graphics/tiff

On 2013-02-10 02:30, Ryan Schmidt wrote: > > On Feb 9, 2013, at 12:43, jerem...@macports.org wrote: > >> Revision: 102860 >> https://trac.macports.org/changeset/102860 >> Author: jerem...@macports.org >> Date: 2013-02-09 10:43:07 -0800 (Sat, 09 Feb 2013) >> Log Message: >>

Re: Removing port submit

On 2013-02-11 02:36, Joshua Root wrote: > On 2013-2-11 09:40 , Clemens Lang wrote: >> Hi, >> >> while I was writing a patch for #32542 [1] I noticed that base could >> benefit from some refactoring. As a first measure, I'm proposing the >> removal of port submit. Since I assume not everybody on the

Re: OpenSSL update breaks SSH

On 2013-02-09 01:59, Clemens Lang wrote: > On Sat, Feb 09, 2013 at 01:48:53AM +0100, Clemens Lang wrote: >> just a quick warning that the update of openssl to 1.0.1d breaks >> MacPorts OpenSSH in the sense that connecting to other machines using >> the ssh client is no longer possible. Rebuilding o

Re: Anything else for 2.1.3?

On 2013-01-28 18:20, Sean Farley wrote: > On Mon, Jan 28, 2013 at 2:39 AM, Joshua Root wrote: >> As per the milestone due date, I'm thinking we should do the release at >> the end of the month. If there anything else we really need to merge to >> the branch? Eligible changes at this point should b

Re: gcc and xgetbv

On 2013-01-25 17:20, Vincent Habchi wrote: > On 25 janv. 2013, at 16:30, Rainer Müller wrote: > >> This will still become a problem if we are going to distribute this >> software as a pre-compiled binary, as the machine running the buildbot >> might have support for AV

Re: gcc and xgetbv

On 2013-01-25 16:13, Michael Dickens wrote: > Hi Vincent - Thanks for your reply; it seems like that thread from a > while back said pretty much what you're now saying. So, what I'm trying > to do is create a configure-time test which first tries to compile a > "xgetbv" instruction, and if that su

Re: gcc and xgetbv

On 2013-01-25 14:15, vincent habchi wrote: > > On 25 janv. 2013, at 04:02, Michael Dickens wrote: > >> but, this code does not compile using MacPorts' gcc 4.7; it errors out >> with "no such instruction: `xgetbv'". Apple's clang compiles this code >> without the #if, but it errors out when runni

Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl

On 2013-01-24 16:29, Michael Dickens wrote: > On Jan 24, 2013, at 9:46 AM, Rainer Müller wrote: >> It's probably not a problem for most users with a recent enough terminal >> emulator that supports UTF-8. Actually one would have to check by locale >> environment

Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl

On 2013-01-24 15:14, Ryan Schmidt wrote: > Sorry to hear smart quotes don't work with your xterm; this is the > first I've heard of such a problem. I don't know why that would be. > They work fine in my OS X Terminal.app on Mountain Lion. > > I've been switching to smart quotes in many ports alrea

Re: Skipping *nix hidden folders while indexing

On 2013-01-23 01:30, Andrea D'Amore wrote: > I sometime disable a port in tree and reindex, the natural way to do > it is to prepend a dot to the portdir name. Is there anything against > the following? > > Index: src/macports1.0/macports.tcl > =

Re: PortGroup perl5 dependencies for non-module ports

On 2013-01-10 15:23, Rainer Müller wrote: > Some other ports using the perl5 port group outside of perl/p5-* suffer > from the same problem: > > $ port -q installed perl5 > perl5 @5.12.4_0+perl5_16 (active) > $ port -q info --depends_lib ikiwiki > port:perl5.16, port:

Re: [101775] trunk/dports/lang/ruby19/Portfile

On 2013-01-20 10:15, kimura wataru wrote: > This configure error occurs only when universal binary specified > (passing multiple archs for --with-archs optition to `configure`). > There is no problem for building single arch ruby. However, as autoconf is only required at build time, it should be l

Re: Double port: scapy

On 2013-01-16 16:52, Aljaž Srebrnič wrote: > On 16/gen/2013, at 16:48, Rainer Müller wrote: >> I don't know simpy, but it does not look like there is any tool in this >> port – at least no files ends up at bin/*. The included SimGUI.py seems >> to be a basic example onl

Re: Portfile Workflow Advice

Hello, On 2013-01-14 09:18, rod wrote: > I've been finding developing and especially updating Portfiles a bit > tricky and error prone, so have been writing some tools for myself to > help with this... > > https://github.com/rodnaph/pearl > https://github.com/rodnaph/ghsum > > But while submitti

Re: Double port: scapy

On 2013-01-16 16:20, Aljaž Srebrnič wrote: > Hello list, > I just noticed that we have two ports for scapy, one named scapy and the > other named py26-scapy. Should we: > - create a unified portfile named py-scapy > - delete py26-scapy > - mark scapy replaced_by py27-scapy (since scapy is based on

Re: International Ticket-closing day

On 2013-01-15 10:32, Ryan Schmidt wrote: > > On Jan 15, 2013, at 03:14, Aljaž Srebrnič wrote: > >> I was poking around on Trac tying to find an excuse for not studying and >> found out that there are 1091 tickets open but older than a year[1]. So, >> what about choosing a date and have a big me

Re: International Ticket-closing day

On 2013-01-15 21:16, Lawrence Velázquez wrote: > On Jan 15, 2013, at 2:33 PM, Aljaž Srebrnič wrote: > >> Oh, that, too :) I'll try to close some old ones when I have some time then! > > Great idea! How about starting with this one? > > https://trac.macports.org/ticket/126 Actually, I don't thi

Re: filetype in modeline

On 2013-01-14 16:07, Clemens Lang wrote: > On Mon, Jan 14, 2013 at 09:33:34AM -0500, Jeremy Lavergne wrote: >>> Another way to make sure Portfiles have filetype set to Portfile despite >>> the modeline is adding the following line to your .vimrc: >>>au BufNewFile,BufRead,BufWinEnter Portfile se

Re: [101504] trunk/base/src/port1.0/portextract.tcl

On 2013-01-14 09:20, Sean Farley wrote: > $ /usr/bin/find . -mindepth 1 -maxdepth 1 ! -perm -01000 -exec cp -R {} /tmp > \; > > I think all we really need to do in cases like these are ignore files > / directories that have the sticky bit set. The problem is not the sticky bit, but the missing r

filetype in modeline (was: Re: [101588] trunk/dports/devel/pcre/Portfile)

On 2013-01-14 13:20, Aljaž Srebrnič wrote: > But I like mpvim! :( I agree, I also prefer mpvim for editing Portfiles. Specifying filetype=tcl in the modeline overrides the syntax and compiler settings provides by mpvim [1] and falls back to plain Tcl syntax highlighting, which does not recognize o

Re: PortGroup perl5 dependencies for non-module ports

On 2013-01-10 16:21, Michael Schout wrote: > On 1/10/13 8:23 AM, Rainer Müller wrote: > >> I tried to use the perl5 port group to create a port for an application, >> not a module. The port group insists on using the version of perl >> extracted from the currently inst

PortGroup perl5 dependencies for non-module ports

Hello, I tried to use the perl5 port group to create a port for an application, not a module. The port group insists on using the version of perl extracted from the currently installed ${prefix}/bin/perl. Actually this is the renaming of p5-app-ack, #37595 [1]. nameack perl5.b

Re: Where to include port version in 'port pkg' output?

On 2013-01-05 23:04, Blair Zajac wrote: > On 01/05/2013 01:32 PM, Rainer Müller wrote: >> I guess munki uses the version number from in the metadata of the pkg >> and not from the filename, so we could avoid putting epoch 0 in the >> filename (to keep them short), but sti

Re: Where to include port version in 'port pkg' output?

On 2013-01-05 19:18, Blair Zajac wrote: >> That would cause problems if the epoch for a package is ever increased >> from 0 to 1, since the version number would change unpredictably. >> >> e.g. say you have a package with version 3.2.1 epoch 0, revision 0, so >> if you missed out the epoch when zer

New committers: larryv and sean

Please join us in welcoming the following new MacPorts committers: - Larry Velásquez (larryv) - Sean Farley (sean) We look forward to continued excellent contributions from these new team members. - Joshua, Rainer, and Ryan Do you want to join the MacPorts team? If you would like to be consi

Re: Where to include port version in 'port pkg' output?

On 2013-01-04 00:49, Blair Zajac wrote: >> Also, should we put the epoch number into the generated pkg and mpkg >> filenames? I'm going to add it to the version number: >> >> ${epoch}.${portversion}.${portrevision} > > I decided to drop the epoch number since Apple docs suggest there's only > thr

Checksum in statefile (was: Re: [101027] trunk/dports/graphics/libwmf/files/configure.ac.diff)

On 2013-01-03 09:45, Ryan Schmidt wrote: > When you make a change to a patchfile that will fix a build problem, you > should simultaneously make some change to the Portfile as well (any change: > could just be a whitespace change) so that any users who had a failed > configuration attempt becaus

Re: automake-1.13 (and 1.14 planning)

On 2013-01-03 19:20, Jeremy Huddleston Sequoia wrote: > There seem to be more ports than I realized failing due to automake-1.13. If > you encounter build failure in a port due to automake-1.13, give this > post-patch block a try: > > post-patch { > reinplace {s:AM_CONFIG_HEADER(\(.*\))

Re: Buildbot error

On 2012-12-26 21:16, Vincent Habchi wrote: > ok I reverted back. Something appears to be messy in my tree: > > -> svn info py32-pyobjc > Path: py32-pyobjc > URL: > https://svn.macports.org/repository/macports/trunk/dports/python/py27-pyobjc > Repository Root: https://svn.macports.org/repository/m

Re: [MacPorts] Tickets modified

On 2012-12-23 03:55, Ryan Schmidt wrote: >> I just read through the documentation for Trac again and found the >> solution just now. It's not a real but, but special quoting needs to be >> applied according to the rules for TracLinks (I was only looking at the >> TracQuery documentation yesterday).

Re: [MacPorts] Tickets modified

On 2012-12-21 04:08, Ryan Schmidt wrote: > > On Dec 20, 2012, at 09:26, MacPorts wrote: > >> +NOTE: There is a bug in Trac that does not pass the '+' sign properly to >> the query, use a link here instead of `query:` syntax. > > "+" is a special character in the query portion of URLs and is us

Re: [100611] trunk/dports/net/youtube-dl/Portfile

On 2012-12-18 13:38, Andrea D'Amore wrote: > me@biboop ~> youtube-dl > Hi! We changed distribution method and now youtube-dl needs to update > itself one more time. > This will only happen once. Simply press enter to go on. Sorry for the > trouble! > The new location of the binaries is > https://g

Re: [100449] users/raimue/ports/sysutils/collectd

On 2012-12-12 21:07, Ryan Schmidt wrote: > On Dec 12, 2012, at 12:01, Rainer Müller wrote: > >>> Something wrong... deleting and then appending the same dependency? >> >> Hm, right. This is the code that was originally written by Clemens, so >> probably he can cl

Re: [100449] users/raimue/ports/sysutils/collectd

On 2012-12-12 18:25, Ryan Schmidt wrote: >> Modified: users/raimue/ports/sysutils/collectd/Portfile >> === >> --- users/raimue/ports/sysutils/collectd/Portfile2012-12-12 16:57:53 UTC >> (rev 100448) >> +++ users/raimue/ports/sysut

Re: [100423] trunk/base/src/port

On 2012-12-11 20:44, Ryan Schmidt wrote: > > On Dec 11, 2012, at 11:35, rai...@macports.org wrote: > >> Revision: 100423 >> https://trac.macports.org/changeset/100423 >> Author: rai...@macports.org >> Date: 2012-12-11 09:35:51 -0800 (Tue, 11 Dec 2012) >> Log Message: >> ---

Re: python24-26 policy

On 2012-12-09 05:12, Ryan Schmidt wrote: > On Dec 8, 2012, at 17:53, Joshua Root wrote: >> With the unified portgroup there's almost no extra effort involved >> in having them. I don't think there's any reason to drop them >> until upstream does. > > Users unfamiliar with the intricacies of the py

Re: [100350] trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl

On 2012-12-09 04:54, Ryan Schmidt wrote: >> Modified Paths: >> -- >>trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl > >> # http://trac.macports.org/ticket/29104 >> -if {${configure.compiler} == "llvm-gcc-4.2"} { >> -configure.compiler clang >> +

Re: Blacklisting compiler versions or build numbers

On 2012-12-09 05:05, Ryan Schmidt wrote: > If clang >= 421 fails to build the port, then the blacklist entry > should not be removed unless the source gets modified to work around > the clang bug. Agreed, but how do you know it's really any later version after 421 when adding the blacklist entry?

Re: Blacklisting compiler versions or build numbers

On 2012-11-25 17:48, Jeremy Huddleston Sequoia wrote: > # All clang versions blacklisted > compiler.blacklist-append clang > > # clang < 308 blacklisted: > compiler.blacklist-append {clang < 308} > > # clang >= 421.11.66 and < 444 blacklisted > compiler.blacklist-append {clang >= 421.11.16 < 444}

Dependencies on kerberos5

Hello, Cc: maintainers of depends:kerberos5 At the moment, several ports depend directly on kerberos5 in their default variant set. Most important for me are cyrus-sasl2 and openssh. As I want to use kerberos authentication against servers, I currently have to maintain two independent sets of ke

Re: Blacklisting compiler versions or build numbers

On 2012-12-05 22:09, Ryan Schmidt wrote: > I find that tabular format easier to read than what we currently have. A table works if we only present the version number. However, I would prefer to save the whole version information string in case we need to improve our regular expressions for matchin

Re: Blacklisting compiler versions or build numbers

On 2012-11-27 11:51, Ryan Schmidt wrote: > I've created the compiler_blacklist_versions 1.0 portgroup in r100083. It > works in my limited testing. Please try it and let me know what you think. In order to use this PortGroup, we need information in which version of Xcode a specific compiler versi

New committers: andy and mojca

Please join us in welcoming the following new MacPorts committers: - Andy Kitchen (andy) - Mojca Miklavec (mojca) We look forward to continued excellent contributions from these new team members. - Joshua, Rainer, and Ryan Do you want to join the MacPorts team? If you would like to be consid

Re: subportof pseudoport

On 2012-11-24 06:40, Ryan Schmidt wrote: > It feels like there should be a "subportof" pseudoport, but there doesn't > seem to be: > > > $ port echo subportof:graphviz > Can't map the URL 'subportof:graphviz' to a port description file ("Can't > parse url subportof:graphviz"). > Please verify t

Standalone Darwin (was: Re: 100,000th commit)

On 2012-11-24 10:00, vincent habchi wrote: > BTW, and totally unrelated: by chance, would you know someone more or > less versed in getting a xnu environment running? I’m looking to > upgrade my G5 server to Snow Leopard, which happens to be available > for PPC, but only I am not sure what you are

Re: qt4-mac and qt4-x11

On 2012-11-23 17:08, Michael Dickens wrote: > I dream of some day having a +x11 variant to qt4-mac, but I doubt it > will be fully ABI compatible with the +quartz variant. So, it might > make sense to keep a qt4-x11 version which is not compatible with the > qt4-mac version at least for now. I wi

qt4-mac and qt4-x11

Hello Michael, I just noticed that qt4-x11 is no longer maintained and is already a few versions behind of qt4-mac: qt4-mac @4.8.3_1 qt4-x11 @4.4.3_9 Are there plans to support qt4-x11 longer? Some ports still depend on qt4-x11 in some variants, however, no port depends on qt4-x11 in the def

<    1   2   3   4   5   6   7   8   9   10   >