Re: MacPorts 2.5.0-beta1 now available for testing

> On May 26, 2018, at 9:40 AM, Ryan Schmidt wrote: > > Unfortunately, we have no way to tell Xcode to use one of our compilers. I > believe we need to create some kind of Xcode-specific file to tell it about > each of our compilers, then update the xcode portgroup

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 26, 2018, at 9:49 AM, Ryan Schmidt <ryandes...@macports.org> 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 better way, but I wait to see..

Re: MacPorts 2.5.0-beta1 now available for testing

Well I think you did the cmake finaggeling last time Not sure you could find a better way, but I wait to see... K Sent from my iPhone > On May 26, 2018, at 9:40 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > >> On May 26, 2018, at 11:15, Ken Cunningham wrote: >&

Re: MacPorts 2.5.0-beta1 now available for testing

> 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 > versions of MacPorts did not check for this kind of

Re: [macports-ports] branch master updated: py-protobuf3: fix build on older systems

On 2018-05-25, at 8:38 AM, Ryan Schmidt wrote: > > On May 24, 2018, at 23:15, Ken wrote: > > > If this is supposed to help 10.6... > > >> +@@ -197,6 +197,8 @@ >> + v = float('.'.join(v.split('.')[:2])) >> + if v >= 10.12: >> + extra_compile_args.append('-std=c++11') >>

please take a second to check out this versioning plan for the devel versions of LibreCAD

Is this the smartest way to version these, or is there a better method to use? Thx, Ken

Re: regex for finding all ports using the cxx11 1.0 PG and changing them en-masse to the cxx11 1.1 PG

Thanks for that, guys. > On May 18, 2018, at 2:18 PM, Marius Schamschula >> wrote: >> >> Drat. Autocorrect strikes again. The regex should be: >> >> >>

regex for finding all ports using the cxx11 1.0 PG and changing them en-masse to the cxx11 1.1 PG

It seems that there is no reason for a port to still be in the cxx11 1.0 PG. I stumble across them from time to time still. Do any of the regex-masters have an easy way to find all the cxx11 1.0 PG entries and change them all to 1.1 PG? Thanks, Ken

gcc5 potential fix

If anyone else can test > and see if it works for them as well, we can commit this fix for gcc5. Ken

Re: Qt5 port group

> On May 10, 2018, at 5:44 PM, Marcus Calhoun-Lopez > wrote: > I am certainly open to suggestions to how to improve the situation. > The only thing that comes to mind is having qt ports be able select a qt version variant that is mutually exclusive to the other qt

Re: Instructions for creating patches

copy, there is only one repo. > > unless they have credentials, they will not be able to push changes > back to the master/origin even if they choose not to branch and work > on master > > it should say something like build your branch Portfile, port lint > blah blah blah

Re: Request for discussion: lowering the backlog of old Trac tickets.

At one point about two years ago I also suggested closing all tickets more than about six months old, for the exact same reasons. So I'm on board. There _is_ a vast storehouse of practical information in MacPorts trac. Whenever I get a build error I go there first, often before Google. But

Re: Strange behaviour of trace mode in MacPorts 2.4.3 / 10.13

It’s almost _always_ pkg-config that is responsible for these wacky errors. That has bit me dozens of times, including a week ago. Wasted hours. We should probably just make pkg-config a default dependency for _every_ build and save everyone a pile of heartburn. Ken > On Apr 29, 2018, at

Re: Gsoc 18 Project | Collect build statistics

> On Apr 28, 2018, at 5:06 PM, Vishnu wrote: > > am i supposed to install port tclsh ? > > There's no port named tclsh. > you should have it /opt/local/bin/port-tclsh but your path is probably calling /usr/bin/tclsh Ken

Re: Ports still using protobuf-cpp

hu, 26 Apr 2018 09:18:47 -0700 Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: >> On 10.6.8, this has broken all the ports that used protobuf-cpp, as >> predicted, due to the thread_local thing. > > Ah, I'd misinterpreted. I thought in the "mosh" discu

