On Wed, Mar 26, 2014 at 10:37 AM, Joshua Root j...@macports.org wrote:
My reading of RFC 5322 is that the header field names are case-insensitive.
RFC5322 is one thing, the reality of spam traps another. De facto, it's
often assumed that non-normalized case is suspicious. And good luck
getting
On Fri, Apr 4, 2014 at 4:39 AM, Mojca Miklavec mo...@macports.org wrote:
I wonder why libperl.dylib ends up under
$prefix/lib/perl5/5.x.y/darwin-thread-multi-2level/CORE/libperl.dylib
when perl5.x.y is supposed to be binary compatible with perl5.x.z.
That's Perl's own packaging doing (and
On Fri, Apr 4, 2014 at 10:26 AM, Daniel J. Luke dl...@geeklair.net wrote:
On Apr 4, 2014, at 10:00 AM, Brandon Allbery allber...@gmail.com wrote:
People are still trying to figure out how to deal with perl ports; there
was a recent aborted attempt at building a port select mechanism
On Fri, Apr 4, 2014 at 7:46 PM, Ryan Schmidt ryandes...@macports.orgwrote:
On Apr 4, 2014, at 18:05, Brandon Allbery wrote:
If they're pure perl then that might work; if there's any XS involved
then a hard version dependency would be needed.
How would we determine that?
I don’t know enough
On Sat, Apr 5, 2014 at 1:59 AM, Mojca Miklavec mo...@macports.org wrote:
I also agree. (But maybe keep support for Perl 6 as a separate port(?) in
mind.)
Perl 6 is different enough that there's not much point in trying to fit it
into this.
--
brandon s allbery kf8nh
On Mon, Apr 7, 2014 at 10:20 AM, Mojca Miklavec mo...@macports.org wrote:
I see that mysql55 for example installs man pages to
$prefix/share/man/mysql55/man1/*.1.gz
where they are not really functional.
Is that a proper place for these files? / Is there any better place?
If you arrange
On Mon, Apr 7, 2014 at 10:40 AM, Mojca Miklavec mo...@macports.org wrote:
On Mon, Apr 7, 2014 at 4:22 PM, Brandon Allbery wrote:
On Mon, Apr 7, 2014 at 10:20 AM, Mojca Miklavec wrote:
I see that mysql55 for example installs man pages to
$prefix/share/man/mysql55/man1/*.1.gz
where
On Sun, Apr 13, 2014 at 10:39 AM, mk-macpo...@techno.ms wrote:
But if I let port show me all kmymoney4-devel deps it gets listed:
—
$ port rdeps kmymoney4-devel
...
kde4-runtime
kdelibs4
soprano
libiodbc
gtk2
gtk-doc
…
—
So, the question is,
On Sun, Apr 13, 2014 at 11:51 AM, mk-macpo...@techno.ms wrote:
On 13 Apr 2014, at 17:46 , Brandon Allbery allber...@gmail.com wrote:
Looks like it's because it's a build dependency --- so, while the gtk2
port is what pulled it in, it is not needed at runtime.
Ahhh, I see.
Thanks for solving
On Sun, Apr 13, 2014 at 7:56 PM, mk-macpo...@techno.ms wrote:
The only idea I had was that I started the whole MacPorts installation
from scratch and it ran perhaps for 4 hrs (with a 1h of short
interruptions) and somewhere in between I saw rev-upgrade rebuilding tiff…
So, I thought that some
On Tue, May 6, 2014 at 11:50 AM, Bruce Miller bruce.mil...@nist.gov wrote:
I have a draft of an updated Portfile,
but am not clear how to express the dependencies
on the Perl modules: DB_File, Pod::Parser and Test::More.
There don't seem to be separate p5-module ports
available. Are these
On Fri, Jun 6, 2014 at 3:06 AM, Vincent vi...@macports.org wrote:
The way to fix this is to use $@ instead of $*. See the wine port,
for example, which does this.
Is it “$@” with the double quotes or without? I guess it’s without, but
I’d like you to confirm.
With the quotes. Pedantically
On Fri, Jun 6, 2014 at 1:58 PM, Vincent vi...@macports.org wrote:
With the quotes. Pedantically ${1+$@} is most correct, but (a) I
suspect the case that protects against would fail anyway, and (b) on OS X
/bin/sh is bash which handles $@ as if it were ${1+$@}. (I do wonder
how long before
On Sat, Jun 7, 2014 at 12:15 PM, Eric Gallager eg...@gwmail.gwu.edu wrote:
On 6/6/14, Brandon Allbery allber...@gmail.com wrote:
replaced bash at some point, should Apple decide it needs a newer shell
than a GPL2-ed bash. zsh also has a permissive license (although some
contributed scripts
On Sat, Jun 14, 2014 at 10:25 PM, Ian Wadham iandw...@gmail.com wrote:
The procedure for closing the file descriptors is a bit brute force. It
uses
struct rlimit rlp; getrlimit(RLIMIT_NOFILE, rlp); to find out how many
open files the user is allowed (my system says 2560) and then does
On Sun, Jun 15, 2014 at 8:15 PM, Ian Wadham iandw...@gmail.com wrote:
Later the the FDs get closed anyway and it works then, perhaps because
the app gets issued with a STOP.
Unix closes all fd-s at process exit (including abnormal exit) anyway;
closing them preemptively like that doesn't make
On Sun, Jun 22, 2014 at 6:53 PM, Ryan Schmidt ryandes...@macports.org
wrote:
On Jun 22, 2014, at 3:47 PM, Michael Dickens wrote:
I use XQuartz's xterm, which, when used with default settings, locks
when one of those characters comes up. That's one reason I switched the
zmq* ports to use 0
On Sun, Jun 22, 2014 at 6:55 PM, Ryan Schmidt ryandes...@macports.org
wrote:
On Jun 22, 2014, at 9:54 AM, Kurt Hindenburg wrote:
On 6/21/14, 7:20 PM, Ryan Schmidt wrote:
Wouldn't this patch be safe to use on all OS X versions? If so, that
should be done. This will ensure that someone
On Sat, Jun 28, 2014 at 1:45 PM, Mark Brethen mark.bret...@gmail.com
wrote:
Those are the install_names at build time of each respective port.
I think you're confused about install_name means.
Every link-time shared object contains a canonical name telling the dynamic
loader how to find the
On Sat, Jun 28, 2014 at 2:23 PM, Mark Brethen mark.bret...@gmail.com
wrote:
So either the coin or soqt framework is bundled incorrectly? How would
check which is the culprit? I just installed coin +aqua and soqt +aqua
using '--without-framework' and did not get any link errors.
The
On Mon, Jun 30, 2014 at 4:30 PM, Marko Käning mk-macpo...@techno.ms
wrote:
Is qt5-mac not binary distributable? I had expected the buildbots to serve
it just like qt4-mac...
It was committed recently enough that I suspect the buildbots just haven't
caught up with it yet.
--
brandon s
On Tue, Jul 1, 2014 at 8:36 AM, Clemens Lang c...@macports.org wrote:
The other tools links, lynx, elinks fall into another category I have
really
no idea how to handle: while they seem to certainly be optional,
shouldn't we
make apache2 happy by providing them? Or is that useless
On Mon, Jul 7, 2014 at 2:30 PM, Mark Brethen mark.bret...@gmail.com wrote:
I only need to replace the uncommented line. So I tried
post-configure {
reinplace {:^#:!s:Inventor/scxml:scxml:g} \
${worksrcpath}/src/3rdParty/CMakeLists.txt
}
But this had no effect, when it should
On Tue, Jul 8, 2014 at 11:24 PM, Daisuke Takahashi dtakaha...@macports.org
wrote:
I would like to update the gnubg port to the current version. Could you
please check a proposing portfile and a patch that are attached on this
mail?
You might want to subscribe to macports-dev for this kind of
On Fri, Jul 18, 2014 at 5:54 PM, Mojca Miklavec mo...@macports.org wrote:
In my opinion it doesn't really make sense to use the last number to
install the modules or at least it's not compatible with the way
The problem with this is that XS-based modules can in fact be incompatible
between
On Tue, Jul 22, 2014 at 2:47 AM, Joshua Root j...@macports.org wrote:
There are some more unusual ways that people manage to break their
systems, like replacing executables (sed, tar, etc...) in /usr/bin with
incompatible versions (or just deleting them). I'm not sure if you want
to go down
On Tue, Jul 22, 2014 at 2:01 PM, Kyle Sammons ksamm...@macports.org wrote:
There are some more unusual ways that people manage to break their
systems, like replacing executables (sed, tar, etc...) in /usr/bin with
incompatible versions (or just deleting them). I'm not sure if you want
to go
On Tue, Jul 22, 2014 at 8:23 PM, Mihai Moldovan io...@ionic.de wrote:
Will `doctor` error if something like this is being found? Some software
likes
to install headers and dylibs to those locations and MacPorts should in
theory
not be affected when using -(i)sysroot.
In theory. Practice
On Mon, Aug 11, 2014 at 5:16 PM, David Evans dev...@macports.org wrote:
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.
Before assuming that, make sure the ones you've seen it in don't have a
break between pure Perl and XS
On Tue, Aug 12, 2014 at 11:15 AM, Daniel J. Luke dl...@geeklair.net wrote:
I'm just saying, it's a /lot/ of effort to do this for p5.8-p5.20 ports
when it could be reduced (somewhat) by just working on p5.20... (and
deprecating/removing everything else).
Also worth noting: the current Perl
On Thu, Aug 14, 2014 at 11:45 AM, Ryan Schmidt ryandes...@macports.org
wrote:
Check my work, but it looks like there aren't any ports that depend on
p5.8 or p5.10 versions of modules (other than other p5.8 and p5.10 modules
of course):
This caused me to check something and find a potential
On Thu, Aug 14, 2014 at 12:50 PM, Eric Cronin ecro...@macports.org wrote:
The pushd/popd came from the existing svn support, since it makes no sense
in a system() call I assumed it was intentionally done for the output vs a
single cd at the start (system -W didn't exist yet back then I think).
On Thu, Aug 14, 2014 at 1:00 PM, Jeffrey Johnson n3...@mac.com wrote:
(aside to Brandon Allbery)
The right fix is to repair the perl script that ghc -fvia-C needs
and flush the ancient perl5.8 and perl5.10 hysteria. JMHO, YMMV.
The correct fix is to disable -fvia-C and remove both the script
On Sun, Aug 17, 2014 at 10:39 AM, Davide Liessi davide.lie...@gmail.com
wrote:
/opt/macports-x86_64/libexec/macports/lib/darwintrace1.0/darwintrace.dylibDARWINTRACE_LOG=/tmp/macports_trace_859-336
This looks to me like a space is dropped somewhere, possibly only in the
case where a
On Fri, Sep 5, 2014 at 9:10 PM, Bradley Giesbrecht pixi...@macports.org
wrote:
I'm trying to write a function to return the remote file moddate. I copied
isnewer and changed the end as so.
...
theModDate = 0;
/* get the modification date */
theCurlCode =
On Sun, Sep 7, 2014 at 12:35 AM, Lawrence Velázquez lar...@macports.org
wrote:
On Sep 6, 2014, at 11:14 PM, Kurt Hindenburg kurt.hindenb...@gmail.com
wrote:
On 9/6/14, 9:03 PM, Ryan Schmidt wrote:
Many ports that use tcl also need the tcl source code (to get the
private headers, which are
On Sun, Sep 7, 2014 at 2:12 AM, Lawrence Velázquez lar...@macports.org
wrote:
On Sep 7, 2014, at 1:35 AM, Brandon Allbery allber...@gmail.com wrote:
Perhaps more to the point, the fact that MacPorts itself uses Tcl means
that it's much harder to deal with multiple versions. (As it is, I think
On Mon, Sep 8, 2014 at 1:24 PM, Lawrence Velázquez lar...@macports.org
wrote:
That's true, but it's a red herring. If our libstdc++ wasn't broken, ports
would not have to avoid it.
Our actual problem is that none of the g++ compilers we distribute are
viable because they don't use the
On Mon, Sep 8, 2014 at 2:22 PM, Lawrence Velázquez lar...@macports.org
wrote:
- My first assertion is that MacPorts' libstdc++ is broken on OS X because
it doesn't use the system C++ runtime, libc++abi. This assertion, strictly
speaking, is not about C++11 support.
It strictly IS about C++11
On Mon, Sep 8, 2014 at 2:35 PM, Lawrence Velázquez lar...@macports.org
wrote:
So if we start using our own libc++abi on older OS X, wouldn't C++
binaries built with Xcode's compilers be unable to interoperate with
binaries built with MacPorts compilers?
Only if you try to use it for
On Mon, Sep 8, 2014 at 2:44 PM, Brandon Allbery allber...@gmail.com wrote:
So the cases here are:
- pre-C++11 C++ support must use the system libstdc++ (the binary-only
backward compatibility one on newer systems whose development C++ runtime
is libc++).
- C++11 C++ support must either
On Tue, Sep 9, 2014 at 9:27 AM, Adam Dershowitz Ph.D., P.E.
de...@alum.mit.edu wrote:
I do understand why the behavior happened, and I am not sure of the best
solution going forward. Perhaps, when doing upgrades due to “scanning
binaries for linking errors” macports should honor the full
On Tue, Sep 9, 2014 at 10:12 AM, Daniel J. Luke dl...@geeklair.net wrote:
It's not entirely obvious what the 'correct' behavior would be, though.
Your new omniORBpy (upgraded with -u) is the only one available after the
upgrade. The installed openmodelica-devel is now broken (won't work with
On Sat, Sep 20, 2014 at 7:43 PM, Ryan Schmidt ryandes...@macports.org
wrote:
Why does ld64 need the *-headers ports at all?
Good question. Jeremy?
I expect it's common definitions for C++ exception handling/stack
unwinding. ld64 needs it to generate the link time information needed to
On Sat, Sep 20, 2014 at 8:01 PM, Jeremy Huddleston Sequoia
jerem...@macports.org wrote:
It was there long before I started working on it. I wonder if for some
reason libunwind.h wasn't installed in older SDKs. I see it there in
/usr/include on my Snow Leopard machine, so I gave the
On Tue, Sep 23, 2014 at 12:49 AM, Sean Farley s...@macports.org wrote:
I actually have the back story for this from the last PyCon. Suffice to
say, it's because of Python 3 screwing up the treatment of unicode
strings.
Huh. I'd assumed arm-twisting from Red Hat, possibly with an education
On Wed, Sep 24, 2014 at 6:08 PM, Lawrence Velázquez lar...@macports.org
wrote:
This would be, at best, an unreliable heuristic. I suppose it could check
whether a file named Portfile had been modified.
I could easily imagine having works in progress that I did *not* want the
buildbot to
On Wed, Sep 24, 2014 at 6:13 PM, Lawrence Velázquez lar...@macports.org
wrote:
What is the purpose of the buildslaves? Are they meant for building binary
archives, helping committers debug on the side? Or are they meant to be
committers' debugging tools that conveniently produce binary
On Sat, Sep 27, 2014 at 11:59 AM, Kurt Hindenburg kurt.hindenb...@gmail.com
wrote:
Hi, I find reinplace easier and less work for new releases. Are there
reasons to use one over the other?
reinplace is appropriate for replacing self-contained tokens and such.
When the context of an edit is
On Sat, Sep 27, 2014 at 11:12 PM, Joshua Root j...@macports.org wrote:
It would be better to fix the macros in xorg-cf-files or wherever so
they work with a modern preprocessor.
This probably isn't possible; the issue is that a modern preprocessor
speaks C / C++, not Makefile.
--
brandon s
On Sat, Sep 27, 2014 at 11:47 PM, Joshua Root j...@macports.org wrote:
That isn't the issue AFAICT, it's just doing things with comments that
were probably undefined before and now don't work:
That is in fact closely related to the issue. The old KR preprocessor
allowed that as a hack; ANSI C
On Sun, Sep 28, 2014 at 12:28 AM, Joshua Root j...@macports.org wrote:
It does, with a little tweaking. But you're still right, it then
proceeds to screw up the indentation in the Makefile.
Yeh. I got to know this stuff all to well trying to deal with Haskell's use
of CPP --- Haskell tokens
On Sun, Sep 28, 2014 at 5:22 AM, Clemens Lang c...@macports.org wrote:
as preprocessor. That's what GHC uses to preprocess its non-C macros, and
it
works there.
Mostly works. There are still cases where you can't turn off the implicit
dependency on C tokens, as I outlined previously. GHC
On Sun, Sep 28, 2014 at 11:21 PM, Jeremy Huddleston Sequoia
jerem...@apple.com wrote:
If I hear no objections in the next few days, I'll remove the ports in
that first group. If nobody speaks up, I think we should nuke KDE3 in a
few weeks.
If I understood other discussions correctly, KDE3
On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery allber...@gmail.com
wrote:
If I understood other discussions correctly, KDE3 is already being removed.
Sorry, not discussions; recent commit messages indicate that it's being
obsoleted and slated for removal starting from the leaves. See
On Tue, Sep 30, 2014 at 5:46 AM, Nicolas Pavillon ni...@macports.org
wrote:
Apart from the possibility of announcing calligra as a replacement of
koffice, I am nevertheless hesitating about committing the existing
portfile. It can build, so that it would be a good starting point to
improve
On Tue, Sep 30, 2014 at 11:44 AM, Craig Treleaven ctrelea...@macports.org
wrote:
I have only rudimentary acquaintance with sed and less with awk. I'd like
to learn more and this seemed like an opportunity to do so. From some
reading [1], I think sed's Hold buffer is the way to extract the
On Tue, Sep 30, 2014 at 5:02 PM, Bradley Giesbrecht pixi...@macports.org
wrote:
That's where the dictator comes in. At the moment, I would say the
obvious choices for a default MySQL variant would be mysql55, mariadb55 or,
maybe, mysql56. AFAICT there is no clear-cut, compelling reason to
On Wed, Oct 1, 2014 at 12:04 AM, Ryan Schmidt ryandes...@macports.org
wrote:
However, many ports have gcc variants from years ago before we fully
understood the C++ standard library mismatch issues
Said mismatch issues didn't exist until Apple switched the default compiler
to clang and
On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley s...@macports.org wrote:
- Always use clang for C/C++
- Drop PPC support
There are a lot of people relying on MacPorts to keep PPCs running.
In addition, I suspect that 99% of use cases are better handled by:
- Always use clang on 10.9 (or maybe
On Tue, Oct 14, 2014 at 10:12 AM, Daniel J. Luke dl...@geeklair.net wrote:
I suppose so. I never considered that there might be users that would
actually read a port's / portgroup's / base's code to validate it before
installing a port. Do such people actually exist?
I exist, and I do it.
On Thu, Oct 16, 2014 at 12:12 PM, Rainer Müller rai...@macports.org wrote:
$ dscl . -read /Users/macports NFSHomeDirectory
NFSHomeDirectory: /opt/local/var/macports/home
Oh, blah. I hate it when programs without specific security needs use that
instead of $HOME
--
brandon s allbery
On Sun, Oct 19, 2014 at 4:49 PM, Ryan Schmidt ryandes...@macports.org
wrote:
Why add IMPORTANT - Do Not Skip this step to this step? Singling out
this step gives the erroneous impression that other steps are not important
and can be skipped. All steps are important.
Because at least two
On Mon, Oct 27, 2014 at 8:26 PM, Landon J Fuller land...@macports.org
wrote:
On Oct 27, 2014, at 5:36 PM, Dan Ports dpo...@macports.org wrote:
Also, I think Apple mandates using a separate certificate for each
kext -- so we're stuck getting more certificates no matter what.
AFAIK it's
On Sun, Nov 2, 2014 at 10:25 PM, Lawrence Velázquez lar...@macports.org
wrote:
On Nov 2, 2014, at 9:29 PM, Marcus Calhoun-Lopez mcalh...@macports.org
wrote:
Recently, a user reported having his root account deleted after
installing the port dbus (Ticket #45737).
I do not see how it is
On Sun, Nov 16, 2014 at 4:52 PM, David Strubbe dstru...@macports.org
wrote:
Is there a way to make default variants be passed to dependencies when
installing them? My octopus port depends on fftw-3 and needs it to be built
with a Fortran variant. octopus has +gcc48 as default variant, and
On Tue, Nov 18, 2014 at 11:31 PM, Ian Wadham iandw...@gmail.com wrote:
For this kind of reason, fellow relational database designers/programmers
and I have
always eschewed the use of nulls (wherever I have worked, since about the
80s).
Funny, I never had a problem with the behavior of NULL.
On Wed, Nov 19, 2014 at 5:32 PM, petr 9...@ingv.it wrote:
It worked, but it seems to be down again. Ore is it only me?
Not loading for me either.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com
On Sun, Dec 7, 2014 at 4:10 PM, Marko Käning mk-macpo...@techno.ms wrote:
Joshua, how can we advertise mpstats to more users???
Message in the installer dmg (maybe even a checkbox to auto-install the
port?) and after selfupdate to a new version? The latter would even be
better as a
On Fri, Dec 12, 2014 at 12:05 PM, René J.V. rjvber...@gmail.com wrote:
subport ${name}-transitional {
I have yet to figure out the rules here, but one thing I tripped over when
I was experimenting with subports is that this can be recursive. That is,
if you select the subport, then $name is
On Fri, Dec 12, 2014 at 2:08 PM, Mark Brethen mark.bret...@gmail.com
wrote:
:info:build bflatten.cc:35:10: warning: cast to 'const void *' from
smaller integer type 'int' [-Wint-to-void-pointer-cast]
This indicates that the port is not 64-bit clean and you may have to force
the arch to i386
On Fri, Dec 12, 2014 at 9:59 PM, Mark Brethen mark.bret...@gmail.com
wrote:
Now, when building I had 5 errors:
:info:build perl ../smbase/run-flex.pl
-oagramlex.yy.cc
agramlex.lex
:info:build flex -oagramlex.yy.cc
agramlex.lex
:info:build modifying agramlex.yy.cc
:info:build c++ -c
On Sun, Dec 14, 2014 at 7:50 PM, Ryan Schmidt ryandes...@macports.org
wrote:
-pre-configure {
-system -W ${worksrcpath} ${waf.python} bootstrap.py
+post-extract {
+xinstall -m 0644 -W ${distpath} ${waf_distfile}
${worksrcpath}/waf
}
Remember, as Larry said in response to
On Thu, Feb 5, 2015 at 10:46 PM, Ryan Schmidt ryandes...@macports.org
wrote:
I think the perl5 portgroup is supposed to contain code now to make it
easy to create perl variants, instead of having to write all this code to
do it manually.
eperl is not a Perl module though, it is a Perl
On Mon, Jan 19, 2015 at 12:14 PM, Mojca Miklavec mo...@macports.org wrote:
Does one need the server edition of 10.5 to be able to install it in a
virtual machine?
Yes.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com
On Wed, Feb 11, 2015 at 2:45 PM, René J.V. rjvber...@gmail.com wrote:
Actually, I ran into it not because of a build system, but because I'd
opened destroot/Applications in the Finder, to check a generated app
bundle. Doesn't strike me as particularly not done, that ;)
Doctor, it hurts when
On Tue, Feb 10, 2015 at 9:52 AM, René J.V. rjvber...@gmail.com wrote:
On Tuesday February 10 2015 09:37:53 Brandon Allbery wrote:
I think someone did have this (try to) happen to them recently-ish. I also
I don't recall having seen this recently-ish issue discussed on a ML - or
it was about
On Tue, Feb 10, 2015 at 9:30 AM, René J.V. rjvber...@gmail.com wrote:
On Tuesday February 10 2015, Brandon Allbery wrote regarding Re:
~/.macports
Not supported, not a great idea, not an outright installation-breaking
idea. (Among other potential problems, a Portfile bug could nuke your home
On Wed, Feb 11, 2015 at 6:31 PM, René J.V. rjvber...@gmail.com wrote:
I take that to mean that doing fork() doesn't oblige you to do an exec()
afterwards, it's that you cannot do a fork() from a process that's not been
started through exec.
I will guess that this is related to the fact that
On Tue, Feb 10, 2015 at 12:46 PM, Chris Jones jon...@hep.phy.cam.ac.uk
wrote:
I for one so no particular reason why anyone would need a list of all list
members, whatever password protection or mangling you put into place. If
you want to send someone a mail and not sure if they are are member,
On Thu, Feb 12, 2015 at 11:58 AM, Jack Howarth
howarth.at.macpo...@gmail.com wrote:
So I take it that it is impossible to use MacPort's Xvfb without
abandoning the use of the Xquartz server in /opt/local/X11? That is
Installing MacPorts' Xquartz via xorg-server does not require you to
On Tue, Feb 17, 2015 at 3:36 PM, Bruce Miller bruce.mil...@nist.gov wrote:
Is the reason for (1) that 5.16 is currently the default perl,
and the reason for (2) that that user currently has perl 5.12
installed? (and thus should upgrade to perl 5.16)
Roughly yes to both. In the latter case,
On Thu, Feb 19, 2015 at 4:24 PM, Mojca Miklavec mo...@macports.org wrote:
It would be really nice if it was possible to use some key combination
that would stop the upgrade at the first convenient moment (making
sure that's not during patching or port activation for example).
I'm only aware
On Sun, Jan 11, 2015 at 2:43 PM, René J.V. rjvber...@gmail.com wrote:
My specific case (turned out to be moot) was that having QTDIR set in the
environment might undo MacPorts' sandboxing attempts
MacPorts nukes most user environment variables, doesn't it, precisely for
that reason?
--
On Sun, Jan 11, 2015 at 4:28 PM, Clemens Lang c...@macports.org wrote:
- On 11 Jan, 2015, at 22:21, Ian Wadham iandw...@gmail.com wrote:
Is there a good reason why we have the yersinia port on MacPorts? Please
read the description in full.
I don't see a problem with it? We have
On Sun, Jan 11, 2015 at 4:43 PM, Ian Wadham iandw...@gmail.com wrote:
OK, thanks. I was just checking… Yersinia pestis = bubonic plague (aka
the Black Death),
so an odd name for a piece of software.
I know. The SAINT white-hat vulnerability scanner was originally named
SATAN. The
On Tue, Jan 6, 2015 at 5:16 PM, Jeremy Whiting jpwhit...@kde.org wrote:
When I try to build Qt 5.4 with -dbus-linked using dbus from macports it
seems I have to specify -I/opt/local/include/dbus-1.0 but it still can't
configure because dbus's /opt/local/include/dbus-1.0/dbus/dbus.h includes
On Tue, Jan 6, 2015 at 5:46 PM, Jeremy Whiting jpwhit...@kde.org wrote:
Heh, only the one .h file is under /opt/local/lib, seems it should be by
the other dbus header files, no?
At a guess, the intended split was arch-dependent vs. arch-independent, and
all the other includes are the latter.
On Tue, Feb 10, 2015 at 6:02 PM, Ryan Schmidt ryandes...@macports.org
wrote:
As far as I know, Gmail is unique in that it deduplicates for you and only
shows you one copy. I assume it uses the Message-ID to do so.
It's not unique; Cyrus imapd could be configured to do so in early versions
and
On Tue, Feb 10, 2015 at 7:27 PM, Ian Wadham iandw...@gmail.com wrote:
From now on I want to use sudo, have a local-port structure that is NOT in
/opt/local
and have NO modifications of standard permissions in /opt/local.
But how do I get there, *safely*, from where I am?
On Tue, Feb 10, 2015 at 7:57 AM, René J.V. rjvber...@gmail.com wrote:
~/.macports is used instead of /opt/local/var/macports when you run
MacPorts in
a root installation but without root privileges. As such, MacPorts will
put
When `macportsuser root` in macports.conf?
I don't know if
On Wed, Mar 4, 2015 at 12:39 PM, Chris Jones jon...@hep.phy.cam.ac.uk
wrote:
Hmm, I did not realise this. I thought that it was the opposite way
around, so only files explicitly registered are made visible. Whats the
reason it doesn't work this way ? Some technical limitation or by choice
On Wed, Mar 4, 2015 at 11:43 AM, René J.V. rjvber...@gmail.com wrote:
I used to think like that, until I reported this kind of issue in one of
Qt's component. It was not very delicately pointed out to me that it's
common practice to build things without previous versions present (cf. the
On Wed, Mar 4, 2015 at 6:29 AM, René J.V. rjvber...@gmail.com wrote:
So to you it's OK if a port fails to build because it pulls in things from
an earlier, installed version of itself that were not blocked because the
feature was not enabled, and do so without as much as an explanation?
Port
On Mon, Feb 23, 2015 at 9:18 AM, René J.V. rjvber...@gmail.com wrote:
How can it do that without deactivating everything that's not somehow a
dependency (and thus making it impossible to do anything while an install
is being done), or by duplicating potentially a huge portion of the entire
On Thu, May 7, 2015 at 10:01 AM, René J.V. rjvber...@gmail.com wrote:
Building something unpronouncable: port:gwenhywfar4
gwenhwyfar4 which is plenty pronounceable if you understand how Welsh is
put together. If not, try the usual anglicization-via-French: guinevere-4.
--
brandon s allbery
On Thu, May 7, 2015 at 10:53 AM, René J.V. rjvber...@gmail.com wrote:
gwenhwyfar4 which is plenty pronounceable if you understand how Welsh
is
Seems you're skipping a prerequisite there... how should one know it's
Welsh and not, say, Polish?
The main prerequisite is recognizing a name
On Thu, May 7, 2015 at 12:48 PM, petr 9...@ingv.it wrote:
I am working on some new port. It works already quite fine, but I observe
that when using it without Tracemode, it would pick up various already
installed programs. Most of these are also provided by Xcode, but notably
when `doxygen`
On Thu, May 7, 2015 at 1:18 PM, René J.V. rjvber...@gmail.com wrote:
I thought it'd be nice to have the kdelibs4 documentation in Qt help
(.qch) format. It is available online, but seriously outdated and will of
course not reflect any OS X specific changes that we made.
There is a script in
On Fri, May 8, 2015 at 8:23 PM, Bradley Giesbrecht pixi...@macports.org
wrote:
mp-distributable kdelibs4
kdelibs4 is not distributable because its license gpl conflicts with
license APSL-2 of dependency ld64
I feel like that should have an exemption. Is ld64's *output* really
covered by
1 - 100 of 215 matches
Mail list logo
