Go Ports: Update PG to Ensure Ports Aren't Built if Version Required Not Available

At present, our Go port is pinned at an older version - 1.17.3 - for macOS 10.12 and earlier. With the result being that many Go-based ports simply fail to build for those releases, wasting precious buildbot time. Just as importantly, the user experience isn’t great, either: There’s no checking

RE: Commit Messages

> From: Fred Wright > Date: 2023-07-15 18:57:46 > > In recent times, commit messages failing to conform to the guidelines have > been becoming more common - specifically, the failure to include a blank line > after the summary. The guidelines even state briefly why this matters, though > perhap

build.macports.org down?

FYI, it looks like ‘build.macports.org’ is currently offline.

Re: [MacPorts] #65892: gtk3: windows displayed as all black

Given the context - this ticket is related to GTK 3, after all - I can't remotely comprehend the confusion. And indeed, the upstream project I searched through, was GTK. Fair enough? On October 5, 2022 19:06:17 Michael Campbell wrote: Hi All, This is not about black windows in X11. I hav

RE: Code signing

> I’m using a couple of ports that deliver services (unbound/nsd, dovecot, > postfix, nginx, minIO, etc.) and the reliability of these being able to be > started and used becomes less and less over the successive macOS versions. I > have no proof, but I get the distinct feeling that unsigned cod

ffmpeg 5.x status

For anyone curious as to where things stand with updating ffmpeg to 5.x: Based on local testing of dependents, it appears that upstream has made some breaking API changes. And that affects a number of ports, making the update a no-go at present. However, I still need to dig into the details, to

Darktable - ARM Testers Needed!

Folks, we just enabled native ARM support for Darktable, and now we need to ensure the apps runs successfully for both X11 and Quartz. In terms of testing, we’d want to try, at a minimum: * Launch the app, and look for any any immediately-obvious UI issues * Poke around the UI a bit, and try some

RE: Beginner's problems with old hardware

While I’m not sure what your options are for mail clients, you do have a good option for web browsing: TenFourFox. It’s what I use on my PowerBook G4, running 10.5. https://www.floodgap.com/software/tenfourfox/ And while it’s no longer actively d

PR Backlog - Help Needed!

While I’ve been trying to help folks with their PRs - and the count is back down to 60-ish, as of this writing - there are still quite a few in limbo. So if you happen to have relevant knowledge - and can help the author, including pushing minor changes if needed - that would be awesome! Cheers

Re: build.macports.org - certificate expired

>>> FYI, It looks like the SSL cert for build.macports.org >>> expired today, preventing access to the site. >> Can you post a link to the ticket if you do find/create one ? > https://trac.macports.org/ticket/65479 > Ryan just

Re: build.macports.org - certificate expired

> Can you post a link to the ticket if you do find/create one ? >> FYI, It looks like the SSL cert for build.macports.org >> expired today, preventing access to the site. https://trac.macports.org/ticket/65479

build.macports.org - certificate expired

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: Help with Unsigned MacPorts App Bundles, on Big Sur and Monterey

> I’m still very new to the Big Sur and Monterey scene - particularly relative > to development - and could use some assistance with the following ticket. But > in short, when various apps are run, user files are inaccessible. > > https://trac.macports.org/ticket/65302 >

Help with Unsigned MacPorts App Bundles, on Big Sur and Monterey

I’m still very new to the Big Sur and Monterey scene - particularly relative to development - and could use some assistance with the following ticket. But in short, when various apps are run, user files are inaccessible. https://trac.macports.org/ticket/65302

RE: A bunch of failures with nodejs on the builders

>> My solution is to leave the installer in place - ensuring it’s not >> auto-downloaded again - while removing ‘SharedSupport.dmg’ from within the >> app bundle. This frees up the vast majority of storage space, without >> invalidating the installer itself. > This method has not been effective

Re: Fastly Mirrors Throttled to 1 MB/sec?

> 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 > will saturate my connection. I’ve tried that numerous times over the past few months, b

Fastly Mirrors Throttled to 1 MB/sec?

Over the past few months, I’ve found that downloads from ‘packages.macports.org’ and ‘distfiles.macports.org’ are consistently throttled at 1 megabyte/second. And while that isn’t an issue for smaller payloads, it significantly impacts binary installation/update times for larger ports like Rust