Re: Ports still using protobuf-cpp

On 10.6.8, this has broken all the ports that used protobuf-cpp, as predicted, due to the thread_local thing. Normal ports can be fixed up by adding this (eg mosh): # force protobuf3-cpp into the no_threadlocal mode if { ${os.platform} eq "darwin" && ${os.major} < 11 } {

Re: Binary packages not rebuilding against updated libraries

On 2018-04-26, at 8:09 AM, Joshua Root wrote: > Detecting this situation and rebuilding locally is automatic. Actually > increasing the revision of the dependents so updated archives are made > available is not. There's next years GSOC project for you :> Ken

Re: Binary packages not rebuilding against updated libraries

> On Apr 25, 2018, at 22:48, Jan Stary wrote: > > The packages that were installed before get rebuilt > with port rev-upgrade, automatically, > without anyone touching their Portfile. Well the idea is that download a prebuilt packaged binary, not revupgrade and build them all

Re: How do I check what is autobuilding successfully?

On 2018-04-25, at 11:58 AM, Perry E. Metzger wrote: > There's a port I suspect hasn't built in a long while. How can I > check on what is and isn't building on the buildbots? > > -- > Perry E. Metzger pmetz...@macports.org check packages.macports.org and see if it's there and if

Re: Agility

On 2018-04-25, at 11:02 AM, Chris Jones wrote: > > That, frankly, would be absurb. > > Chris Absurd might be strong. It depends on the stage of your work. A nearly completed patch that needs a few tweaks is one thing. A PR list full of [WIP] PRs that have gone nowhere for six or twelve

Re: What "openmaintainer" means

On 2018-04-25, at 10:13 AM, Mojca Miklavec wrote: > And if there's a need, we could of course define more levels of "how > closed" a port should be. This is another case where for a lot of > software updates are usually trivial, while for others it may break > your system (say, when software

Re: Agility

On 2018-04-25, at 9:23 AM, Chris Jones wrote: > >> I have one request though. You are sometimes asking people to close >> the PRs because you don't want unfinished PRs in the queue. I would >> like to suggest adding a special label to such PRs before closing >> them, saying something like

Re: [macports-ports] branch master updated: collectd: update to 5.8.0

> On Apr 24, 2018, at 10:41 AM, Perry E. Metzger wrote: > >> I wouldn't consider version updates to be a minor change permitted >> by openmaintainer. All too often they are not in fact "simple". > > I do, in fact, consider it that way, and I need some way of telling >

Re: Binary packages not rebuilding against updated libraries

On 2018-04-24, at 9:05 AM, Artur Szostak wrote: > > So then there is a bug from what I understand, or cfitsio in MacPorts is > being built incorrectly. Compare file names for the newer Cfitsio: > /opt/local/lib/libcfitsio.6.3.44.dylib > /opt/local/lib/libcfitsio.6.dylib ->

disable-dependency-tracking issue all of a sudden?

Several gnome ports seem to be failing to update with a similar error all of a sudden: config.status: error: Something went wrong bootstrapping makefile fragments for automatic dependency tracking. Try re-running configure with the '--disable-dependency-tracking' option to at least

Re: [macports-ports] 01/01: icu: update to 61.1

On 2018-04-23, at 9:46 AM, Leonardo Brondani Schenkel wrote: > On 2018-04-23 18:07, Ryan Schmidt wrote: >> I've been meaning to revisit updating icu, now that we have the cxx11 1.1 >> portgroup. Let me know what you discover! > > I meant to push this to a branch on my fork, ended up pushing to

Re: [macports-ports] branch master updated: nzbget: add cxx11 1.1 PG

On 2018-04-16, at 10:55 PM, Ryan Schmidt wrote: > > On Apr 17, 2018, at 00:43, Ken wrote: > >> Ken (kencu) pushed a commit to branch master >> in repository macports-ports. >> >> >> https://github.com/macports/macports-ports/commit/8f64c49b083ab312882b2f7c3b45658a49a37397 >> >> The

