> Sent: Sunday, November 26, 2023 at 4:05 PM
> From: "MacPorts"
> Subject: Re: [MacPorts] #67130: subversion: Segmentation fault
> #67130: subversion: Segmentation fault
> -+
> Reporter: ogourgue | Owner: (none)
> Type: defect | Status: new
> Priority: N
https://github.com/macports/macports-ports/pull/18669
https://github.com/macports/macports-ports/pull/19021
Sent: Friday, March 17, 2023 at 5:32 AM
From: "Christopher Chavez"
> I did report them to GitHub, but maybe someone part of MacPorts organization
> can report them more authoritatively…
Never mind, GitHub has already acted on my report and terminated the account
for violating ToS.
Sent: Thursday, March 16, 2023 at 10:24 PM
From: "Ken Cunningham"
> don't recognize the username
The GitHub account responsible for the edit looks like a QAnon-themed spammer
and/or bot (who also uses the name of the founder of Ethereum).
I did report them to GitHub, but maybe someone part of Ma
Sent: Wednesday, March 01, 2023 at 9:12 AM
From: "contextnerror "
> At ports.macports.org you can follow ports. Does this meet your needs?
Unfortunately I would say it does not. So far the only functionality I am aware
this provides is that it shows ports having versions updated or being
obso
Sent: Monday, January 30, 2023 at 12:48 AM
From: "Janick TAILLANDIER"
> I think you tested without a music CD in the drive…
> Could you please retry the test with a music CD? I can confirm I still see
> the problem with Ventura 13.2
Trac does not accept ticket comments via email. I have created
Sent: Wednesday, October 19, 2022 at 12:25 PM
From: "Alejandro Imass"
> I found a problem with dia (GNU dia diagraming app) in Apple Silicon and
> finally got it to compile and run. Was wondering what the process is to
> submit a patch ? Are there any docs I can read that describe the process of
…unless this can be merged without prior testing on on Apple Silicon (I’m not
expecting any issues):
https://github.com/macports/macports-ports/pull/14470
> Sent: Sunday, April 03, 2022 at 4:00 AM
> From: "Fred Wright"
> I verified that qt6-qtbase builds on 10.14. I don't have an easy way to
> test it.
Thank you for testing. However the proposed change is specifically to allow
building with the 10.14 SDK, and so what I wanted to be sure of is whet
Could someone with access to 10.14 please try this PR?
https://github.com/macports/macports-ports/pull/14427
Does the port (or output object qapplekeymapper.mm.o more specifically) now
build with the patch, or does it encounter other errors?
Thanks,
Christopher A. Chavez
https://github.com/macports/macports-ports/pull/14370
This patch has already been accepted upstream. I hope this allows the macOS 12
builders to finally build qt5-qtbase and dependents, which are rather popular
ports, and help identify dependents which are still having issues.
https://github.com/macports/macports-ports/pull/14204
https://github.com/macports/macports-ports/pull/13332 is ready for review and
possibly merging. Could a committer please take a look?
Christopher A. Chavez
Unless I should first wait for the cmake port maintainer to respond, I would
invite others especially those knowledgeable of trace mode internals to have a
look at https://trac.macports.org/ticket/64368
Christopher A. Chavez
> Before you mentioned the AppKit overhaul some time ago and started addressing
> it in your ports, I had never heard of it and I don't think anyone else's
> ports do anything about it. So either we have a lot of broken ports due to
> this problem that we're not aware of, or for some reason it u
I recently specified bin:node:… build dependency in qt5-qtwebengine. I would
not consider Node.js to be a lightweight dependency, so I thought it would be
preferable to allow using whichever is present, even a non-MacPorts one, before
having to install a fallback; and because I had not investiga
> https://github.com/macports/macports-ports/pull/12595
This update for qt5-qtwebengine has now built successfully on Monterey (both
ARM64 and x86_84). I believe it is ready for final review and merging. The port
maintainer has been unavailable for review. Can a committer please take a look?
Ch
> This brings up two questions:
> * Would it be feasible to update our 10.15 buildbot to a newer Xcode release?
> Or are there certain ports/situations that necessitate remaining with 11.7?
Xcode 12 prohibiting implicit function declarations is probably no longer a
reason since these must have b
Could a committer please have a look?
https://github.com/macports/macports-ports/pull/13065
Sent: Thursday, June 06, 2019 at 10:07 PM
From: "Ryan Schmidt"
> I am assuming that MacPorts base copies these files to the sip-workaround
> directory when it thinks they are being used.
>
> I note that macOS (High Sierra at least) ships with both /usr/bin/perl and
> /usr/bin/perl5.18. They are
> I think it would be preferable to have compiler.openmp_version allow using
> Xcode clang (if compatible) to reduce port-specific tricks.
I am proposing this in https://github.com/macports/macports-base/pull/247
> Is it okay if the extra flags needed for Xcode clang are passed to MacPorts’
>
> Error observed on macOS 12 Monterey
> for both x86_64 (Intel) and arm64 (Apple Silicon e.g. M1)
> described in https://trac.macports.org/ticket/63725
> and still observed when attempting to update to QtWebEngine 5.15.7:
> https://github.com/macports/macports-ports/pull/12595
I remain stumped by
Sent: Friday, November 12, 2021 at 8:08 PM
From: "Eric Borisch"
> Just looking for anyone interested to provide feedback on this:
> https://github.com/macports/macports-ports/pull/12933
> It uses '-Xpreprocessor -fopenmp' to get Apple's clang to compile OpenMP
> code; it still relies on li
Sent: Monday, November 08, 2021 at 2:58 PM
From: "Blair Zajac"
> Which nodejs version is the build failing on?
> On Nov 8, 2021, at 12:50 PM, Jimmy Yuen Ho Wong
> mailto:wyue...@gmail.com]> wrote:
>> This also have broken nodejs as well, I have 2 errors here:
>> ../src/node_crypto.cc:4585[h
Error observed on macOS 12 Monterey
for both x86_64 (Intel) and arm64 (Apple Silicon e.g. M1)
described in https://trac.macports.org/ticket/63725
and still observed when attempting to update to QtWebEngine 5.15.7:
https://github.com/macports/macports-ports/pull/12595
:info:build Undefined symbols
https://github.com/macports/macports-ports/pull/12595
A few users have requested that qt5-qtwebengine work on Apple Silicon, which
this PR hopes to provide but I cannot test myself. There could also be a much
neater approach for switching a single Qt module to a different source than
what I use
Sent: Friday, September 10, 2021 at 1:53 PM
From: "Chris Jones"
>> I corrected several examples already, but I doubt that I found all of them:
>> https://github.com/macports/macports-ports/pulls?q=is%3Apr+author%3Achrstphrchvz+is%3Aclosed+python+3.10
> Strictly speaking the fixes in the above lin
Sent: Tuesday, September 07, 2021 at 12:57 AM
From: "Mojca Miklavec"
> 3.) We have 20k+ ports. Many of them are outdated or broken and could
> use some love. What most people contribute to are updates to various
> ports that they personally care about.
I am not a MacPorts member, so my suggestion
Python 3.10.0 is expected to be released 2021-10-04, which will become the
python310 port.
Just want to remind others to be on the lookout for portfiles (usually for
ports not having `python` as the primary category) with version string handling
that erroneously assumed there would never be Pyt
Should CI/buildbots report any errors from `port rev-upgrade`? (I'm not aware
that they already do.)
Additionally, is it true that, once CI or a buildbot has built and installed a
port, `port rev-upgrade` should never report any errors? If so, should the
build be marked as failed if there are r
I have revived https://github.com/macports/macports-ports/pull/9695
I believe it is ready to merge, if there are no further comments.
Christopher A. Chavez
The deprecated 1.0 portgroup has a `deprecated.eol_version` option, which is
currently used in older Python ports.
I am trying to understand the distinction between this option and the existing
`deprecated.upstream_support` option, i.e. why adding a new
`deprecated.eol_version` option was neede
The MPI wrapper ports (openmpi, mpich) for Xcode avoid binary archives from
builders. The stated reason (currently in the mpiutil 1.0 portgroup) is that
the builder and user may have different Xcode versions. This goes back at least
to https://github.com/macports/macports-ports/commit/7c6fc1faa9
Asking on behalf of PR submitter if someone can please review and merge this:
https://github.com/macports/macports-ports/pull/8415
Thanks,
Christopher A. Chavez
https://github.com/macports/macports-ports/pull/9968
Sent: Wednesday, February 03, 2021 at 7:02 PM
From: "Ken Cunningham"
To: "MacPorts Developers"
Subject: mesa OpenGL header problem with mesa > 17 on SnowLeopard (and older)
-- help wanted
> I’m stuck, and that doesn’t happen so often to me.
>
> Something is going on that makes mesa versions > 1
Can a committer please review/merge
https://github.com/macports/macports-ports/pull/8220 ?
The port maintainer is okay with the changes.
Thanks,
Christopher A. Chavez
So far the versions for Python have been able to compact into two-digit
strings: e.g. 36 37 38 39. Is the compacted version number for next year's
Python 3.10 going to be "310"?
If so, there is code in portfiles which requires adjustment. Common example:
set pbranch [string range ${pver} 0 end
Hello Michael,
Thank you very much for this information. I am forwarding this to the
macports-dev mailing list for others who are involved in MacPorts more closely
and for much longer than I have been.
On Friday, October 16, 2020 at 6:32 PM, Mike Pique wrote:
> I have a DTK and have built Ope
> Comment (by kencu):
> …Ryan has made it clear he does not want every build to be forced to a
> macports clang compiler as that causes the drives on the buildbots to die
> prematurely due to all the installing and uninstalling of macports-
> clang-9.0 (or whichever is the head of the line at that
> I've been putting off the upgrade to XCode 12 for a while, since I kinda
> got burned by the upgrade from 10 to 11. I haven't seen any reports of
> problems with the new version, but I thought I'd ask -- any reason not to
> upgrade at this point?
It seems the most frequently encountered issue so
Can MacPorts hardcode references to Xcode.app, by assuming it is at
/Applications/Xcode.app (as when installed from the App Store), and/or that it
will remain wherever it was found and won't ever be moved/deleted?
I would think the answer is "no": it is outside of MacPorts' control, and some
us
The gpg_verify 1.0 PortGroup was added one year ago. I count 5 ports which are
using it (4 of which were setup by the author of the PortGroup soon after it
was introduced). However there are many more ports which could be using it. It
would be nice if one day the MacPorts guide encouraged using
Continuing the recent topic of (L)GPL port openssl dependency
nonredistributability:
I notice the spread-sheet-widget port claims to be affected by this.
It is not a large port, but it only has coreutils and pkgconfig as build
dependencies, and gtk3 as a library dependency, and all direct dependen
Joshua Root (2020-09-09 00:34):
> On 2020-9-9 05:08 , Jason Liu wrote:
>> Does this mean that the Blender port is yet another victim of The Curse
>> of the OpenSSL License?
> Yes (though you could equally call it the Curse of the GPL, as both are
responsible).
An idea I haven't seen mentioned wou
Sent: Monday, August 17, 2020 at 12:28 PM
From: "Ken Cunningham"
To: "MacPorts Developers"
Subject: port release candidate versioning question
> This sounds like a dumb question, that I should already know the answer to,
> but apparently I don’t seem to:
> I would like to make sure this works th
On 8/5/2020 8:12 AM, Lothar Haeger wrote:
Am 05.08.2020 um 14:52 schrieb Georges Martin mailto:jrjsm...@gmail.com>>:
If MacPorts starts to mix both approaches, I worry we may end up
having (open source) packages depending on closed source, binary
packages. And have less control on ensuring
On 8/4/2020 12:52 PM, Ruben Di Battista wrote:
One of the reasons I chose Macports for is the fact it builds its own
tree from source and it ships basically open source only software.
I think there have been cases where MacPorts' preference/insistence on
building from source, even when prebuilt
On 8/4/2020 5:21 PM, Fred Wright wrote:
I don't know how "babyname.tips" got into the mirror list, since the
name suggests that it's completely inappropriate, but it seems to have
been there for almost three years, due to commit 49ffee556c1a. Perhaps
that's been benign until recently, but now vi
In https://trac.macports.org/ticket/60509 it is explained that MacPorts
uses pings to find nearby servers, and it is claimed nearby servers will
likely be the fastest.
I'm not a network engineer, but can say this claim is a myth. The
purpose of ping is to measure latency, not bandwidth. Yes, suff
https://github.com/macports/macports-ports/pull/6909 has been open for
some time, but it has had no feedback from the maintainer nor anyone else.
The PR was initially for having the libpcl port use
compiler.openmp_version instead of a compiler blacklist. However I found
that the port has also bee
On 6/5/2020 12:32 PM, Clemens Lang wrote:
or switch to a different source, e.g. git
As a user, I've thought it would be great if MacPorts used git syncing
by default. I have used git-over-https since 2016 when I was constrained
to ports 80/443 by a university campus network. I had found it also
On 3/28/2020 1:58 AM, Joshua Root wrote:
On 2020-3-28 17:45 , SAPTARSHI MUKHERJEE wrote:
Hi All,
Trying the build of port jamvm (after modification in an attempt to
update to version 2.0.0) on MacOS Catalina, I'm encountering an error as
"*x86_64-apple-darwin19.3.0 not supported*". The associat
> On Aug 31, 2019, at 7:30 PM, Ralph Seichter wrote:
>
>> You’ll want to avoid the PATH approach as it requires that
>> ${prefix}/bin/python be symlinked to a Python 3.x, which isn’t always
>> the case.
>
> Not always, but it is for me:
>
> $ ls -dl /opt/local/bin/python
> lrwxr-xr-x 1 root
> On Jun 12, 2019, at 4:47 PM, Bruce R Miller via macports-dev
> wrote:
>
> So, I tracked it down to the Makefile that perl's MakeMaker generates;
> an innocuous thing called "fixin" does that substitution.
Possibly related: it is a known issue in MakeMaker that `#!/usr/bin/env perl`
in scr
On 5/22/2019 4:37 PM, Joshua Root wrote:
Discussion on IRC indicates it was done from the GitHub web UI.
My impression is they were using GitHub desktop
(https://desktop.github.com/).
On 5/19/2019 1:40 PM, Mark Anderson wrote:
making it possible to re-run CI from GitHub commits.
As a PR submitter, one workaround I'm aware of is rebasing the PR
commit(s). I'm not sure that's something members can/should try though,
so a better solution is probably still preferred…
I have opened a pull request to remove the 500+ ports for PHP PEAR
modules and their portgroup:
https://github.com/macports/macports-ports/pull/4192
This was suggested by Ryan in https://trac.macports.org/ticket/56424 .
Perry agreed with this idea.
One question I have is whether ports PEAR modul
On 4/28/2019 7:57 AM, Ruben Di Battista wrote:
Here’s the port I’m writing (https://gitlab.com/snippets/1851912).
Hi Ruben,
One comment on this approach: I'm not sure it is a good idea to override
`master_sites` in Portfiles that use the github PortGroup. Usually any
tweaking of which download
On 4/20/2019 3:55 PM, Helmut K. C. Tessarek wrote:
Thanks for the reply.
On 2019-04-20 02:19, Nils Breunese wrote:
I haven’t tried it, but Google brought me to a StackExchange post saying you
can use RCDefaultApp, or use
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
(Currently at least one port maintainer suggested their Lisp ports be removed
from MacPorts due to the community preference for Quicklisp. However it appears
that removing ports is not preferred particularly for maintained software with
no known issue being delivered by MacPorts.)
An idea for t
Currently, comments in Portfiles containing dates, such as for when remove
something in the future, are specified in whichever scheme preferred by the
port maintainer or whoever inserted the date. Some of these schemes are
region-specific (e.g. mm/dd/ used in the US) and potentially ambiguou
> On Apr 5, 2019, at 8:18 PM, Gabriel Rosenkoetter wrote:
>
> On 2019-04-05 17:02 EDT, MacPorts wrote:
>> #58307: [port abandoned] abcde
>> Maintainer has not had any activity
>> [https://trac.macports.org/search?q=eclipsed.net since 2016] and had been
>> assigned #56443.
>>
>> #48948 was also o
Hi Mihir, I am a MacPorts user and port maintainer. I have a suggestion, but am
not a member, so do not take my advice as canon.
> On Mar 23, 2019, at 1:52 PM, Mihir Luthra <1999mihir.lut...@gmail.com> wrote:
>
> I was thinking to add an 8th section which gives a small high level tour of
> the
I would like to mark the DesktopManager port as deprecated due to no upstream
support. The Portfile currently checks ${os.major} for an exact version. Should
specifying `deprecated.maximum_osmajor` be avoided due to being redundant?
Conversely, for ports that can be deprecated but are checking `
There is a configuration flag `--enable-64bit` included in the portfile
for Tk, and is enabled as long as not building for universal.
This flag also appears to be available for Tcl and various Tcl/Tk
extensions as well: Tix, Img, tktable, possibly others. Should those
similarly be using `--ena
66 matches
Mail list logo
