Re: Using newer SDK on older macOS

Hi, It could be the linker version(ld) is also too old in this case. If you are using the system provided one try with a newer one. Chris On 03/12/2024 4:45 pm, Ryan Carsten Schmidt wrote: I'm trying to make a port (Aseprite) use the newer macOS 10.13 SDK on older macOS versions like 10.9,

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

So the very first thing that someone should do is fix these three ports libgcc8 libgcc10 libgcc11 See https://github.com/macports/macports-ports/commit/eea28397c811c477a04407cbe3c105c76efd9219 https://github.com/macports/macports-ports/commit/06e249f837f36a877ea5dc0dd67d7b0caf964c40 ( Not

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

On 21/11/2024 3:34 pm, Chris Jones via macports-dev wrote: likewise, if I look at the compilers PG https://github.com/macports/macports-ports/blob/master/_resources/ port1.0/group/compilers-1.0.tcl the list there is also already restricted to   lappend gcc_versions 5 6 7 8 9 if I am

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

likewise, if I look at the compilers PG https://github.com/macports/macports-ports/blob/master/_resources/ port1.0/group/compilers-1.0.tcl the list there is also already restricted to  lappend gcc_versions 5 6 7 8 9 if I am parsing things correctly. So, where exactly are the gcc compile

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

On 21/11/2024 3:11 pm, Chris Jones via macports-dev wrote: On 21/11/2024 3:02 pm, Ken Cunningham wrote: On 2024-11-21, at 6:56 AM, Chris Jones wrote: On 21/11/2024 2:49 pm, Ken Cunningham wrote: On Nov 21, 2024, at 6:44 AM, Chris Jones wrote: On 21/11/2024 2:44 pm, Ken

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

On 21/11/2024 3:02 pm, Ken Cunningham wrote: On 2024-11-21, at 6:56 AM, Chris Jones wrote: On 21/11/2024 2:49 pm, Ken Cunningham wrote: On Nov 21, 2024, at 6:44 AM, Chris Jones wrote: On 21/11/2024 2:44 pm, Ken Cunningham wrote: On Nov 21, 2024, at 1:29 AM, Chris Jones via macports

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

On 21/11/2024 2:49 pm, Ken Cunningham wrote: On Nov 21, 2024, at 6:44 AM, Chris Jones wrote: On 21/11/2024 2:44 pm, Ken Cunningham wrote: On Nov 21, 2024, at 1:29 AM, Chris Jones via macports-dev wrote: OOTH: If gcc10 is available and installed, why would you want to call in a

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

On 21/11/2024 2:44 pm, Ken Cunningham wrote: On Nov 21, 2024, at 1:29 AM, Chris Jones via macports-dev wrote: OOTH: If gcc10 is available and installed, why would you want to call in a full build of gcc13 unnecessarily to build the port? If you are suggesting the builds should

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

OOTH: If gcc10 is available and installed, why would you want to call in a full build of gcc13 unnecessarily to build the port? If you are suggesting the builds should check to see what the user has installed and pick a compiler based on that, then no, absolutely not. That is just introduc

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

needed for a long time (until everything is shown to build without it, really, which could take years).KenOn 2024-11-20, at 1:32 PM, Chris Jones wrote:Hi,One other comment.When talking about the dependency tree we have with the gcc builds, it’s important to remember this is only for the runtime ports, libg

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

could discuss removing, but for me the argument to remove the newer ones just does not really exist. Chris > On 20 Nov 2024, at 9:00 pm, Chris Jones wrote: > >  > > >>> On 20 Nov 2024, at 5:56 pm, Ken Cunningham >>> wrote: >>> >>  >> &g

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

> On 20 Nov 2024, at 5:56 pm, Ken Cunningham > wrote: > >  > > current status then is we have a proposal to restrict available compilers on > systems < 10.6 to > > gcc48, gcc5, gcc6, gcc7, gcc10, and gcc14 > > > This list seems workably short. I’ll leave this sit for a while while we se

Re: gcc compilers to be supported by Macports, especially on older MacOS systems