Parallels 17.1.3 - Parallels Tools Broken, for macOS Guests

For users of Parallels 17: Parallels Tools may be broken for macOS guests, with the latest version released over the past few days (17.1.3). Specifically, there appear to be issues with the signatures for their kexts, for macOS releases between 10.10 through 10.15. (10.9 and earlier seem OK, as

Re: A bunch of failures with nodejs on the builders

> In addition, as you may know, a bug in recent macOS causes it to download the > 12+ GB macOS Monterey installer periodically which would have left it with > only 8 GB available. I recently discovered this behavior as well. My solution is to leave the installer in place - ensuring it’s not au

Recent Purchase of a 2012 MacPro 5,1 - History and Thoughts

I wanted to quickly share some recent experience with a serious Mac upgrade - for me, at least - which finally removes some barriers for MacPorts development and testing. But first, some brief history, which folks might enjoy: My first “real" desktop Mac was a 2005 PowerMac G5/2.7 DP - the liqu

GitHub Currently Impaired

So you may see failures - whether pushing changes via Git, attempting to merge PRs via the site, etc - related to everything. There’s no resolution ETA yet, but hopefully it won’t be impaired for long. Cheers, -Chris

RE: gcc11-devel and our buildbots

>> It seems like we’re updating this port at least weekly. With the result >> being that our Intel buildbots are routinely bogged down for a long time, >> sometimes as long as 4-5 hours. >> >> While I understand that we want to follow upstream’s progress - particularly >> for the ARM version -

Re: gcc11-devel and our buildbots

> It seems like we’re updating this port at least weekly. With the result being > that our Intel buildbots are routinely bogged down for a long time, sometimes > as long as 4-5 hours. > > While I understand that we want to follow upstream’s progress - particularly > for the ARM version - is thi

gcc11-devel and our buildbots

It seems like we’re updating this port at least weekly. With the result being that our Intel buildbots are routinely bogged down for a long time, sometimes as long as 4-5 hours. While I understand that we want to follow upstream’s progress - particularly for the ARM version - is this really nec

Re: 10.15 Xcode version: Buildbot, vs. GitHub CI

> On 2021-12-01-W, at 18:33, Ryan Schmidt wrote: > >> On Dec 1, 2021, at 09:18, Christopher Nielsen wrote: >> >> * Would it be feasible to update our 10.15 buildbot to a newer Xcode >> release? Or are there certain ports/situations that necessitate remaining &g

10.15 Xcode version: Buildbot, vs. GitHub CI

Just encountered an interesting situation, where a Swift-based port builds successfully via 10.15 CI, but fails on our buildbot. This appears to be related to Xcode versions: Presently our 10.15 buildbot has Xcode 11.7, whereas 10.15 CI has Xcode 12.4. This brings up two questions: * Would it b

Re: build.macports.org currently down?

> The RAID is fine. Buildmaster and some workers are back up. I'll work on > getting the remaining workers back online tonight (in a few hours). (Each has > to be checked and cleaned up manually first.) Ryan, do you think we’ll be able to bring the 10.13 buildbot back online soon? Not an emerg

gettext 0.21 update PR - FINAL CALL FOR FEEDBACK/OBJECTIONS

Folks, our long-awaited update to ‘gettext’ 0.21 - via PR 7399 - can now move forward: It was dependent on merging of foundational PR 7074 (update 'python27-bootstrap’ to not use ‘gettext-bootstrap’), and the latter was merged two days ago. https://github.com/macports/macports-ports/pull/7399

GitHub Currently Down/Impaired

So if you’re currently trying to do anything with GitHub - including any Git operations - you’re likely to experience issues. https://www.githubstatus.com/

build.macports.org currently down?

It looks like ‘build.macports.org’ is current inaccessible. Is anyone else seeing the same thing?

Re: Question regarding builders and require_active_variants

Makes sense. And yes, it’s definitely frustrating that Quartz-only gtk2/gtk3 ports don’t build on our buildbots. Ultimately I’m going to fix this issue once and for all, via segregated subports for X11 and Quartz. (That will need to be done for all of the key foundational ports, including: glib

RE: Question regarding builders and require_active_variants

Jason, are you asking relative to the new port you just created, for RawTherapee? > As I was working on a port recently, a question came to mind which I’m > curious about. When using `require_active_variants` in a Portfile, are the > builders smart enough to then install dependencies using the

RE: Slight problem that probably needs resolving...

> mascguy committed the request after only a few hours before waiting for drkp > to comment (drkp is the maintainer.) This isn't my main concern, however; my > main concern is that mascguy then deleted my comments in which I noted that > this wasn't how things are generally done, which doesn't s

Help with Testing GTK3 Bug-Fix Update

Folks, a new Devel port for GTK3 was created two weeks ago, with the goal of testing upstream releases. Along with that, all GTK3 dependents were updated to use a path-style dependency for GTK3, allowing the new port (gtk3-devel) to be a drop-in replacement. In any case, gtk3-devel uses a later

Re: Help with testing of PR 7074 - python27-bootstrap: stop using gettext-bootstrap

> Folks, this PR has been open since 5/12/2020, and we’d love to finally merge > it. Of note, it’s also the key dependency preventing merge of PR 7399, the > latter for a long-awaited update to gettext. > > In short, we need someone to test a source-only install of clang-3.4 - along > with all

Re: ports.macports.org - sync broken?

>> Over the past few days, I’ve added multiple new ports. However, while such >> activity has been quickly picked up in the past - typically within an hour >> or two - that’s no longer occurring. > > Ideally the refresh happens every 10 minutes. The footer shows the time when > the last update

Help with testing of PR 7074 - python27-bootstrap: stop using gettext-bootstrap

Folks, this PR has been open since 5/12/2020, and we’d love to finally merge it. Of note, it’s also the key dependency preventing merge of PR 7399, the latter for a long-awaited update to gettext. In short, we need someone to test a source-only install of clang-3.4 - along with all of its depen

Re: ports.macports.org - sync broken?

>> Over the past few days, I’ve added multiple new ports. However, while such >> activity has been quickly picked up in the past - typically within an hour >> or two - that’s no longer occurring. > > Ideally the refresh happens every 10 minutes. The footer shows the time when > the last update

ports.macports.org - sync broken?

Over the past few days, I’ve added multiple new ports. However, while such activity has been quickly picked up in the past - typically within an hour or two - that’s no longer occurring. Is there a sync/refresh process that is currently broken?

RE: ruby_select is broken

> The ruby_select portile just has: > > destroot { > select::install ruby ${filespath}/base > select::install ruby ${filespath}/none > } > > which does not redirect the commands “ruby” or “gem” to the appropriate > version when you have installed the port “ruby27” for example. Instea

RE: ruby_select is broken

> The ruby_select portile just has: > > destroot { > select::install ruby ${filespath}/base > select::install ruby ${filespath}/none > } > > which does not redirect the commands “ruby” or “gem” to the appropriate > version when you have installed the port “ruby27” for example. Instea

RE: kibana submission node version conflict issue

> On Oct 2 2021, at 05:30, Ryan Schmidt wrote: > >> On Sep 2, 2021, at 05:12, Steven Smith wrote: >> >> How can this node version conflict be resolved? > > The node ports should be fixed so that they do not conflict with one another. Agreed, and tracked by open issue: https://trac.macports.org

Re: New Port harfbuzz-devel/harfbuzz-devel-icu; Path-Style Dependency Now Needed

> On 2021-08-31-T, at 07:14, Christopher Nielsen > wrote: > >> On 2021-08-31-T, at 06:28, Ryan Schmidt > <mailto:ryandes...@macports.org>> wrote: >> >> I haven't been following everything closely and wasn't aware harfbuzz devel >> ports

Re: New Port harfbuzz-devel/harfbuzz-devel-icu; Path-Style Dependency Now Needed

> On 2021-08-31-T, at 06:28, Ryan Schmidt wrote: > > Hi Chris, > > I haven't been following everything closely and wasn't aware harfbuzz devel > ports were going to be introduced. But if they are, then you can make the > required dependency change to all ports in a single commit. I would not

New Port harfbuzz-devel/harfbuzz-devel-icu; Path-Style Dependency Now Needed

Folks, As part of the overarching GIMP upgrade effort, we’re juggling updates to a number of foundational ports. One of those is ‘harfbuzz’, which is still pending via PR 11948 (https://github.com/macports/macports-ports/pull/11948 ). Not

RE: New ports.macports.org website

Just took the new site for a spin, and all I can say is - WOW! It looks great, the design is very logical (if not perfect!), and it’s rich in functionality. It’s clear that a LOT of good thought/discussion went into the UI design, and boy did it pay off! Kudos to everyone involved in the effort!

Re: Buildbots Down?

Sorry, I meant the buildbot watchers and workers, not the jobs themselves. Also, I wasn’t being critical of the perl 5.32 commit. Just trying to understand what happened. > On 2021-06-22-T, at 09:42, Mojca Miklavec wrote: > >> On Tue, 22 Jun 2021 at 14:46, Christopher N

Buildbots Down?

Were the recent buildbot failures related to the perl 5.32 commit…?

GitHub Tip: Check Build Status for Commits

For anyone who isn’t aware: From the Commits area of GitHub, you can quickly check the build status of your changes: https://github.com/macports/macports-ports/commits In the line showing the author and commit date/time, there should be an ic

RE: auto-multiple-choice-devel broken because default perl5 version is still 5.28

> Joel.Brogniart on Wed Jun 9 07:59:30 2021 > > Someone modified the auto-multiple-choice-devel version to use perl5.30 but > as the default perl5 version is still 5.28 the port doesn't works. Why was > the port modified before changing the default perl5 version? > > How could I make sure other

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

Take a look at the following comment in the open PR, which illustrates the before/after: https://github.com/macports/macports-base/pull/243#issuecomment-851587566 > On 2021-06-02-W, at 16:52, Ryan Schmidt wrote: > >> On May 26, 2021, at 08:38, Christopher Nielsen wrote: >>

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

Sounds good. I’ll propose a few ideas over the next day or so, via the PR. And please feel free to do so as well. > On 2021-06-02-W, at 11:19, Joshua Root wrote: > >> On 2021-6-2 23:39 , Christopher Nielsen wrote: >> I absolutely support the package/namespace “named logg

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

evel, sure, that’s also a possibility. Though we might want to do that as a separate PR. I’m certainly open to any and all ideas though! Thoughts? > On 2021-06-01-T, at 19:29, Joshua Root wrote: > >> On 2021-6-2 09:05 , Rainer Müller wrote: >>> On 24/05/2021 17.13, Chr

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

a gander. > On 2021-05-31-M, at 08:32, Christopher Nielsen > wrote: > > To help ensure we’re all on the same page, I’ve gone ahead and implemented > the new functionality via the following PR: > > Base: add lower-level debug output, via new levels debug1-3: > htt

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

existing ‘ui_xxx’ logging procedures.) > On 2021-05-26-W, at 09:38, Christopher Nielsen > wrote: > > I’m referring to debug output like the following, in this cases taken from > one of our builtbot logs. Some of these are generated by base, while others > are generated by the por

RE: How to mark pull request as ready for review?

Brian, Thank you for your first contribution! It looks like there are two suggested changes to your PR, both minor. Once you can make those corrections, we’ll go ahead and merge it. If you have any questions regarding the suggestions, or need further clarification, please comment via the PR it

MacPorts 2.7.1 - Availability for GitHub CI Jobs, as well as Buildbots?

While I realize MacPorts 2.7.1 was just released, is there an ETA on when it will be available for both CI, as well as our buildbots? There’s certainly no rush. But the bug fix for issue 56793 (slow installs of ports with tens of thousands of files) would be hugely beneficial across-the-board.

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

running callback portstartupitem::add_notes DEBUG: Running callback legacysupport::add_legacysupport > On 2021-05-26-W, at 09:30, Ryan Schmidt wrote: > >> On May 26, 2021, at 06:07, Christopher Nielsen wrote: >> >> Great question! >> >> One of the key things this

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

the current Debug level, they’d be hidden, making things less verbose. Does that make sense? > On 2021-05-26-W, at 04:39, Ryan Schmidt wrote: > >> On May 24, 2021, at 10:13, Christopher Nielsen wrote: >> >> Has there been any thoughts/interest in implementing anoth

Re: 2.7.1

On 2nd thought, if there’s interest in creating a 2.7.1 bug-fix release ASAP, this can definitely wait... > On 2021-05-25-T, at 13:13, Christopher Nielsen > wrote: > > Josh, is there any interest in adding base PR 242, which fixes double-space > messages for ‘port diagno

RE: 2.7.1

Josh, is there any interest in adding base PR 242, which fixes double-space messages for ‘port diagnose’? https://github.com/macports/macports-base/pull/242 > On May 25, 2021, at 11:29:32, Joshua Root wrote: > > Any objection to tagging the

MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

Has there been any thoughts/interest in implementing another level (or two) of debug output, providing more detail than we get at Debug? That would allow us to optionally output more diagnostic info in various areas, such as our portgroups, without flooding the logs when running at our present D

Protobuf3-cpp update woes; strategy to avoid broken dependent ports?

We need to figure out a better way to deal with updates to ‘protobuf3-cpp’, as every time this port is updated, all dependent ports are broken. (Apart from a handful that folks manually rev-bump along with it.) The problem is that every update results in the name of the dylib being incremented

Re: Why is binary avoided for Xcode MPI wrappers?

It’s quite possible that those binaries will work without issue. But without further testing and validation - across all supported macOS releases (10.6 through Big Sur) - we simply can’t say for sure. That being said, if our LLVM/toolchain experts (KenC, JeremyHu, etc) think it’s safe, we can a

Re: Buildbot Performance

Well, my recommendation for our setup, is to avoid pinning. Why? For several reasons: * Out-of-the-box, ESX/ESXi makes a best-effort attempt to schedule all vCPUs for a given VM, on a single NUMA node. * Even when that’s not possible, the hypervisor schedules VM vCPUs to hyperthread pairs. Pinn

Re: Buildbot Performance

/each, along with significant CPU overcommitment - I wouldn’t recommend using pinning. > On 2021-05-17-M, at 18:26, Christopher Nielsen > wrote: > > We don’t want any type of pinning, as that will further exacerbate the > situation. > >> On 2021-05-17-M, at 18

Re: Buildbot Performance

Sounds good. And perhaps that’s a good long-term plan: If we can install additional memory in the Xserves, such that all buildbot VMs can be allocated 9 or 10 GB each, that should help across-the-board. Combine that with an upgrade to six-core Westmere Xeons, and our build times will increase

Re: Buildbot Performance

]. > On 2021-05-17-M, at 18:30, Christopher Nielsen > wrote: > > If you total up the memory allocated across all VMs, is there at least one or > two GB free for the hypervisor? > >> On 2021-05-17-M, at 18:26, Ryan Schmidt wrote: >> >>> On May 17, 20

Re: Buildbot Performance

If you total up the memory allocated across all VMs, is there at least one or two GB free for the hypervisor? > On 2021-05-17-M, at 18:26, Ryan Schmidt wrote: > >> On May 17, 2021, at 07:36, Christopher Nielsen wrote: >> >> As for overcommitment: I’m simply sugge

Re: Buildbot Performance

We don’t want any type of pinning, as that will further exacerbate the situation. > On 2021-05-17-M, at 18:24, Ryan Schmidt wrote: > >> On May 17, 2021, at 13:13, Jason Liu wrote: >> >> Regarding CPU overcommitment: Are the virtual hosts doing any sort of CPU >> pinning? Many virtualization p

Re: Buildbot Performance

It used to be that you had to pay for vCenter, to get deep insights into VM performance. But ‘esxtop' is certainly a great starting point. And perhaps it does provide enough info, to get an idea of where time is being spent. > On 2021-05-17-M, at 02:55, Daniel J. Luke wrote: > > I'm not an ESX

Re: Buildbot Performance

021-05-16-S, at 00:13, Ryan Schmidt wrote: > >> On May 14, 2021, at 07:12, Christopher Nielsen wrote: >> >> Since we’re overcommitting on CPU, I’m wondering if it would make sense to >> reduce the vCPUs in each VM to 4? In addition to reducing any swapping, that >&

Re: Buildbot Performance

-switching overhead, and improve build times somewhat. (It’s been awhile, but I think (?) there might be additional hypervisor overhead from overcommitment.) Thoughts? -Chris > On 2021-05-14-F, at 00:54, Ryan Schmidt wrote: > > On May 12, 2021, at 07:41, Christopher Nielsen wrote: >> &

Re: Buildbot Performance

broadly, particularly for ports with large code bases? > On 2021-05-12-W, at 08:41, Christopher Nielsen > wrote: > > To clarify my question about overcommitment: Are the total number of virtual > CPUs for the buildbot VMs running on a given Xserve, greater than the number > of

Re: Buildbot Performance

To clarify my question about overcommitment: Are the total number of virtual CPUs for the buildbot VMs running on a given Xserve, greater than the number of physical CPU cores available? > On 2021-05-12-W, at 08:32, Christopher Nielsen > wrote: > > Looking at the build times

Buildbot Performance

Looking at the build times for various ports, it varies significantly. I was curious, are we overcommitting virtual CPUs vs. the number of available physical cores on our Xserves? And is disk swapping coming into play, within the VMs themselves?

Re: OpenMPI Builds for MacOS 10.8 and Earlier, Targetting GCC

s AVX just fine. > >> On 4 May 2021, at 7:17 pm, Christopher Nielsen > <mailto:masc...@rochester.rr.com>> wrote: >> >> Based on the following ticket, it sounds as if GCC is utilizing Apple’s >> assembler by default? >> >> cctools as does not support AV

Re: OpenMPI Builds for MacOS 10.8 and Earlier, Targetting GCC

nually selecting clang, via ‘port select’. Is that still accurate? Are there any other clean ways to fix this, apart from disabling use of AVX instructions? > On 2021-05-04-T, at 12:45, Christopher Nielsen > wrote: > > I’m currently reviewing the build logs for openmpi-* subports, wh

OpenMPI Builds for MacOS 10.8 and Earlier, Targetting GCC

I’m currently reviewing the build logs for openmpi-* subports, which are failing to build for older MacOS releases. And it looks like the issue relates to the use of the various AVX* instruction sets: CCLD liblocal_ops_avx2.la :1015:20: error: invalid operand for instruction vmovd

RE: MacPorts 2.7.0-beta2 now available for testing

Josh, Reviewing the change log, the following piqued my interest: - reclaim: remove everything under build and ccache directories. (#60126, khindenburg in b9fdb847, d08d261f) I quickly reviewed the related ticket, and new logic, but one thing still isn’t clear: Will the ccache directory be emp

Open PR for OpenMPI 4.1.1 Update - Including Big Sur ARM Fix

Folks, There is presently an open PR for OpenMPI, which updates the port to 4.1.1. In addition to many bug fixes, upstream also included a fix for Big Sur ARM builds. Hurray! The PR also enables use of buildbot binaries for most cases, greatly improving the user experience. But wait, there’s

Re: openmpi-* subports, and publishing of binaries

1-04-28-W, at 08:15, Christopher Nielsen > wrote: > > Good point, and the binaries do indeed exist. > > I’m running on a 2008 MacPro, with pre-Nehalem Xeons that are one major > generation behind the Xserves. So that makes me an ideal candidate to test. > > Now it’s simp

build.macports.org down?

I’m currently trying to check the builder logs, but build.macports.org isn’t responding. Is it down?

Builds Failing on 10.6_x64 Buildbot: Full Xcode Installation Not Found

FYI, for anyone who might be interested. I’m not sure how long 10.6_x64 builds have been failing, but noticed the issue today. Tracked by ticket: https://trac.macports.org/ticket/62771

Re: openmpi-* subports, and publishing of binaries

. Stay tuned... > On 2021-04-27-T, at 19:20, Ryan Schmidt wrote: > >> On Apr 27, 2021, at 18:15, Christopher Nielsen wrote: >> >> [My previous reply looks like it may be stuck in the mailman queue, and/or >> rejected. So re-sending with additional info.] >> >

Re: openmpi-* subports, and publishing of binaries

documentation - or on the web in-general - that suggests binaries are tied to a build machine’s specific hardware. So what I’m asking is, should we just go ahead and update openmpi-* to publish binaries? > On 2021-04-27-T, at 18:13, Ryan Schmidt wrote: > >> On Apr 27, 2021, at 17:10,

Re: openmpi-* subports, and publishing of binaries

As a follow-up to this thread, I recently noticed that we’ve been publishing binaries for port hwloc for quite some time. And openmpi is utilizing that library, apparently without any issues. (Confirmed by the dependencies of the openmpi-* binaries, via otool.) So I’m wondering if perhaps there

Re: GitHub CI Jobs Slower than Usual?

2021, at 11:17, Ryan Schmidt wrote: > >> On Apr 27, 2021, at 10:58, Christopher Nielsen wrote: >> >>> Is this normal/expected? >> >> Nope, there is a problem for me to fix on the server. I see lots of "403 >> Forbidden" requests to the priva

Re: GitHub CI Jobs Slower than Usual?

-- --:--:-- 3459 I’ve also spot-checked a few others, and they were also being installed from the published binary. That’s good, but it doesn’t account for why the process is taking so long. > On 2021-04-27-T, at 12:17, Ryan Schmidt wrote: > >> On Apr 27, 2021, at 10:58, Christoph

Re: GitHub CI Jobs Slower than Usual?

on process is slow. Is this normal/expected? > On 2021-04-27-T, at 11:21, Ryan Schmidt wrote: > >> On Apr 25, 2021, at 08:46, Christopher Nielsen wrote: >> >> Are the GitHub CI builds running much slower than usual? (At least, as >> compared to a few weeks ag

Re: GitHub CI Jobs Failing During MacPorts Bootstrap

FYI, Bintray is available at the moment. So if you created a new PR over the past two days, and the CI jobs died immediately due to Bintray being unavailable, force-push a change to re-initiate the CI process. > On 2021-04-26-M, at 15:48, Christopher Nielsen > wrote: > >

Re: GitHub CI Jobs Failing During MacPorts Bootstrap

pecific hours will be advertised > in the Bintray status page.)” > > Chris > >> On 26 Apr 2021, at 5:35 pm, Christopher Nielsen > <mailto:masc...@rochester.rr.com>> wrote: >> >> I’m seeing the following failures in the CI jobs, during the MacPorts >>

GitHub CI Jobs Failing During MacPorts Bootstrap

I’m seeing the following failures in the CI jobs, during the MacPorts Bootstrap phase: Installing MacPorts Fetching... curl: (22) The requested URL returned error: 403 Forbidden curl: (22) The requested URL returned error: 403 Forbidden Error: Process completed with exit code 22. Any thoughts/id

GitHub CI Jobs Slower than Usual?

Are the GitHub CI builds running much slower than usual? (At least, as compared to a few weeks ago.) Installing of dependencies, in particular, is taking several hours. Does anyone have any thoughts/insight?

openmpi-* subports, and publishing of binaries

Given how long the various openmpi-* subports take to build, it would be beneficial to publish binaries for our users. This is currently disabled in the Portfile, with a brief mention that it’s due to ‘hwloc’... and the tight coupling between the compiled binaries, and the hardware it’s compile

Re: Desolate Condition

On 2021-01-30-S, at 12:00, Rainer Müller wrote: > > Yes, we do have a Twitter account [1], but we are not using it much. Mostly > we announce new releases and maintenance stuff there. > > I added a new SocialMedia wiki page [2] to document the existence of such > social media presence. This al

Fwd: GIMP is running slow on Big Sur (#5989)

For anyone interested in GIMP on Big Sur, this is encouraging. Not necessarily a final fix, but getting there... > Subject: Re: GIMP is running slow on Big Sur (#5989) > Date: 2021-01-28-Thu at 09:30:06.0 > DesMcGuinness commented >

RE: Desolate Condition

> Ken Cunningham wrote: > > homebrew is in shambles. > > their long-touted "no-sudo" and "no PATH" advantage from installing into > /usr/local has been eliminated by Apple as the horrible security threat it > always was. They have to retool into /opt/homebrew and make 10,000 builds > respect t

Re: build.macports.org down?

On 2021-01-20-W, at 00:47, Ryan Schmidt wrote: > Disk first aid showed no major problems but buildbot's sqlite3 database was > unrecoverable so we'll start over with a new database. I'll be scheduling > builds for anything that was in the queue due to commits, but if anyone had > put any force

build.macports.org down?

This isn’t urgent - I was simply interested in checking the build backlog - but can’t get a response from build.macports.org . Earlier I was seeing a “Bad Gateway” message via web browser, now it’s simply timing out with a blank page. Output from a ‘wget’ test: $ wg

  1   2   >