These should take care of the vast majority of the poppler / GO-I issues
https://github.com/macports/macports-ports/pull/8779
https://github.com/macports/macports-ports/pull/8780
I might have overlooked something. Please test / verify! - MLD
On Wed, Oct 14, 2020, at 6:06 AM, Ryan Schmidt wrote:
Hi Greg - You need to reinstall the "at-spi2-atk" port. For example:
{{{
sudo port -f uninstall at-spi2-atk
sudo port install at-spi2-atk
sudo port clean gtk3
sudo port upgrade gtk3
}}}
This worked for me recently. I hope it does for you too! - MLD
On Wed, Oct 14, 2020, at 10:41 AM, Greg Earle wro
Excellent! Thanks for the heads-up. I've downloaded this file and will get it
installed and start testing later today. - MLD
On Tue, Sep 29, 2020, at 2:47 PM, Gary Palter wrote:
> Apple today released Xcode 12.2 beta 2 and the Release Notes state
>> Apple Clang Compiler
>> Resolved Issues
>> *
Let's try this again from my MP email so that it gets to lists ... sorry for
duplicate emails!
I've finally gotten to the point of working out a hack solution.
One can -not- modify '/usr/bin' without a lot of effort. But, one can modify
'/Applications/Xcode[-beta].app/Contents/Developer/Toolcha
ntirely work with those built using
12.2beta? H
Thx! - MLD
On Tue, Sep 22, 2020, at 2:58 PM, Ryan Schmidt wrote:
>
>
> On Sep 22, 2020, at 13:29, Michael Dickens wrote:
>
> > % codesign -v - --ignore-resources
> > /opt/local/Library/Frameworks/Python.
There has been some discussion about the recent change Apple made for macOS
11.0beta7 for ARM Mac only (-not- Intel Mac at this time); we in MP-land had
some on this PR < https://github.com/macports/macports-ports/pull/8328 >. As
pointed out, a better venue for discussion would be these lists.
Hi Leo - We just merged in changes that swap which SWIG provides "bin/swig" ...
so, if you update your ports, then SWIG4 will be providing this binary.
Hopefully that addresses your issue! - MLD
On Thu, Apr 2, 2020, at 12:57 PM, Singer, Leo P. (GSFC-6610) wrote:
> Hi,
>
> I noticed that the "sw
s well.
Further thoughts? - MLD
On Fri, May 24, 2019, at 2:57 AM, Ryan Schmidt wrote:
>
>
> On May 19, 2019, at 10:13, Michael Dickens wrote:
>
> > I'm looking for advice on how to move forward with Boost 1.70.0's CMake
> > find scripts: do we just not install them
We're working on updating Boost to 1.70.0 <
https://github.com/macports/macports-ports/pull/4243 > ... we'd value others
participating, BTW! Thus far many ports work out of the box with it (current
Boost in MacPorts is 1.66.0, so there are some significant bug fixes and API
changes to deal with
Hi MacPorts folks - SWIG 4.0.0 has been released after much ado <
https://sourceforge.net/p/swig/news/2019/04/swig-400-released/ >. I'm positive
that this release fixes a bunch of bugs from the prior 3.0.12 release, as well
as adds a bunch of new useful features! But also as with any release the
I'd hope that there's a way to robustly move from one variant to the other
without the user having to engage with "port" to do so. I would hope that we
can avoid forcing the user to explicitly deactivate one and activate the other
variant.
I can think of a way to do this where we would end up w
See < https://trac.macports.org/ticket/58338 > with title "lots-o-ports: decide
on common variant name to build documentation: +docs or +doc".
There are approximately 128 ports that use +doc or +docs as the variant to
build documentation. Of those, approximately 75 use +docs, while the rest --
Yes that fix seems to work for me. - MLD
On Tue, Apr 2, 2019, at 11:32 AM, Chris Jones wrote:
>
>
> On 02/04/2019 4:25 pm, Chris Jones wrote:
> > Hi,
> >
> > I've just pushed an update to xterm enabling the double buffer option in
> > its configuration step. Could those affected please update
This issue started with the prior "xorg-server-devel" bump a while back. I just
moved to iTerm2 for the interim; -very- impressed with that terminal manager! I
still need Xterm for some things though ... sigh ... - MLD
On Mon, Apr 1, 2019, at 11:37 PM, Ken Cunningham wrote:
> > Has anybody else
This issue should be fixed. Please update your ports info, clean ‘libuv’, and
try installing it again. If you encounter the error after all of this, please
file a ticket. - MLD
On Sun, Jan 27, 2019, at 11:15 AM, Ryan Schmidt wrote:
>
>
> On Jan 19, 2019, at 16:16, Riccardo Mottola wrote:
>
>
Boost 1.67.00 and 1.68.00 both changed some critical APIs & we wanted to give
projects time to catch up. I haven't tested the recently released 1.69.0 yet,
but I've been running 1.68.00 for quite a while & it seems pretty stable with
respect to building MacPorts ports. I'll be testing 1.69.0 ove
2 ways that I can think of:
1) "activate" the specific port version & have port print "contents". As you
note, this doesn't work unless the port & version is active. This way might
break other ports temporarily due to binary incompatibility, but port does not
generally verify binary compatibili
I've no idea. I just got to this point today LOL ... barely enough time to
debug other issues right now with my work load! - MLD
On Wed, Oct 10, 2018, at 4:55 PM, René J.V. Bertin wrote:
> About the flashing you mention: is that related to the use of raster
> mode rendering, like KDE4 apps also
The Qt4-provided native apps seem to work correctly with no display issues.
I have "my usual" ports that use Qt4 mostly working on 10.14: mostly GNU Radio
and related. These apps are using PyQt4 as the interface to Qt4. At least in my
testing, PyQt4 has some display glitches that make it challen
This would be a Portfile change, adding in the flag you mention. Here's my
recommendation:
{{{
diff --git a/math/octave/Portfile b/math/octave/Portfile
index b20fb7b622..032ea2dce6 100644
--- a/math/octave/Portfile
+++ b/math/octave/Portfile
@@ -273,7 +273,8 @@ configure.args-append \
confi
Looks like the link command is missing LAPACK or the equivalent (e.g. maybe:
Atlas, OpenBLAS, Eigen), but since the log doesn't include the actual link
command I can't say for certain. Maybe add some verbosity to the build stage to
show the actual link command? - MLD
On Mon, Jul 23, 2018, at 3:
See < https://trac.macports.org/ticket/56294 >.
Boost 1.67.0 has significant changes in the way it handles time computations
that are not ABI or API backward compatible with any prior Boost.
I think all of the ports I maintain are multi-Boost compatible, and I've seen
updates to others I don't
I don't think I did anything special, and texlive-bin installed for me on 10.5
PPC without complaint.
That said, on 10.6 Intel there's an issue with objc++ compiling, where the
OBJCXXFLAGS requires "-fpermissive" to get over some untyped enum issues in
some security framework. I had 'port' use
< https://trac.macports.org/ticket/55944[1] >
We're working on it. - MLD
On Sat, Mar 10, 2018, at 7:15 PM, Lenore Horner wrote:
> I just upgraded outdated ports (it had been a month or two probably).
> And qscintilla-qt4 failed. I think the relevant chunk from the log
> is below. Has anyone el
Yes. Looks like the correct entry would be:
{{{
prefpane-8a65eb2.tar.gz \
rmd160 2527eee92d1634b811e6be9aab9b93c42f08d4e7 \
sha256
9227d2e309fcab59fb4ea342b5b72d9e1eee5e1de430e1e45175f0f9f50d1f34
Committed in <
https://github.com/macports/macports-ports/commit/83b7e9c9f69e8cc56cda33bab5f856a64cccdb5a
> already. Do a selfupdate / sync & update. - MLD
On Tue, Jul 25, 2017, at 03:33 PM, frédéric dubois wrote:
> Dear all,
>
> After the last update of my ports it appears a problem with sphinx
erty. Cheers! - MLD
On Tue, May 2, 2017, at 06:46 PM, Dave Horsfall wrote:
> On Tue, 2 May 2017, Michael Dickens wrote:
>
> > The new CppUnit has an interesting issue: #include'ing the header,
> > whether directly or indirectly, results in requiring linking to the
> >
The new CppUnit has an interesting issue: #include'ing the header,
whether directly or indirectly, results in requiring linking to the
library, because there is a new static variable in the primary namespace
in the header.
I think this is poor programming because, as an example, I might
#include a
Luckily the number of ports affected is pretty small (found via a grep):
./graphics/agave/Portfile:port:cppunit \
./graphics/libcdr-0.1/Portfile:port:cppunit
./graphics/libvisio-0.1/Portfile:port:cppunit \
./graphics/podofo/Portfile:
Guessing it's legacy cruft. Seems like for deprecated projects, there
should be just a "final release" port with patches added here and there
for compatibility; "devel" is really in my opinion for actively
in-development projects. That's what I do with qt4-mac, which amazingly
still mostly builds o
Your issue is https://trac.macports.org/ticket/53438 . - MLD
On Thu, Mar 23, 2017, at 08:27 PM, Eneko Gotzon wrote:
> Hi byte geniuses :)
>
> On Thu, Mar 23, 2017 at 3:54 PM, Michael Dickens
> wrote:
>> *The actual error is*:
>> {{{
>> :info:build ld: war
Hi Eneko - The actual error is:
{{{
:info:build ld: warning: ignoring file ../lib-src/lv2/liblv2.a, file was
built for archive which is not the architecture being linked (x86_64):
../lib-src/lv2/liblv2.a
:info:build Undefined symbols for architecture x86_64:
:info:build "_lilv_instance_free",
I'm glad that change worked. I didn't even realize that NumPy was still
being provided for any Python version outside 2.7 and 3.5 / 6. Now I'm
wondering why that's the case. Just out of curiousity, why NumPy using
Python 2.6? Why not use Python 2.7? It's been out for a -very- long time
and is still
Looks like upstream dropped support for Python 2.6 in 1.12.0 (that's the
error in the provided logfile). I've added back py26-numpy @1.11.3 in
https://github.com/macports/macports-ports/commit/e17e21ecb4c6feb901cca6a1b6125262a816b518
just now. Thanks for the pointer! - MLD
On Sat, Jan 21, 2017, at
34 matches
Mail list logo