Hi, Personally, I object to the idea of removing (perfectly functional) compiler options from users, the vast majority of which will get them via the binary tarballs and thus the dependency chain is not an issue (the libgccN ports are very light weight, once built) just to cater to the needs

Re: macOS 15 runner is available

Are the runners arm64 or x86_64 ? We have the buildbot for x86_64 macOS15 so enabling runners for that should be OK I would guess. > On 1 Oct 2024, at 4:09 am, Joshua Root wrote: > >  >> >>> On Mon, Sep 30, 2024, at 7:51 PM, Ryan Carsten Schmidt wrote: >>> > On Sep 30, 2024, at 18:47, Mark

Re: Sequoia vs SuiteSparse

I am puzzled as to why SuiteSparse_GraphBLAS drags in clang17 and SuiteSparse_LAGraph drags in both clang16 and clang17 as build dependencies. I don't see anything in the SuiteSparse Portfile showing those dependencies. LLVM 17 is a few versions back, LLVM 18 and 19 are both available, so

Re: Sequoia vs SuiteSparse

I am puzzled as to why SuiteSparse_GraphBLAS drags in clang17 and SuiteSparse_LAGraph drags in both clang16 and clang17 as build dependencies. I don't see anything in the SuiteSparse Portfile showing those dependencies. See this line https://github.com/macports/macports-ports/blob/6220

ports-12_x86_64-watcher out of disk space

Hi, See https://build.macports.org/builders/ports-12_x86_64-watcher error: cannot open '.git/FETCH_HEAD': No space left on device cheers Chris

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

> On 5 Apr 2024, at 7:03 PM, Riccardo Mottola via macports-dev > wrote: > > Hi, > > Ryan Schmidt wrote: >>> I propose to keep even versions, because they are stable ones >> Do you have a source for this claim? It's the first I've heard of it. As far >> as I know, all gcc version numbers a

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

On 05/04/2024 1:45 pm, Ryan Schmidt wrote: On Apr 5, 2024, at 03:52, Riccardo Mottola wrote: I propose to keep even versions, because they are stable ones Do you have a source for this claim? It's the first I've heard of it. As far as I know, all gcc version numbers are stable. They ar

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

Hi, On 05/04/2024 12:30 pm, Ken Cunningham wrote: It’s important you understand how the libgcc ports work now, to see how this libgcc chain is set up and the problems it might cause on slower older systems that have no buildbot. Go to an Intel system like 10.7, uninstall all ports. Disable t

how to handle 'internal' logs for failed builds

Hi, I recently pushed an update to the root6 port. It works fine for me but fails on all build bots, e.g. https://build.macports.org/builders/ports-12_arm64-builder/builds/17/steps/install-port/logs/stdio the only error is this './configure' '--prefix' '/opt/local/var/macports/build/

Re: librsvg, and what MacPorts is for

Hi, I am not sure what you are complaining about. Version 2.56.3, whilst not the absolute latest version a pretty up to date rust based version, is already used on Darwin 10 and newer. Your mail below seems to imply the old C version is used everywhere, which just isn't the case. What am I mis

Re: [MacPorts] #68346: scotch-7.0.4_0+mpich.darwin_23.arm64 configure fails