Re: [macports-ports] branch master updated: gcc7 / libgcc: fix build on Intel Tiger

On 2018-04-16, at 4:29 PM, Ryan Schmidt wrote: > > > Do these ports build for you on PowerPC Tiger? They didn't for me, last time > I checked a month or two ago. Yes, both gcc6 / libgcc6 and gcc7 / libgcc7 build fine without these patches on PPC Tiger. I haven't had any troubles with any of

Re: [macports-ports] branch master updated: gcc7 / libgcc: fix build on Intel Tiger

gt;> https://github.com/macports/macports-ports/commit/084e2e8809afc62472eafc9c098b4bc9249b48b0 >> >> The following commit(s) were added to refs/heads/master by this push: >> >> new 084e2e8 gcc7 / libgcc: fix build on Intel Tiger >> >> 084e2e8 is described below >> >&g

gcc6, libgcc, and the ABI issue reprised

There is expressed concern about the improvements to portconfigure.tcl to put forth gcc6 for PPC instead of clang-3.4 (which always fails) when the default compilers were blacklisted. I don't see there being such a concern. I'd hope to put some of this to rest with a few examples. 1. the

Re: CI system for PR builds

I've taken some of them on, including the oldest one (From Ryan, of all people) for a game called enigma from a submission 10 years ago. I advise you to be very careful with them, based on the ones I've seen. Lots of them are not of high quality, build wrongly or against the wrong libraries,

Re: Releasing 2.4.3

On 2018-04-10, at 12:02 PM, Ryan Schmidt wrote: > > On Apr 10, 2018, at 13:55, Ken Cunningham wrote: > Mixing libc++ and libstdc++ results in a link failure. Mixing old libstdc++ > and new libstdc++ did not previously result in a link failure; it resulted in > a runt

Re: CI system for PR builds

On 2018-04-08, at 6:46 AM, Ryan Schmidt wrote: > Yes, I know you like to build your legacy MacPorts installs with a different > copy of curl. And yes, we have a ticket tracking that issue as well. It's my nature. I just can't understand why people would spend years working around a problem

Re: CI system for PR builds

> On Apr 8, 2018, at 03:49, Rainer Müller wrote: > > We need to stop investing > so much effort into legacy systems. True. Making current software build on ancient compliers is a waste of effort. Finish the plan to push all those systems to libc++, put forward a modern

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

You're not expected to fix it. It would be nice perhaps to make a ticket about it if you like, so someone who uses that OS cersion might dig in. Best, Ken > On Apr 4, 2018, at 07:36, Andrew Moore wrote: > > If I’m reading correctly the attached report from

Re: xcodebuild wants to write to $HOME/Library/Developer (was: Re: Editing Git history with GitUp)

There's a third mulle* port that converts xcode projects into cmake projects that I have used as well. Sent from my iPhone > On Apr 2, 2018, at 10:11 AM, Rainer Müller wrote: > >> On 2018-03-23 11:17, Mojca Miklavec wrote: >> I just stumbled upon this app (I haven't

Re: xcodebuild wants to write to $HOME/Library/Developer (was: Re: Editing Git history with GitUp)

You might check the two mulle* ports I added last year. One lets you dump all the settings in a project, the other lets you set them on the fly in a portfile. K Sent from my iPhone > On Apr 2, 2018, at 10:11 AM, Rainer Müller wrote: > >> On 2018-03-23 11:17, Mojca

Re: Port trees for specific versions of MacOS

> On Mar 31, 2018, at 8:08 AM, Mojca Miklavec wrote: > A few problems I see with this approach: > (a) What happens when a dependency of one of those ports is changed. > Unless you have some CI system in place for this to tell you that a > port needs a revbump at least, you

Re: Port trees for specific versions of MacOS

