Re: inserting -stdlib=libstdc++ into cxxflags

[Ken Cunningham]

the clang-10-bootstrap port builds against libstdc++ now.

K

npm portgroup default version

[contextnerror]

Is there a reason why the npm portgroup still defaults to nodejs16? It’s been 
EOL for a little bit now.

Re: inserting -stdlib=libstdc++ into cxxflags

[Ken Cunningham]

sorry, clang-11-bootstrap

> On Mar 23, 2024, at 00:01, Ken Cunningham  
> wrote:
> 
> the clang-10-bootstrap port builds against libstdc++ now.
> 
> K

Re: npm portgroup default version

[Blair Zajac]

It’s only seen two commits in its entire history with only a handful of ports 
using it:

bash-language-server
eask-cli
pnpm
pyright
typescript-language-server
bitwarden-cli

With this low number of ports, one could check if they work with nodejs20.

Blair

> On Mar 23, 2024, at 12:01 AM, contextnerror  wrote:
> 
> Is there a reason why the npm portgroup still defaults to nodejs16? It’s been 
> EOL for a little bit now.
> 

cmake-devel --> cmake coming .... please test if you care to

[Ken Cunningham]

the cmake port is very very far behind.

cmake-devel has been updated to the newest version currently available (3.29.0) 
for most systems, and then newest supportable (3.28.4) for 10.7 and < 10.6.

Please try out if you care to, as cmake-devel should become cmake soon.

If you are interested in the issues regarding v3.29.0 on 10.7 (kernel panic) or 
< 10.6, there are details here:

https://trac.macports.org/ticket/67540 

If you are a keener with debugging on 10.7, and can sort out a proper fix for 
3.29.0 on 10.7, upstream will love you. Most likely eventually we/they will use 
the commits they added to the 3.28.N branch to fix it for those systems, 
although those commits are more involved that we usually like to carry.

K

Re: Ruby question: solution for dependency version specs?

[Fred Wright]

On Sun, 17 Mar 2024, Sergio Had wrote:

I have no idea what is going on with archaic versions, but Ruby 3.1+ 
through ruby-devel (3.4) should work on every system.


Please stop posting falsehoods. Ruby 3.1-3.3 most certainly do *not* work 
on every system (yet), and I posted a list of the failing cases in another 
thread where you were a participant.  I haven't looked at 3.4.


They are, and everything relevant is rb33-* etc. Unversioned one which 
use rb18 should re updated or removed: we have no reason to keep Ruby 
versions prior to 3.0, since 3.0 works on Tiger, and 3.1+ work on 
Leopard through Sonoma. That also includes PowerPC systems.


Again, false.

For at least the past few years, no version of Ruby has worked on all 
systems until I personally fixed it, and I haven't had a chance to fix 
anything later than 3.0 yet.  And contrary to popular belief, Ruby 3.0 
isn't (quite) EOL yet.


As far as having multiple versions goes, Ruby is just like many other 
things, where having multiple versions is useful for (at least):


1) Testing code against multiple versions.

2) Using a textbook that is based on a particular version.

3) Avoiding brokenness in one or more versions.

No too long ago, the instructions for building the RaspberryPi docs stated 
that asciidoctor needed to be run with Ruby 2.7 because it didn't work 
properly with 3.0 (at least for their files).  While that no longer seems 
to be the case, it does serve to illustrate that newer isn't always 
better, and that it's best to give users a choice as to what version to 
use, rather than inflicting someone else's notion of the one true best 
version on them.


On Sat, 16 Mar 2024, Austin Ziegler wrote:


I also think that the `ruby` port needs to be renamed to `ruby18` and `port
install ruby` should *either* fail (like `port install python` or `port
install python3` does) or it should install the latest stable version
(updated on Christmas Day every year).


Agreed.  Presumably this came about because having multiple versions 
wasn't initially anticipated.  It's unfortunate that (unlike some other 
packaging systems) MacPorts doesn't have a way to directly make multiple 
versions of something available without resorting to the kludge of 
building the version number into the name.


Fred Wright

Re: Ruby question: solution for dependency version specs?

[Gagan Sidhu via macports-dev]

dear fred,

i understand this is the dev mailing list and politeness does not supersede 
correctness given the topical nature of this mailing list.

i am the last one to be pedantic, but serge *did* qualify his statement with a 
“should” (i.e. expectation), meaning it was not absolute.

let us not be too strong with our correctness and trample the spirit of our 
already-scarce contributors, lest we want them to defect to our snooty 
fink-derived alcohol competitor.

ta ta’

