On Mon, Oct 31, 2016 at 07:03:24PM -0500, Ryan Schmidt wrote:
> On Oct 31, 2016, at 17:17, Dan Ports <dpo...@macports.org> wrote:
> >
> > Any reason not to just bulk-remove them all at once?
>
> That would probably tie up the buildbot for weeks or months. We c
Any reason not to just bulk-remove them all at once?
Dan
On Mon, Oct 31, 2016 at 05:30:07PM -0400, Lawrence Velázquez wrote:
> Hi,
>
> We no longer have use for "$Id" lines, so committers should remove them at
> their convenience.
>
> vq
>
> > On Oct 31, 2016, at 5:20 PM, Schamschula
> >
On Mon, Sep 26, 2016 at 07:23:38PM +1000, Joshua Root wrote:
> I really don't see a problem with using patch_sites for any patches that are
> available for download somewhere stable. In fact it's even slightly
> preferable because it avoids the extra work of adding the file and adding a
> comment
On Mon, May 11, 2015 at 06:36:06PM -0500, Ryan Schmidt wrote:
Modified: trunk/dports/sysutils/synergy/Portfile (136191 = 136192)
+set major [lindex [split ${macosx_version} .] 0]
+set minor [lindex [split ${macosx_version} .] 1]
+configure.args -G \Unix
I haven't upgraded to Yosemite myself yet, but I'm hearing that in
10.10 the system refuses to load any unsigned kernel modules by
default. Worse, the only option for working around it appears to be
turning off signature checks entirely.
This is obviously a problem for ports that build kexts,
On Wed, Aug 13, 2014 at 09:00:09AM +0200, Mojca Miklavec wrote:
On Tue, Aug 12, 2014 at 11:25 PM, Dan Ports wrote:
Longer-term, we need to decide whether to go to a single perl.
Personally, I'm in favor of this. But it's clearly going to involve a
lot of work (even if it'll save us more
On Tue, Aug 12, 2014 at 08:19:27AM -0700, David Evans wrote:
As Daniel has said, no point in changing things that are going to go away so
we need to get a consensus on where we want to go with this. My input here
would be this:
* make the necessary changes to perl5.18 to work as perl5.20
On Mon, Aug 11, 2014 at 02:16:35PM -0700, David Evans wrote:
Thanks, Frank. Fixed in r123644
https://trac.macports.org/changeset/123644. I've seen it both ways so
if someone has a bent for detail work, I'm sure there are a few others
that could be fixed.
The stub ports always ought to be
On Fri, Nov 01, 2013 at 03:21:36PM -0400, Eric Gallager wrote:
Really? That's strange, I could've sworn I was able to use the qmake
portgroup in my local PortFile repository successfully when I was testing
it...
I believe portfiles will use portgroups from their own repository, so
portgroups
On Fri, Oct 25, 2013 at 06:23:02PM +, John Owens wrote:
To enable MacTeX within macports, I set binpath in macports.conf
to /usr/texbin:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:
/usr/sbin (so prepend /usr/texbin to the default). That's historically
worked well. (Is that in fact
This seems like yet another instance of the current perl situation
making it harder to maintain other ports.
Are we really getting enough benefit out of supporting multiple perl
versions to make this worthwhile?
Dan
--
Dan R. K. PortsUW CSEhttp://drkp.net/
The perl5 - gdbm dependency introduces a lot of license conflicts (as
does the python - openssl dependency).
A while back we talked about removing gdbm from the standard perl5.x
installation and moving it to a separate port. I get the impression
that this module isn't widely used and wouldn't
Looks like devans already did this in r100850.
Dan
--
Dan R. K. PortsUW CSEhttp://drkp.net/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
On Fri, Oct 05, 2012 at 08:37:02AM +1000, Joshua Root wrote:
On 2012-10-5 08:18 , Ryan Schmidt wrote:
But at that point, does anything speak against just making pango/cairo/gtk2
always install both quartz and x11 parts and just get rid of the variants?
Is that even possible?
I
On Wed, Sep 26, 2012 at 09:11:24PM -0400, Matt Cottrell wrote:
Would a committer please look at https://trac.macports.org/ticket/36271 and
commit my maintainer patches or suggest revisions. I would like to close
this ticket and move on.
Done in r98170. Thanks for the patch!
Dan
--
Dan
On Mon, Sep 17, 2012 at 05:41:10PM +0200, Clemens Lang wrote:
MPAB (the software running the buildbots) needs to be adapted to
activate all dependent ports one-by-one and run rev-upgrade to detect
this kind of problems.
Could we use a modified rev-upgrade to track the library dependencies
of
On Tue, Sep 18, 2012 at 12:45:40AM +0200, Clemens Lang wrote:
We are in control of that, so it's entirely our decision whether a
revbump is our only way to ensure users rebuild.
I think the way I'd prefer to handle this would be to have the buildbot
produce a list of ports that need to be
On Tue, Sep 18, 2012 at 12:58:50AM +0200, Clemens Lang wrote:
Yes, we could copy the information in the binary header into a database
and run the testing there, marking packages as broken if a package that
has been rebuilt no longer satisfies a dependency.
Oh... actually, I'd kinda figured
On Thu, Sep 13, 2012 at 10:39:14PM -0700, Jeremy Huddleston Sequoia wrote:
The problem seems to be that some of MacPorts' gcc compilers have been built
with --enable-fully-dynamic-string and others haven't. gcc44 and gcc45 are
built with --enable-fully-dynamic-string and gcc46, gcc47, and
On Fri, Sep 14, 2012 at 12:45:38AM -0700, Jeremy Huddleston Sequoia wrote:
Yep, so we're going to need to revbump those ports.
Yeah, but I wasn't worried about that so much... it's more that if
someone installed the gcc45 port and used it to compile something
outside of MacPorts, the resulting
On Tue, Sep 11, 2012 at 01:37:08PM -0700, Dan Ports wrote:
I haven't run into that, but what I'm seeing is that my octave that was
linked against gcc45's libstdc++ now fails at runtime:
octave(24531) malloc: *** error for object 0x7fff76cc2860: pointer being
freed was not allocated
On Tue, Sep 11, 2012 at 03:32:04PM -0400, Michael Dickens wrote:
I've already had folks writing me that octave (via octave-devel) is now
broken during build, because the linked libstdc++ does not contain
certain symbols. I cannot fix this issue since it requires the correct
libstdc++ for the
On Mon, Sep 10, 2012 at 02:44:16PM -0700, jerem...@macports.org wrote:
Revision: 97657
https://trac.macports.org/changeset/97657
Author: jerem...@macports.org
Date: 2012-09-10 14:44:14 -0700 (Mon, 10 Sep 2012)
Log Message:
---
gcc*: Don't install the C++ runtime
On Mon, Aug 20, 2012 at 05:16:43AM +, John Owens wrote:
The only thing I need to build is a pdftex binary. What should I change
depends_build to be?
I don't think this is true -- it seems to need the EC fonts (from
texlive-latex-recommended) and the fullpage package (from
On Mon, Aug 20, 2012 at 04:53:30AM +, John Owens wrote:
depends_buildport:ocaml port:hevea port:texlive-latex-extra
port:texlive-latex-recommended
which I propose to change to bin:latex:texlive-latex-recommended.
This isn't quite right. The latex binary is
While working on a port that installs Python bindings, I was surprised
to discover that $prefix/lib/python2.7/site-packages wasn't in
python27's package search path. (The correct path, apparently, is
$frameworks_dir/Python/Versions/2.7/lib/site-packages.)
I was surprised by this because, in
On Wed, Jun 27, 2012 at 10:44:51AM +0300, Reuben Cummings wrote:
Do you know how I can get the gnucash port to build the
bindings?
I'll look into adding support for this to the port.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
On Wed, Jun 27, 2012 at 04:04:35AM -0500, Ryan Schmidt wrote:
You would need to increase the port's revision so that it gets rebuilt
following this change.
No, the port previously failed to build.
However, the problem with this change is that it makes all the subports
conflict with one
On Wed, May 02, 2012 at 01:06:08PM +1000, Joshua Root wrote:
Isn't this just another name for the same license?
http://llvm.org/docs/DeveloperPolicy.html#license links to
http://www.opensource.org/licenses/UoI-NCSA.php, which lists the SPDX
short identifier NCSA.
Yeah, we had this license
On Mon, Apr 30, 2012 at 07:52:20PM +0200, Mojca Miklavec wrote:
make install prefix=/path/to/that/weird/macports/destroot
(which is what macports does for gnuplot) is the wrong way of
installing and that one should use
make install DESTDIR=/path/to/that/weird/macports/destroot
Yeah,
What's happening here is that the pymol port, like most Python modules
using setuptools/distribute (as well as most perl modules, etc) builds
using the same compiler that was used to build Python, not the one
specified by configure.compiler.
This sounds like a pretty serious problem now that we
On Thu, Mar 29, 2012 at 12:50:59PM -0700, Jeremy Huddleston wrote:
@@ -38,7 +38,11 @@
port:freetype \
port:libpng \
port:zlib \
-port:expat
+
On Mon, Mar 19, 2012 at 06:47:28PM +1100, Joshua Root wrote:
Sort of. It checks if an archive is available locally (which includes
ports that are installed but inactive). This dates from before the
buildbot, and I'm planning to add a check for a remote archive.
Great, the combination of that
On Sun, Mar 18, 2012 at 04:38:38AM -0500, Ryan Schmidt wrote:
You should depend on the specific subport of p5-www-mechanize that will be
used, not on the stub port.
Thanks. Apparently I am a bit sleepy myself. Fixed in r90919.
Dan
--
Dan R. K. Ports MIT CSAIL
On Sun, Mar 18, 2012 at 07:00:13PM +0100, Freek Dijkstra wrote:
One of the reasons I see people moving away to package managers like
Homebrew is that they don't like the many dependencies that come with
MacPorts.
I agree that this is a problem. Many people have complained about this,
and it's
On Fri, Mar 16, 2012 at 12:37:46AM -0500, Ryan Schmidt wrote:
In what way are we still on python 2.4? Ports that use python should offer
variants, and should default to 2.7.
My take is that the py24-* ports are typically just hanging around not
being used but not usually not hurting anything
On Thu, Mar 08, 2012 at 08:46:33AM +0100, Michael Klein wrote:
Can someone please commit the sane-backends patch and close #29207?
Committed in r90549 -- sorry this one fell through the cracks.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
On Wed, Mar 07, 2012 at 10:15:26PM -0500, Jeremy Lavergne wrote:
Does the python 1.0 PortGroup need some more love, or is this specific to
py-tornado?
It's happening because this port sets python.default_version before
python.versions rather than after. That seems to be a pretty reasonable
On Wed, Mar 07, 2012 at 08:03:14PM -0800, Dan Ports wrote:
It's happening because this port sets python.default_version before
python.versions rather than after. That seems to be a pretty reasonable
thing to do (and some 35 other ports do the same thing) so i'd call it
a bug in the portgroup
On Sat, Feb 25, 2012 at 10:54:32AM -0500, Eric Cronin wrote:
This is probably an issue with a ton of our perl ports that install things in
bin since before subports and the updated perl5 port that was the correct
hashbang line:
Yes, I noted this issue in
On Thu, Mar 01, 2012 at 04:05:22PM -0800, Art McGee wrote:
Not sure if this is an approriate question for this list or -users,
but does anyone know how the texlive metaport with the default +medium
variant compares to the BasicTex package, which is a subset of the
full Tex Live:
As I
On Tue, Feb 28, 2012 at 11:26:48PM +0100, Benoit T wrote:
Why again is it that one may have to symlink
/Applications/Xcode.app/Contents/Developer to /Developer ?
You shouldn't ever have to do this.
I had to do that in order to build py27-tkinter, a trivial package that
does not have the
On Wed, Feb 22, 2012 at 09:17:30PM +1100, Joshua Root wrote:
Yeah, it turns out xcodebuild doesn't care about $HOME and just asks
DirectoryServices or something. So in fact there's no point copying the
plist at all unless we're root, and no point putting it in the per-port
home dirs.
Yeah,
On Mon, Feb 20, 2012 at 11:04:19PM -0800, Dan Ports wrote:
Right now, what I'm worried about are the kind of errors we'll get if
Xcode is not properly installed/configured. There are a couple
non-obvious steps you have to take and the results can be surprising:
I added some additional warnings
On Tue, Feb 21, 2012 at 05:48:44PM +1100, Joshua Root wrote:
It seems that the subversion port doesn't know about the Apple-supplied
root certs, and it's really inconvenient to put a config file in
/opt/local/var/macports/home. /usr/bin/svn might do better.
/usr/bin/svn is going to be svn 1.6
On Wed, Feb 22, 2012 at 02:39:42AM +1100, Joshua Root wrote:
And why did Dan set the ownership in the first place? I can see that
making sense in the per-port dirs but not really in the global one.
Without it, the plist had 0600 permissions and it was owned by root, so
xcodebuild couldn't
On Mon, Feb 20, 2012 at 05:48:55PM +1100, Joshua Root wrote:
On 2012-2-20 11:14 , jberry at macports.org wrote:
Use xcrun -find to find xcode compiler if it's not found in /usr/bin.
I deliberately didn't merge these, and the changes in r90031, in order
to minimise the changes made on the
On Mon, Feb 20, 2012 at 08:49:24PM +1100, Joshua Root wrote:
On 2012-2-20 19:32 , Dan Ports wrote:
Does that mean we'll have to require people to have both Xcode and the
command-line tools package installed?
Yes, that seems the best way to avoid future problems if the compiler
paths
On Fri, Feb 17, 2012 at 10:32:48AM -0800, James Berry wrote:
(2) If developer_dir is not set, or is not correct, do the following,
in order
(a) Use any valid value from: xcode-select -print-path (the
user has chosen an Xcode, or Xcode's default is correct)
[...]
On Mon, Feb 20, 2012 at 07:41:00AM -0800, James Berry wrote:
Any more information you can give about the failure mode would be
appreciated. According to my testing, xcode-select -print-path can be safely
run even if you've never agreed to the Xcode agreement, so I don't think
that's what
On Tue, Feb 21, 2012 at 05:14:36PM +1100, Joshua Root wrote:
Seems to work OK in my basic testing. The sooner we catch any problems
and get a release out, the better.
I have been testing this and think we're close to ready for release.
I haven't had any problems with it once correctly set up.
On Fri, Feb 17, 2012 at 08:15:43AM -0500, Eric Cronin wrote:
audiofile would not update correctly until I rebuilt libtool, at which point
it did. I don't know if audiofile or libtool is to blame there, but libtool
was where it was learning /Developer from?
Well, in the case of audiofile, it
On Sun, Feb 19, 2012 at 04:45:44PM -0500, Daniel J. Luke wrote:
It's somewhat debatable that 'fixing' this by having the modules build with
configure.compiler is really the right thing here (there is a reason why
upstream tries to make both perl and its modules build with the same
Another difference in Xcode 4.3 that I haven't seen mentioned yet: it
doesn't install autoconf, automake, (g)libtool, and friends. I'm
assuming that this mostly isn't going to be a problem, since
use_autoconf will pull in the right dependencies, but I thought I'd
mention it for completeness.
I
On Sat, Feb 18, 2012 at 08:32:40AM -0800, James Berry wrote:
- The record of whether you've agree to the license is stored per-user
in ~/Library/Preferences/com.apple.dt.Xcode.plist:
[...]
Maybe we need to create a macports user home at something like
/opt/local/users/macports, with
On Fri, Feb 17, 2012 at 05:51:30PM +1100, Joshua Root wrote:
No. This is exactly as big a change as Xcode 4.1 - 4.2, which also
changed the default compiler path.
Well, it's a bit different in that the previous compiler path is no
longer even valid. That didn't happen with the 4.2 upgrade.
I'm
On Sun, Feb 19, 2012 at 02:42:38PM +1100, Joshua Root wrote:
Remember the location of the invoking user's home dir by saving $HOME
when we start up. Set HOME at the macports level to
${prefix}/var/macports/home. Copy or link the Xcode plist from the
user's home into
On Fri, Feb 17, 2012 at 01:15:35PM -0800, Blair Zajac wrote:
Looks like the filename list has a typo in it with mercerial instead of
mercurial.
It's possible that's just random corruption, since that's a single-bit
error...
Dan
--
Dan R. K. Ports MIT CSAIL
On Fri, Feb 17, 2012 at 12:58:56PM -0800, James Berry wrote:
On Feb 17, 2012, at 12:41 PM, Daniel J. Luke wrote:
I had 4.2 installed, downloaded 4.3 from the app store, ran new Xcode
(4.3), told it to uninstall 4.2 (/Developer and the installer from
/Applications), had it install the
On Fri, Feb 17, 2012 at 02:53:13PM -0800, James Berry wrote:
- Was Xcode 4.3 installed at that point?
- Had Xcode been run after the install? (In other words, had you agreed to
the license?)
Yes, I had installed Xcode 4.3, launched it, accepted its offer to
remove the 4.2 installation,
On Fri, Feb 17, 2012 at 03:05:51PM -0800, James Berry wrote:
It would be interesting to know what xcode-select -print-path returns at this
point.
Sure would. Unfortunately, I changed the path before I thought to try
that. (Things do seem to be working now that I've done that, BTW.)
Yes, I
On Fri, Feb 17, 2012 at 02:45:23PM -0800, James Berry wrote:
(1) Do these tools exist on a machine if Xcode has never been
installed? (i.e., are they part of the core os?)
Yes -- it looks like they are installed by the 10.7.3 update.
Dan
--
Dan R. K. Ports MIT CSAIL
On Wed, Feb 15, 2012 at 09:21:12PM +, Eric Hall wrote:
There are valid reasons to have multiple versions of perl
installed at the same time - the least of which is testing new
versions to make sure they work while still being able to build
and run things against older versions.
I
Although we nominally support having multiple versions of perl
installed, it seems we actually don't do a very good job of it...
A couple weeks ago, I mentioned two problems that will cause multiple
versions of the same module (e.g. p5.12-foo and p5.14-foo) to conflict:
- they install manpages
I see that quite a few ports call adduser and addgroup in the destroot
phase. Isn't this going to fail if we're installing from a binary (and
skip destroot)?
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
___
We've had a few duplicate ports recently, usually as part of unifying
Python ports. That's easily fixable -- but, to my surprise, it isn't
enough just to remove one of the offending ports. We also need to make
some change to the remaining port (say, a whitespace change) to force
portindex to
On Sun, Jan 29, 2012 at 12:28:04PM -0600, Ryan Schmidt wrote:
I'm still really not comfortable with this strategy. Any user selecting a
variant should get the same result; it should not matter what existing
versions of other ports they have installed.
In particular, this will probably not
On Mon, Jan 23, 2012 at 01:52:53PM -0800, Bradley Giesbrecht wrote:
Might it be advantageous to use a PortGroup for this?
Isn't this covered by compiler.blacklist in trunk (r88676)? I suppose
except for the fact that it doesn't automatically add a dependency on
any necessary gcc port.
We're
On Sun, Jan 22, 2012 at 01:03:34AM +0100, Andrea D'Amore wrote:
I moved a few python port to python-1.0 portgroup, and for them I got
a lint report saying py24- dependency was unknown. I remember
stumbling into this and I figure this is due to portindex not indexing
the default port at the
On Mon, Jan 16, 2012 at 05:36:26PM -0800, Dan Ports wrote:
Just about every perl port runs into this one. We probably want to have
them either install manpages into separate directories or include a
version in the name. (I think the former is better if we can get the
manpath set up correctly
On Wed, Jan 18, 2012 at 06:43:11PM -0600, Ryan Schmidt wrote:
Since there used to exist a py-paver port based on python24, you should not
set python.default_version 27; you should leave python.default_version at its
default value of 24.
Maybe it's time for us to consider dropping support for
On Mon, Jan 16, 2012 at 07:35:10PM +, Eric Hall wrote:
I think it's high (well past, very much so, etc.) time
to move perl5 to perl5.14. If anyone has a reason *not* to
do so, please let me know by the end of this week (20Jan2012).
I certainly don't object to the idea, but I'm
On Mon, Jan 16, 2012 at 06:48:36PM -0600, Ryan Schmidt wrote:
On Jan 16, 2012, at 17:42, Dan Ports wrote:
If so, we're in
trouble, because most p5.12-* ports conflict with their p5.14-*
counterparts.
They should not conflict. That's the whole reason they're subports. Which
ones
On Fri, Jan 13, 2012 at 07:30:12PM -0600, Ryan Schmidt wrote:
It seems to me that livecheck should be disabled in subports. I use port
livecheck maintainer:ryandesign to check all my ports for updates, and I
imagine other maintainers do similarly, and it is of no benefit to check the
same
On Wed, Dec 28, 2011 at 10:46:50AM +, Chris Jones wrote:
Has anyone consider moving to osxfuse, instead of fuse4x ? It also was born
out of the death of macfuse, but shares a lot of code with MacFuse but has
been updated a lot to, for instance work with 64 bit kernels etc.
Yes, it
On Sat, Dec 24, 2011 at 02:17:09PM -0600, Ryan Schmidt wrote:
If fuse4x-kext is forcing universal and shouldn't be on PowerPC, then we
should fix the port.
Yep, fixed in r88273.
It now only defaults to universal on Intel platforms. It also occurred
to me that if build_arch was ppc64, we'd
Yes, I've been giving some thought lately to the question of whether
we should remove this port.
It is certainly deprecated: any ports that depend on it default to
using fuse4x to satisfy the dependency instead. The macfuse port also
refuses to install for anyone who's using a 64-bit kernel.
One
On Fri, Dec 23, 2011 at 07:04:26PM -0800, Bradley Giesbrecht wrote:
On Dec 23, 2011, at 6:55 PM, Bradley Giesbrecht wrote:
Please make fuse4x build on PPC before removing MacFUSE.
Nevermind.
Setting 'universal_archs ppc' solved this error.
Hmm. We build the fuse4x kext universal by
On Mon, Dec 12, 2011 at 09:17:40PM -0500, Michael Dickens wrote:
From: Lukas Reichlin lukas.reich...@gmail.com
[...]
For reasons I don't understand, MacPorts octave port is still
version 3.2.4. The current release, version 3.4.3, is only
available as octave-devel. Since Octave 3.6.0 will be
On Fri, Dec 09, 2011 at 02:25:24PM -0800, Bradley Giesbrecht wrote:
Dan, I am not that familiar with svn. Are you suggesting something like the
following?
base/getversion.sh:
# Path to me.
DIRNAME=$(dirname $0)
SVN_REVISION=$(svnversion -n $DIRNAME)
Yes, exactly.
Dan
--
Dan R. K.
On Fri, Dec 09, 2011 at 12:42:53PM -0800, Bradley Giesbrecht wrote:
Is there any interest in adding the svn revision to the MACPORTS_VERSION when
port is built from trunk?
I wrote a shell script getversion.sh and call it from configure to add
-$REVISION when MACPORTS_VERSION
On Wed, Nov 30, 2011 at 02:49:57AM -0500, KonaBlend wrote:
1. new port:mkvtoolnix-gcc46 and install to mkvtoolnix private subtree.
2. new port:mkvtoolnix-boost and install to mkvtoolnix private subtree.
3. modify port:mkvtoolnix to depend on port:mkvtoolnix-gcc46 and
port:mkvtoolnix-boost and
As many of you may have noticed, gcc46 currently fails to build on
Lion: http://trac.macports.org/ticket/31171
As the discussion in that ticket indicates, the problem seems to be
caused by the --enable-fully-dynamic-string option we're adding to
configure.args. Basically, that needs to match
On Wed, Nov 23, 2011 at 09:46:20PM +1100, Joshua Root wrote:
I'm not entirely sure it's a false failure. FSF's position is a little
bit complicated and to me seems to try to make distinctions that don't
exist in reality. They say an interpreted program is not a derivative
work of the
On Tue, Nov 22, 2011 at 07:50:00PM -0600, Eric A. Borisch wrote:
OpenSSL's license negatively impacts the usefulness of the binary
distribution process within MacPorts. I propose moving openssl support
to a non-default variant within the pythonNN ports. This will permit
more of the packages
On Fri, Oct 21, 2011 at 04:13:56PM -0500, Ryan Schmidt wrote:
It's tedious to determine what license a project is under. It would be nice
if I could run a script and it would figure it out for me. Do we already have
one? My thoughts for how this could be done, for simple cases anyway, is to
On Tue, Oct 18, 2011 at 03:27:43PM +1100, Joshua Root wrote:
On 2011-10-18 09:35 , Dan Ports wrote:
Actually, the X11 license *is* the MIT license. We shouldn't refer to
it by two different names. Standardizing on MIT also conveniently
avoids this special case.
The X11 license has
On Mon, Oct 17, 2011 at 02:26:05PM -0500, Ryan Schmidt wrote:
I think it should only complain if there's a digit at the *end* of the
license (excepting X11).
Actually, the X11 license *is* the MIT license. We shouldn't refer to
it by two different names. Standardizing on MIT also conveniently
On Wed, Sep 21, 2011 at 02:19:13PM -0400, Jeremy Lavergne wrote:
I believe the perl 5 license equates to artistic-1 or gpl-1.
Is it worth adding to portmgr/jobs/port_binary_distributable.tcl?
The perl license allows any version of the GPL, so it should just be
'GPL' not 'GPL-1'
I've been
On Sat, Sep 03, 2011 at 06:22:08PM -0500, Ryan Schmidt wrote:
My understanding is that in the license field, the dash is a separator
between license name and version, so this looks like you're saying this port
is under version ZIP of the Info license.
Similarly, I'm not sure why we're
On Wed, Aug 31, 2011 at 01:59:22AM -0500, Ryan Schmidt wrote:
On Aug 30, 2011, at 19:03, Jeremy Lavergne wrote:
emacs-snapshot: drop lzmautils dependency (use_xz has that covered)
use_xz is only for depends_extract though, right?
Correct.
Someone can for any number of reasons wind
On Wed, Aug 17, 2011 at 03:57:18AM -0500, Ryan Schmidt wrote:
I haven't really looked at what all the changes in the perl5 portgroup
recently are, but why does this port set perl5.major to 5.12? What's the
reasoning?
This is a port that uses the perl5 portgroup but is really installing a
On Tue, Aug 16, 2011 at 03:29:38PM -0400, Daniel J. Luke wrote:
see https://trac.macports.org/wiki/FAQ#ownlibs
FWIW, I find that FAQ answer really unsatisfying. I agree that there
are good reasons why MacPorts uses its own libraries, but the claim
that the drawbacks of this policy are minimal
On Tue, Aug 16, 2011 at 03:08:31PM -0700, M.E. O'Neill wrote:
I summarized my feelings about swig's dependencies with this diagram:
http://i.imgur.com/S6vyf.png
I certainly take your point re: dependencies; I think it's a problem in
general.
It's easy for ports to accumulate
On Wed, Aug 17, 2011 at 09:09:25AM +1000, Joshua Root wrote:
Lion is the beginning of the end for Apple-supplied Java. So maybe we'll
need our own again soon.
...but hopefully it won't be Kaffe, which hasn't been updated in
years.
Dan
--
Dan R. K. Ports MIT CSAIL
On Tue, Aug 16, 2011 at 09:00:45PM -0700, M.E. O'Neill wrote:
The errors I discovered were:
biblatex-biber - piblatex-module-build
p5-list-uniq - p5.12-list-uniq
pemail - p5.12--mail-pop3client
pemail - p5.12--mime-lite
pemail - p5.12--term-readkey
On Mon, Aug 01, 2011 at 06:01:22PM -0400, Landon J Fuller wrote:
I think https://trac.macports.org/ticket/30373 might be worth holding 2.0.1
for a fix.
Yes, I agree. I am looking into that one now (but if anyone else knows
what's going on, don't let me stop you from fixing it!)
Dan
--
Dan
It looks like this is a problem with certain binary packages being
built on a case-sensitive FS and installed on a case-insensitive FS:
the package lists two separate files in its CONTENTS file, but only one
exists when it's extracted.
It only comes up for ports which install multiple files with
On Mon, Aug 01, 2011 at 10:05:34PM -0400, Arno Hautala wrote:
Either way, disabling archive fetching for a port (or all ports)
because of an edge case like this doesn't seem like a good solution.
I don't claim it to be -- I did it as a temporary workaround for a
problem that was clearly
On Sun, Jul 31, 2011 at 01:56:56AM -0500, Ryan Schmidt wrote:
...until those ports start jumping on the fuse4x bandwagon and start looking
for it by that name, right? :)
The well-behaved ones are already getting the library name from
pkgconfig (fuse.pc) and don't care, there are just a couple
1 - 100 of 160 matches
Mail list logo