On 2018-03-28, at 10:04 AM, René J.V. Bertin wrote: > > I'm not sure I follow nor that I agree with what I think I understand. If > pegged ports are ports no longer supported (in that form/version) on the main > tree, why would they have to follow what the main tree does with their > current

Re: Port trees for specific versions of MacOS

On 2018-03-28, at 9:20 AM, René J.V. Bertin wrote: > On Wednesday March 28 2018 09:00:52 Ken Cunningham wrote: > > Thanks for picking this up, > >> I'd just like to mention that I've been working on this on my own for a >> while now, and have such trees

Re: Blacklisting gcc

On 2018-03-27, at 7:43 AM, Benjamin Redelings wrote: > I suppose there could be a c++14 portgroup? There could be. But I would instead propose that MacPorts never puts forward a compiler that can't handle c++14 at this point in time instead. If the system-installed clang is new enough to

Re: how to handle this element in Makefile.config ?

On 2018-03-26, at 11:03 AM, macpo...@parvis.nl wrote: >> Try setting the variable in build.args instead: >> >> build.args-append JCVALID=no >> >> Rainer > > no effect sounds like patches are your friend, then, if you can't override it with settings. K

Re: Blacklisting gcc

I think blacklisting *gcc-4* would achieve the desired goal. gcc-3.x is no longer a compiler macports puts forward for use, so can be ignored now. K > On Mar 26, 2018, at 01:25, Mojca Miklavec wrote: > >> On 26 March 2018 at 02:49, Ryan Schmidt wrote: >>> On Mar 25, 2018,

Re: Request for assistance closing some old pull requests

> > There's no good way to shim the ABI without having something > physically deal with this problem, which likely requires a lot of > work on very low level hacking. When last I read about this, the Wine devs were asking for compiler support in clang to accomplish this feat. I bet they will

Re: Changing default cxx_stdlib to libc++

> On Mar 11, 2018, at 06:06, db wrote: > >> On 11 Mar 2018, at 02:47, "Kenneth F. Cunningham" >> wrote: >>> On 2018-03-10, at 12:23 PM, db wrote: >>> Except for building from source for minor versions and revbumps, especially >>> large

Re: Changing default cxx_stdlib to libc++

> On Mar 9, 2018, at 06:18, Joshua Root wrote: > > We may have to create some bootstrap versions of toolchain ports in > order to achieve this, so that they can be automatically installed as > dependencies with no manual intervention. Maybe we could just force clang 3.4 to

Re: Changing default cxx_stdlib to libc++

On 2018-03-08, at 4:27 PM, Ryan Schmidt wrote: > How will users upgrade from libstdc++ to libc++? What subset of the > instructions on the LibcxxOnOlderSystems page would they have to follow? What > if they don't do that and stay on libstdc++? We do have to ponder the bootstrap toolchain

Re: Changing default cxx_stdlib to libc++

Thank God. 10.6.8, agree. I use clang 3.9 as a good balance between capability and compatability, but might as well sort out how to use clang 5 as that is more consistent w older systems, and I nearly have thread_local working there on 10.6 Ken Sent from my iPhone > On Mar 8, 2018, at

Re: [macports-ports] branch master updated: atf: update to 0.21

> On Mar 8, 2018, at 08:21, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On Mar 8, 2018, at 10:13, Ken Cunningham wrote: >> >>> On Mar 7, 2018, at 11:56 PM, Ryan Schmidt wrote: >>> >>>> On Mar 2, 2018, at 01:58, Ken

Re: [macports-ports] branch master updated: atf: update to 0.21

> On Mar 7, 2018, at 11:56 PM, Ryan Schmidt wrote: > > > On Mar 2, 2018, at 01:58, Ken wrote: > >> +github.setupjmmv atf 0.21 >> + >> +# github.tarball_from downloads or releases does not set the mastersite >> correctly >> +master_sites >>

Re: request for port create command, to build a portfile from a URL

On 2018-03-06, at 7:19 AM, Joshua Root wrote: > > There's a fairly basic tool called portfile-gen in contrib. Improvements > are certainly welcome. That is indeed a step towards what I was thinking of. I'll look at this. Ken

