On May 24, 2018, at 16:30, Eric Hall wrote:
> ghosthound pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/fd863dfac229f861d7c2245f7e25a0fabc07b814
>
> The following commit(s) were added to refs/heads/master by this push:
>
On May 24, 2018, at 23:15, Ken wrote:
> Ken (kencu) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/5cb3bb12990f7ea682e4b964eb86269923521397
>
> The following commit(s) were added to refs/heads/master by this push:
>
>
On May 25, 2018, at 12:57, Zero King wrote:
> On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:
>> It's been a week with no new tickets filed against base. I'll give it
>> one more week and then, if nothing comes up, tag a release candidate.
>>
>> - Josh
>
> I tried the rc1, and unar
On May 25, 2018, at 11:04, Ken Cunningham wrote:
> On 2018-05-25, at 8:38 AM, Ryan Schmidt wrote:
>
>> If this is supposed to help 10.6...
>>
>>
>>> +@@ -197,6 +197,8 @@
>>> + v = float('.'.join(v.split('.')[:2]))
>>&g
On May 24, 2018, at 09:06, Renee Otten wrote:
> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/bf5b0c8d47ccb5ebd6ea008744708aef2ea6020c
>
> commit bf5b0c8d47ccb5ebd6ea008744708aef2ea6020c
>
>
On May 25, 2018, at 21:28, Renee Otten wrote:
> On May 25, 2018, at 3:48 PM, Ryan Schmidt wrote:
>
>> Replacement doesn't work (doesn't show up in "port outdated") unless the
>> version or revision of the replacement is higher. So you want "0.7.6
On May 26, 2018, at 11:15, Ken Cunningham wrote:
> On May 25, 2018, at 12:05 PM, Ryan Schmidt wrote:
>
>> It's "broken" in that it links with libstdc++, even though MacPorts believes
>> it will link with libc++ on your system. The rev-upgrade code in previous
On May 26, 2018, at 11:48, Ken Cunningham wrote:
> Well I think you did the cmake finaggeling last time Not sure you could
> find a better way, but I wait to see...
I don't recall what you're referring to.
On May 26, 2018, at 14:25, Ken Cunningham wrote:
> On May 26, 2018, at 9:49 AM, Ryan Schmidt wrote:
>
>> On May 26, 2018, at 11:48, Ken Cunningham wrote:
>>
>>> Well I think you did the cmake finaggeling last time Not sure you could
>>> find a bette
On May 26, 2018, at 14:38, Ken Cunningham wrote:
> On May 26, 2018, at 12:27 PM, Ryan Schmidt wrote:
>
>> The error occurs when there is a mismatch between which C++ standard library
>> a port says it uses (by setting configure.cxx_stdlib, or by leaving it set
>> t
On May 28, 2018, at 21:10, Zero King wrote:
> Hi,
>
> On Thu, May 10, 2018 at 03:58:11PM +1000, Joshua Root wrote:
>> Source code and pkgs for MacPorts 2.5.0-beta1 are now
>> available [1]. Testing of either of these install methods is helpful.
>
> Now that 2.5.0 is released, we should protect
On May 29, 2018, at 13:31, macpo...@parvis.nl wrote:
> I'm trying to work as much as possible with scripted procedures.
>
> After an initial install of a new/modified port, I need to apply/change
> patches.
>
> My workflow is:
>
> port install munin
>
> #- cycle start
> port clean --work
On May 28, 2018, at 11:49, Joshua Root wrote:
> On 2018-5-28 13:58 , Ken Cunningham wrote:
>> I believe understand that there is one copy of libstdc++ installed by the
>> latest functional version of gcc, at present gcc7.
>>
>> All the versions of gcc from gcc45 to gcc7 use that same library.
On May 30, 2018, at 12:48, macpo...@parvis.nl wrote:
> $ port livecheck macports
> MacPorts seems to have been updated (port version: 2.5.0, new version:
> 2.5.0-rc1)
>
> missed this one in the release process ?
Doesn't really matter; nobody but MacPorts release engineers should be doing
any
On May 29, 2018, at 14:10, macpo...@parvis.nl wrote:
> On 2018-05-29, at 20:41, Ryan Schmidt wrote:
>
>> On May 29, 2018, at 13:31, macpo...@parvis.nl wrote:
>>
>>> I'm trying to work as much as possible with scripted procedures.
>>>
>>>
On May 30, 2018, at 16:31, macpo...@parvis.nl wrote:
> On 2018-05-30, at 21:47, MacPorts wrote:
>
>> #56562: jbig2dec @0.14: checksum mismatch
>> ---+--
>> Reporter: pdvnl | Owner: (none)
>> Type: defect| Status: new
>> Priority:
On May 31, 2018, at 00:39, Ken Cunningham wrote:
> pbzip2 is using libstdc++ (this installation is configured to use libc++)
> dylibbundler is using libstdc++ (this installation is configured to use
> libc++)
> lzma is using libstdc++ (this installation is configured to use libc++)
> SuiteSpars
On May 31, 2018, at 10:44, Dr M J Carter wrote:
> On Thu, May 31, 2018 at 07:49:23AM -0700, Ken Cunningham wrote:
>>
>> On 2018-05-30, at 11:04 PM, Joshua Root wrote:
>>
>>> On 2018-5-31 15:39 , Ken Cunningham wrote:
gcc5 is using libstdc++ (this installation is configured to use libc++)
On May 31, 2018, at 12:21, iEFdev wrote:
> I have some 5-6 ports that show this (gptfdisk, flac, etc.).
gptfdisk: https://github.com/macports/macports-ports/pull/1910
flac: I do not see anything wrong with the port. Every invocation of the
clang++ already specifies the -stdlib flag. If that's
On May 31, 2018, at 00:39, Ken Cunningham wrote:
> pbzip2 is using libstdc++ (this installation is configured to use libc++)
I can't see why this would be. The build only invokes the C++ compiler once,
and does pass the -stdlib flag when doing so. Please file a ticket with a
main.log and any
On Jun 2, 2018, at 16:51, Marius Schamschula wrote:
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/4c13d30353d2d95d746769aad50070aebdb4b688
>
> The following commit(s) were added to re
On Jun 5, 2018, at 02:29, Jeremy Huddleston Sequoia wrote:
> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
> in repository macports-base.
>
>
> https://github.com/macports/macports-base/commit/87faa2b7c04210924a051170d46d5577ec5695e8
>
> The following commit(s) were ad
On Jun 11, 2018, at 06:11, Marius Schamschula wrote:
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/dfa205dc41704c676c0314dbad7b05f0dd316dd4
>
> commit dfa205dc41704c676c0314dbad7b05f0
On Jun 11, 2018, at 11:02, Jimmy Yuen Ho Wong wrote:
> Jimmy Yuen Ho Wong (wyuenho) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/939a556e7a2572b8f1efe72ddd23857f2ef4e92f
>
> The following commit(s) were added to refs/
On Jun 11, 2018, at 20:31, Adam Mercer wrote:
> Adam Mercer (skymoo) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/16e7c1d2b68ae38536271e6572c116b11620b125
>
> The following commit(s) were added to refs/heads/master by
On Jun 14, 2018, at 21:05, Mark Moll wrote:
>
> Mark Moll (mamoll) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/38cd410e2856185b53446dabe2667cd47969fcce
>
> The following commit(s) were added to refs/heads/master by t
On Jun 18, 2018, at 14:20, Randolph M. Fritz wrote:
> This is what I ended up with. I don't like it at all.
>
> pre-destroot {
> # This fixes what may be a cmake error
> catch {
> # look for DESTDIR in the fixup_bundle arguments
> exec grep -q {fixup_bundle.*DESTDIR}
> ${wo
On Jun 19, 2018, at 12:15, Randolph M. Fritz wrote:
> Ryan Schmidt – Portfile attached.
Thanks. It references the patchfile cmakelists_patches.diff; could you attach
that too? I want to try to build the port.
On Jun 20, 2018, at 05:45, George Plymale II wrote:
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/35915ffebeb3fc380ca45cdbde23e8ed9a8eb51d
>
> The following commit(s) were added to re
On Jun 20, 2018, at 23:15, Blair Zajac wrote:
> On Jun 20, 2018, at 7:21 PM, Ryan Schmidt wrote:
>
>> On Jun 20, 2018, at 05:45, George Plymale II wrote:
>>
>>> Marius Schamschula (Schamschula) pushed a commit to branch master
>>> in repository macports-por
On Jun 21, 2018, at 03:44, George Plymale II wrote:
Why are we offering this? Selecting this variant would break any port that
depends on this port. We should strive not to provide users with ways of
shooting themselves in the foot.
>>>
>>> Besides this breaking change, i
;
> --
> Randolph M. Fritz || +1 206 659-8617 || rmfri...@gmail.com
>
> On Tue, Jun 19, 2018 at 5:04 PM, Randolph M. Fritz wrote:
> Wow, thanks.
>
>
>
> --
> Randolph M. Fritz || +1 206 659-8617 || rmfri...@gmail.com
>
> On Tue, Jun 19, 2018 at 2:46 PM
On Jun 27, 2018, at 15:25, Rainer Müller wrote:
> Just to add to the previous discussion, /usr/bin/grep used to be
> GNU grep on older versions of macOS. That is probably the reason why it
> does not implement the g* prefix like the other ports for GNU tools yet.
>
> On 2018-06-27 21:14, George
On Jul 4, 2018, at 14:07, Jeremy L wrote:
> Jeremy L (nerdling) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/0ef87ed1231742cf86a026814f6e866fef4268db
>
> commit 0ef87ed1231742cf86a026814f6e866fef4268db
>
> Author: Je
On Jul 4, 2018, at 10:41, Christopher Jones wrote:
> I am just curious, has anyone else signed up for the 10.14 beta and played
> with it and MacPorts ?
>
> I have been doing this myself, in a VM, and whilst we cannot discuss anything
> here on list, as per the NDA, I would be interested to i
On Jul 6, 2018, at 00:00, Eitan Adler wrote:
> Eitan Adler (grimreaper) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/6935f6ab1cf8b99c9ca0cdaa2f8d03a5566b4e73
>
> The following commit(s) were added to refs/heads/master
On Jun 28, 2018, at 12:47, tomio-arisaka wrote:
> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/f564833fda44e715f61fe9c5e34e521a7ddc1882
>
> The following commit(s) were added to refs/heads/
On Jul 7, 2018, at 07:28, Perry E. Metzger wrote:
> I strongly suggest that you simply fix the issues in question. Were
> it not for the fact that I've had a lot of unavoidable drains on my
> time recently, I would have hand-fixed all of the issues and
> committed the (correct) changes myself, b
On Jul 13, 2018, at 21:33, Jeremy L wrote:
> On 07/05/2018 01:29 AM, Ryan Schmidt wrote:
>> On Jul 4, 2018, at 14:07, Jeremy L wrote:
>>> Jeremy L (nerdling) pushed a commit to branch master
>>> in repository macports-ports.
>>>
>>>
>>
On Jul 17, 2018, at 10:54, Scott Cantor wrote:
> Scott Cantor (scantor) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/2ef05daf9bd5363708c60a6ddf04ac8a02221356
>
> The following commit(s) were added to refs/heads/maste
On Jul 19, 2018, at 17:46, Mark Moll wrote:
> The py-graph-tool port doesn’t compile on High Sierra (10.13) due to a linker
> error that happens during the configure stage [1]:
>
>
> configure:19051: checking consistency of all components of python development
> environment
> 2037 configur
On Jul 24, 2018, at 13:51, Mark Moll wrote:
> Mark Moll (mamoll) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/d5637d824ed07189a10a3e32dc135fe909192f8c
>
> commit d5637d824ed07189a10a3e32dc135fe909192f8c
>
> Merge: 04b9
On Jul 29, 2018, at 11:32, Chris Jones wrote:
> Is there anyone who has a PPC machine running Darwin 9 (OSX 10.5) that would
> be willing to run a test of the PR
>
> https://github.com/macports/macports-ports/pull/2296
>
> ? For the reasons outlined in the PR it would be useful to know if th
I am hoping instead it also defaults to
> clang-3.4 (or we can convince it to). Its also true that gcc9/libgcc-devel is
> only a snapshot, so things might improve in before a final release (which is
> why right now I don’t think its a big deal).
>
> Chris
>
>> On 29 Jul
On Jul 29, 2018, at 13:59, Chris Jones wrote:
> On 29 Jul 2018, at 7:29 pm, Ryan Schmidt wrote:
>
>> clang does not work on PowerPC.
>
> Ah, right. I was just looking at
>
> http://packages.macports.org/clang-3.4/
>
> And saw the last versions had a Darwin 9
On Aug 2, 2018, at 08:03, Vincent wrote:
> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/a3f753c7a496641b4c85d6494806eee3951eb59b
>
> The following commit(s) were added to refs/heads/master by this pu
On Aug 3, 2018, at 18:01, David B. Evans wrote:
> David B. Evans (dbevans) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/7d5300f0703c626ec2f649b38c023bbd42093236
>
> commit 7d5300f0703c626ec2f649b38c023bbd42093236
>
On Aug 8, 2018, at 10:11, Craig Treleaven wrote:
> I ran across an article this morning describing how Homebrew was hacked with
> a few minutes effort:
>
> https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab
>
> Has anybody checked to see if we have
On Aug 11, 2018, at 10:13, René J.V. Bertin wrote:
> I've been using non-integer (but numerical) epochs in a few of my ports just
> because it made sense to set it e.g. to 5.1 when I started using the 5.1
> branch in a port. AFAIK the property is purely internal so it could be
> anything (i.
On Aug 11, 2018, at 15:58, René J.V. Bertin wrote:
>> " Some Portfile authors have used large epoch values that look like a date,
>> but there is no reason to do so"
>
> nor is there a reason not to (that's not based on an ad-hoc decision) ...
>
> The doc reads a bit as if the epoch is equivale
On Aug 15, 2018, at 01:35, Andrew Stromnov wrote:
> Andrew Stromnov (stromnov) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/efcf55361d5dd2a42f115372c8f741ac4ec8f674
>
> commit efcf55361d5dd2a42f115372c8f741ac4ec8f674
On Aug 17, 2018, at 15:06, Clemens Lang wrote:
> I think the idea of the size keyword is to start to use it to display
> download progress bars for servers that do not send a Content-Length
> HTTP header (or do not have an equivalent of such a header due to the
> used protocol). This is current
On Aug 18, 2018, at 02:53, Jan Stary wrote:
> How many of the total number of ports have their distfiles served
> by such servers?
One such server that does not use a Content-Length header is the GitHub server
that generates tarballs of commits and tags; many hundreds of Portfiles use
those.
On Aug 22, 2018, at 20:30, Perry E. Metzger wrote:
> After seeing a security advisory on one of the xorg ports and
> realizing that we hadn't updated a bunch of them in a while and that
> xquartz (the project) seems pretty dead, I started going in and
> updating various things in xorg-* that ha
On Aug 22, 2018, at 13:46, Jan Stary wrote:
> On Aug 21 22:58:07, j...@macports.org wrote:
>> On 2018-8-18 06:06 , Clemens Lang wrote:
>>> I think the idea of the size keyword is to start to use it to display
>>> download progress bars for servers that do not send a Content-Length
>>> HTTP head
On Sep 4, 2018, at 08:13, Mojca Miklavec wrote:
> Dear Joshua,
>
> On Tue, 4 Sep 2018 at 14:04, Joshua Root wrote:
>> On 2018-9-4 19:15 , Mojca Miklavec wrote:
>>> Hi,
>>>
>>> I would like to ask for some help making a little trick work. Here's
>>> my attempt of a PR:
>>>https://github.co
The freetype-config script is now deprecated. pkg-config should be used instead.
If you maintain a port that depends on freetype, please install the freetype
port with its new +no_freetype_config variant and see if your port still builds
correctly. Look out for errors that stop the build due to
On Sep 4, 2018, at 09:21, Mojca Miklavec wrote:
> Hi,
>
> I tried to set up a new buildbot slave on a Mac, but failed to do so due to
>
>pkg_resources.DistributionNotFound: The 'PyHamcrest>=1.9.0'
> distribution was not found and is required by Twisted
>
> I'll try to create a package for t
On Sep 7, 2018, at 04:08, Mojca Miklavec wrote:
> On Fri, 7 Sep 2018 at 10:39, Chih-Hsuan Yen wrote:
>>
>> Hi all,
>>
>> In many Python libraries, depends_lib is used to store dependencies
>> listed in install_requires of setup.py. According to MacPorts
>> documents, depends_lib is for depend
On Sep 7, 2018, at 22:08, Chih-Hsuan Yen wrote:
> Thank you both for explanations and reasoning! As depends_run and
> depends_lib are practically the same for Python ports, how about
> moving all ports to either depends_lib or depends_run gradually?
> Having two patterns hurts my eyes :D
>
> I
On Sep 14, 2018, at 00:12, Mojca Miklavec wrote:
> On Fri, 14 Sep 2018 at 06:18, Joshua Root wrote:
>>
>> On 2018-9-14 13:49 , George Plymale II wrote:
>>> Also, I'm curious. You said that I'll lose the ability to get binary
>>> packages. Which element of this setup causes compilation to become
>
On Sep 17, 2018, at 08:33, Mark Brethen wrote:
> I’m getting the following error when trying to build current snapshot of
> reduce-csl:
>
>
> :info:build Undefined symbols for architecture x86_64:
> :info:build "_libintl_dgettext", referenced from:
> :info:build _FcConfigFileInfoIter
On Sep 16, 2018, at 22:48, Mark Brethen wrote:
> I was having trouble building the pdf file in /doc/manual. Checking the
> manual.log I saw the following error on the title.tex file:
>
> ! Package inputenc Error: Invalid UTF-8 byte 246.
>
> See the inputenc package documentation for explanat
On Sep 17, 2018, at 17:01, Mark Brethen wrote:
> Adding "-lintl" to configure.ldflags seems to have worked however new errors
> popped up:
>
> :info:build make[3]: *** No rule to make target
> `/opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce-csl/work/Reduce-source_4717/c
On Sep 18, 2018, at 08:25, Mark Brethen wrote:
> Yep, here is his response:
>
>> Aha - when I look at your macports log you do not seem to be fetching Reduce
>> from subversion, you are fetching a source .tar file for it. Well that has
>> not up to now contained profile.dat because one can r
On Sep 18, 2018, at 09:55, Jackson Isaac wrote:
> Lately, I have seen open source projects have started adopting Code of
> Conduct. [1], [2]
>
> I think it is a great step to keep the open source community healthy
> and welcoming to everyone.
>
> I would like to know what other developers thi
On Sep 17, 2018, at 21:55, Ken Cunningham wrote:
> I’m about to archive my current high sierra setup into a VM, and if possible,
> I’d like it to match the way the buildbot will be finally left.
>
> 10.13 with XCode 9?
>
> or
>
> 10.13 with Xcode 10?
>
> I guess people who stay on 10.13 wi
On Sep 17, 2018, at 19:39, Perry E. Metzger wrote:
> Are we currently set up for the new Xcode 10? It was officially
> released today, although Mojave won't show up for another week.
The minimal changes to have MacPorts recognize Xcode 10 were committed in June:
https://github.com/macports/ma
Apple has announced [1] that macOS Mojave (10.14) will be released on September
24, 2018. It will require Xcode 10, which has already been released.
If you have not yet been testing the macOS Mojave public beta, and you have a
spare machine or disk you could install it on, you may want to do so
On Sep 18, 2018, at 10:53, Ryan Schmidt wrote:
>
> An area of possible concern for High Sierra is if Xcode 10 removes the same
> 32-bit parts that macOS Mojave removes.
The Xcode 10 release notes confirm that it does remove the 32-bit parts from
the macOS SDK:
https://developer.
On Sep 18, 2018, at 13:09, Perry E. Metzger wrote:
> On Tue, 18 Sep 2018 10:53:19 -0500 Ryan Schmidt wrote:
>> The minimal changes to have MacPorts recognize Xcode 10 were
>> committed in June:
> [...]
>> The base change was included in MacPorts 2.5.3 released in July
On Sep 18, 2018, at 13:04, Mark Brethen wrote:
>
> More feedback from the developer:
>
>> Supposing that a profile.dat is available in csl/generated-c (as it is when
>> one has fetched from subversion, and it will be in some future snapshots,
>> but is NOT in the files you unpack from the .t
On Sep 18, 2018, at 21:48, Mark Brethen wrote:
> The current src for reduce now builds a reduce.app that you should be able to
> double-click to open. Should this be moved to the Macports Applications
> folder? There is also a script "redcsl" which must be stored adjacent to
> reduce.app. A
On Sep 20, 2018, at 13:43, Ken Cunningham wrote:
>> On Sep 18, 2018, at 8:46 AM, Ryan Schmidt wrote:
>
>> I have not looked into it, but if the macOS SDK in Xcode 10 removes the same
>> aspects of 32-bit support that macOS Mojave removes, then we may not want to
>> i
On Sep 21, 2018, at 21:46, Mark Brethen wrote:
> I’m trying to install a list of files into directory:
>
>foreach app {reduce.app bootstrapreduce.app csl} {
>xinstall -p -W ${cslbuilddir}/csl/${app} ${libexecdir}/csl
>ln -s ${destroot}${applications_dir}/${name}/${app}
> $
On Sep 21, 2018, at 23:30, Ryan Schmidt wrote:
> On Sep 21, 2018, at 21:46, Mark Brethen wrote:
>
>> I’m trying to install a list of files into directory:
>>
>> foreach app {reduce.app bootstrapreduce.app csl} {
>> xinstall -p -W ${cslbuilddir
On Sep 21, 2018, at 23:42, Ryan Schmidt wrote:
> On Sep 21, 2018, at 23:30, Ryan Schmidt wrote:
>
>> On Sep 21, 2018, at 21:46, Mark Brethen wrote:
>>
>>> I’m trying to install a list of files into directory:
>>>
>>> foreach app {reduce.app bo
On Sep 23, 2018, at 08:17, Mark Brethen wrote:
> I have updated the Macports portfile for Reduce snapshot 2018-08-08.
> Everything seems to function properly, with one exception: reduce.app. When
> launched in gui mode under X11 the plot command does not open AquaTerm, as if
> it does not re
On Sep 23, 2018, at 18:25, Mark Brethen wrote:
> On Sep 23, 2018, at 5:42 PM, Ryan Schmidt wrote:
>> On Sep 23, 2018, at 08:17, Mark Brethen wrote:
>>
>>> I have updated the Macports portfile for Reduce snapshot 2018-08-08.
>>> Everything seems to func
On Sep 23, 2018, at 18:58, Mark Brethen wrote:
> Here’s the portfile.
I can't build it because it uses two patchfiles I don't have:
patch-csl-cslbase-create_bundle.sh.diff
patch-csl-cslbase-create_old_bundle.sh.diff
It doesn't build for me...
Undefined symbols for architecture x86_64:
"directoryp(char*, char const*, unsigned long)", referenced from:
Ldirectoryp(long, long) in csl-print.o
"fwin_menus(char**, char**, void (*)())", referenced from:
cslstart(int, char const**, int (*)(int)) in cs
to your gnuplot question, since I know nothing about reduce,
what do I do to get it try to launch gnuplot?
\r
On Sep 23, 2018, at 21:23, Mark Brethen wrote:
> I built it on Sierra. What’s the missing symbol?
>
>
> Mark Brethen
> mark.bret...@gmail.com
>
>
>
e ‘plot cos(x);’ [enter]
>
> At this point AquaTerm should open and display a plot of the cosine for -10 <
> x < 10.
Thanks. So doing this did fix the problem for me:
On Sep 23, 2018, at 20:16, Ryan Schmidt wrote:
> a) Figure out where in the code it calls the gnuplot executable, a
The release of macOS Mojave is imminent and I want to make sure we do the right
thing for the first release of MacPorts on Mojave. Let me know if you have any
thoughts about the below.
Ideally I would like to keep the ability to build 32-bit ports in MacPorts on
Mojave, mainly because I don't w
On Sep 24, 2018, at 11:06, Frank Schima wrote:
> On Sep 24, 2018, at 1:48 AM, Joshua Root wrote:
>
>> Currently, portconfigure::configure_get_sdkroot will return an error if
>> there is no SDK for the current OS version, and /usr/include also is not
>> present [1]. A recent change stopped warn
On Sep 24, 2018, at 18:54, Eitan Adler wrote:
> When i ran "sudo port selfupdate" for the first time on a new (from
> source) install I see this
>
> ---
> ∴sudo port -v selfupdate
> Password:
> ---> Updating MacPorts base sources using rsync
>
> Willkommen auf dem RSYNC-server auf ftp.fau.de
On Sep 24, 2018, at 19:02, Eitan Adler wrote:
> On Mon, 24 Sep 2018 at 16:58, Ryan Schmidt wrote:
>>> Nothing seemed to go wrong, but it is noisy and might spark additional
>>> questions. This email is mostly an FYI.
>>
>> Just to make sure: your complaint is th
On Sep 26, 2018, at 17:14, Perry E. Metzger wrote:
> It seems that there's a bad interaction between Xcode 10's new build
> system and certain ports. "pinentry-mac" is the only one I've hit so
> far but there may be others. The kludge is to tell Xcode 10 (if it is
> the version running) to use
On Sep 29, 2018, at 02:19, Mojca Miklavec wrote:
> Hi,
>
> Is there a chance that we add a new cxx14 (and cxx17) PortGroup, at
> least as an intermediate step before a better solution is worked out.
>
> I admit that I don't like zillion portgroup to achieve basically the
> same thing (cxx11 c
On Sep 29, 2018, at 08:13, Perry E. Metzger wrote:
> It's relatively important that
> https://github.com/macports/macports-base/pull/107
> get dealt with relatively soon. There are significant ports that fail
> to build for Mojave because universal builds fail.
Can you give an example?
> If
On Sep 30, 2018, at 15:07, Jack Howarth wrote:
> Why aren't we leveraging the -DLIBOMP_OSX_ARCHITECTURES cmake flag to control
> whether "x86_64;i386" or "x86_64" get built?
We already use CMAKE_OSX_ARCHITECTURES, via the cmake portgroup.
The specific problem for libomp was that the portfile
On Oct 1, 2018, at 09:00, Ken Cunningham wrote:
> To force Xcode10 to use the old build system (as it did before) add this flag
> to the xcodebuild args. Some ports need this in both the build and destroot
> args (aquaterm), others pass it in a different way (macvim).
>
> UseNewBuildSystem=
On Oct 4, 2018, at 09:24, Mark Brethen wrote:
> I’m not sure how to handle this build setup: in the top directory there is a
> makefile but the configure files are in a subdirectory “src”. The makefile
> handles it thusly,
>
> all:
> cd src; \
> autoconf; \
> autoheader
>
On Oct 4, 2018, at 11:55, Mark Brethen wrote:
> There’s just one glitch, the name of the build directory is determined by
>
> BUILD = $(shell ../../scripts/findhost.sh $(shell src/config.guess))
>
> I can set it after the extract phase like so
>
> post-extract {
> set builddir [exec ${works
On Oct 4, 2018, at 11:57, Ryan Schmidt wrote:
> On Oct 4, 2018, at 11:55, Mark Brethen wrote:
>
>> There’s just one glitch, the name of the build directory is determined by
>>
>> BUILD = $(shell ../../scripts/findhost.sh $(shell src/config.guess))
>>
>>
On Oct 4, 2018, at 12:05, Mark Brethen wrote:
> On Oct 4, 2018, at 11:57 AM, Ryan Schmidt wrote:
>
>> On Oct 4, 2018, at 11:55, Mark Brethen wrote:
>>
>>> There’s just one glitch, the name of the build directory is determined by
>>>
>>> BUILD =
On Oct 4, 2018, at 12:24, Mark Brethen wrote:
>
> I only need to set it during build and destroot. How about setting the
> variable in the pre-build and pre-destroot phases?
If that's easier, yes, you can do that.
Is there a simple command one can use at the command line to determine the
MacPorts prefix?
`port prefix` came to mind as a logical thing to try, but it does not work.
On Oct 4, 2018, at 21:07, Mark Brethen wrote:
> This worked:
>
>use_autoreconf yes
>autoreconf.dir ${worksrcpath}/generic/libreduce/src
>
>pre-configure {
>set builddir [exec ${worksrcpath}/scripts/findhost.sh [exec
> ${worksrcpath}/config.guess]]
>set redbin
> $
On Oct 5, 2018, at 15:41, Mark Brethen wrote:
> running the lrtest binary fails:
>
> brethen-air:examples marbre$ ./lrtest
> dyld: Library not loaded: libreduce.so
> Referenced from:
> /opt/local/share/libreduce/x86_64-mac_10.12_sierra-darwin16.7.0/examples/./lrtest
> Reason: image not fo
201 - 300 of 1750 matches
Mail list logo
