I have also observed the regression in compilation speed. Which
is not really surprising: GCC was slower, but producing better
code (at least on my project). Now clang is catching up on
the quality of the produced code, but that does require more
compilation time.
Is there a means to specify con
On Sun, Jul 06, 2014 at 02:26:46PM +0200, Mojca Miklavec wrote:
> I didn't look closely yet, but my blind guess is that ps4pdf used to
> be part of texlive-bin-extra and is now part of texlive-latex-extra.
> That's a common problem with TeX Live packaging on MacPorts (upstream
> sometimes moves fil
On 2014-7-7 10:00 , Mihai Moldovan wrote:
> Hi gpg users,
>
> We currently have three unmaintained ports for gnupg: gnupg (ver 1.4), gnupg12
> (ver 1.2) and gnupg2 (ver 2.x).
>
> In order to implement proper launchd integration in gpg-agent, I will likely
> have to slightly patch gnupg as well.
>
Hi gpg users,
We currently have three unmaintained ports for gnupg: gnupg (ver 1.4), gnupg12
(ver 1.2) and gnupg2 (ver 2.x).
In order to implement proper launchd integration in gpg-agent, I will likely
have to slightly patch gnupg as well.
If anyone here is (actively) using gpg 1.4 or 1.2, pleas
On Jul 06, 2014, at 23:56, Mojca Miklavec wrote:
>> universal_variant no
>
> I don't agree with this change. The "universal_variant no" is there
> for ports that are not capable of being built as universal.
It was just a suggestion, but semantically speaking the expression just
indicates that t
On Jul 06, 2014, at 23:30, Brandon Allbery wrote:
> I do not always understand the reasoning Canonical applies. But they use
> Debian as their upstream, so in this case that's where the policy comes from.
That's not exactly true, AFAIK they evolve independently (= much faster)
nowadays and just
On Sun, Jul 6, 2014 at 4:27 PM, René J.V. wrote:
>
> If one agrees that there is 0 (zero, nil) interest in a universal cmake
> variant, you could disallow building one with
>
> universal_variant no
I don't agree with this change. The "universal_variant no" is there
for ports that are not capable o
Hi,
On July 6, 2014 9:21:47 PM CEST, Ryan Schmidt wrote:
>Otherwise, a binary of git cannot be distributed
>(not by us, not by anyone).
That's not correct. Remember the GPL has an exception for linking against a
system's libraries. AFAIK, Linux distributions build git binaries on the
grounds t
On Sun, Jul 6, 2014 at 5:16 PM, "René J.V. Bertin"
wrote:
>
> On Jul 06, 2014, at 21:31, Brandon Allbery wrote:
>
> > public forums), but given that Debian distributes git and they're
> usually pretty good at being a stickler for license terms, I would expect
> the exemption exists and we just hav
On Jul 06, 2014, at 21:31, Brandon Allbery wrote:
> public forums), but given that Debian distributes git and they're usually
> pretty good at being a stickler for license terms, I would expect the
> exemption exists and we just have to confirm it and add it to the Portfile.
I suppose Canonica
On Sun, Jul 6, 2014 at 7:05 AM, "René J.V. Bertin"
wrote:
> That's got nothing to do with Apple-specific policies, right? Any idea how
> Unix repositories get around that conflict?
I expect git has an exception in its license terms for openssl. Otherwise,
it's being distributed illegally; this
On Jul 6, 2014, at 6:05 AM, René J.V. Bertin wrote:
> On Jul 06, 2014, at 12:30, Ryan Schmidt wrote:
>
>> $ ~/macports/base/portmgr/jobs/port_binary_distributable.tcl -v git
>> "git" is not distributable because its license "gpl" conflicts with license
>> "OpenSSL" of dependency "openssl"
>
>
On Jul 6, 2014, at 9:27 AM, René J.V. Bertin wrote:
> On Sunday July 06 2014 16:01:26 Clemens Lang wrote:
> >Hi,
> >
> >> Do those work both when installing cmake (as in it wasn't present) and when
> >> it is already installed but one installs an i386 port or a universal port
> >> that require cma
On Jul 6, 2014, at 10:30 AM, René J.V. Bertin wrote:
> A quick question concerning the MacPorts cmake-fu: I've noticed that you've
> managed to get cmake to ignore everything installed in /usr/local . I've
> tried invoking /opt/local/bin/cmake directly (= not through port) with the
> exact sam
On 7/6/14 9:44 AM, René J.V. Bertin wrote:
>
> On Sunday July 06 2014 11:40:55 Jeremy Lavergne wrote:
>
>
>
> >Don't forget we set our own PATH as well. Perhaps cmake actually
> respects it.
>
>
>
> I had a hunch, but didn't think yet to figure out to what you set it.
>
> It would make sense th
Don't forget we set our own PATH as well. Perhaps cmake actually respects it.
On July 6, 2014 11:30:07 AM EDT, "René J.V. Bertin" wrote:
>A quick question concerning the MacPorts cmake-fu: I've noticed that
>you've managed to get cmake to ignore everything installed in
>/usr/local . I've tried in
A quick question concerning the MacPorts cmake-fu: I've noticed that you've
managed to get cmake to ignore everything installed in /usr/local . I've tried
invoking /opt/local/bin/cmake directly (= not through port) with the exact same
arguments as port uses, but then it does find libraries I ins
Hi,
> Suggest you look at that file to see what is interfering with your network
> connection. Wildcard DNS A records and proxies are common causes, as noted
> on the wiki page also linked above. It's also possible that you got a 404
> page from the site. The downloaded HTML should say where the p
Hi,
> Do those work both when installing cmake (as in it wasn't present) and when
> it is already installed but one installs an i386 port or a universal port
> that require cmake?
Yes and yes. They will, however, not work when you install a new port
+universal and don't have cmake installed yet:
On Sun, Jul 6, 2014 at 6:55 AM, Jerry wrote:
> ---> Verifying checksums for qtiplot
> Error: Checksum (rmd160) mismatch for QTeXEngine-0.3-opensource.zip
> Error: Checksum (sha256) mismatch for QTeXEngine-0.3-opensource.zip
> ***
> The non-matching file appears to be HTML. See this page for poss
Hi,
> Can someone please help me come up with a setting in the cmake
> PortGroup that wouldn't lead to CMake being built as universal (when a
> port using the PortGroup would be installed as +universal)?
`installs_libs no' in the cmake Portfile should already do that.
Furthermore, there's the dep
Can someone please help me come up with a setting in the cmake
PortGroup that wouldn't lead to CMake being built as universal (when a
port using the PortGroup would be installed as +universal)?
Mojca
___
macports-users mailing list
macports-users@lists.m
On Sun, Jul 6, 2014 at 11:10 AM, Lenore Horner wrote:
> Upgraded outdated after not having done so for a few months (on Mavericks).
> The following.
>
> ---> Activating texlive-latex-extra @34239_0+doc
> Error: org.macports.activate for port texlive-latex-extra returned: Image
> error: /opt/local/
On Jul 06, 2014, at 12:30, Ryan Schmidt wrote:
> $ ~/macports/base/portmgr/jobs/port_binary_distributable.tcl -v git
> "git" is not distributable because its license "gpl" conflicts with license
> "OpenSSL" of dependency "openssl"
Yay ...
That's got nothing to do with Apple-specific policies,
On Jul 05, 2014, at 22:39, Clemens Lang wrote:
> You need an Info.plist file in the Contents folder of the app bundle. It needs
> to be an Apple property list file and contain the key CFBundleIconFile at the
> top dict level, where the corresponding value is the path of the icon file
> relative t
Attempting to install qtiplot like this:
sudo port install qtiplot +qtexengine +python27
causes this (log file is with ticket, https://trac.macports.org/ticket/44252)
MBPro:~ me$ sudo port install qtiplot +qtexengine +python27
---> Computing dependencies for qtiplot
---> Fetching archive for q
On Jul 3, 2014, at 6:32 AM, René J.V. Bertin wrote:
> I'm also a bit troubled installed my weekly bunch of upgrades: it seems there
> are much less binary packages available. I cannot remember having had to wait
> for the git port to build, for instance - it's completely gone from the
> mirror
On Jul 6, 2014, at 4:10 AM, Lenore Horner wrote:
> Upgraded outdated after not having done so for a few months (on Mavericks).
> The following.
>
> ---> Activating texlive-latex-extra @34239_0+doc
> Error: org.macports.activate for port texlive-latex-extra returned: Image
> error: /opt/loca
On Jul 6, 2014, at 4:31 AM, René J.V. Bertin wrote:
> On Saturday July 05 2014 18:30:57 Ryan Schmidt wrote:
>
> >No. MacPorts base does not have the capability to depend on a variant of
> >another port, only to depend on another port. See ticket #126.
> >
> >The active_variants 1.1 portgroup's
Upgraded outdated after not having done so for a few months (on Mavericks).
The following.
---> Activating texlive-latex-extra @34239_0+doc
Error: org.macports.activate for port texlive-latex-extra returned: Image
error: /opt/local/bin/ps4pdf is being used by the active texlive-bin-extra
port
30 matches
Mail list logo