Re: request for port create command, to build a portfile from a URL

On 2018-03-06, at 7:22 AM, G Alexander wrote: > I like the auto calculate hashes > > For grabbing something from url sounds like having a lot of switches, > > for archive type and depedencies > I was kinda hoping that the archive type might be figured out from the tail of the URL. All the

request for port create command, to build a portfile from a URL

It would be nice to have a command like port create URL that would download the URL, calc the checksums for it, and build a basic Portfile for it. It could ask for a category to use for the Port. In a more advance version, it could extract the URL and do some quick analysis on it. if

request for port peg command, to lock down a port at the currently installed version

It is fairly common for users to find an update to a port that won't build on their system for some reason. It would be nice to have a simple command, like port peg PORTNAME that stops the port from attempting to update until the peg is released. Such a command does exist in other package

Re: Upgrading Pandoc

Upgrading haskell looks to be super complicated. Best bet is to work with Clement on it if you have skills for that. Otherwise wait until he has time. Best, K Sent from my iPhone > On Mar 4, 2018, at 11:18 AM, Mark Anderson wrote: > > So I started trying to move pandoc from

Re: #55884: mandoc @1.14.3: not using the right compiler

On 2018-03-03, at 1:14 PM, Jan Stary wrote: > > What of I have two of those, with different Xcode on each? That is undesirable for reproducible builds. Most users have the default Xcode version for a give system, as Apple flushes all the updates that way. If users report broken builds and

Re: [MacPorts] #50645: lapack 3.6.0 update from svn instead of the tarball

Looks like the latest released version is 3.8.0 now. http://www.netlib.org/lapack/lapack-3.8.0.tar.gz So the port could be due for an update to that version. Ken On 2018-03-02, at 4:31 PM, G A wrote: > This is an old report. But thats ok I have my own repo of macports with > updated and

Re: buildbot (10.5-10.8) SSL/TLS issues

The only solution at present is a custom build of macports against a new libcurl. Just ignore these failures until distfile mirroring gets fixed. Ken Sent from my iPhone > On Mar 2, 2018, at 4:16 PM, Helmut K. C. Tessarek > wrote: > > I've received a few errors from

Re: [macports-ports] branch master updated: libcaer: new port

> On Mar 1, 2018, at 11:23 AM, Perry E. Metzger wrote: > > Looking over things carefully seems reasonable. A machine can't > figure out that a Portfile should be written differently. > > Having to build locally in several ways seems bad. The purpose of > automatic CI

Re: [macports-ports] branch master updated: libcaer: new port

CI is not sufficient testing to commit, sadly. There is no xcode 9 in travis at present. misses many things, like liscence etc doesn't check if destrooting is right It's OK for a minor version update of an existing port, but all new ports or sig updates need to checked out locally, port lint

elegant deps for a gtk theme?

I have a nice gtk2 / gtk3 theme that mimics sierra. For dependencies, if you are using this theme with gtk2, you need gtk2-murrine installed. gtk3 works as is. There aren't too many port themes to copy ideas from. adwaita

need someone with steely git-fu to resolve a minor conflict in PR #740

I have tried several times to resolve the minor conflict in this PR and I just keep messing it up. It looks super trivial, but ... https://github.com/macports/macports-ports/pull/740 Please, if you do fix it, tell me what you did so I don't have to ask this particular silly question again.

thread_local with clang-5.0 on 10.6 (and lower) -- works , but slight issue with libc++ that I would appreciate some help with.

thread_local is a c++11 feature that newer software is increasingly using. It is available with gcc 4.8+, and with clang since about clang-3.5. On macOS (darwin) it requires system supports that arrived in 10.7. My goal is to get thread_local with clang-5.0 and newer on 10.6 (and 10.5). Turns

Re: Search for a MacPorts Mascot: looking for talented artists