> On 3 Oct 2023, at 9:32 pm, Murray Eisenberg wrote: > > Then what _are_ useful keywords?? "sonoma"? "arm64" ? what? > > (I'm not trying to be disputatious, just trying to learn!) The full list can be found in the ticket guidelines, you can find linked at the top of https://trac.macpor

Re: Xcode 15.0 on Ventura builders

Hi, For me, I would hold off updating the macOS13 buildbots until the linker issues with Xcode 15 are resolved, as otherwise you are likely to see increased build failures, e.g. with ports that use gcc built binaries. At least at the moment the buildbots are still able to provide binary tarball

Re: Build bot notifications

a while to get to a new commit. Chris -- wbr, Kirill On 23. Aug 2023, at 14:35, Chris Jones <mailto:jon...@hep.phy.cam.ac.uk>> wrote: Hi, I don't know about emails, but you can almost use the ports web page for this. Go to https://ports.macports.org <https://ports.

Re: Build bot notifications

Hi, I don't know about emails, but you can almost use the ports web page for this. Go to https://ports.macports.org Sign in, and then follow the link in your profile to the ports you maintain https://ports.macports.org/accounts/my_ports/github/ There you can get a summary of the latest b

Re: How to rebuild after failed install-dependencies

On 04/08/2023 2:16 pm, Dave Allured - NOAA Affiliate via macports-dev wrote: I am monitoring several ports after a broken dependency was fixed.  I notice that the dependent ports remain broken, and there does not seem to be an automatic trigger to rebuild and update their port health as seen

Re: Clang Clang Clang Went the Buildbots

Hi, On 18/04/2023 1:58 am, Fred Wright wrote: It probably wasn't a good plan to push simultaneous updates to every clang version in sight.  I imagine the buildbots are still struggling to catch up, and meanwhile users doing "upgrade outdated" are stuck doing long builds from source.  My MacB

Re: qt 6.5.0 removes support for macOS 10.14 and macOS 10.15

Hi, Just to add, it would also be useful to know a bit on the reasons for dropping the older OSes, what exactly are the tehcnical reasons for it, as within macports we have a number of build options available to us, like newer builds of the compilers which can be used instead of the Xcode ver

Re: PyTorch CI Build Issue Request for Help

On 23/03/2023 2:13 pm, Joshua Root wrote: On 23/3/2023 23:26, Steven Smith wrote: PyTorch build and runs fine locally, but the CI consistently fails with error below. This issue has created unnecessary delays in merging new PT versions. 2023-03-18T18:24:32.7624930Z CMake Error at third_pa

Re: Location to store Rust binaries

uild and distribute the bootstrap binaries seems to me to well outweigh this small disadvantage. > > -Marcus > >>> On Dec 22, 2022, at 9:28 AM, Chris Jones wrote: >>> >>> >>> >>>> On 22 Dec 2022, at 1:28 pm, mcalh...@macports.org wrote:

Re: Location to store Rust binaries

> On 22 Dec 2022, at 4:38 pm, Chris Jones wrote: > >  > > >>> On 22 Dec 2022, at 4:29 pm, Chris Jones wrote: >>> >>  >> >> >>>> On 22 Dec 2022, at 1:28 pm, mcalh...@macports.org wrote: >>>> >>>  >&

Re: Location to store Rust binaries

> On 22 Dec 2022, at 4:29 pm, Chris Jones wrote: > >  > > >>> On 22 Dec 2022, at 1:28 pm, mcalh...@macports.org wrote: >>> >>  >> Please forgive me if I am misunderstanding your question. >> As Ken pointed out, the rust-bootstrap binarie

Re: Location to store Rust binaries

t; > -Marcus > >>> On Dec 22, 2022, at 2:30 AM, Chris Jones wrote: >>> >>> >>> >>>> On 22 Dec 2022, at 4:02 am, mcalh...@macports.org wrote: >>>> >>>  >>> As many of you know, the Rust compiler is self-hosti

Re: Location to store Rust binaries

> On 22 Dec 2022, at 4:02 am, mcalh...@macports.org wrote: > >  > As many of you know, the Rust compiler is self-hosting, so Rust is required > to build Rust. > The problem is that the Rust binaries provided by upstream only work on macOS > 10.9 and above. > > To get around this, there is a

Re: Xcode (14.0.1) is too old

Xcode 14.1 is indeed the recommended version for macOS13, as its the only one containing the macOS13 SDK (AKAIK). However, Apple apparently hit a few issues with it last minute and thus has not released a public version of it yet, so for now you need to download and install the 14.1 Xcode RC2 (

Re: Selfupdate to MacPorts 2.8.0 Throws Error 'Couldn't change permissions of the MacPorts sources'

 Hi, Already reported. See https://lists.macports.org/pipermail/macports-users/2022-October/051518.html which includes a link to https://trac.macports.org/ticket/66031 Chris > On 22 Oct 2022, at 1:09 pm, Steven Smith wrote: > I’m consistently getting this error across multiple boxes when

Re: MacPorts 2.8.0-beta1 now available for testing

Hi Josh, I've made some progress in understanding the cause of the hang ups I have been having. Its related to the use of a new feature in recent git versions https://github.blog/2022-06-27-highlights-from-git-2-37/#a-builtin-filesystem-monitor-for-windows-and-macos I enabled this feature a

Re: MacPorts 2.8.0-beta1 now available for testing

(or for that matter port selfupdate), > unless my local tree is clean. > >> On Oct 20, 2022, at 10:37 AM, Chris Jones wrote: >> >> Hi >> >> Go to your person checkout >> >> /Users/marius/Development/MacPorts/ports >> >> And then run

Re: MacPorts 2.8.0-beta1 now available for testing

Hi Go to your person checkout /Users/marius/Development/MacPorts/ports And then run /opt/local/bin/git pull --rebase --autostash You will I bet see the same issue, so the problem is nothing to do with macports but your local checkout. Chris > On 20 Oct 2022, at 3:22 pm, Marius Schamschula

Re: ports.macports.org gives strange port dependencies

> On 26 Sep 2022, at 7:35 pm, Arjun Salyan wrote: > >  > >> On 26-Sep-2022, at 3:06 AM, Chris Jones wrote: >> >> Its always been a limitation of the site that it can only report the deps >> for a single platform, but its a bit of a shame that plat

Re: ports.macports.org gives strange port dependencies

> On 26 Sep 2022, at 7:35 pm, Arjun Salyan wrote: > >  > >> On 26-Sep-2022, at 3:06 AM, Chris Jones wrote: >> >> Its always been a limitation of the site that it can only report the deps >> for a single platform, but its a bit of a shame that plat

Re: ports.macports.org gives strange port dependencies

> On 25 Sep 2022, at 10:27 pm, Joshua Root wrote: > > On 2022-9-25 01:13 , Christopher Jones wrote: On 24 Sep 2022, at 3:52 pm, Arjun Salyan >>> > wrote: >>> >>> The output of "port info pciids” from the same Docker container says: >> Can you please run >> > p

Re: ports.macports.org gives strange port dependencies

> On 24 Sep 2022, at 9:52 am, Mojca Miklavec > wrote: > > On Sat, 24 Sept 2022 at 10:30, Chris Jones wrote: >> >> Hi, >> >> I have noticed the ports web site appears to give some odd looking >> dependencies between ports. Take as a random exam

ports.macports.org gives strange port dependencies

Hi, I have noticed the ports web site appears to give some odd looking dependencies between ports. Take as a random example https://ports.macports.org/port/pciids/details/ clang-15 is listed as a build dep. if you check the port file though I see no reason for this at all, in fact the port doe

Re: what's with the C++ extension?

> On 19 Sep 2022, at 6:12 pm, René J.V. Bertin wrote: > > never mind, I discovered port:macports-libcxx and the trac ticket that led > to its creation (which mentions the filesystem extension...) > > The port does exactly what I think should be done, but at a port-specific > level. Indeed

Re: what's with the C++ extension?

> On 19 Sep 2022, at 3:08 pm, René J.V. Bertin wrote: > > On Monday September 19 2022 13:56:01 Chris Jones wrote: > >> But anyway, I m sure you will think you are right, so please feel free to >> experiment on your own system, as you get to own the pieces

Re: what's with the C++ extension?

> On 19 Sep 2022, at 11:53 am, René J.V. Bertin wrote: > > On Sunday September 18 2022 23:57:53 Chris Jones wrote: > >> Follow the above at your own risk. > > As I said, there is no need to update the system libc++ on systems that > already have it; `port:libcxx

Re: what's with the C++ extension?

> On 18 Sep 2022, at 11:58 pm, Chris Jones wrote: > >  > > >>> On 18 Sep 2022, at 1:29 pm, René J.V. Bertin wrote: >>> >> Hi, >> >> Building C++ code that does >> >> #include >> >> I get either a file-not-foun

Re: what's with the C++ extension?

> On 18 Sep 2022, at 1:29 pm, René J.V. Bertin wrote: > > Hi, > > Building C++ code that does > > #include > > I get either a file-not-found error or a bunch of errors that the functions > are 10.15+ only. What's with that? Seems pretty clear to me… > If the implementation is provided b

Re: Issues with config.h

Please provide a full log file for the build in Macports, and also one for exactly what commands you run and output you get when built outside ? On 04/08/2022 2:36 pm, Robert Kennedy wrote: I am working on creating a new port that uses its own *config.h*.  See attached.  The project compiles

Re: include files for cgxCADTools

The makefile here is very poorly written. You should never directly reference standard headers like that… > On 1 Aug 2022, at 4:52 pm, Mark Brethen wrote: > > This Makefile has the following lines: > > CadReader.o: /usr/include/stdlib.h /usr/include/bits/libc-header-start.h > CadReader.o: /u

Re: SPOOLES MT routines

> On 30 Jul 2022, at 5:11 pm, Mark Brethen wrote: > > Now that I think about it, a subport would not work since the ccx makefile > expects spooles.a in its workpath. No, it would still be perfectly fine. Just make the subport a build dependency, and then pre-build just copy the static libra

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

> On 28 Jul 2022, at 5:21 pm, Chris Jones wrote: > >  > > >>> On 28 Jul 2022, at 5:17 pm, Mark Brethen wrote: >>> >>  >> ~ $ cd >> /opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src >

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

> On 28 Jul 2022, at 5:17 pm, Mark Brethen wrote: > >  > ~ $ cd > /opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src > src $ sudo ack DrawCommandLine > Password: > cgx.c > 5009: DrawCommandLine(keystroke, strlen(keystroke)+curshft); > 5071:

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

en mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> On Jul 27, 2022, at 7:23 AM, Chris Jones <mailto:jon...@hep.phy.cam.ac.uk>> wrote: Latest clang compilers probably default to a 'recent' c standard, unless otherwise told. If the code in question only builds usi

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

On 27/07/2022 1:49 pm, Mark Brethen wrote: As you can see in the makefile (post-patch), it only makes use of CFLAGS and LDFLAGS. Then you should at least set these as well pre-build CFLAGS="${configure.cflags} [get_canonical_archflags cc]" LDFLAGS="${configure.ldflags} [get_canonical_archf

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

Error 1 Mark Brethen mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> On Jul 27, 2022, at 3:49 AM, Chris Jones <mailto:jon...@hep.phy.cam.ac.uk>> wrote: Please post a complete, clean, build log for the port in question. In general GCC should not be used to build c++ (*) as

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

ddress, by properly declaring the method before using it. A common reason for these errors is not including the require header with said declaration everywhere it is required. On 27/07/2022 1:23 pm, Chris Jones wrote: Latest clang compilers probably default to a 'recent' c standard, unless

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

er.o] Error 1 Mark Brethen mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> On Jul 27, 2022, at 3:49 AM, Chris Jones <mailto:jon...@hep.phy.cam.ac.uk>> wrote: Please post a complete, clean, build log for the port in question. In general GCC should not be used to build

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

Please post a complete, clean, build log for the port in question. In general GCC should not be used to build c++ (*) as doing so leads to these c++ runtime mis-matches. You should use clang for c++ (and c as well, although there is no runtime issues there). cheers Chris * The latest GCC v

Re: CalculiX build error using clang

-1) is needed? Nope, the opposite. That one call to the method ignores the return value. So the void signature is valid and the return statement should just omit the value. I.e. return; Chris > > Mark Brethen > mark.bret...@gmail.com > > > >>> On Jul 26, 2022,

Re: CalculiX build error using clang

> On 26 Jul 2022, at 6:27 pm, Mark Brethen wrote: > > would a ‘return;’ instead of ‘return(-1);’ suffice>? Depends on what the intentions of the developers are here… If callees of the function expect a return value, then the method should instead be updated to declare a return type, and the

Re: compilers PortGroup

e. I > looked at the compilers group and with it set, and gfortran variant is > selected, chooses ${compilers.gcc_default}. Which in my case was gcc12—which > is already installed. > > Mark Brethen > mark.bret...@gmail.com > > > >>> On Jul 17, 2022, at 6:15

Re: compilers PortGroup

> On 17 Jul 2022, at 1:59 am, Mark Brethen wrote: > > I’ve tested the build with gfortran-mp-12 which fails: > > :info:build /opt/local/bin/gfortran-mp-12 -Wall -O2 -c gencontelem_n2f.f > :info:build gencontelem_n2f.f:595:39: > :info:build 184 |call > isortii(ialset(istart

Re: fetch timeout

pher spec (1): >>>> } [1 bytes data] >>>> * TLSv1.2 (OUT), TLS handshake, Finished (20): >>>> } [16 bytes data] >>>> * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): >>>> { [1 bytes data] >>>> * TLSv1.2 (IN), TLS ha

Re: fetch timeout

On 15/07/2022 4:16 pm, Mark Brethen wrote: cert.perm has the same date very surprised ... and. does the curl fetch also fail ? Mark Brethen mark.bret...@gmail.com On Jul 15, 2022, at 10:11 AM, Chris Jones wrote: On 15/07/2022 4:08 pm, Mark Brethen wrote: I checked big sur

Re: fetch timeout

://trac.macports.org/ticket/51516 Mark Brethen mark.bret...@gmail.com On Jul 15, 2022, at 9:55 AM, Chris Jones wrote: On 15/07/2022 3:49 pm, Mark Brethen wrote: -rw-r--r--1 root wheel 346545 Jan 1 2020 cert.pem The above could be your problem, as that is very old, 2.5 years or so now

Re: fetch timeout

notorious for not updating to the latest versions of software with each new OS. Mark Brethen mark.bret...@gmail.com On Jul 15, 2022, at 9:55 AM, Chris Jones wrote: On 15/07/2022 3:49 pm, Mark Brethen wrote: -rw-r--r--1 root wheel 346545 Jan 1 2020 cert.pem The above could be

Re: fetch timeout

https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets Mark Brethen mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> On Jul 15, 2022, at 9:4

Re: fetch timeout

0   Boot Volume:Macintosh HD   Boot Mode:Normal   Computer Name:brethen-air   User Name:Mark Brethen (marbre)   Secure Virtual Memory:Enabled   System Integrity Protection:Enabled   Time since boot:10 days 18:45 Mark Brethen mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> On

Re: fetch timeout

date, then I am very surprised you are seeing SSL issues can anyone else on this OS confirm if they see the same issue... Mark Brethen mark.bret...@gmail.com On Jul 15, 2022, at 9:14 AM, Chris Jones wrote: On 15/07/2022 3:08 pm, Mark Brethen wrote: ~ $ /usr/bin/curl -L -v -o tet

Re: fetch timeout

On 15/07/2022 3:08 pm, Mark Brethen wrote: ~ $ /usr/bin/curl -L -v -o tetgen1.5.1.tar.gz https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz   % Total    % Received % Xferd  Average Speed   Time    Time     Tim

Re: fetch timeout

give the above a try ? I only have access to macOS12 and its fine there for me. Chris Mark Brethen mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> On Jul 15, 2022, at 8:49 AM, Chris Jones <mailto:jon...@hep.phy.cam.ac.uk>> wrote: :debug:fetch Fetching

Re: fetch timeout

On 15/07/2022 2:49 pm, Chris Jones wrote: :debug:fetch Fetching distfile failed: error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure that is your problem. Can you reproduce the above by using the system curl (which is effectively) what macports uses /usr/bin

Re: fetch timeout

://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz On 15/07/2022 2:44 pm, Chris Jones wrote: That is not what I asked... You shouldn't have to override the fetch phase. I think you are probably looking in the wrong place for your issue, but without seeing the portfile and the exact error you get no o

Re: fetch timeout

apologies, just saw the attachments.. On 15/07/2022 2:44 pm, Chris Jones wrote: That is not what I asked... You shouldn't have to override the fetch phase. I think you are probably looking in the wrong place for your issue, but without seeing the portfile and the exact error you g

Re: fetch timeout

Mark Brethen wrote: Overriding fetch in the portfile does work. Mark Brethen mark.bret...@gmail.com On Jul 15, 2022, at 8:26 AM, Chris Jones wrote: OK, so next please post the portfile you are testing, and exactly what you get from the fetch phase when you run sudo port -d fetch xyz On

Re: fetch timeout

, at 8:10 AM, Mark Brethen <mailto:mark.bret...@gmail.com>> wrote: ~ $ which curl /opt/local/bin/curl Mark Brethen mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> On Jul 15, 2022, at 8:09 AM, Chris Jones <mailto:jon...@hep.phy.cam.ac.uk>> wrote: what curl a

Re: fetch timeout

what curl are you using ? System of macports version ? What OS are you on ? On 15/07/2022 2:01 pm, Mark Brethen wrote: Have to follow a redirected file. This worked in terminal: ~ $ curl -L -o tetgen1.5.1.tar.gz http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz

Re: How about a MacPorts "system" (generic) python port?

Some users have objected to being made to install multiple versions of python, especially python27 which is EOL, so when possible we usually choose to use a recommended version of python3x (as specified in the python portgroup) rather than python27. I'd be among those users (save for the v

Re: bazel 4.2 and 3.7 no longer building with native clang

sary previous versions can be obtained from binary downloads from github. Personally, I have also adopted the stance of avoiding bazel entirely unless absolutely necessary. On Jul 14, 2022, at 05:54, Chris Jones wrote: Hi On 13/07/2022 10:50 pm, Ryan Schmidt wrote: On Jul 13, 2022, at 11:46,

Re: bazel 4.2 and 3.7 no longer building with native clang

Hi On 13/07/2022 10:50 pm, Ryan Schmidt wrote: On Jul 13, 2022, at 11:46, Steven Smith wrote: How does one reconfigure the bazel Portfile to use a previous version of clang that has a chance of working to build previous versions of bazel, which are in turn necessary to build the tensor flow

Re: build.macports.org - certificate expired

Can you post a link to the ticket if you do find/create one ? > On 12 Jul 2022, at 4:18 pm, Christopher Nielsen > wrote: > > FYI, It looks like the SSL cert for build.macports.org expired today, > preventing access to the site. > > I’ll add a Trac ticket, if one doesn’t exist already.

Re: +universal for x864+arm64 on Macintel

> On 13 Jun 2022, at 1:06 pm, René J.V. Bertin wrote: > > Ryan Schmidt wrote on 20220613::04:34:46 re: "Re: +universal for x864+arm64 > on Macintel" > >> As far as I know, the SDK would also need to support arm64, which SDKs prior >> to macOS 11 don't. Therefore MacPorts doesn't support co

Re: +universal for x864+arm64 on Macintel

> On 13 Jun 2022, at 1:06 pm, René J.V. Bertin wrote: > > Ryan Schmidt wrote on 20220613::04:34:46 re: "Re: +universal for x864+arm64 > on Macintel" > >> As far as I know, the SDK would also need to support arm64, which SDKs prior >> to macOS 11 don't. Therefore MacPorts doesn't support co

Re: +universal for x864+arm64 on Macintel

I assume you have tried removing these two line from your portfile ? On 13/06/2022 8:48 am, Ryan Schmidt wrote: On Jun 10, 2022, at 11:23, René J.V. Bertin wrote: When I trie

Re: Fastly Mirrors Throttled to 1 MB/sec?

On 07/06/2022 3:09 pm, Joshua Root wrote: On 2022-6-7 21:43 , Christopher Nielsen wrote: On 2022-06-06-M, at 13:53, Joshua Root wrote: Try fetching the same file twice in a row. In my experience, the first fetch from a cold cache is quite slow, but once the local node has the file, it wil

Re: Reason for rpath usage on arm64

> On 24 May 2022, at 4:22 pm, Ken Cunningham > wrote: > >  >> >> Does anyone know why things seem to be using rpath on arm64 builds > > Basically, it comes down to the fact that Apple has disallowed > DYLD_LIBRARY_PATH to work on newer systems. > > gcc for Darwin has one developer workin

Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance

> On 23 May 2022, at 9:59 pm, Steven Smith wrote: > >  >> >> What has changed between the time that the buildbot built the package and >> the time that the user installs it? > > The certs in curl-ca-bundle are updated regularly to clear out expired certs. > > Per the previous discussion,

Re: Location to store binaries

Maybe i am missing some detail here, but why cannot this bootstrap compiler just be a port like everything else, and thus the binary hosting is just the same as any other binary tarball macports distributes ? > On 15 Apr 2022, at 11:16 pm, Herby G wrote: > >  > Since this would be adding a co

Re: latest git version no longer detected by base

> On 14 Apr 2022, at 11:16 pm, Joshua Root wrote: > > On 2022-4-14 23:56 , Christopher Jones wrote: >> Hi All, >> Does anyone have any ideas on >> https://github.com/macports/macports-ports/commit/053dbb666a57972ceefba10b1edd12f16d886fd4#commitcomment-71271508 >> >>

Re: macOS 12 x86_64 buildbot weirdness

The errors below to me more suggest issues with free disk space than memory or cpu. But yes it seems the build should be checked. Chris > On 8 Apr 2022, at 4:06 pm, Herby G wrote: > >  > Hello, > > Something weird might be going on with the macOS 12 x86_64 buildbot > > Two builds of the

Re: python2.7 pip install fails with SSLError

Does the port *have* to use python 2.7 ? Is it not compatible with python 3.x ? On 15/03/2022 12:09 am, Steven Smith wrote: I’m trying to update calendar-contacts-server to macOS 12.3. This requires installing a bunch of stuff with python2.7’s pip. I’m hitting an SSLError at the command:

Re: LLVM port mp-llvm-* select groups mislinks certain programs

E > On 14 Mar 2022, at 8:10 pm, Ryan Schmidt wrote: > > On Mar 14, 2022, at 14:02, Christopher Jones wrote: > >> You can easily see the issue with >> >>> sudo port -d select llvm mp-llvm-13 >> >> the linkage starts out in sync, but then starts to diverge.. >> >> >> DEBUG: ln -sf /opt/local

Re: M1 MacPorts failures, "configure: error: C compiler cannot create executables"

I recently ran into something similar, albeit on an intel machine running the latest macOS12 release, not an M1 machine. In the end I 'brute force' fixed it by completely removing Xcode and the CLT, then reinstalling both. Chris On 11/03/2022 3:15 pm, Steven Smith wrote: I’m recently hitt

Re: "port upgrade" error message usability

Hi, On 30/01/2022 8:24 am, Andrew Janke wrote: Hi, MacPorts developers, Long-time Homebrew user and recent MacPorts convert here. Minor usability issue with the `port` program, I think: I suspect that a common operation for regular MacPorts users to do is "upgrade all my stuff to the latest

Re: Detecting Apple Silicon (vs. legacy Intel)

I > On 31 Dec 2021, at 5:13 pm, Vincent Habchi wrote: > > Folks, > > finally put my hands on my brand new MacBook Pro 14”! (Well, not really mine, > rather my company’s, but let’s pretend…) > > I was wondering if there is a simple scheme to detect on which type of > architecture MacPorts is

Re: gcc11-devel and our buildbots

Hi Before arm came along the gccdevel ports indeed did not update that regularly. Normally in the run up to a new major release they might see more activity, as we take a look as to if the upcoming release has any issues, but outside that they perhaps would go a month or two between updates. Ar

Re: [10.6.8] MySQL 5.7.36_1 compile hell

> On 20 Dec 2021, at 2:42 pm, Renee Otten wrote: > > Please don’t use the mailing list for this stuff - Trac is the appropriate > medium for this IMHO… Agreed. Please open a trac ticket and post any logs you wish to share there. > > > >> On Dec 20, 2021, at 9:17 AM, Bjarne D Mathiesen

  1   2   3   4   >