Thanks,
Gagan

P.S/ valerio, you know what’s coming next time you post, so be ready. 
-i didn’t want to scare you off by saying it earlier this week, because 
i was already worried i scared you off the first time!

> On Mar 23, 2024, at 6:59 PM, Fred Wright  wrote:
> 
> 
> On Sun, 17 Mar 2024, Sergio Had wrote:
> 
>> I have no idea what is going on with archaic versions, but Ruby 3.1+ through 
>> ruby-devel (3.4) should work on every system.
> 
> Please stop posting falsehoods. Ruby 3.1-3.3 most certainly do *not* work on 
> every system (yet), and I posted a list of the failing cases in another 
> thread where you were a participant.  I haven't looked at 3.4.
> 
>> They are, and everything relevant is rb33-* etc. Unversioned one which use 
>> rb18 should re updated or removed: we have no reason to keep Ruby versions 
>> prior to 3.0, since 3.0 works on Tiger, and 3.1+ work on Leopard through 
>> Sonoma. That also includes PowerPC systems.
> 
> Again, false.
> 
> For at least the past few years, no version of Ruby has worked on all systems 
> until I personally fixed it, and I haven't had a chance to fix anything later 
> than 3.0 yet.  And contrary to popular belief, Ruby 3.0 isn't (quite) EOL yet.
> 
> As far as having multiple versions goes, Ruby is just like many other things, 
> where having multiple versions is useful for (at least):
> 
> 1) Testing code against multiple versions.
> 
> 2) Using a textbook that is based on a particular version.
> 
> 3) Avoiding brokenness in one or more versions.
> 
> No too long ago, the instructions for building the RaspberryPi docs stated 
> that asciidoctor needed to be run with Ruby 2.7 because it didn't work 
> properly with 3.0 (at least for their files).  While that no longer seems to 
> be the case, it does serve to illustrate that newer isn't always better, and 
> that it's best to give users a choice as to what version to use, rather than 
> inflicting someone else's notion of the one true best version on them.
> 
> On Sat, 16 Mar 2024, Austin Ziegler wrote:
> 
>> I also think that the `ruby` port needs to be renamed to `ruby18` and `port
>> install ruby` should *either* fail (like `port install python` or `port
>> install python3` does) or it should install the latest stable version
>> (updated on Christmas Day every year).
> 
> Agreed.  Presumably this came about because having multiple versions wasn't 
> initially anticipated.  It's unfortunate that (unlike some other packaging 
> systems) MacPorts doesn't have a way to directly make multiple versions of 
> something available without resorting to the kludge of building the version 
> number into the name.
> 
> Fred Wright

Humor + Thanks

[Frank Stock]

>On Mar 23, 2024, at 6:06 PM, Gagan Sidhu via macports-dev 
> wrote:
>our snooty fink-derived alcohol competitor
LOL

Can I just say to every contributor (past and present) how much I appreciate 
the MacPorts architecture and design. 
Why anyone would intentionally *replace* *shared* system files is beyond me!

-Frank

Unable to build Xcode projects using SwiftPM in MacPorts sandbox

[Zero King]

Hi,

As I try to package the latest commit of poedit, I encountered the 
following error:


Failed to determine if database is empty or not: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have 
permission to save the file “org.swift.swiftpm” in the folder “Caches”." 
UserInfo={NSFilePath=/opt/local/var/macports/home/Library/Caches/org.swift.swiftpm, NSUnderlyingError=0x6010daa0 
{Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}Failed to determine if database is empty 
or not: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “org.swift.swiftpm” 
in the folder “Caches”." UserInfo={NSFilePath=/opt/local/var/macports/home/Library/Caches/org.swift.swiftpm, 
NSUnderlyingError=0x61e180c0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

I think it could be base's sandbox that prevented writes to the home 
directory, where SwiftPM stores its cache.


Any ideas?

--
Zero

Re: Unable to build Xcode projects using SwiftPM in MacPorts sandbox

[Ryan Schmidt]

On Mar 23, 2024, at 23:00, Zero King wrote:
> 
> I think it could be base's sandbox that prevented writes to the home 
> directory, where SwiftPM stores its cache.

If disabling sandboxing in macports.conf makes it work, then your suspicion is 
probably correct. 

MacPorts sets the HOME environment variable to point to a directory within 
workpath. It looks like it's ignoring that and trying to write to a 
subdirectory of the macports user's real home directory, 
/opt/local/var/macports/home. That would be a bug to file with Apple. It has 
been a long-standing problem that has affected MacPorts in other ways before.