On 2018-02-21, at 12:36 PM, Dave Horsfall wrote: > On Wed, 21 Feb 2018, Mojca Miklavec wrote: > >> During the GSOC meeting in Mountain View we had some fruitful evening >> discussions where we were heavily criticised for not having our own happy >> fluffy animal mascot (like a flying

Re: [macports-ports] 01/02: pugixml: update to v1.8.1

On 2018-02-13, at 4:54 AM, Ryan Schmidt wrote: >> >> -github.setupzeux pugixml 1.7 v >> -github.tarball_from releases >> +github.setupzeux pugixml 1.8.1 v > > Why no longer use the release download? If a developer goes to the effort of > providing a release download, we should

system -notty what is it for?

I noted here https://github.com/macports/macports-base/blob/master/src/pextlib1.0/system.c an option for system called “-notty” Searching macports-ports seems to show no ports use this. What would that option be

Re: cxx11 portgroup: C++11, C++14, C++17

> On Feb 4, 2018, at 9:36 PM, Ryan Schmidt wrote: > > We should think about how this will work if and when it is integrated into > MacPorts base and not a portgroup. I think starting with configure.cc_std and > configure.cxx_std might work well. > I’m trying to

Re: cxx11 portgroup: C++11, C++14, C++17

Somewhere in the tickets Marcus has this at least 1/2 done... K Sent from my iPhone > On Feb 4, 2018, at 7:14 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On Feb 4, 2018, at 18:09, Ken Cunningham wrote: >> >>> On Feb 4, 2018, at 7:03 PM, Ry

Re: cxx11 portgroup: C++11, C++14, C++17

Please not more portgroups, tho. How about we just move up that clang floor as time goes by? K Sent from my iPhone > On Feb 4, 2018, at 7:03 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > >> On Feb 4, 2018, at 18:01, Ken Cunningham wrote: >> >>>

Re: cxx11 portgroup: C++11, C++14, C++17

By providing a current clang, like 5.0, all these are covered I believe. The PG is really misnamedshould be "modern compiler" PG or similar. K Sent from my iPhone > On Feb 4, 2018, at 6:56 PM, Ryan Schmidt wrote: > > The cxx11 portgroup is fine for C++11, but

cxx11 1.0 PG -> mass change to cxx11 1.1 ?

I think it's time to consider a mass change of any ports that remain on the old cxx11 1.0 PG to the new cxx11 1.1 PG. Any thoughts? Ken

Re: [macports-ports] branch master updated: apiextractor: mark obsolete

Thanks Frank! Best, K On 2018-01-29, at 10:59 AM, wrote: > Hi Ken, > > > Please follow the guidelines for obsoleting a port: > > https://guide.macports.org/#development.obsolete-portgroup > > You have not specified the replacement port and have too many lines in >

Re: Redistributable binaries for 10.5 or 10.6 from C++11 sources

On 2018-01-14, at 12:33 PM, Mojca Miklavec wrote: > On 13 January 2018 at 18:03, Ken Cunningham wrote: >> I know it can be done. TenFourFox does it. It builds with Macports >> infrastructure, required parts to support c++11 are moved into the >> application bundle,

something is wrong with www.macports.org webpage

hacked? misconfigures?

Re: Redistributable binaries for 10.5 or 10.6 from C++11 sources

I know it can be done. TenFourFox does it. It builds with Macports infrastructure, required parts to support c++11 are moved into the application bundle, and there are scripts that appear to update the install names as you describe. There is a description in the "building tenfourfox" page.

Re: a no-homepage homepage for ports with dead homepages

On 2018-01-12, at 2:12 AM, Rainer Müller wrote: > > Nit pick: I would have called it NoHomepage (small letter p), as the > compound form seems to be more common than two words and it is used this > way as Portfile option and in the wiki page itself. Done. I always seem to want to CamelCase

Re: a no-homepage homepage for ports with dead homepages

On 2018-01-11, at 9:37 AM, Ken Cunningham wrote: > > But if I can find a saved one at archive.org, that would be better, to be > sure. > > K I've been prospecting MacPorts errors reported by repology <https://repology.org/maintainer/nomaintainer%40macports.org/problems

Re: a no-homepage homepage for ports with dead homepages

On 2018-01-11, at 9:30 AM, Jan Stary wrote: > > Voila, that's its homepage then. > Well now we're back to where I started :> But if I can find a saved one at archive.org, that would be better, to be sure. K

Re: Python 2.7 – allow another db version beside 4.8

On 2018-01-11, at 12:28 AM, Jan Stary wrote: > > > Does anyone now? If my port requires (say) python (any python), > what is the right way to say that? (In some cases, having > /usr/bin/python is just fine.) > MacPorts tries to undertake the principle of reproducible builds

Re: port "gohome" --> "A keychain cannot be found."

> On Jan 2, 2018, at 3:01 PM, Frank Schima wrote: > > > I can completely reproduce this. I think this must be a base bug because the > open command works by itself. I have never seen this before because I always > have Safari running on my computers. > > Ken, would you

Re: port "gohome" --> "A keychain cannot be found."

> On Jan 2, 2018, at 1:14 PM, Rainer Müller <rai...@macports.org> wrote: > > On 01/02/2018 08:52 PM, Ken Cunningham wrote: >> Often, but oddly not always, when I try to use >> >> port gohome PORTNAME >> >> it opens Safari but then brings up

port "gohome" --> "A keychain cannot be found."

Often, but oddly not always, when I try to use port gohome PORTNAME it opens Safari but then brings up a modal dialog box with the above message, requiring Safari to be force-quit. If you click the option button “Reset To Defaults” it offers to erase all your Safari passwords, etc. I haven’t

Re: compiler selection on PPC

On 2017-12-06, at 12:19 PM, Ken Cunningham wrote: > There have been a number of tickets over the past two years that relate to > compiler selection on PPC systems. > > Basically, on PPC, if the default compiler (gcc 4.2 on 10.5, or apple-gcc42 > on Tiger) does not work

Re: [macports-ports] 01/02: meson-1.0: new PortGroup

> On Dec 30, 2017, at 11:52 PM, Ryan Schmidt wrote: > >> +# Meson's install_name currently seems to be broken, so workarounds might >> be needed to make ports actually work. >> +# See: https://github.com/mesonbuild/meson/issues/2121 > > Yeah something is going to

Re: set merger_configure_env question

> On Dec 30, 2017, at 11:00 AM, Marcus Calhoun-Lopez <mcalh...@macports.org> > wrote: > > On Sat, Dec 30, 2017 at 11:36 AM, Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: >> configure.env-append libIDL_cv_long_long_format=ll > I would respectfully

Re: set merger_configure_env question

> On Dec 30, 2017, at 9:20 AM, Marcus Calhoun-Lopez > wrote: > >> # Required when cross-compiling. >> foreach arch ${configure.universal_archs} { >>lappend merger_configure_env(${arch}) libIDL_cv_long_long_format=ll >> } Turns out none of these shenanigans are

set merger_configure_env question

Trying to build libidl+universal on 10.5 fails. I’m set up to build it universal, with universal_archs as i386 and x86_64. It uses the muniversal portgroup, which I don’t know tons about. It fails because an environment variable doesn’t get set properly during the x86_64 build: checking for

Re: [macports-ports] branch master updated: supertuxkart: allow build on 10.7 and 10.8

On 2017-12-25, at 6:07 PM, Ryan Schmidt wrote: > > This doesn't match now. The error message says it needs 10.7 or later, but > the port allows installation on 10.6 or later. Which is it? > > If it builds on 10.6, does it need the 10.7 SDK to do so? If so, the port > should enforce that. See

Re: use_autogen

can you add environment variables to "use_autoconf"? some of these autogen.sh scripts automatically run configure if you don't set one. K > On Dec 23, 2017, at 7:38 AM, Ryan Schmidt wrote: > > Should we add a "use_autogen" (or "use_autogen_sh") option to MacPorts

Re: Question about meson and boost libraries

On 2017-12-22, at 11:51 AM, Mojca Miklavec wrote: > > meson recently changed something in that respect, but I don't fully > understand how that rpath-stuff works, so something needs to be fixed > in either case). It takes a moment to grok it. Here is a 1 minute summary of all you need to know

Re: Question about meson and boost libraries

On 2017-12-22, at 10:14 AM, Benjamin Redelings wrote: > Hi, > > I'm new to macports. I'm the author or the bali-phy software, and I'm > working on updating the ancient Portfile for it. The software has changed a > lot since someone wrote the original Portfile years ago, and I was

Re: Addressing Port submission failures on Travis

> On Dec 20, 2017, at 1:04 AM, Mojca Miklavec <mo...@macports.org> wrote: > >> On 20 December 2017 at 09:04, Ken Cunningham wrote: >> keep the master branch up to date, but leave your PR branch alone until it's >> merged, then delete the branch. > > Indeed,

Re: Addressing Port submission failures on Travis

keep the master branch up to date, but leave your PR branch alone until it's merged, then delete the branch. > On Dec 19, 2017, at 11:54 PM, Andrew L. Moore wrote: > > I’m thinking that rebasing against my GitHub fork of MacPorts is what sent my > pull request into a tail

Re: I did something stupid and now can't uninstall a port

n 12/19/2017 08:24 PM, Ken Cunningham wrote: >> I have a port I'm working on, with a gui subport: >> >> sheepshaver >> sheepshaver-gui >> >> I accidentally made a typo installing the subport, and I typed this: >> >> sudo port -v install

I did something stupid and now can't uninstall a port

I have a port I'm working on, with a gui subport: sheepshaver sheepshaver-gui I accidentally made a typo installing the subport, and I typed this: sudo port -v install subport=sheepshaver=gui now I have a port installed like this: $ port -v installed | grep sheep sheepshaver=gui

Re: Installing a Python wheel (whl) file using a port - Tensorflow

https://github.com/Homebrew/homebrew-core/blob/master/Formula/libtensorflow.rb On 2017-12-18, at 2:09 PM, Enrico Maria Crisostomo wrote: > Thanks Ken. > > Actually I checked brew and they haven't got a formula for TensorFlow (at > least at the moment). > > On 18 December 2017 at 22:57:42,

Re: Installing a Python wheel (whl) file using a port - Tensorflow

FYI, I recall homebrew has tensorflow, so you might get some hints looking at their formula. Marius was taking this on a few months ago as well, so might have some thoughts. Ken On 2017-12-18, at 1:52 PM, Enrico Maria Crisostomo wrote: > Hi, > > I’m trying to create a port for TensorFlow

Re: trace mode fails with sh: /usr/bin/tar: No such file or directory

> On Dec 17, 2017, at 12:52 PM, Joshua Root <j...@macports.org> wrote: > > On 2017-12-18 07:18 , Ken Cunningham wrote: >> I haven’t been able to use trace mode to test port installs because of >> the following error. Am I doing something wrong? > > Aside fro

trace mode fails with sh: /usr/bin/tar: No such file or directory

I haven’t been able to use trace mode to test port installs because of the following error. Am I doing something wrong? $ sudo port -vst install poco ---> Fetching distfiles for poco ---> poco-1.6.0-all.tar.bz2 does not exist in /opt/local/var/macports/distfiles/poco ---> Attempting to

Re: compiler selection on PPC

> On Dec 17, 2017, at 12:02 AM, Jeremy Huddleston Sequoia <jerem...@apple.com> > wrote: > > > >> On Dec 6, 2017, at 20:09, Ken Cunningham <ken.cunningham.web...@gmail.com> >> wrote: >> >> >>> On 2017-12-06, at 12:19 PM, Ken Cu

<    1   2   3   4   5   6   7   8   >