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, at 14:37, David B. E

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

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 sup

Re: Blacklisting gcc

On 2018-03-27, at 2:40 PM, Chris Jones wrote: >> >> But I would instead propose that MacPorts never puts forward a compiler that >> can't handle c++14 at this point in time instead. > > Agreed, but what about c++17 ? And then the next standard, and so on. This is > an issue that isn’t going to

Port trees for specific versions of MacOS

In Rene mentions the idea of generating port tree overlays for specific versions of MacOS, to preserve compatible versions of ports which have moved beyond the capabilities of that OS. I'd just like to mention that I've been working on this on

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

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 v

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 won't know. I don’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 Miklavec wrote: >> I just

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 tested it yet) which might

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 build...@macports.org, port > net/m

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 clang in portconfigur

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 t

Re: Releasing 2.4.3

On 2018-04-10, at 11:47 AM, Rainer Müller wrote: >> >> I don't want to release 2.4.3 with the libstdc++ ABI issue unanswered. I >> believe it will cause problems. > > Then we should revert this change for 2.4.3 and we have one more reason > to go for a 2.4.4 release. > > Rainer I would have

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 runtime

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, a

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 port

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

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 >> >> >> commit 084e2e8809af

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 t

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 following

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

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 be

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 -> libcfitsio.6.3.44.dy

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 > people they should feel

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 "workn

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 switc

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 months

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: 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 yourself K

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: 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 } { configure.cppflags-a

Re: Ports still using protobuf-cpp

hu, 26 Apr 2018 09:18:47 -0700 Ken Cunningham > 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" discussion that you > had said

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: 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: Strange behaviour of trace mode in MacPorts 2.4.3 / 10.13

But I knew I lost this one before I even sent the email. :> K > On Apr 29, 2018, at 6:59 PM, Ryan Schmidt wrote: > > > On Apr 29, 2018, at 20:53, Ken Cunningham wrote: > >> We should probably just make pkg-config a default dependency for _every_ >> build an

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 anc

Re: Instructions for creating patches

> On May 4, 2018, at 3:33 PM, Rainer Müller wrote: > > > Maybe the instructions on how to create a local ports tree should come > first and then the next section should show how to create a diff against > the official ports tree? > > Instructions on how to create a pull request would overlap

Re: Instructions for creating patches

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 > > > > > On Sat, May 5, 201

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 versions, something like

Re: [macports-mgr] Question about MacPorts project membership application

vacation autoresponder > On May 13, 2018, at 22:31, Ryan Schmidt wrote: > > >> On May 13, 2018, at 23:55, Joshua Root wrote: >> >>> On 2018-5-14 14:30 , Ryan Schmidt wrote: >>> On May 13, 2018, at 22:39, Joshua Root wrote: Perhaps by recommending the use of return receipt

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

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

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: >> >> >> port file all | xargs grep

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: [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') >> ++

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

On 2018-05-25, at 12:37 PM, Ryan Schmidt wrote: > > I've asked the developers: > > https://github.com/google/protobuf/issues/4683 > Great! The devs previously decided to drop non-c++11 support, so I can guess what they will suggest: https://github.com/google/protobuf/issues/2780 > I gues

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 "broken". > > Fix it by fixin

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 wrote: > >> On May 26, 2018, at 11:15, Ken Cunningham wrote: >> >>> On May

Re: MacPorts 2.5.0-beta1 now available for testing

> 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 better way, but I wait to see... > > I don'

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 to use that. Nobody's > do

Re: MacPorts 2.5.0-beta1 now available for testing

> 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 to > its default value) and which C++ standard library it actually links with. >

understanding gcc's header choices and how to fix them

There have been some improvements to the headers for libgcc to better support the math issues found on 10.5 and 10.6 (the missing llrintf, etc that lead to all the std::math functions being disabled). These missing functions cause a lot of headaches building c++ software on these older systems.

Re: understanding gcc's header choices and how to fix them

> On May 29, 2018, at 11:46 AM, Ryan Schmidt wrote: > > > On May 28, 2018, at 11:49, Joshua Root wrote: > >> On 2018-5-28 13:58 , Ken Cunningham wrote: >> Not 100% certain but I would think this is telling it where to install >> its headers (as opposed to

multiple ports with stdlibc++ mismatches (all on 10.13)...

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++) SuiteSparse is using libstdc++ (this installation is configured to use li

Re: multiple ports with stdlibc++ mismatches (all on 10.13)...

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++) >> gcc6 is using libstdc++ (this installation is configured to use libc++) >> gcc7 is using libstdc++

Re: multiple ports with stdlibc++ mismatches (all on 10.13)...

On 2018-05-31, at 5:53 PM, Joshua Root wrote: > Those that do provide or use C++ libraries need to be fixed to use the > C++ stdlib that they are being told to use. And indeed, that is the exact point of having this test and check ... to find and fix these broken ports. Ken

libjpeg-turbo vs jpeg

I have a new game port done, Endless Sky >. It requires "libjpeg-turbo" rather than “jpeg" and so I came across the mess with the conflict with jpeg:

status of the webkit2-gtk-* ports

Yan12125 and I have been working on the webkit2-gtk-* ports, and now the webkit2-gtk port is at the latest stable release, and the webkit2-gtk-devel port is at the latest development release. This allows the latest and one-from latest versions of epiphany to build and function. However I need

feature request: a method to try a Port build against the buildbot farm BEFORE it is committed to the main macports repository

It would be very helpful to be able to try a Portfile build against the buildbot farm before committing it. We would get lots of info regarding breakage before the damage is done that way. I can see that at present there is no easy method to tweak the system to allow this. Ken

Re: feature request: a method to try a Port build against the buildbot farm BEFORE it is committed to the main macports repository

On 2018-07-08, at 7:59 AM, Rainer Müller wrote: > > There was a lengthy thread on this in April: > https://lists.macports.org/pipermail/macports-dev/2018-April/038023.html > > Rainer I had thought that one was mostly about using GitHub (which does CI on only a couple of systems). I'll go bac

protobuf3-cpp now requires -std=c++11

It appears this latest update to protobuf3-cpp now requires c++11 enabled to build anything. AFAICT, every port that uses protobuf3-cpp (ostinato, libphonenumber-cpp, mosh, etc, etc, etc) will all have to be reworked to kick them into c++11 builds. This requires more than just: PortGroup cxx11

re:ranlib: malformed objects on 10.6

> After upgrading ports on 10.6 (I probably didn't touch the machine since > about May this year) I ran into issue compiling software with clang-5.0 > against libc++: /usr/bin/ranlib: object: .libs/libfoo.a(libfoo_la-bar-file.o) malformed object (unknown load command 2) ar: internal ranlib comman

llvm-7.0 and clang-7.0 on SnowLeopard are working with minor adjustments

With minor modifications to the patches and Portfile, both of these install and appear to be working fine. I'll set up a PR for the minor changes needed. -- Ken $ port -v installed llvm-7.0 The following ports are currently installed: llvm-7.0 @7.0.0rc2_0 (active) platform='darwin 10' archs='x8

viewing code while respecting defines

I don't know if I asked this correctly, and it's not macports-specific, but I don't know where else to ask. Some of the code I'm trying to tweak (llvm-N, webkit2-gtk-N, etc) has a lot of #defines in it to modify code paths for various OS versions. It can get pretty mind-bending to try to follow

final buildbot setup for high sierra?

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 will be prompted to upgrade to XCode 10 by the App Store, and so I suppose

Re: viewing code while respecting defines

Thank you, Perry! I see it’s right there in Xcode — I just never noticed it before. That (at present) is likely about as close as I will get to what I want. Ken > On Sep 18, 2018, at 5:11 AM, Perry E. Metzger wrote: > > On Mon, 10 Sep 2018 12:15:37 -0700 Michael > wrote: >> Is there a way to

Re: final buildbot setup for high sierra?

> 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 > impose those restrictions on High Sierra, and in that case I would probably > wan

Re: final buildbot setup for high sierra?

> On Sep 20, 2018, at 2:07 PM, Ryan Schmidt wrote: > >> So — something is still working right, at least on 10.13 with Xcode 10. > > Yes, but based on the above output, the SDK wasn't used. If the SDK had been > used, a 32-bit build would not have been possible, as far as I understand. > I

Re: final buildbot setup for high sierra?

> On Sep 20, 2018, at 2:07 PM, Ryan Schmidt wrote: > Yes, but based on the above output, the SDK wasn't used. If the SDK had been > used, a 32-bit build would not have been possible, as far as I understand. > You are right, the SDK apparently has no tapi symbols for i386: configure:3118: /u

Re: final buildbot setup for high sierra?

> On Sep 20, 2018, at 3:02 PM, Ken Cunningham > wrote: > > > >> On Sep 20, 2018, at 2:07 PM, Ryan Schmidt wrote: >> Yes, but based on the above output, the SDK wasn't used. If the SDK had been >> used, a 32-bit build would not have been possible, a

new xcode build system and build failures

Xcode 9 introduced a new build system behind the scenes, but it was not the default, so most of us building OSS didn't really notice. Xcode10 has made it the default, and now a number of errors are showing u

Re: new xcode build system and build failures

On 2018-10-01, at 7:00 AM, Ken Cunningham wrote: > To force Xcode10 to use the old build system (as it did before) Pre-coffee correction. Xcode 10 always defaulted to the new build system. Previous Xcode versions used the old build system by default.

Re: new xcode build system and build failures

On 2018-10-01, at 7:53 AM, Ryan Schmidt wrote: > > > 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 >> de

Re: new xcode build system and build failures

> On Oct 1, 2018, at 1:00 PM, Rainer Müller wrote: > > > One of the bugs with most impact seems to be that it always uses the > user home from Directory Service and does not respect $HOME in the > environment. The build system want to place > ~/Library/Developer/Xcode/DerivedData/ there, but

Re: Keep 32-bit build support on Mojave

On 2018-10-01, at 3:50 PM, Joshua Root wrote: > On 2018-9-24 18:22 , Ryan Schmidt wrote: >> https://github.com/ryandesign/macports-base/commits/MacOSX.sdk > > Second, I'm not sure about changing the SDK only some of the time, or > not changing the deployment target. > I'm not sure how much of

thread_local storage on 10.6.8 with clang-7.0

With a couple of very minor modifications, recent versions of clang will support thread_local storage including support for complex destructors on 10.6.8 using the same emutls.c system that gcc uses to support it. I'll attach the (amazingly simple) patches below. It picks up the emutls.c support

Error: Unable to determine location of a macOS SDK.

Brand new installation of High Sierra, installed Xcode from App Store, opened it, installed MacPorts from installer. Then: $ sudo port selfupdate ---> Updating MacPorts base sources using rsync MacPorts base version 2.5.4 installed, MacPorts base version 2.5.4 downloaded. ---> Updating the por

Re: Error: Unable to determine location of a macOS SDK.

> On Oct 6, 2018, at 5:24 PM, Joshua Root wrote: > > This is one of the reasons our installation instructions say to install > both Xcode and the Command Line Tools. But see also > . > > - Josh Exactly. I will admit I am currently trying (myself) to

Re: Commit History vs User Convenience

On 2018-10-08, at 9:31 AM, Chris Jones wrote: > > To be honest, my concern with the above is to get adequate testing, across a > range of macOS versions, rather than nuances around the revisions... So lets > focus energies on that aspect... > > Chris Ah, the lure of the bikeshedding is stron

tenfourfox - should it be in the MacPorts repo?

Older MacOS versions lack browsers that support TLSv1.2, and other enhancements that allow them to work comfortably in the current world. Cameron Kaiser has been dutifully maintaining a fork of Firefox for a decade that works nicely on PPC Macs 10.4 and 10.5, and keeps it remarkably up to date w

Re: tenfourfox - should it be in the MacPorts repo?

On 2018-10-11, at 10:05 AM, Christopher Jones wrote: > Hi, > > Being ’niche’ in itself is no reason to not include something in MacPorts, so > that shouldn’t be a concern. We have plenty of ‘niche’ ports already, which > is partly what makes MacPorts better than the alternatives ;) > > If t

Re: tenfourfox - should it be in the MacPorts repo?

On 2018-10-11, at 10:38 AM, Christopher Jones wrote: > Hi, > > A couple other thoughts… > > What platforms do you see this being useful on ? I know that older platforms, > but newer than 10.4, also have issues with SSL/TLS support. Presumably this > would also be useful on these ? 10.6 ? 10.7

Re: Merging pull requests before 72 hours

On 2018-10-18, at 1:18 PM, Christopher Jones wrote: > > Beyond the above, not really. If it is indeed agreed that some package > version updates are allowed under the ‘minor’ tag, then I think the best you > can do is just state that, and acknowledge that the determination of what is > or is

icu is old

I have another port that I can't update due to a too-old icu (mozjs60). I think we're going to have to find some way to update icu. If we need a non-c++11 version, I guess we'll have to make that as a separate port perhaps. Ken

Re: Merging pull requests before 72 hours

> On Oct 21, 2018, at 10:46 AM, Mojca Miklavec wrote: > > > They currently have 28 issues open for formulas. We have ... > thousands? (Last time I checked it was somewhere between 4k and 5k.) > Disclaimer: I don't know what their policy on closing the issues is. There is a “Stale Bot” that a

github hosed tonight

In case you haven’t noticed, github is hosed tonight. There is info on the github server status page (google “github status”). Ken

icu 63.1 build errors

As we’re pondering the PR to update ICU to what amounts to a new ABI version, and as github is hosed tonight, I thought I would point people to freebsd’s attack on this issue when they braced ICU 61 and the failures they saw in doing so.

Re: Issues with clock_gettime(CLOCK_REALTIME, &wait) pre macOS 10.13

On 2018-10-23, at 1:57 AM, Chris Jones wrote: > Hi, > > I've stumbled into the same issue twice in recent days, with two different > ports, which is the use of > > clock_gettime(CLOCK_REALTIME, &wait); > > which is only available in macOS 10.12 or newer. See for instance the issue I > found

Re: Issues with clock_gettime(CLOCK_REALTIME, &wait) pre macOS 10.13

On 2018-10-23, at 8:18 AM, Chris Jones wrote: > >> We have worked around this in a number of ports so far, and turned off some >> functionality in others. >> I use the_silver_searcher to find stuff like this, for example in the >> macports-ports repo: >> ag -i clock_gettime . > > Sorry, I do

Re: Issues with clock_gettime(CLOCK_REALTIME, &wait) pre macOS 10.13

Yep, that is exactly what I was thinking as well. I was pondering a specific include folder like ${prefix}/include/snowleopardfixes for want of a better title for it, where these could be placed. Then we could just add that folder to the beginning of the system header search queue. (It would i

Re: Issues with clock_gettime(CLOCK_REALTIME, &wait) pre macOS 10.13

On 2018-10-23, at 4:23 PM, Chris Jones wrote: > > I see no reason to not just place them directly in the main MacPorts include > prefix, i.e. normally /opt/local/include. Placing them anywhere else requires > that specific folder to be included as well, which is a complication I dont > see th

Re: loading checksums table from pre-checksum block?

On 2018-10-27, at 3:52 PM, Ryan Schmidt wrote: > > > On Oct 27, 2018, at 17:37, René J.V. Bertin wrote: > >> No, I do not want to reintegrate the 60-some checksums into the portfile, I >> don't want to split it up and I don't want to rewrite my checksum generator >> script either. My questi

forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

I notice homebrew is forcing the installation of binaries built on their 10.12 or 10.13 builders onto 10.14 to get around the 32bit build problem on 10.14. I don't believe there is any way to force our binary installer to install older system builds in the same way -- but if there was, it would

mojave 32-bit compatible and universal builds

I thought I’d try a 32-bit compatible installation of MacPorts today on Mojave as a proof-of-concept, so I made a new prefix under /opt/universal and set up macports in it. I installed a copy of the MacOSX10.13.sdk and referenced that during the builds. To make it work, I made a couple of mi

Re: mojave 32-bit compatible and universal builds

, which I have to imagine > will eventually. > > —Mark > ___ > Mark E. Anderson > > >> On Sun, Nov 4, 2018 at 9:44 AM Christopher Jones >> wrote: >> >> >> > On 4 Nov 2018, at 1:54 pm, Ryan Schmidt wrote: >> > >> > On N

Re: mojave 32-bit compatible and universal builds

> On Nov 4, 2018, at 6:44 AM, Christopher Jones > wrote: > I don’t get all the effort going into keep 32 bit going for just a little bit > longer, until Apple completely pull the plug, in a future macOS release. > > Chris > It’s because there are a few packages, like wine and some of the e

Re: mojave 32-bit compatible and universal builds

> On Nov 4, 2018, at 5:54 AM, Ryan Schmidt wrote: > I thought we decided we didn't want to pursue that idea, based on Joshua's > objections, and instead we wanted to figure out a way to compile universal > with the 10.14 SDK, maybe by making a universal 10.14 SDK, That’s why I thought I’d ac

Re: mojave 32-bit compatible and universal builds

> On Nov 4, 2018, at 9:07 AM, Ken Cunningham > wrote: > > In the end, the thing that *does* work is to set the -isysroot to > /path/to/MacOSX10.14.sdk and the -syslibroot to / now why would I make that typo? Need another coffee this am I guess. In the end, the thing that *d

Re: mojave 32-bit compatible and universal builds

I think I have this clean enough to present for the curious…here are the (minor) tweaks. put the MacOSX10.13.sdk in the proper location in your active Xcode.app put this in macports.conf macosx_deployment_target 10.13 macosx_sdk_version 10.13 and in portconfigure.tcl change l

portconfigure.tcl - why does appending to an ENV variable (like CFLAGS) not also append to configure.cflags ?

I noticed this recently "fixing" some ports that don't use a configure step. During the run of portconfigure.tcl, various things (sdkroot) might be tested, and the appropriate values appended to the ENV variables. But these things don't seem to come out in the configure.variables, like I would

  1   2   3   4   5   6   7   8   9   >